The Employee Offboarding Checklist for Every Type of Departure

An engineer’s last day was Friday. IT disabled her single sign-on account that afternoon, and HR closed the offboarding ticket. A week later, two apps she used outside single sign-on still accepted her password, and a token on her laptop could still reach production.

The shared admin password she kept in the team vault hadn't changed, and the nightly export job she wrote was still running under her name. Nothing on the checklist was skipped. None of it was on the checklist.

An employee offboarding checklist is the ordered list of steps HR, IT, security, and the manager complete when someone leaves, so their access, data, devices, and obligations close out on schedule and with proof. Most teams run an offboarding checklist written months ago from the apps IT knew about. The version that holds is built from what the person can reach on the day the departure is confirmed, and it isn't finished until every removal is verified.

The ten steps in this article run in the order you'd work them, starting with the HR record that sets the clock. From there they cover the notice period, the hand-off of what the person built, the cut itself, and the proof your auditor will ask for. Each one opens with its rule, and a one-page recap with owners and timing closes out the list.

1. Start offboarding the moment HR records the departure

Offboarding starts when HR records the departure in the HRIS, and the type of exit decides when access goes. A resignation email sitting in a manager's inbox, or a ticket filed the morning after, leaves IT working from hearsay. The HRIS record carries the date, the type of exit, and the manager, which is everything employee offboarding needs to start on time.

Ask HR to enter the termination date and type as soon as the decision is made. For an involuntary exit, that means before the meeting, and it's the difference between cutting access while the person is in the room and cutting it after they've gone home with a laptop.

Some auditors already hold you to a clock. PCI DSS Requirement 8.2.5 says access for terminated users is "immediately revoked," and assessors test it by comparing information about terminated users against current access lists for local and remote access. Most other frameworks leave the window to you, which is why yours needs to be written down.

A sensible default takes privileged access just before the meeting for an involuntary exit and everything else during it. Resignations lose access at the end of the last working day, and contractors on the end date set when their account was created. The IT offboarding process breaks that schedule down by stage, from before the conversation to the 30-day close-out.

Once the schedule is policy, the trigger has to fire without anyone filing a ticket. Lumos Lifecycle Management runs the leaver workflow from the HRIS, while Albus, our AI agent, watches each person's role, department, manager, and status for the change that starts it. If you're wiring those HR fields for the first time, the guide to how to automate HR onboarding and offboarding covers which ones should be allowed to change access.

Get HR and legal to sign the schedule before you need it. Then send it to each app owner who removes accounts by hand, because they're on the clock too.

2. Build the leaver's checklist from their live access

Generate the access half of the checklist from what the person can reach today, since last year's template only lists the apps you knew about then. A person's access comes from what their groups granted, what they requested along the way, what they created, and what they hold outside the identity provider. A template covers group grants well and guesses at the rest, and the longer someone stays, the more of their access lives in the other three.

The generated list pulls from identity provider assignments and groups, each app's account list (local accounts included), admin roles, cloud console users, password vault permissions, devices, licenses, and anything the person owns (step 4). Built that way, your IT offboarding checklist becomes a view into workforce identity and access management, with each line traceable to a grant and an owner who can remove it.

We run our own IT offboarding this way. When Lumos sees a departure come through the HRIS and identity provider sync, it builds a checklist from the person's live access and notifies each app owner automatically. As our Director of IT describes it, IT nudges owners from inside Lumos when a task stalls, and each step lands in an auditable trail. Revocation covers the identity provider, SaaS apps, and on-premises tools without a Jira ticket or a spreadsheet.

To size the gap, compare the apps on a recent leaver's checklist with the apps they held accounts in. The difference is your template's blind spot, and it applies to everyone the template touches.

3. Lock down sensitive access during the notice period

For anyone with sensitive access, offboarding starts the day they resign, and the review reaches back a month before that. The Common Sense Guide to Mitigating Insider Threats from Carnegie Mellon's Software Engineering Institute recommends that when someone with access to sensitive intellectual property resigns, HR alert the incident response team and the insider risk program. Those teams then review activity logs with attention to the 30 days before and after the resignation.

Part of the risk sits in the weeks before anyone says a word, so the look-back matters as much as the watch that follows. For offboarding employees in sensitive roles, the notice has to reach security the same day, and a resignation that sits in a manager's inbox for a week costs you a week of both.

The notice-period plan itself is short. Remove the admin rights and bulk-export permissions the hand-off doesn't need, and keep the day-to-day access the person needs to finish their work. Send any new access request from a leaver to security, set the end time on the account now, and review downloads and exports from the month before. If they're leaving for a competitor, cut access at notice, the way you would for an involuntary exit.

Trimming admin rights at notice is easier when there's less standing admin access to trim. Code42 reduced privileged access by 67%, using time-based access to critical apps that Lumos removes within a few hours, so most of its admin access ends on a schedule without waiting for anyone to resign.

