CMMC Level 2 Practice 3.8.2: Limit access to CUI on system media to authorized users

To meet CMMC Level 2 Practice 3.8.2, you must ensure that only explicitly authorized users can access CUI stored on system media, including removable drives, backup media, and local disks. Operationalize it by identifying where CUI resides on media, enforcing role-based and need-to-know access controls, and retaining repeatable evidence that the controls work in day-to-day operations. ¹

Key takeaways:

• Limit who can read/copy/export CUI from any media type (endpoint disks, removable media, backups), not just shared drives. ²
• Assessors look for implemented technical controls plus proof of operation, not policy statements. ³
• Your fastest path is a tight “CUI-on-media” map, enforced access rules, and recurring evidence capture tied to tickets and logs. ²

“System media” is where teams quietly fail CMMC assessments because it includes the messy reality: laptops with cached files, external drives used for transfers, backup repositories, VM snapshots, and imaging media. CMMC Level 2 Practice 3.8.2 requires you to prevent access to CUI on that media by anyone who is not authorized. ¹

For a Compliance Officer, CCO, or GRC lead, the work is less about drafting new policy language and more about building a control that can survive scrutiny: you need a clear authorization model (who can access what CUI and why), a technical enforcement mechanism (permissions, encryption access controls, removable media restrictions), and evidence that proves the mechanism is continuously operating. ²

This page gives requirement-level implementation guidance you can hand to IT and security owners. It focuses on what assessors typically test: where CUI is stored, how access is granted and removed, whether removable media is controlled, and whether backups and images are protected with the same rigor as production systems. ³

Requirement name (target keyword)

cmmc level 2 practice 3.8.2: limit access to cui on system media to authorized users requirement

Regulatory text

Regulatory excerpt: “CMMC Level 2 practice mapped to NIST SP 800-171 Rev. 2 requirement 3.8.2 (Limit access to CUI on system media to authorized users).” ⁴

Operator interpretation: You must (1) identify system media that contains CUI and (2) implement access controls so only authorized users can access CUI on that media. “Authorized” needs to be explicit (role/need-to-know), enforced technically where feasible, and supported by evidence that access is reviewed and revoked when no longer needed. ²

Plain-English interpretation (what this means day to day)

If a person is not approved to handle specific CUI, they should not be able to retrieve it from:

• endpoint storage (local disk, synced folders, cached email attachments)
• removable media (USB drives, external SSDs, CDs/DVDs if used)
• backup media and backup repositories (including cloud backup vaults)
• system images, snapshots, forensic images, and exported VM disks

This is fundamentally an access governance + technical enforcement + evidence requirement. Policies help, but they do not satisfy 3.8.2 by themselves. ²

Who it applies to

Entities: Defense contractors and federal contractors handling CUI that are pursuing or maintaining CMMC Level 2 alignment. ⁵

Operational context: Any in-scope environment (the CUI boundary) where CUI is processed, stored, or transmitted, including corporate endpoints used for CUI work, shared storage, and backup/DR systems supporting the CUI boundary. ³

Roles you will need involved:

• System owners / IT operations (endpoints, servers, backups)
• Security engineering (access control, encryption, logging)
• HR or identity team (joiner/mover/leaver feeds)
• Program/project leadership (need-to-know validation)
• GRC/compliance (control design, evidence, assessment readiness)

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

Step 1: Define “system media” in your environment

Create a scoped inventory list focused on where CUI can land:

• endpoints: laptops/desktops for in-scope users
• shared drives and collaboration storage inside the boundary
• removable media: organization-issued encrypted drives, if allowed
• backup systems: backup servers, backup admin consoles, storage vaults
• gold images and VM templates used for in-scope systems

Deliverable: a CUI Media Register (table) with columns: media type, owner, location/system, contains CUI (Y/N), how access is controlled, evidence source. ²

Step 2: Establish an authorization model for CUI-on-media access

You need a simple, enforceable rule set:

