{
  "title": "Step‑by‑Step Implementation Guide: Removing CUI Before Off‑Site Repairs — NIST SP 800-171 REV.2 / CMMC 2.0 Level 2 - Control - MA.L2-3.7.3",
  "date": "2026-04-19",
  "author": "Lakeridge Technologies",
  "featured_image": "/assets/images/blog/2026/4/stepbystep-implementation-guide-removing-cui-before-offsite-repairs-nist-sp-800-171-rev2-cmmc-20-level-2-control-mal2-373.jpg",
  "content": {
    "full_html": "<p>This post provides a practical, step‑by‑step implementation guide to satisfy NIST SP 800‑171 Rev.2 / CMMC 2.0 Level 2 Control MA.L2‑3.7.3 — ensuring Controlled Unclassified Information (CUI) is removed or protected prior to sending devices off‑site for repair, with actionable controls, technical commands, small‑business examples, and compliance documentation tips.</p>\n\n<h2>Scope and key objectives</h2>\n<p>The control MA.L2‑3.7.3 requires organizations to remove CUI from information systems or devices before those systems are transferred outside organizational control for maintenance or repair. Key objectives are: identify media that contains CUI; remove or render the CUI unreadable; document the process and evidence; and ensure any third‑party repair provider is contractually and operationally prevented from accessing residual data. For Compliance Framework implementations this maps directly into the System Security Plan (SSP), procedures, and audit evidence in your POA&M.</p>\n\n<h2>Why this matters — risks of not removing CUI</h2>\n<p>Failing to remove CUI before off‑site repair exposes you to data breach, loss of DoD contracts, monetary penalties, and reputational damage. A single laptop sent with CUI that is later accessed by a repair technician can lead to exfiltration of program data or personally identifiable information. Noncompliance also creates findings during supplier assessments and CMMC audits. From a threat perspective, off‑site repairs increase the attack surface: physical access by unknown personnel, insecure transport, and potential data recovery from residual media.</p>\n\n<h2>High‑level implementation approach</h2>\n<p>There are three defensible approaches: 1) Remove/erase the storage media containing CUI before shipping (preferred); 2) Use cryptographic protections and key destruction (crypto‑erase) such that the data is unrecoverable; 3) Avoid off‑site repairs entirely by using on‑site repair, vendor on‑site service, or device swap (loaner program). Your choice should be driven by data classification, business continuity needs, and cost. Document the chosen approach in the SSP and create procedure templates for each path.</p>\n\n<h3>Practical step‑by‑step checklist (operations & technical)</h3>\n<p>Step 1 — Identify CUI on device: use asset inventory and data discovery (e.g., indexed shares, desktop, and known application stores) to confirm presence of CUI. Step 2 — Back up any business‑required data to an approved secure repository (encrypted backup with access controls) and verify integrity. Step 3 — Decide removal method (reimage, sanitize, remove media, or cryptographic erase) and obtain sign‑off. Step 4 — Execute sanitization with documented tooling and capture evidence (screenshots, hashes, serials). Step 5 — Produce a chain‑of‑custody form and tamper‑evident packaging for shipping. Step 6 — Require vendor acceptance, NDA, and attestations before release; on return, validate device integrity before recommissioning.</p>\n\n<h3>Technical implementation details and example commands</h3>\n<p>Use NIST SP 800‑88 Rev.1 media sanitization categories: Clear (logical overwrite), Purge (cryptographic or vendor secure erase), Destroy (physical). For HDDs: a secure erase via hdparm is common — e.g., <code>hdparm --user-master u --security-set-pass PASS /dev/sdX</code> followed by <code>hdparm --user-master u --security-erase PASS /dev/sdX</code>. For SSD/NVMe, use vendor utilities or <code>nvme format /dev/nvme0n1 -s 1</code> (cryptographic erase) or <code>blkdiscard /dev/sdX</code> where supported. For Windows systems, reimage with a known good golden image or use <code>diskpart</code> and <code>clean all</code> for full overwrite; for free‑space only: <code>cipher /w:C:</code>. For BitLocker‑encrypted drives, the quickest secure option is to remove encryption keys and perform a cryptographic erase or remove the drive before shipping — do not ship with keys accessible. Always validate with a post‑sanitization verification step: check partition table, run <code>dd if=/dev/sdX bs=1M count=10 | hexdump -C</code> (Linux) to review that the drive contains zeros or random data depending on the method.</p>\n\n<h3>Vendor controls, contractual language, and chain‑of‑custody</h3>\n<p>Small businesses should adopt strong vendor selection and contract controls: require the repair vendor to maintain written procedures for CUI, background checks for technicians, a SOC 2 or equivalent attestation where available, restricted access areas, and a specific clause that technicians cannot access customer data. Example contract clause: \"Vendor shall not access, copy, retain, or disclose any CUI on devices sent for repair; vendor will return device sealed with tamper‑evident packaging and provide written certification of media sanitization where relevant.\" Maintain a chain‑of‑custody form that records device serial number, IMEI, shipper, tracking number, seal ID, point of contact, and signatures at handover points. Keep scanned copies in your compliance evidence store.</p>\n\n<h2>Small business scenarios and practical tradeoffs</h2>\n<p>Example A — Two‑person engineering firm: a laptop with CUI needs a failed keyboard repaired. Low cost option: remove the SSD and send only the device (or send a loaner), or physically replace keyboard on‑site with an external technician. Example B — Small defense subcontractor with several assets: implement a loaner pool and a centralized reimaging workstation — when an asset is returned from repair, wipe and reimage from a golden image and validate with checksums. Tradeoffs: removing drives increases logistic complexity but gives strongest protection; using on‑site repair or loaners increases operational cost but reduces risk and audit burden.</p>\n\n<h2>Compliance tips and best practices</h2>\n<p>Maintain these artifacts for audits: SSP text mapping MA.L2‑3.7.3, sanitization procedures, sanitized drive verification evidence (hashes or screenshots), signed chain‑of‑custody records, vendor attestations/NDAs, and training logs showing staff can follow the procedure. Train helpdesk and asset custodians on the checklist. Automate where possible: use ticketing workflows that require sanitization checkbox and attach artifacts before status changes to \"released to vendor.\" Maintain a POA&M for exceptions (for instance, urgent repairs requiring on‑site vendor with documented compensating controls).</p>\n\n<p>In summary, MA.L2‑3.7.3 is straightforward in intent but requires practical processes, technical controls, and vendor governance to implement effectively. For small businesses the lowest friction, highest assurance solutions are (in order): remove media before shipping, use on‑site/vendor‑on‑site repairs or loaners, or cryptographically render data inaccessible and document the steps thoroughly. Combine technical sanitization (per NIST SP 800‑88), clear SOPs, chain‑of‑custody records, and contractual vendor controls to meet NIST SP 800‑171/CMMC expectations and reduce the real business risk of CUI exposure.</p>",
    "plain_text": "This post provides a practical, step‑by‑step implementation guide to satisfy NIST SP 800‑171 Rev.2 / CMMC 2.0 Level 2 Control MA.L2‑3.7.3 — ensuring Controlled Unclassified Information (CUI) is removed or protected prior to sending devices off‑site for repair, with actionable controls, technical commands, small‑business examples, and compliance documentation tips.\n\nScope and key objectives\nThe control MA.L2‑3.7.3 requires organizations to remove CUI from information systems or devices before those systems are transferred outside organizational control for maintenance or repair. Key objectives are: identify media that contains CUI; remove or render the CUI unreadable; document the process and evidence; and ensure any third‑party repair provider is contractually and operationally prevented from accessing residual data. For Compliance Framework implementations this maps directly into the System Security Plan (SSP), procedures, and audit evidence in your POA&M.\n\nWhy this matters — risks of not removing CUI\nFailing to remove CUI before off‑site repair exposes you to data breach, loss of DoD contracts, monetary penalties, and reputational damage. A single laptop sent with CUI that is later accessed by a repair technician can lead to exfiltration of program data or personally identifiable information. Noncompliance also creates findings during supplier assessments and CMMC audits. From a threat perspective, off‑site repairs increase the attack surface: physical access by unknown personnel, insecure transport, and potential data recovery from residual media.\n\nHigh‑level implementation approach\nThere are three defensible approaches: 1) Remove/erase the storage media containing CUI before shipping (preferred); 2) Use cryptographic protections and key destruction (crypto‑erase) such that the data is unrecoverable; 3) Avoid off‑site repairs entirely by using on‑site repair, vendor on‑site service, or device swap (loaner program). Your choice should be driven by data classification, business continuity needs, and cost. Document the chosen approach in the SSP and create procedure templates for each path.\n\nPractical step‑by‑step checklist (operations & technical)\nStep 1 — Identify CUI on device: use asset inventory and data discovery (e.g., indexed shares, desktop, and known application stores) to confirm presence of CUI. Step 2 — Back up any business‑required data to an approved secure repository (encrypted backup with access controls) and verify integrity. Step 3 — Decide removal method (reimage, sanitize, remove media, or cryptographic erase) and obtain sign‑off. Step 4 — Execute sanitization with documented tooling and capture evidence (screenshots, hashes, serials). Step 5 — Produce a chain‑of‑custody form and tamper‑evident packaging for shipping. Step 6 — Require vendor acceptance, NDA, and attestations before release; on return, validate device integrity before recommissioning.\n\nTechnical implementation details and example commands\nUse NIST SP 800‑88 Rev.1 media sanitization categories: Clear (logical overwrite), Purge (cryptographic or vendor secure erase), Destroy (physical). For HDDs: a secure erase via hdparm is common — e.g., hdparm --user-master u --security-set-pass PASS /dev/sdX followed by hdparm --user-master u --security-erase PASS /dev/sdX. For SSD/NVMe, use vendor utilities or nvme format /dev/nvme0n1 -s 1 (cryptographic erase) or blkdiscard /dev/sdX where supported. For Windows systems, reimage with a known good golden image or use diskpart and clean all for full overwrite; for free‑space only: cipher /w:C:. For BitLocker‑encrypted drives, the quickest secure option is to remove encryption keys and perform a cryptographic erase or remove the drive before shipping — do not ship with keys accessible. Always validate with a post‑sanitization verification step: check partition table, run dd if=/dev/sdX bs=1M count=10 | hexdump -C (Linux) to review that the drive contains zeros or random data depending on the method.\n\nVendor controls, contractual language, and chain‑of‑custody\nSmall businesses should adopt strong vendor selection and contract controls: require the repair vendor to maintain written procedures for CUI, background checks for technicians, a SOC 2 or equivalent attestation where available, restricted access areas, and a specific clause that technicians cannot access customer data. Example contract clause: \"Vendor shall not access, copy, retain, or disclose any CUI on devices sent for repair; vendor will return device sealed with tamper‑evident packaging and provide written certification of media sanitization where relevant.\" Maintain a chain‑of‑custody form that records device serial number, IMEI, shipper, tracking number, seal ID, point of contact, and signatures at handover points. Keep scanned copies in your compliance evidence store.\n\nSmall business scenarios and practical tradeoffs\nExample A — Two‑person engineering firm: a laptop with CUI needs a failed keyboard repaired. Low cost option: remove the SSD and send only the device (or send a loaner), or physically replace keyboard on‑site with an external technician. Example B — Small defense subcontractor with several assets: implement a loaner pool and a centralized reimaging workstation — when an asset is returned from repair, wipe and reimage from a golden image and validate with checksums. Tradeoffs: removing drives increases logistic complexity but gives strongest protection; using on‑site repair or loaners increases operational cost but reduces risk and audit burden.\n\nCompliance tips and best practices\nMaintain these artifacts for audits: SSP text mapping MA.L2‑3.7.3, sanitization procedures, sanitized drive verification evidence (hashes or screenshots), signed chain‑of‑custody records, vendor attestations/NDAs, and training logs showing staff can follow the procedure. Train helpdesk and asset custodians on the checklist. Automate where possible: use ticketing workflows that require sanitization checkbox and attach artifacts before status changes to \"released to vendor.\" Maintain a POA&M for exceptions (for instance, urgent repairs requiring on‑site vendor with documented compensating controls).\n\nIn summary, MA.L2‑3.7.3 is straightforward in intent but requires practical processes, technical controls, and vendor governance to implement effectively. For small businesses the lowest friction, highest assurance solutions are (in order): remove media before shipping, use on‑site/vendor‑on‑site repairs or loaners, or cryptographically render data inaccessible and document the steps thoroughly. Combine technical sanitization (per NIST SP 800‑88), clear SOPs, chain‑of‑custody records, and contractual vendor controls to meet NIST SP 800‑171/CMMC expectations and reduce the real business risk of CUI exposure."
  },
  "metadata": {
    "description": "Practical, step‑by‑step guidance for small organizations to remove Controlled Unclassified Information (CUI) before sending equipment off‑site to satisfy NIST SP 800‑171 / CMMC 2.0 MA.L2‑3.7.3.",
    "permalink": "/stepbystep-implementation-guide-removing-cui-before-offsite-repairs-nist-sp-800-171-rev2-cmmc-20-level-2-control-mal2-373.json",
    "categories": [],
    "tags": []
  }
}