A governance project should show how an access decision becomes a completed, verified change.
Creating users is only one possible technical action. The more useful demonstration explains why access is appropriate, who decides, what must change, and what evidence confirms the result.
You can model this with fictional users, a small test environment, and ordinary records. The goal is a traceable chain from request or review to actual access—not a claim that you've reproduced an enterprise governance program.
Start with an access inventory that contains a reason
Create a fictional project resource and a small set of users with different responsibilities.
For each assignment, record the identity, permission, owner, business reason, and expected end or review condition. Use enough variation to make the review meaningful: a current employee, a former project participant, and a contractor with an approaching end date.
Do not populate a large table just to simulate scale. A few carefully chosen cases can reveal the questions you want the project to answer.
Give the reviewer a decision they can understand
The reviewer needs context, not just usernames and a button labeled approve.
Show what the access permits, why it was originally granted, and what has changed. Ask the fictional resource owner to retain, remove, or investigate each assignment.
You are modeling a decision process. Clearly distinguish a manually recorded review from a review enforced by a governance platform.
Microsoft's access-review overview provides an example of how review capabilities can be organized around resources and reviewers. Check current feature requirements before attempting a product-specific implementation.
Keep the decision separate from the completed change
A reviewer selecting “remove” is not proof that access has disappeared.
Track the resulting action: which membership, assignment, or permission needs to change, who is responsible for carrying it out, and what evidence will confirm completion.
For the lab, perform the authorized change on your fictional identities and test the relevant resource action afterward.
The project becomes more useful when it shows the entire chain rather than stopping at a completed review spreadsheet.
Include one exception and one unresolved item
Realistic decision-making does not require inventing a production incident.
For a fictional exception, let a contractor receive a short extension with a named sponsor and a new end condition. Record why the exception exists and how it will be revisited.
For an unresolved item, make the business reason unclear. Show that it needs investigation rather than silently treating uncertainty as approval.
The information a useful access request should capture can help explain why incomplete records create difficult review decisions later.
Compare the decision with the access that actually exists
After implementing the review decisions, reconcile the inventory with the system state you can observe.
Use separate records for:
| State | What it means |
|---|---|
| Decided | The reviewer authorized keeping, changing, or removing access. |
| Implemented | The corresponding technical change was made. |
| Verified | The observed state or resource test supports the intended result. |
| Unresolved | A failure, dependency, or untested condition remains. |
Where practical, test the actual action instead of relying only on a configuration screenshot.
Document the identities, resources, and session conditions checked. A small review cannot establish that every possible access path in an organization is correct.
This reconciliation is what makes the project more than a form-filling exercise: it shows that you distinguish a policy decision from an outcome you have evidence to support.
Present the project as an evidence chain
Your portfolio can show five connected artifacts: the initial inventory, reviewer decisions, change record, test results, and unresolved or exception items.
Explain the business question first: who should still have access, and how do we know the system now reflects that decision?
Then describe the implementation and limitations. The project does not need a commercial platform to demonstrate the reasoning, though platform experience may be a separate requirement for particular roles.
The Six-Figure IAM Career Playbook introduces IAM lanes and practical lifecycle work within a 90-day career plan. The $9 guide helps you turn a governance interest into a concrete project that shows decision-making, implementation, and verification—not just another batch of user accounts.