How to Create an IT Offboarding Process That Closes Every Account

A marketing director gives two weeks' notice. On her last afternoon, her identity provider account is disabled, the ticket is closed, and her laptop is in a return box. Six weeks later, the expense platform's invoice still bills for her seat, and her account there still holds approver rights, because that app was never behind single sign-on.

The IT offboarding process is the sequence that takes a departing person's access from active to provably gone, starting when the HR record changes and ending when every app they could reach confirms the removal. Most teams run the middle of that sequence well. They disable the account and wipe the laptop, then skip both ends, so the process starts late from a ticket and stops at the identity provider.

Done in full, IT offboarding has nine steps: the trigger, the clock, the revocation list, the hand-off, the cut order, the failure path, reconciliation, evidence, and measurement. Each one is a design decision you make once, before the next resignation lands.

1. Trigger the IT offboarding process from the HRIS termination record

The termination record in your HRIS should trigger the IT offboarding process, because every other start is a copy of that event that arrives later and less complete. A ticket depends on a manager remembering to file it, carries only what they thought to type, and often lands after an involuntary exit has already happened.

HR's offboarding process covers the exit itself, and its hand-off to IT should be a status change that software reads the moment HR saves it. What that change schedules depends on how the person is leaving. A resignation entered with a future date sets the cutoff for the end of the last working day, and a termination entered before the meeting sets it for the moment the conversation starts.

Once the record sets the schedule, nobody has to work a queue to start removals. Lumos Lifecycle Management treats every HRIS event as an access event, and its leaver workflow revokes access across identity providers, local accounts, custom apps, SaaS, cloud, and on-premises apps in a single pass. For Microsoft Entra ID, the offboarding step removes a departing user from every group in one action.

The same record already drives onboarding at scale. Tekion automated global onboarding on Lumos for more than 3,000 employees across 200+ SaaS integrations, and it handles more than 1,500 requests a month with 95% of tickets resolved without manual intervention. A departure is that record changing in the other direction, and it should need just as little help.

Some people never generate an HR event. Contractors, vendors, agency staff, and interns on a third party's payroll need a sponsor and an end date on their identity record from day one, and that end date becomes their trigger. If you're wiring the HRIS side for the first time, settle which HR fields can change access, since that list is the first decision in how to automate HR onboarding and offboarding.

2. Schedule access removal for involuntary terminations, resignations, and contractors

An involuntary termination, a resignation with notice, and a contractor's last day run the same IT offboarding steps, and access removal needs its own schedule for each. Most teams run one schedule for every exit, which is too slow for a firing and too blunt for someone who gave two weeks' notice.

NIST SP 800-53 leaves each of those clocks to you. Its personnel termination control, PS-4, asks you to disable access within a period you define, revoke the person's credentials, recover company property, and keep access to the information they controlled. PS-5 asks you to review and adjust access when someone transfers, AC-2 ties account management to termination and transfer alike, and none of the three sets a number of hours.

The involuntary case shows why access has to end when the person is told. A senior HR platform architect at MedAmerica learned he was being fired, and the next day he used a privileged service account on that platform to change the password on another employee's privileged account. Months after he left, he used that account to reset a contractor's password, signed in as the contractor, and overwrote records for about 90% of the company's current and former employees with dummy data. He was sentenced in January 2025 to 18 months in prison and $400,930 in restitution.

He acted within a day of being told. That's why the involuntary row below cuts privileged access as the conversation starts and rotates everything the person could reach the same day, service accounts included.

Here's a schedule by departure type. Treat the timings as starting points to tune with HR and legal.

‍

The involuntary row works only if nothing reaches the person before the conversation. In Lumos, the offboarding dialog shows which deprovisioning workflow will run for each of a person's accounts and lets an admin change it for one account without touching the rest. Lifecycle changes don't send the affected employee a notice, so IT can stage an exit and check exactly what will run before anyone says a word.

Write your own five rows this month. Then get HR and legal to sign the involuntary row before you need it.

3. Join HR, identity, and app data into one revocation list per leaver

One revocation list per leaver, joined from HR, identity, and app data, is what catches the account only that person had, like the marketing director's expense approver rights. That's why an employee offboarding checklist has to start from live access, and for IT it means building the list from the same sources, in the same order, for every departure.

Start from the HRIS record, which names the person, their worker ID, and their manager. Join their identity provider assignments and group memberships to it, then each app's account export, local accounts included, and the vault permissions that show which shared credentials they could open. Add the non-human identities the person owns, which go to the hand-off in the next section rather than straight to revocation. The job they held points to sources no export covers, like a finance lead’s bank portals or an executive’s board portal, which is why how to offboard an employee starts from the role.

Match each app account to the person on a persistent identifier, such as the HRIS worker ID or the identity provider's immutable user ID, rather than on email. Email addresses change when people change names, and apps outside single sign-on often hold accounts created under an old or personal address, so an email-only match drops them without a trace.

Some accounts won't match anyone, and they need an answer before the list is final. Search each app the person used for their name, former addresses, and any personal email on the HR record, then send the near-misses to the app owner to confirm. A second login made for testing often turns up here, and it goes on the list like any other account.

