An auditor testing offboarding does something very simple. They take the list of people who left during the period, pick a sample, and compare each person's last day with the time their access was removed. Any gap longer than your policy allows is an exception.
It is a familiar finding in first audits, and it is rarely about malice or neglect. It happens because HR told IT on Monday about someone who left on Friday, because a contractor's engagement ended without anyone noticing, or because the identity provider account was disabled but the cloud access key was not.
This article covers how to define the standard, where the trigger should come from, the order of removal, what single sign-on leaves behind, devices and data, and how auditors test it.
Set the standard in your policy, in hours
The frameworks agree on the outcome and differ on precision.
PCI DSS v4.0 Requirement 8.2.5 says access for terminated users is immediately revoked.
SOC 2 CC6.2 asks that credentials are removed when access is no longer authorized. The timing is yours to define.
ISO 27001:2022 Annex A 5.18 covers removing access rights on termination, 6.5 covers responsibilities that remain after employment ends, and 5.11 covers the return of assets.
The HIPAA Security Rule includes termination procedures at 45 CFR 164.308(a)(3)(ii)(C), as an addressable implementation specification.
NIST SP 800-53 Rev. 5 PS-4 covers personnel termination, including disabling system access within a time period you define.
Because SOC 2 and ISO 27001 let you set the timing, your policy is the standard you will be tested against. Write it precisely. "Access is removed promptly" is untestable, so the auditor will pick an interpretation for you. "Access to all in-scope systems is removed by the end of the employee's last working day, and at the time of notification for involuntary terminations" is testable, and it is a standard you can meet.
Do not write a tighter commitment than your process can deliver. A policy that says one hour, met in four, produces exceptions. A policy that says end of day, met in four hours, does not.
Start from a trigger you can trust
Late removals usually trace back to the trigger. If offboarding starts when a manager remembers to email IT, the timing depends on memory.
The reliable trigger is the HR system. When a termination is entered with an effective date, that record should start the offboarding, either directly through an integration with the identity provider or through an automatically created ticket. The HR record is also what the auditor will use as the leaver population, so starting from it keeps your process and your evidence aligned.
Two cases need special handling:
Involuntary terminations. Access should be removed during or before the conversation, not after it. That requires HR to tell IT in advance, under confidentiality, with an agreed time.
Contractors and temporary staff. They are often not in the HR system at all. Give every non-employee account an end date when it is created, and have the identity provider disable it automatically on that date unless someone extends it.
The removal runbook, in order
Order matters. Remove the ways back in first, then tidy up.
Disable the identity provider account. This blocks new sign-ins to every federated application.
Revoke active sessions and refresh tokens. Disabling the account does not always end sessions already open. Most identity providers and major SaaS tools have a revoke or sign-out-everywhere action.
Remove cloud and infrastructure credentials. Access keys, SSH keys, VPN certificates, and database users that exist outside the identity provider.
Remove access to non-federated applications. Work from the application inventory, using each app's owner and recorded removal step.
Revoke personal tokens. API tokens and personal access tokens in source control, CI, and SaaS tools often survive account removal.
Rotate shared secrets the person knew. Any shared credential, team password, or break-glass secret they had access to.
Transfer ownership. Documents, repositories, scheduled jobs, and integrations that run as the departing user will break or keep running under a dead identity.
Record completion. Each step dated, on the ticket.
For leavers who held administrative rights, add a check that no new administrators, keys, or federated apps were created in their final days. Managing privileged access covers how to find those accounts in the first place.
What single sign-on does not remove
Single sign-on makes step one cover most of your applications. It does not cover steps two to seven on its own.
Federation stops new logins through the identity provider. It does not necessarily delete the account inside the application, end its sessions, revoke its tokens, or touch credentials issued outside the identity provider. Applications with automated provisioning will deactivate the account. Applications with federation only will not. SSO as a compliance control sets out the application tiers that determine which removal steps each app needs.
Devices and data
Access removal covers more than accounts.
Company devices. Recover them, or lock and wipe them remotely if they cannot be recovered promptly. Record the device, its status, and the date.
Personal devices with company data. If staff read email or chat on their own phones, remove the work profile or the company apps.
Mail handling. Decide whether mail is forwarded to a manager, answered with an automatic reply, or bounced, and for how long. Do not leave the mailbox signed in on a device you cannot reach.
Physical access. Badges and keys, if you have offices.
Where the person handled regulated data, such as ePHI under HIPAA, document that data and devices were returned as part of the termination record. For the wider picture, see our HIPAA overview.
How auditors test it
The test is mechanical, which is why it finds problems so reliably.
The auditor requests the complete list of terminations during the period from the HR system. They choose a sample, the size depending on the population and the auditor's methodology. For each sampled leaver they compare the effective termination date with the time access was removed in each in-scope system, usually from the identity provider's audit log and the logs of non-federated systems. How auditors sample controls covers how sample sizes are chosen.
The common exceptions are predictable:
Access removed days after the termination date
Identity provider disabled on time, but a non-federated system missed
A contractor whose account was never disabled because nobody owned the end date
A leaver who still appears as active in an application's user list, even if they cannot sign in
You can run this test on yourself every month. Take the leavers since the last check, pull the removal timestamps, and fix any gap before the auditor finds it. A record of those self-checks is also evidence that the control is monitored.
How TrustLynce helps
TrustLynce continuous monitoring runs control checks against the HR, identity, and cloud systems you connect and routes failures to their owners, so a missed removal is raised during the period rather than found in the audit sample.