Data sanitisation before a business device leaves your control

Data sanitisation should give your business a defensible reason to release a device, not simply a freshly installed operating system. Before a laptop, drive or server leaves your control, agree what must be preserved, choose a method suited to its storage and intended destination, and check the result against that decision.

Mimir recommends a simple release gate: the asset stays with you until someone can explain which storage was treated, why the method was suitable, whether it completed successfully and who accepted the handover. That approach is useful for equipment donations, lease returns and resale, as well as internal reuse. It also gives the technician a clear way to stop when the evidence is incomplete.

Start with the destination and the business owner

A device returning to a managed team and a drive leaving with an external buyer have different destinations. Record that destination before booking a collection. Ask the business owner what information the equipment held and whether anything must remain available elsewhere. Do not let a courier deadline become the reason to accept an undocumented result.

Our suggested ticket starts with the asset tag, proposed recipient, responsible business owner and planned handover date. Add a short description of the information involved, such as accounts working files or general office documents. Avoid copying sensitive files into the ticket merely to demonstrate that they existed.

Treat data sanitisation as a decision with an owner. If the equipment's history is unknown, mark that uncertainty explicitly. The next step is to investigate or retain the asset securely, rather than assume that an unrecognised disk contains nothing important.

Preserve what the business still needs

Before any destructive work, Mimir recommends getting the business owner to confirm that required records have a usable home. For example, a finance laptop might contain a local export needed for an upcoming reconciliation. That is a hypothetical planning example, not a claim about a client incident.

Ask for a practical recovery check: can the authorised person open the retained material from its new location without using the retiring device? Our backup restore-drill guide explains how to turn a successful backup job into a recovery exercise. Decide who can authorise deletion only after that check has an owner and an outcome.

Data sanitisation is not a substitute for deciding which business records should be kept. If a preservation requirement or unresolved investigation applies, obtain the relevant internal approval first. This article does not set a retention period or determine a legal obligation.

Match the method to the storage

NIST SP 800-88 Revision 2 distinguishes three outcomes: clear resists straightforward recovery through normal interfaces; purge resists laboratory recovery while potentially preserving reuse; destroy makes storage unusable and recovery infeasible. It also warns that ordinary overwriting can miss inaccessible flash storage areas. These distinctions help frame the question; they do not select a command for your hardware.

For data sanitisation planning, list the installed storage devices, not just the computer's marketing name. Our advice is to record the drive model, serial number, storage type and relevant firmware or tool version. Include secondary drives and removable storage in the scope, or explicitly record that they are being retained separately.

Dell's Data Wipe documentation illustrates why this matters: the supported action varies by media, and the storage manufacturer implements the command after the BIOS issues it. That document still labels its references as NIST Revision 1 and IEEE 2883-2022; it is not evidence of Revision 2 certification. Confirm support for the actual model before choosing a procedure.

Understand what a Windows reset promises

Microsoft describes its consumer Reset your PC data-erasure option as making deleted files harder to recover. The same guidance says that this function does not meet government and industry data-erasure standards. The keep-files option also deliberately retains personal files.

That is a reason to inspect the exact operation, not to treat every Windows management action as equivalent. A screenshot of a welcome screen is not enough for our proposed release gate. Ask the technician to identify the documented method used on each storage device and the completion evidence it produced.

If the only recorded action is a consumer reset, pause the handover and compare that action with the organisation's chosen requirements. Do not quietly describe it as a certified wipe. A separate supported process may be needed, and that decision belongs before collection rather than after resale.

Use encryption evidence, not an encryption assumption

Cryptographic erase depends on its implementation. NIST describes prerequisites concerning encrypted coverage, earlier plaintext data and the ability to sanitise relevant keys, including copies. Turning on encryption late or removing a sign-in account does not establish those prerequisites. See NIST section 3.2.

