MP-6(1): Review, Approve, Track, Document, and Verify
MP-6(1) requires you to treat every media sanitization or disposal event as a controlled, auditable workflow: someone reviews the request, an authorized person approves it, the action is tracked and documented end-to-end, and you verify the sanitization/disposal actually happened as intended 1. Build a repeatable chain of custody with approvals and validation evidence.
Key takeaways:
- You need an auditable workflow for media sanitization/disposal: review → approval → tracking → documentation → verification 1.
- Chain-of-custody and verification evidence matter as much as the technical wipe or destruction method.
- Assign one control owner and standardize evidence artifacts so audits don’t rely on “tribal knowledge.”
The mp-6(1): review, approve, track, document, and verify requirement is about control of data-bearing media at its highest-risk moment: when devices and storage leave normal operational custody. Organizations often have a media sanitization SOP, but fail MP-6(1) because the workflow is informal (email approvals, missing serial numbers, no independent verification, unclear roles) and evidence is scattered across IT, facilities, and third parties.
MP-6(1) is an “operator’s control.” Auditors won’t accept a policy statement alone. They will look for individual disposal events that show the complete trail: who requested sanitization, who approved it, exactly what asset/media was handled, what method was used, where it went, and what proof confirms the outcome 1. If you outsource destruction or recycling, MP-6(1) still applies; your obligation shifts to oversight and evidence capture.
This page gives you requirement-level implementation guidance you can put into production quickly: roles, workflow, artifacts, and the exam questions you should be able to answer without scrambling.
Regulatory text
Requirement (verbatim excerpt): “Review, approve, track, document, and verify media sanitization and disposal actions.” 1
What the operator must do:
- Review each sanitization/disposal request for correctness and completeness (asset identity, media type, data sensitivity, required method).
- Approve the action using an authorized approver with defined authority.
- Track the media through the process so you can prove chain of custody.
- Document what happened in enough detail to reconstruct the event later.
- Verify the action succeeded (wipe/destroy/dispose) and meets your sanitization requirements 1.
This control enhancement is not asking you to pick a specific technical sanitization method. It is asking you to make the sanitization/disposal process governable and auditable.
Plain-English interpretation (what MP-6(1) really means)
If a laptop, server drive, backup tape, removable media, or any other data-bearing component is wiped, destroyed, recycled, returned to a lessor, or handed to a third party, you must be able to prove five things:
- It was the right item. You can uniquely identify the media (serial number, asset tag, drive ID, tape barcode).
- The decision was authorized. Someone accountable approved the method and disposition.
- It never “went missing.” Custody transfers are recorded from request through final disposition.
- The record is durable. The documentation persists beyond staff turnover and tooling changes.
- You validated the outcome. You have objective evidence the wipe/destruction/disposal occurred and matched the requirement 1.
Who it applies to (entity and operational context)
MP-6(1) applies broadly anywhere you align to NIST SP 800-53, including federal information systems and contractor systems handling federal data 2.
Operationally, it applies wherever media is:
- Decommissioned (end-of-life servers, storage arrays, network appliances with flash storage).
- Repaired or RMA’d (sending devices to OEMs or repair shops).
- Reassigned (reimaging laptops, transferring equipment between departments).
- Disposed or recycled (e-waste events, ITAD engagements).
- Virtualized or cloud-adjacent (physical media managed by a colocation provider or cloud service where you still retain evidence obligations through contracts and reports).
If you use third parties for IT asset disposition (ITAD), shredding, recycling, or offsite destruction, MP-6(1) becomes a third-party oversight and evidence capture requirement as much as an IT requirement.
What you actually need to do (step-by-step)
1) Name a control owner and define RACI
Pick a single accountable owner (often IT Operations, Security, or Asset Management) and document RACI:
- Requester: initiates sanitization/disposal (e.g., desktop support, data center ops).
- Reviewer: checks completeness and method selection.
- Approver: authorizes disposition (often Security or IT Asset Manager).
- Custodian/Executor: performs wipe/destruction or coordinates with third party.
- Verifier: confirms results (can be Security, QA, or a separate technician).
- Records owner: ensures retention and audit readiness.
Keep separation of duties where feasible: the person who performs destruction should not be the only person who verifies it.
2) Standardize “what counts as media” and define trigger events
Create a short internal standard that lists in-scope media types and triggers, such as:
- Storage devices (HDD/SSD/NVMe), removable media (USB, SD cards), backup media, embedded flash in devices.
- Triggers: decommission, transfer, return/lease end, repair/RMA, disposal, loss/theft, or damage requiring destruction.
This prevents gaps like “we tracked laptops but not the SSDs pulled from servers.”
3) Implement a controlled workflow (ticket + disposition record)
You need one system of record. A practical pattern:
- Ticketing system (request and approval trail)
- Asset/CMDB (asset identity)
- Disposition log (sanitization/disposal record, can be the ticket itself if structured)
Minimum fields to capture:
- Asset ID, serial number, media type, system association
- Data classification or handling level
- Requested disposition (wipe, degauss, shred, recycle, return)
- Required method/standard (your internal sanitization standard)
- Approver name/title and timestamp
- Third party involvement and chain-of-custody handoff details
- Verification method and verifier identity
- Final disposition date and evidence attachments
4) Build “approval rules” that match risk
Define approval thresholds that scale with sensitivity and exposure:
- Higher-risk media (regulated data, authentication secrets, security tooling, privileged systems) requires Security approval.
- Routine endpoints may route to IT Asset Management approval if policy permits.
- Any third-party transfer requires confirmation of contract terms and evidence expectations before pickup.
Write these as decision rules in your SOP so technicians aren’t making ad hoc calls.
5) Track chain of custody end-to-end (including third parties)
Chain-of-custody is where programs fail. Make it explicit:
- Internal handoffs: who released the device, who received it, where it was stored, storage cage access controls.
- Third-party handoffs: pickup manifest, container seal numbers (if used), courier tracking, receipt confirmation.
- Partial media removals: if you pull drives from a chassis, track both the chassis disposition and the drive disposition.
If your ITAD partner issues Certificates of Destruction (CoD), ensure the CoD references asset identifiers you can reconcile.
6) Document the action in a consistent “evidence packet”
For each event, you should be able to produce one packet (digital) containing:
- Request and approval record
- Asset identifiers and classification basis
- Sanitization/destruction method used
- Proof of completion (logs, screenshots, tool output, third-party certificate)
- Verification evidence and sign-off 1
7) Verify outcomes (don’t confuse “done” with “verified”)
Verification should be objective and appropriate to the method:
- If you perform a software wipe, verification might include wipe tool logs and spot-check validation steps.
- If you destroy media, verification might include witnessed destruction records or third-party CoD tied to serials.
- If media is returned (lease/OEM), verification might include confirmation the required sanitization occurred before transfer, plus receiving documentation.
Define what “pass/fail” means. If verification fails, treat it as an incident or at least a nonconformance with corrective action.
8) Operationalize recurring oversight (sampling + reconciliation)
Add lightweight governance that makes audits easy:
- Periodic sampling of completed tickets for completeness.
- Reconciliation between asset inventory and disposition logs (assets retired should have a corresponding sanitization/disposal record).
- Review third-party evidence quality and timeliness.
If you use Daydream for third-party risk management and due diligence, route ITAD providers through Daydream intake so contract requirements (evidence, reporting cadence, subcontractor controls) align with MP-6(1), and store recurring artifacts (CoDs, manifests, SOC reports if provided) alongside the third-party record for faster audits.
Required evidence and artifacts to retain
Retain artifacts that prove each verb in MP-6(1) happened 1:
Core artifacts 1:
- Sanitization/disposal request record (ticket or form)
- Review notes (completeness check, method selection)
- Approval record (name/role/date, approval rule invoked)
- Chain-of-custody log (handoffs, storage location, pickup/delivery proof)
- Execution record (wipe tool output, destruction work order, recycler job record)
- Verification record (verifier sign-off, validation results)
- Final disposition confirmation (asset status change in CMDB/asset system)
Program-level artifacts:
- Media sanitization and disposal SOP
- Role/authority matrix for approvals
- Third-party contracts/SOW language specifying evidence and handling
- Training records for personnel executing/verifying disposal
- Exception register (approved deviations with compensating controls)
Common exam/audit questions and hangups
Auditors and assessors commonly ask:
- “Show me the last few media disposals and the full evidence trail from request through verification.”
- “Who is authorized to approve destruction of regulated-data media, and where is that authority documented?”
- “How do you know the Certificate of Destruction maps to your asset inventory?”
- “How do you prevent ‘shadow disposal’ where devices are recycled without a record?”
- “What do you do when a third party can’t provide serial-level CoDs?”
Hangups that trigger findings:
- Evidence exists, but identifiers don’t reconcile (CoD lists counts, not serials).
- Approval is implicit (“manager said ok in chat”) and not captured.
- Verification is missing or performed by the same person who executed the action.
Frequent implementation mistakes (and how to avoid them)
| Mistake | Why it fails MP-6(1) | Fix |
|---|---|---|
| Treating “policy exists” as compliance | MP-6(1) expects operational evidence per action 1 | Build an evidence packet template and require attachments before ticket closure |
| No serial/asset identifiers in records | You can’t prove the right media was sanitized | Require asset tag/serial fields; block closure if blank |
| Third-party CoDs not reconcilable | Tracking and verification break at the boundary | Contract for serial-level reporting; require manifests tied to your inventory |
| Approvals via email/chat only | Approval is not durable or consistently retrievable | Use a ticket workflow with role-based approvals |
| Verification is vague (“completed”) | “Verify” requires an actual validation step 1 | Define verification criteria per method and record the result |
Enforcement context and risk implications
No public enforcement cases were provided in the source catalog for MP-6(1). Treat the risk as practical and audit-driven: weak media disposal controls can cause data exposure, loss of regulated data, or inability to prove sanitization to customers and government assessors. The direct business impact is often failed assessments, delayed authorizations, or customer audit findings rather than a single cited penalty.
Practical 30/60/90-day execution plan
First 30 days (get control of the workflow)
- Assign a control owner and publish RACI for review/approve/verify.
- Define in-scope media types and triggers (decommission, RMA, recycle, lease return).
- Create a single disposition record template (ticket form fields + required attachments).
- Draft approval rules (who approves what) and implement them in the ticketing tool.
Days 31–60 (prove chain of custody and third-party evidence)
- Implement chain-of-custody logging for internal handoffs and storage.
- Update third-party contract/SOW language to require pickup manifests and verifiable completion evidence tied to identifiers.
- Run a pilot: process a small set of disposals through the new workflow and fix field gaps.
- Train technicians and approvers on “no evidence, no closure.”
Days 61–90 (make it audit-ready and sustainable)
- Add verification checklists by method (wipe vs. destroy vs. return).
- Start sampling completed events for completeness and reconciliation with asset inventory.
- Build a dashboard or report showing disposed assets without CoD/verification and remediate.
- Centralize artifacts: store third-party evidence and recurring due diligence in one place (Daydream can hold third-party documentation and map it to MP-6(1) evidence expectations).
Frequently Asked Questions
Do we have to verify every single disposal event, or can we sample?
MP-6(1) explicitly includes “verify,” so you need a defined verification step for each action 1. You can add sampling as an extra oversight layer, but don’t treat sampling as the only verification method unless your procedure defines how each event is verified.
What counts as “approval” for MP-6(1)?
Approval must be attributable to an authorized role and recorded in a retrievable system 1. A ticket approval, workflow sign-off, or recorded e-signature is easier to defend than informal messages.
Our ITAD vendor provides a Certificate of Destruction that lists totals, not serial numbers. Is that acceptable?
It creates a tracking and verification gap because you can’t prove which specific assets were destroyed. Contract for item-level identifiers on manifests/CoDs, or maintain an internal manifest signed at handoff and cross-referenced to the vendor’s certificate.
Does MP-6(1) apply to cloud environments where we don’t touch disks?
If your service model removes physical media handling from your team, your implementation shifts to governance: contract terms, provider attestations, and evidence collection that shows sanitization and disposal actions are reviewed, tracked, and verified through the provider relationship 2.
What evidence is strongest for “verify” on software wiping?
Tool-generated logs tied to the asset identifier, plus a verifier sign-off that confirms the log was reviewed and met pass criteria. Store the log with the ticket so the evidence packet is complete.
Who should own MP-6(1): Security, IT, or Facilities?
Put ownership where the process runs day-to-day (often IT Asset Management or IT Operations) and require Security approval for higher-risk media classes. Facilities can support physical handling, but the control owner should be able to produce end-to-end evidence on demand.
Footnotes
Frequently Asked Questions
Do we have to verify every single disposal event, or can we sample?
MP-6(1) explicitly includes “verify,” so you need a defined verification step for each action (Source: NIST SP 800-53 Rev. 5 OSCAL JSON). You can add sampling as an extra oversight layer, but don’t treat sampling as the only verification method unless your procedure defines how each event is verified.
What counts as “approval” for MP-6(1)?
Approval must be attributable to an authorized role and recorded in a retrievable system (Source: NIST SP 800-53 Rev. 5 OSCAL JSON). A ticket approval, workflow sign-off, or recorded e-signature is easier to defend than informal messages.
Our ITAD vendor provides a Certificate of Destruction that lists totals, not serial numbers. Is that acceptable?
It creates a tracking and verification gap because you can’t prove which specific assets were destroyed. Contract for item-level identifiers on manifests/CoDs, or maintain an internal manifest signed at handoff and cross-referenced to the vendor’s certificate.
Does MP-6(1) apply to cloud environments where we don’t touch disks?
If your service model removes physical media handling from your team, your implementation shifts to governance: contract terms, provider attestations, and evidence collection that shows sanitization and disposal actions are reviewed, tracked, and verified through the provider relationship (Source: NIST SP 800-53 Rev. 5).
What evidence is strongest for “verify” on software wiping?
Tool-generated logs tied to the asset identifier, plus a verifier sign-off that confirms the log was reviewed and met pass criteria. Store the log with the ticket so the evidence packet is complete.
Who should own MP-6(1): Security, IT, or Facilities?
Put ownership where the process runs day-to-day (often IT Asset Management or IT Operations) and require Security approval for higher-risk media classes. Facilities can support physical handling, but the control owner should be able to produce end-to-end evidence on demand.
Operationalize this requirement
Map requirement text to controls, owners, evidence, and review workflows inside Daydream.
See Daydream