MP-6(6): Media Destruction

MP-6(6): media destruction requirement means you must destroy storage media that contains federal data (or information system data) using approved methods, with documented chain of custody and verifiable results, before disposal, reuse, return, or servicing. Operationalize it with a media inventory, destruction triggers, approved sanitization/destruction methods by media type, and retained evidence for every destruction event. ¹

Key takeaways:

• Treat media destruction as an end-to-end workflow: identify media, approve the method, execute securely, and prove it happened.
• Match destruction/sanitization methods to media type and sensitivity, then document the decision and outcome each time.
• Your audit pass/fail hinges on evidence: logs, certificates, tickets, chain-of-custody records, and exception handling.

MP-6(6) sits in the NIST SP 800-53 “Media Protection” family and focuses on a common failure mode: data exposure from retired, returned, lost, or reused media. For most programs, the technical part (shredding a drive, wiping a laptop, degaussing tapes) is easier than the operational part: making destruction consistent, authorized, provable, and repeatable across IT, security, facilities, and third parties.

If you are a Compliance Officer, CCO, or GRC lead, your job is to turn “destroy media” into a control that runs on triggers (device retirement, lease return, RMA, data center exit, employee offboarding, cloud hardware lifecycle events) and produces durable evidence. Examiners and customer assessors will focus on two questions: (1) did you use a method appropriate for the media and the data, and (2) can you prove it for a sample of assets over time.

This page gives requirement-level implementation guidance you can hand to ITAD teams, endpoint ops, data center ops, and third-party managers, and then audit without guesswork. ¹

Regulatory text

Control requirement: “NIST SP 800-53 control MP-6.6.” ²

Operator interpretation: MP-6(6): media destruction requirement expects you to (a) define when media must be destroyed, (b) ensure destruction is performed using authorized methods appropriate to the media type and risk, and (c) maintain records that show the destruction occurred and was controlled. The enhancement label (“Media Destruction”) signals a focus on destruction outcomes, not just general “sanitization policy.” ¹

Plain-English interpretation (what the requirement is really asking)

If storage media ever held sensitive or regulated data, you cannot treat it like ordinary trash or generic surplus. You must destroy it (or sanitize it to an equivalent risk-reducing state, depending on your system’s policy and authorization boundary) in a controlled way and be able to prove it after the fact.

“Controlled” means:

• Someone is accountable for the decision to destroy.
• The method is approved for that media type (HDD, SSD, mobile device flash storage, removable media, backup tape, printed media).
• Custody is tracked from collection to destruction (especially when a third party performs destruction).
• Exceptions are rare, approved, and documented (for example, legal hold or manufacturer return constraints).

Who it applies to (entity and operational context)

Entities

• Federal information systems.
• Contractors and service providers handling federal data or operating systems subject to NIST SP 800-53 security controls. ¹

Operational contexts where MP-6(6) shows up

• Endpoint lifecycle: laptop/desktop retirement, refresh, redeploy, donation, resale, or recycling.
• Data center lifecycle: server decommission, storage array replacement, tape rotation, colocation exit.
• Break/fix and warranty: RMAs, vendor repair depots, leased equipment returns.
• M&A or divestiture: separating inventories and proving destruction of residual media.
• Incident response: drives removed during forensics that later need controlled disposition.
• Third-party risk: IT asset disposition (ITAD) providers, shredding vendors, repair vendors, and logistics providers.

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

1) Create a “control card” operators can run

Write a one-page runbook that includes:

• Objective: prevent data exposure through retired/returned media.
• Owner: Security/GRC with IT Operations execution ownership.
• Trigger events: retirement, reuse/redeploy, disposal, RMA/return, lease return, data center exit.
• Method decision rule: which method is allowed per media type and data classification.
• Evidence bundle: exactly what must be saved per destruction event.
• Exceptions: who can approve and how long exceptions can remain open.
  This aligns with the practical expectation that teams can show ownership, cadence, and evidence. ²

2) Build and maintain a media inventory that supports sampling

Your inventory must allow you to answer, for any sampled asset:

• What it is (asset ID/serial, media type, capacity if relevant).
• Where it is/was (site, cage, user assignment).
• What data category could have been stored (system, environment, classification tag).
• What disposition occurred (destroyed, sanitized then redeployed, returned to lessor, sent for repair under exception). If you cannot tie destruction evidence to a unique asset identifier, audits degrade into story time.

3) Define approved destruction/sanitization methods by media type

Create a simple decision matrix (owned by security, implemented by ops). Example structure:

Media type	Default disposition	Approved methods (examples)	Notes to document
HDD	Destroy or sanitize then reuse	Physical destruction or approved wipe method	Record method + verification result
SSD / flash	Prefer destroy	Physical destruction; wipe only if verified effective for model	Capture rationale if sanitizing
Backup tape	Destroy	Degauss/shred via approved provider	Chain of custody is critical
Paper	Destroy	Cross-cut shred or secure destruction service	Track bins, pickups, certs

Keep it policy-neutral in language if your organization distinguishes “destroy” vs “sanitize,” but operationally insist on method selection + proof.

4) Implement chain-of-custody from collection to destruction

Minimum operational controls:

• Secure collection containers (locked bins, tamper-evident seals where appropriate).
• Logged transfers between teams (IT → facilities → third party).
• Restricted access storage for “awaiting destruction” media.
• Reconciliation: what was collected equals what was destroyed, with discrepancy handling.

If a third party is involved, contract terms should require:

• Documented procedures.
• Personnel screening expectations aligned to your program.
• Destruction certificates with asset identifiers.
• Right to audit (at least document review; onsite if needed).
• Defined breach notification for loss in transit.

5) Execute destruction with verification

Make verification concrete:

