Removing access for a departing employee can be relevant IAM experience. Describe the part you actually handled and how you checked it.
Don't dismiss the work as merely clicking Disable. Don't imply that one account change means you owned every application, session, and handoff in the offboarding process.
An accurate boundary makes the example credible. It also shows which surrounding lifecycle responsibilities you could learn next through approved work or a fictional lab.
Start with the authorization and timing
An offboarding action should follow the organization's approved process and the appropriate authority.
Your example may involve receiving a valid request, confirming the intended identity, and applying a change at the required time.
Keep private employment details out of your resume and portfolio. You can explain the control and your responsibility without describing a real person's departure.
The useful career evidence is how you handled a sensitive access change, not the circumstances behind the request.
Identify the systems you actually changed
Did you disable a directory account, remove group assignments, coordinate application-account removal, or perform a different defined task?
Name the category of action and the scope. A central identity change may not cover every separate application account or active session.
Microsoft's access-revocation guidance illustrates why application and session behavior need attention in its environment.
Don't assume that one visible disabled status proves every possible access path has ended.
Explain the verification you owned
A completed ticket is not, by itself, evidence that the intended result occurred.
Describe the checks required by the process and which ones you performed. You may have verified a directory state, checked a group removal, or received confirmation from an application owner.
Keep the distinction between direct observation and somebody else's confirmation clear.
If you only implemented the change and another team verified the outcome, say that. It is still a legitimate contribution.
For example, you may have disabled a directory account while another team owned application sessions and data retention. Describe your completed step and its verification, then identify that boundary. Accurate scope makes the experience more credible, not less valuable.
Include the handoff where responsibility continued
Offboarding may involve data ownership, shared resources, service dependencies, or other tasks outside your authority.
You don't need to claim those responsibilities to show that you understood the boundary. Explain how unresolved items were assigned or escalated according to the process.
A careful handoff can be useful evidence of operational judgment.
Avoid describing improvised access retention or bypasses as a clever solution. Sensitive exceptions should have the appropriate authorization and documented ownership.
Use a lab to explore the parts of offboarding you didn't own
Create a fictional employee and a small set of resources. Then document:
- Authorized removal: What change is required, by whom, and when?
- Supported actions: What can your environment actually change?
- Verification: Which access attempts or states can you check?
- Exclusions: What applications, sessions, or handoffs remain outside the exercise?
Label simulated behavior as simulated. A worksheet representing an application removal isn't the same as completing that removal through a real integration.
Understanding why offboarding extends beyond disabling an account helps you choose the next useful question. You don't need to add unrelated tools to make the environment look enterprise-sized.
The lab should extend your understanding while keeping professional responsibility, tested behavior, and modeled steps clearly separate.
Write the experience as a specific contribution
A truthful resume statement might describe implementing approved departure-related account changes and recording completion through the organization's process.
Add verification or coordination only when you actually performed it. Keep metrics out unless they are accurate and appropriate to disclose.
The point is to show responsibility for an identity-related outcome without inflating the job title or the scope.
The Six-Figure IAM Career Playbook helps connect familiar IT responsibilities to an IAM lane and practical proof. The $9 guide includes lifecycle lab work, positioning, and a 90-day plan.
A routine departure task can reveal a meaningful identity skill. Make the action, authority, evidence, and limit clear enough that an employer can see what you genuinely know.