5 Steps in The Offboarding Process to Follow For Every Departure

Ask the head of HR and the IT director at the same company whether they have an offboarding process, and you'll get two yeses describing two different things. HR describes the final paycheck, the benefits letter, the exit interview, and the laptop coming back. IT describes a ticket queue and a script that disables an account. Both are right, and the process is only as strong as the place where their halves meet.

The offboarding process is everything a company does when someone leaves, from closing the HR record to confirming that every account the person could use is gone. In between come the notices, final pay and paperwork, device return, handing off work, and removing access, the steps any employee offboarding checklist lists.

Those steps barely differ from one employee offboarding process to the next. What drives them does. Each of the five steps in this article is defined by what the process runs on: someone remembering to tell IT, tickets and a template, the identity provider, a record of every account, and daily policy. Once you know which one runs yours, you'll know where your process leaks and which move comes next.

Step 1: Make sure every departure reaches IT

When offboarding runs on someone remembering to tell IT, the departures nobody mentions are the ones that keep their access. HR knows the date, the manager sends an email or a chat message when they think of it, and IT acts on whatever arrives.

At this step, the HR offboarding process and IT's work are two separate lists joined by a message. HR assumes IT knows because HR told the manager, and the manager assumes HR told IT. When a contractor's engagement ends on a Wednesday or an employee moves to another team, nobody sends anything, since nobody calls either one a departure.

Every one of those exits depends on a notice from HR to IT that nobody owns. Deciding who sends it, to whom, and by when is the first job of an offboarding communication plan.

A September 2026 audit by DHS's inspector general shows what removal that depends on people looks like at scale. Reviewing US Customs and Border Protection, it found that 20% of sampled employee accounts and 15% of the contractor accounts it identified weren't promptly disabled after the person left. Among employees who transferred, 17% kept access they no longer needed. CBP told the inspector general the lapses traced to human error and an inability to track how access changed over time.

Reminders and manager training make people remember more often. The process still runs on memory, though, so every departure nobody mentions stays open until someone stumbles on it.

Step 2: Cover the access your offboarding template misses

A ticket is the first real record offboarding gets, and its weakness is the template it carries. A ticket filed from an HR or manager form gives every departure a timestamp, a queue, and an owner, which step 1 never had. When someone asks whether a leaver was offboarded, there's finally something to look up.

The ticket's tasks come from a template of the apps everyone in that role gets. The admin role someone granted by hand isn't on it, and neither is the app a person got through a one-off request or the tool they signed up for with a work email. Those accounts come from the person's job, which is why how to offboard an employee should start from what their role gave them. HR files the ticket, watches it close on the last day, and reasonably reads that as done.

Access requests exist for whatever the template didn't grant, so the request queue is where step 2's blind spots come from. Before Lumos, ChargePoint ran access requests and access reviews manually through tickets and spreadsheets, and its IT team fielded 500 to 600 access request tickets a month across more than 70 applications. That's hundreds of one-off grants a month, the kind a role template doesn't list. Lumos has taken over 80% of those tickets, and once requests run through the same platform as offboarding, each grant sits where its removal can find it.

A closed ticket records that the template ran, and the person can still show up in an app's user list weeks later. The queue behind the ticket also grows with every hire and every departure. How fast a leaver's access goes ends up depending on how busy IT is that week.

Step 3: Find the accounts your identity provider can't disable

step 3 connects the HRIS to the identity provider, the sign-in service employees use to reach most of their apps. Once a status change in the HRIS disables that account on its own, the timing failures of the first two steps go away. With no message or ticket in between, everyone with an HR record loses sign-in on schedule, and the dashboard turns green.

That green dashboard is why processes stall here. The identity provider reports "disabled," and nobody has a reason to look further, but "disabled" describes one account out of however many the person had. The sign-in service can't see the apps people log into with a password, the admin accounts created inside apps, or the paid seats that stay assigned after sign-in stops.

Take a marketing manager whose last day was a month ago. Her identity provider account went off on schedule, but the design tool her team put on a company card still lists her as an admin, and next month's invoice still bills her seat. Apps like that pile up for ordinary reasons: vendor portals issue their own logins, and some admin consoles never supported single sign-on (one sign-in that opens every connected app) at all.

This is also the step where HR's data becomes the trigger. A termination date entered late, or a contractor never entered at all, now moves access directly, so the accuracy of the HR record turns into a security control.

Rules written about departures ask for more than a disabled sign-in. New York's cybersecurity regulation for financial firms, amended in 2023, requires covered entities to "promptly terminate access following departures," and those requirements took effect in May 2025. The rule's word is access, and access reaches well past one sign-in.

Getting off step 3 starts with a list of the accounts that exist in each app, which is a different list from the accounts the identity provider assigned. That inventory is what step 4 works from.

Step 4: Remove every account from one record

Working from a record of every account is what makes offboarding complete. step 3 is fast, but it stops at the identity provider. Step 4 is the first step that can hold every account to a deadline, because it's the first that knows what every account is. The HRIS event still starts the work, but the list comes from the account record, so nothing on it depends on what someone remembered or what a template assumed.

Each app on the list gets an offboarding workflow. Apps with an API (a way for software to make the change) remove the account automatically. Apps without one become a task for a named app owner, and the offboarding stays open until every app reports back. Building the per-person list, ordering the cuts, and handling removals that fail are the mechanics of an IT offboarding process, and they're where most of the engineering lives.

For HR, this is the first step where "is this person fully offboarded?" has an answer. A secure offboarding process can prove every account is gone, including the ones outside single sign-on, and the proof sits in a record HR can ask for.

