Employee Deprovisioning: The Definitive Guide

An offboarding goes wrong the same way almost every time. Someone leaves, HR closes the file, and three weeks later an auditor asks who still has access to the CRM. Nobody has a clean answer.

Deprovisioning is the process of pulling an employee's access the moment it should end: identity, apps, licenses, hardware. It breaks because that access sits across the HRIS, the identity provider, and a long tail of apps neither system fully controls, the same gap that trips up the access control basics most teams think they've already covered.

This guide covers the canonical process, the compliance controls behind it, and how automated deprovisioning chains those systems together. It also covers the contractor and role-change variants, the audit trail an auditor will accept, and the numbers worth tracking afterward, with a forwardable checklist and a look at the tools built for it.

TL;DR

• Deprovisioning fails when nothing connects the HR event to every downstream app.
• The process runs in six steps: HR trigger, identity suspension, app-by-app revocation, hardware recovery, knowledge transfer, and evidence.
• SOC 2, ISO 27001, and HIPAA all require timely removal and evidence that it happened, and none of them names a universal deadline. Your own policy sets the clock you get tested against.
• Role changes and contractor exits run the same revocation with a different trigger, which is where most surviving access accumulates.
• An audit trail needs to answer four questions automatically, and four numbers show whether the process works, from the time to revoke through the share of revocations that run without a person.
• Siit orchestrates that chain across your existing IdP, apps, and HR system, so deprovisioning runs on policy, with an audit trail attached.

Why Deprovisioning Breaks

Deprovisioning fails less often because a tool can't revoke access, and more often because nothing connects the HR event to every downstream app in the first place. IT owns the identity provider. HR owns the termination date. Finance owns the SaaS contracts nobody remembers to check. Each system does its own job correctly, and the handoffs between them are where access survives.

The numbers back this up. In OneLogin's survey of 500 US IT decision-makers, 50% reported that ex-employee accounts stayed active for longer than a day after departure, 48% were aware of former employees who still had access to corporate applications, and 20% linked a data breach directly to a deprovisioning failure. That's a connection gap between HR, the identity provider, and the long tail of apps neither one directly controls.

What Compliance Frameworks Actually Require

No major framework names a universal deadline for revoking access. Each one requires that removal happens on a timeline you have defined, across every system in scope, with evidence that it happened. The commitment written in your own access control policy becomes the bar you get tested against.

SOC 2

Two of the common criteria carry the requirement. CC6.2 covers registering and authorizing users before credentials are issued, and removing those credentials once access is no longer authorized. CC6.3 covers authorizing, modifying, and removing access based on roles and responsibilities, with least privilege and segregation of duties in scope. Auditors test this by sampling departures and comparing HR records against system logs, so a departure with no log entry for a given application reads as a control gap even when the access was in fact pulled. The criteria are published in the AICPA's trust services criteria.

ISO 27001

Annex A control 5.18 in the 2022 revision requires that access rights be provisioned, reviewed, modified, and removed in line with the organization's access control policy. Two things follow from that wording. Periodic review sits inside the same control as removal, so an access review cadence is part of what the control asks for. And control 5.11, covering return of assets, puts the hardware recovery step on the same footing as the identity and app steps.

HIPAA

The Security Rule addresses this at 45 CFR 164.308(a)(3)(ii)(C), which requires procedures for terminating access to electronic protected health information when employment or another arrangement with a workforce member ends. Two details matter operationally. The specification is addressable rather than required, meaning it must be implemented, met through an equivalent alternative, or documented as not reasonable and appropriate. And the phrase covering another arrangement pulls contractors, temporary staff, and vendor personnel into the same control as employees.

That last point is under review. HHS published a proposed update to the Security Rule in January 2025 that would remove the addressable designation and tighten the timeline for terminating access. It remains a proposed rule as of August 2026, and the current Security Rule stands in the meantime.

What This Means for Your Access Control Policy

Read together, the three frameworks ask for the same three things: a defined timeline, coverage of every system a person could reach, and a record of each action. Speed is what your policy commits to. Consistency is what gets audited.

The practical consequence is that the access control policy needs to be specific enough to test and realistic enough to hit. Name a separate target for identity suspension and for full app revocation, since one runs in minutes over API and the other depends on how much of your stack is federated. State which systems are in scope and how the ones outside SSO get handled. Say who is accountable when the timeline is missed. A policy promising immediate revocation across all systems fails its first sample; one promising identity suspension within minutes of the HR event and full revocation within one business day is defensible because it matches what the mechanism can actually do.

The Six Steps of the Deprovisioning Process

Every deprovisioning event follows the same sequence, whether it runs by hand or gets triggered automatically. Here's the canonical order, and what has to happen at each step:

1. HR trigger. The termination or role change gets recorded in the HRIS, the single event everything downstream should key off.
2. Identity suspension. The identity provider (Okta, Entra ID, JumpCloud) disables the account and forces session termination.
3. App-by-app revocation. Every connected app, SSO-federated or not, gets access pulled: licenses reclaimed, sessions killed, API tokens revoked.
4. Hardware recovery. Devices get locked or wiped, with return logistics tracked as their own step.
5. Knowledge transfer. Shared drives, ticket queues, and Slack channel ownership get reassigned while the account is still active, ahead of the final step.
6. Evidence. Every action in steps 2 through 5 gets logged with a timestamp and an actor, the record an auditor will ask for.

