MP-7(2): Prohibit Use of Sanitization-resistant Media

To meet the mp-7(2): prohibit use of sanitization-resistant media requirement, you must block or strictly prevent media types that cannot be reliably sanitized from being introduced or used in your systems, and prove that prohibition through technical controls, procurement controls, and operational checks. Treat this as a design and operations requirement, not a disposal procedure. ¹

Key takeaways:

• Define “sanitization-resistant media” for your environment, then ban it through policy, procurement, and endpoint controls.
• Enforce the prohibition with device control tooling, removable media controls, and exception handling tied to risk acceptance.
• Keep audit-ready evidence: approved media list, technical enforcement configs, detection logs, and exception records.

MP-7(2) sits inside the NIST SP 800-53 Media Protection family and is easy to misunderstand. Many teams read “sanitization” and jump straight to wipe procedures and destruction certificates. MP-7(2) is earlier in the lifecycle: it requires you to prohibit the use of media that you cannot sanitize reliably, because if you cannot sanitize it, you cannot safely repurpose it, return it, or dispose of it without increasing data exposure risk. ¹

For a CCO, GRC lead, or Compliance Officer supporting federal systems or contractor systems handling federal data, MP-7(2) becomes operational very quickly: endpoint engineering needs clear device control rules; procurement needs “do-not-buy” constraints; asset management needs an allowlist; and IT operations needs a way to detect and respond when prohibited media appears. ²

This page gives requirement-level implementation guidance you can put into motion immediately: what to ban, where bans break down in real environments, how to handle legitimate edge cases (lab gear, industrial systems, field data collection), and what evidence auditors expect to see when they test the control.

Regulatory text

Requirement (verbatim): “Prohibit the use of sanitization-resistant media in organizational systems.” ¹

Operator interpretation: You must prevent media that cannot be reliably sanitized from being used with organizational systems. In practice, this means you (1) define which media types are “sanitization-resistant” for your organization, (2) implement technical and administrative controls so those media types are not introduced, and (3) maintain evidence that the prohibition is operating.

Plain-English interpretation (what this really means)

“Sanitization-resistant media” is media where you cannot confidently remove data using your approved sanitization methods. If you allow it into endpoints, servers, or specialized equipment, you risk data remnants persisting after “wiping,” which turns routine operations (repurpose, ship to repair, return to lessor, decommission) into a data exposure event.

MP-7(2) is satisfied when:

• Your organization has a clear prohibition statement (policy/standard).
• Your environment prevents or detects prohibited media at the points where it would be introduced (purchase, receiving, endpoint ports, imaging benches, labs).
• Exceptions are rare, time-bound, and supported by compensating controls.

Who it applies to

Entity types

• Federal information systems and the teams that manage them. ²
• Contractor systems handling federal data (including cloud, on-prem, and hybrid environments supporting federal workloads). ²

Operational contexts where MP-7(2) commonly matters

• End-user computing fleets where removable media appears (USB drives, SD cards).
• Data centers and build rooms where drives are staged, reimaged, and repurposed.
• Field operations that ingest data from cameras, sensors, or test equipment.
• Third-party repair/RMA flows and leased equipment returns.
• OT/ICS and lab environments with niche media formats.

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

Step 1: Define “sanitization-resistant” for your organization

Create a short standard (one page is fine) that answers:

• What sanitization methods are approved in your environment?
• Which media types are considered sanitization-resistant because they cannot be sanitized with those methods or cannot provide verifiable sanitization outcomes?

Practical scoping tip: Don’t try to classify every device on earth. Start by classifying what your teams actually touch: removable media types, drive types used in endpoints/servers, and any specialized media used by labs/OT.

Step 2: Publish an explicit prohibition and an allowlist

Write an enforceable rule:

• Prohibited: media types you designate as sanitization-resistant.
• Allowed: approved media types and models (or approved classes) that your org can sanitize and verify.
• Conditionally allowed: special-purpose media permitted only under an approved exception.

Make the prohibition appear in three places operators will follow:

