Backup and Recovery Architectures for CMMC Environments

CMMC Level 2 expects you to protect backup CUI and prove that you can restore systems. The model points to NIST SP 800-171 and NIST SP 800-53 for substance, and the assessment guides spell out the evidence assessors examine. Backup and recovery design becomes part of your CUI boundary, not a bolt-on at the edge.

Regulatory and CMMC requirements

The CMMC Model defines practice MP.L2-3.8.9. It directs you to protect the confidentiality of backup CUI at storage locations. DoD cites NIST SP 800-171 requirement 3.8.9 and the derivation from NIST SP 800-53 CP-9 System Backup in the model overview. NIST SP 800-171 Revision 3 retains the mapping of 03.08.09 to CP-09 and calls out CP-09(01) for testing reliability and integrity, and CP-09(08) for cryptographic protection. Those references anchor the expectation that you back up in line with recovery objectives, protect backups with cryptography that meets federal standards, and test restores.

The CMMC Level 2 Assessment Guide sets the inspection lens. Assessors examine procedures for system backup, system configuration settings, backup storage locations, and system backup logs. They also look for encryption of CUI backups on media before removal from secured facilities and the use of FIPS-validated cryptographic mechanisms. That list tells you where to collect evidence and what to harden.

Scoping decisions pull backup systems into the boundary. The CMMC Level 2 Scoping Guide includes backup media and backup repositories that store CUI or security-relevant information in the in-scope asset set. That guidance covers cloud repositories and physical media alike. Teams that treat backups as out-of-band risk gaps during assessment and during incidents.

Backup architecture that protects CUI

Start by drawing the data boundary with precision. Name the workloads that hold CUI and the backup repositories that store copies of that data. That diagram belongs in your SSP. If you need a refresher on boundary definition, see our post on CMMC scoping and the CUI boundary.

Build confidentiality protection into every storage location. Use FIPS-validated cryptographic modules to protect CUI at rest in backup repositories and in transit across networks. Apply the same standard to removable media and to backup traffic that crosses network segments or leaves a facility. The Assessment Guide calls for encryption of CUI backups before media leaves secured space, so plan the workflow and record the control points.

Control who can touch backup data. Assign a small set of operators, require MFA, and separate backup administration from production administration. Use dedicated credentials for backup systems. Backups often expose a broad blast radius, so treat operator authentication and authorization as high-risk paths.

Place storage with clear intent. On-premises arrays with offsite media storage give you direct control inside your boundary. Cloud object storage in a government region gives you scale and geographic spread. Both patterns can meet CMMC expectations when you protect CUI with FIPS-validated cryptography and when you align service configurations to your boundary.

Prove integrity with routine verification and restores. CP-09(01) points to testing for reliability and integrity. Run test restores on a schedule and on change events, and keep evidence. Operators who rely on checkmarks in a console invite surprises during an outage.

Recovery objectives and testing

Set recovery objectives that your business can fund and your systems can meet. Define RTO and RPO in your contingency and impact analyses, then size backup frequency, retention, and recovery tooling to match. NIST SP 800-53 CP-9 and CP-10 drive that linkage between objectives, backup cadence, and the ability to reconstitute to a known state.

Test what you plan to rely on. File-level restores exercise media handling, keys, and operator procedures. Full system recovery to a known state exercises configuration management, infrastructure capacity, and the sequence you need to bring up dependent services. Record the results and track defects to closure. Assessors read those records to judge reliability and integrity.

Tune backup frequency to your defined RPO and risk exposure. A design that backs up too infrequently sets you up for excess data loss. A design that backs up too often without capacity planning can overload systems and fail silently. Tie schedule, retention, and media handling to your business impact analysis.

Design for ransomware pressure. Immutable storage and isolation measures reduce the chance that an attacker can alter or delete backups during an incident. Many platforms support write-once policies and time-bound retention controls. Treat those controls as part of your integrity plan, and test the recovery path that reads from those stores.

