CMMC Level 2 Practice 3.13.16: Protect the confidentiality of CUI at rest

CMMC Level 2 Practice 3.13.16 requires you to protect the confidentiality of CUI while it is stored (“at rest”) across every place it can land: endpoints, servers, virtual machines, databases, removable media, backups, and cloud storage. Operationally, you implement strong encryption (or an approved alternative), control key management, and retain proof that encryption is consistently enforced for all CUI storage locations. ¹

Key takeaways:

• Scope “CUI at rest” by mapping every storage location, including backups, exports, caches, and removable media. ²
• Make encryption enforceable, not optional: policy + technical controls + monitored compliance state. ²
• Keep assessor-ready evidence: system boundary, CUI data flow, encryption configurations, key management procedures, and recurring compliance checks. ³

“Protect the confidentiality of CUI at rest” sounds like “turn on disk encryption,” but assessments fail on scope and proof, not on intent. This practice is mapped to NIST SP 800-171 Rev. 2 control 3.13.16 and is evaluated in the context of your CMMC Level 2 environment: the people, processes, and technology that store or can store CUI. ¹

For a CCO or GRC lead, the fastest path is to treat 3.13.16 as an execution package: (1) identify every CUI storage location, (2) enforce encryption (or a documented alternative) across that inventory, (3) define and test key management and recovery, and (4) keep evidence that shows the control is operating continuously. The recurring failure mode is “we have encryption in some places” with no boundary clarity, no backup coverage, and no artifacts that an assessor can verify. ⁴

This page gives requirement-level implementation guidance you can assign to IT/security owners and then verify through evidence, so you can operationalize cmmc level 2 practice 3.13.16: protect the confidentiality of cui at rest requirement quickly and defend it during assessment. ⁴

Regulatory text

Excerpt (mapped requirement): “CMMC Level 2 practice mapped to NIST SP 800-171 Rev. 2 requirement 3.13.16 (Protect the confidentiality of CUI at rest).” ¹

Operator meaning: You must prevent unauthorized disclosure of CUI that is stored on any media or storage service in your CMMC Level 2 scope. In practice, that usually means encrypting CUI at rest with centrally managed keys and restricting who can access decrypted data through access control and key handling procedures. Your assessment outcome depends on whether the assessor can trace CUI to storage locations and verify that protections are consistently applied. ⁴

Plain-English interpretation (what “confidentiality of CUI at rest” means)

• “CUI”: Controlled Unclassified Information you process, store, or transmit for DoD contracts, within your defined assessment scope/boundary. ⁵
• “At rest”: Stored on disk, SSD, database tables, file shares, object storage, SaaS repositories, VM images, backups, snapshots, logs, exports, caches, and removable media.
• “Protect confidentiality”: An unauthorized person who obtains the storage media (or a copy of it) should not be able to read CUI without authorized access and decryption ability, and your organization should be able to show that protection is enforced and maintained. ²

Who it applies to (entity + operational context)

This applies to:

• Defense contractors and federal contractors handling CUI that are seeking or maintaining CMMC Level 2 for in-scope contracts. ⁶
• In-scope systems and services where CUI can be stored, including third-party hosted environments if they are part of your CUI boundary (for example: cloud IaaS/PaaS, managed service providers, backup providers). Your obligation does not stop at “our IT vendor handles it”; you must ensure the control is met and evidenced for the in-scope environment. ⁴

Practical scoping rule: if a user can download, sync, cache, email-save, or print-to-file CUI onto a device or service, that device or service is a CUI-at-rest location unless you technically block it.

What you actually need to do (step-by-step)

Step 1: Define the CUI storage inventory (your “at rest” map)

Create and maintain an inventory that answers: Where can CUI exist at rest? Include:

• Endpoints (laptops/desktops used by engineering, program management, contracts)
• Servers/VMs (application servers, file servers)
• Network storage (NAS/SAN/file shares)
• Databases and data lakes
• Collaboration and ticketing repositories in-scope for CUI
• Backup systems (on-prem and cloud), snapshots, archives, disaster recovery replicas
• Removable media and external drives
• Build artifacts, exports, and reporting outputs

