MP-6(7): Dual Authorization

MP-6(7) requires you to enforce dual authorization before any media sanitization occurs for the media types and environments you define. Operationally, that means two independent, pre-approved people must sign off on the sanitization request and/or completion record, with separation of duties and auditable evidence for every event. ¹

Key takeaways:

• Dual authorization must be enforced for sanitization events, not just documented as a policy statement. ¹
• Define the scope of media and sanitization scenarios, then build a workflow that requires two independent approvals and preserves logs. ²
• Your audit pass/fail often hinges on evidence: tickets, approvals, chain-of-custody, and sanitization certificates mapped to assets. ¹

MP-6 is the NIST SP 800-53 control family for media sanitization. Enhancement MP-6(7) tightens the operational bar by requiring dual authorization for sanitization. ¹ This is a classic “high-risk, low-volume” control: sanitization events might not happen daily, but failures can create irreversible exposure because media leaving your control can carry sensitive data.

For a CCO or GRC lead, the fastest path to operationalizing MP-6(7): treat sanitization as a controlled change with a two-person approval gate, implement separation of duties, and retain evidence that ties each sanitization event to a specific asset and disposition outcome. The control is also a strong third-party risk and supply chain requirement, because many organizations outsource destruction, degaussing, shredding, or device refurbishment. You still need dual authorization on your side for the decision to sanitize and for validating completion, even if a third party performs the physical work.

This page breaks MP-6(7) into “what it means,” who it applies to, how to implement it in a workflow, and the exact artifacts auditors ask for.

Regulatory text

Requirement (verbatim): “Enforce dual authorization for the sanitization of {{ insert: param, mp-06.07_odp }}.” ²

Operator interpretation of the text:

• You must require two authorized individuals to approve sanitization actions for the media scope you define under the MP-6(7) organization-defined parameter. ²
• “Enforce” means the process is system- or workflow-enforced (for example, ticketing approvals and access controls), not a best-effort checklist. ¹
• The approvals must be auditable and linked to the sanitization event, the asset, and the final disposition (reused, redeployed, returned, destroyed, etc.). ¹

Plain-English interpretation (what MP-6(7) is asking for)

Dual authorization for sanitization is a guardrail against a single point of failure. One person should not be able to decide to wipe/destroy media and also certify the outcome without oversight. In practice, MP-6(7) expects:

• Two-person integrity: two approvals from defined roles (often “requestor/asset owner” plus “security/IT operations” or “security plus facilities”).
• Independence: the two approvers should be different people, and you should prevent “self-approval.”
• Evidence: the approvals, the method used, and the result must be recorded so an assessor can reconstruct what happened.

This control is especially relevant where sanitization supports device disposal, returns, repairs (RMA), cloud offboarding, data center decommissioning, and third-party destruction services.

Who it applies to (entity and operational context)

Entity types typically scoped to NIST SP 800-53 programs: federal information systems and contractor systems handling federal data. ¹

Operational contexts where MP-6(7) matters most:

• End-user devices: laptops, phones, tablets, removable media.
• Data center gear: servers, storage arrays, backup appliances, tapes.
• Virtual/cloud artifacts: snapshots, virtual disks, encrypted volumes, object storage lifecycle deletes (if your program treats these as “media” under MP-6).
• Third-party flows: leased devices, e-waste vendors, repair depots, managed service providers that handle your hardware.

Control ownership (typical):

• Primary: Information Security / GRC (control design, monitoring).
• Operational: IT Asset Management, Endpoint/Infrastructure Ops, Data Center Ops.
• Supporting: Procurement/TPRM (third-party contracts and certificates), Legal (retention), Facilities (physical destruction chain-of-custody).

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

Step 1: Define the scope for the “organization-defined parameter”

MP-6(7) explicitly relies on your defined scope (“the sanitization of [X]”). ² Write down:

• Media types in scope (e.g., “all storage media that may store controlled or sensitive data”).
• Triggers (disposal, re-assignment, loss, return to lessor, offsite repair, break/fix, data center decommission).
• Sanitization methods allowed in each case (clear, purge, destroy, cryptographic erase), and who is allowed to perform/verify.

