A contractor's access can outlast the assignment when there is no clear end condition, responsible sponsor, or verification step.
An account's existence is only part of the question. You also need a current reason for each permission the person retains.
Use a fictional contractor project to practice the full decision: who approves temporary access, when it should end, what changes at that point, and how you confirm the result. That is more useful than simply adding an expiry date to a form.
Record the end condition when access is requested
Use a fictional contractor joining a project for a defined period.
The request should identify the sponsor, the resource, the permitted actions, and the expected end date. It should also explain how an extension would be approved.
This turns “temporary access” from a vague description into a condition someone can act on.
You are not trying to predict every contract change. You are making sure a change has an owner and a decision path rather than relying on an administrator to guess what the business intended.
Distinguish access expiry from account removal
A contractor may have several assignments or resources.
Ending access to one project does not necessarily mean deleting the entire identity immediately. Conversely, retaining the identity does not justify retaining every permission it has accumulated.
For a lab, keep the scope explicit: which assignment is expiring, which access should be removed, and what should remain if another approved need exists.
This distinction helps you avoid presenting account deletion as the universal answer to every lifecycle event.
Make the sponsor's decision visible
Suppose the project owner wants to extend access.
Record the reason, the new duration, and who approved it. Avoid treating the absence of a response as automatic permission to keep access indefinitely unless you are explicitly modeling an authorized policy that says so.
Your project can compare two cases: one assignment expires without renewal, while another receives a documented extension.
Use dummy records and clearly label any manual process. A spreadsheet can demonstrate your decision model, but it does not prove an identity product enforced that model automatically.
Use platform features only within their actual scope
Some governance platforms provide time-limited access assignments and review workflows.
Microsoft's external-access guidance discusses access-package expiration and reviews. It also distinguishes access granted through that mechanism from access that may exist elsewhere.
That boundary matters. A correctly expired package does not prove every independent permission, account, or session has been addressed.
For implementation, verify the current feature requirements and configuration behavior. Do not assume that enabling a lifecycle option covers resources outside the workflow you configured.
Test the resource after the contractor's assignment ends
Use the fictional contractor to establish a working baseline. Then follow your documented removal or expiry process.
Record:
- Before: Which approved action worked?
- Change: Which assignment or permission expired or was removed?
- Retest: Which resource action did you attempt afterward?
- Session conditions: Was this a new session, an existing session, or another defined test?
- Limit: Which other applications or session types did you not evaluate?
Keep configuration evidence and behavior evidence separate. A screenshot showing a removed assignment is not, by itself, a test of the resulting access.
The difference between offboarding and merely disabling an account explains why this distinction matters. Your lab doesn't have to reproduce complete enterprise offboarding, but its claims should stay within the permissions and sessions you actually checked.
Turn the exercise into a governance story
Your portfolio should show the request, approval, initial access, end event, and verification.
The technical configuration is one part of the story. The other part is the responsibility: who decided access was appropriate, when that decision stopped applying, and how the system's state was checked afterward.
This gives you a concrete way to discuss identity governance without needing to claim experience running a large commercial platform.
The Six-Figure IAM Career Playbook includes identity lifecycle as one of three practical lab areas. The $9 guide helps you connect an exercise like this to an IAM lane and a career plan, so the project demonstrates a responsibility rather than just another account-creation task.