What MA.L2-3.7.3 equipment sanitization requires before off-site repair
Before a device that may hold CUI goes to a vendor for repair, a warranty swap or any other off-site maintenance, your organization must ensure that the equipment is sanitized of any CUI. That is the whole of MA.L2-3.7.3. The requirement is worth 1 point under the CMMC scoring methodology, yet it is a common finding because the assessment objective in NIST SP 800-171A is narrow and easy to fail in practice. An assessor checks one thing: whether equipment removed from organizational spaces for off-site maintenance is sanitized of any CUI. There is no partial credit for a policy that says the step should happen. The organization owns this control and the outcome. An implementation partner or consultant can help you design the process and collect records, but only the independent assessor decides whether the requirement is met.
Several things make this hard. Staff often do not know where CUI sits on a laptop, workstation, printer or storage array, especially when it has been copied into temporary folders, caches, backups or synced cloud clients. Drives fail, so a wipe command may not complete and the device may not be readable at all. Vendors frequently return equipment unchanged or with the original data intact, and some warranty processes replace a unit before anyone has checked what it contained. Each of these gaps can make the single objective unmet. Before you ship anything, confirm with your maintenance vendors which sanitization method they accept, whether they will return media or destroy it, and who signs for each item.
Plan the decision around the equipment, not the ticket. Identify which assets are likely to store CUI, choose clearing, purging or destruction for each class of media, and decide what happens when a drive cannot be sanitized (usually removal and retention or destruction on site). Keep a record for each item showing what was removed, the method used, who performed it, the date and the vendor. Assessors look for sanitization records and maintenance records as evidence, along with tests of the sanitization process itself. For the full method list and evidence expectations, see the CMMC Assessment Guide Level 2.
Which equipment and teams fall under equipment sanitization scope
Scope for MA.L2-3.7.3 follows the system security plan and the CUI boundary, not the asset register alone. The cards below cover the decisions that determine which equipment must be sanitized before it leaves organizational spaces, and which teams touch that equipment along the way. Confirm each device class against your own environment before you write the procedure.
Equipment that stores or processes CUI
Workstations, servers, laptops, and storage arrays that hold or process CUI are in scope when they leave organizational spaces for off-site maintenance. Network devices are in scope when their configuration files contain CUI, such as system details or security settings tied to the CUI environment. Check the system security plan for each device class and record which ones hold CUI at rest, in memory, or in configuration.
Printers, copiers, and test rigs
Multifunction printers and copiers with internal storage can retain scanned or printed CUI, and test rigs with attached drives or logs can hold CUI from test runs. These devices are often missed because they are managed by facilities or engineering rather than IT. Ask each owner whether the device has storage that persists after power-off and whether it has been in contact with CUI.
Equipment that never held CUI
Equipment that has never stored, processed, or transmitted CUI may leave for maintenance without the sanitization step, but the decision must be documented and supported by evidence. Confirm the device's history against asset records and the boundary diagram. A device that was briefly connected to a CUI network, shared a drive, or was reimaged onto a CUI system falls back into scope.
Warranty and vendor return flows
Warranty replacements and vendor returns are the most common way CUI-bearing media leaves the building without a sanitization step. The return process should flag any device with a storage component before shipment, and the RMA paperwork should not be the only record of what left. Ask vendors whether they will return drives that failed diagnostics, and plan for how failed drives will be destroyed rather than returned.
Leased and shared equipment
Leased equipment and devices shared between projects or business units may carry CUI from a previous user or contract. Leasing agreements often assign data return responsibilities to the lessee, and shared equipment can move between CUI and non-CUI systems without a clear record. Confirm ownership, lease return terms, and the chain of custody for each shared device before it is scheduled for off-site work.
Teams that touch the equipment
IT staff, facilities, procurement, and the external maintenance vendor each handle equipment at a different point in its life. Procurement sets return terms, facilities manages physical removal, and the maintenance vendor may receive the device before any sanitization is complete. Assign one owner for the sanitization step, define handoffs in writing, and confirm that each team knows which device classes require sanitization before they move.
How an assessor tests equipment sanitization
This table compares the assessor's test approach, the evidence requested and the findings that most often fail for MA.L2-3.7.3. Read each row as a question the assessor will ask, then check that your records answer it in final form. The main takeaway is that a single assessment objective is judged on proof that every piece of equipment leaving for off-site maintenance was actually sanitized.
| Assessor activity | What the assessor does | Evidence requested or common finding |
|---|---|---|
| Interview maintenance and asset staff | Asks who decides whether equipment leaves for off-site repair, who clears it and how the decision is recorded | Staff describe a different process than the written procedure; no named owner for sanitization before shipment |
| Examine sanitization and maintenance records | Reviews logs for equipment removed for off-site maintenance and matches each entry to a sanitization record | Missing records for some devices; no record links a sanitization event to the specific asset that left the site |
| Examine vendor maintenance specifications | Checks whether vendor terms or service agreements describe media handling and who sanitizes before pickup | Vendor paperwork is silent on sanitization, and the organization has not documented its own step |
| Test the sanitization process on a sample device | Selects a device, runs the documented method (clearing, purging or destruction) and checks that CUI cannot be recovered | No proof the method was applied; the procedure names a method that the team cannot reproduce on the sample |
| Check that records are in final form | Confirms that sanitization records are completed, signed or approved and not left as drafts or open tickets | Draft or unsigned records, or entries that were never closed after the device was released |
| Trace released devices to a check | Starts from the list of devices sent off site and looks for a documented pre-release check for each one | Devices released without a check, especially loaner, warranty or failed units returned in a hurry |
Clearing, purging or destroying: choosing a method for each device
Clearing overwrites storage with data, typically a fixed pattern, so that the original CUI cannot be read back through normal operating system or application access. It is the lightest method and usually fits devices that stay within a controlled environment, such as a workstation returned to a vendor under a contract that keeps the drive in your custody, or a device that will be reused internally after maintenance. The key question is whether the overwrite reaches every location where CUI could sit.
- Where it fits: Magnetic hard drives and some removable media where the controller writes directly to addressable sectors and the device is staying in a controlled chain of custody.
- What it leaves behind: A device with its storage intact but its readable content replaced. Remnants can persist in areas the operating system cannot address, such as spare or remapped sectors.
- What the record should show: The device identifier, the tool and version, the pattern and number of passes, the operator, the start and end times, and the verification result.
- Where it fails: Overwrites do not reliably reach remapped blocks or wear-leveled flash cells in solid-state drives, and some drives cannot be verified by a read-back from the host.
- Confirm with the vendor: Whether the drive's firmware supports a documented block-level erase and whether the tool can report which areas were covered.
Before you choose clearing for any device, confirm with the manufacturer that the overwrite method is documented for that exact model and that the record can show it completed.
Purging uses a method that makes recovery infeasible even with laboratory techniques, such as cryptographic erase, a firmware-level secure erase command, or degaussing for magnetic media. It fits devices that leave your facility and that hold CUI which is difficult to clear fully, including solid-state drives and drives with damaged or inaccessible sectors. Purging is usually the right choice when the vendor needs the device back for repair or warranty work and you cannot keep it in custody.
- Where it fits: Solid-state drives with a supported secure erase command, self-encrypting drives where the key can be destroyed, and magnetic media that will be degaussed by a method rated for that media type.
- What it leaves behind: Storage that is not readable by the operating system or by a standard recovery attempt, but which may still hold the device in a form that needs to be handled as media until verified.
- What the record should show: The make, model and serial number, the purge method and command or tool used, the result reported by the device or tool, and who witnessed or verified it.
- Where it fails: Degaussing does not work on solid-state media. A secure erase command that is not implemented correctly by the firmware may report success without erasing every cell. Cryptographic erase depends on the key being fully destroyed and on the drive's encryption being active before the data was written.
- Confirm with the vendor: Which purge methods the manufacturer documents for each model, and whether the drive reports a verifiable completion status.
Ask your provider for the documented purge method for each model before the device leaves your spaces.
Destroying makes the media unusable, typically by shredding, pulverizing or incineration. It is the method for media that cannot be verified as sanitized, for failed devices where clearing or purging will not complete, and for media whose risk does not justify the effort of verification. Destruction also fits devices that have reached end of life and will not be reused, since the organization no longer needs the storage to hold anything.
- Where it fits: Failed drives, drives with unreadable sectors, solid-state media that cannot be purged, and any media where the organization decides verification is not practical.
- What it leaves behind: Fragments or residue that cannot be reassembled into a readable device. The remaining material may still be subject to your disposal and recycling rules.
- What the record should show: The asset and serial numbers, the destruction method, the facility or vendor that performed the work, the date, a certificate of destruction, and the chain of custody from pickup to destruction.
- Where it fails: A destruction vendor's certificate is only as strong as the chain of custody behind it. Shredding to a particle size that leaves usable storage pieces or incomplete incineration can leave data recoverable.
- Confirm with the vendor: The particle size or destruction standard used, whether the work is done on site or off site, and whether you can witness it or receive a signed report.
If you outsource destruction, the contract should name the vendor's destruction method and the record you will receive.
The CMMC Assessment Guide Level 2 names clearing, purging and destroying as sanitization options, but it does not assign a method to a device type. The organization must select the method its media and risk justify, document that choice in its policy or procedure, and produce a record for each sanitization event. An assessor will test whether the process is followed and whether the evidence shows the result, not whether one method was used.
- Match method to media type: Use clearing where verification is reliable, purging where a documented command or cryptographic erase applies, and destruction where neither can be verified.
- Set a rule by destination: Devices leaving your facility for repair usually need purging or destruction, while devices staying in custody may suit clearing.
- Record the decision: Keep a written procedure that lists each media type and its approved method, reviewed when hardware changes.
- Verify after the work: Use a read-back or a device status report where available, and keep the output with the sanitization record.
- Connect to asset inventory: Link each sanitization record to the asset entry so the device history is traceable.
Before you rely on any method, confirm with your maintenance vendor and your assessor how they will test the result, since the record must show that the process worked.
How to implement equipment sanitization before off-site maintenance
This sequence turns MA.L2-3.7.3 into a repeatable routine: find every device that may hold CUI, stop it from leaving until it is checked, sanitize it, record the result, and close the loop when it returns. Each step ends with a document or check an assessor can examine.
Identify equipment that holds or may hold CUI
Start from your system inventory and list every device that stores, processes or can reach CUI, including laptops, workstations, servers, storage arrays, network gear with local configuration, printers with memory, and removable media. Use an asset register such as the GLPI Assets module or Wazuh system inventory data to confirm what exists and where it is stored. The output is a scoped asset list that marks each item as CUI-bearing, possibly CUI-bearing, or out of scope, with the owner named for each entry.
Set a hold rule for removals
Write a rule that no CUI-bearing or possibly CUI-bearing device leaves an organizational space for off-site maintenance until a sanitization check is complete. Communicate the rule to facilities, IT staff and anyone who ships hardware, and make the maintenance request form ask whether the device has been through the check. The output is a written hold procedure, approved by the control owner, that applies to warranty swaps, vendor repairs and leased equipment returns.
Select a sanitization method per media type
Match each media type to a method your assessor will accept: clearing (such as overwriting with a fixed pattern), purging (such as degaussing or a secure erase command) or destroying (such as shredding or incineration). Confirm with the vendor and your own environment that the chosen method works on the specific drive technology, especially solid-state storage, where overwriting may not reach every cell. The output is a method matrix by media type, with the tool, command or service used for each.
Sanitize and verify the result
Run the selected method under a named technician, and verify it with a check that proves the media no longer holds CUI, such as a read-back test, a blank-sector sample or a tool report. Where the device cannot be sanitized reliably, route it to destruction instead of release. The output is a verification result for each device, with a failed check stopping the removal and sending the item back to the hold queue.
Record the sanitization with identifier, person and date
Create a sanitization record for each device that states its asset identifier and serial number, the media type, the method and tool used, the verification result, the name of the person who performed the work, and the date. Store the record with your maintenance records so it can be produced at assessment. The output is a signed or approved sanitization record in final form, since a draft does not show that the requirement is met.
Approve the removal and hand over to the vendor
Only after the sanitization record exists, issue an approved removal ticket that names the device, the destination vendor, the reason for maintenance and the expected return date. Hand the device to the vendor with that ticket and a copy of the record, and keep the chain of custody documented from the room to the courier. The output is an approved removal ticket linked to the sanitization record, and no device leaves without both.
Reconcile the returned equipment
When the device comes back, match it against the removal ticket by serial number and check that the device arrived unchanged in identity, that the vendor's work is documented, and that the asset register reflects its status. Confirm whether the vendor retained any media or replaced components, and treat any unexplained difference as an incident to investigate. The output is a return-receipt check closed in the ticket system and an updated asset record, so the device can rejoin the scoped inventory.
Evidence that passes equipment sanitization and how to keep it current
SP 800-171A points assessors toward a small set of records for MA.L2-3.7.3: sanitization records, maintenance records, vendor specifications, removal approvals and custody records. Each card below covers one artifact, and together they show that every piece of equipment leaving the site was cleared of CUI before the work started.
Sanitization records per device
Each record should name the device and its asset tag or serial number, the sanitization method (clearing, purging or destruction), the tool and its version, the operator, the date, and the verification result. Assessors look for a record that matches each piece of equipment that left the site, so a generic log entry for a batch rarely passes. Check that the device identifier matches the asset inventory exactly.
Method selection by media type
The assessment guide describes clearing by overwriting with a fixed pattern, purging with degaussing or secure erase, and destruction by shredding or incinerating. The record should show which method applied to which media type, such as a spinning disk versus a flash device, and why. Confirm with the media vendor that the chosen method is suitable for the specific hardware.
Maintenance records
SP 800-171A lists maintenance records as potential evidence for 3.7.3. These should show the reason the equipment left the site, the vendor or technician involved, the work performed, and the date it was sent and returned. Link each entry to the sanitization record for the same device so an assessor can trace the full sequence.
Vendor maintenance specifications
Vendor specifications explain how a device must be handled, including any sanitization steps the manufacturer requires before off-site service. Keep the version of each specification on file, since the procedure may change between releases. Where a vendor cannot support the sanitization required by the organization, the record should document that gap and the decision made.
Removal approval and chain of custody
A signed removal approval should exist before any equipment leaves organizational spaces. Chain of custody records track the device from the approval through transit, service, return and reintegration, with a named custodian at each handoff. Returned equipment should be checked against its original record before it reconnects to a system that handles CUI.
A single register tied to the asset inventory
Keep these records in one register keyed to the asset inventory, so each device has one current entry showing its status and linked artifacts. GLPI can hold the asset records, and Wazuh Syscollector can confirm hardware and software details on endpoints. Review the register on a fixed schedule and before any assessment, because only final, non-draft records count toward MET.
What equipment sanitization costs in money and effort
This table compares the cost components of sanitizing CUI from equipment before off-site maintenance, who is paid for each, whether it is one-time or recurring, and what drives it up or down. Use it to build a quote request and to see where open-source tools remove license spend. Figures must come from your own device counts, media types and vendor terms, not from this page.
| Cost component | Who is paid or who bears it | One-time or recurring | What drives the cost |
|---|---|---|---|
| Sanitization tooling (degaussers, secure-erase licenses, overwrite utilities) | Hardware or software vendor, or the organization's own budget | Mostly one-time for hardware, recurring if licensed per seat or per device | Number of media types, whether vendor licenses are needed, and whether tools are bought or already available |
| Technician time per device (clearing, purging or destroying) | Internal staff or a contracted service provider | Recurring, tied to each device that leaves for maintenance | Device count, share of devices returning from vendors, and the method chosen for each media type |
| Destruction services (shredding or incineration) | Certified destruction vendor, usually per pickup or per unit | Recurring | Whether destruction is contracted or done in-house, and how many failed or unreadable media go this route |
| Verification and sampling effort | Internal staff or the service provider performing checks | Recurring | Number of devices sampled, how verification is recorded, and whether results are reviewed by a second person |
| Sanitization record upkeep | Internal compliance or IT staff | Recurring | Volume of devices, depth of records kept (asset ID, method, operator, date, result) and where records are stored |
| Asset inventory tooling (for example GLPI or Wazuh Syscollector) | Open-source deployment carried by the organization or implementation partner; no license fee for the software itself | One-time setup, recurring hosting and upkeep | Number of endpoints, integration with existing asset records, and in-house or partner administration hours |
| External testing or review of the process | Independent security assessor or consultant, quoted from written scope | Often one-time per cycle, sometimes recurring | Scope of the process reviewed, number of methods in use, and whether test results are sampled or fully reproduced |
| Assessor sampling time during a CMMC assessment | Assessor (C3PAO) under its own engagement terms; the organization supplies staff and evidence | Recurring per assessment cycle | Number of sanitization events the assessor samples and how quickly complete records can be produced |
Open-source tools that support the asset and sanitization trail
Sanitization is only defensible when the organization can show which device held CUI, what it contained, and who approved its removal. The three tools below keep that trail in self-hosted systems, though none of them sanitizes media or proves that a wipe happened.
GLPI Assets as the device register
GLPI's Assets module (GPL-3.0-or-later) records computers, monitors, software, network equipment, peripherals, printers and racks, entered by hand or pushed automatically by the GLPI Agent through native inventory in GLPI 10 and later. Before a device leaves for off-site maintenance, the team can check its register entry to see whether it may hold CUI and which storage media it carries. Confirm in your deployment that agent-collected records include storage devices, not only the parent asset.
Wazuh Syscollector for endpoint state
Wazuh's Syscollector module (GPL-2.0-only) collects hardware, operating system, installed software, network interfaces, services and users from each endpoint and stores them in the Wazuh indexer. Security staff can use the dashboard inventory to confirm what software and accounts a device carried at the time it was pulled for service. It shows what was installed, not whether data was overwritten, so it supports the record rather than replacing the sanitization log.
Zammad tickets for removal approval
Zammad (AGPL-3.0-only) is a web-based helpdesk that places requests from email, chat, telephone and social media into one ticket system. A removal request can be opened as a ticket, linked to the asset ID, and closed only after sanitization is recorded and signed off. Configure the ticket workflow so the closure step requires the sanitization method and the approver's name, since Zammad will not enforce that on its own.
Sanitization record still comes from the process
None of these tools clears, purges or destroys media. The sanitization record must be produced by the process: the method used (clearing, purging or destruction), the device identifier, the person who performed it, and the verification step. Assessors look for this evidence under the single assessment objective for 3.7.3, so a register entry alone does not show the device was sanitized.
Confirm capabilities in your own deployment
Capabilities depend on version, agent configuration and integrations, and the team should verify each one before relying on it for a CMMC assessment. Test a sample device end to end: confirm the GLPI record, the Wazuh inventory entry and the Zammad ticket all reference the same asset identifier. Keep the test results as evidence of the control design.
Who owns equipment sanitization, who helps and where the auditor stops
Your organization owns MA.L2-3.7.3. The requirement asks that equipment removed from organizational spaces for off-site maintenance is sanitized of any CUI, and no outside party can accept that accountability on your behalf. Internal ownership covers the decisions that determine whether the control works day to day: which equipment counts as in scope, who authorizes a removal, and what happens when a device has no clear sanitization record.
- Device register: Maintain the authoritative list of equipment that may hold CUI, including laptops, storage arrays, network gear and specialized test equipment.
- Hold rule: Write and enforce a rule that no device leaves the facility for maintenance until sanitization is confirmed or the device is handled under a documented exception.
- Sanitization method selection: Choose clearing, purging or destruction for each media type and document why it fits your risk and vendor requirements.
- Records: Keep sanitization logs, vendor return forms and approvals in a form that shows the final state, not drafts.
- Ongoing review: Check that the procedure runs as written, with periodic samples of actual removals.
Before relying on this tab, confirm that a named owner signs off on each removal and that someone outside the maintenance workflow reviews the records.
An implementation partner such as DeployOpen can help prepare the systems and paperwork that support the control, but it does not own the control or decide whether it is met. In practice this work usually sits with a partner that already works inside your infrastructure, because the asset register and tool configuration depend on how your environment is built.
- Asset register setup: Configure inventory so that equipment records can be traced to CUI handling and removal events, for example using GLPI's Assets module.
- Self-hosted tool configuration: Set up inventory collection, such as Wazuh Syscollector data, so hardware and software records are current when a device is pulled for service.
- Workflow and templates: Draft removal request forms, sanitization record templates and vendor return checklists for your team to adopt.
- Test sanitization: Run a controlled test on representative media, document the steps and results, and hand the record to your team to review.
- Documentation handover: Deliver runbooks so that your staff can operate the process without the partner present.
Ask any partner to put the scope, deliverables and handover items in writing before work starts, and confirm that your team, not the partner, approves the final evidence.
The independent assessor tests whether MA.L2-3.7.3 is met and reports the result. For Level 2 certification, that assessor is a C3PAO authorized or accredited by the CMMC Accreditation Body, currently The Cyber AB. For a self-assessment, the organization's own leadership makes the determination and affirms it. Neither DeployOpen nor any other implementation partner issues reports, attestations or certifications.
- What the assessor examines: The assessor reviews the sanitization process, the records, and sample removals against the single assessment objective in NIST SP 800-171A for this requirement.
- What the assessor expects: Final-form evidence, such as completed sanitization logs and maintenance records, rather than drafts or plans.
- Where independence stops: A partner that designed the process may help you prepare, but it cannot perform the assessment or score your evidence.
- Where the auditor stops: The assessor does not write your procedures, select your sanitization methods or fix gaps for you.
- Questions to ask: Confirm the assessor's authorization status and whether the preparation partner has any role that could compromise independence.
Before engaging anyone, check the current CMMC program status, because the program's assessment phases have changed in 2026.
Common questions about MA.L2-3.7.3 equipment sanitization
How much effort does MA.L2-3.7.3 take to meet?
The effort is usually modest compared with other CMMC Level 2 requirements, but it depends on how many devices leave your spaces for off-site maintenance and how mature your media handling process is. The assessment has a single objective: equipment removed for off-site maintenance must be sanitized of any CUI. The work therefore concentrates on defining a sanitization step, applying it consistently, and keeping records. Drivers include the number and types of devices (laptops, servers, storage arrays, test equipment), whether sanitization is done in-house or by a vendor, and whether the process already exists in your media protection procedures. Requirement points are fixed by the scoring methodology under 32 CFR 170.24, so effort is about execution and proof, not points.
Can a small team meet this requirement without outside help?
Yes, a small team can usually meet this requirement internally if it has a written sanitization procedure, a clear owner, and a simple log of each device that leaves the premises. Outside help is most useful for drafting the procedure, testing that the chosen method works on your actual media, and preparing evidence in a form an assessor can review. An implementation partner such as DeployOpen can prepare systems, procedures and records, but the organization owns the control and only an independent assessor can judge it. Ask whether your team has the time to run the process and keep records consistently, since gaps usually appear in the paperwork rather than the technical step.
Which sanitization method does a device need?
The method depends on the media type and how sensitive the CUI on it is, not on a single rule in the requirement. The CMMC Assessment Guide Level 2 describes three families: clearing, such as overwriting with a fixed pattern; purging, such as degaussing or a secure erase command; and destroying, such as shredding or incinerating. Clearing may be enough for some magnetic drives where the device will stay with a trusted maintainer, while solid-state media and devices that will not be returned may need purge or destruction. Confirm the method against your own media inventory and your maintenance vendor's specifications, and test it on a sample device before relying on it.
What evidence will an assessor ask for under MA.L2-3.7.3?
An assessor will look for proof that sanitization happened for each device that left your spaces, and that the process works as written. NIST SP 800-171A lists maintenance records, vendor maintenance specifications, and equipment and media sanitization records as potential evidence, and it includes tests of the sanitization processes and mechanisms. Practically, expect a sanitization procedure, a sanitization or removal log linking each device to its maintenance ticket and sanitization method, vendor documentation for any third party that handled the device, and a sample test showing the method was applied. Evidence must be final, not draft, to count toward a MET result under 32 CFR 170.17 and 170.24(b).
Can a vendor's repair service handle sanitization for us?
A vendor can perform sanitization for you, but the organization remains responsible for the control, so the contract and records must show that CUI is removed before the device leaves. Ask the vendor to state the sanitization method it uses, to provide certificates or logs for each device, and to confirm whether it will destroy or return media. Also check whether the vendor will accept devices with CUI at all. If a vendor cannot document sanitization, the safer option is to sanitize in-house before shipment. Include these requirements in your maintenance agreement, and review the vendor's records as part of your own evidence set.
What happens if MA.L2-3.7.3 is on a POA&M?
Under 32 CFR 170.21, MA.L2-3.7.3 is a 1-point requirement that is not on the exclusion list, so it can be placed on a plan of action and milestones if your score is at least 88 of 110 (0.8). The plan must be closed out within 180 days. Being on a POA&M does not remove the obligation to protect CUI, and an assessor will still expect a real sanitization step in place by closeout. Confirm current status with the DoW CIO and your contracting officer, because the CMMC rollout schedule has changed and the rule text and implementation guidance should be checked before you rely on any POA&M timeline.
What does the work need from our organization?
The work needs a named owner, access to your device inventory and maintenance workflow, and time from the people who handle returns, repairs and disposals. Your team must confirm which systems hold CUI, decide which sanitization method applies to each media type, and agree who signs off on each removal. Engineers need access to test devices or a test environment, and procurement or legal should review vendor terms. Scope is usually set in writing before work starts, so list the device types, locations and maintenance vendors in scope so any quote reflects the actual workload.
How DeployOpen prepares equipment sanitization for assessment
DeployOpen helps organizations prepare the sanitization procedure, the tooling that records it and the evidence an assessor will examine for MA.L2-3.7.3 Equipment sanitization. The organization owns the control and its decisions, while DeployOpen builds and documents the supporting systems, and only an independent assessor can judge whether the requirement is met.
How we scope
- We list the equipment types that leave organizational spaces for off-site maintenance and that may hold CUI.
- We agree which sanitization method, clearing, purging or destruction, applies to each media type in the written scope.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work begins.
How we build
- We configure GLPI asset records so each device leaving the premises carries its owner, location and maintenance status.
- We configure Wazuh Syscollector inventory on managed endpoints so hardware and media records can be checked against asset lists.
- We set up Zammad ticket workflows that route each off-site maintenance request through a documented sanitization step before release.
How we hand over
- We write the sanitization procedure, covering method selection, verification steps and sign-off roles, for the organization to adopt.
- We deliver sanitization records templates and sample completed entries that show who sanitized what, when and how.
- We walk the organization's staff through the evidence set so they can produce final-form records for the assessor.
How we support
- Ongoing support, upgrades and periodic review of the procedure and records are available as a retainer.
- We help the organization confirm its sanitization tooling and method against the assessment objectives in NIST SP 800-171A.
- The organization should confirm with its assessor which evidence form and retention period it will accept before the assessment.