Deliverable: a short “MP-6(7) Scope Statement” that your procedures reference.

Step 2: Establish roles and separation-of-duties rules

Define two required authorizers, and make the rule enforceable:

• Authorizer A (business/asset authority): asset owner, system owner, or delegated manager who confirms the asset is approved for sanitization and that retention/legal holds were checked.
• Authorizer B (security/technical authority): security, IT operations lead, or asset management lead who confirms the method is appropriate and the workflow will capture evidence.

Minimum rules to document:

• Approver A and B must be two different individuals.
• Approvers must be trained and pre-approved (role-based list).
• Exceptions must be documented and time-bounded with compensating controls.

Step 3: Implement an enforced workflow (ticket + approvals + completion)

Build a single “sanitization event” record that cannot close without dual authorization.

A practical workflow:

1. Request created (ticket in ITSM or GRC system) with asset ID, serial number, data classification, location, and reason.
2. Hold check (legal hold / investigation hold / records retention gate) recorded in the ticket.
3. Approval 1 captured (electronic approval with identity and timestamp).
4. Approval 2 captured (different approver; workflow blocks self-approval).
5. Execution (wipe/destroy performed by authorized technician or approved third party).
6. Verification recorded (wipe report, degauss log, destruction certificate, or secure erase output).
7. Disposition update (asset inventory updated; chain-of-custody attached).
8. Ticket closed only after required evidence is attached and verified.

Step 4: Tie sanitization to asset inventory and chain-of-custody

Auditors will test whether a ticket “represents a real asset.” Make sure:

• Every sanitization record references an asset inventory identifier and serial number.
• Chain-of-custody shows who had the media, when custody transferred, and where it went (internal, storage cage, third party).
• Final disposition is reflected in asset status (destroyed, retired, transferred, returned).

Step 5: Control third-party sanitization

If a third party performs destruction:

• Require dual authorization before releasing media to the third party.
• Contractually require sanitization/destruction certificates and specify minimum certificate fields (date, method, asset identifiers, signature).
• Reconcile certificates to your asset list and ticket list. Missing certificates should open an exception ticket.

Step 6: Monitor and test the control

Operational checks that work:

• Periodic sampling of sanitization events to confirm dual approvals exist and are independent.
• Reconcile “retired assets” against “sanitization records.” Any mismatch becomes a finding.
• Validate approver lists against HR rosters (terminated users removed, role changes reflected).

Daydream fit (earned mention): If you manage multiple frameworks, Daydream helps map MP-6(7) to a named control owner, a repeatable procedure, and a standard evidence set so you stop rebuilding the same audit packet each cycle. ¹

Required evidence and artifacts to retain

Keep evidence at two levels: control design and control operation.

Design artifacts (what you planned):

• MP-6(7) scope statement (what media and scenarios require dual authorization). ²
• Media sanitization policy and procedure with dual-authorization steps. ¹
• Role/permission matrix: who can approve, who can execute, who can verify.

Operational artifacts (what happened):

• Sanitization tickets/records showing two approvals (identity, timestamp, approver role).
• Proof of separation of duties (system prevents the same user approving both steps).
• Execution evidence: wipe logs, tool output, degauss logs, or destruction certificates.
• Chain-of-custody forms and shipping manifests (if moved offsite).
• Asset inventory updates that match the sanitization outcome.
• Exception approvals and compensating-control documentation (if any).

Common exam/audit questions and hangups

Assessors tend to ask:

• “Show me the workflow. Where is dual authorization enforced rather than optional?” ¹
• “Who are the authorized approvers, and how do you remove access when people leave?”
• “How do you prevent self-approval or approval by a shared mailbox?”
• “Pick three retired assets. Prove they were sanitized, with two approvals and final disposition evidence.”
• “For third-party destruction, how do you reconcile certificates to your asset inventory?”

Hangups that trigger findings:

