MSP Device Sanitisation Workflow Guide Steps

A laptop returned by a departing employee is not simply another ticket to close. It may contain client records, cached credentials, browser sessions, financial data, protected health information or source files. For an MSP, one missed device can create liability for both the provider and the client. This guide establishes a repeatable process for removing data, preserving audit evidence and releasing devices for redeployment, resale, return or disposal.

The goal is not to make a device appear empty. The goal is to apply a documented sanitisation method that matches the media type, the client’s requirements and the device’s final disposition. That distinction matters when an auditor, client executive or incident responder asks what happened to a retired endpoint.

Can an MSP remotely wipe a client device without authorisation?

No. An MSP should only wipe a client device with documented authorisation from the client, normally set out in the contract and confirmed per job. Wiping without authority risks destroying records the client must keep and can breach contract and data protection law.

Why MSPs need a defined sanitisation workflow

MSPs work across different client environments, policies and regulatory obligations. A one-off approach based on technician memory creates inconsistent outcomes. One technician may reset a Windows device, another may manually delete files and a third may wipe the drive without recording the serial number. None of those actions alone creates a defensible chain of custody.

A defined workflow standardises decisions before the hardware reaches the bench. It identifies who authorised the device release, what data-bearing components are present, which sanitisation method was used and where the resulting evidence is stored. It also protects the MSP from scope confusion. If a client requests disposal but expects a certificate of erasure, that requirement must be captured before the asset leaves control.

The right level of rigor depends on the client. A small business recycling old office PCs may need straightforward documented wiping. A healthcare, legal, financial or public-sector client may require stricter approval controls, retention periods and alignment with NIST guidance. The workflow should be consistent, while the policy settings and evidence requirements can vary by client agreement.

1. Open a disposition record before touching the device

Create a ticket, asset disposition record or work order at intake. Record the client name, asset tag, manufacturer, model, serial number, assigned user if known, intake date and requested disposition. Include the reason for retirement, such as employee offboarding, lease return, hardware refresh, warranty replacement, resale or destruction.

This record should also name the person who authorised the action. MSPs should not assume that every device delivered to the help desk is approved for wiping. A device involved in litigation, an internal investigation, an insurance claim or a security incident may be subject to a preservation hold. Sanitising it prematurely can destroy evidence and create a separate compliance problem.

2. Maintain chain of custody from intake to release

Once accepted, label the device and place it in a controlled staging area. Record each transfer when custody changes, especially when devices move between client premises, an MSP office, a repair depot and an IT asset disposition provider.

Chain of custody does not need to be bureaucratic to be useful. At minimum, it should show who released the asset, who received it, when it moved and its current status. For high-volume refresh projects, barcode scanning and batch tracking reduce manual errors. For small batches, a ticket-based log may be sufficient if it is complete and consistently maintained.

3. Identify every data-bearing component

Do not treat the outer device as the only asset. Inspect laptops, desktops, servers, tablets and mobile devices for internal SSDs, HDDs, removable drives, SD cards, USB storage and embedded storage. A device that fails to boot may still contain accessible data. A workstation with two drives may have only one drive visible to the operating system.

Storage technology determines the proper sanitisation approach. Traditional hard disk drives, SATA SSDs, NVMe SSDs, self-encrypting drives and mobile flash storage do not all respond to the same methods. Overwriting techniques that were common for magnetic drives may not provide the intended assurance on modern flash media because of wear levelling and inaccessible storage areas.

If the drive is damaged, locked, missing or cannot be reliably accessed, document the exception. Physical destruction through an approved process may be the appropriate option, but it must be recorded as a different outcome from successful software-based sanitisation.

4. Confirm the approved sanitisation method

The method should be selected from the client’s written policy, contractual obligations and media type. Common outcomes include clearing for internal reuse, purging for higher assurance, cryptographic erase where properly implemented, or physical destruction when the media cannot be sanitised or is leaving a controlled environment.

Avoid vague language such as “formatted” or “factory reset” in client documentation. Formatting may remove file system references without removing recoverable data. A factory reset may be appropriate for certain managed mobile devices when combined with encryption and policy controls, but it is not automatically equivalent to a documented media sanitisation process.

For devices intended for reuse or resale, use a dedicated data erasure tool capable of verifying completion and generating an erasure record. Our RedKey USB supports USB-based secure data erasure for supported computers and laptops, with supported mobile-device erasure in the Ultimate edition, unlimited wipes and no subscription model. PDF erasure reports are included in the Professional and Ultimate editions; the Home edition shows the result on screen only. The operational value for MSPs is consistency: technicians can apply the same controlled process across routine offboarding and high-volume refresh work.

