MP-8(4): Classified Information

MP-8(4) requires you to downgrade any system media that contains classified information before you release it to people who do not hold the required access authorizations. Operationally, this means you must have a controlled, documented “classification review and downgrade” workflow for media leaving your custody, plus evidence that each release was approved and handled correctly. 1

Key takeaways:

  • Treat “release” as any transfer of media custody to unauthorized individuals, including reuse, disposal, returns, and third-party handoff. 1
  • Build a repeatable downgrade decision path with approvals, chain-of-custody, and labeling updates tied to each media item. 1
  • Evidence wins audits: maintain downgrade determinations, sanitization/downgrade actions performed, and release authorizations per event. 1

The mp-8(4): classified information requirement is a media-release control. It focuses on what happens when removable media, printed output, storage devices, or other system media that may contain classified information is about to leave your control and be provided to someone who is not cleared or otherwise authorized to receive that classified level.

CCOs and GRC leads usually run into MP-8(4) during assessments because media handling is distributed across IT, security operations, facilities, and sometimes program teams. The risk is simple: if you release media with residual classified content (or labels indicating it is classified, even after content changes), you can create an unauthorized disclosure event. MP-8(4) is the requirement that forces a formal downgrade step before release to an unauthorized party. 1

This page gives you requirement-level implementation guidance you can put into a procedure quickly: who owns the decision, what checks must happen, how to document it, what auditors ask for, and how to avoid the most common operational failures. It also includes an execution plan and practical artifacts you can adopt immediately.

Regulatory text

Requirement (verbatim): “Downgrade system media containing classified information prior to release to individuals without required access authorizations.” 1

Operator interpretation: Before any media that contains classified information leaves your custody and is transferred to someone who lacks the required authorization, you must perform a formal downgrade of that media. This is not a generic “dispose securely” statement. It is a specific gate: downgrade must occur prior to release, and it must address classified information on system media. 1

Plain-English meaning

  • If the recipient is not authorized for the classification level on the media, the media cannot be released “as-is.”
  • “Downgrade” means you change the classification status of the media through an approved process so it is safe to release to the intended recipient, and the classification markings/handling instructions align with the downgraded state. 1

Who it applies to

MP-8(4) most directly applies to:

  • Federal information systems handling classified information. 1
  • Contractor systems handling federal data where classified information is present on system media, including mission systems, lab environments, or program enclaves. 1

Operational contexts where MP-8(4) becomes real:

  • Returning failed drives or appliances to a manufacturer or third party for RMA.
  • Releasing decommissioned storage to an IT asset disposition provider.
  • Handing removable media or printed output to a customer, partner, or uncleared internal staff.
  • Reusing media internally in a lower-classification or unclassified environment.
  • Shipping media offsite for analysis, eDiscovery, forensic support, or repairs with parties that lack the clearance level.

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

The goal is a repeatable release workflow with enforceable gates. Build it as a short runbook that technicians can follow and auditors can test.

Step 1: Define “media release events” and scope the media types

Create a one-page scope statement that lists what counts as “system media” in your environment and what counts as “release.” Include:

  • Removable storage (USB, external SSD/HDD, memory cards)
  • Internal storage removed from systems (drives, arrays, tapes)
  • Virtual media exports where applicable (images, snapshots) when they are treated as portable media
  • Printed output if your program treats print artifacts as media

Define “release” broadly as any transfer of custody to a person without required access authorizations, including disposal vendors and repair vendors (third parties). Anchor your scope to your asset inventory and media handling process so the control is testable. 1

Step 2: Establish roles and a downgrade approval authority

Assign and document:

  • Control owner: accountable for the procedure and evidence readiness.
  • Media custodian (IT/ops): executes the technical steps and maintains chain-of-custody.
  • Downgrade approver: authorized to make the downgrade determination (often security/program authority depending on your environment).

Make the approver role explicit. Auditors will look for independence and authority: the person authorizing downgrade should be recognized as having the responsibility to make that call. 1

Step 3: Build a downgrade decision workflow

Implement a decision path that answers, in order:

  1. Is the media known or suspected to contain classified information?
  2. Who is the recipient and what access authorizations do they have?
  3. Can the media be downgraded under your rules, or must it be retained/destroyed/handled in a classified channel?
  4. What exact actions are required to effect the downgrade (technical + administrative)?
  5. Who signs off, and what labels/records must be updated before release?