Artifact: “CUI Storage Locations Register” linked to your system boundary and data flow diagrams. ⁴

Step 2: Decide your protection method per storage type (encryption is the default)

For each storage location, document the mechanism that provides confidentiality at rest, typically:

• Full disk encryption for endpoints and servers
• Volume/storage encryption for file shares and VM disks
• Database encryption (at rest) where applicable
• Object storage encryption for cloud repositories
• Backup encryption (including backup media and backup catalogs if they contain CUI)

If you have a location where encryption cannot be implemented, document a compensating approach and be prepared to defend how it protects confidentiality and how you prove it operates. Keep this exception list tight and time-bound. ⁴

Artifact: “3.13.16 Encryption Coverage Matrix” mapping each CUI storage location to: encryption method, enforcement point, key owner, and monitoring evidence.

Step 3: Implement enforceable technical controls (not user preference)

Typical enforceable patterns:

• Endpoint encryption enforced via device management with compliance reporting.
• Server/storage encryption enforced through baseline configurations and infrastructure-as-code where possible.
• Cloud storage encryption enforced using tenant/org policies and configuration rules, plus continuous posture monitoring.
• Removable media control: either block, restrict to encrypted media, or implement strong handling procedures with auditable checks.

Evidence to plan for: screenshots/exports of encryption policy settings, compliance status reports, and configuration baselines. ⁴

Step 4: Establish key management that an assessor can follow

Your encryption story is incomplete without key management. Document:

• Where keys are stored (key vault, HSM, OS key store)
• Who can administer keys and under what approvals
• Key rotation and recovery procedures
• How you prevent key exposure in logs, scripts, and tickets
• How you handle offboarding for admins with key access

If keys are controlled by a cloud provider or third party, document shared responsibility and your administrative controls over key policy and access. ⁴

Artifact: “Key Management Standard (CUI systems)” and “Key Access Review Records.”

Step 5: Operationalize: monitor, test, and collect recurring evidence

Build an operating rhythm that produces artifacts without heroics:

• Periodic checks that encryption is enabled on in-scope endpoints/servers
• Alerts for encryption disabled, noncompliant devices, unencrypted storage creation
• Backup restore tests that confirm encryption does not break recovery while keeping confidentiality intact
• Exception review workflow for any system that cannot meet the baseline

Daydream fit: teams often centralize this as a mapped control with scheduled evidence capture (configuration exports, reports, screenshots, tickets) so 3.13.16 stays continuously “assessment-ready” instead of rebuilt during the audit window. ³

Required evidence and artifacts to retain (assessor-ready)

Keep evidence that proves both design and operation:

Control design artifacts

• CUI boundary definition and in-scope system inventory ⁷
• CUI data flow diagram showing storage points ²
• Encryption standard/policy that explicitly covers CUI at rest ²
• Key management standard/procedure ²
• Exception register with approvals and remediation plan ⁷

Operating effectiveness artifacts (examples)

• Endpoint encryption compliance report exports
• Server/VM disk encryption settings and proofs (config snapshots, CMDB links)
• Cloud storage encryption policy exports and compliance findings
• Backup encryption configuration + a sample encrypted backup job detail
• Access reviews for key administrators and storage admins
• Tickets showing remediation of noncompliant encryption findings

Common exam/audit questions and hangups

Assessors tend to probe these points (prepare answers with artifacts):

1. “Show me where CUI is stored.” If you cannot enumerate storage locations, you cannot prove coverage. ²
2. “Is encryption enforced or optional?” A policy statement without enforcement and monitoring is fragile. ⁷
3. “Are backups encrypted?” Many teams encrypt endpoints but miss backup repositories and snapshots.
4. “Who can decrypt?” Expect scrutiny of key admin access, break-glass accounts, and offboarding.
5. “How do you know encryption stayed on?” Point to recurring compliance reports and alerting, not a one-time screenshot. ⁷

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails	Fix
Treating “disk encryption enabled” as the whole control	CUI may exist in backups, cloud storage, exports, or unmanaged endpoints	Build the CUI storage register and coverage matrix; validate each storage class
Relying on manual user steps	Users forget; assessors look for enforceability	Enforce via MDM/GPO/baselines/org policies and monitor compliance state
No key management documentation	Encryption without key control is hard to defend	Write a key management standard; restrict admin access; keep access reviews
Exceptions with no end date	Becomes permanent “temporary” noncompliance	Use an exception register with owner, rationale, and closure criteria
Evidence scramble right before assessment	Gaps appear under sampling	Schedule recurring evidence capture; store artifacts centrally (Daydream-style control mapping) 7