1. Security policy or media handling standard
2. Endpoint/hardening standard (what controls must be configured)
3. Procurement standard (what purchasing must block)

Step 3: Implement procurement and receiving controls (stop it at the door)

Operationalize the ban before the device hits your network:

• Add prohibited media to purchasing catalogs as “blocked” items.
• Require procurement to buy only from an approved list (models that are sanitizable under your methods).
• Add a receiving check for IT stockrooms: quarantine nonstandard media until security approves it.

Third-party angle: If a third party provides appliances or embedded systems with internal storage, require disclosure of storage media type and sanitization approach in onboarding questionnaires and contract terms. The risk shows up when you later RMA the device or return it at end-of-life.

Step 4: Enforce technically on endpoints and servers

Auditors will expect more than “policy says don’t.” Implement at least one of:

• Device control to block unauthorized USB mass storage classes.
• Removable media restrictions via endpoint management (allowlist by device ID/vendor/product).
• DLP or EDR rules to alert when new removable media mounts.

Minimum viable enforcement outcome: A standard user cannot connect unknown removable storage and write sensitive data to it without triggering a block or an alert that creates a ticket.

Step 5: Control “exception pathways” that bypass endpoint controls

Most failures occur where normal endpoint controls do not apply:

• Imaging benches and IT repair stations.
• Offline systems, jump kits, and emergency laptops.
• Lab instruments and OT workstations managed outside corporate MDM.
• Cloud import/export workflows that result in physical media shipment.

For each pathway, define a control:

• Dedicated, monitored transfer workstation with logging.
• Check-in/check-out process for removable media with labeling.
• Physical storage controls and chain-of-custody.
• Mandatory encryption for any permitted removable media.

Step 6: Create an exception process with compensating controls

MP-7(2) is a prohibition, but reality produces edge cases. Your exception workflow should require:

• Business justification and data classification.
• Time limit and scope (systems, users, locations).
• Compensating controls (encryption, custody, restricted ports, logging).
• Risk acceptance sign-off by the right authority.

Keep exceptions auditable. If exceptions become the norm, auditors will treat the “prohibition” as non-operational.

Step 7: Monitor, respond, and prove operations

Build a routine:

• Review device-control events and investigate prohibited media detections.
• Tie detections to incident handling or service management tickets.
• Periodically reconcile the approved media list to what’s actually observed in the environment.

Daydream fit (earned mention): Daydream can help you map MP-7(2) to a named control owner, a repeatable procedure, and a recurring evidence set so you can answer assessors with consistent artifacts instead of scrambling across IT, procurement, and security tooling. ¹

Required evidence and artifacts to retain

Keep evidence that demonstrates both design (you defined and implemented the prohibition) and operation (it’s working).

Policy and governance

• Media protection standard with explicit prohibition language for sanitization-resistant media.
• Definition document: what your org considers sanitization-resistant and why.
• Approved media allowlist and prohibited media list with version history.
• Exception register with approvals and expirations.

Technical configuration evidence

• Endpoint management policies (screenshots/exports) showing removable media controls.
• Device control allowlist/denylist configuration exports.
• Sample logs showing blocked/alerted insertion attempts and follow-up tickets.

Procurement and third-party evidence

• Procurement controls (catalog restrictions, purchasing SOP).
• Contract clauses or third-party requirements for storage media disclosure and end-of-life handling where applicable.
• Receiving/stockroom SOP and quarantine records (if you operate central IT receiving).

Operational records

• Periodic review notes (meeting minutes or tickets) showing monitoring and remediation.
• Training or communications sent to IT admins and support desks about the prohibited media list.

Common exam/audit questions and hangups

Expect assessors to probe these points:

1. “Define sanitization-resistant.” If your definition is vague, the control becomes untestable.
2. “Show me how you prevent it.” Policy-only answers usually fail. Provide technical enforcement proof.
3. “Where can prohibited media still enter?” Build rooms, labs, OT, and incident response kits are common gaps.
4. “How do you handle exceptions?” Auditors look for approval, compensating controls, and expiry.
5. “Show me evidence it’s operating.” Provide logs and tickets, not just screenshots of settings.