Run by hand, this sequence takes a person working through six separate systems, each one a chance for a step to get skipped. Run through orchestration, the same six steps happen as one connected chain, the difference the rest of this guide covers.

The Deprovisioning Checklist

Copy this into your ticket template or your runbook. The owner column is the part most checklists leave out, and it is what stops a step from sitting unclaimed between two teams. The evidence column is what an auditor samples.

Two additions worth making before you forward it. Add a row for any system that sits outside the identity provider in your stack, and name the person accountable when a step misses its deadline, which is the field auditors ask about when the log shows a gap.

How Deprovisioning Works for a Role Change

A role change runs the same six steps against a narrower target, with hardware recovery dropped and knowledge transfer reduced to whatever the person is handing over. The account stays open, which is exactly why this variant leaks. The trigger is the harder half. A termination usually writes a clean status change in the HRIS that downstream systems can key off, while a promotion or a transfer often writes a field update instead, so the workflow has to watch the department, manager, or job title field rather than an employment status. Teams that automate terminations and leave role changes manual usually discover this the first time an access review surfaces someone carrying two roles' worth of permissions.

Revocation targets only what belonged to the old role. Group membership changes while the account stays open, licenses move between teams, and any access tied to the previous manager's approval chain needs re-approval under the new one. The asymmetry is where it goes wrong. Granting the new access is urgent because the person cannot work without it, and removing the old access is urgent to nobody. Both halves have to live in the same change for least privilege to hold.

Evidence works the same way as a termination, with one difference auditors notice. The account never closed, so the log is the only thing showing that the old permissions came off. Where a termination leaves a disabled account as corroborating proof, a role change leaves nothing but the record, and if your access review and your role-change log disagree about what someone can reach, the review is what gets questioned. The practical move is to treat every role change as a scheduled review of everything that person can currently reach, which costs a few minutes at the point of change and clears the accumulation that annual reviews exist to catch.

Contractor and Vendor Deprovisioning

Contractor access outlives contracts because no HR event marks the end. A contractor often has no HRIS record at all, and the person who knows the engagement finished is the project sponsor, not IT or HR. Nothing fires, so nothing gets revoked, and the account sits active until someone runs a review.

The fix is to set the end date at the start, when access is granted rather than when it expires. Time-bound access turns the absent HR event into a scheduled one. The engagement length becomes the expiry, and the sponsor who requested the access is named on the record as the person accountable for extending or closing it. Extensions then require a decision, which is the point.

Siit's App Access Policies support this directly. A role can require an access duration on the request, the resulting App Access record carries that expiration, and Siit creates the deprovisioning task on the morning it expires. The record has its own lifecycle independent of the request that produced it, so closing the ticket does not cancel the scheduled deprovisioning.

Three access patterns need handling beyond a scheduled expiry, because the thing being revoked is not an individual account:

• Shared and service accounts. Revocation here means rotating the credential and updating whatever depends on it, since there is no individual account to disable. Both need a named owner recorded somewhere durable, because the alternative is discovering during an incident that nobody knows what the credential is used for. The same applies to API tokens and OAuth grants a contractor created, which survive the account they were issued under.
• Agency and outsourced staff. They have an employment record, just not in your HRIS, so the departure event fires in a system you cannot read and often will not be told about. The workable arrangement is to make the agency's account manager the named owner of every access record for their people, with a standing obligation to report changes, and to keep the expiry date short enough that a missed report closes the access anyway.
• Vendor and partner access. Third-party support staff, implementation partners, and auditors typically get access under a contract with its own end date, held by procurement or legal rather than IT. Worth mapping those dates into the same expiry mechanism as contractor access, since a contract that ended in a system nobody in IT reads is functionally the same problem as a departure nobody reported.
  

Manual vs. Scripted vs. Orchestrated Deprovisioning

Most teams don't choose their approach on purpose. They start manual, bolt on scripts as the SaaS stack grows, and only reach for orchestration after a bad audit or a departure that slipped through. Here's what separates the three, and where each one breaks.

Manual means someone works the six steps by hand across every system. It's fine for a five-person company with three SaaS tools. Past that, a step eventually gets missed.

Scripted means a script or a handful of Zapier-style automations handle the identity provider and maybe the top few apps. It closes the biggest gaps but still needs someone to maintain the script list, and it usually stops at the apps someone remembered to script for.

Orchestrated means the HR event triggers the identity provider, which triggers app-by-app revocation, with approval checkpoints and an audit log generated as a byproduct of the workflow. This is identity automation done right, the only version that scales past a few hundred employees without a dedicated headcount to run it.

Inside the Automated Deprovisioning Chain

Automated deprovisioning fires the identity provider suspension over API the moment the HR event is recorded, with no delay waiting for someone to notice. From there, SCIM or direct API calls push revocation to individual apps outside SSO, and sensitive steps route through the approval workflow itself before they execute.