Keep procedures clear and measurable. Name backup jobs, storage locations, key management steps, and restore sequences. Keep logs that show success and failure, and keep operator runbooks under change control. The Assessment Guide references procedures, locations, and logs as assessment touchpoints, so maintain a trail that shows how your team runs the plan.

Scoping backup infrastructure

Include backup infrastructure in scope wherever it stores CUI or security-relevant information. The Scoping Guide names backup media and repositories in that set, so do not leave out staging caches, temporary export locations, or snapshot stores that hold CUI. That includes tape libraries, disk-based targets, cloud buckets, and export shares used during migration.

Address third-party services with the same rigor. If a service ingests CUI from your environment for backup or replication, treat that service as in scope. Validate FIPS-validated cryptography, contractual terms, and incident cooperation. DFARS 252.204-7012 requirements for incident reporting and media preservation intersect with backup and recovery decisions, so align contracts and workflows. Our DFARS overview covers the reporting and preservation context in more detail: DFARS 252.204-7012 requirements.

Pull management planes and identity into scope discussions. Backup administration consoles, backup APIs, and the identities that control them present high-risk surfaces. Place those identities under the same conditional access and MFA standards you use for privileged roles. Keep audit logs for those planes with retention that meets your investigation needs.

Document scope choices and the rationale in the SSP. Name in-scope repositories, tools, and services, and explain exclusion decisions. Tie each to MP.L2-3.8.9 and to the relevant NIST mappings for CP-09 and CP-10. Reference your test evidence and recovery results. If you track remediation, align tasks and timelines within your POA&M process. Our post on System Security Plans offers a structure that fits this material.

Microsoft 365 considerations

Many DIB tenants hold CUI in Exchange Online, SharePoint, OneDrive, and Teams. Backups that touch that data sit inside the CUI boundary. You decide how to cover recovery for those workloads with in-scope controls and storage locations.

Treat Microsoft guidance as informational, not as authorization. The Microsoft Product Placemat for CMMC 2.0 appears as a Preview mapping that links practices to Microsoft products. Microsoft states that this document does not serve as authorization or a guarantee. Use it for orientation, then confirm service capabilities and compliance statements with Microsoft public documentation and the Service Trust Portal. Align design decisions with your boundary and with MP.L2-3.8.9.

Two patterns appear in M365 backup designs that handle CUI.

Use native retention, holds, and versioning to remediate user error and short‑term corruption, while treating this as a complement to your recovery plan, not the whole plan.
Use a separate backup system that captures M365 content into an in-scope repository with FIPS-validated cryptographic protection and access controls aligned to your privileged access standards.

Place backup repositories where your CUI is authorized. GCC High tenants often select storage and services in the same sovereign boundary to keep data residency and support expectations aligned. Validate cryptographic modules and key management practices for any backup integration that leaves Microsoft 365.

Test mailbox, site, and chat restores on a written cadence. Record evidence that shows item recovery, permission preservation, and time to restore against your RTO. Track defects, and fold fixes into configuration baselines. Assessors read both the plan and the proof.

Map identity and admin controls from your tenant to backup tools. Privileged identities over M365 generate the data, and privileged identities over backup tools preserve the copy. Use the same conditional access, MFA, and Just‑In‑Time patterns for backup operators that you use for tenant admins. Keep admin audit logs with retention that supports investigations tied to 7012 reporting timelines.

Practical evidence to collect

You can speed assessment work and reduce rework by staging a focused set of artifacts.

System backup and recovery procedures that tie to RTO and RPO and name FIPS-validated modules in use.
Backup job logs, restore test records, and media handling records for removable media leaving secured facilities.

Store these artifacts with change control and assign owners. Match each artifact to MP.L2-3.8.9 in your control matrix and to the CP-09 or CP-10 mapping in NIST SP 800-171 Rev. 3. That map helps assessors track practice implementation without guesswork.