Media Sanitization

To meet the media sanitization requirement, you must sanitize any organization-defined system media before you dispose of it, release it outside your control, or reuse it, using documented techniques and procedures your organization has defined. This is an operational control: define what “media” includes, standardize sanitization methods, and keep proof for every sanitization event. (NIST Special Publication 800-53 Revision 5)

Key takeaways:

• Define “system media” broadly (physical and virtual) and tie it to concrete handling workflows (reuse, disposal, external transfer).
• Require approved sanitization methods per media type, then document and train the process.
• Keep auditable evidence for each sanitization action: inventory, request/approval, method, performer, and verification. (NIST Special Publication 800-53 Revision 5)

Media sanitization fails in practice for one reason: teams treat it as a “disposal” problem, not a lifecycle control. The requirement in NIST SP 800-53 Rev. 5 MP-6 is simple, but the operational scope is wide. “System media” can include laptops, removable drives, storage arrays, paper output, backup media, and media embedded inside assets you ship back to a lessor, manufacturer, or third party. The trigger events are also broader than “end of life”: reuse inside the organization, release outside organizational control, and disposal all require sanitization. (NIST Special Publication 800-53 Revision 5)

For a Compliance Officer, CCO, or GRC lead supporting FedRAMP Moderate work, MP-6 is a control you operationalize by (1) defining your media categories and sanitization techniques, (2) implementing repeatable workflows across ITAM, security, data center operations, and procurement/third-party management, and (3) retaining evidence that shows sanitization occurred before control changed hands. This page gives you requirement-level guidance you can put into tickets, procedures, and audit folders without guesswork. (NIST Special Publication 800-53 Revision 5)

Regulatory text

Requirement (MP-6): “Sanitize organization-defined system media prior to disposal, release out of organizational control, or release for reuse using organization-defined sanitization techniques and procedures.” (NIST Special Publication 800-53 Revision 5)

Operator interpretation: You are required to do three things:

1. Define what counts as “system media” in your environment (“organization-defined system media”).
2. Define acceptable sanitization techniques and procedures for those media types (“organization-defined sanitization techniques and procedures”).
3. Ensure sanitization occurs before any of these events: disposal, release outside your control, or release for reuse. Then prove it with records. (NIST Special Publication 800-53 Revision 5)

Plain-English interpretation (what the requirement really means)

If a device or storage medium has held your system’s data (including sensitive configuration data, credentials, logs, or customer content), you must remove that data in an approved way before the medium:

• gets thrown away or recycled,
• gets shipped to anyone outside your organization (return-to-lessor, RMA to manufacturer, e-waste vendor, moving company, hosting provider, data center landlord, or any third party), or
• gets reassigned for reuse (reimaged laptop, repurposed server, reused backup tapes, redeployed disks). (NIST Special Publication 800-53 Revision 5)

The “organization-defined” language is your responsibility: auditors expect you to make explicit decisions and apply them consistently.

Who it applies to (entity and operational context)

Applies to:

• Cloud Service Providers and Federal Agencies operating systems aligned to FedRAMP Moderate that implement NIST SP 800-53 controls. (NIST Special Publication 800-53 Revision 5)

Operational contexts that trigger MP-6 quickly:

• Endpoint lifecycle: provisioning, repair, reissue, and disposal.
• Data center operations: disk replacements, array decommission, server refresh, colocation exits.
• Backup and DR: rotating removable media, offsite storage returns, destruction events.
• Third-party returns: leased equipment, manufacturer RMAs, managed service hardware swaps.
• Mergers, office closures, relocations, or contract terminations where assets leave your custody.

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

Step 1: Define “system media” and scope it to your asset reality

Create a short scoping statement and a media register. Include, at minimum, categories you actually handle:

• End-user devices (laptops/desktops/tablets/phones)
• Removable storage (USB, external drives)
• Server/storage components (HDD/SSD/NVMe, arrays, SAN/NAS components)
• Backup media (if you use it)
• Paper or printed output that contains system data (if applicable to your environment)

Your definition must be operational: teams should be able to decide in minutes whether an item is in-scope. (NIST Special Publication 800-53 Revision 5)

Step 2: Define sanitization techniques and procedures per media type

Write a sanitization standard that maps media type → approved technique → verification method → who can perform it → evidence required. MP-6 does not prescribe methods; it requires you to define and follow them. (NIST Special Publication 800-53 Revision 5)