Siit's App Access Policies, generally available since June 2026, run this chain end to end. Per-application roles define who's eligible, what approval flow applies, and how access provisions, automatically or through an app owner. The same policy governs the exit, supporting scheduled deprovisioning set at the time approval was granted.

Siit sits alongside the identity provider as the layer that connects the HR event to the IdP and the apps around it, with the approvals and audit log attached.

What Your IdP Doesn't Cover During Deprovisioning

Okta, Entra ID, and JumpCloud handle SSO-federated apps well, and three kinds of access sit outside their reach. Apps bought on a company card and never wired into SSO have no federated identity to suspend. Shared accounts, a single Figma seat or social login used by a team, have no individual identity either. Licenses that attach to a workspace or a project rather than a person survive an identity suspension because they were never tied to the person in the first place.

Orchestration closes all three by extending revocation to the apps and access patterns the IdP was never built to see, the mirror image of the inbound provisioning side of the same problem. For the app-layer mechanics, including how to phase this in without starting a tool war, see our walkthrough on avoiding orphaned permissions.

The Deprovisioning Audit Trail: What Auditors Actually Ask For

Deprovisioning without a record is invisible to everyone except the person who did the work, and an auditor won't accept that as evidence. The trail needs to answer a short, consistent list of questions every time:

• Who approved this access, and when?
• Who currently has access to this system?
• What did the system actually do when the person left?
• Where's the record, and how fast can it be produced?

Answering all of that means the trail writes itself automatically as each action happens. Siit is SOC 2 Type II certified and GDPR compliant, and the trail it generates is built to answer those four questions without anyone assembling it.

What to Measure After Deprovisioning

Four numbers tell you whether the process works, and all four come out of the same log that satisfies the auditor.

1. Time to identity suspension. The gap between the HR event and the account being disabled in the IdP. Track the median and the worst case separately, because the worst case is what an audit sample surfaces. A median of four minutes with a worst case of nine days describes a process that works except when it matters.
   
2. Time to full app revocation. The gap between the HR event and the last application closing. The distance between this number and the first one is the size of your manual tail, expressed in hours. Watching it narrow is the clearest signal that wiring another integration was worth it.
   
3. Orphaned account count. Accounts still active in an application with no matching active person. Producing this figure means reconciling each app's user roster against the people record, which is also why it needs to be tracked alongside SaaS inventory coverage. An orphaned account count of zero across 40 known apps means nothing if the company runs 90.
   
4. Share of revocations automated. The proportion of revocation actions that executed without a person, broken out by application. This is the number that tells you where to spend the next integration effort, since it names the apps that consume the most manual minutes per departure.
   

Baselining these takes one afternoon rather than a project. Pull the last ten departures, then for each one find the HR event timestamp and the timestamp of the last access that came off. Two of the ten will come back worse than anyone expected, and those two describe the process as it currently runs. Re-measure after each integration you wire in, using the same ten-departure sample size, so the comparison stays honest as volume changes.

Siit's Active Users tab reconciles each app's live roster from the connected IdP, App Access records, and direct adds, showing where each person's access came from. That makes the who-has-access-and-why question a query you can run, and it turns the first two numbers into something you report on instead of an estimate.

Tools That Automate Deprovisioning

Evaluate on four criteria: coverage beyond SSO, approval checkpoints before revocation executes, audit evidence generated automatically, and time to deploy. None of these are pricing comparisons; check each vendor's own site for current rates.

The table splits along one line: identity-and-device tools go deep on their own ecosystem, SaaS-management tools go wide on visibility and reviews, and Siit sits across both, orchestrating the handoff between them with approvals and an audit log attached. All of it still needs an IdP underneath; Siit's role is the connective layer most teams are missing, and more than one tool on this list can coexist in the same stack.

Real Results From Automated Deprovisioning

The mechanism holds up in daily use. Airalo's people team automated offboarding on this chain, covered in Airalo's IT story. A manager submits a request, it is auto-approved, and the user is deactivated in Okta, with no manual work needed.

SSO and SCIM carry the grant side of the same chain. At Unit, access routes by risk, with automatic provisioning on core apps like Slack and Google, manager and app-owner approval on standard apps, and a manager, app-owner, and COO chain on financial systems. Adi Avraham, Head of IT, describes what the automation covers in Unit's lean IT story: "Where the SaaS app has SSO and SCIM provisioning, we can automate the whole process. The employee requests access, it goes through the approval chain, and they get notified when it's done. Completely automated."

The Fix Is Connecting the Systems You Already Have

The process, the automation, and the audit trail work as one connected system. That combination is what turns "we're pretty sure we caught everything" into an answer an auditor actually accepts.

Louis-Marie Fusco, IT Director at Swile, has run that shift for three years, with no birthright access for new joiners beyond the company default and every elevated permission requested through Siit, documented and time-bounded. In Swile's scaling story, he puts it in one line: "It's the orchestration layer of our entire IT operation." That's the process this guide just walked through, applied across an entire IT operation, including exits.

Book a demo and see how Siit automates deprovisioning from the HR trigger to the audit log.