MP-6(4): Controlled Unclassified Information

To meet the mp-6(4): controlled unclassified information requirement, you must ensure media sanitization and disposal practices explicitly address Controlled Unclassified Information (CUI) so CUI cannot be recovered from paper, devices, or storage media leaving your control. Operationalize it by classifying where CUI exists, applying approved sanitization methods, and keeping auditable disposal evidence tied to each asset and event. ¹

Key takeaways:

• Treat CUI media as a special handling category in your media sanitization and disposal workflow, not as “standard data.”
• Build traceability: CUI location → asset/media ID → sanitization method → approval → disposition evidence.
• Auditors look for repeatable execution and proof, not a policy statement.

MP-6 is the NIST SP 800-53 media sanitization control family; the (4) enhancement focuses your program on Controlled Unclassified Information (CUI). If your environment stores, processes, or transmits federal information subject to CUI handling rules, this requirement pushes you to prove a simple outcome: when media is reused, transferred, returned, decommissioned, or destroyed, CUI is not recoverable.

For a Compliance Officer, CCO, or GRC lead, the fastest path is to turn MP-6(4) into an operational “CUI media exit process.” That process needs named owners, defined triggers (asset retirement, laptop refresh, server decommission, copier lease return, cloud volume deletion, backup tape rotation), and pre-approved sanitization methods by media type. Your evidence must connect those steps to actual assets and actual events.

This page gives requirement-level implementation guidance you can drop into your control library, map to system owners and IT operations, and run through an internal assessment. Control text references come from NIST SP 800-53 Rev. 5. ²

Regulatory text

Requirement: “NIST SP 800-53 control MP-6.4.” ¹

Operator interpretation of what the text demands: MP-6(4) requires you to implement media sanitization controls in a way that explicitly covers Controlled Unclassified Information. Your program must prevent CUI retrieval from any media that is disposed of, released outside the system boundary, or repurposed for new use. This is not satisfied by a generic “we wipe drives” statement; you need a CUI-scoped procedure, execution records, and a way to prove consistent application across endpoints, servers, removable media, printed output, and backups. ²

Plain-English interpretation (what MP-6(4) really means)

If a device, storage medium, or printed material has ever contained CUI, you must treat its end-of-life handling as controlled work. You need to:

• Know which assets/media may contain CUI.
• Use sanitization methods appropriate to the media type and risk.
• Control and document any third party involved in destruction, return, repair, or recycling.
• Keep evidence that the sanitization happened before the asset left your custody or changed use.

The operational objective: CUI does not “walk out” in residual data on retired laptops, returned copiers, sold servers, discarded drives, or mismanaged backups.

Who it applies to (entity and operational context)

MP-6(4) is most relevant when you operate:

• Federal information systems implementing NIST SP 800-53 controls. ³
• Contractor systems handling federal data, including environments where CUI exists on endpoints, shared drives, ticket attachments, DevOps artifacts, backups, or SaaS exports. ³

Operationally, it applies to teams and workflows that touch media lifecycle:

• IT asset management (ITAM) and endpoint operations
• Infrastructure/server teams and data center ops
• Backup/restore administrators
• Records management and facilities (paper shredding bins, clean-out events)
• Procurement and third-party management (recyclers, destruction providers, copier lessors)
• Cloud operations (volume snapshots, object storage lifecycle, tenant offboarding)

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

1) Define the CUI media scope (where CUI can land)

Create a scoped inventory view that answers two questions:

• Which systems and repositories are authorized to store/process CUI?
• Which media types can store CUI as a byproduct (endpoint drives, MFD/copiers, removable media, backup media, VM images, logs, exports)?

Practical approach:

• Start from your CUI data flow and system boundary documentation, then map to asset classes in ITAM (laptops, servers, storage arrays, mobile devices, MFDs).
• Add “shadow media” you don’t own directly: contractor laptops used for CUI, third-party managed backup services, leased equipment, and RMA/repair returns.

Deliverable: a “CUI Media Scope Register” that lists asset/media categories and their handling rules.

2) Establish sanitization standards by media type

You need an approved method matrix that staff can follow without debate during offboarding or break/fix. Build a table like this:

