CMMC Backups: When Backup Repositories, Replicas, and Recovery Media Become In Scope

Why Backups Are Not "Just Copies"

The instinct to exclude backups from CMMC scope comes from a reasonable-sounding premise: a backup is an inert archive. Nobody works in it. Nobody reads from it. It exists only for disaster recovery. It should be outside the assessment boundary because no user interacts with it during normal operations.

That premise is wrong — and the reason it is wrong goes back to the definition of scope itself.

The DoD CIO scoping guidance reinforces this by categorizing assets into several types — CUI Assets, Security Protection Assets, Contractor Risk Managed Assets, and Specialized Assets. A backup server that holds CUI is a CUI Asset. The network switches that carry backup traffic to it may be Specialized Assets. The SIEM that logs backup events generates Security Protection Data. None of these are out of scope by default.

Contractors who exclude backup infrastructure from their SSP do not reduce their assessment boundary. They create an undocumented system that an assessor will discover — and that discovery turns a scoping question into a finding.

Backup Servers, Repositories, Immutable Storage, Offsite Copies, and Tape

Modern backup architectures are not a single server with a hard drive. They are distributed systems with multiple tiers, retention policies, and replication targets — each of which has its own scope implications.

When Encrypted Backups Still Remain in Scope

This is the most persistent misconception in backup scoping for CMMC: "Our backups are encrypted, so the data is protected, so the backup system is out of scope."

Encryption does not remove a system from scope. Encryption is a control — specifically, it satisfies parts of SC.L2-3.13.8 (transmission confidentiality) and SC.L2-3.13.16 (data at rest confidentiality). But the system that holds the encrypted data is still a system that stores CUI. The encryption protects the confidentiality of the data; it does not change the classification of the system.

There is one narrow exception: if CUI is encrypted before it reaches the backup system, using a key that the backup system and its administrators do not possess, and the backup system has no ability to decrypt the data, then the argument for excluding the repository from CUI Asset classification becomes stronger. But this architecture is rare in practice. Most backup solutions encrypt data using keys they manage — which means the backup server can decrypt the data, which means the backup server processes CUI, which means the backup server is in scope.

Restore Testing and What Assessors Care About

NIST SP 800-171 control CP.L2-3.8.9 requires organizations to protect the confidentiality of backup CUI at storage locations. But the controls do not stop at storage. Assessors also evaluate whether the organization can actually recover from a backup — and whether the recovery process itself maintains CUI protections.

This matters because a restore operation creates a new copy of CUI. The destination of that restore — the server, workstation, or cloud environment where the data is recovered to — must itself be within the assessment boundary and compliant with CUI handling requirements. Restoring CUI to a non-compliant test server for validation is, technically, a CUI spill.

What assessors actually look for in restore testing:

• Restore test logs — dated evidence that restores have been performed within a documented interval (quarterly or semiannually is typical)
• Restore destination — documentation showing where the restore was written and that the target system is within the CUI boundary, or evidence that non-CUI test data was used
• Recovery time — not formally scored under CMMC, but assessors may probe whether backup capabilities meet the organization's stated Recovery Time Objective (RTO) and Recovery Point Objective (RPO)
• Post-test cleanup — evidence that restored CUI data was purged from the test environment after validation, if the test used actual CUI

Backup Admin Accounts and Shared Responsibility

The accounts that manage backup infrastructure are among the most privileged in any environment — and among the most overlooked in CMMC scoping. A backup admin account typically has read access to every protected system, write access to the repository, and the ability to restore data to any destination. That level of access makes backup admin accounts CUI Assets subject to the full range of Access Control, Identification and Authentication, and Audit and Accountability controls.

Backup admin accounts should be subject to the same controls as any other privileged account in the CUI environment: multi-factor authentication, least-privilege access, regular access reviews, and audit logging of every action performed. Service accounts should use managed identities or dedicated credentials that are not shared with human users. If the backup solution uses a domain admin account to run its agents — and many small deployments do — that account's access footprint puts the entire domain inside the assessment boundary.

How Backup Design Affects Enclave Claims

Many contractors use an enclave architecture to limit their CMMC assessment scope — segmenting CUI into a tightly defined boundary and keeping the rest of the corporate environment out of scope. Backup architecture is where enclave claims most frequently break down.

The enclave only works if CUI stays inside the enclave. The moment a backup job copies CUI from the enclave to a backup server outside the enclave, the CUI has left the boundary — and the backup server is now in scope. If that backup server also backs up non-CUI corporate systems, those systems may themselves be drawn into the assessment boundary as Contractor Risk Managed Assets, depending on the architecture.

The cleanest enclave design includes backup as a first-class consideration — not as an afterthought. If the enclave's backup target is shared with non-enclave systems, the enclave boundary is effectively meaningless for the purposes of scope reduction. The assessor will trace the data flow from CUI source to backup destination, and if that destination is outside the enclave, the enclave claim fails.

Evidence to Retain for Backup-Related Controls

Backup infrastructure intersects with multiple NIST SP 800-171 control families. The evidence requirements are distributed — there is no single "backup control" to satisfy. An assessor will evaluate backup-related evidence across Access Control, Audit, Media Protection, System and Communications Protection, and System and Information Integrity.

The Bottom Line

Backup infrastructure is not a supporting system that sits quietly outside the assessment boundary. It is a CUI-storing, CUI-processing, CUI-transmitting system that is subject to the same 110 controls as any server, workstation, or cloud service in your environment. The backup server, the repository, the offsite replica, the tape in the vault, the admin account that manages all of it, and the MSP that runs it — all assessable.

Excluding backups from scope does not reduce the assessment boundary. It creates an undocumented system that an assessor will find — and a finding that could have been avoided by treating backup architecture as what it is: a first-class component of your compliance posture.