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.
Versioned applicability rule
{
"any": [
{
"characteristic": "SENSITIVE_DATA",
"equals": true
},
{
"characteristic": "PRODUCTION_MODIFICATION",
"equals": true
}
]
}Decisions for the project owner
Leave a decision open when its value is unknown. Suggested values become confirmed only through an explicit user decision.
- 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 retain
- 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.
Mappings indicate contextual relevance or partial support. They do not establish equivalence, certification, government endorsement, or complete framework implementation.
- 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