Media type	Common example	Allowed disposition	Required sanitization evidence
Endpoint storage	Laptops/desktops	Reuse internally, recycle, return to lessor	Wipe certificate or tool log + asset tag match
Server/storage	Physical servers, SAN drives	Redeploy, destroy	Wipe/destroy record + chain-of-custody
Removable	USB, external drives	Prefer prohibition; otherwise controlled	Serial/ID tracking + destruction record
Paper	Printed CUI	Shred or secure destruction	Shredding log or secure bin pickup record
MFD/copiers	Copier hard drives	Return to lessor, decommission	Proof of drive wipe/destruction before return
Backups	Tapes, offline media	Rotation, destruction	Inventory + destruction certificate + retention approval

The control expectation is consistency: same media type, same approved process, same proof pattern. ¹

3) Add explicit CUI triggers to your operational workflows

Update your operational runbooks and tickets so MP-6(4) happens automatically at the right times:

• Asset retirement / refresh
• Employee offboarding (especially remote endpoints)
• Lease return (copiers, laptops)
• Hardware RMA/repair shipments
• Data center decommission
• Cloud tenant offboarding and storage lifecycle actions
• Backup media expiration and destruction events

In practice, the fastest win is to add mandatory fields in the ticket:

• “Did asset store CUI?” (Yes/No/Unknown; default to Yes for in-scope classes)
• Sanitization method selected
• Approver sign-off when exceptions occur
• Attached evidence requirement before closure

4) Control third parties in the disposal chain

If any third party handles your media (recycler, destruction vendor, copier lessor, ITAD provider), bind MP-6(4) expectations into:

• Contract language (sanitization/destruction requirements, proof delivery, breach notification)
• Chain-of-custody procedures
• Personnel access controls and facility controls where relevant
• Required certificates of destruction/wipe logs that reference your asset identifiers

This is where third-party risk management intersects directly with MP-6(4): you are still accountable for the outcome even if a third party performs the destruction.

5) Implement exception handling that auditors will accept

Exceptions happen (lost devices, failed drives, emergency replacements). Your exception path should require:

• Written justification tied to incident/ticket number
• Risk acceptance by an authorized approver
• Compensating controls (device encryption status, remote wipe attempt, confirmed vendor destruction)
• Post-event follow-up and trend tracking

Avoid an exception process that is “email-only” with no record retention plan.

6) Prove ongoing operation through recurring checks

Build a lightweight control monitoring routine:

• Sample closed tickets for asset disposal and validate evidence attachments.
• Reconcile ITAM dispositions against destruction certificates.
• Verify that in-scope asset classes are not being sold/auctioned without sanitization proof.
• Confirm third-party certificates are complete and match asset IDs.

If you manage controls in Daydream, map MP-6(4) to a control owner and define recurring evidence requests (for example: monthly disposal report + sample artifacts) so you are never rebuilding proof during an assessment.

Required evidence and artifacts to retain

Auditors typically want “policy + procedure + proof.” For MP-6(4), keep:

• Media Sanitization and Disposal Policy with CUI scope called out. ³
• CUI media sanitization standard (method matrix by media type).
• Asset inventory exports showing in-scope asset classes and unique identifiers.
• Sanitization/destruction records, such as:
  • Tool logs (wipe reports) mapped to asset tag/serial
  • Certificates of destruction from third parties
  • Chain-of-custody forms for pickups and transfers
  • Copier/MFD end-of-lease wipe confirmations
• Tickets/work orders demonstrating execution, including approvals and attachments.
• Exception/risk acceptance records with compensating controls.
• Third-party due diligence and contract clauses for ITAD/destruction providers (as applicable).

Retention period: align to your organization’s records retention schedule; document it and apply it consistently.

Common exam/audit questions and hangups

Expect questions like:

1. “Show me how you identify media that contains CUI.”
   Hangup: teams rely on tribal knowledge instead of a scope register tied to ITAM.

2. “Provide evidence for a sample of disposed assets.”
   Hangup: destruction certificates do not list serial numbers, or they list them but your ITAM uses different identifiers.

3. “How do you handle leased copiers and MFDs?”
   Hangup: copier hard drives are frequently missed, especially during office moves.