Practical approach:

• For each media type, choose one primary method and one fallback (for failures, damaged drives, or encryption key loss scenarios).
• Include decision logic for: reusable vs. non-reusable outcomes, and “cannot sanitize” escalation.

Step 3: Build three workflows (reuse, disposal, out-of-control release)

Auditors look for consistent handling at the “gate” moments named in MP-6. Implement three ticketable workflows:

1. Release for reuse (internal)

   • Trigger: reassignment, redeploy, reimage, repurpose.
   • Control: sanitization completed before the asset changes assignee or function.

2. Disposal

   • Trigger: e-waste pickup, recycler handoff, destruction.
   • Control: sanitization completed and documented before discard.

3. Release out of organizational control (external transfer)

   • Trigger: shipping to third party, returning leased gear, RMA, moving to offsite storage where you no longer control the media.
   • Control: sanitize before shipment/transfer, or follow your defined procedure when sanitization is infeasible (then document the exception and compensating actions you defined). (NIST Special Publication 800-53 Revision 5)

Step 4: Assign clear roles and approvals

Common RACI pattern:

• Asset owner / system owner: initiates and confirms the media is in scope.
• IT operations / data center ops: performs sanitization steps.
• Security or GRC: defines standards, reviews exceptions, samples evidence.
• Procurement / third-party management: enforces contract language for third parties handling media and confirms chain-of-custody artifacts exist.

Keep this simple: if nobody “owns” the handoff moment, MP-6 fails in practice. (NIST Special Publication 800-53 Revision 5)

Step 5: Add verification and exception handling that auditors can follow

Your procedure should require verification appropriate to the technique you defined. Then add an exception path for:

• failed wipes,
• dead drives,
• encrypted media where key material is unknown,
• assets that must be returned quickly (RMA/lease return).

Your exception path must still satisfy “organization-defined techniques and procedures.” If the procedure says “destroy,” then document destruction instead of wipe. (NIST Special Publication 800-53 Revision 5)

Step 6: Train and embed it in systems of record

Media sanitization fails when it lives in a PDF nobody uses. Embed required fields into your systems:

• ITSM ticket templates for decommission/reuse/transfer
• Asset management statuses and required transitions
• Shipping/receiving checklists
• Third-party offboarding checklists

If you use Daydream to manage third-party due diligence and offboarding workflows, add a “media leaving our control” task bundle that requires chain-of-custody and sanitization artifacts before closure. That keeps MP-6 from becoming an email-based scramble during audits. (NIST Special Publication 800-53 Revision 5)

Required evidence and artifacts to retain

Keep artifacts that prove sanitization happened before the trigger event, and that you followed your defined procedures:

Policy and standards

• Media sanitization policy/standard defining in-scope media and approved techniques/procedures. (NIST Special Publication 800-53 Revision 5)
• Roles/responsibilities (RACI) and exception process. (NIST Special Publication 800-53 Revision 5)

Operational records ¹

• Asset or media identifier (serial number, asset tag, volume ID, or equivalent).
• Trigger type: reuse, disposal, or out-of-control release.
• Date/time of sanitization and who performed it.
• Method used ¹.
• Verification record (tool output, checklist sign-off, destruction certificate, or equivalent).
• Chain-of-custody/shipping record when media leaves your control. (NIST Special Publication 800-53 Revision 5)

Third-party artifacts (when applicable)

• Contract clauses or service terms requiring handling aligned to your procedures.
• Third-party destruction/sanitization attestations where they perform the action (only if your procedure permits it). (NIST Special Publication 800-53 Revision 5)

Common exam/audit questions and hangups

Expect these lines of questioning:

1. “What media is in scope?”
   Auditors test whether “organization-defined system media” is defined and complete. (NIST Special Publication 800-53 Revision 5)

2. “Show me evidence for a sample of disposals/transfers.”
   They will trace an asset from inventory → ticket → sanitization evidence → disposal/transfer evidence. (NIST Special Publication 800-53 Revision 5)

3. “How do you handle RMAs and leased equipment returns?”
   “Release out of organizational control” is where teams get caught. (NIST Special Publication 800-53 Revision 5)

