Procedure 20 TECHNICAL
Backup & Business Continuity Policy — how Revique implements this rule today, and how an auditor verifies it.
Policy 20 · PCI DSS Req 12.10 (contingency) · 2 of 6 policy statements fully met · AWS facts collected read-only 2026-08-13
← All 21 procedures
📘← Back to Policy 20 — Backup & Business Continuity PolicyThe rule this procedure implements
How Revique implements this today
The production Aurora PostgreSQL cluster in us-e****-1 — the native platform's system of record — is protected by automated backups with a 14-day retention window, is Multi-AZ, and has deletion protection enabled, so it survives both an availability-zone failure and an accidental drop. Separately, the legacy production estate in us-e****-2 is covered by an AWS Backup plan that snapshots EC2 resources daily at 08:00 UTC into a dedicated backup vault, retained for 3 days; the five most recent backup jobs all completed successfully, the latest on 2026-08-12. All backups inherit the encryption of their source, and access to the vault is IAM-controlled.
The rule against the current state
Each row takes a statement from Policy 20 and states what is actually configured. Meets = implemented as written. Partial = implemented, but not everywhere or not to the full standard. Gap = not implemented. N/A = not verifiable from infrastructure configuration.
| The rule | Current state | Verdict |
|---|
| Backups of critical data performed on a defined schedule | Aurora: continuous with 14-day PITR. Legacy EC2: daily at 08:00 UTC via AWS Backup, jobs completing successfully. | Meets |
| Backups encrypted and access-controlled | Aurora backups inherit the cluster's encryption; the AWS Backup vault is IAM-controlled. The legacy MySQL instance that is unencrypted (Procedure 09) produces unencrypted backups. | Partial |
| Recovery objectives (RTO/RPO) defined for critical systems | Multi-AZ and 14-day PITR imply an RPO of minutes for the native platform, but no RTO/RPO is documented. | Gap |
| A documented DR / business continuity plan is maintained | No plan document is evidenced. | Gap |
| Backup restoration tested and results documented | No restore test evidence exists. | Gap |
| Resilience of the critical data tier | Production Aurora cluster: Multi-AZ enabled, deletion protection enabled, one reader instance alongside the writer. | Meets |
🔍 Auditor verification — where to log in and what you will see
Aurora backups and resilienceConsole → RDS → production account, us-e****-1 → the Aurora PostgreSQL cluster → Maintenance & backups shows Automated backups: Enabled, 14 days; the Configuration tab shows Multi-AZ and Deletion protection: Enabled.
The AWS Backup planConsole → AWS Backup → production account, us-e****-2 → Backup plans → the primary plan → its rule runs cron(0 8 ? * * *) into the backup vault with a 3-day lifecycle, and the resource selection covers the EC2 resources.
Backups are actually runningAWS Backup → Jobs → Backup jobs — consecutive daily entries with state COMPLETED, most recently 2026-08-12.
Where backup coverage stopsAWS Backup → the dev (292****) and UAT (559****) accounts, and production us-e****-1 — no backup plans and no vaults.
The DR plan and restore testsAsk for the business continuity plan, the defined RTO/RPO, and the dated results of the last restore test. Not stored in AWS.
Team process
DevOps owns backup configuration and monitors job success; the Security Officer owns the continuity plan and is responsible for scheduling and documenting restore tests. A restore is performed by point-in-time recovery on the Aurora cluster or by restoring from the backup vault for the legacy estate.
⚠️ Where reality does not meet the policy
- No documented disaster recovery / business continuity plan and no defined RTO or RPO. The technical capability to recover is good; the plan that would tell someone how and how fast does not exist.
- Backup restoration has never been demonstrably tested. The policy requires periodic restore tests with documented results; an untested backup is an assumption, not a control.
- The legacy backup retention is 3 days, and the production legacy MySQL instances retain only 1 day of automated backups — far short of the 14 days the native platform holds, and thin for any incident not noticed within 24 hours.
- No backup coverage outside production. The dev and UAT accounts have no AWS Backup plans or vaults at all.
- No cross-region backup copy is configured, so a region-level event would take the backups with the workload for the legacy estate.
- The legacy production MySQL instances are not Multi-AZ and have deletion protection disabled.
Evidence location. Backup configuration and job history are in AWS. The BC/DR plan, RTO/RPO definitions and restore-test results are documents held by the Security Officer.
📘Back to the PolicyPolicy 20 — Backup & Business Continuity Policy (PCI DSS Req 12.10 (contingency))←