Control Packs · REL-004 · v1.0.0
Data Durability and Tested Restore
Decide how much data loss and downtime is acceptable, then show that a restore has actually been performed rather than assumed from the existence of a backup.
Status: review · Review: not independent. This is design guidance; review status does not establish independent verification or compliance.
What this safeguard addresses
Ensure the acceptable data loss and restore time are stated, that every store the system depends on is covered, and that a restore has been performed and dated rather than assumed.
- There is a backup, and nobody has ever restored from itDurability is assumed from a backup job existing. Nothing states acceptable data loss, acceptable restore time, whether every store is covered, or whether a restore has ever been performed.
Matching rule
{
"any": [
{
"characteristic": "SENSITIVE_DATA",
"equals": true
},
{
"characteristic": "PRODUCTION_MODIFICATION",
"equals": true
}
]
}Decisions you need to make
Leave a decision open when its value is unknown. Confirm a suggested value only if it matches your intended design.
- How much data loss, in hours, is acceptable if you have to restore?This single number decides backup frequency, storage cost, and design. Guessing it for you would set your recovery expectations without asking.REL-004-Q1 · threshold
Requirements for the coding agent
- REL-004-R1Cover every store the system depends on at a frequency consistent with the confirmed acceptable data loss, keep copies outside the failure domain of the primary, and perform and date a restore that demonstrates the data returns usable — recording the elapsed time.
Tests and evidence to keep
- RESTORE_REHEARSAL_TESTRestore each covered store into an isolated environment from a copy taken through the normal path, confirm the data is usable and within the confirmed acceptable loss, and record the elapsed time.
- configuration_or_policy
- implementation_location
- test_result
- operational_procedure
Passing a published example shows that example's behavior. A coding agent's implementation report remains a claim until its evidence is independently checked.
Related guidance
- CP-9 · System BackupNIST_SP_800_53_5_2_0 · partially addressesCovering every store at a confirmed frequency addresses backup for this system; it does not cover the full contingency-planning family.
- CP-10 · System Recovery and ReconstitutionNIST_SP_800_53_5_2_0 · partially addressesA performed and dated restore addresses recovery for the stores tested; it does not establish organization-wide recovery capability.
These references cover related topics. They do not mean this pack satisfies a framework, certifies your project, or has government endorsement.
- Amazon Web Services Builders' Library — Timeouts, retries, and backoff with jitterGUIDANCE_RELIABILITY
- National Institute of Standards and Technology — Security and Privacy Controls for Information Systems and OrganizationsGUIDANCE_AUDITABILITY
- National Institute of Standards and Technology — Security and Privacy Controls for Information Systems and OrganizationsGUIDANCE_NIST_SP_800_53_5_2_0