Apple's deployment guidance describes key destruction that makes user data cryptographically inaccessible. Its Mac support conditions include Apple silicon or the T2 chip and macOS 12.0.1 or later. Those conditions should not be generalised to every older Mac or an unrelated external drive.

For a data sanitisation record, our recommendation is to link the vendor procedure that matches the machine, record the applicable hardware and software, and retain its reported result. Where encryption history or coverage cannot be established, ask for a suitable alternative. A sticker saying the fleet is encrypted does not answer those device-specific questions.

Separate completion from permission to release

NIST distinguishes verification, checking the operation's completion and errors, from validation, deciding whether the result is acceptable. An unsuccessful or inadequate result needs further action. Sections 4.5.1 and 4.5.2 explain the distinction.

Mimir suggests reflecting that separation in the handover ticket. The technician records what ran and what happened. An authorised reviewer then checks whether that evidence meets the agreed release requirements. For a small business, this can be a short review by another responsible person rather than a new committee.

Make the outcome unambiguous: release approved, further work required, or secure retention pending a decision. An error should remain visible in the record. Avoid replacing an inconvenient failure log with a later screenshot that makes the process appear straightforward.

Make the handover record useful months later

Our suggested data sanitisation record connects the decision to the physical item. Start with the computer asset tag and each storage serial number. Add the selected method, procedure reference, tool and version, operator, execution date, completion result, reviewer and eventual recipient. Keep the raw output alongside a readable explanation of any exceptions.

If a supplier does the work, agree this evidence before sending the equipment. Ask how its report will identify your individual drives and how it will handle an item that cannot complete the chosen procedure. A generic collection receipt should not be accepted as the result of work it does not actually describe.

For internal reuse, record the receiving team. For external handover, reconcile the items collected against the approved list. The point is traceability: someone reviewing a single serial number later should not have to reconstruct its journey from several unrelated emails.

Close the management relationship separately

Storage treatment and device-management cleanup need distinct evidence. Microsoft says devices permanently leaving an organisation should be deregistered from Windows Autopilot. Its documented sequence and Microsoft Entra guidance vary with the join state, so follow the applicable procedure rather than deleting directory objects indiscriminately.

There is another distinction for organisations using the newer Windows Autopilot device association. Microsoft explains that deleting its list entry alone does not clear tenant affiliation already stored in device firmware. Removing that association also does not itself unenrol the device or delete its other management records.

Our recommendation is to put management release on the same handover ticket, with a separate owner and completion field. Use the Microsoft Intune overview as broader context, then consult the current Microsoft procedure for your deployment. Neither a management deletion nor an erase receipt should be used as proof that the other task happened.

Decide what happens when a drive cannot be treated

If the agreed data sanitisation process cannot complete, our advice is to quarantine the item from the outgoing batch and escalate the exception. A non-responsive drive should not leave merely because its failure prevents an ordinary logon. Agree a route with the responsible business owner and a qualified provider, particularly where the storage cannot be separated from the equipment.

Check lease or return arrangements before promising that the whole device will be returned intact. Ask what happens if the storage must be retained or destroyed, who authorises that choice and which evidence will be supplied. Those are contractual questions for the parties, not assumptions a technician should make at the packing bench.

Do not improvise a destructive demonstration to make the schedule work. Keep the device secured, record the reason for the delay and resolve the method through the approved process.

Put data sanitisation into the next refresh

Start with the next small batch of retiring equipment. Choose the ticket owner, collect the device inventory and agree which evidence is needed before any handover. Mimir recommends reviewing one completed record before repeating the workflow across the rest of the batch; that exposes missing fields while they are still easy to correct.

The useful outcome of data sanitisation is a supported release decision for an identified asset. If a result is incomplete, keep control of the equipment until the exception has been resolved. If it is acceptable, retain the evidence with the asset record and close the business and technical tasks together.

Mimir's cybersecurity and risk-management service can help make these responsibilities part of your wider IT process. The aim is a repeatable handover that your team can explain, rather than a collection of devices that merely look ready for their next owner.