4. “What happens when sanitization fails?”
   If your exception path is informal, auditors will treat it as noncompliance. (NIST Special Publication 800-53 Revision 5)

Frequent implementation mistakes (and how to avoid them)

• Mistake: Treating encryption as automatic sanitization without a defined procedure.
  Fix: If you rely on cryptographic methods, explicitly define them as an approved technique in your standard and require proof of the condition you depend on ¹. (NIST Special Publication 800-53 Revision 5)

• Mistake: No chain-of-custody for third-party pickups.
  Fix: Require pickup receipts, shipping logs, and linkage to asset IDs before closure. (NIST Special Publication 800-53 Revision 5)

• Mistake: “We wiped it” with no per-asset record.
  Fix: Standardize evidence capture per event, tied to asset identifiers. (NIST Special Publication 800-53 Revision 5)

• Mistake: Siloed ownership (IT wipes, procurement ships, nobody governs the handoff).
  Fix: Put the “release out of control” workflow under a controlled ticket with required approvals. (NIST Special Publication 800-53 Revision 5)

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not cite specific actions.

Risk-wise, MP-6 failures tend to show up as:

• data exposure from improperly disposed or resold devices,
• inadvertent disclosure during returns/repairs,
• audit findings due to inability to prove sanitization occurred before transfer. (NIST Special Publication 800-53 Revision 5)

Treat MP-6 as a “proof” control as much as a “do” control. If you cannot produce per-event evidence, you should assume an auditor will mark it as ineffective even if teams believe they sanitize correctly.

Practical 30/60/90-day execution plan

Because the source catalog does not provide time-bound implementation requirements, treat this as a practical rollout cadence you can adapt.

First 30 days (stand up the minimum viable control)

• Define “system media” scope and publish the sanitization standard with approved techniques/procedures. (NIST Special Publication 800-53 Revision 5)
• Identify the three trigger workflows (reuse, disposal, out-of-control release) and create ITSM ticket templates with mandatory evidence fields.
• Start capturing evidence for all new events, even if legacy cleanup takes longer.

By 60 days (make it repeatable across teams and third parties)

• Integrate asset inventory status transitions with required sanitization proof before closure.
• Add contract/offboarding checklist steps for third parties who receive media or assets.
• Start exception tracking: require documented approvals and compensating actions per your defined procedures. (NIST Special Publication 800-53 Revision 5)

By 90 days (make it auditable and resilient)

• Run an internal sampling review: pick a set of recent reuse/disposal/transfer events and verify end-to-end evidence.
• Fix gaps found in chain-of-custody, asset IDs, or verification records.
• Train IT ops, service desk, data center ops, and procurement on the exact workflows and “stop ship” conditions. (NIST Special Publication 800-53 Revision 5)

Frequently Asked Questions

Does MP-6 apply only when we dispose of devices?

No. MP-6 explicitly requires sanitization before disposal, before release out of organizational control, and before release for reuse. Your procedures must cover all three triggers. (NIST Special Publication 800-53 Revision 5)

What counts as “system media” for this requirement?

MP-6 says “organization-defined system media,” so you must define it. In practice, scope anything that can store system data and could be disposed, transferred, or reused. (NIST Special Publication 800-53 Revision 5)

Can a third party perform sanitization for us?

MP-6 allows “organization-defined sanitization techniques and procedures,” which can include third-party steps if your procedures allow it. If you do this, require chain-of-custody and sanitization evidence tied to specific asset identifiers. (NIST Special Publication 800-53 Revision 5)

How do we handle RMAs where the manufacturer wants the drive back?

Treat RMAs as “release out of organizational control.” Your procedure should require sanitization before shipment or define an approved exception method (for example, destruction and replacement) with documented approvals. (NIST Special Publication 800-53 Revision 5)

What evidence do auditors actually want to see?

They typically trace from asset inventory to a ticket/work order, then to sanitization method and verification, then to disposal or transfer documentation. Evidence must be per event and tied to a unique asset identifier. (NIST Special Publication 800-53 Revision 5)

We have a strong decommission process, but records are inconsistent. What should we fix first?

Fix the “proof layer” first: standard ticket templates, required fields, and a single place to store outputs/receipts. Consistent evidence turns a good practice into a passable control. (NIST Special Publication 800-53 Revision 5)

Footnotes

1. NIST Special Publication 800-53 Revision 5