SOC 2 Laptop Offboarding: Evidence Auditors Sample

An employee leaves on a Friday and their account is disabled by evening. The laptop is another matter.

Their SaaS seats are gone and the ticket is closed. The laptop is still in a flat two time zones away, with cached credentials and customer files on the disk. In a SOC 2 audit, that laptop is the part of offboarding most teams cannot prove.

What device evidence does a SOC 2 auditor ask for at offboarding?

Auditors sample terminated employees and follow each one through the full offboarding record. For a laptop, the record that holds up is a dated chain: the HR termination, the access removal, the device's return or lock, and a wipe or deactivation reading tied to its serial number.

Strike Graph's guidance on access termination says the termination list for a Type 2 audit "should be generated from your HRIS or payroll system", and that the auditor then picks a sample and reviews the full termination tickets or checklists. The same article notes that the default control wording says all assets are returned when employment ends. It does not say which assets, so your own policy has to.

Why isn't disabling the account enough?

Because the account and the device are separate things. Disabling a login stops new access to cloud systems. It does nothing to what is already on the laptop.

Growrk's IT operations note puts it directly: "Disabling an account doesn't remove local files, cached credentials, downloaded customer data, or IP." It also argues that an unrecovered laptop "is a compliance and security exposure," not just a lost asset, and that "written off" is an accounting label rather than a security control.

This is where device evidence differs from access evidence. An identity log proves a person lost their sign-in. Only a device record proves what state the hardware was left in.

How do auditors cross-check HR records against devices?

They compare two lists. Linford & Co's walkthrough of remote-company audits says auditors "cross-reference a human resources termination list with a hardware inventory log."

The same page describes the failure case: a departed employee's laptop that "hasn't been checked into the MDM system or marked as 'wiped'", which it calls "a major physical security exception." It lists the evidence that answers it as a live hardware asset ledger with serial numbers and device assignments, plus a timestamped process for remote wipes.

That makes the device inventory the join key. If every laptop has a stable identifier and an assigned owner, the cross-check takes minutes. If the inventory is a spreadsheet last edited in March, each departure becomes a manual hunt. Our guide to what auditors actually check in a SOC 2 device inventory covers how to keep that register honest.

What should the per-device offboarding record contain?

One row per departed employee's device, written when the event happens. Seven fields cover what the sources above describe:

1. The device serial number and the assigned owner.
2. The HR termination date, taken from the HRIS.
3. The date access was removed, with a link to the identity-provider log.
4. The disposition: returned, recovered from the employee, or unrecovered with an incident record.
5. The state reading at disposition: enrolled, last check-in time, and whether disk encryption was on.
6. The wipe or deactivation record and its date, with the standard it followed.
7. The approver, because a wipe of company hardware is a decision a named person signs off.

Growrk's note adds a program-level view worth borrowing: a "device disposition rate," the share of departing employees whose device was recovered and documented. A rate you can compute is a rate an auditor can test.

What does a wipe record need to show?

That the data is no longer reachable, to a named standard, for a specific serial number. "Deleted" is not enough. Growrk's wording is that wiping should follow a recognized standard such as NIST 800-88, or the device should be destroyed with documentation, and that "Deleted" is not "destroyed."

The standard itself has moved. NIST SP 800-88 Rev. 2, Guidelines for Media Sanitization, was finalized in September 2025 and supersedes Rev. 1. NIST's page for Rev. 1 now lists it as withdrawn as of September 26, 2025. If your wipe procedure still cites Rev. 1, update the citation and have your auditor confirm they accept it.

Do not assume a remote command settled the question either. Growrk is plain about the limit: "A remote wipe only works if the device is online and still enrolled." A wipe that was sent is a request. A wipe that was confirmed is evidence. Record the confirmation, or record that the device never checked in.

What if the laptop never comes back?

Treat it as an incident with its own record, not as a gap in the spreadsheet. Auditors accept an exception they can read about. They do not accept one they find.

For an unrecovered device, the record should show:

• The recovery attempts, with dates.
• The last time the device was seen enrolled, and whether disk encryption was on at that point.
• The decision taken: remote lock or wipe queued for the next check-in, or the risk documented with a compensating control.
• The person who approved that decision.

The encryption reading carries the most weight here. A laptop that left with full-disk encryption enforced and a screen lock policy in effect is a very different exposure from one with neither. That is why the controls we cover in our posts on proving disk encryption and proving screen lock matter at offboarding as well as during the audit window. The last good reading is the nearest thing you have to proof about a device you cannot touch.

How does BYOD change offboarding?

You cannot wipe what you do not manage. Drata's BYOD guidance says business use of personal devices may still require you to show they are configured securely, and lists enrolling in an MDM as one route to that evidence. It also warns that users may not want to enroll in an MDM, install vendor software or provide a screenshot from their personal device.

For offboarding, the question is what you can honestly attest. Typically that means removing the managed work profile or revoking its tokens and recording that, rather than claiming a full wipe you had no authority to perform. Drata is clear on who decides whether alternatives are accepted: "up to your auditor to decide." Settle that before the observation window opens, not during fieldwork.

How do you make offboarding evidence collect itself?

By reading device state continuously instead of assembling it at the end. The wipe record is the one you cannot backfill: it exists when the wipe is confirmed or it does not exist. The reading before departure can come from a sensor that has been reporting all year.

That is where continuous device telemetry earns its place. A sensor that reports encryption status, last check-in and OS state per device gives you the "last known good" reading for every laptop, including the one that never came back.

It also surfaces the device that is still checking in a week after its owner's termination date, which is the mismatch an auditor would have found. Where a device cannot be verified, the honest output is "unknown," and that goes in the record as unknown. Any remediation, including a wipe, stays a human-approved action.

If you want the sampling to go well, run it on yourself first. Take last quarter's departures, pull each device's record, and count how many have all seven fields. The number that do not is your fieldwork finding, found early.

What is the key takeaway?

• Account removal and device disposition are separate controls, and auditors test both.
• The device inventory is the join key between the HR termination list and the hardware.
• Each departed employee's device needs a dated record: disposition, last state reading, wipe or deactivation evidence and an approver.
• A sent wipe command is not a confirmed wipe. Record the confirmation or the missing check-in.
• An unrecovered laptop needs an incident record and the last known encryption state.
• Confirm with your auditor which sanitization standard and which BYOD alternatives they will accept.

See which of your laptops can already prove their last state: start free with up to 10 devices for 30 days, no card required.