What Your Offboarding Process Says About Your Entire IT Operation
You can tell a remarkable amount about the maturity of an IT organization by watching what happens in the first four hours after someone gives notice. Not what the policy says should happen. What actually happens. Whether the offboarding checklist exists in a ticket or in someone's memory. Whether access revocation is triggered automatically or requires a human to remember to do it. Whether the accounts that get disabled are all of the accounts, including the three SaaS tools that person set up eighteen months ago that never made it into the identity provider, or whether those quiet little access windows stay open for weeks because nobody knew they existed.
Offboarding is the operational stress test that every IT environment eventually takes, and it is one of the most reliable indicators of how the environment is actually managed versus how it is described in the documentation. The organizations that have done the identity governance work, the ones that know what accounts exist, what they have access to, and who owns them, complete offboarding in minutes rather than days and do it consistently regardless of which IT team member is handling it. The organizations that have not done that work complete offboarding unevenly, occasionally, and with a persistent background anxiety that something was missed. Both of these environments can have the same offboarding policy document. The document is not the operation.
The specific failure modes are worth naming because they are common and they are expensive. The shared account that five people use for a critical integration, provisioned by someone who left two years ago, that is still authenticated to a former employee's credentials: a security incident waiting for a trigger. The application that was provisioned outside the standard workflow because the standard workflow was too slow, that never got connected to the deprovisioning trigger: a ghost license paying for access that no longer has a legitimate holder. The admin rights granted temporarily during a project that were never revoked after the project ended: a privilege escalation surface sitting quietly in the environment. Each of these is a documentation failure before it is a security failure, and each of them is visible in a mature offboarding process and invisible in an immature one.
The discipline that fixes offboarding fixes far more than offboarding. Knowing what accounts exist requires an accurate identity inventory. Automating the deprovisioning trigger requires the HRIS and the identity provider to be integrated. Catching the SaaS tools that were never connected to SSO requires a SaaS discovery practice that runs continuously rather than at audit time. Every one of these capabilities is valuable beyond the moment someone hands in their badge. The offboarding process is just the scenario where the gaps are most visible, most consequential, and most immediately connected to a specific event that forces them to the surface.
If it is not in the ticket, it did not happen. That principle applies to offboarding with particular force, because the access that was not documented was not revoked, and the access that was not revoked is still open, and what is still open is still a risk. The cleanest offboarding processes are not the result of diligent manual effort by careful IT professionals. They are the result of an environment that was built to know itself well enough to clean up after itself automatically. Build the environment. The offboarding takes care of itself.
