Backup, Recovery, and Business Continuity: What CMMC Auditors Expect
Consider a scenario we see versions of regularly. A manufacturer runs nightly backups. There’s a written procedure. The IT manager is confident that if something went wrong, critical systems could be restored.
Then the team is asked to prove it. They attempt a test restore of their ERP system and discover it takes most of a working day, far longer than anyone assumed. A second problem surfaces along the way: Nobody had written down which systems should come back first, or who was authorized to make that call.
Nothing had failed. The backups were fine. But “We have backups,” and “We can prove we can recover,” turned out to be two very different statements.
This scenario is an illustrative composite of common patterns, not a specific client engagement.
The Backup Was There. The Recovery Plan Wasn’t
These three terms get used interchangeably, but they describe different things:
- Backup is a copy of your data.
- Recovery is the tested ability to restore systems and data from that copy within an acceptable timeframe.
- Business continuity is how the organization keeps operating while recovery happens.
An organization can do the first perfectly and still be unprepared for the other two. Recovery readiness depends on questions a backup schedule doesn’t answer:
- What data matters most?
- How quickly does each critical system need to return?
- Are backups accessible if the primary network is compromised?
- Has restoration actually been tested?
- Who owns recovery decisions?
- What happens if the primary method fails?
What CMMC and NIST Expect Organizations To Demonstrate
It helps to be precise here, because CMMC business continuity requirements are narrower than many assume.
CMMC Level 2 draws on NIST SP 800-171, and NIST explicitly states that the contingency planning, system and services acquisition, and planning requirements are not included within the scope of that publication.
In other words, there’s no standalone CMMC requirement for a formal business continuity or disaster recovery plan.
What NIST SP 800-171 does require touches backup and recovery directly:
- Protecting Backups (3.8.9): Organizations must protect the confidentiality of backup CUI at storage locations. The requirement doesn’t say an organization must have a backup; it says wherever CUI ends up once it’s backed up, that copy has to be protected the same way the original is.
- Recovery as Part of Incident Handling (3.6.1): Organizations must establish an operational incident-handling capability that includes preparation, detection, analysis, containment, recovery, and user response activities.
- Testing the Capability (3.6.3): The incident response capability must be tested, not just documented.
So recovery enters CMMC through incident response. An assessor evaluating your incident-handling capability will reasonably ask how you’d restore affected systems, and whether you’ve shown that works.
Beyond those requirements, continuity planning remains sound practice. Just be clear internally about which parts are CMMC obligations and which are operational resilience.
Where Backup and Recovery Programs Commonly Fall Short
Backup and recovery gaps tend to appear between what the policy says and what the evidence shows:
The Policy Says: Critical data is backed up regularly.
The Evidence Shows: Backups exist, but restoration hasn’t been tested recently, or ever.
The Policy Says: Systems can be restored following an incident.
The Evidence Shows: No documented recovery sequence and no assigned recovery responsibilities.
The Policy Says: Backup data is protected.
The Evidence Shows: Backup copies containing CUI sit on a storage location that was never evaluated against the CUI boundary.
None of these mean the organization is failing. They mean the process works in principle but hasn’t been validated in practice, which is precisely the gap assessments and real incidents expose.
What Evidence Should Your Team Be Ready To Show?
Evidence requirements depend on your scope and environment, so there’s no universal checklist. That said, teams are generally well placed when they can produce:
Documented procedures
for backup and recovery
Defined roles and responsibilities,
including who authorizes recovery decisions
Backup configurations
showing what’s backed up, how often, and where it’s stored
Protection measures
for backup CUI, such as encryption and access controls
Recovery procedures,
including restoration sequence
Restoration test records
with dates and results
Lessons learned
and resulting procedure updates
Incident response test records
showing recovery was exercised
Remember, a policy proves intent, while test records prove the process works.
A Practical Backup and Recovery Readiness Checklist
Use this as a starting point, not a substitute for a formal assessment:
Are our most critical systems and data clearly identified?
Are backups performed according to documented procedures?
Are backup copies protected against unauthorized access and ransomware?
Have we actually tested restoration?
Are restoration results documented?
Do we know how quickly critical systems need to be restored?
Does everyone know who owns recovery decisions?
Have we documented what happens if the primary recovery method fails?
Have we updated procedures based on previous tests or incidents?
Can we produce evidence showing these processes are followed?
Recovery Doesn’t Happen in Isolation
Recovery is one phase of a larger sequence:
Incident Detected → Contain → Investigate → Restore → Validate → Resume Operations
Restoring too early is a common and costly mistake. Bring systems back before the threat is contained and understood, and you risk restoring the attacker’s foothold along with your data.
Recovery has to be coordinated with investigation, which is exactly why NIST places it inside incident handling rather than treating it separately.
DataSure24’s Incident Response as a Service helps organizations build that coordination in advance, with structured response planning, tabletop exercises that include recovery
scenarios, and a retained team ready to support containment, investigation, and restoration when an incident occurs.
When Professional Support Can Help
Outside expertise is often most useful when you need to review existing recovery processes objectively, identify documentation gaps before an assessment, run a realistic tabletop exercise, or turn a list of findings into a prioritized improvement plan.
DataSure24’s Professional Services provide that support on a project basis, helping teams evaluate their current environment and strengthen the processes that need it.
Turn Recovery Planning Into a Repeatable Process
Backups protect the data. Recovery planning prepares the organization to restore it. Incident response coordinates everything around the incident. All three need to be documented, tested, and repeatable.
Is your recovery plan ready for an audit, or an incident? Schedule a time to talk with our team at datasure24.com.