Make this workflow a checklist that can be attached to each release ticket. MP-8(4) is hard to “prove” without per-event records. 1

Step 4: Implement controlled execution and chain-of-custody

For each release event, require:

  • A tracked request (ticket or form) that identifies the media item uniquely (asset tag/serial).
  • Custody logging from removal to final handoff.
  • Storage of the media in an appropriate controlled area while pending downgrade approval.
  • Release only after approvals and downgrade actions are completed.

Chain-of-custody does two jobs: it reduces mishandling risk and provides audit evidence that the downgraded media released is the same media that was reviewed. 1

Step 5: Update markings and handling instructions

Downgrade is not complete if your labels and documentation still treat the media as classified at the old level, or if they omit required markings for the new status. Standardize:

  • Physical labels (if used)
  • Shipping labels and shipping method constraints
  • Inventory classification fields
  • Any handling caveats that remain after downgrade

Your procedure should state that outdated markings must be removed or corrected as part of the downgrade package before release. 1

Step 6: Make it measurable and reviewable

Operationalize governance:

  • Periodic sampling of release events for completeness of evidence.
  • Exception handling: how you document “could not downgrade” outcomes and what alternative handling occurred.
  • Training for staff who decommission assets, process RMAs, and manage disposal vendors.

If you use Daydream to run control operations, map MP-8(4) to a single owner, a documented procedure, and a recurring evidence set so you can show assessors a clean control narrative and consistent artifacts without scrambling. 1

Required evidence and artifacts to retain

Keep evidence at two levels: design evidence (your program exists) and operational evidence (it ran for real events).

Design evidence (program-level)

  • Media downgrade/release procedure covering classified media and unauthorized recipients. 1
  • Role assignment (RACI or equivalent) naming control owner and downgrade approval authority. 1
  • Templates: downgrade checklist, release authorization form, chain-of-custody log. 1
  • Training/acknowledgement records for staff involved in media release. 1

Operational evidence (event-level)

  • Ticket/form for each release, including recipient authorization basis. 1
  • Downgrade determination and approver sign-off. 1
  • Record of downgrade actions performed and date/time performed. 1
  • Updated inventory record showing post-downgrade status. 1
  • Chain-of-custody record through handoff. 1

Common exam/audit questions and hangups

Assessors tend to probe the same failure points:

  1. “Show me the procedure”
    They want to see a written, usable runbook for downgrading media before release. 1

  2. “How do you decide the recipient lacks required authorization?”
    Expect questions on how you validate access authorizations and how that validation is documented in the release record. 1

  3. “Give me samples”
    They will sample release events and ask for evidence that downgrade occurred prior to release, not after. 1

  4. “What about third parties?”
    They’ll test whether your process covers RMAs, disposal, and repairs. If your program treats those as “IT operations,” the assessor will still treat them as “release.” 1

Frequent implementation mistakes and how to avoid them

Mistake Why it fails MP-8(4) Fix
Treating sanitization/disposal as the same as downgrade MP-8(4) is a pre-release downgrade gate, not a generic disposal control Create a specific “downgrade prior to release” step and require approval before any handoff. 1
Missing per-event evidence Auditors cannot verify that downgrade occurred before release Require a ticket/checklist and attach approvals + chain-of-custody for every release event. 1
RMA/repair shipments bypass the process These are common “shadow releases” Put receiving/shipping and ITAD/RMA workflows into scope and train those teams. 1
Outdated classification markings remain Creates handling confusion and potential unauthorized disclosure Include label/marking update as a required task in the downgrade checklist. 1
No clear authority to approve downgrade Decisions become ad hoc and inconsistent Name an approval authority in policy and enforce it via workflow controls. 1

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. Your risk exposure is still concrete: releasing media with classified content to unauthorized individuals can trigger incident response, contractual consequences, and loss of trust with the sponsoring agency. MP-8(4) reduces the likelihood of unauthorized disclosure by forcing a documented downgrade gate before release. 1

A practical execution plan (30/60/90)

Use this as a sequencing guide for operators. Adjust for your environment and authority model.

First 30 days (stand up the control)

  • Assign a control owner and downgrade approval authority; publish the responsibility statement. 1
  • Define “system media” and “release” in your environment; update your media handling standard accordingly. 1
  • Create the downgrade/release checklist and chain-of-custody template; make them mandatory for any media leaving custody. 1
  • Identify the top release pathways: ITAD, RMAs, device swaps, offsite support. Add the new gate to those workflows. 1