Most people who resign are doing nothing wrong, and this plan protects them as well, since a clean record at departure is the easiest way to show it. Decide in advance which roles get the plan, so nobody has to work out how to offboard an employee they know well on the day that person hands in their notice.

4. Hand off what they built before you switch off their identity

Before you disable anyone with technical access, move what runs under their identity to a new owner. Some of it stops when the account goes dark, and some of it fires.

According to the Justice Department, a software developer at a company headquartered in Beachwood, Ohio, planted code named "IsDLEnabledinAD" that would lock out all users if his Active Directory account was disabled. When the company placed him on leave in September 2019, the code fired and hit thousands of users worldwide. He was sentenced to four years in prison in August 2025.

That was sabotage, and most load-bearing identities are accidents. A developer writes an export job under their own credentials, or authorizes an integration with their own account, and moves on. Either way, disabling the account first is how you find out what depended on it.

Before the account changes state, inventory the service accounts and workload identities the person owns, along with their personal access tokens and API keys. Add the OAuth apps they authorized, scheduled jobs and CI pipelines running under their credentials, code that references their username, and any AI agents they own. Each type has its own hand-off rule, and an automated non-human identity lifecycle starts applying them on the day of the departure. Agents follow their own leaver steps under AI agent lifecycle management.

This goes faster when owners were recorded before anyone resigned. Lumos maps each non-human identity in your environment, such as a service account or workload identity, to the person who owns it (the feature is in beta), so a resignation shows you what needs a new owner.

Build the hand-off list as soon as the departure is known. Start by searching your repos, schedulers, and CI secrets for the person’s username, since anything that references it can break or fire when the account goes dark. For an involuntary exit, security builds the list before the meeting, and for a move to a competitor, it happens at notice.

5. Disable the identity provider account and end every active session

Disabling someone in your identity provider stops new sign-ins, and the sessions apps have already issued keep working until they expire or someone ends them. A browser session in a SaaS app, an app password on a phone, and an OAuth grant to a third-party tool each answer to the app that issued them, so they can outlive the disable.

Run the cut in one window, in this order. Each step closes something the one before it leaves open.

• Transfer ownership of any groups the person owns, then remove them from every group, so group-granted app access drops with it.
• Disable the account, and hold off on deleting it until step 8 is done.
• Revoke sessions and refresh tokens at the identity provider.
• Sign the person out of the apps that keep their own sessions, starting with mail, chat, file storage, and anything with admin rights.
• Revoke the app passwords and OAuth grants they created.
• Remove MFA factors and passkeys, so their phone and keys stop working if the account is ever re-enabled by mistake.
• Remove forwarding rules and delegated mailbox access the person set up, then retire or wipe managed devices along with their certificates.

Offboard a test account this week, then try its old sessions in your three most-used apps the next morning. Whatever still loads needs its own line here, and repeating the test after any change to your identity provider or device management is one of the employee offboarding best practices that keeps the list current.

6. Remove the accounts your identity provider doesn't control

Apps your identity provider doesn't control keep the leaver's account until someone removes it in the app. That includes apps with their own logins, local admin accounts, cloud console users and access keys, on-premises tools, vendor and partner portals, and reporting tools. It also includes apps that use single sign-on without automated deprovisioning through SCIM or an API connector, where the identity provider blocks the sign-in and the account itself stays put.

Block's SEC filing from April 2022 shows what one surviving grant can cost. A former employee downloaded Cash App Investing reports on December 10, 2021, reports they'd had regular access to in their job and accessed without permission after their employment ended. The company began contacting about 8.2 million current and former customers.

The filing doesn't say where that access lived or why it outlasted the job. The lesson holds either way, since access granted for a job ends only when someone ends it app by app, which is the whole discipline of user deprovisioning.

Lifecycle Management runs the leaver workflow across identity providers, local accounts, custom apps, SaaS, cloud, and on-premises apps at once. Where a removal still runs through a ticket, you can route access tickets, deprovisioning included, to the ITSM queue that owns them. Marqeta automated onboarding and offboarding across more than 150 apps in its first two months on Lumos, part of cutting the manual, ticket-based processes behind onboarding, offboarding, and access reviews.

For the apps that remain, the removal belongs to a named owner with a deadline. Put that name on the checklist next to the app, so a missed removal has someone to call.

7. Rotate the shared and privileged credentials they knew

A shared password still works after its holder leaves, which makes each shared and privileged credential the leaver could see a rotation job. NIST SP 800-53 sets the scope. Its personnel termination control, PS-4, asks you to disable access within a period you define and to terminate or revoke any authenticators and credentials associated with the person.

We read "associated with" to include the credentials they shared, and that's the part teams skip. Build the rotation list from the vault's permissions, which show what the person could open, and use its access log to rotate what they did open first. Then add the secrets that never lived in the vault.