• Approvals exist, but they are captured as email screenshots with no identity assurance.
• Dual authorization applies only to destruction, not to wipe-and-redeploy scenarios.
• Asset inventory does not track serial numbers consistently, so evidence cannot be tied to a specific device.

Frequent implementation mistakes (and how to avoid them)

1. Policy-only compliance.
   Fix: enforce approvals in ITSM/GRC tooling; block closure without two approvals. ¹

2. No “organization-defined parameter” clarity.
   Fix: define exactly which media and scenarios require dual authorization; publish the scope and train teams. ²

3. Same person approves twice.
   Fix: workflow rule and periodic review of approval logs for duplicates.

4. Execution without verification evidence.
   Fix: define required proof per method (wipe report vs destruction certificate) and make attachment mandatory.

5. Third-party certificates don’t match your assets.
   Fix: require certificates to include asset identifiers; reconcile on receipt; treat gaps as incidents or exceptions.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so you should frame risk using assessment outcomes rather than enforcement headlines.

Risk implications that matter operationally:

• Data remanence risk: media leaves your control with recoverable data.
• Fraud/abuse risk: a single insider can destroy evidence or circumvent retention/legal hold by wiping media without oversight.
• Audit failure risk: inability to prove dual authorization and sanitization completion is a common “evidence gap” finding. ¹

Practical 30/60/90-day execution plan

First 30 days (stabilize scope and workflow)

• Write and approve the MP-6(7) scope statement tied to your media types and disposition scenarios. ²
• Assign control owner and backups; document approver roles and separation-of-duties rules.
• Implement or update the sanitization ticket template with required fields and two approval steps.
• Identify where evidence lives (ITSM attachments, DLP logs, endpoint wipe reports, third-party certificates).

Days 31–60 (enforce, integrate, and train)

• Configure tooling to prevent self-approval and require two distinct approvals before execution or before ticket closure.
• Integrate asset inventory identifiers into sanitization requests (mandatory serial/asset tag).
• Update third-party contracts/SOWs to require certificates with required fields and defined turnaround.
• Run a tabletop with ITAM + Security + Facilities for one internal and one third-party sanitization scenario.

Days 61–90 (prove operation and close evidence gaps)

• Perform a small internal assessment: sample closed tickets and verify dual authorization, method evidence, and asset inventory updates.
• Establish recurring monitoring: reconciliation of retired assets vs sanitization records.
• Formalize exception handling (who can approve, what evidence is required, how long exceptions last).
• Package a standard “audit binder” for MP-6(7) in Daydream or your GRC system: procedure, role list, sample tickets, and reconciliation results. ¹

Frequently Asked Questions

Does MP-6(7) require two approvals before the wipe/destroy happens, or can the second approval be after?

The control text requires dual authorization “for the sanitization,” so treat it as a pre-execution gate in your workflow. If you place the second approval after-the-fact, document why and add compensating controls, but expect scrutiny. ²

Can the same team provide both approvers if they are different individuals?

Yes, if you can show independence and separation of duties in practice. Many programs use two different roles within IT operations (e.g., ITAM manager plus data center lead) when Security is not operationally in the loop.

What counts as “media” for MP-6(7)?

MP-6 is about media sanitization broadly, and your organization-defined scope for MP-6(7) determines what media types are covered. Write the scope so it matches your data storage reality: endpoints, removable media, and data center storage are typical starting points. ²

If we use full-disk encryption and do cryptographic erase, do we still need dual authorization?

Yes. Dual authorization is about governance and preventing unilateral action, not about which technical sanitization method you choose. Record the method as part of the evidence set.

How do we handle emergency sanitization (lost device, incident response)?

Pre-define an emergency path with named approver roles, faster approvals, and tighter post-event review. Keep the dual-authorization requirement unless you document an exception with compensating controls and leadership sign-off.

What evidence is strongest for auditors?

A single ticket that shows two distinct approvals, an attached wipe/destroy proof artifact, and an asset inventory update that matches the serial number and disposition. That end-to-end trace is what most assessors want to see. ¹

Footnotes

1. NIST SP 800-53 Rev. 5

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