Skip to content

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:
    1. Identify the most recent successful backup.
    2. Initiate the restoration process from the GCS storage bucket.
    3. 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:
  1. Retrieving the latest backup from GCS.
  2. Verifying the integrity of the source code before reintegration.
  3. 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:
    1. Incident detection and notification to the CTO.
    2. Identification of the affected system(s).
    3. Restoration of data from the most recent backup.
    4. Verification of data integrity and functionality post-restoration.
    5. 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