MP-6(2): Equipment Testing

A surprising number of media sanitization programs fail during assessments for one simple reason: the organization can describe what it intends to do (wipe, degauss, shred), but cannot prove the method works as implemented in their environment. MP-6(2) closes that gap by requiring testing of sanitization equipment and procedures so you can show the intended sanitization is being achieved. ¹

For a Compliance Officer, CCO, or GRC lead, the fastest path to “operationalized” is to treat MP-6(2) like a quality assurance control: define acceptance criteria, test against those criteria on a repeatable cadence, capture objective evidence, and fix deviations with documented corrective actions. This is not a one-time commissioning activity. Equipment performance drifts, procedures erode, staff change, and third parties rotate tools. Your program needs a testing loop that survives all of that.

This page gives requirement-level implementation guidance: who owns it, what to test, how to test, what evidence to keep, what auditors ask, and a practical execution plan you can run without guessing.

Regulatory text

Text: “Test sanitization equipment and procedures {{ insert: param, mp-6.2_prm_1 }} to ensure that the intended sanitization is being achieved.” ¹

What the operator must do:

• You must validate effectiveness, not just perform sanitization. The requirement is satisfied by tests that demonstrate your method achieves the intended sanitization result for the equipment and procedures you rely on. ¹
• The placeholder parameter in the excerpt typically represents organization-defined frequency/conditions for testing. Your job is to define those conditions in your standard, then execute and evidence them consistently. ¹

Plain-English interpretation (what MP-6(2) is really asking)

MP-6(2): equipment testing requirement expects proof that:

1. your sanitization tools function correctly (for example, wiping software runs and completes as expected, a degausser operates within its operating parameters, or a shredder meets your destruction intent), and
2. your people and third parties follow the procedure correctly (right method for the right media, right settings, right documentation, right handling chain).

Assessors look for a closed loop: test → record results → remediate failures → retest → update procedures/training if needed.

Who it applies to (entity and operational context)

This requirement commonly applies where NIST SP 800-53 is used, including:

• Federal information systems and the teams operating them (IT Ops, Security, Asset Management, Data Center Ops). ²
• Contractor systems handling federal data, including environments where a third party performs storage, repair, disposal, ITAD, or managed services that touch media containing federal information. ²

Operationally, MP-6(2) applies anywhere you sanitize media, such as: end-user devices, data center storage, removable media, network devices with storage, and any return-to-lessor/return-to-vendor workflows. It also applies when sanitization is outsourced; your obligation becomes “test and verify” through third-party due diligence plus your own validation activities.

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

Step 1: Define scope and “intended sanitization” targets

Create a one-page scope statement that answers:

• What media types exist in your environment (SSD, HDD, tapes, mobile devices, removable drives, embedded storage)?
• What sanitization outcomes you claim (clear, purge, destroy) and where those are required (by data classification, system boundary, contract requirement).
  Document this in your media sanitization standard and reference MP-6(2) as the testing driver. ¹

Step 2: Inventory sanitization equipment and procedures (including third parties)

Build and maintain:

• An equipment register (model, serial, location, owner, maintenance status, calibration/servicing details if applicable).
• A procedure register (SOP versions, work instructions, forms/checklists).
• A third-party register for any ITAD, shredding, repair depots, cloud/hosting providers, or managed services that sanitize on your behalf.

Your goal: every sanitization event traces back to an approved tool and an approved procedure version.

Step 3: Design a testing protocol with pass/fail criteria

Write a Sanitization Testing Plan that includes:

• What you test (equipment, software configurations, operator procedure steps, chain-of-custody checkpoints).
• How you test (functional tests, sample-based verification, negative/exception testing, witness checks).
• What “pass” means (objective criteria, not “completed successfully”).
• What triggers retesting (equipment servicing, software updates, SOP change, incident/near miss, new third party).

Keep the protocol simple enough that it will be followed and repeatable enough that results can be compared over time.

Step 4: Execute tests and capture objective results

Run tests according to your plan and record:

• Date/time, tester, tool identifier, procedure version, media type, method used, result, and any anomalies.
• For third parties, obtain their test records or certificates and reconcile them to your chain-of-custody records.

If your program includes automated wipe tools, preserve system-generated logs and map them to asset identifiers. If physical destruction is used, preserve destruction records tied to asset lists and transport custody.

Step 5: Manage failures with documented corrective action

Define what constitutes a failure: incomplete wipe, tool malfunction, missing logs, misapplied method, broken custody, or undocumented exception.
Then require:

• documented containment (quarantine media, stop using equipment if needed),
• root-cause analysis,
• corrective action (repair, recalibration, software fix, SOP update, retraining), and
• retesting evidence.

Assessors commonly treat “no documented corrective action” as “testing didn’t happen in a meaningful way.”

Step 6: Make it assessable (control mapping + recurring evidence)

Operationalize MP-6(2) in your GRC system as a control with:

• a named owner,
• a procedure link,
• a testing cadence/trigger definition, and
• a recurring evidence request list.

Daydream-style control mapping (owner + procedure + recurring artifacts) is the fastest way to prevent the most common gap: missing evidence at audit time. ¹

Required evidence and artifacts to retain

Aim for “show me” evidence that stands alone without oral explanation:

