Onboarding & Offboarding: A Practical Playbook
Note: This is general information and not legal advice.
On this page
Executive Summary
- Orphaned accounts and shared credentials are common breach paths.
- Inconsistent onboarding creates support tickets and productivity drag.
- Vendor questionnaires often ask for access removal and termination controls.
- Roles/groups drive access (not ad-hoc exceptions).
- Offboarding revokes access quickly and predictably (including SaaS tokens and shared creds).
- A simple checklist is followed every time.
Common failure modes
- Single Sign-On (SSO) offboarding only: the user is disabled in the Identity Provider (IdP), but app accounts and API tokens remain active.
- Shared accounts: passwords never rotated after departures.
- "Cloned access" onboarding: copying another employee's permissions creates privilege creep.
- No device custody: laptops, phones, and Multi-Factor Authentication (MFA) methods aren't recovered or wiped.
- No owner for data handoff: mailboxes/files don't get transferred cleanly, so access is re-enabled "temporarily."
Implementation approach
Onboarding (joiners)
- Role-based access: assign via groups/roles, not one-off permissions.
- Baseline security: MFA enrollment, device compliance posture, and required apps/config.
- Day-one readiness: hardware, accounts, and access verified before the user’s first day.
Moves (role changes)
- Remove before add: revoke old privileges as part of the role change (especially admin/sensitive access).
- Re-certify: confirm access is still needed after 30–60 days.
Offboarding (leavers)
- Disable access quickly: identity accounts, VPN/remote access, and privileged roles.
- Revoke sessions/tokens: don’t rely on password resets alone.
- Close SaaS accounts: identify all apps with direct logins, API tokens, and ownership ties.
- Rotate shared credentials: where shared access still exists, reset and re-issue intentionally.
Sample scenario: Sarah's last day is Friday
Sarah gave her two weeks' notice. HR told her manager. Her last day is Friday. It's now Thursday afternoon.
Now the questions start:
- Who tells IT? Is there a formal notification process, or does IT find out when Sarah's laptop shows up in a box?
- When does access get disabled? End of day Friday? Monday morning? "When someone remembers"?
- What about her email? Does her manager need access to her inbox? For how long? Who sets that up?
- What files does she own? SharePoint sites, shared drives, project folders — who inherits them?
- What SaaS apps does she use? Did she sign up for tools with her work email that IT doesn't know about? Who's paying for those subscriptions now?
- Does she have admin access anywhere? Billing portals, domain registrar, social media accounts, vendor dashboards?
- What about her phone? Is company email on her personal device? Can you wipe it? Did she ever set up MFA?
- Shared passwords? Does she know the credentials for any shared accounts that should be rotated?
This single scenario — a normal, friendly departure — exposes gaps in: HR-to-IT handoff, access revocation timing, data ownership, SaaS inventory, and device management. That's why offboarding needs a checklist, not heroics.
Operations & evidence
- Audit trail: log who approved access and when it was removed.
- Quarterly access reviews: privileged roles, sensitive groups, external guests.
- Offboarding checklist evidence: keep a lightweight record (ticket ID + completion confirmation).
Common Questions
Why is offboarding a security risk?
Orphaned accounts and shared credentials are common breach paths. When access isn't revoked properly, former employees may retain access to email, files, SaaS apps, and admin portals. SSO offboarding alone isn't enough—app accounts, API tokens, and shared credentials often remain active.
What is "cloned access" and why is it a problem?
Cloned access means copying another employee's permissions when onboarding someone new. This creates privilege creep over time—new hires inherit permissions that made sense for someone else but not for their role, and access accumulates without intentional review.
What should happen when an employee leaves?
Disable identity accounts, VPN/remote access, and privileged roles. Revoke sessions and tokens (not just password reset). Close SaaS accounts including direct logins and API tokens. Rotate any shared credentials the departing employee knew. Transfer data ownership (mailboxes, files, project folders).
How should role changes (movers) be handled?
Remove old privileges as part of the role change, especially admin or sensitive access. Don't just add new permissions without cleaning up old ones. Re-certify access after 30-60 days to ensure it still makes sense.
What evidence should we keep for onboarding/offboarding?
Maintain an audit trail of who approved access and when it was removed. Keep offboarding checklist completion records (ticket ID + confirmation). Run quarterly access reviews for privileged roles, sensitive groups, and external guests.
Sources & References
Want onboarding/offboarding that doesn’t rely on heroics?
We can help standardize joiner/mover/leaver processes across identity, devices, and SaaS apps.
Contact N2CON