Risk implications (why operators treat this as “medium” but urgent)

CUI at rest is a high-frequency exposure point because theft/loss, misconfiguration, and overbroad access often start with stored data: laptops, shared drives, backups, or cloud buckets. If an incident occurs and stored CUI was unprotected, you face contractual impact and potential loss of eligibility for in-scope work due to failed CMMC assessment outcomes. Tie this practice directly to your risk register as a confidentiality control for CUI-bearing assets. ⁵

Practical 30/60/90-day execution plan

First 30 days (stabilize scope + stop obvious gaps)

• Confirm CUI boundary and build the CUI Storage Locations Register.
• Identify the “top risk” storage locations (endpoints, file shares, backups, primary cloud storage) and validate current encryption state.
• Publish an encryption-at-rest standard for CUI systems and an exception workflow.
• Start collecting baseline evidence (current policy exports, sample device reports). ⁴

By 60 days (enforce + document key management)

• Enforce endpoint and server encryption through centralized configuration controls.
• Implement cloud policy guardrails for encryption at rest where applicable.
• Document key management procedures and restrict key admin roles.
• Stand up recurring compliance reporting and a remediation ticket workflow for noncompliance. ⁴

By 90 days (prove operation + assessor-ready package)

• Run a sampling exercise: pick systems from each storage class and compile evidence the way an assessor will request it.
• Validate backup encryption end-to-end (config + restore test evidence).
• Review exceptions; close or reduce scope; document compensating controls where unavoidable.
• Operationalize recurring evidence capture and map artifacts to 3.13.16 in a single control record (commonly where Daydream reduces last-minute work). ³

Frequently Asked Questions

Does 3.13.16 require encryption everywhere CUI is stored?

The requirement is to protect confidentiality of CUI at rest ². Encryption is the typical method; if you claim an alternative, document how it protects confidentiality and keep strong evidence that it operates. ⁷

Are backups and snapshots in scope for “CUI at rest”?

Yes, if backups/snapshots can contain CUI, they are CUI at rest locations that must be covered by your protection approach. Treat backup repositories, archives, and DR replicas as first-class items in your CUI storage register. ²

What if a third party hosts the system that stores our CUI?

You still need to show the control is met for the in-scope environment and retain evidence that encryption at rest and key/access controls are enforced. Document shared responsibility and collect configuration and attestation artifacts that align to your control narrative. ⁵

How do assessors test 3.13.16 in practice?

Expect sampling across endpoints, servers, cloud storage, and backups, plus a request for your CUI data flow and encryption coverage mapping. They typically ask for proof of enforcement and ongoing monitoring, not a one-time configuration screenshot. ³

Is full disk encryption enough for endpoints that process CUI?

It can be, if CUI is only stored on the encrypted disk and you can prove encryption is enforced and monitored for all in-scope devices. If CUI can be copied to unencrypted removable media or synced to uncontrolled locations, you need additional controls. ²

What evidence should a GRC team ask IT for each month or quarter?

Ask for encryption compliance reports for in-scope endpoints/servers, cloud encryption policy compliance outputs, backup encryption configuration evidence, and a list of exceptions with remediation status. Store it with a mapped control narrative so the evidence stays attributable to 3.13.16. ³

Footnotes

1. NIST SP 800-171 Rev. 2; DoD CMMC Program Guidance; 32 CFR Part 170

2. NIST SP 800-171 Rev. 2

3. DoD CMMC Program Guidance; NIST SP 800-171 Rev. 2

4. NIST SP 800-171 Rev. 2; DoD CMMC Program Guidance

5. DoD CMMC Program Guidance; 32 CFR Part 170

6. 32 CFR Part 170; DoD CMMC Program Guidance

7. DoD CMMC Program Guidance