• Break-glass and root accounts
• Shared admin logins
• SSH keys and cloud access keys on hosts they managed
• Service passwords they set
• VPN and Wi-Fi keys

For resignations, rotate after the last day. For involuntary exits, rotate anything privileged during the meeting window. And drop the habit of collecting a leaver's passwords to hand to their replacement, which turns one person's secret into two.

The lasting fix is fewer shared secrets. Each one you move behind per-person access, starting with the vault entries the most people can open, is one less rotation the next time someone leaves.

8. Move their data to a new owner and reclaim their licenses

Move the leaver's data to a named owner before you delete anything, then take their licenses back. The same NIST control asks you to retain access to the organization's information and to whatever the person controlled, and in practice that's a short list.

• Transfer drive files and shared-link ownership to the manager.
• Convert the mailbox, or forward it to the manager for a set period with an end date, and set an auto-reply.
• Move calendar ownership, including recurring meetings the person organized.
• Check legal hold before anything is deleted.
• Remove or downgrade the licenses.
• Delete the account only after the forwarding window ends and any hold clears.

License reclamation pays for the rest of the process. Roku estimated that with 95% of its licenses provisioned, real use might be closer to 40%, and Zoom Pro users who never hosted a meeting could be moved to a free license automatically. Roku's estimate covers everyone on staff, and a leaver's seat is the one case that needs no judgment call, so each month a checklist skips it, you pay for an empty chair.

Total the licenses still assigned to people who left in the last 90 days. That number is your first reclamation target.

9. Verify every removal and keep the evidence

A closed ticket proves someone clicked a button, so check each removal in the app itself and keep the proof. Proof means the account's state in the target app (from its API or user list), who removed it, when, and what was removed. Without it, your offboarding process ends at whatever the last person to touch the ticket believed.

Then reconcile on a schedule, at day 7 and day 30 after the last day. Compare HR's list of leavers with the account list of each app, local accounts included, and treat every unexplained match as an incident with an owner. It's the same comparison a PCI assessor runs, and the day-30 sweep catches accounts a stale sync recreated along with the ones nobody knew existed.

Failed removals hide in logs nobody reads, which makes failure handling the first thing to test in any employee offboarding software. Offboarding in Lumos runs on Account Workflows, the deprovisioning workflow each app or entitlement gets, so a removal that fails becomes an error task with a workflow record and retries.

Access reviews are the net under all of it, since a leaver account that survives both sweeps should surface in the next campaign of your user access review software. In Lumos, review removals run on the same deprovisioning workflows as offboarding, so a leaver account caught there leaves the same record as one removed on the last day.

Run your first day-30 reconciliation this week against the people who left a month ago, and count what it finds. That count belongs in front of whoever owns the checklist.

10. Run the same checklist for movers and contractors

Run the leaver checklist for movers and contractors too. A mover leaves their old role, and a contractor leaves on a date you already know.

Movers are the hardest part of joiner-mover-leaver, since their old access piles up unless someone deliberately takes it away. Run steps 2, 4, 6, 7, and 9 against the old role's access, along with the group removals from step 5, and give the person a short overlap window with an end date for the hand-off. When the window closes, the old access goes the way a leaver's would.

Contractors and vendors are easier to miss. Their accounts often have no HR record, so the HRIS never fires a leaver event for them, and contractor offboarding falls to whoever remembers. Set a sponsor and an end date when the account is created, and let the account end on that date unless the sponsor renews it. Any existing account with no HR record and no sponsor behind it should get both this month.

A recap of the offboarding checklist in ten steps

Put together, the ten steps above fit in one table that HR, the manager, IT, and security can all work from when the next departure lands. Each row names the step, who owns it, when it runs, and what proves it's done, so whoever picks up a departure can see whose turn it is without digging through a ticket thread.

HR's own tasks (final pay, benefits, the exit interview, and signed agreements) run alongside these steps. Involuntary exits run the same steps on a faster clock, so the table doubles as an employee termination checklist. Steps 3 through 7 cover the security work a typical offboarding security checklist squeezes into a single line.

‍

Copy the table into the ticket or workflow for each departure, and put a name and a date in each row before the cutoff. The proof column becomes the evidence step 9 asks for, so a departure is done when that column is full.

Build offboarding around what people can reach

Your employee offboarding checklist is only as good as the list it starts from. A template written for the access you knew about lets your leavers carry the rest out the door, while a list generated from live access, cut on a written schedule, and checked app by app closes that gap.

Start with the next departure. Generate the list from what that person can reach, run the cut in one window, and check each removal at day 7 and day 30. One clean offboarding with evidence makes the case for the rest.

If you'd rather every departure ran that way without a ticket, Lumos starts the leaver workflow from your HRIS and builds the list from each person's access. It removes that access across your identity providers and the apps behind them in one pass, and failed removals come back as tasks with a record, so the evidence builds as the work happens. Book a demo and bring your next departure, or see what to look for in employee offboarding software first.

‍