Official intent
Maintain resilient backup and disaster recovery so you can restore operations from an attack you could not prevent. The official source remains authoritative.
Read the official campaign ↗Ransomware assumes your backups fail. A resilient architecture keeps at least one copy offline or immutable, protects backups with separate credentials and MFA, and — most importantly — proves recovery by testing restores against defined objectives. Backups you have never restored are a hope, not a plan.
Who this applies to: Universal. The practice scales by how much you back up and how thoroughly you test, not by whether it applies.
Why it matters
Backup is the control that turns a catastrophic breach into a bad week. Attackers now target and delete backups before triggering encryption, so copies must be isolated and tamper-resistant. And a backup only counts if it restores cleanly within the time and data-loss limits the business can survive — which you only know by testing.
Risks this reduces
- Ransomware that encrypts production and the backups together
- Deletion of backup data using compromised production credentials
- Recovery that takes far longer than the business assumed
- Discovering at restore time that a critical system was never in scope
Who owns it
IT leader
System administrators, Executive sponsor, MSP
Medium
Medium
Ownership is a named person, not a department. If nobody can be named, that is the first finding.
Dependencies and prerequisites
Leans on: IT-02 — Asset inventory, IT-01 — Phishing-resistant MFA
- An inventory that identifies which systems and data are critical
- Business agreement on how long recovery may take and how much data may be lost
- Backup administration credentials that are separate from production administration
Action timeline
- Confirm critical systems and CUI are actually being backed up
- Verify at least one copy is offline or immutable
- Perform one real test restore of a critical system and time it against what the business expects
- Separate backup administration credentials from production administration and enforce MFA on them
- Separate backup credentials from production admin accounts and add MFA
- Define RTO/RPO for critical systems
- Perform and document a test restore of a critical system
- Close any gaps in backup coverage
- Run a scenario-based recovery exercise
- Set a recurring restore-test and review cadence
The 90-day target for this practice is the Measured level below: coverage and effectiveness are reported, and exceptions are handled rather than accumulated.
Step-by-step implementation
- Identify critical systems and CUI, and confirm each is covered by backup.
- Apply 3-2-1: three copies, two media, one off-site — with at least one offline or immutable.
- Protect backups with credentials separate from production, MFA, and least-privilege access.
- Define RTO (how fast) and RPO (how much data loss) for each critical system.
- Test restores on a schedule and run scenario exercises so recovery is proven, not assumed.
What good looks like
Seven levels, used identically across every practice, scorecard, and download on this site. The distinction that matters most is between having a tool, deploying it to the correct scope, and operating it consistently.
- Absent
No backups, or backups whose scope and success nobody checks.
Is there anything at all — a tool, a document, a person who owns it? - Documented
A policy names what is backed up, how often, and the recovery-time and data-loss targets.
Is the intent written down, with a named owner and a scope? - Configured
Backup jobs run for critical systems, and at least one copy is offline or immutable.
Is it switched on and set up somewhere — even if only in part of the estate? - Deployed
Coverage matches the critical-systems list, credentials are separated, and immutability is verified rather than assumed.
Does it cover everything in scope, with the exceptions written down? - Measured
Restore tests are timed against the targets, coverage and job success are reported, and gaps drive action.
Can you state a number for coverage or effectiveness, and show the trend? - Governed
An owner runs scenario recovery exercises, reviews objectives against business change, and retains the test evidence.
Is there an accountable owner, a review cadence, and retained evidence?
Validation procedures
Until these pass, the practice is configured — not deployed.
- Perform an unannounced test restore of a critical system and time it against the RTO.
- Confirm backup admin accounts are separate from production admins and require MFA.
- Verify at least one backup copy cannot be altered or deleted from the production environment.
Evidence to retain
Backup and DR policy with RTO/RPO targets
Backup job configuration and immutability/offline settings
Test-restore records with dates, durations, and outcomes
Scenario recovery-exercise report and gap remediation
Retaining these supports your own assurance and gives a reviewer something concrete to examine. It does not constitute an assessment or satisfy a contractual requirement on its own.
Operating metrics
| Metric | How it is calculated | Directional target |
|---|---|---|
| Backup coverage | Critical systems with a verified successful backup in the last cycle ÷ critical systems. | 100%. |
| Tested restore time | Elapsed time of the most recent test restore, compared with the recovery-time objective. | Within the objective; gaps documented and funded. |
| Immutable or offline copies | Critical datasets with at least one copy that production credentials cannot alter or delete. | 100%. |
Targets are directional guidance for your own programme, not compliance thresholds.
Common failure modes
Backups running but never restored, backup credentials shared with the domain admin an attacker will compromise, and every copy online and reachable — so ransomware encrypts them too. An untested backup is an assumption.
Two sized paths
Cloud backup for your critical systems with immutability enabled, a separate administrator account with MFA that is not your daily admin, and one test restore per quarter that you write down. That combination survives most ransomware scenarios and costs far less than the outage it prevents.
Exercise full-environment recovery, not single-system restores; measure against per-system recovery objectives; verify immutability with an actual deletion attempt from a production identity; and treat missed objectives as an investment case rather than an accepted risk.
Tool categories
Categories, not recommendations. This site ranks no vendors and accepts no paid placement.
New systems must be added to backup scope as part of build, and retired systems removed deliberately with a retention decision. Test restores into an isolated environment so a recovery exercise never overwrites production.
Framework mappings
Independent mappings are aids to your own analysis — not authoritative equivalence, not coverage, and not a compliance determination. Read the caveat on every row before using it.
Why: The CMMC practice inherits the 800-171 requirement text directly.
What this does not claim: Supports the requirement; it does not satisfy it on its own and does not establish an assessment outcome. Scope, implementation quality, and evidence decide that.
Why: The CSF covers backup creation and the execution of recovery plans as distinct outcomes.
What this does not claim: The CSF describes outcomes, not testable controls.
Why: The CIS data-recovery control covers the process, protection of backup data, and testing recovery.
What this does not claim: CIS is a voluntary benchmark. Alignment with it carries no contractual weight.
Method: Read against the primary source text, then classified by relationship type and confidence. No automated mapping tool was used. How mappings are made →
NIST SP 800-171 relationships have their own requirement-level section below, with links into the full mapping experience.
Related NIST SP 800-171 requirements
Requirement-level relationships from the site’s independent 800-171 mapping. Each one names what it does and does not claim — a practice supports implementation of a requirement; it never satisfies one by itself. Expand a row for the rationale and caveat.
NIST SP 800-171 Rev. 2
3.6.1Incident-handling capabilityPartial implementation supportModerate
Why: Recovery is one of the six activities this requirement names, and tested restore capability — immutable copies, timed test restores, separated backup administration — is what makes that phase real rather than aspirational when an incident reaches it.
What this does not claim: May partially address the recovery phase only. Preparation, detection, analysis, containment, and user response — the other five activities the requirement names — are untouched by backup architecture and need their own capability, plan, and people. A tested restore inside an incident that nobody could detect or contain is not an incident-handling capability.
Review status: Pending NIST SME review.
Open the 3.6.1 page →3.8.9Backup CUI confidentialityDirect implementation supportHigh
Why: Protecting the confidentiality of backup CUI at storage locations is this requirement, and the practice's architecture — encrypted backup sets, backup administration separated from production credentials, restricted read and export access — is how that protection is built in practice.
What this does not claim: The requirement's text is confidentiality at storage locations, not recovery: the availability, immutability, and tested-restore work that motivates the practice serves resilience, and only its encryption and access-limitation elements bear on this requirement. Every storage location counts — cloud and offsite copies included — and each needs the same protection and its own evidence.
Review status: Technical review complete.
Open the 3.8.9 page →NIST SP 800-171 Rev. 3
03.06.01Incident HandlingContextual relationshipModerate
Why: Recovery is one of the incident-handling phases this requirement names, and a tested backup and disaster recovery architecture is what makes that phase real rather than aspirational when the incident is destructive.
What this does not claim: One phase is not the capability: preparation, detection and analysis, containment, and eradication are untouched by backup architecture, and restoring from backup before eradication completes simply re-runs the incident. The practice informs how the recovery phase executes; the handling capability itself is separate work.
Review status: Pending NIST SME review.
Open the 03.06.01 page →03.08.09System Backup — Cryptographic ProtectionDirect implementation supportHigh
Why: Protecting the confidentiality of backup information — with cryptographic mechanisms against unauthorized disclosure of CUI at backup storage locations — is what a resilient backup architecture configures as a matter of course: encrypted repositories, restricted access, separated administration.
What this does not claim: The requirement is specifically about confidentiality at backup storage locations; availability, immutability, and tested recovery are the practice's campaign intent, not this requirement's text. Encryption must also be verifiably configured with sound key handling at every storage location — cloud targets and legacy tape included — for the relationship to hold under assessment.
Review status: Technical review complete.
Open the 03.08.09 page →Review status
| Technical review | Reviewed |
|---|---|
| Editorial review | Reviewed |
| Reviewed by | inDirectIT practitioner review — CUI security and NIST SP 800-171 engineering |
| Last reviewed | |
| Official source verified | |
| Content version | 1.0 |