Start with the departure decision and system owners
HR or the authorised manager should provide the effective time and approved handling instructions through a trusted process. IT should not infer the departure terms from an informal message. Identify who coordinates the work, who owns each system and who resolves missing information. A planned departure and an urgent restriction may require different sequencing.
Separate removal of the person's access from preservation of the organisation's data. A mailbox, project file or automation may need a new owner. Retention or legal-hold requirements can affect deletion and licence decisions. Microsoft publishes a sequence for former employees covering access, mailbox and file handling; confirm the current requirements for your tenant and licences before making irreversible changes.
Inventory access beyond the main directory
Ask the manager what the person actually used, then reconcile that answer with available identity, device and application records. Include external SaaS accounts, partner portals, code repositories, cloud consoles, VPN, shared accounts and recovery contacts. Single sign-on reduces some administration but does not prove every service participates in the same termination event.
Look for ownership as well as membership. An employee may own a scheduled integration, approve payments or be the sole administrator of a supplier portal. Removing access without transferring that responsibility can interrupt work. Conversely, preserving an integration by leaving the person's whole account active retains unnecessary access.
Record the change and its effect separately
| Access path | Action to agree | Verification question |
|---|---|---|
| Main identity | Block sign-in and revoke relevant sessions | Does the target resource reject access as expected? |
| External application | Remove membership or disable the local account | Is an independent login still available? |
| Shared credential | Rotate it and update authorised dependencies | Does the old credential cease to work? |
| Device or recovery route | Apply the approved device and recovery actions | Can it still restore or retain access? |
| Owned automation | Transfer ownership and review permissions | Does the process work without personal access? |
A provider may retain an application session after an identity change, depending on the design and support for revocation. Record the resources and times checked. Our MFA and session protection article explains why the login control and the issued session need separate attention.
Use a controlled acceptance check
For a planned exercise, agree test accounts, resources, allowed actions and the point at which the test stops. Verify the relevant access paths with minimal exposure to real data. A test result in one application does not establish the behaviour of another application with a different session model.
For an actual departure, use administrative and resource-side records and approved verification procedures. Do not ask the former employee to disclose a password or log in again to prove the process. Where a check cannot be performed, state what remains uncertain, who owns it and the temporary restriction in place.
A fictional example: the overlooked supplier portal
The central account is disabled on time, but a procurement portal has a separate local login and lists the employee as the only recovery contact. The main-directory record therefore confirms only part of the outcome. The portal owner must arrange an authorised replacement, remove the old access and verify the new recovery route.
This example demonstrates an access dependency, not a Dyasol client result. Its important feature is the acceptance question: can the former user still reach the business resource through another path? That question is more useful than counting completed directory tasks.
Close the record with the business owner
Use the offboarding access checklist to record the systems, owners, effective time, changes, verification evidence and outstanding exceptions. Store references to sensitive evidence rather than passwords, recovery codes or token values. Record who accepts each remaining exception and when it expires.
A completed record should also identify transferred files, mailbox responsibilities, application ownership and equipment handling where these are in scope. Schedule a follow-up for delayed provider actions or unresolved access. Completion should mean the agreed acceptance criteria are met, not simply that the employee's name disappears from the directory.
Where Dyasol can help
A practical access review can map the relevant paths and define repeatable checks with your IT team. Where the result is needed for a customer, connect the record to the security questionnaire evidence process. Answer for the tested scope and date; do not turn one successful departure into a claim that every historical account has been checked.