Proposed deadlines are getting tighter. In January 2025, HHS proposed that HIPAA-regulated organizations end a departing workforce member's access within an hour of their employment ending, and sooner where possible. The rule is still a proposal, with final action projected for July 2027, and an hour is out of reach for any app that waits on a ticket.

At step 4, the hour is within reach for every app that removes automatically, and the apps that still need a person are where it gets lost. That's why the workflow has to reach every kind of account the record holds. Lumos Lifecycle Management treats each HRIS event as an access event, and an offboarding event revokes access across identity providers, local accounts, custom apps, SaaS, cloud, and on-premises apps at the same time.

step 4 removes everything, but it removes it late. Every entry the person hadn't touched in months is access they didn't need the day before they left, and the longer the list runs, the more of that there was.

Step 5: Trim access with policy before anyone leaves

A step 5 last day is short, because policy removed most of the person's access on the days they stopped needing it. Access granted for a project ends when the project does, access nobody uses gets reclaimed, and a move to another team removes the old team's access the day it happens.

Scheduled access reviews catch what the rules missed, and reviewers spend their time on the exceptions. Reviews matter more here than anywhere else in the model. Rules handle the access you can predict, and reviews handle the access someone granted for a reason nobody wrote down, which is what's left once the rules are in place.

At this step, the employee onboarding and offboarding process turns into one set of rules applied on the first day, the last day, and every day between. That changes what HR's data does. Role, manager, and department changes now drive removals, so HR's mover data matters as much as its leaver dates.

Rules set by app and role are what let access run without a person in every request. Intercom built autonomous identity for more than 1,200 employees on Lumos, moving off provisioning and deprovisioning that was largely manual and heavy on IT toil. Most requests are now self-service under policies set by app and role, and rule-based access simplified reviews enough that IT handles most of them and sends only true exceptions to app owners.

The day someone leaves, the removal list is short. It's mostly the access everyone in the role gets. The project tools, the elevated grants, and the apps the person stopped opening came off during the year, as each one came due.

Agents now take the routine review and request work too. In Lumos's Identity Agent Force, the Access Review Agent runs reviews end to end and brings people only the items that need a human call. The Access Request Agent grants access for as long as someone needs it, then revokes it on its own. People set the policies, guardrails, and approval thresholds the agents work inside.

The same rules carry over to AI agent offboarding, when the identity leaving is an agent someone built. Either way, once this step is in place, the people running offboarding spend their time on the calls a rule can’t make.

Compare the five steps of the offboarding process

Side by side, the five steps look like this. Read across a row to see what each step misses and how that gap shows up in your own records.

‍

Your process sits at the step of its weakest step. Say you've connected your HRIS to the identity provider for employees but still offboard contractors by email. You run a step 3 process for employees and a step 1 process for contractors, and the contractors are where the risk sits.

The group most likely to pull your step down is the one without an HR record, because nothing in the HR data starts its offboarding. Finding that group is most of the value of knowing your step.

Score your offboarding process in one afternoon

You can score your process on this model with last quarter's leavers and five questions. The first four fit in an afternoon, and the fifth only matters if they put you at step 4. HR pulls the leaver list, with contractors and transfers on it, and IT adds the time it first acted on each leaver, its offboarding records, and a few app user exports.

‍

Score employees, contractors, and transfers separately, and give each group the lowest step any of its answers points to. A team with a connected HRIS can answer the first question well and still score a 3 on the third, and that gap shows exactly where to start.

Write the step for each group on one page. Then share it with whoever owns the other half of the process, because neither half can move the step alone.

Write an offboarding plan for one step at a time

Move your process up one step at a time, because automating a step you haven't reached carries its gaps along at machine speed. Each move takes one change, in this order.

• From 1 to 2: write an offboarding policy that says who tells whom, by when, for each kind of departure, and make a ticket mandatory for every one.
• From 2 to 3: connect the HRIS to the identity provider once HR has cleaned up the records that break automation.
• From 3 to 4: build the account record and give every app without an API a named owner.
• From 4 to 5: turn your most common grants into role policies, give project and elevated access end dates, and put access reviews on a schedule.

Each move also changes who owns the work. At steps 1 and 2, IT does every task and HR sends notice. At step 3, HR offboarding work becomes data work, because the termination date and time are now the trigger. From step 4 on, app owners handle removals in apps without an API, policy owners write the rules, and reviewers decide the exceptions.

Skipping a step automates its gap. Connect the HRIS while contractors still live outside it, and contractors get a step 1 process behind a step 3 dashboard. Write the offboarding plan for the next step only, with one owner and one date, and when you shop for employee offboarding software, buy for that step first.

We built autonomous identity the same way. Autonomy doesn't arrive all at once, so the path runs from manual processes to policy one stage at a time, and each stage gives the next something solid to automate.

Name the owner of your next move, and give them a date this quarter. One step, one owner, and one date is a plan small enough to finish.

Shorten the last day of your offboarding process

Take the group that scored lowest up one step before you touch anything else. That's the group where former employees keep their access, and the one whose leavers you'd least want an auditor to sample. Fixing it moves your whole process.

Every step after that shrinks the work waiting on the last day. A mature offboarding process makes that day short, and a short list is one you can clear inside a deadline counted in hours.

Lumos starts offboarding from the HRIS event and works across every kind of account the record holds. With autonomous identity, it keeps access trimmed during employment through policy and access reviews, so the last day has less to remove. See how Lifecycle Management handles the leavers on your list, or start with a free identity assessment. In 30 minutes, it shows what your identities can reach, including over-provisioned access and orphaned accounts.

‍

‍