03.08.07: Media Use

03.08.07: media use requirement sits in the practical danger zone for CUI programs: teams can have strong access controls and still lose control of data the moment it lands on a removable drive or gets copied to unmanaged media. Media controls are also one of the fastest ways an assessor tests whether “policy” matches reality, because evidence is tangible: device control settings, encryption requirements, and logs of who connected what.

For a CCO, GRC lead, or Compliance Officer supporting NIST SP 800-171, your job is to turn this into a small set of enforceable decisions: which media types are allowed, which roles can use them, under what conditions (encryption, labeling, time-bound need), and how you detect and respond to violations. Then you need to prove it operates, not just that it’s written down.

This page gives requirement-level implementation guidance you can put into a control narrative, a system security plan, and an evidence collection routine. It also flags the audit hangups that delay assessments: unclear scope, unmanaged endpoints, and “exceptions” that become the default. ¹

Regulatory text

Requirement: “NIST SP 800-171 Rev. 3 requirement 03.08.07 (Media Use).” ¹

Operator interpretation: You must establish and enforce rules for using media in environments that handle CUI. In practice, this means: (1) decide what removable/portable media is permitted, (2) restrict use to authorized users and approved purposes, (3) require protective safeguards (commonly encryption and logging), and (4) keep evidence that those rules are implemented and operating. ¹

Plain-English interpretation (what the requirement expects)

03.08.07: media use requirement expects you to prevent “side door” data movement through media. If CUI can be copied to a USB drive, burned to a disc, written to an external SSD, or transferred via other portable media without guardrails, you have a control gap.

A workable interpretation for operators:

• Default deny: media use is blocked unless explicitly allowed for a defined business need.
• Least privilege: only specific roles can use approved media, and only in approved ways (for example, read-only vs. read/write).
• Safeguards: CUI written to approved media is protected (commonly via encryption) and traceable (logging).
• Exception discipline: temporary approvals exist, expire, and generate evidence.

This is not a paperwork exercise. Assessors will look for alignment between policy, endpoint controls, and logs. ¹

Who it applies to (entity and operational context)

Applies to:

• Federal contractors and subcontractors processing, storing, or transmitting CUI in nonfederal systems. ¹
• Nonfederal organizations handling CUI on behalf of the government (including cloud, managed service, engineering environments, and shared service centers). ¹

Operationally, scope this to:

• Endpoints: laptops, desktops, VDI endpoints, engineering workstations.
• Servers and jump hosts where removable media is physically possible.
• Printers/MFPs and kiosks if they accept or produce storage media.
• Third parties: IT support providers or contract staff who have physical access to endpoints or facilities where CUI is present.

If you cannot clearly list where CUI lives and how users interact with it, media use controls will be inconsistent. Tie scope to your CUI data flow and asset inventory.

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

Step 1: Define your “media use” policy decisions

Document these decisions in a media handling/acceptable use standard:

1. Define media types in scope: USB mass storage, external HDD/SSD, SD cards, optical media, mobile devices in “storage mode,” portable encrypted drives.
2. Allowed vs. prohibited: decide what is blocked outright (common: personal USB drives) vs. allowed (company-issued encrypted drives).
3. Allowed actions by role and system boundary:
   • Read-only access for most users
   • Read/write only for approved roles
   • No CUI export except via approved workflow
4. Safeguards required when CUI touches media:
   • Encryption requirement for writable removable media
   • Labeling/marking requirement where feasible
   • Storage and transport requirements (locked storage, chain-of-custody if applicable)
5. Exception process: who can approve, what justification is required, expiration rules, and required post-use attestation.

Deliverable: a short standard that can be tested in technical settings and HR/IT processes.

Step 2: Implement technical enforcement on endpoints

Pick controls that match your endpoint stack (Windows/macOS/Linux/VDI). Typical enforcement layers:

• Device control (block/allow by device class, serial number, or approved model list).
• Encryption enforcement for removable storage (only allow writes to encrypted media).
• DLP rules where practical to detect CUI patterns copied to removable devices.
• Logging of device insertions, mount events, file copy events (as supported), and policy blocks.

Minimum expectation for audit readiness: you can show a configuration that blocks unapproved media and you can show logs proving it’s working.

Step 3: Build an approved media issuance and inventory workflow

Create an “approved removable media” workflow:

• Request ticket (business need + data classification = CUI).
• Issue company-managed encrypted device.
• Record serial number, custodian, purpose, issue date, return date (or status).
• Require return or periodic re-authorization.
• Revoke access if user changes role or leaves.

This is where many programs fail: they allow “approved USB drives” but cannot prove which ones exist or who has them.

Step 4: Train the behaviors that cause violations

Training does not need to be long; it must be specific:

• “Do not copy CUI to personal media.”
• “Use approved encrypted media only.”
• “If you need an exception, request it before copying.”
• “Report lost media immediately.”

Tie training content to your policy decisions and to real tools users will see (device block pop-ups, request forms).

Step 5: Monitor, respond, and keep evidence on a cadence

Operationalize:

