The 3-2-1 backup rule — three copies of data, on two different media types, with one offsite — was developed for on-premise infrastructure in the pre-cloud era. It remains a useful resilience principle, and it is insufficient for regulated environments. HIPAA has specific backup testing requirements. SOX requires immutable backup media with documented chain of custody. FedRAMP requires documented Recovery Time Objectives and Recovery Point Objectives with evidence of testing. A backup architecture that satisfies all of these requirements is built differently from one that satisfies only the 3-2-1 rule.
HIPAA Backup Requirements
The HIPAA Security Rule's Contingency Plan standard (§164.308(a)(7)) includes five required implementation specifications: data backup plan, disaster recovery plan, emergency mode operation plan, testing and revision procedures, and applications and data criticality analysis. The testing and revision procedures specification requires that the contingency plan be tested. An untested backup is not a HIPAA-compliant backup. The testing requirement is frequently overlooked because it creates work: actually restoring data from backup, verifying the restore is complete and consistent, and documenting the test outcome. The documentation is the evidence — without a test record, the backup might as well not exist from a compliance perspective.
The applications and data criticality analysis specification requires that the organisation identify which ePHI applications and data are critical to patient care and business operations and ensure those systems can be recovered within defined timeframes. This is effectively the HIPAA equivalent of defining RTO/RPO — the backup architecture must be designed to meet the documented values, and the testing programme must verify that it does.
Object-level immutability (S3 Object Lock, Azure Blob immutability policies, GCP Object Hold) is the cloud-native mechanism for satisfying SOX's requirement for immutable backup media. Once a backup object is written with an immutability lock, it cannot be modified or deleted before the lock expiry — even by account administrators. For SOX compliance, the lock period should match the applicable document retention requirement (typically seven years for financial records). The WORM (Write Once Read Many) compliance posture is equivalent to the tamper-resistant physical media requirements in traditional SOX implementation guidance.
FedRAMP Backup and Recovery Requirements
The NIST SP 800-53 CP (Contingency Planning) control family includes CP-9 (Information System Backup) and CP-10 (Information System Recovery and Reconstitution). CP-9 requires backup of user-level information, system-level information, and system documentation. For FedRAMP Moderate, full backups must be performed at defined frequencies and backup integrity must be verified. CP-10 requires reconstitution within defined timeframes — the RTO must be documented in the Contingency Plan and tested. FedRAMP's continuous monitoring requirements additionally require that backup testing results be reported to the Authorising Official as part of the annual security review.
The Restore Testing Cadence
Restore testing should occur at three levels: component-level testing (restore individual files or database records to verify backup integrity — this should run automatically as part of the backup process), system-level testing (restore an entire service or application from backup in a test environment and verify functionality — quarterly), and scenario-level testing (simulate a realistic failure scenario and execute the full recovery procedure — annually). Each test must produce a documented record: what was tested, the duration of the restore operation (relevant to RTO verification), the result of functional verification, and any gaps identified. Store test records in a location separate from the backup infrastructure being tested.
- Run automated restore verification as part of every backup job — verify the restore is complete and consistent, not just that the backup process completed without errors
- Implement object-level immutability locks for SOX-covered financial data backups — the cloud-native equivalent of WORM media
- Document RTO and RPO values in the Contingency Plan before the backup architecture is designed — design to meet the documented values
- Conduct quarterly system-level restore tests and document the results — the documentation is the compliance evidence
- Store backup test records in a separate location from the backup infrastructure being tested
- Include backup and recovery evidence in the FedRAMP continuous monitoring deliverables — the AO needs to see testing evidence, not just backup configuration documentation
The engineering behind this article is available as a service.
We have done this work — not advised on it, not reviewed documentation about it. If the problem in this article is your problem, the first call is with a senior engineer who has solved it.