5. Remove management controls and account dependencies

Sanitisation should be coordinated with identity and endpoint management, not performed in isolation. Before releasing a device, confirm that it has been removed from the relevant management platforms, encryption key repositories, mobile device management systems and asset registers.

This step prevents a common failure: a wiped device is resold or transferred while still associated with the client’s tenant, activation lock or management enrollment. It can also prevent the loss of recovery information needed during an approved process. For encrypted endpoints, verify key-handling requirements before taking action. Destroying or revoking keys can be an effective control in the right circumstances, but it should be performed under an approved policy rather than as an improvised shortcut.

6. Perform the wipe in a controlled environment

Technicians should use a documented procedure that starts with verifying the target drive. This is particularly important for multi-drive systems and bench environments where multiple devices may be connected. Confirm the asset identifier and drive serial number before starting the process.

Run the selected sanitisation method without interruption. If the process fails, do not mark the device complete simply because it no longer boots or appears blank. Capture the failure reason, determine whether a second approved method is available and escalate exceptions according to the client’s policy.

For batch work, establish a clear status system such as received, pending approval, in process, sanitised, exception and released. That visibility makes it easier for service managers to identify stalled assets before they become a client escalation.

7. Check the result and retain the record

A completed erasure is operationally useful when its reported result is recorded and checked. The disposition record should capture the sanitisation date, technician, software or method used, media serial number, outcome and any verification result. Attach the certificate or report generated by the erasure process when available.

Store records in a location that is accessible to authorised staff and protected from alteration. The retention period should follow the client contract and applicable compliance requirements. For regulated clients, the evidence package may also need the approval record, chain-of-custody entries and downstream recycling or destruction documentation.

A certificate is not a substitute for process discipline. It records a specific action and reported result for a specific device. Its value depends on accurate asset identification, proper method selection and reliable record retention, and it does not by itself guarantee compliance or that data is unrecoverable.

8. Release the asset only after status reconciliation

Before a device is redeployed, shipped, sold or sent for recycling, reconcile the physical asset against the disposition record. Confirm that its status is sanitised, the evidence is attached and all exceptions are resolved or formally accepted.

For redeployment, reinstall the approved operating system image and enroll the device in the client’s management environment as a new endpoint. For resale or recycling, remove client labels where required and obtain downstream documentation from the receiving party. A recycler’s certificate does not show that the MSP completed an earlier software wipe, so retain both records when both actions occurred.

Build exceptions into the process

The best workflow assumes some devices will not follow the happy path. Failed drives, unknown ownership, inaccessible BIOS settings, encryption locks, legal holds and missing serial numbers need defined handling. Technicians should know when to stop, who can approve an alternate disposition and what evidence is required.

This is where MSP standardisation pays off. Instead of asking a senior engineer to make a judgement call each time, the service desk can route exceptions through an established approval path. It reduces delays while preventing technicians from making irreversible decisions without authority.

Make sanitisation a service standard

Device sanitisation belongs in onboarding documentation, offboarding checklists, refresh project plans and managed service agreements. Define whether it is included in the monthly service scope, billed per device or delivered as part of a project. Clarify who approves disposition and how long records will be retained.

A mature process also benefits from periodic review. Sample completed records, compare physical inventory against asset records and test whether certificates can be retrieved quickly for a past client request. If a technician cannot show what happened to a device six months ago, the workflow is not yet audit-ready.

Treat every retired endpoint as a controlled data event. When the workflow is repeatable, the records are complete and exceptions are handled deliberately, device retirement becomes a reliable service operation rather than a last-minute security risk.

Frequently asked questions

What records should an MSP give a client after a wipe?

Give the client a per-device record with the serial number, sanitisation method, result, date and technician, plus custody details. A recycler's certificate alone does not show the MSP completed the erasure.

Should an MSP use one wiping tool for all clients?

A single, consistent tool and process makes results comparable and easier to audit across clients. Make sure it supports each client's hardware, including SSDs and multi-drive machines.

MSPs supporting several clients or sites can equip each technician with the RedKey USB Professional 5-Pack, including PDF reports for client records. Related reading: ITAD Sanitisation Workflow That Stands Up to Audit and Why Audit Ready Erasure Reports Matter.