Skip to main content

Backup & Recovery Policy

Document control

FieldValue
OwnerRon Benisty — CTO & CSO (ron.b@iontwrks.com)
StatusApproved
Version1.0
ClassificationConfidential
Approved byRon Benisty — CTO & CSO
Approval date2026-05-26 (Tuesday)
Last reviewed2026-05-26
Review cycleAnnual — next review due May 2027
Parent policySecure SDLC (SSDLC)

Satisfies ISO/IEC 27001:2022 A.8.13 (information backup) and supports SOC 2 Type II CC7.5 (recovery from identified events). Closes the backup portion of the SSDLC gap analysis. The mechanism is implemented in Architecture §Data layer + §DR; this policy states it as a named control with verification cadence.


1. Purpose

Ensure that — for every category of data S.E.T holds — there exists a tested, encrypted, retention-bounded backup, and that the procedure to restore it is exercised on a schedule.

2. Scope

DataMechanismRetention
RDS Postgres — all tenant schemas + control-planeMulti-AZ + continuous WAL + PITR35 days prod, 3 days nonprod (Environments)
RDS Postgres — DR copyCross-region encrypted snapshotPer Architecture §DR lifecycle
S3 Evidence bucketVersioning + Object Lock (Compliance)Bound by Object Lock; lifecycle to Glacier Deep Archive after threshold
S3 Documents bucketVersioningLifecycle-aged
S3 Backup bucket (RDS exports + CloudTrail archive)Object Lock (Compliance)7 years
CloudTrailMulti-region trail → S3 (Object Lock)7 years
ECR container imagesImage immutability + lifecycle retentionLast 50 images per repo
Terraform stateS3 with versioning + DynamoDB lockIndefinite (small)
Customer audit audit_events (per tenant schema)Lives inside the RDS backup above; append-only at the DB-role level7 years

3. Encryption

  • Every backup is AES-256-encrypted with KMS Customer-Managed Keys (CMKs) per environment.
  • CMKs do not cross account boundaries — even an exfiltrated backup cannot be decrypted in a different environment.

4. Verification cadence (Type II will sample these)

CadenceActivityOutput
WeeklyAutomated RDS restore test — restore a recent snapshot to a sandbox, run smoke checks, tear downA pass/fail log per week
MonthlyS3 Evidence-bucket integrity check — sample object versions, confirm Object Lock retention, read-back checksumsA pass/fail log per month
AnnuallyFull Disaster Recovery drill — restore prod from cross-region encrypted backup; redeploy via Terraform runbook; validate RTO < 24 h, RPO < 15 minA DR-drill report

Failed restore tests are treated as Sev 2 incidents and trigger the Incident Response Plan — a backup that does not restore is not a backup.

5. Restore authority

Only the CTO & CSO (or a delegated S.E.T-team member during an active incident) may invoke a production restore. Restores are executed via the documented runbook in shared-services, never via console clicks. Every restore is logged in CloudTrail and in the incident record (if any).

6. Per-tenant restore (procedural note)

Schema-per-tenant (Multi-Tenancy) makes per-tenant restore straightforward: pg_dump --schema=tenant_xxx from a PITR-restored copy, then re-apply to the live cluster under a quarantine schema name for verification before swap. This procedure is documented in the operations runbook; no customer-facing "restore button" exists today.

7. Evidence

Restore-test logs, monthly integrity-check logs, and annual DR-drill reports are retained ≥ 12 months per the Evidence Collection & Retention Policy.

8. Document change history

VersionDateAuthorDescription of changeApproved by
1.02026-05-26Ron Benisty (CTO & CSO)Initial version — establishes the Backup & Recovery Policy.Ron Benisty (CTO & CSO)