• Which roles are permitted to access CUI on endpoints and shared storage?
• Who is permitted to access backup copies containing CUI?
• Who is permitted to handle removable media with CUI?

Practical approach:

• Map authorization to roles (engineering, QA, contracts) plus need-to-know (project/program). Keep it small enough to administer.
• Document the approval workflow for granting access (ticket-based approvals or access request system).
• Define separation for privileged roles: backup admins can often access everything by default; you must constrain and monitor that access because backups contain CUI. ²

Deliverable: Access Control Standard for CUI on Media (one to two pages) that references your RBAC groups and approval steps.

Step 3: Implement technical controls that enforce the model

Implement controls in priority order based on where CUI most commonly lands.

A. Endpoints (local disks)

• Enforce full-disk encryption for in-scope endpoints and manage keys centrally so access requires authenticated logon and authorized group membership.
• Restrict local admin rights; local admins can bypass many file-level controls.
• Control local storage locations (approved folders) and prevent uncontrolled syncing to personal accounts.

B. File and collaboration storage

• Use group-based permissions (least privilege) for CUI repositories.
• Prohibit “everyone”/broad groups; eliminate inherited access that grants accidental visibility.
• Enable auditing for access to sensitive folders and review logs on an operational cadence.

C. Removable media

• Decide: prohibited by default, or allowed only as organization-issued encrypted devices.
• If allowed, require encryption and access control (device control policies plus encryption key management).
• Maintain issuance/return records and ensure media is sanitized or destroyed when retired. ²

D. Backups, images, snapshots

• Restrict access to backup consoles and backup repositories to a small set of authorized administrators.
• Use separate admin accounts for backup administration; do not use daily user accounts.
• Ensure backup data is encrypted and that decryption/restore rights are restricted and logged.
• Treat “restore” as access to CUI; require approvals for restores involving CUI datasets.

Deliverable: configuration baselines and change records that show these controls were implemented.

Step 4: Make access decisions reviewable and repeatable

Assessors will test whether access is controlled over time, not only at one moment.

Minimum operational loop:

• Access requests require documented approval.
• Provisioning is tied to identity (unique users, groups).
• Deprovisioning is triggered by role change or termination.
• Periodic access reviews for CUI repositories and backup administrator groups.

Deliverable: Access review outputs (exported group membership, reviewer sign-off, remediation tickets). ²

Step 5: Build recurring evidence capture (assessment-ready)

A common failure mode is “we do this” with no artifacts. Map 3.8.2 to a control statement and attach recurring evidence capture. This aligns with the recommended best practice to document control operation and collect recurring evidence. ⁶

If you use Daydream, treat 3.8.2 as a requirement record with:

• the control narrative,
• owner assignments,
• evidence tasks (monthly/quarterly),
• and an evidence library aligned to your assessment scope.

Required evidence and artifacts to retain

Keep artifacts that prove both design (what you intended) and operation (what happened).

Design evidence

• CUI Media Register (inventory of media that can contain CUI)
• Access Control Standard for CUI on Media (authorization model)
• Backup/restore SOP that includes authorization checks for CUI restores
• Removable media policy and exception process (if any) ²

Operating evidence

• Permission exports for key CUI repositories (before/after cleanup, current state)
• Group membership lists for CUI access groups and backup admin groups
• Access request tickets showing approvals and provisioning actions
• Sample log excerpts showing access auditing enabled and reviewed
• Backup platform role assignments and audit logs of restore events ²

Assessment packaging tip Create an “Assessor Binder” folder for 3.8.2 with a short readme: scope, systems, control summary, and links to evidence.

Common exam/audit questions and hangups

Assessors and internal auditors often push on these points:

