SOC 2 offboarding: proving the assets came back

Q: Does SOC 2 set a deadline for revoking a leaver's access?

Not a fixed one. The Trust Services Criteria require timely removal, and your own access-control policy defines what timely means. Most policies commit to same day or one business day, and the auditor tests against whatever you wrote down. A generous window you actually meet is stronger evidence than an ambitious one you miss.

Q: What proves a device came back?

A record tied to the specific asset, not a checkbox on a form: the assignment history showing the return date and who received it, the serial number matched against the inventory entry, and, where the device is not immediately reused, a wipe or factory-reset record linked to that same entry.

Q: What happens if a leaver never returns the laptop?

Document the exception rather than hiding it: the remote wipe or lock command with its timestamp, the write-off decision with an approver, and the asset's status updated to lost. An exception you found, contained, and documented reads far better in an audit than one the auditor finds for you.

Q: Does SCIM deprovisioning cover SOC 2 offboarding?

It covers the access half. A SCIM leaver event from your identity provider can disable the account, revoke roles, and leave an audit-logged trail within minutes of the HR action. It says nothing about the laptop, the monitor, the license seats, or the consumables the person still holds. That half lives in your asset register.

Q: Does using OnTrackio make us SOC 2 compliant?

No. A SOC 2 report is an auditor's opinion on your whole control environment. OnTrackio produces the offboarding evidence that feeds the CC6 criteria, from revocation logs to return records to the offboarded-still-holding-assets count. Policies, HR process, and the audit itself remain yours.

2026-07-16

Every SOC 2 Type II audit samples leavers. The auditor picks a handful of departures from the observation window and asks the same questions about each: when did HR terminate this person, when did each system revoke their access, and where is the laptop? Most teams pass the first two questions from their identity provider’s logs and stall on the third, because the asset half of offboarding lives in a spreadsheet nobody updated in March. This post covers what the offboarding sample actually tests, the evidence that satisfies it, and why the asset register, not the IdP, is where offboarding audits are won or lost.

What the auditor samples

For each sampled leaver, fieldwork converges on a short list. Industry evidence checklists describe the same set: the termination notice with its date, proof of access revocation in each affected system with timestamps, confirmation that revocation happened within your policy’s window, device return or remote wipe records, and an IT sign-off that the checklist completed.

Two properties make the sample pass or fail. First, timestamps: “we removed access” is an assertion; a revocation log entry dated the same day as the termination is evidence. Second, completeness across systems: the identity provider covers the SSO surface, but the auditor will ask about applications outside SSO, API tokens, and the physical estate. A leaver whose Okta account died on day one but whose laptop shows no return record is an audit exception.

The criteria behind the sample

Offboarding evidence feeds three criteria in the 2017 Trust Services Criteria:

CC6.2 and CC6.3 cover credential issue, modification, and removal. The points of focus include removing access when it is no longer required, which is the clause the leaver sample tests directly.
CC6.5 covers the physical side: ceasing to protect an asset is only acceptable after the data on it has been dealt with. This is where device return, remote wipe, and disposal records live. A returned laptop with no wipe record, reissued to a new hire with the leaver’s data still on it, is exactly the failure this criterion exists to catch.

The pattern from the asset inventory post holds here: the auditor rarely tests a policy document. They test whether a record set that could only exist if the process ran does in fact exist, leaver by leaver.

If you run offboarding from a spreadsheet today, we keep an ungated IT offboarding checklist template (XLSX): nineteen leaver steps plus the dated asset-return and access-revocation logs that make that record set exist. No email gate.

The evidence set, concretely

For a clean offboarding sample, you want to produce, per leaver:

The termination record with date and time, from HR or the identity provider.
Access revocation timestamps per system: the IdP event, plus revocation in anything outside SSO, plus API tokens and shared credentials rotated where relevant.
The holdings list at departure: every device, license seat, and pooled item assigned to the person on their last day. You cannot prove everything came back if you cannot say what was out.
Return records tied to asset entries: the assignment history closing with a return date and receiver, serial numbers matching the inventory.
Wipe or reset records for returned devices, linked to the specific asset entry, with a date and an operator.
The exception file for anything that did not come back: remote wipe or lock evidence, the write-off approval, the asset marked lost.

Where offboarding actually fails

The failure mode is almost never the IdP. It is the gap between three systems that do not talk: HR knows the person left, the identity provider killed the account, and the asset register still shows a laptop, two monitors, a YubiKey, and four license seats assigned to a ghost. Common variants the sample turns up:

The still-holding leaver. Offboarded in every system, still holding hardware in the register, nobody assigned to chase it.
The license shadow. Seats on tools outside SSO that kept billing and kept access for weeks after departure.
The undocumented wipe. The laptop came back and got reimaged, but nobody recorded it, so for audit purposes it did not happen.
The contractor blind spot. Offboarding runs through HR for employees, and contractors leave through a different door with no checklist at all.

Automating the leaver trail

The fix is structural, not heroic: make the offboarding checklist read from the systems of record instead of people’s memories.

Access first: a SCIM connection from Okta or Microsoft Entra turns the HR termination into a deprovisioning event automatically, with every revocation logged with its provenance. That closes questions one and two of the sample within minutes of the HR action.

Assets second, and this is the half most stacks miss: the offboarding view should list the leaver’s complete holdings, hardware, license seats, consumables, and pooled loans, and refuse to mark the person offboarded while anything is outstanding. Each return closes against the asset’s own history; each wipe gets a record tied to the entry. The evidence then accumulates as a side effect of running the process, which is precisely what a Type II observation window rewards.

How OnTrackio produces this evidence

OnTrackio’s offboarding workflow is built around that gate: it shows every departing user’s holdings across hardware, software seats, stockroom consumables, and pool checkouts, and the offboarding cannot be completed while any of them is outstanding. Returns close the assignment history, wipe and disposal certificates attach to the asset entry, and SCIM leaver events from Okta or Entra revoke access with an audit-logged trail. The SOC 2 CC6 evidence pack surfaces the number an auditor circles first on this topic: offboarded people still holding assets, straight from live data. US teams can start at the US overview.

Honesty about scope: OnTrackio covers the asset and access evidence. Exit interviews, NDA acknowledgements, payroll, and the HR side of offboarding live in your HR stack. Our own Type II window has not opened yet, which the security page states plainly. If your next audit includes a leaver sample you are not sure would pass, book a 30-minute demo and bring one real departure; we will trace it end to end.

Frequently asked questions

Does SOC 2 set a deadline for revoking a leaver’s access? No fixed deadline. Your access-control policy defines the window, and the auditor tests against it. Same day or one business day is the common commitment.

What proves a device came back? The asset’s own history: a return date and receiver on the assignment record, the serial matched to the inventory entry, and a wipe or reset record for devices not immediately reused.

What happens if a leaver never returns the laptop? Document the exception: remote wipe or lock evidence, a write-off approval, the asset marked lost. A contained, documented exception reads far better than a discovered one.

Does SCIM deprovisioning cover SOC 2 offboarding? The access half. The laptop, monitors, license seats, and consumables the person holds are asset-register questions SCIM cannot answer.

Does using OnTrackio make us SOC 2 compliant? No. OnTrackio produces the offboarding evidence feeding CC6.2, CC6.3, and CC6.5; your policies, your HR process, and the auditor’s opinion make up the rest.