The offboarding evidence pack, control by control
An auditor does not ask whether an offboarding SOP exists. They ask for the artifact that proves each control ran. Here are the twelve controls I build the evidence pack around and the proof each one needs.
An auditor rarely asks whether a leaver procedure exists on paper. The real question is whether you can show the artifact that proves each step ran, with a timestamp and an executor. I structure the ITSailor offboarding evidence pack around twelve controls across six categories, each tied to the specific proof it needs.
Last verified: 2026-08-03.
The twelve controls and their proof
- Identity: primary account disabled - a timestamped Entra, Okta, or Google account state change. Maps to GDPR Art. 32, NIS2 Art. 21, ISO 27001 A.5/A.8.
- Identity: active sessions revoked - a Graph revokeSignInSessions or IdP session-kill event.
- Identity: admin and privileged roles removed - a directory-role membership delta and PIM eligible-assignment removal log.
- SaaS: OAuth grants and app consent reviewed - a per-user grant list before and after revocation.
- SaaS: developer tokens and deploy keys rotated - a PAT, SSH key, and deploy-token owner inventory.
- SaaS: SCIM deprovisioning verified - a SCIM active=false response or an application disabled-account state.
- Devices: managed device wipe or retire confirmed - an Intune, Jamf, Kandji, or Google Endpoint command and completion state.
- Data: mailbox and drive ownership transferred - a shared-mailbox conversion, forwarding-rule review, and drive owner transfer.
- Data: manager handover sign-off captured - a signed checklist with owner, date, open risks, and successor.
- Compliance: SOP and evidence record exist - a versioned SOP plus a per-user evidence record with timestamps.
- Monitoring: post-departure login alerts - a SIEM or Sentinel alert rule for former-user sign-in attempts.
- Monitoring: 30-day straggler sweep - a scheduled sweep for stale accounts, device return, and OAuth grants.
Recommendation
Build the pack around the proof, not the checklist. For every control, name the exact artifact and where it lands, so an assessor can open it without asking. Set a clear revocation-time target per departure risk: under 24 hours for a standard leaver, under 60 minutes for a sensitive one, under 15 minutes for a hostile termination. The offboarding tool that assesses these is at /tools/offboarding-risk.
Trade-offs
A full evidence pack costs collection effort on every departure, which feels heavy for a low-risk leaver. The answer is to tier it: the standard path collects the identity and licence proof automatically, and the sensitive and hostile paths add the developer-secret, monitoring, and sign-off artifacts. Automating collection trades an upfront build for a repeatable record.
Where this does not apply
The device and developer-secret controls do not apply to a user who never held a managed device or a code repository, so a fixed twelve-item pack over-collects for a purely office role. The framework mappings are the control objectives those regulations expect evidence for; they are not a certification, and the auditor still owns the judgement.
Offboarding Evidence maps each departure's findings to the same control objectives this pack lists and keeps the result as a dated record per departure, from Offboarding Evidence.
Sources and further reading
Turn the trade-off into a scoped brief.
Share the constraints that differ in your environment. Michal will identify the next check needed before a delivery decision.
Start a scoped briefMore from Ops Log
A daily offboarding check can prove closure only as a bound
A leaver check that runs once a day can report closure only as a bound between two runs. A Graph 429, including one inside a batch that returns 200, and a membership read that returns nulls can each make a degraded run look clean, so an absence counts only from a run that read cleanly.
Google's admin.directory.user.security scope has no read-only form
Google publishes no read-only form of the admin.directory.user.security scope. The scope that lists a user's OAuth tokens and app passwords is the same scope that deletes them, so treat any grant of it as a write permission when reviewing a third-party app.
The Google Workspace scope for reading a leaver's app grants is not read-only
Listing a Google Workspace user's third-party app tokens needs admin.directory.user.security, the same scope that deletes them, and Google lists no read-only variant. Microsoft Graph lists the equivalent grants with Directory.Read.All. Treat the Google credential as a revocation key.