Core artifacts

• Media Sanitization Policy/Standard (with defined testing frequency/conditions) ¹
• Sanitization SOPs/work instructions, version-controlled
• Sanitization Testing Plan with pass/fail criteria
• Sanitization equipment inventory/register
• Test execution records (tickets, checklists, lab notes)
• Automated tool logs mapped to asset IDs
• Corrective action records and retest evidence
• Third-party documentation (certificates of destruction, testing attestations) plus your review/acceptance record

Nice-to-have artifacts that reduce examiner friction

• Training completion records for staff who run sanitization equipment
• Exception approvals (with compensating controls and final disposition)
• Internal audit/QA review notes of sanitization testing

Common exam/audit questions and hangups

Expect these questions and pre-build answers with evidence:

• “How do you know this wipe/degauss/shred method worked?” Show test protocol + test results tied to equipment and procedure. ¹
• “What triggers retesting?” Point to documented triggers (maintenance, updates, SOP changes, incidents).
• “How do you validate third-party sanitization?” Provide contracts/SOW clauses plus received evidence and your review trail.
• “Can you trace a sanitized asset from inventory to final disposition?” Demonstrate asset ID continuity, including chain-of-custody.
• “Where is the evidence for the last period?” Have a single evidence folder/report for the assessment window, not scattered tickets.

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails MP-6(2)	Avoid it by
Treating “sanitized” as a checkbox in the asset system	MP-6(2) requires testing to confirm intended sanitization, not a status field	Require logs/test records attached to each batch/event
Testing tools but not procedures	Operator error is a common failure mode; MP-6(2) includes procedures	Add witnessed runs, checklist adherence checks, and exception handling tests
Relying on a third party’s certificate alone	Certificates may not show method suitability for your data/media	Contract for method disclosure + sampling/spot checks + custody reconciliation
No defined retest triggers	Equipment and software changes invalidate assumptions	Tie retest to maintenance, firmware/software updates, or SOP changes
Evidence exists but cannot be linked to assets	Assessors need traceability	Use asset IDs in logs, tickets, and destruction manifests

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 enforcement outcomes.

Risk-wise, MP-6(2) is a control that prevents two categories of failure:

• data remanence exposure (media leaves your control with recoverable data), and
• audit failure (you cannot prove sanitization effectiveness even if you believe it happened).
  Both risks increase when sanitization is decentralized across teams or delegated to third parties without a verification loop. ¹

A practical 30/60/90-day execution plan

First 30 days (stand up the control so it can run)

• Assign a control owner and backup owner for MP-6(2), with clear scope boundaries.
• Draft or update the Sanitization Testing Plan and define pass/fail criteria. ¹
• Build the equipment and procedure registers.
• Identify third parties that sanitize media and collect current artifacts (certificates, process descriptions, logs, or attestations).

Day 31–60 (execute first testing cycle and fix obvious gaps)

• Run an initial set of tests across each sanitization method you use (software wipe, degauss, destruction).
• Verify traceability: pick a small sample of recent assets and prove end-to-end mapping from inventory to sanitization evidence to disposition record.
• Open corrective actions for any missing logs, unclear procedures, or equipment maintenance issues; document retesting after remediation.

Day 61–90 (stabilize and make it audit-ready)

• Operationalize recurring evidence collection in your GRC workflow (scheduled tasks, ticket templates, evidence folder structure).
• Add MP-6(2) testing checks into onboarding for new equipment, new wipe software versions, and new third parties.
• Run a lightweight internal QA review: confirm evidence completeness, sign-offs, and that the testing cadence/trigger definition is followed.

If you want this to stay “green” without heroics, configure Daydream (or your GRC system) so MP-6(2) always has a named owner, a linked procedure, and a standing evidence request package that matches your testing plan. ¹

Frequently Asked Questions

Do we have to test every single sanitized drive?

MP-6(2) requires testing to ensure intended sanitization is achieved, but it does not prescribe a specific sampling rate in the provided text. Define a defensible testing approach in your plan, then apply it consistently with traceable evidence. ¹

Does MP-6(2) apply if sanitization is performed by an ITAD third party?

Yes in practice, because you still need assurance the intended sanitization is achieved. Operationalize this through contract requirements, third-party evidence collection, and your own validation steps tied to custody and asset records. ²

What counts as “equipment” under MP-6(2)?

Treat any tool that performs or enables sanitization as equipment, including degaussers, shredders, and wipe stations or appliances. If a procedure depends on it to achieve sanitization, include it in the equipment register and testing plan. ¹

We only use software wiping. Do we still need MP-6(2) testing?

Yes. Testing applies to the wiping tool configuration and to the procedure operators follow, including log review, exception handling, and verification that the wipe completed successfully for the intended method. ¹

What evidence do auditors usually reject?

The most common weak evidence is a generic “certificate” or a spreadsheet status with no linkage to equipment identifiers, procedure versions, or system-generated logs. Keep artifacts that show what method ran, on what asset, with what result, and who reviewed it. ¹

How do we handle equipment repairs or software updates?

Treat them as retest triggers. Document the change, run the defined validation test, and retain the before/after evidence so you can show continued effectiveness across the change event. ¹

Footnotes

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

2. NIST SP 800-53 Rev. 5