RM Compliance
llms.txt
SOC 2/Policies21

Business continuity, disaster recovery and backup policy

Version0.1 draft
OwnerInfrastructure Owner
ReviewYearly, and after every disaster recovery exercise
Applies toEvery in-scope service and its data
Markdown

Recovery objectives#

Set per service. Publish to customers only what the exercise has measured.

Service RTO (time to restore) RPO (data loss accepted) Measured in last exercise
Gate [4 hours] [24 hours] [not yet]
Mail [8 hours] [24 hours] [not yet]
Drive [8 hours] [24 hours] [not yet]
Meet [4 hours] n/a (no stored state beyond recordings) [not yet]
Writer, Sign, Bills [8 hours] [24 hours] [not yet]
RM Cloud per client contract per client contract [not yet]

Backups#

  1. Every in-scope database is backed up at least daily AVL-03. Write-heavy databases add continuous archiving (WAL) where the RPO needs it.
  2. Backups are encrypted before leaving the host and stored in a separate account and a separate region from production, with versioning and deletion protection. A backup that lives only on the machine it protects is not a backup.
  3. Object storage (Drive files, uploads) is versioned or replicated to the backup account.
  4. Retention: 30 daily, 12 monthly, consistent with the retention defaults. Deletion requests propagate to backups within the stated window, or on restore.
  5. Backup failure alerts a human OPS-02.
  6. The backup inventory lists each data store, its backup job, destination, encryption key reference and last successful run.

Restore testing#

  1. Monthly, the latest backup of each in-scope database is restored into a scratch environment and verified by row counts against production and by booting the application against it AVL-04. The record keeps the backup timestamp, restore duration, and result.
  2. A backup that has never been restored is treated as untested and does not count toward the RPO.

Disaster recovery#

  1. Scenarios planned for: loss of the production host or region, loss of the database, compromise of the cloud account, loss of the edge provider account, loss of the source host, loss of a key person.
  2. Recovery runbooks per service: rebuild infrastructure from code, restore data from backup, re-point DNS, verify.
  3. Yearly exercise: rebuild at least one service end to end in a clean environment and measure RTO and RPO AVL-05.
  4. Credentials needed during a disaster (cloud root, registrar, Cloudflare, backup account, break-glass) are reachable without the production systems, held by at least two people.

Business continuity#

  • At least two people can deploy, restore and operate every in-scope service. Knowledge that exists only in one head, or only in an AI agent's memory files, is written into the runbooks.
  • Customer communication during an outage uses a status page or channel that does not run on the affected infrastructure.