Employee Offboarding Security: The 47-Point Checklist That Prevents Data Leaks

Onboarding gets the budget, the project plan, and the welcome champagne. Offboarding gets a checklist nobody updated in three years and the unspoken assumption that "we'll get to it next week". This is the 47-point checklist we use to make sure every leaver's access is properly revoked, every asset returned, and every audit-evidence record captured before the badge gets handed back.

Why 47 points and not 12? Because every line below is a finding we have personally encountered in production audits — a piece of access that was missed, an asset that was unaccounted for, a compliance obligation that the rushed offboarding failed to satisfy. The list is long because the failure modes are long.

Why offboarding is harder than onboarding

Onboarding is one-shot, well-defined: give this person what they need. Offboarding is fan-out: revoke everything they accumulated over their tenure. The asymmetry is structural — joining gets formal celebration; leaving is administrative and often emotional.

Three failure modes we see in 9 out of 10 offboarding audits:

1. Standing access nobody knew about. SaaS accounts provisioned 4 years ago in a side project. Access to legacy systems that predates the current IAM. Shared mailboxes the user was a delegate on. Access nobody documented at grant-time means access nobody revokes at leave-time.
2. Delayed revocation. The intent is correct ("we'll revoke when they leave"). The execution slips ("we'll revoke this week"). The cumulative gap between the leave date and the actual revocation date is where most offboarding incidents originate.
3. Missing audit trail. The revocation happened but nobody captured the evidence. A year later, an auditor asks "show me when access for this departed user was revoked" and the answer is a guess.

The trigger architecture

The checklist below works only if it triggers reliably. The trigger is the HRIS termination event — same architecture as our onboarding pipeline, but running the deprovisioning workflow instead of the provisioning one.

Three trigger patterns we ship:

1. Friendly exit (planned leave date). Trigger fires 7 days before leave date. Items execute on a schedule across the 7-day window. Bulk of revocation happens at end-of-business on the leave date.
2. Immediate revocation (involuntary). Trigger fires within minutes of HRIS event. Items execute in priority order: identity first, then high-risk access, then everything else. Target: full revocation in <30 minutes.
3. Garden leave / suspended access. Trigger fires immediately but with a reversibility flag. The user is disabled rather than deleted, with restoration possible if the situation resolves.

The 47-point checklist

Identity (items 01-08)

1. Disable the primary identity account in Entra ID / Okta / Google Workspace. Do not delete — preserves audit trail and allows reversal if needed.
2. Revoke all active sessions across all platforms. PowerShell: Revoke-AzureADUserAllRefreshToken -ObjectId <UserId>. Google: token revocation API. Sessions that were active at termination should not survive past it.
3. Reset password to random 32-character string. Even disabled accounts get re-enabled by mistake; the random password prevents re-use if the disable flag is accidentally cleared.
4. Revoke MFA enrolments + remove backup codes. Mobile-app MFA stays paired to a personal device; if the account is ever re-enabled, the MFA must start fresh.
5. Remove from all group memberships (security groups, distribution lists, dynamic groups). Document the memberships at the time of removal — they may need to be restored if the offboarding is reversed.
6. Revoke directory roles (admin, PIM-eligible). If the user had any standing or eligible admin role, revoke before disabling. Some platforms (Entra) require role revocation while the account is still enabled.
7. Update conditional-access exception lists. If the user was in any CA exclusion group, remove from those groups.
8. Force re-authentication on inherited access. Any shared accounts the user knew the password to need password rotation. Service accounts they had credentials for need rotation.

Email + collaboration (items 09-15)

9. Convert mailbox to shared mailbox (Exchange Online) or set up auto-forwarding to manager. Preserves business continuity for ongoing customer / supplier conversations. Apply retention per compliance policy.
10. Audit mailbox forwarding rules. Departing users sometimes set up auto-forwards to personal email. Check inbox rules, transport rules, OAuth-app-driven forwards. Remove any pointing to external addresses.
11. Audit delegation permissions. Was the user a delegate on any executive mailbox? Did they have full-access permission on shared mailboxes? Document and re-issue access as needed.
12. Apply legal hold if litigation, regulatory action, or HR matter is open. The hold preserves data beyond standard retention.
13. OneDrive transfer of ownership. Reassign the user's OneDrive to the manager or to a successor. Document the new owner. Retain per retention policy.
14. SharePoint site ownership transfer. Any sites where the user was the only / primary owner need new owners assigned before disabling the account.
15. Teams + channel ownership. Teams where the user was the sole owner need ownership transferred. Channel-specific membership is removed automatically when the user is disabled, but ownership requires explicit transfer.

SaaS applications (items 16-22)