Frequent implementation mistakes (and how to avoid them)

• Mistake: Treating MP-7(2) as disposal-only. Fix: implement “no entry” controls (procurement + endpoint) and document them.
• Mistake: No authoritative list. Fix: publish an allowlist/prohibited list with ownership (Security/ITAM) and a change process.
• Mistake: Blocking USB broadly but ignoring other media. Fix: map all media pathways in your environment (SD, microSD, external drives, embedded storage in appliances, data export media in specialized systems).
• Mistake: Exceptions via email and chat. Fix: require ticketed approvals with time bounds and compensating controls.
• Mistake: Lab/OT carved out permanently. Fix: treat lab/OT as a separate boundary with its own enforcement and evidence, not a permanent waiver.

Enforcement context and risk implications

No public enforcement cases were provided in the source material for this requirement, so you should treat MP-7(2) as an assessment-driven requirement: failure typically shows up as audit findings, authorization delays, or security assessment POA&Ms rather than a named enforcement action. ¹

Operational risk is still real:

• Data remanence risk: data persists on media you believed was sanitized.
• Supply chain risk: third parties handling returns/repairs can access residual data.
• Incident expansion: a simple asset disposal mistake turns into reportable exposure.

Practical 30/60/90-day execution plan

First 30 days: Establish the prohibition and scope

• Name a control owner (usually Security with IT Ops and Procurement as stakeholders).
• Draft the sanitization-resistant media definition and the initial prohibited/approved list.
• Publish the prohibition in the media handling standard and endpoint standard.
• Identify your top bypass pathways (imaging benches, labs, OT, field kits) and assign owners.

By 60 days: Enforce the ban in the highest-risk pathways

• Implement removable media controls in endpoint management for corporate fleets.
• Add procurement blocks and receiving SOP for nonstandard media.
• Stand up an exception process with ticketing, approvers, and compensating control requirements.
• Start collecting operating evidence: alerts, blocks, and tickets.

By 90 days: Prove operations and close gaps

• Expand enforcement coverage to servers, admin workstations, and special environments.
• Run a targeted internal test: attempt to connect prohibited media and verify it is blocked/alerted and handled.
• Review exceptions, remove stale approvals, and tighten the allowlist.
• Package an “audit kit” for MP-7(2): policy, lists, configs, sample logs, and exception register.

Frequently Asked Questions

What counts as “sanitization-resistant media” under MP-7(2)?

NIST requires you to prohibit media you cannot reliably sanitize, but it does not publish a single universal list in the excerpt for MP-7(2). Define it for your environment based on your approved sanitization methods and your ability to verify outcomes. ¹

Is MP-7(2) satisfied if we require encryption on all removable media?

Encryption reduces exposure if media is lost, but it does not automatically satisfy a “prohibit use” requirement. If the media is still sanitization-resistant, you either block it or treat it as an exception with compensating controls and explicit approval. ¹

Do we have to block all USB storage to meet MP-7(2)?

No. You need to prohibit sanitization-resistant media, which can be accomplished with allowlisting approved devices, blocking unknown devices, or restricting to managed/encrypted media. The enforcement method matters less than your ability to prove the prohibition works. ¹

How do we handle labs or OT systems where removable media is operationally required?

Treat those as explicit exception pathways with their own controls: dedicated transfer stations, chain-of-custody, logging, and time-bound approvals. Document why normal endpoint controls don’t apply and what you do instead. ¹

What evidence is most persuasive to auditors for MP-7(2)?

A short prohibited/approved media standard plus technical enforcement exports and real logs tied to tickets. Auditors want to see the prohibition is implemented and operating, not just written. ¹

How does this relate to third parties that repair or dispose of our equipment?

If media cannot be sanitized reliably, repairs, RMAs, and disposal become higher risk because residual data may remain accessible outside your control. Address this by prohibiting the media type internally and requiring third-party handling terms where those workflows exist. ²

Footnotes

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

2. NIST SP 800-53 Rev. 5