Identity governance software does that join for you, pulling HRIS, identity provider, and app data into one view of each person. In Lumos, opening a person's identity shows an Entitlements tab beside their accounts, listing each active entitlement they hold across connected apps, with its source and type. Entitlements from accounts already deactivated drop out, so what's left is the access still standing.

A deprovisioning process is only as complete as the list it starts from. Build the list on the day the departure is entered, then rebuild it on the last day so anything granted during notice makes the cut.

4. Transfer files, mailboxes, and service accounts before access ends

Transfer the files, mailboxes, and service accounts a person owned before their access ends, or the jobs and integrations that ran under their name break with it. The list is longer than most managers expect: files and shared drives, the mailbox and calendar, recurring reports and scheduled jobs, integrations they authorized, service accounts and tokens they created, and AI agents running on their access.

Timing follows the clock. With notice, the hand-off happens during the notice period, so the last day holds nothing but revocation. Without notice, containment comes first, and the manager finishes the hand-off from their side in the first week, working from the list IT already built.

Machine identities need more than a new name in an owner field, since revoking them can break production and ignoring them creates orphans. An automated non-human identity lifecycle gives each kind a departing person leaves behind its own hand-off rule, from personal access tokens to OAuth apps and agents.

One check comes before anything gets deleted: whether legal has a hold on the person's mailbox or files. A hold means the original stays after the transfer, so route that question through legal on the day the departure is entered.

Every voluntary departure gets a hand-off owner, usually the manager, and a due date on the day notice is given. If the hand-off isn't finished by the last day, revoke on schedule anyway and let the manager finish it from their side.

5. Sequence access revocation from privileged roles to shared credentials

Sequence access revocation by the damage each kind of access could do, from privileged roles down to the shared credentials the person knew, then recover devices and licenses once access is closed. Here's the order in six steps.

1. Privileged roles, production and cloud consoles, and remote access.
2. Sign-in at the identity provider, live sessions and refresh tokens, and, for a firing, a remote lock on the device.
3. Apps outside single sign-on, and local accounts.
4. OAuth grants, personal access tokens, API keys, and SSH keys tied to the person.
5. Shared credentials they could read, which get rotated.
6. Devices and licenses, recovered and reclaimed once access is closed.

Automated removals can fire together. The order governs everything they don't cover: what you cut first in a firing, which manual steps a person takes first, and what you check before moving on.

The departure type decides how fast the order runs. For an involuntary exit, steps 1 and 2 run as the conversation starts, and steps 3 through 5 finish the same day. For a resignation, the hand-off is already done, and the whole order runs at the end of the last working day.

Google's Workspace admin help spells out what step 2 involves on its own platform. Resetting a user's sign-in cookies, which suspension does automatically, signs them out of browsers and mobile devices. The reset doesn't sign them out of installed apps like Gmail or Drive for desktop, and revoking third-party app access is a separate step. Other identity providers draw those lines in different places, which is why testing that a disabled account stops working everywhere is one of the employee offboarding best practices worth writing into your runbook.

The cheapest access to cut on a last day is access that already expired. Netskope cut standing access by 80% with Lumos, pairing usage-driven least privilege with just-in-time grants that give a person a specific permission for a set window, expire on their own, and keep a record of each grant. Every standing admin grant you convert to time-based access is one less thing to cut when someone leaves.

Shared credentials are the step teams skip most, because nobody remembers who knew them. Record who can read each one when you grant it, so the rotation list for any leaver comes straight from that record.

6. Route failed and manual deprovisioning to an owner with a deadline

Some deprovisioning steps in every offboarding will fail or need a person, and each one should go to a named owner with a deadline. Otherwise the failure lives as a line in a log nobody reads.

Failures take a few predictable forms. An app's API returns an error, a connector's credential has expired, the app has no API at all, or its owner doesn't respond. The worst is the removal that half works, where the account is disabled but the license or admin role stays.

User deprovisioning fails quietly in most stacks because an error in a script doesn't page anyone. Four rules fix that. Preview what each app will do before the run starts, and send every manual step to a named app owner with a deadline that matches your clock. Retry failed calls, then escalate to a person, and keep the offboarding open until each app step is complete or an exception is logged with an owner and an expiry.

With those rules in place, each app removal shows up as done, open, or failed. In Lumos, every app ships with a default deprovisioning workflow, and failed removals become error tasks with retries. Manual steps become tasks routed to the ITSM queue you choose, and each leaver's record shows which app steps are done and which are still waiting on an app admin. Sync Circuit Breakers halt any sync that would mass-deactivate accounts, so a bad data feed can't turn the automated path into an outage.

Escalation needs a clock of its own. A reasonable starting ladder is a retry within the hour, the app owner the same day, the owner's manager the next morning, and IT security after that. For a firing, the whole ladder runs in hours. The removal request each app owner receives belongs in your offboarding communication plan, with the account, the deadline, and how to confirm it.