16. Deprovision via SCIM for every SCIM-connected SaaS application. Verify deprovisioning succeeded — SCIM failures are silent more often than they should be.
17. Manual deprovision for non-SCIM SaaS. Walk the list of every SaaS account assigned to the user. For each, deactivate or delete the account, transfer ownership of any artefacts.
18. Revoke OAuth grants. Personal OAuth apps the user authorised (with corporate identity) need to be revoked. Entra: enterprise applications → user's grants. Google: Account → Security → Third-party apps.
19. API tokens + personal access tokens. Any API tokens, GitHub PATs, GitLab tokens, internal service tokens the user generated need to be invalidated. Walk every developer tool with token-based auth.
20. SSH keys. Public keys deployed to servers, GitHub / GitLab account keys, key-management services. Revoke at the source + remove from any deployed location.
21. Cloud account access. AWS / Azure / GCP individual user access (IAM users, individual subscription access, service-account binding). Revoke at the identity provider + at the cloud account.
22. Code repository access. GitHub, GitLab, Bitbucket. Remove from organisations + teams + individual repository collaborator lists. Audit recent commits for sensitive content (rare but worth checking on suspicious departures).

Devices + physical (items 23-30)

23. Initiate remote wipe on managed devices via MDM (Intune / Jamf / Kandji). For employee-owned (BYOD), use selective wipe of corporate data only.
24. Trigger device retrieval workflow. Shipping label generated, instructions sent to departing user (or manager if user is unreachable). Default expectation: return within 7 business days.
25. Verify device received. Physical receipt confirmed; serial number matches asset register.
26. Secure-wipe on receipt (full disk encryption + DoD wipe equivalent). Document the wipe completion in the asset register.
27. Redeploy or recycle. Device either re-imaged for next employee or routed to WEEE-compliant recycling per asset disposition policy.
28. Revoke building access (badge / key fob deactivation). If physical access cards exist, retrieve them.
29. Disable parking + facility access. Often forgotten when the office is not the primary touch-point.
30. Update office reception list. Receptionists should know the user is no longer authorised to enter, even with a visitor signature.

Communication + data (items 31-36)

31. Update org chart + intranet + wiki. Remove from team pages, contact lists, employee directories.
32. Disable corporate phone number / extension. Forward to manager or to a successor for transition period.
33. Remove from customer-facing contact lists. CRM contact updates, customer notifications if the user was a primary contact, signature blocks in templates.
34. Update vendor contact lists. If the user was the primary contact with a vendor, notify the vendor and provide new contact details.
35. Update social media + external bios. LinkedIn company page, Twitter / X corporate accounts, conference speaker bios.
36. Out-of-office message on the converted shared mailbox with the successor's contact details.

Compliance + legal (items 37-42)

37. Trigger NDA enforcement reminder. Send the standard "your NDA continues to apply" letter as part of the exit package.
38. Capture IP transfer evidence. Any work product, code, designs, documents the user created should be in corporate-controlled locations, not in their personal accounts. Audit at offboarding; remediate if needed.
39. Apply data-retention policies. User's content (mailbox, OneDrive, Teams chats) retained per compliance policy. Different categories may have different retention.
40. Litigation hold check. If any active litigation involves the user, ensure standard offboarding does not delete relevant content.
41. GDPR Article 30 record. Update the record of processing to reflect the user's departure if they were a data processor on behalf of the entity.
42. ISO 27001 evidence capture. Offboarding completion record saved to compliance evidence store with timestamps, actions, owners.

Financial + HR (items 43-47)

43. Expense system access revocation. Prevents post-departure expense submissions; preserves history for audit.
44. Corporate card cancellation. Coordinate with finance on outstanding charges; final reconciliation.
45. Payroll closure. Final pay calculated; benefits continuation notified; tax forms scheduled.
46. HRIS status update. Employee record moved to "former employee" status. Triggers downstream automation for record retention.
47. Final-check confirmation by HR + IT + Manager. Three-way sign-off that nothing was missed. Stored in the offboarding evidence record.

The escalation tiers

Not every offboarding is the same. Three tiers we apply:

Tier 1 — Standard departure

Friendly exit, planned timeline, no special risk factors. Full 47-point checklist executed over the 7-day window before leave date. Manager + HR + IT sign-off.

Tier 2 — Sensitive departure

Higher risk: user had privileged access, was leaving to a competitor, had performance issues, or had access to highly-sensitive data. Triggers:

• Immediate access revocation (skip the 7-day window, revoke on day of notification)
• Audit of last 30 days of user activity for indicators of pre-departure data exfiltration
• Legal counsel notification
• HR + Manager + Security joint review

Tier 3 — Hostile departure

Termination for cause, investigation in progress, suspicion of policy violation. Triggers:

• Immediate access revocation (within 15 minutes of decision)
• Full forensic preservation of mailbox, OneDrive, devices
• Legal counsel + outside counsel notification
• Coordination with HR + Security + Legal
• Documented chain of custody on all evidence
• Communication freeze until counsel-approved messaging

The audit evidence record

