← All policies

Business Continuity & Disaster Recovery Plan

1. Purpose

To define the Company's commitments and procedures for maintaining the availability of the Cadences.work service in the face of disruption, and for recovering it within stated objectives when disruption occurs.

2. Scope

The production environment of Cadences.work — application (Vercel), database and authentication (Supabase), email delivery (Postmark), AI inference (OpenAI), domain and DNS, source code (GitLab) — and the operational continuity of the Company itself.

3. Recovery objectives

These targets are the Company's commitments to customers in the Data Processing Agreement and the Trust page.

4. Backup strategy

4.1 Database

• Mechanism: Supabase point-in-time recovery (PITR), included with Pro tier.
• Retention: 30 days minimum.
• Encryption: AES-256 at rest, provider-managed keys.
• Geographic redundancy: backups stored in the same EU region as the primary, with multi-AZ replication.
• Access control: limited to the Director's Supabase project-owner account, protected by TOTP MFA and Google Workspace 2-Step Verification on the Director's Google identity.

4.2 Source code

• Primary: GitLab repository (private).
• Local mirrors: developer's workstation has a full clone; a periodic offline backup is stored on an encrypted external drive at a separate physical location.
• Retention: indefinite via Git history.

4.3 Configuration

• Vercel project settings: documented in this repository (vercel.json, environment variables list in .env.example); current values stored in the Vercel dashboard with read-only export available to the Director.
• Supabase project settings: captured in supabase/config.template.toml with secrets via env(...) interpolation.
• Secrets: stored in the password manager; not stored in source.

4.4 Documentation and policies

• Source: this repository (Git-versioned).
• Continuity copy: a periodic export to the Director's offline encrypted drive ensures availability if both GitLab and the Company's primary cloud accounts are simultaneously unavailable.

5. Restore procedures

5.1 Database restore

1. Identify the point in time to restore to (typically just before the incident).
2. From the Supabase dashboard, initiate point-in-time recovery to a new project / branch.
3. Validate data integrity by sampling expected records.
4. Update application connection strings to the recovered project (or restore data in place if the original project is intact).
5. Smoke test the application end-to-end.
6. Communicate restoration completion to affected customers.

5.2 Application rollback

1. From the Vercel dashboard, identify the last known-good production deployment.
2. Use Instant Rollback to switch the production alias to that deployment.
3. Smoke test.
4. Investigate the broken deployment in a non-production branch.

5.3 Source-code recovery

1. If GitLab is unavailable, restore from local mirror to a temporary remote (GitHub, Bitbucket, or local Git server).
2. Update Vercel's source binding if redeployment is needed.
3. Re-establish on GitLab once available.

6. Continuity scenarios

7. Founder unavailability (continuity-of-control)

The Company is currently a one-person organisation. The risk that the Director is unavailable (illness, accident, travel without connectivity, worse) is non-zero and is treated as a primary continuity scenario.

Mitigations in place:

• Sealed emergency kit: a sealed envelope at the Director's residence contains password-manager emergency-access details, Google account 2-Step Verification backup codes, and instructions. A designated trusted contact (next of kin) knows where it is and what to do.
• Trusted contact's instructions: in the event of incapacity, the trusted contact opens the kit and contacts the EU Representative and the Company's accountant. The kit contains a pre-drafted letter to customers explaining service continuity.
• Cyber-incident-line equivalent: the Director maintains an account with [a fractional CISO / IR retainer or service to be engaged] that can be activated by the trusted contact for technical continuity.
• Account inheritance plans: critical SaaS accounts (Vercel, Supabase, GitLab, domain registrar) have legacy / inheritance settings configured where supported.

These mitigations are reviewed annually and updated whenever personal circumstances change.

8. Testing

• Annual restore drill: a database restore is performed to a non-production environment; the restored environment is smoke-tested; results are recorded.
• Quarterly tabletop: a continuity scenario from §6 is walked through on paper with timing estimates.
• After every infrastructure change affecting backups: a focused test is performed.

Test outcomes are recorded in docs/compliance/incidents/exercises/ and feed back into this Plan.

9. Communications during a continuity event

• Status page: TBD — until a dedicated status page is operational, status updates are posted on the marketing site banner and emailed to the primary admin contact of each customer.
• Customer communications template: held in docs/compliance/templates/ and used by the Communications Lead.
• Escalation contacts: the Incident Response Runbook §Contact log lists pre-populated sub-processor and advisor contacts.

10. Insurance

The Company maintains, or will obtain by 2026-Q3:

• Cyber liability insurance with first-party coverage for incident response, data restoration, and customer-notification costs, and third-party coverage for regulatory penalties and customer claims.
• Professional indemnity for service-delivery errors.

11. Compliance and references

ISO/IEC 27001:2022 Annex A: A.5.29 (information security during disruption), A.5.30 (ICT readiness for business continuity), A.8.13 (information backup), A.8.14 (redundancy of information processing facilities).

ISO/IEC 22301:2019 Business continuity management systems — Requirements (referenced for terminology).

GDPR Article 32(1)(c) (the ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident).

12. Version history