CMMC Level 2 Practice 3.7.3: Ensure equipment removed for off-site maintenance is sanitized of any CUI

To meet CMMC Level 2 Practice 3.7.3, you must ensure any equipment sent off-site for maintenance (laptops, servers, drives, MFDs, phones, removable media) is sanitized so it contains no CUI before it leaves your control. Operationalize this with a controlled “remove-for-service” workflow: identify CUI-bearing components, sanitize or remove storage, document the method, and retain chain-of-custody evidence. (NIST SP 800-171 Rev. 2; DoD CMMC Program Guidance)

Key takeaways:

• Treat off-site maintenance as a data exfiltration path; block shipment until sanitization is verified and recorded.
• Build a repeatable workflow: asset identification → CUI determination → sanitize/remove media → approval → custody tracking → closure.
• Evidence wins assessments: tickets, sanitization logs, custody forms, and procedures mapped to 3.7.3.

cmmc level 2 practice 3.7.3: ensure equipment removed for off-site maintenance is sanitized of any cui requirement is a “simple sentence, hard in practice” control. Most failures come from operational gaps, not technology gaps: an IT tech ships a laptop to a depot, a copier vendor swaps a hard drive, or a third-party repair shop runs diagnostics on a system that still holds Controlled Unclassified Information (CUI).

CMMC Level 2 aligns to NIST SP 800-171 Rev. 2 practices, and 3.7.3 sits in the media protection family: don’t let CUI ride along with equipment leaving the facility. Your assessor will look for a defined process, consistent execution, and proof. That means you need to predefine what “sanitized” means in your environment, which assets are in scope, and how you prevent exceptions from becoming the norm.

This page gives requirement-level implementation guidance you can put into service quickly: who owns what, what steps must happen before a device leaves your control, what to collect as evidence, and the audit questions that typically expose weak spots. (NIST SP 800-171 Rev. 2; DoD CMMC Program Guidance; 32 CFR Part 170)

Regulatory text

Requirement (framework mapping): “CMMC Level 2 practice mapped to NIST SP 800-171 Rev. 2 requirement 3.7.3 (Ensure equipment removed for off-site maintenance is sanitized of any CUI).” (NIST SP 800-171 Rev. 2; DoD CMMC Program Guidance; 32 CFR Part 170)

Operator meaning: before equipment leaves your physical or logical control for maintenance, you must ensure it does not contain CUI. If sanitization is not feasible (for example, the device must remain intact for repair), you need an alternate path that still prevents CUI disclosure, such as removing storage media, using controlled service arrangements, or replacing the device rather than sending it out.

Plain-English interpretation

You cannot ship CUI to a repair shop by accident.

If a device might contain CUI, one of these must be true before it goes off-site:

1. the device is sanitized to remove CUI from all storage; or
2. all CUI-bearing components (usually storage media) are removed and retained; or
3. the maintenance occurs under conditions that keep CUI protected (for example, on-site service, escorted service, or controlled handling that preserves confidentiality).

This practice is about preventing disclosure during the maintenance lifecycle: shipping, depot intake, bench work, diagnostics, part swaps, and disposal. (NIST SP 800-171 Rev. 2)

Who it applies to

Entities

• Defense contractors and subcontractors handling CUI as part of DoD contracting obligations tied to CMMC Level 2. (32 CFR Part 170; DoD CMMC Program Guidance)

Operational context (where it bites)

• End-user computing: laptops/desktops sent to OEM or repair depot
• Data center gear: servers, storage arrays, network appliances with local storage
• Print/copy/scan: MFDs and printers with internal drives
• Mobile: phones/tablets with local storage
• Removable media: external drives, USBs, memory cards used for troubleshooting
• Field/OT equipment: controllers or test rigs with logging storage
• Returns/RMA flows managed by a third party

If your environment has a segmented CUI enclave, your boundary definition matters: devices used inside that enclave (or that can access CUI stores offline) are higher-risk and need stricter gating before shipment. (NIST SP 800-171 Rev. 2)

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

1) Define “off-site maintenance” and “equipment”

Write a short standard that clarifies in-scope events:

• Any device leaving your facilities (shipping, courier, employee carry-out for repair)
• Any third party taking custody, even temporarily
• Any component swap that moves storage media off-site