List every app with no API and name its owner. Then give each one a removal deadline tied to your clock.

7. Reconcile app accounts against the HR roster to catch stale accounts

Reconciling every app's active accounts against the HR roster is how you catch the stale accounts offboarding leaves behind. Your identity provider can't run that check alone, because it only knows about the accounts it manages. On a schedule, weekly at minimum, match the active accounts in each connected app, local accounts included, against the HR roster and the contractor list.

Two kinds of hits come back. Accounts that belong to someone who left mean a removal failed or never ran. Accounts that match nobody at all are the dangerous ones, since an account created under a generic name or for a test can't be offboarded by name.

Match on the same persistent key you used to build each revocation list, so a renamed account or a personal sign-up address still lands on the right person. Send accounts that match nothing to the app owner, who either names the person or purpose behind each one or agrees to disable it. Run the same check after every mass event, like a layoff, a reorganization, or an acquisition, when the roster changes faster than any queue can follow.

Some of what reconciliation turns up can surface without anyone running an export. Lumos Identity Analytics brings HRIS and identity provider data together, detects orphaned and over-provisioned accounts, and surfaces dormant ones with a fix already attached, so those findings arrive ready to close.

Payment card rules add a backstop for anything in PCI scope. Requirement 8.2.6 of PCI DSS v4.0.1 says inactive user accounts are removed or disabled within 90 days of inactivity, which catches removals that never ran as long as nobody is using the account. An ex-employee who's still signing in won't trip it, and that's the account the HR match finds.

Run the reconciliation for everyone who left in the last 90 days, across every app you can export users from. Open a task for each hit, and get an answer on every account that matches nobody by the end of the week.

8. Keep a timestamped offboarding record for SOC 2 audits

Every offboarding should leave a timestamped record that answers without a screenshot, because SOC 2 auditors test offboarding by sampling leavers and asking when each account went. The record needs six fields: the HR termination date and time, the time the process started, each app's removal time and method, who completed each manual step, any exception with its owner and expiry, and the reconciliation result.

The frameworks set the expectation and leave the deadline to you. Under the AICPA's Trust Services Criteria, the criteria behind SOC 2, CC6.2 expects credentials to be removed when a user's access is no longer authorized, and CC6.3 expects access to protected assets to be removed in line with roles and responsibilities. Neither sets a window, so your auditor tests each sampled leaver against the one in your own policy, which is why every line of the record needs a timestamp.

Evidence is cheapest when it's written down as each removal happens. Prosper centralized compliance for all of its apps in Lumos, so its evidence lives in one place. On the leaver side, Lifecycle Management keeps an audit trail of every grant and revocation, so each removal's time and method are on record the moment it runs. Access reviews need the same record, and the best user access review software logs every reviewer decision as evidence and revokes rejected access automatically.

Exceptions belong in the record too. A contractor whose engagement ends on Friday but whose final deliverable lands on Monday can keep access through the weekend, as long as the record shows who approved it, why, and the date it ends. An exception with no end date is the account your auditor will find.

9. Measure IT offboarding with time to last revoke

Measure IT offboarding with time to last revoke, the time from the scheduled cutoff to the last account confirmed gone, because time to disable measures only the step that was already easy. The cutoff comes from your clock, so a firing starts timing at the conversation and a resignation at the end of the last working day.

Four supporting numbers show where the time goes: the share of removals completed without a person, failed or manual tasks still open past their deadline, reconciliation hits per 100 leavers, and licenses reclaimed per leaver. Add the lag between the HR entry and the first removal, which tells you whether the trigger works at all. Watch the slowest app as closely as the overall number, since one app that takes nine days to confirm a removal sets your worst case every month. It's usually an app with no API whose admin nobody has asked.

The data comes from the step status your offboarding already records, so there's nothing new to collect once the failure path is in place. Set the target by departure type, since a firing and a resignation shouldn't share one.

The gap shows up in the people who've left. In Tailscale's 2025 survey of 1,000 IT, security, engineering, and development professionals in the US and Canada, 68% said they could still get into a former employer's environment after leaving. Time to last revoke is how you find out whether your own leavers would say the same.

Report time to last revoke for last quarter's leavers, split by departure type. Then set a target for each row of your clock.

Close the IT offboarding process when the last app confirms

Start from the HR record this month, write your clock and get it signed, build each leaver's list from their live access, and turn every failed removal into a task. Within a quarter, reconciliation and evidence start coming out of the process on their own, and time to last revoke tells you whether it's working.

You don't have to replace what you run today to get there. Keep the ITSM checklist and the identity provider script, and change three things first. Start both from the HR record's status change, build the checklist from each person's live access, and send every step the script can't finish to a named owner with a deadline.

Your identity provider is usually the first place a departure looks finished. An offboarding is finished when the last app confirms it, not when the identity provider says disabled.

Lumos runs that process from the HRIS event to the last confirmed removal, with failed and manual steps tracked as owned tasks and every revocation in the audit trail your auditor will sample. See how Lifecycle Management handles each stage, and book a demo with your next departure in mind.

‍