Next 60 days (operate and generate evidence)

  • Run the process on real events and keep complete event packets (ticket, approval, actions, inventory update, custody log). 1
  • Train IT ops, facilities/shipping, and program staff who touch media release events; track completion. 1
  • Add a lightweight QA review: spot-check event packets for missing approvals or timestamps that suggest release occurred before downgrade. 1

Next 90 days (stabilize and audit-proof)

  • Formalize exception handling for “cannot downgrade” outcomes and verify the alternative handling path is controlled and documented. 1
  • Run an internal assessment-style walkthrough: pick samples, answer the audit questions above, and fix gaps. 1
  • In Daydream, map MP-8(4) to the owner, procedure, and recurring evidence requests so evidence collection stays consistent quarter to quarter. 1

Frequently Asked Questions

Does MP-8(4) apply if the media is being destroyed, not reused?

If the media is released to a third party for destruction and that party lacks required access authorizations, treat it as a release event and apply your downgrade gate before handoff. The requirement is triggered by releasing media to unauthorized individuals. 1

Is “downgrade” the same as “sanitize”?

MP-8(4) is specifically about downgrading classified media before release to unauthorized recipients. Sanitization may be one mechanism you use as part of downgrade, but the control expects a formal downgrade decision and documented authorization before release. 1

What counts as “system media” in practice?

Treat any storage or output medium that can contain system information as in scope, especially removable drives, internal drives removed from servers, and backup media. Define the scope in your procedure so staff can apply it consistently. 1

How do we prove downgrade occurred before release?

Keep a per-event packet with timestamps for approval, downgrade actions performed, and final handoff, plus chain-of-custody logs. Auditors typically sample events and check ordering and completeness. 1

We ship devices to the manufacturer for repair. Does that trigger MP-8(4)?

If the device or its storage contains classified information and the receiving individuals lack the required access authorizations, you must downgrade before shipping or remove the media and process it under your downgrade workflow. Treat RMAs as a standard “release pathway” with required records. 1

What’s the minimum set of artifacts an assessor will accept?

A written procedure, named owner/approver roles, and a set of completed release records showing downgrade determinations and approvals prior to release. Without operational samples, the control often fails on “implemented but not operating.” 1

Footnotes

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

Frequently Asked Questions

Does MP-8(4) apply if the media is being destroyed, not reused?

If the media is released to a third party for destruction and that party lacks required access authorizations, treat it as a release event and apply your downgrade gate before handoff. The requirement is triggered by releasing media to unauthorized individuals. (Source: NIST SP 800-53 Rev. 5 OSCAL JSON)

Is “downgrade” the same as “sanitize”?

MP-8(4) is specifically about downgrading classified media before release to unauthorized recipients. Sanitization may be one mechanism you use as part of downgrade, but the control expects a formal downgrade decision and documented authorization before release. (Source: NIST SP 800-53 Rev. 5 OSCAL JSON)

What counts as “system media” in practice?

Treat any storage or output medium that can contain system information as in scope, especially removable drives, internal drives removed from servers, and backup media. Define the scope in your procedure so staff can apply it consistently. (Source: NIST SP 800-53 Rev. 5 OSCAL JSON)

How do we prove downgrade occurred before release?

Keep a per-event packet with timestamps for approval, downgrade actions performed, and final handoff, plus chain-of-custody logs. Auditors typically sample events and check ordering and completeness. (Source: NIST SP 800-53 Rev. 5 OSCAL JSON)

We ship devices to the manufacturer for repair. Does that trigger MP-8(4)?

If the device or its storage contains classified information and the receiving individuals lack the required access authorizations, you must downgrade before shipping or remove the media and process it under your downgrade workflow. Treat RMAs as a standard “release pathway” with required records. (Source: NIST SP 800-53 Rev. 5 OSCAL JSON)

What’s the minimum set of artifacts an assessor will accept?

A written procedure, named owner/approver roles, and a set of completed release records showing downgrade determinations and approvals prior to release. Without operational samples, the control often fails on “implemented but not operating.” (Source: NIST SP 800-53 Rev. 5 OSCAL JSON)

Operationalize this requirement

Map requirement text to controls, owners, evidence, and review workflows inside Daydream.

See Daydream