1. “Show me where CUI exists on media.” If you can’t name repositories, endpoints, and backups, you can’t prove access limitation. ²
2. “Who can restore backups containing CUI?” Backup admins frequently have broad rights; you need explicit authorization boundaries. ²
3. “How do you prevent CUI from being copied to USB?” If removable media is allowed, show device controls, encryption, and issuance records. ²
4. “Prove it’s operating.” Expect requests for recent tickets, group exports, and audit logs that align to your narrative. ³

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails	Better approach
Treating “system media” as only servers	CUI often sits on endpoints and backups	Inventory endpoints, removable media, and backup repositories in the CUI Media Register 2
Relying on policy with no technical enforcement	Policy does not block access	Use permissions, encryption access controls, and device control settings; retain configuration evidence 2
Ignoring backup admin access	Backup consoles can expose CUI broadly	Restrict backup roles, require approvals for restores, log and review restore activity 2
No recurring evidence	You can’t show ongoing compliance	Schedule periodic exports/reviews and store artifacts in a controlled evidence repository 3

Enforcement context and risk implications (practical)

No public enforcement cases were provided for this specific practice in the source catalog, so don’t build your program around assumed penalties or headlines.

The operational risk is straightforward: unauthorized access to CUI on portable or secondary copies (removable media, backups, images) is hard to detect after the fact and can expand incident scope, customer notifications, and contractual consequences. Tie 3.8.2 to incident response readiness by ensuring you can answer, quickly, “who had access to the CUI copy on that media?” ²

Practical 30/60/90-day execution plan

First 30 days (stabilize scope and stop obvious gaps)

• Build the CUI Media Register for in-scope systems and storage.
• Identify your highest-risk media paths: removable media usage, unmanaged local storage, and backup admin access.
• Implement quick wins: remove broad permissions on known CUI shares; restrict backup console access to named admins; require ticket-based approvals for new CUI repository access. ²

Days 31–60 (enforce consistently, document decisions)

• Formalize RBAC groups for CUI repositories and backup roles; map them to job functions and programs.
• Implement removable media controls (block by default or allow only encrypted organization-issued devices).
• Turn on logging/auditing for key repositories and backup restore actions; define who reviews and where evidence is stored. ²

Days 61–90 (make it assessment-ready)

• Run an access review of all CUI repositories and backup administrator groups; track remediation to closure.
• Test restores and confirm only authorized admins can perform restores and only through approved workflows.
• Package evidence: one control narrative, one system/media inventory, and a small set of repeatable artifacts that demonstrate operation. Use Daydream to map 3.8.2 to the control operation and schedule recurring evidence capture so your next assessment does not become a document scramble. ⁶

Frequently Asked Questions

Does “system media” include cloud storage and SaaS?

If the storage is part of the system boundary where CUI is stored (including backups or synced folders), treat it as system media for control purposes and restrict access to authorized users. Align your interpretation to the CUI boundary used for CMMC Level 2. ⁶

Are backups containing CUI in scope for 3.8.2?

Yes in practice, because backups are system media that can store CUI and can be used to retrieve it. Limit who can access backup repositories and who can perform restores, and retain logs and role assignments as evidence. ²

If we encrypt drives, is that enough to satisfy 3.8.2?

Encryption helps, but assessors will still expect authorization controls over who can decrypt/access the CUI and proof those controls operate. Pair encryption with RBAC, restricted admin rights, and documented approvals. ²

Can we allow USB drives for CUI transfers?

You can, but you need a controlled approach: organization-issued encrypted media, device control policies, issuance tracking, and defined sanitization or destruction at retirement. If you cannot enforce those controls, block removable media within the CUI boundary. ²

What evidence is most persuasive to a CMMC assessor for 3.8.2?

A media inventory tied to the CUI boundary, permission/group membership exports for CUI repositories, backup admin role assignments, and recent access request tickets with approvals. Evidence that repeats over time carries more weight than a one-time screenshot. ⁶

How do we handle third parties (MSPs, consultants) who administer systems with CUI on media?

Treat third-party personnel as users who require explicit authorization, least-privilege access, and auditable admin actions. Ensure their accounts are uniquely identifiable and removed promptly when access is no longer required. ²

Footnotes

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

2. NIST SP 800-171 Rev. 2

3. DoD CMMC Program Guidance

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

5. 32 CFR Part 170; DoD CMMC Program Guidance

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