CMMC Level 2 Practice 3.8.3: Sanitize or destroy system media containing CUI before disposal or release for reuse
CMMC Level 2 Practice 3.8.3 requires you to sanitize or destroy any system media that contains CUI before you dispose of it or release it for reuse. To operationalize it fast, define “media” in scope, standardize approved sanitization and destruction methods by media type, and retain verifiable records (chain of custody, method used, and authorization) for every disposition event. 1
Key takeaways:
- Treat media disposition as a controlled workflow, not an ad hoc IT task, because assessors will test repeatability and evidence. 2
- Match sanitization/destruction method to media type and reuse scenario, then document the decision and outcome each time. 1
- Evidence is the usual failure point; build recurring evidence capture into tickets, asset records, and third-party destruction certificates. 3
For CMMC Level 2, media sanitization is one of the fastest ways to create real risk if it’s inconsistent. Old drives in a drawer, returned laptops to a leasing company, decommissioned servers, defective SSDs shipped back under warranty, and “reassigned” USB storage are all common failure paths. Practice 3.8.3 draws a clear line: if the media contains CUI, you must sanitize it or destroy it before disposal or release for reuse. 1
Operationally, this requirement is less about buying a shredder and more about controlling decisions: what counts as “system media,” how you determine whether it contains CUI, which methods are approved for each media type, who can authorize release, and what proof you keep. CMMC assessors will not accept “we always wipe drives” without records that tie specific assets to a method and outcome. 2
This page gives requirement-level, step-by-step implementation guidance you can hand to IT, Security, and Asset Management to stand up an auditable workflow for the target keyword: cmmc level 2 practice 3.8.3: sanitize or destroy system media containing cui before disposal or release for reuse requirement. 1
Regulatory text
Requirement (mapped): “Sanitize or destroy system media containing CUI before disposal or release for reuse.” 1
Operator interpretation:
You must prevent CUI from leaving your control on any storage medium. Before you (a) dispose of media or (b) release it for reuse (internally or externally), you must either:
- Sanitize it using an approved method appropriate to the media type, or
- Destroy it so data cannot be recovered. 1
What the assessor looks for: a defined process, consistently followed, with objective evidence for a sample of media disposition events in the assessment period. 2
Plain-English requirement interpretation
If a device can store CUI, you treat it as sensitive during end-of-life and reassignment. The requirement triggers at two moments:
- Disposal: discarding, recycling, scrapping, donating, or returning equipment.
- Release for reuse: reassigning to another user, repurposing a system, returning a loaner, sending hardware for repair, or returning leased assets. 1
Sanitization is acceptable only if it reliably removes CUI for the intended next use. Destruction is acceptable when you cannot validate sanitization or the media is too risky (damaged drives, unknown history, failed encryption states).
Who it applies to
Entities
- Defense contractors and subcontractors handling CUI in scope for CMMC Level 2. 3
- Other federal contractors handling CUI where NIST SP 800-171 Rev. 2 is contractually required. 1
Operational context and assets in scope
Include any system media that may store CUI, such as:
- End-user endpoints (laptops/desktops) with internal drives
- Servers, storage arrays, NAS/SAN components
- Removable media (USB drives, external HDD/SSD, memory cards)
- Mobile devices with persistent storage
- Virtualized or cloud-adjacent components where you control the underlying media disposition (for example, on-prem hypervisors and their disks) 1
Also include “non-obvious” media:
- Multifunction printers/copiers with internal storage
- Network equipment with logs/config backups stored locally
- Embedded/IoT devices with flash storage
What you actually need to do (step-by-step)
1) Define and publish your media disposition standard
Create a short standard (or SOP) that states:
- What qualifies as system media in your environment
- What “containing CUI” means in practice (for example, any asset in the CUI enclave, any endpoint authorized for CUI, any device that processed CUI, or any media labeled as CUI)
- Approved sanitization vs destruction methods by media type
- Required approvals and evidence for each disposition path 1
2) Build a decision matrix: sanitize vs destroy
Use a simple decision table you can embed in a ticket template:
| Scenario | Media condition | Next state | Required action |
|---|---|---|---|
| Internal reassignment within same CUI boundary | Working | Reuse | Sanitize per standard; record verification |
| Reuse outside CUI boundary | Working | Reuse | Prefer destroy; if sanitize, require stronger validation and documented approval |
| RMA/repair to manufacturer or third party | Any | Release externally | Destroy if feasible; if not, sanitize with documented justification and chain of custody |
| Disposal/recycling | Any | Disposal | Destroy or sanitize then release to recycler with certificate/receipt |
| Drive failure / cannot complete wipe | Not working | Disposal/RMA | Destroy and record exception handling |
Keep the matrix tight and enforce it through workflow gates. 2
3) Centralize disposition through a controlled workflow
Make media disposition a ticketed process with required fields:
- Asset ID / serial number
- Owner / system / location
- CUI exposure basis (why you treat it as containing CUI)
- Selected method (sanitize/destroy), tool or service used, operator
- Date/time, approvals, and final disposition (scrap, recycle, RMA, redeploy) 1
Practical move: block ad hoc disposal by policy. If Facilities or IT “just tosses it,” you will not pass sampling.
4) Implement approved sanitization methods and verification
Your standard must specify:
- Which tools/processes are approved for each OS and media type
- What “success” looks like (tool logs, completion code, or cryptographic erase confirmation)
- What to do when sanitization fails (escalate to destruction, document exception)
Verification is the difference between “we ran a wipe once” and “we can prove drives were sanitized.” Tie logs to serial numbers where possible. 1
5) Implement destruction with chain of custody
If you destroy in-house:
- Limit who can perform destruction
- Record serial numbers and method (shred, degauss, pulverize, etc.)
- Witness or dual-authorization for high-risk media, if your risk model requires it
If you use a third party:
- Treat the destruction provider as a third party in your supply chain
- Require certificates of destruction that list serial numbers or asset IDs
- Maintain pickup logs, transport controls, and receipt confirmation 2
6) Control releases: leasing, returns, repairs, and employee offboarding
Add checkpoints to processes that commonly “leak” media:
- ITAD/recycling pickups: nothing leaves without a ticket and inventory list.
- Lease returns: sanitize/destroy before shipment; store shipping and acceptance records.
- Warranty returns (RMA): if you cannot destroy the drive, sanitize first, document why, and preserve chain-of-custody details.
- Offboarding: reclaimed devices must be sanitized before reassignment, even if the user “didn’t store CUI locally.” Your stance should be based on system authorization and actual exposure, not user testimony. 1
7) Make evidence capture recurring and reviewable
You need a repeatable evidence package for every event. Daydream (as a GRC system of record) fits here when you want one place to map 3.8.3 to the workflow, require attachments, and generate assessor-ready exports without chasing spreadsheets. 2
Required evidence and artifacts to retain
Keep these artifacts in a form you can produce quickly:
- Media sanitization and destruction policy/standard approved by management 1
- Inventory of in-scope media (asset inventory) with identifiers
- Ticket or change record for each disposition/reuse event with:
- Asset ID/serial number
- Method used and outcome
- Approver
- Date/time and operator
- Tool logs or wipe reports mapped to specific media identifiers
- Certificates of destruction (third-party ITAD), pickup manifests, and receipts
- Exception records (failed wipe, damaged drive, emergency replacement) with compensating actions and final resolution 1
Common exam/audit questions and hangups
Expect assessors to probe these areas:
- Scope clarity: “Which media is considered to contain CUI, and how do you know?” 1
- Method appropriateness: “How do you decide between sanitize and destroy?” 1
- Repeatability: “Show me the last few media disposition events end-to-end.” 2
- External releases: “How do you handle RMAs and lease returns?” 1
- Evidence integrity: “Do certificates list serial numbers? Can you reconcile them to your asset inventory?” 2
Most hangups come from weak linkage between asset records and sanitization/destruction proof.
Frequent implementation mistakes and how to avoid them
-
Mistake: Treating encryption as an automatic pass without documenting the disposition method.
Fix: Document the approved approach for encrypted media in your standard and keep proof of the action taken per asset. 1 -
Mistake: No control over “shadow disposal” by Facilities or local IT.
Fix: Require tickets and inventory reconciliation before any pickup or recycling. 2 -
Mistake: Certificates of destruction that don’t identify assets.
Fix: Contractually require serial/asset IDs on certificates or attached manifests. -
Mistake: RMAs ship with drives still installed.
Fix: Create a default rule: remove and destroy storage before shipment unless the business owner approves a documented exception. 1 -
Mistake: Inconsistent retention of wipe logs.
Fix: Standardize where logs go (ticket attachment + central repository) and add periodic checks.
Enforcement context and risk implications
No public enforcement cases were provided in the source catalog for this specific practice, so you should treat enforcement risk through the lens of contractual and assessment failure impact. CMMC Level 2 is implemented through DoD program requirements and assessment expectations, and gaps can affect award eligibility and ongoing contract performance requirements under the CMMC program structure. 4
Practically, the risk is straightforward: loss of CUI through improper disposal or reuse is hard to detect after the fact and creates incident response, contractual reporting, and reputational exposure.
Practical execution plan (30/60/90 days)
First 30 days (stabilize and stop uncontrolled releases)
- Publish an interim rule: no media leaves control without a disposition ticket and approval.
- Identify all disposition paths: ITAD, recycler, leasing company, OEM repair, internal redeployments.
- Draft the media sanitization/destruction SOP and decision matrix; socialize with IT, Security, Facilities, and Procurement. 1
By 60 days (standardize methods and evidence)
- Finalize approved methods by media type; align tool output/logging with asset identifiers.
- Update third-party contracts/SOWs for ITAD to require itemized certificates and chain-of-custody artifacts.
- Implement the ticket template and required attachments; train the teams that touch hardware returns and surplus. 2
By 90 days (prove operation and audit readiness)
- Run a sampling drill: pull a set of recent disposition events and confirm you can produce end-to-end evidence in one package.
- Close gaps: missing serial numbers, missing logs, unclear approvals, exception handling.
- Operationalize recurring reviews: reconcile asset inventory against disposition records and third-party manifests. Store mappings in Daydream so 3.8.3 evidence is consistently captured and exported for assessment. 2
Frequently Asked Questions
Does this apply only when we throw equipment away?
No. It also applies before you release media for reuse, including internal reassignment, lease returns, or shipping devices for repair. 1
What counts as “system media” for 3.8.3?
Treat any storage component that can hold CUI as in scope, including internal drives, removable media, and devices with onboard storage like printers or network appliances. Define your scope explicitly in your SOP. 1
Can we rely on a third-party ITAD provider’s certificate of destruction?
Yes, if the certificate and supporting manifest let you reconcile destroyed items to your asset inventory (serial numbers or asset IDs) and you retain chain-of-custody records. Build those requirements into the contract. 2
What if we must return a failed drive under warranty?
Treat it as an external release path. If you cannot destroy the drive, sanitize it using an approved method, document the exception rationale, and retain shipment and custody records. 1
How do assessors test this practice?
They typically sample recent media disposition and reuse events and ask you to show the workflow, approvals, and objective evidence that the specific media was sanitized or destroyed before it left control or was reassigned. 2
What’s the fastest way to fail 3.8.3 in an assessment?
Having a policy that says “we wipe drives” without records tying specific asset identifiers to wipe logs or destruction certificates, especially for lease returns, RMAs, and recycling pickups. 2
Footnotes
Frequently Asked Questions
Does this apply only when we throw equipment away?
No. It also applies before you release media for reuse, including internal reassignment, lease returns, or shipping devices for repair. (Source: NIST SP 800-171 Rev. 2)
What counts as “system media” for 3.8.3?
Treat any storage component that can hold CUI as in scope, including internal drives, removable media, and devices with onboard storage like printers or network appliances. Define your scope explicitly in your SOP. (Source: NIST SP 800-171 Rev. 2)
Can we rely on a third-party ITAD provider’s certificate of destruction?
Yes, if the certificate and supporting manifest let you reconcile destroyed items to your asset inventory (serial numbers or asset IDs) and you retain chain-of-custody records. Build those requirements into the contract. (Source: DoD CMMC Program Guidance)
What if we must return a failed drive under warranty?
Treat it as an external release path. If you cannot destroy the drive, sanitize it using an approved method, document the exception rationale, and retain shipment and custody records. (Source: NIST SP 800-171 Rev. 2)
How do assessors test this practice?
They typically sample recent media disposition and reuse events and ask you to show the workflow, approvals, and objective evidence that the specific media was sanitized or destroyed before it left control or was reassigned. (Source: DoD CMMC Program Guidance)
What’s the fastest way to fail 3.8.3 in an assessment?
Having a policy that says “we wipe drives” without records tying specific asset identifiers to wipe logs or destruction certificates, especially for lease returns, RMAs, and recycling pickups. (Source: DoD CMMC Program Guidance)
Operationalize this requirement
Map requirement text to controls, owners, evidence, and review workflows inside Daydream.
See Daydream