This prevents the common loophole: “We didn’t send the laptop off-site, we handed it to the vendor rep in our lobby.” If they take it away, it’s off-site. (NIST SP 800-171 Rev. 2)

2) Maintain an asset list with “CUI potential” tags

You need a reliable way to decide if a device could contain CUI:

• Tag devices assigned to CUI users/roles
• Tag devices that connect to the CUI enclave
• Tag device types that store data locally by default (MFDs, endpoints)
• Track storage media identifiers (drive serials where feasible)

Assessment reality: if you can’t show how you determine scope, you will struggle to prove sanitization is consistently applied. (DoD CMMC Program Guidance)

3) Create a “Remove for Service” workflow with hard stops

Implement a ticket type (ITSM works well) that must be opened before equipment leaves:

• Requestor enters asset ID, reason, destination, third party name
• System requires CUI determination (Yes/No/Unknown)
• If Yes/Unknown, require sanitization plan before approval
• Approval gates: IT + Security/Compliance (or delegated approver)

Hard stop control: shipping labels are not generated and the device is not released until the ticket includes sanitization evidence. This is where teams often add Daydream: it helps standardize required fields, required evidence attachments, and control mapping so every ticket produces assessment-ready artifacts without manual chasing. (DoD CMMC Program Guidance; NIST SP 800-171 Rev. 2)

4) Standardize sanitization methods by device type

Document acceptable methods for your environment and apply them consistently:

Endpoints (laptops/desktops)

• Preferred: cryptographic erase if full-disk encryption is in place and keys can be destroyed, or secure wipe then reimage (choose a method you can execute repeatably and evidence).
• If repair requires preserving the OS state: remove the drive and retain it; send a blank drive with the chassis if needed.

Servers / appliances with internal storage

• Remove drives/SSDs/NVMe modules before shipment when practical.
• If drives are soldered or removal is impractical, route to on-site service or replace unit.

MFDs/printers

• Treat internal storage as in scope; wipe via manufacturer procedures or remove/retain the drive before return/service.

Mobile devices

• Enterprise wipe and verify; if the device is non-functional, treat it as containing CUI and avoid off-site repair unless storage is removed or controlled handling exists.

Your policy does not need to name specific wipe standards to comply with 3.7.3, but it must define what your organization accepts as “sanitized,” how you verify it, and how you record it. (NIST SP 800-171 Rev. 2)

5) Add chain-of-custody controls for anything leaving your control

Minimum operational elements:

• Custody form or ticket log capturing who released the device, who received it, date/time, tracking number, destination
• Tamper-evident packaging for media when appropriate
• Restricted shipping methods and designated shippers
• For third parties: written handling requirements in contracts or service terms (for example, “no data access; return/replace media; notify of any loss”)

This practice is not only about wiping. If you cannot prove custody, an assessor may conclude the control is not effectively implemented. (DoD CMMC Program Guidance)

6) Verify and close the loop on return

On return from maintenance:

• Validate asset identity (serial number match)
• Confirm storage state (original drive returned? new drive installed? encryption present?)
• Reimage before reintroducing to CUI environment unless you have a controlled, documented rationale
• Close the ticket with final disposition: returned to service, decommissioned, destroyed, or retained as evidence

Required evidence and artifacts to retain

Keep evidence that shows both design (your rules) and operation (you follow them):

Design artifacts

• Policy/standard: off-site maintenance sanitization requirement mapped to 3.7.3 (NIST SP 800-171 Rev. 2)
• Procedures by device class (endpoint/server/MFD/mobile)
• Roles and approval matrix (who can authorize exceptions)

Operational artifacts

• Service tickets showing required fields completed (asset ID, CUI determination, destination, approver)
• Sanitization records (wipe logs, encryption key destruction record, reimage confirmation, drive removal record)
• Chain-of-custody/shipping records (tracking number, ship/receive dates)
• Third-party service documentation (RMA paperwork, service reports)
• Exception records with compensating controls and sign-off

Assessor-friendly tip: sample sets matter. Keep examples across different device types and different teams (helpdesk, data center, facilities/copier support). (DoD CMMC Program Guidance)

Common exam/audit questions and hangups

