At a glance
The employee’s directory account is disabled. That is an important action, but it may not answer whether all relevant access ended. A reliable offboarding process checks the systems and access paths it claims to cover.
- Define the departure event and effective time.
- Verify application-local and indirect access paths.
- Keep business-data retention separate from permission retention.
Know which relationship is ending
Consider a fictional engineer leaving Stonefield Services after completing a fixed-term assignment. The HR record closes, but a separate project account and a supplier portal identity also exist. The departure workflow needs to know which identities belong to the person and which relationships remain legitimate.
A contractor becoming an employee presents a different case from someone leaving entirely. Do not let an ambiguous status change decide the outcome accidentally. Ask the authorised workforce owner to establish the intended relationship and timing.
List the access paths in scope
Include the central identity, connected application accounts, direct permissions and any privileged access arrangements. Determine whether existing sessions or issued credentials require separate action in each environment. The answer depends on the target system, not only the governance record.
| Area | Question |
|---|---|
| Central identity | Was access disabled at the authorised effective time? |
| Application-local account | Does it remain usable independently of the central identity? |
| Privileged permissions | Were standing and temporary grants removed? |
| Business ownership | Who now owns workflows, shared resources or unattended tasks? |
Do not delete business records merely to demonstrate that access ended. Retention and ownership transfer may have different requirements. The operational plan should preserve needed information while withdrawing the departing person’s ability to use it.
Handle failures as unresolved access work
A target application may reject the removal or be unavailable. Assign the exception to someone who can act, record the known state and define the escalation. A generic failure message without an account and application gives the support team too little information.
The IGAX lifecycle and integration capabilities described on the website are relevant to coordinating this work. Verify which actions the deployed connector performs, which need a manual step and how the resulting state is checked. Do not assume one supported action means complete coverage of every access path.
Keep a traceable completion record
Record the departure authority, effective time, actions performed and verification results. If an exception remains, name its owner and next action. A dashboard can distinguish the processed departure event from the unresolved application change.
Use a realistic test before widening the workflow: a person with several accounts, a target-system failure and a corrected end date. Check that a late update does not accidentally restore access. The test should show how operations recovers, not only that the normal path works.
Published by AIdentX Editorial. Illustrative scenarios are fictional and do not represent customer results.