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.
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
Mailbox forwarding rules survive the leaver: the offboarding check most runbooks skip
An enabled inbox forwarding or redirect rule keeps sending a departed employee mail long after the account is disabled. Here is how to find every one from Microsoft Graph and shut it before it becomes an exfiltration path.
The licence you keep paying for after the seat goes dark
License waste in Microsoft 365 has two honest layers: seats you can reclaim from hard data today, and a term premium you can model but not read from Graph. Here is how I separate them so the number I quote is defensible.
The offboarding runbook and the MTTFAR clock
Offboarding is a race against the access a leaver still holds. This is the order of operations I run and the mean-time-to-full-access-revocation targets I hold each departure to, from a standard leaver to a hostile termination.