• “Show me the last few devices you shipped off-site and prove they were sanitized before shipment.”
• “How do you determine whether a device contains CUI?”
• “What happens if the device is broken and can’t be wiped?”
• “Do your copier/MFD returns follow the same process?”
• “Who can approve an exception, and where is that recorded?”
• “How do you prevent a technician from bypassing the workflow?”

Hangup to anticipate: teams can describe the process verbally, but cannot produce consistent records. That is a direct risk factor for 3.7.3 implementation evidence. (DoD CMMC Program Guidance; NIST SP 800-171 Rev. 2)

Frequent implementation mistakes and how to avoid them

1. Assuming encryption alone satisfies sanitization without a defined method.
   Fix: document when crypto-erase/key destruction is acceptable and how you prove it.

2. Ignoring “non-obvious” storage.
   Fix: include MFDs, network gear with flash, spare drives, and removable media in scope.

3. No hard stop before shipping.
   Fix: require a ticket and approval before shipping labels are created or devices leave the cage.

4. Drive swaps without tracking.
   Fix: record drive serials (or another unique identifier) at removal and confirm retention/destruction.

5. Third-party maintenance contracts silent on handling.
   Fix: add basic handling clauses and require the third party to return replaced storage or certify disposition.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this specific practice. Operationally, treat this as a preventable disclosure scenario: a lost shipment, a depot tech imaging a drive, or a returned device resold with data still present can trigger contractual, incident response, and reporting consequences under your DoD obligations. CMMC assessments will focus on whether your control is implemented and evidenced in day-to-day operations. (32 CFR Part 170; DoD CMMC Program Guidance)

Practical 30/60/90-day execution plan

First 30 days (stabilize)

• Name an owner (IT ops) and a control owner (GRC) for 3.7.3.
• Publish a one-page standard: “No off-site maintenance without sanitization or media removal.”
• Stand up the ticket workflow with mandatory fields and an approval gate.
• Identify high-risk asset classes: endpoints in the CUI environment, MFDs, server drives.

By 60 days (operationalize)

• Document device-type playbooks (wipe, crypto-erase, reimage, drive removal).
• Train helpdesk, desktop, data center, and facilities/copier coordinators.
• Update third-party service terms for common maintenance providers to address data handling and return of storage.
• Start monthly spot checks: pick recent RMAs and confirm evidence completeness.

By 90 days (harden and prove)

• Run an internal “mini-assessment” for 3.7.3: sample tickets, match to shipping logs, confirm sanitization proof.
• Close workflow gaps (missing MFDs, field gear, mobile).
• Automate evidence capture where possible (attach wipe logs automatically, template custody forms).
• If you use Daydream, map the workflow outputs directly to the 3.7.3 control record so your evidence stays assessment-ready without manual compilation. (DoD CMMC Program Guidance; NIST SP 800-171 Rev. 2)

Frequently Asked Questions

Does this apply if the equipment is only leaving for warranty repair and coming back?

Yes. The risk event is the period of third-party custody. If the device contains CUI, sanitize it (or remove storage) before it leaves, then document custody and closure. (NIST SP 800-171 Rev. 2)

What if the device is dead and cannot be wiped?

Treat it as containing CUI. Remove the storage media and retain it, or change the service approach (on-site service or replacement) so CUI does not leave your control. (NIST SP 800-171 Rev. 2)

Are copiers and MFDs really in scope?

If they store images or jobs internally, they can retain CUI. Include them in the off-site maintenance workflow and require wipe evidence or drive removal before return/service. (NIST SP 800-171 Rev. 2)

Can we rely on the third party to sanitize the equipment?

You can require safeguards contractually, but 3.7.3 expects you to ensure the equipment is sanitized before off-site maintenance. The cleanest assessment posture is to sanitize or remove storage before release, then keep proof. (NIST SP 800-171 Rev. 2; DoD CMMC Program Guidance)

What evidence is “enough” for an assessor?

You need artifacts that tie a specific asset to a specific maintenance event and show sanitization occurred before it left, plus custody/shipping records and approvals. Tickets with attachments are often the simplest package to present. (DoD CMMC Program Guidance)

How do we handle laptops that use full-disk encryption?

Define an approved method such as key destruction (crypto-erase) or wipe-and-reimage, and record what was done. Avoid informal “it’s encrypted, so it’s fine” statements without documented steps and evidence. (NIST SP 800-171 Rev. 2)