Independent DIB implementation resource — not affiliated with or endorsed by the U.S. Department of WarView the official DoW campaign ↗
Brilliant at the BasicsDIB Resource Center
IT-09IT SYSTEMSOFFICIAL INTENTEXPERT REVIEWED

Resilient Backup and Disaster Recovery Architecture

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.

AUTHOR inDirectIT EditorialREVIEW STATUS SME review completeUPDATED 2026-07-21SOURCE CHECKED 2026-07-19
EXPLAINER · 5 SCENES · ≈40 SEC · CAPTIONS, NO AUDIO

IT-09 in 40 seconds

The problem, the plain-words meaning, three key moves, and what “done” looks like.

Official intent

What the campaign asks for

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 ↗

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.

Minimum / Strong / Advanced

1
Minimum

Critical systems and CUI are backed up on a schedule, with at least one copy kept offline or immutable.

2
Strong

Backups follow 3-2-1, are protected by separate credentials/MFA, and restores are tested against defined RTO/RPO targets.

3
Advanced

Recovery is exercised end-to-end (including full-environment scenarios), immutability is enforced, and objectives are measured and improved.

Implementation timeline

First 24 hours
  • Confirm critical systems and CUI are actually being backed up
  • Verify at least one copy is offline or immutable
Next 30 days
  • Separate backup credentials from production admin accounts and add MFA
  • Define RTO/RPO for critical systems
Next 60 days
  • Perform and document a test restore of a critical system
  • Close any gaps in backup coverage
By day 90
  • Run a scenario-based recovery exercise
  • Set a recurring restore-test and review cadence

Implementation steps

  1. Identify critical systems and CUI, and confirm each is covered by backup.
  2. Apply 3-2-1: three copies, two media, one off-site — with at least one offline or immutable.
  3. Protect backups with credentials separate from production, MFA, and least-privilege access.
  4. Define RTO (how fast) and RPO (how much data loss) for each critical system.
  5. Test restores on a schedule and run scenario exercises so recovery is proven, not assumed.

Validation

  • 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

Governance

Backup and DR policy with RTO/RPO targets

Configuration

Backup job configuration and immutability/offline settings

Operations

Test-restore records with dates, durations, and outcomes

Validation

Scenario recovery-exercise report and gap remediation

Common failure modes

What looks done but is not

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.

Framework mappings

Independent mappings are aids, not authoritative equivalence or compliance determinations.

FrameworkRequirementRelationshipConfidence
NIST SP 800-1713.8.9DirectHigh
CMMC Level 2MP.L2-3.8.9DirectHigh
CIS Controls v8.111.1DirectHigh