Disabling a departing employee's account is one offboarding action, not proof that every access path has ended.
Identify the systems, sessions, permissions, and ownership relationships that need attention. Different applications may respond differently to a directory change.
A useful offboarding process connects an authorized departure event to specific actions and verification. For a learning project, model that coordination with fictional accounts and record what you can—and cannot—confirm instead of treating one completed ticket as evidence that the entire environment is covered.
Start with an authorized departure event
The process needs a reliable trigger, an effective time, and the appropriate approvals. Do not make employment or access decisions based on an informal rumor.
In a lab, use a fictional employee and a clearly stated departure event. Identify which systems are in scope and which people would own the decisions in a real organization.
The event should explain why the access is changing. The technical actions should implement that decision rather than substitute for it.
A good record also identifies who is responsible for confirming completion.
Distinguish new authentication from existing sessions
Blocking a new sign-in and terminating an existing application session are related but different concerns.
Microsoft's access-revocation guidance explains that applications can manage their own sessions. Do not assume an identity-provider action directly revokes every application-issued session.
The correct response depends on the application, integration, and available controls. Follow the provider's documentation and the organization's approved procedure.
In your portfolio, describe the exact behavior you tested instead of claiming that one action instantly removed all access everywhere.
Check independently managed access paths
A local application account, a manually assigned role, or another separately managed identity may require a distinct action.
Your scenario should identify those paths rather than treating every system as automatically connected to the central directory.
This is where an access inventory becomes useful. It gives you a list of systems to verify and a place to record exceptions.
Do not create a false sense of completeness by checking only the systems that are easiest to administer.
Handle ownership and business continuity separately
A departing employee may own documents, workflows, groups, or application responsibilities that the business still needs.
The decision about preserving or transferring those responsibilities should follow organizational policy and the relevant owner's approval.
Do not confuse preserving business information with leaving the former employee's access active. Those are different requirements.
A fictional lab can model the distinction even when it does not implement every retention or transfer feature. Label the modeled steps clearly.
Record verified results and outstanding offboarding actions
For each relevant system or access path, record:
- Completed action: What was blocked, removed, or otherwise changed.
- Verification: The safe test and session conditions supporting the result.
- Unverified item: What you couldn't confirm.
- Follow-up owner: Who is responsible for the remaining action or exception.
“Ticket closed” shouldn't hide an untested assumption. Turning real offboarding responsibilities into a credible career example requires the same distinction between your completed work and the wider process.
Don't treat account deletion as a substitute for an offboarding plan. Access termination, retention of business data, account removal, and ownership transfer serve different purposes.
In a real environment, follow approved policy and coordinate with the owners responsible for those decisions. In a lab, state which parts are implemented, simulated, or outside the scope.
Build a lifecycle project that shows the coordination
Use one fictional employee, a small set of systems, and a clear access inventory. Document the trigger, the actions, the verification, and the limitations.
The lifecycle project in The Six-Figure IAM Career Playbook gives you a practical starting point. The $9 guide connects that project with role selection and portfolio positioning.
The stronger IAM story is not “I disabled an account.” It is that you understood the access paths, followed the authorized process, and knew how to verify the parts you were responsible for.