MP-8(3): Controlled Unclassified Information

The mp-8(3): controlled unclassified information requirement shows up at the exact moment teams are under pressure: shipping laptops to employees, donating retired hardware, returning leased copiers, sharing datasets externally, or publishing materials to a public site. MP-8(3) is a narrow control enhancement, but it creates a broad operational obligation because “system media” includes more than hard drives. Any storage medium that can retain CUI becomes in-scope when you plan public release.

A CCO or GRC lead’s job here is to convert a one-line requirement into a release-ready operating procedure that people follow when time is tight. You need clear ownership, a decision tree for what counts as “public release,” approved downgrade/sanitization methods by media type, verification steps, and a clean evidence trail. If you already run a media protection program, MP-8(3) becomes a specific “CUI downgrade before release” gate that plugs into asset disposition, ITAD, records management, and communications/publication workflows. ¹

Regulatory text

Requirement (MP-8(3)): “Downgrade system media containing controlled unclassified information prior to public release.” ²

Operator meaning: before any media is released outside your control in a way that makes it publicly accessible (or effectively uncontrolled), you must ensure that CUI is no longer present on that media. “Downgrade” is the key verb: you are changing the information state of the media from “contains CUI” to “does not contain CUI,” and you must be able to prove it. ²

Plain-English interpretation (what MP-8(3) expects)

MP-8(3) expects a controlled process that:

1. Identifies whether the media contains CUI (or could contain it).
2. Prevents release until the media is downgraded (sanitized, re-imaged, destroyed, or otherwise rendered free of CUI).
3. Verifies the downgrade action worked for that media type.
4. Records the decision and the evidence so an assessor can reconstruct what happened. ²

If you cannot confidently remove CUI from the media, the compliant path is to avoid public release and route the asset to controlled destruction or controlled handling instead.

Who it applies to

Entity scope

• Federal information systems implementing NIST SP 800-53 controls. ¹
• Contractor systems handling federal data, where NIST SP 800-53 controls are flowed down via contract, ATO boundary requirements, or program security requirements. ¹

Operational scope (where this bites in practice)

• IT asset disposition (ITAD): decommissioned endpoints, servers, storage arrays, removable media.
• Third-party returns: leased printers/copiers, lab equipment with internal storage, managed service provider equipment returns.
• Public-facing release workflows: publishing datasets, logs, or exports to public repositories or websites when the “media” is a file package intended for unrestricted distribution.
• Internal “free hardware” programs: giveaways to staff or charity donations.

Media types to explicitly list in your procedure

• HDD/SSD/NVMe, USB drives, SD cards, external drives
• Mobile devices and tablets
• Printers/copiers/MFPs with internal storage
• Backup media (tape, disk-based backups), portable backup devices
• Virtual disk images, snapshots, exported VM images (treat as media for this control’s intent)

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

Use this as a requirement-level runbook that your teams can execute under change control.

1) Assign control ownership and define the release gate

• Control owner: usually IT Operations / Infrastructure (technical sanitization) with GRC oversight (evidence, policy).
• Release authority: define who can approve “public release” after downgrade (e.g., IT asset manager plus Information Security).
• Trigger events: asset retirement, contract end/lease return, donation, transfer to surplus, publication of datasets.
  Best practice: map MP-8(3) to a named owner, written procedure, and recurring evidence artifacts so it stays audit-ready. ²

2) Define what “public release” means in your environment

Write it in one paragraph and include examples. Treat these as public release:

• Disposal/donation outside controlled channels
• Return to a third party where you cannot guarantee custody controls
• Posting data packages to a public site/repo
• Sale or auction of used equipment

If an item stays within controlled custody (for example, transfer to another internal system owner within the same authorization boundary), document that it is not public release and reference the alternative handling process.

3) Build a CUI identification decision tree for media

Your teams need a fast “does this contain CUI?” test:

• System association: was the device used on systems that store/process CUI?
• Data paths: did it receive exports, print jobs, scan-to-email, backups, or local caches?
• User behavior: did users copy files locally, sync folders, or store downloads?

If you cannot answer confidently, treat it as potential CUI and require downgrade before release.

4) Define approved downgrade methods by media type

MP-8(3) does not prescribe a single technique in the excerpt provided. Your procedure should still specify methods you approve, by media type, such as:

• Cryptographic erase (if full-disk encryption with controlled keys is proven and keys are destroyed)
• Sanitization/wipe with verification
• Re-image to a known-clean baseline plus validation that no user data remains
• Physical destruction if sanitization cannot be assured (common for failed drives)

Keep it practical: your goal is a method that reliably results in “no CUI remains” and can be evidenced.

5) Verify and document the downgrade action

Verification is where many programs fail in audits. Require at least:

• Operator attestation (who performed, when, method used)
• Tool output/logs or service provider certificate (if ITAD vendor performed destruction)
• Spot checks appropriate to the media type (e.g., confirm device boots to baseline image, confirm storage shows as unallocated after wipe, confirm encryption keys are destroyed and unrecoverable per your key management process)

6) Approve release and retain a complete release packet

Create a “Media Public Release Packet” record containing:

• Asset identifier (serial, hostname, asset tag)
• Media type and capacity (if available from inventory)
• CUI determination (contains / potentially contains / does not contain)
• Downgrade method and date
• Verification evidence
• Approver name/title/date
• Final disposition (donated, sold, recycled, returned, published)