• For logical sanitization: capture tool output, success status, and operator identity.
• For physical destruction: capture certificate of destruction, date/time, facility, and a mapping to serial numbers; add photos only if your program requires them.
• For internal destruction: work orders/tickets with approvals and completion sign-off.

6) Close the loop: reconcile, review, and remediate

Run a recurring control health check:

• Sample recent destruction events.
• Confirm every event has the minimum evidence bundle.
• Track gaps to closure with owners and due dates. ²

Daydream fits naturally here when you need a single place to define the control card, standardize evidence bundles, and run recurring health checks so audits do not depend on tribal knowledge. ²

Required evidence and artifacts to retain

Build a “minimum evidence bundle” and enforce it per event. ²

Per destruction batch/event

• Ticket/work order showing trigger event and authorization.
• Asset list with unique identifiers (serial/asset tag) and media type.
• Chain-of-custody record (internal transfers; shipping manifests if shipped).
• Destruction proof:
  • Certificate of Destruction from the provider, or
  • Sanitization logs/output and verification results, or
  • Internal destruction record with witness/approver sign-off.
• Exception records (if any): reason, compensating controls, approver, closure evidence.

Program-level

• Media handling and destruction standard (your decision matrix).
• Third-party contracts/SOWs and due diligence artifacts for ITAD/destruction providers.
• Training or work instructions for staff performing handling and verification.
• Control health check records and remediation tracking.

Common exam/audit questions and hangups

Auditors usually ask for samples and then test traceability:

• “Show me the inventory record and the destruction evidence for these sampled serial numbers.”
• “How do you decide between wiping and physical destruction for SSDs?”
• “Who approves exceptions and how do you prevent ‘temporary’ exceptions from becoming permanent?”
• “What happens when equipment is returned to a lessor or manufacturer?”
• “How do you know the third party destroyed what you shipped?”
• “Where are destruction records stored, and what is the retention expectation?”

Hangup: organizations can describe the process but cannot produce complete evidence for a consistent sample set. Fix this by enforcing the evidence bundle as a closure requirement in the ticketing workflow.

Frequent implementation mistakes (and how to avoid them)

1. Policy-only control. A policy that says “destroy media” without triggers, roles, and evidence fails in practice. Publish the control card and make it operational. ²

2. No asset-to-certificate mapping. Certificates that list “10 drives destroyed” without serial numbers do not support audit sampling. Require identifier-level detail in provider outputs and internal records.

3. SSD assumptions. Teams apply HDD wipe practices to SSDs without validating effectiveness. Default to physical destruction for flash-based media unless you have documented justification and verification artifacts.

4. Third-party blind spot. Shipping media offsite without chain-of-custody records turns destruction into trust. Add custody logs, reconciliation, and contract obligations.

5. Exceptions for RMAs that never close. Track RMAs as exceptions with explicit closure evidence (return receipt, destruction confirmation, or verified sanitization before shipment).

Enforcement context and risk implications

No public enforcement cases were provided in the source material for this requirement, so this page does not cite specific actions. Practically, MP-6(6) failures translate into preventable data exposure events: lost drives in transit, resale of unsanitized devices, and returns to manufacturers with recoverable data. The operational risk is high even when the control severity is rated “medium” in many internal mappings, because the downside is direct confidentiality impact and breach response obligations.

Practical execution plan (30/60/90-day)

Day 30 (foundation)

• Assign control owner and execution owner; publish the control card. ²
• Draft the media-type decision matrix; get Security + IT Ops sign-off.
• Define the minimum evidence bundle and the storage location for records. ²
• Identify third parties in scope (ITAD, shredding, repair depots, logistics).

Day 60 (operationalize)

• Integrate destruction triggers into ITSM workflows (decommission, offboarding, RMA).
• Require identifier-level tracking from inventory to destruction evidence.
• Update third-party contract language or add addenda for evidence, chain-of-custody, and audit rights.
• Pilot a control health check on a small sample; log findings and fix the workflow.

Day 90 (scale and sustain)

• Expand to all sites and teams; standardize intake bins, custody logs, and reconciliations.
• Formalize exception handling with approval routing and closure SLAs (your internal targets).
• Run a recurring health check and track remediation to validated closure with due dates. ²
• Package an “audit-ready” evidence binder: policy/standard + last period’s sample set + third-party artifacts.

Frequently Asked Questions

Does MP-6(6) require physical destruction, or is wiping enough?

The control enhancement label focuses on “media destruction,” so your program should default to destruction where risk warrants it and document any sanitization alternative with verification artifacts. Your decision matrix by media type is what makes this defensible. ¹

How do we handle leased equipment returns?

Treat lease returns as a trigger event with a required disposition path: sanitize/destroy per your policy, then document chain of custody and return receipts. If you cannot destroy media due to contract terms, document the exception and compensating controls.

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

Require a certificate of destruction that maps to unique asset identifiers, plus shipping/chain-of-custody documents that reconcile what you sent to what was destroyed. If the provider cannot produce identifier-level reporting, treat it as a control gap.

We have remote employees. How do we destroy media from home offices?

Provide a controlled return process (prepaid tracked shipping, tamper-evident packaging where appropriate) or an approved local destruction option with documented proof. Do not accept “employee confirmation” as the only evidence.

How do we manage RMAs and devices sent for repair?

Make “repair shipment” an exception workflow unless the device is verified sanitized before shipment. Keep a record of approvals, what data could be present, and closure evidence (return confirmation and final disposition).

What should we store in Daydream versus in ITSM or asset tools?

Keep system-of-record asset data in your CMDB/asset platform and operational tickets in ITSM, then use Daydream to standardize the control card, define the evidence bundle, and run control health checks with a consistent audit trail. ²

Footnotes

1. NIST SP 800-53 Rev. 5

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