What should an offboarding access check prove?
An offboarding access check should establish which accounts belonged to the departing identity, which access paths were reviewed, what approved changes occurred and which exceptions remain. A disabled identity-provider account is useful evidence, but it does not automatically describe every local application account.
Agree on the scope and completion criteria with the responsible teams. The exact actions depend on the application, the account’s purpose and your organisation’s offboarding process.
Before removing access
- Confirm the identity and effective departure time.
- Identify the applications and environments in scope.
- Check standard and privileged accounts separately.
- Identify shared functions or service accounts owned by the departing employee.
- Assign responsibility for data ownership, integrations and exceptions.
Do not assume that an account with a similar name belongs to the same person. Verify source identifiers and identity matches before taking action.
After the primary sign-in account is disabled
Inspect application accounts that remain enabled. Check whether access is local, federated or maintained through another mechanism. Ask the application owner to verify any source-specific sessions or credentials covered by your policy; an account-status field alone may not describe them.
If an account must remain for an approved operational reason, establish a new accountable owner and record the exception. A shared account should not silently retain the former employee as its only known owner.
Verify the result
Collect evidence after the approved source changes. Compare the account’s current state with the intended result and note the collection time. If a connector failed or its data predates the change, resolve that before calling the review complete.
For example, an inactive identity linked to an enabled application administrator account should remain an open finding until its purpose is explained or its access is changed and verified.
Using KeySkope in the workflow
Start with leavers with live access, inspect the application account and confirm the source context. KeySkope’s collected findings support the review; carry out approved changes in the source administration tools.
Document unsupported applications and unverified access paths alongside the completed checks. See collection and matching limitations and how to record evidence.
Continue your review
Explore the IGA and AI access governance library, check connector coverage or read the documentation.