Backup Policy
Breakout Learning Inc.
Purpose
To protect the confidentiality, integrity, and availability of data, both for Breakout Learning Inc. and its customers, regular backups are performed (typically on a weekly basis) to ensure that data remains available when needed and in the case of a disaster.
Policy
Breakout Learning Inc. requires the following to ensure proper data backup and recovery processes:
- Data Classification:
All data must be classified at the time of creation or acquisition, following the Data Classification Policy. - Inventory and Data Flow Map:
An up-to-date inventory and data flow map of all critical data are maintained. This includes:- Firestore database
- Google Cloud Storage (GCS) blob storage
- Source code
- Backup Scope:
- Data that needs to be backed up includes our Firestore database, GCS blob storage for the app, and source code.
- Firestore database and GCS blob storage data are backed up to another GCS blob storage bucket.
- Source code is backed up on GitHub and replicated to Breakout Learning Inc.’s GCS account daily.
- Data Storage and Replication:
All business data must be stored or replicated into a company-controlled repository, including data on end-user computing systems. - Backup Frequency:
- Firestore database and GCS blob storage are backed up daily to ensure business continuity.
- Source code backups occur daily and are stored in GCS for redundancy.
- Data Retention:
- The retention period for data must comply with applicable regulatory and contractual requirements.
- Customer data is retained per Breakout Learning Inc.’s product terms and conditions.
- Security documentation and audit trails are retained for a minimum of seven years, unless otherwise specified by Breakout Learning Inc.'s Data Classification Policy and applicable regulations.
Backup and Recovery Procedures
Customer Data
- Storage and Backup:
Customer data is securely stored in a GCP production account, utilizing Firestore databases. GCS provides infrastructure designed for 99.999% durability of objects. - Automated Backups:
Breakout Learning Inc. performs automated backups of all customer and system data. Backups are encrypted using the same security mechanisms as production data. - Backup Monitoring:
Backups are monitored by Google Cloud Monitoring. In case of backup failure, an incident is triggered, alerting the CTO. - Restoration Procedure:
In the event of a disaster or data loss, the restoration process for customer data will follow these steps:- Identify the most recent successful backup.
- Initiate the restoration process from the GCS storage bucket.
- Confirm the integrity of the restored data through an integrity check before the system is returned to production.
- Storage and Backup:
Source code is stored in GitHub repositories, which are backed up daily to Breakout Learning Inc.’s GCS account. - Restoration Procedure:
If GitHub experiences data loss, source code will be restored from GCS by:
- Retrieving the latest backup from GCS.
- Verifying the integrity of the source code before reintegration.
- Redeploying the code to production if required.
Integrity of Backups
- Breakout Learning Inc. verifies the integrity of all backups by conducting regular checks and audits.
- Any inconsistencies or failures in the backup process are addressed immediately, and corrective actions are taken to ensure future backups succeed.
Recovery Procedure
- In the event of a system failure, Breakout Learning Inc. follows a documented recovery procedure:
- Incident detection and notification to the CTO.
- Identification of the affected system(s).
- Restoration of data from the most recent backup.
- Verification of data integrity and functionality post-restoration.
- System return to production.
Environmental Protection Mechanisms
- Backups are stored in geographically redundant locations within GCS to protect against environmental threats and ensure availability.
Revision History
Version |
Date |
Editor |
Approver |
Description of Changes |
1.1 |
2024/10/01 |
Nikita Rogatnev |
Joshua Oster-Morris |
Standardized role titles across all relevant policies, replacing previous variations |
1.0 |
2024/01/01 |
Joshua Oster-Morris |
Jake Shepherd |
Initial version |