Backup & Recovery Policy

1. Purpose and Scope

This Backup and Recovery Policy defines the processes and controls for backing up noIM₃ data and systems, and for restoring them in the event of data loss, corruption, or a disaster scenario. The goal is to minimise data loss and restore normal operations within defined timeframes.

This policy applies to:

• All production databases containing customer and platform data
• Platform configuration files and infrastructure state
• Application code repositories
• Critical business data and operational records

2. Recovery Objectives

[Fill in your actual RPO and RTO targets based on your infrastructure and business requirements.]

• Recovery Point Objective (RPO): The maximum acceptable data loss in time. Target: [e.g. 24 hours].
• Recovery Time Objective (RTO): The maximum acceptable downtime before service is restored. Target: [e.g. 4 hours].

3. Backup Schedule

Database backups

[Describe your database backup frequency and method, e.g. automated daily snapshots via your hosting provider.]

• Frequency: [e.g. Daily automated snapshots]
• Retention: [e.g. 30 days rolling]
• Method: [e.g. Managed snapshots via Supabase / Vercel Postgres / AWS RDS]

Application and configuration

• Source code is version-controlled in Git with a hosted remote repository (e.g. GitHub)
• Infrastructure configuration is managed via [e.g. code/Terraform/Vercel project settings]
• Environment variables and secrets are stored in [e.g. Vercel environment settings / AWS Secrets Manager]

4. Backup Storage

[Describe where backups are stored, geographic redundancy, and encryption status.]

Backups are stored in [location/region] with encryption at rest. Backups are geographically separated from primary data where practicable. Access to backup storage is restricted to authorised personnel only.

5. Backup Verification and Testing

Backups are only as valuable as their ability to be successfully restored. We conduct periodic restore tests to verify backup integrity and validate recovery procedures.

• Backup integrity verification: [e.g. Weekly automated checksum validation]
• Full restore test: [e.g. Quarterly, to a non-production environment]
• Test results are documented and reviewed

[Document your actual testing schedule and who is responsible for conducting and reviewing tests.]

6. Recovery Procedures

Data loss or corruption

1. Identify the scope and cause of data loss or corruption
2. Isolate affected systems to prevent further damage
3. Identify the most recent clean backup point
4. Initiate restoration from backup per documented restoration procedures
5. Verify data integrity post-restoration
6. Notify affected customers where required under privacy obligations
7. Document the incident, root cause, and remediation steps

[Link to your detailed restoration runbook or incident response procedure here.]

7. Disaster Recovery

In the event of a major incident affecting platform availability (e.g. provider outage, data centre failure, ransomware), the following steps apply:

1. Declare a disaster recovery event and notify relevant personnel
2. Assess the extent of the impact and estimated recovery timeline
3. Communicate status to customers via [status page / email / social channels]
4. Activate disaster recovery procedures appropriate to the incident type
5. Restore from backup to recovery environment
6. Validate platform functionality before returning to production
7. Conduct post-incident review within [e.g. 5 business days]

8. Responsibilities

[Define who is responsible for backup monitoring, testing, and recovery execution.]

• Backup owner: Responsible for monitoring backup jobs and ensuring schedules are maintained.
• Recovery lead: Responsible for coordinating and executing recovery procedures during an incident.

9. Policy Review

This policy is reviewed annually, following any significant data loss or recovery event, or when infrastructure changes materially alter backup or recovery capabilities.