Business Continuity and Disaster Recovery Plan
Organization: Aina Design Corp
Applies To: hawaii.mokunet.us · kuleana.ainadesign.org · huikoeaina.ainadesign.org · ainadesign.org
Version: 1.0
Effective Date: February 20, 2026
Next Review: February 20, 2027
Policy Owner: Security Lead
This plan defines how Aina Design Corp maintains continuity of platform services for district partners and recovers from disruptive events — including data loss, infrastructure outages, or security incidents — with minimal impact to ongoing educational programs.
Recovery Time Objective (RTO)
Critical services restored within 4 hours of declared disruption
Recovery Point Objective (RPO)
No more than 24 hours of data loss for student records
Districts notified within 2 hours of a confirmed service disruption
Firebase Hosting + Supabase
Firebase Hosting + Supabase
huikoeaina.ainadesign.org
Firebase Hosting + Supabase
Email / Campaign Functions
This plan addresses the following disruption scenarios:
Cloud provider outage (Firebase, Supabase)
High — platform unavailable
Data corruption or accidental deletion
High — student data at risk
Ransomware or destructive cyberattack
High — platform unreachable
Key personnel unavailability
Third-party API dependency failure
•
Supabase automated backups are enabled on all production projects.
•
Backup frequency: Daily (point-in-time recovery enabled where available).
•
Backup retention: 14 days for standard backups; 30 days for project archive snapshots at contract close.
•
Backup restoration is tested at least once per year and documented.
5.2 File and Media Storage
•
Student-uploaded files are stored in cloud object storage with versioning enabled.
•
Storage bucket backups are configured to replicate to a secondary region.
5.3 Configuration and Code
•
All platform code is version-controlled in Git.
•
Infrastructure configuration is documented and stored in version control.
•
Secrets are stored in Firebase Secret Manager with access logs.
6.1 Detection and Declaration
A business continuity event is declared when:
•
A production service is unavailable for more than 30 minutes, or
•
Student data integrity is at risk, or
•
The Security Lead determines that a threat warrants activation.
The Security Lead has authority to declare a continuity event and activate this plan.
1.
Internal team notified immediately via primary communication channel.
2.
Affected district partners notified within 2 hours with:
•
Interim guidance for affected users
1.
Assess — Determine scope of impact (which services, which districts, what data).
2.
Isolate — If security-related, isolate affected systems before recovery.
3.
Restore — Restore from most recent clean backup; use runbook for each service.
4.
Verify — Confirm data integrity and service functionality before bringing users back.
5.
Communicate — Update districts on restoration status.
6.
Review — Complete post-incident review within 5 business days.
Service-specific recovery runbooks are maintained by the Engineering team and stored in the internal documentation repository. Runbooks are reviewed annually and updated after any recovery event.
•
Supabase database restoration
•
Firebase Hosting redeployment
•
Cloud Function redeployment
8. Key Personnel and Contacts
Declare events, lead recovery
Designated backup named in internal contacts
Execute technical recovery
On-call rotation documented internally
Communicate with district partners
Contact information for all key personnel is maintained in the internal emergency contacts document (not published publicly).
Tabletop exercise (plan walkthrough)
Results are documented and incorporated into plan updates.
This plan is reviewed annually and updated after any declared continuity event or significant change to platform architecture.
Security Lead: _________________________
Engineering Lead: _________________________
Date Approved: _________________________