4. “What happens when hardware is sent for repair or RMA?”
   Hangup: no documented decision about whether to remove drives, encrypt, or sanitize first.

5. “How do you manage backups that may contain CUI?”
   Hangup: backups are treated as operational, not as media requiring controlled destruction at end-of-life.

Frequent implementation mistakes (and how to avoid them)

• Mistake: Policy exists, but no ticket hooks.
  Fix: require sanitization evidence before asset disposal tickets can close.

• Mistake: CUI scope is undefined.
  Fix: create a CUI media scope register and default uncertain assets to “in scope” until proven otherwise.

• Mistake: Third-party destruction proof is not verifiable.
  Fix: require certificates/logs that reference your asset identifiers and reconcile them monthly.

• Mistake: Ignoring “non-obvious” media.
  Fix: include MFD/copiers, removable media, and backup media in the same lifecycle process.

• Mistake: Exceptions become the norm.
  Fix: require formal approval and track exception themes; convert frequent exceptions into updated process or tooling.

Risk implications (what failure looks like)

MP-6(4) failures often surface as:

• Data exposure when devices are resold, recycled, or returned.
• Inability to demonstrate control operation during a federal assessment, leading to findings and remediation plans.
• Third-party incidents where your media is mishandled and you cannot prove chain-of-custody or sanitization.

Even without public enforcement cases in the provided sources, the risk is straightforward: residual CUI on media is a preventable loss path, and auditors treat weak evidence as weak control operation. ³

A practical 30/60/90-day execution plan

First 30 days (stabilize and define)

• Assign an MP-6(4) control owner and name the operational owners (ITAM, endpoint, infra, records, procurement).
• Build the CUI media scope register (asset classes + repositories + third parties).
• Standardize the sanitization method matrix and get it approved.
• Update disposal/return tickets to require CUI determination and evidence attachments.

Days 31–60 (operationalize and collect proof)

• Train service desk, ITAM, and facilities on the CUI media process.
• Pilot on a small set of real events (endpoint refreshes, server decommissions, paper destruction pickup).
• Amend third-party contracts/SOWs to require traceable certificates and chain-of-custody where needed.
• Stand up an evidence repository structure (by month, by asset class) so retrieval is predictable.

Days 61–90 (monitor and harden)

• Run a control effectiveness check: sample completed disposals and verify evidence quality end-to-end.
• Close gaps found in reconciliation (missing serials, missing tickets, unclear approvals).
• Formalize exception handling and reporting.
• In Daydream, map MP-6(4) to recurring evidence artifacts and set reminders so future audits pull from a living record, not a one-time scramble.

Frequently Asked Questions

Does MP-6(4) require a specific wipe standard or tool?

The provided source text does not prescribe a specific tool in this excerpt. What auditors expect is that your approved sanitization methods are appropriate by media type and that you can prove they were applied to CUI-bearing media. ¹

If drives are encrypted, can we skip sanitization before disposal?

Treat encryption as a supporting control, not a universal waiver. Document your decision criteria, require approval for any “encrypt-only” disposition, and retain evidence of encryption status plus the disposition record.

How do we handle leased copiers and multifunction devices that may store CUI?

Put MFDs in your CUI media scope register and require wipe/destruction proof before return. Make this a procurement and facilities checklist item so it happens during moves and lease transitions.

What evidence is “good enough” for a third-party ITAD/destruction provider?

Keep a certificate or log that ties the destruction or sanitization to your asset identifiers and dates, plus chain-of-custody where media leaves your site. If the vendor cannot reference serials/asset tags, your evidence will be hard to defend.

Do cloud snapshots and exported backups count as “media” for MP-6(4)?

They can, from an operational standpoint, because they are persistent storage that may contain CUI. Treat snapshot deletion, lifecycle policies, and tenant offboarding as sanitization-equivalent events with logs and approvals retained.

We have multiple systems with CUI. How do we keep MP-6(4) from becoming a documentation burden?

Standardize the method matrix and evidence pattern across asset classes, then automate the ticket fields and evidence collection. Daydream helps by tying MP-6(4) to owners and recurring evidence requests so you collect proof as part of operations, not as a special audit project.

Footnotes

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

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

3. NIST SP 800-53 Rev. 5