Federal agencies invest heavily in backup infrastructure. Most of it will not save them during a serious cyber incident. The gap between having backups and achieving actual recovery is where missions fail — and it is a gap that is both common and largely preventable.
Key Takeaways
- Backup and cyber recovery are related capabilities, but they are not the same thing. Conflating them creates measurable mission risk.
- Traditional backup is well-suited for accidental deletion, corruption, and operational restores. It was not designed to survive an adversary who has already compromised your environment.
- Ransomware and advanced persistent threats routinely target backup infrastructure first. If backups live in the same trust boundary as production, they are part of the attack surface.
- Cyber recovery requires immutable storage, logical or physical separation, clean recovery points, and validated restoration procedures — not just scheduled backup jobs.
- RTOs and RPOs documented in a contingency plan but never exercised under realistic conditions are planning assumptions, not operational commitments. Assessors and AOs increasingly expect evidence of both.
- Federal organizations should validate their recovery posture against CP-2, CP-9, CP-10, and applicable agency overlays — not just confirm that backup jobs are completing.
In This Article
Why This Matters for Federal Agencies
Federal missions do not pause for recovery windows. Whether a system supports personnel services, logistics, intelligence workflows, or financial operations, continuity of operations is a standing requirement — not a contingency plan that lives in a SharePoint folder and gets reviewed annually during assessments.
Ransomware, destructive malware, and advanced persistent threats have fundamentally changed the recovery calculus. These are not scenarios where an agency pulls last night’s backup, restores over the weekend, and resumes Monday morning. Modern attack campaigns are designed specifically to undermine recovery infrastructure — often targeting backup systems and management planes before the primary attack payload is deployed. By the time the disruption is visible, the recovery path may already be compromised.
Federal cyber resilience now requires a clear-eyed distinction between backup operations and cyber recovery operations. Agencies that treat these as synonymous are building mission continuity plans on a foundation that has not been tested against the actual threat environment. That gap surfaces during incidents and during assessments — often at the same time.
This distinction deserves deliberate attention at the ISSO, ISSM, system owner, and leadership level — not just inside the infrastructure team. ISSMs and ISSOs who cannot answer basic questions about recovery architecture, isolation, and tested RTOs are operating with incomplete situational awareness of the system’s resilience posture.
The Common Misunderstanding: Backup ≠ Cyber Recovery
The assumption is understandable. Backup has been the cornerstone of IT recovery planning for decades. Agencies have spent years building out backup schedules, retention policies, and storage infrastructure. When contingency planning conversations arise — whether during an assessment, an ATO review, or an incident response tabletop — backup is almost always the first thing pointed to.
The problem is that traditional backup was designed for a different threat model. It was built to address hardware failure, human error, file corruption, and accidental deletion — scenarios where the environment itself is trustworthy and the only problem is missing or damaged data. Those scenarios still happen. But they are not the scenarios that end missions.
Cyber incidents — particularly ransomware and adversarial intrusions — operate on entirely different assumptions. The environment is not trustworthy. The adversary may have been present for weeks or months before any disruption is visible. Backup data captured during that dwell period may contain malicious artifacts. Management plane credentials may be compromised. Backup repositories may have been encrypted, modified, or deleted. And the backup management system itself may have been the initial target.
Restoring from backup into a compromised environment does not produce recovery. It produces reinfection — often faster than the original intrusion, because the adversary’s tooling and persistence mechanisms are still in place.
The false confidence problem is operationally significant: an agency can have a fully documented backup program, green dashboards, completed job logs, and passing contingency plan reviews — and still be completely unable to recover from a serious cyber incident. The backup infrastructure was never designed for that scenario, and without cyber recovery capabilities layered on top, it will not perform as one.
What Traditional Backup Does Well
This is not an argument against backup. A well-designed backup program is a foundational control and a meaningful capability against a significant range of operational failures. The point is to be precise about what backup is actually good at — so organizations can plan accurately for what it does not cover and stop treating completeness in one area as coverage in another.
Traditional backup performs well in the following scenarios:
- Accidental deletion. A user or administrator removes data unintentionally. A clean backup restores it without complication.
- File or database corruption. A storage failure or application error corrupts data. A known-good backup provides a reliable restore point that pre-dates the corruption.
- Hardware failure. A disk array, server, or storage system fails. Backup enables recovery to replacement hardware or an alternate environment within a defined window.
- Operational rollback. An update, migration, or configuration change produces unintended results. Rolling back to a prior backup resolves it cleanly.
- Retention and records management. Backup supports data retention requirements and the ability to retrieve historical records within defined windows — a requirement that surfaces in audits, litigation holds, and records management reviews.
In each case, the common factor is a trustworthy environment. The infrastructure itself is not compromised, the backup data has not been touched by an adversary, and restoring the backup produces a known-good state. That is the operating assumption traditional backup is built on — and it is valid under those conditions. The question is what happens when those conditions no longer hold.
Where Traditional Backup Falls Short
The operating assumption that makes traditional backup effective — a trustworthy environment — is precisely what a serious cyber incident removes. The failure modes below are not theoretical. They appear consistently in post-incident analysis and in assessments of federal recovery programs that looked adequate on paper.
Ransomware targeting backup infrastructure
Ransomware operators understand that backup is the primary recovery path for most organizations. Modern campaigns routinely enumerate backup systems, delete or encrypt repositories, and disable backup agents before deploying the primary payload. An organization whose backups are accessible from the same network segment as production — or managed through the same credential store — has limited protection against this sequence. The backup system is not a safe harbor if it shares a trust boundary with the systems being attacked.
Privileged account compromise
Backup management platforms require privileged access to function. If administrative credentials are compromised — through phishing, credential stuffing, lateral movement, or pass-the-hash techniques — an adversary with access to backup management consoles can modify retention policies, delete backup jobs, or wipe repositories directly. The backup tool becomes the attack vector. This risk is compounded when backup administrators share credential stores or MFA configurations with other privileged roles in the environment.
Lateral movement and persistence during extended dwell time
Advanced intrusions frequently involve weeks or months of dwell time during which an adversary establishes persistence across multiple systems. Backup data captured during that window may contain malicious artifacts: backdoors, scheduled tasks, registry modifications, implanted credentials, or tooling that enables re-entry. Restoring from these backups does not produce a clean environment — it restores the adversary’s position alongside legitimate data. Identifying which recovery points pre-date the initial compromise is a forensic problem, not a backup operations problem.
Compromised management planes
In cloud and virtualized environments, the management plane — hypervisors, orchestration layers, cloud control planes — operates above the level that traditional backup agents protect. An adversary with management-plane access can manipulate virtual machines, alter snapshot policies, modify storage configurations, or destroy backup catalogs in ways that guest-OS backup agents cannot detect or prevent. Cloud-native backup solutions that rely on the same control plane credentials as production workloads inherit the same exposure.
Restoring into an unverified environment
Even when backup data is intact and a clean recovery point has been identified, restoring into an environment that has not been fully scoped and remediated introduces ongoing risk. The data may be clean. The environment receiving the restore may not be. This is one of the more underappreciated failure modes in federal incident response: recovery actions begin before the scope of compromise is fully understood, and the restored system reconnects to infrastructure that still contains adversary access. Speed pressure during incidents makes this mistake easy to make and difficult to reverse.
What Cyber Recovery Actually Means
Cyber recovery is a discipline that addresses the specific challenges of restoring mission operations after an adversarial incident. It extends beyond backup to include the architecture, processes, and validated procedures required to recover in a hostile or post-compromise environment — where the infrastructure itself cannot be assumed to be trustworthy and where the adversary may still have access.
A mature backup and cyber recovery program addresses the following capabilities:
Immutable recovery points
Backup data that cannot be modified, encrypted, or deleted — even by privileged accounts — provides a reliable foundation for recovery when the rest of the environment cannot be trusted. Immutability is a technical control enforced at the storage or platform level, not a policy statement. It must be documented in the SSP and verified through testing, not assumed based on vendor claims. CP-9(7) and CP-9(8) enhancements address cryptographic protection and dual authorization for backup deletion — organizations operating under higher-impact baselines should evaluate whether these enhancements are required or appropriate.
Logical or physical air gap
Recovery infrastructure that is isolated from the production environment — and from the same identity and access management trust boundary — limits an adversary’s ability to reach and compromise it. Air-gapped or logically separated recovery environments are a defining characteristic of federal cyber resilience architecture. This separation requires deliberate design decisions: separate credential stores, independent MFA configurations, distinct network paths, and periodic validation that the isolation has not eroded through configuration drift or infrastructure changes.
Verified clean recovery points
Knowing which recovery points pre-date the initial compromise is a prerequisite for safe recovery. This is a forensic determination, not a backup operations function — it requires telemetry, log analysis, and coordination between incident response and recovery teams. Recovery that begins before a clean point is identified risks restoring malicious artifacts alongside legitimate data. Organizations that lack sufficient logging and telemetry to make this determination are effectively unable to confidently identify safe recovery points under adversarial conditions.
Isolated recovery environments
Restoration should occur into a controlled environment separated from compromised infrastructure. This allows recovery teams to validate the restore, confirm application functionality, test against known-good baselines, and verify cleanliness before reconnecting systems to operational networks. Isolated recovery environments are a key component of ransomware resilience — and they require pre-planned infrastructure, not improvised staging built during an active incident.
Validated restoration procedures
Procedures that have never been exercised are assumptions, not commitments. Validated procedures are tested under conditions that approximate the actual recovery scenario — including realistic data volumes, system dependencies, and time constraints aligned to the Recovery Time Objective. CP-4 requires contingency plan testing; recovery procedure validation is a core component of meeting that control, and undocumented or informal testing does not satisfy assessor expectations.
Mission restoration sequencing
Mission continuity planning requires knowing which systems are mission-critical, in what order they must be restored, and what dependencies exist between them. Identity infrastructure, DNS, certificate services, and shared authentication dependencies must come before the systems that depend on them. A cyber recovery plan that restores application servers before the identity and network services they require will produce a partial recovery that cannot support mission operations — regardless of how well the individual restores execute.
What This Looks Like in Federal Environments
Write-Once, Tamper-Resistant Backup
Immutable backup storage enforces write-once protection at the platform or storage level, preventing modification or deletion regardless of account privilege. For federal systems, this is increasingly a baseline expectation rather than an advanced capability. Immutability must be documented in the SSP, tied to applicable contingency planning controls — including CP-9(7) and CP-9(8) where the impact level warrants — and verified through testing rather than assumed based on configuration settings alone. Backup immutability that has never been tested under simulated adversarial conditions is an untested control.
02 — Air-Gapped Recovery
Isolated Recovery Infrastructure
Air-gapped or logically separated recovery environments maintain backup data and recovery tooling in a trust boundary distinct from production. This separation ensures that a compromise of the production environment does not automatically extend to recovery infrastructure. Designing and maintaining this separation requires deliberate architecture decisions: independent credential stores, separate MFA configurations, distinct network paths, and periodic validation that the isolation has not degraded through infrastructure changes or configuration drift over time.
03 — Recovery Testing & Validation
Exercised, Documented Recovery Procedures
Recovery procedures must be exercised, not just written down. Testing should encompass realistic data volumes, system dependencies, and time constraints aligned to the organization’s RTO. Results must be formally documented and retained as contingency plan evidence in the authorization package. CP-4 requires this — untested recovery procedures are among the most consistent findings during federal assessments. Test results are operational feedback, not compliance artifacts. When a test reveals that actual recovery time exceeds the documented RTO, that is a POA&M item, not a footnote.
04 — Recovery Time Objectives (RTO)
Validated, Mission-Aligned RTOs
RTOs define how long an organization can tolerate system unavailability before mission impact becomes unacceptable. RTOs documented in a contingency plan but never validated against actual recovery capability are planning assumptions, not operational commitments — and they will not hold under real incident conditions. Federal organizations should test recovery procedures under time-constrained conditions, validate that RTOs are achievable with current infrastructure and staffing, and update the contingency plan when those objectives cannot be met. An RTO that has never been tested is a liability, not an assurance.
Common Federal Mistakes
Recommended Federal Approach
Addressing the gap between backup and cyber recovery does not require replacing existing infrastructure. It requires layering cyber recovery capabilities onto a backup foundation — and being honest about where that foundation is not sufficient on its own. The steps below are a practical framework for assessment and planning, to be validated against specific authorization context, agency requirements, and AO expectations.
Assess your current recovery posture honestly
Start by asking whether your organization can actually recover from a serious cyber incident — not whether backups are completing. Identify gaps in isolation, immutability, tested procedures, and mission-priority sequencing. This assessment should involve infrastructure, cybersecurity, and mission owners together — not be conducted by the backup team in isolation. ISSOs and ISSMs should be active participants, not recipients of a summary afterward.
Architect backup infrastructure with cyber recovery in mind
Evaluate whether backup repositories are isolated from production trust boundaries. Assess whether immutability is enforced at the storage or platform level — not just stated in policy. Determine whether management-plane access to backup systems uses separate credentials, separate MFA, and access controls distinct from production administration. These are architectural decisions that cannot be retrofitted through monitoring or configuration policy alone.
Develop and document ransomware-specific recovery procedures
Document the specific steps required to recover from ransomware: identifying clean recovery points through forensic analysis, restoring into an isolated environment, validating application and data integrity, sequencing restoration in mission-priority order, and reconnecting systems only after verification. These procedures should be owned by named roles, integrated into the contingency plan and incident response plan, exercised at least annually, and updated after every major infrastructure change.
Validate RTOs and RPOs under realistic conditions
Test recovery procedures against time constraints derived from the contingency plan’s RTOs. If systems cannot be restored within the committed window using current infrastructure, staffing, and procedures, that gap needs to be addressed — either by improving recovery capability or by updating the contingency plan to reflect actual operational reality. A contingency plan that documents an RTO that has never been tested is not a plan; it is an untested assumption that will surface at the worst possible moment.
Integrate cyber recovery into RMF documentation
Cyber recovery procedures should be reflected in the system contingency plan, the SSP, and the incident response plan. Assessors cross-reference CP-2, CP-9, CP-10, and IR controls — and they look for consistency across those documents. Organizations that treat contingency planning and incident response as documents owned by separate teams frequently have gaps at exactly the integration points where coherence matters most. ISSOs and ISSMs should be able to trace recovery capability from SSP documentation through to test evidence without reconstructing the picture from multiple disconnected sources.
Maintain continuous evidence, not point-in-time snapshots
Recovery capability is an ongoing operational state, not a compliance checkbox satisfied at authorization. Backup integrity reports, restoration test results, RTO validation records, and isolation verification evidence should be maintained continuously and available for review as part of ongoing continuous monitoring. An organization that cannot produce recent recovery evidence during an assessment is, operationally, in the same position as one that never tested at all — because in both cases, there is no demonstrated basis for confidence in the recovery posture.
Need help evaluating solutions for your environment?
Whether you’re modernizing infrastructure, improving cyber resilience, or evaluating technologies, Anchor Defense helps organizations align mission requirements with practical outcomes.