• Review device control/DLP alerts.
• Investigate policy blocks that indicate users attempted CUI export.
• Treat lost removable media as an incident with defined response steps.
• Run periodic reconciliations: issued media list vs. active users; stale exceptions; devices not returned.

If you use Daydream, map 03.08.07 to the specific policy section, the endpoint configuration objects, and a recurring evidence task that pulls logs/config exports on a set cadence aligned to your assessment cycle. That mapping is what keeps media controls from drifting after IT changes.

Required evidence and artifacts to retain

Keep evidence in a format an assessor can re-perform:

• Media use policy/standard with version history and approval.
• System scope statement: which systems handle CUI and are subject to device control.
• Device control configuration exports (MDM/endpoint management screenshots or config profiles).
• Encryption policy evidence for removable media (configuration + proof it applies).
• Approved media inventory: issued devices, serial numbers, custodians, status.
• Exception tickets/approvals with expiry and justification.
• Logs: removable media events, policy blocks, and investigation notes for any flagged events.
• Training record showing targeted media handling content for CUI roles.

Artifact quality test: a third party can look at the evidence and understand what is blocked, what is allowed, and how you would detect misuse.

Common exam/audit questions and hangups

Expect these questions:

• “Show me how you prevent copying CUI to removable media on a typical endpoint.”
• “Which users can write to removable storage, and why?”
• “Do you maintain an inventory of approved removable media devices?”
• “How do you enforce encryption on removable media?”
• “Show alerts/logs for removable media activity and your review process.”
• “How do exceptions work, and can you show one closed example?”

Common hangups:

• Policy says “encrypted only,” but IT cannot show the enforcement configuration.
• Exceptions exist but never expire.
• Inventory is a spreadsheet with no linkage to issuance/return workflow.
• BYOD endpoints touch CUI without device control coverage.

Frequent implementation mistakes (and how to avoid them)

1. Relying on “policy only.” Fix: tie every rule to a control you can demonstrate (device control, encryption, logging).
2. Allowing personal media “temporarily.” Fix: make the default deny, and issue company-managed encrypted devices for approved use cases.
3. No system boundary clarity. Fix: explicitly list in-scope CUI endpoints; block removable media on out-of-scope machines from receiving CUI.
4. Logging without review. Fix: define who reviews alerts, what constitutes an incident, and where investigation notes live.
5. “Everyone is an admin” operationally. Fix: restrict who can override device control policies and require ticketed approvals.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so do not build your program around assumed penalty narratives.

Risk implications you can defend operationally:

• Media misuse creates data spillage risk (CUI copied outside controlled environments).
• Lost or stolen media creates confidentiality and reporting risk.
• Weak evidence creates assessment failure risk even if teams “usually do the right thing.” ¹

Practical execution plan (30/60/90)

First 30 days (stabilize decisions and scope)

• Confirm where CUI exists and which endpoints/users are in scope.
• Publish media use standard: allowed media, allowed roles, safeguards, exception path.
• Configure baseline device control: block unknown removable storage on in-scope endpoints.
• Stand up exception ticket type and approval routing.

By 60 days (enforce + inventory + evidence)

• Implement encryption enforcement for approved writable media.
• Launch issuance workflow and inventory tracking for approved devices.
• Turn on logging and route alerts to a monitored queue.
• Run a tabletop for “lost encrypted drive” and “attempted copy to blocked USB” scenarios.

By 90 days (operate and prove)

• Perform an internal mini-assessment: sample endpoints, verify controls, pull logs.
• Close gaps: unmanaged endpoints, legacy machines, lab environments.
• Implement a recurring evidence package: policy version, config exports, inventory snapshot, and sample logs with review notes.
• If using Daydream, automate control-to-evidence mapping for 03.08.07 so you can generate an assessment-ready packet without last-minute scrambling. ¹

Frequently Asked Questions

Does 03.08.07 require banning all USB devices?

No. A practical approach is default-deny for unapproved removable storage, with a controlled path for approved encrypted devices tied to specific roles and business needs. ¹

What counts as “media” under the 03.08.07: media use requirement?

Treat portable storage that can carry CUI as “media,” including USB drives, external HDD/SSD, SD cards, and optical media. Document your in-scope media types so enforcement and evidence match. ¹

How do we handle third parties (MSPs, field technicians) who need removable media?

Require the same controls: company-managed encrypted media, ticketed approvals, and logs. If a third party cannot meet the rules, treat the activity as prohibited and provide an alternate transfer method within your controlled environment. ¹

What evidence is most persuasive to an assessor?

Configuration proof (device control + encryption enforcement), an inventory of issued approved devices, and logs showing real activity plus your review notes. A clean exception example with an expiration date also helps. ¹

We use VDI. Do we still need media controls?

Yes, if endpoints can redirect USB storage into the VDI session or if users can export files to local devices. Disable or restrict USB redirection and keep logs that show the policy is enforced. ¹

Can we meet the requirement with DLP alone?

DLP helps detect exfiltration, but you still need defined allowed media rules and technical restrictions that prevent unapproved writing or copying. Pair detection with blocking and an exception workflow. ¹

Footnotes

1. NIST SP 800-171 Rev. 3