7) Extend the control to third parties (ITAD and managed services)

If a third party performs sanitization or destruction:

• Contractually require downgrade/sanitization before public release or downstream resale.
• Require certificates of destruction/sanitization and chain-of-custody records.
• Include audit rights or at least evidence delivery SLAs.

This is a classic third-party risk management (TPRM) gap: your policy may be fine, but your ITAD provider’s process becomes your control in practice.

Required evidence and artifacts to retain

Assessors typically expect artifacts that prove both design (you planned the control) and operation (you executed it repeatedly). Keep:

• Media sanitization and public release procedure (with roles, triggers, methods)
• Asset inventory tags tied to disposition events
• Completed Media Public Release Packets (samples across time and media types)
• Sanitization tool logs/screenshots or centralized job logs
• ITAD or destruction certificates and chain-of-custody records
• Exceptions log (assets that could not be sanitized and were destroyed instead)
• Training or job aids for technicians performing downgrade steps

Daydream can help by mapping MP-8(3) to a control owner, a written implementation procedure, and a recurring evidence checklist so your team collects the same artifacts every cycle. ²

Common exam/audit questions and hangups

Expect these questions and prepare clean, reproducible answers:

• “Define public release.” Auditors want to see your definition and that staff follow it.
• “Show me three examples.” Provide three release packets with evidence attached.
• “How do you know CUI was removed?” Tool logs, verification steps, approvals.
• “What about copiers, scanners, and printers?” Many teams forget embedded storage.
• “What happens when a drive fails and cannot be wiped?” Your procedure should route to destruction, with evidence.

Frequent implementation mistakes (and how to avoid them)

1. Treating ‘asset disposal’ as a ticket without evidence. Fix: require a release packet with mandatory fields and attachments before closure.
2. Assuming encryption alone is enough without key control proof. Fix: tie crypto-erase claims to key destruction records and system configuration evidence.
3. Forgetting non-obvious media. Fix: maintain an in-scope media list and add it to procurement/asset intake.
4. Letting ITAD vendors “handle it” without verification. Fix: require certificates, chain of custody, and periodic sampling reviews.
5. No exception path. Fix: define “sanitize or destroy” decision logic with approvals.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so you should treat MP-8(3) primarily as an assessment and incident-risk control: failure typically shows up as (a) audit findings for missing process/evidence, or (b) a data spill when retired media is later found to contain CUI. ¹

Risk outcomes to brief to leadership:

• Uncontrolled release of federal CUI can trigger contractual noncompliance, incident response obligations, and loss of trust with the sponsoring agency.
• The failure mode is usually operational, not technical: assets leave before approvals because the release gate is informal.

Practical 30/60/90-day execution plan

First 30 days (stabilize and stop accidental release)

• Stand up a public release gate: no media disposition without InfoSec/asset manager approval.
• Publish a one-page CUI-on-media decision tree for IT and records teams.
• Identify your highest-risk release channels: ITAD shipments, copier lease returns, donations.
• Create the Media Public Release Packet template and require it for every disposition event.

Days 31–60 (standardize methods and third-party controls)

• Define approved downgrade methods by media type and embed them into IT runbooks.
• Centralize evidence: ticketing attachments, log collection location, naming standards.
• Update ITAD and managed service contracts/SOWs to require sanitization/downgrade before downstream release, plus evidence delivery.
• Run an internal tabletop: “We’re donating 50 laptops,” walk through the exact steps and evidence.

Days 61–90 (prove repeatability and audit readiness)

• Perform a sampling review of recent release packets; fix missing artifacts.
• Add MP-8(3) checks to procurement and asset lifecycle workflows (intake, transfer, retirement).
• Train technicians and asset coordinators using real examples of acceptable evidence.
• Operationalize reporting: a monthly list of dispositions with pass/fail on required evidence fields.

Frequently Asked Questions

Does MP-8(3) apply if we transfer equipment internally to another team?

If the equipment stays within controlled custody and within the same governed environment, many teams treat it as not “public release.” Document your definition of public release and keep transfer records so an assessor can see why MP-8(3) was not triggered. ¹

What counts as “system media” for MP-8(3)?

Treat any storage medium that can retain data as in-scope, including drives, removable media, mobile devices, and embedded storage in printers/copiers. Your procedure should list in-scope media types so technicians do not guess.

Is wiping enough, or do we need physical destruction?

MP-8(3) requires that media containing CUI is downgraded prior to public release, but the excerpt does not mandate a specific technique. Use wipe/re-image/crypto-erase where you can verify results, and use destruction when you cannot reliably sanitize or the media is defective. ²

How do we handle an ITAD provider that resells our equipment?

Require sanitization or destruction before resale, require certificates and chain-of-custody records, and verify evidence delivery before you approve shipments. Treat ITAD as a third party performing part of your control.

What evidence should we show an auditor for a single retired laptop?

Provide the asset record, the CUI determination, the sanitization method and logs (or destruction certificate), verification steps, and the approval for public release. Bundle it as a single release packet so the story is easy to follow.

How does Daydream help with MP-8(3) operationalization?

Daydream can map MP-8(3) to a specific owner, a written procedure, and a recurring evidence checklist, then track whether each disposition event has the required artifacts attached. That reduces scramble during assessments and makes gaps visible early. ²

Footnotes

1. NIST SP 800-53 Rev. 5

2. NIST SP 800-53 Rev. 5 OSCAL JSON