Every offboarding produces a structured record. The record is the audit evidence; it is also the basis for any post-departure inquiry.

# Offboarding evidence record (per user)
employee:
  external_id: HR-2026-0142
  email: jane.doe@client.com
  start_date: 2022-03-14
  end_date: 2026-05-17
  termination_type: voluntary_resignation
  tier: 1

trigger:
  hris_event_received: 2026-05-10T09:14:22Z
  workflow_started: 2026-05-10T09:15:08Z

actions:
  - { item: 01, action: identity_disabled, time: 2026-05-17T17:00:14Z, executor: workflow }
  - { item: 02, action: sessions_revoked, time: 2026-05-17T17:00:18Z, executor: workflow }
  - { item: 03, action: password_reset, time: 2026-05-17T17:00:22Z, executor: workflow }
  # ... all 47 items
  - { item: 47, action: signoff_completed, time: 2026-05-18T11:32:00Z, executor: ic@client.com }

forwarding:
  shared_mailbox_owner: alex.successor@client.com
  onedrive_transferred_to: alex.successor@client.com

device:
  serial: ABC-12345
  wipe_initiated: 2026-05-17T17:01:08Z
  received_back: 2026-05-22T10:14:00Z
  wipe_verified: 2026-05-22T11:30:00Z
  disposition: redeployed

compliance:
  retention_applied: standard_employee
  legal_hold: false
  iso_evidence_path: s3://compliance-evidence/2026/offboarding/INC-2026-0142.yaml

This is the artefact the auditor asks for. The record is also queryable: "show me every offboarding where the device was not wiped within 7 days" becomes a SQL query against the evidence store.

The metric that matters

Mean Time from HRIS Termination Event to Full Access Revocation (MTTFAR). Target depends on tier:

• Tier 1: <24 hours from end-of-business on leave date
• Tier 2: <1 hour from HRIS event
• Tier 3: <15 minutes from authorisation

Track MTTFAR per offboarding. Surface the metric monthly. Investigate any breach of the target. The number is the operational health indicator for the offboarding programme.

Real metrics from a recent rollout

A 250-seat company that deployed the structured offboarding pipeline over a quarter. Six months in:

• Offboardings completed: 22
• Tier 1: 19; Tier 2: 2; Tier 3: 1
• Median MTTFAR (Tier 1): 18 hours (target 24)
• Median MTTFAR (Tier 2): 38 minutes (target 60)
• MTTFAR (Tier 3 — single event): 11 minutes (target 15)
• Devices received back within 7 business days: 21 of 22 (95%)
• Items missed across all 22 offboardings (audit sampling): 3 (1.3% of total items)
• Compliance audit (ISO 27001 interim): zero offboarding-related findings

Pre-deployment baseline: average 4-7 days for full revocation, device-return rate ~60%, recurring offboarding-related findings in internal audits.

What we have learned from running this for clients

1. The trigger architecture is the prerequisite for everything else. Without a reliable HRIS event, the checklist is a manual ritual that gets skipped under pressure.
2. The SaaS inventory drift is the biggest gap. Companies discover, on offboarding, that they did not have a record of every SaaS the user could access. Building the inventory at provisioning time (via SCIM + onboarding pipeline) is what makes offboarding reliable.
3. The tier-3 mistake is cultural, not technical. Coordinating the HR-conversation timing with the IT-revocation timing requires HR + Security + Legal to rehearse together. It is not a technical problem.
4. The 30-day post-offboarding sweep catches stragglers. A month after departure, run a sweep: any SaaS still showing the user as active, any device not returned, any access still granted. The sweep catches 1-3% of cases that slipped through the primary process.
5. The compliance evidence pack pays for itself at the first audit. Auditor sees the structured records and moves on quickly. Without them, offboarding becomes a major audit topic.

The one paragraph version

Offboarding is harder than onboarding because it is fan-out: revoke everything the user accumulated. The 47-point checklist covers identity (8 items), email + collaboration (7), SaaS (7), devices + physical (8), communication + data (6), compliance + legal (6), financial + HR (5). The trigger is the HRIS termination event; the workflow runs deprovisioning automatically across all 47 items. Three escalation tiers (standard / sensitive / hostile) calibrate speed and audit depth. Mean Time to Full Access Revocation is the operational health metric; targets are 24 hours / 1 hour / 15 minutes by tier. The structured evidence record is the audit artefact and the queryable history. Done right, offboarding becomes invisible operational discipline; done wrong, it is the recurring audit finding and the post-incident regret.

If you want the full pipeline built — HRIS trigger, deprovisioning workflow, evidence store, audit reporting — that is the engagement shape under our Intelligent Workflow Automation service, with Microsoft 365 Management covering the M365-specific deprovisioning and Hardware & Endpoint Management covering device retrieval + wipe + redeployment lifecycle. The onboarding pipeline is the mirror — built together they reinforce each other.