A fictional audit finding can give an IAM lab a clear purpose: identify one access problem, correct it, and check the result.
Use synthetic records and a bounded control question. Don't publish employer audit material or imply that a personal project establishes regulatory compliance.
The useful story connects the finding to evidence, an accountable decision, implementation, and retesting. It should also explain which access paths or operational concerns the exercise leaves outside its scope.
Write a finding that describes a verifiable condition
For example: “Three fictional users retain access to the sample project folder after their project assignments ended.”
That statement identifies a condition you can test. It is more useful than “access management is weak,” which could mean many things.
Add the intended requirement: access should be limited to currently approved project members.
The gap between the intended state and observed state becomes the lab's central question. You now have a reason to inspect membership, ownership, and the process that should keep them aligned.
Build a small evidence set
Create a fictional roster showing current project members and a separate list of users with access.
Compare the two and identify the differences. Keep the sample small enough that a reader can understand the result without trusting a large unexplained script.
Then document how you determined that the extra access was no longer appropriate within the scenario.
The presence of a mismatch is not always enough by itself. An exception might be legitimate. Your fictional process should include a responsible owner who confirms the intended decision.
Define the corrective action and its owner
Decide what should change and who is authorized to approve it.
For the sample finding, the action may be removing specific group memberships after the designated owner confirms they are no longer needed. The implementation should be limited to the identified scope.
Also distinguish immediate correction from preventing recurrence. Removing three memberships addresses the observed condition. Improving how project end dates trigger a review addresses the process that allowed the condition to persist. Label proposed process improvements separately if you do not implement them.
Retest the result instead of checking only the change
After the approved correction, repeat the relevant access tests.
Confirm that current project members retain the intended access and that the removed users no longer have it through the tested path. Explain the session or timing assumptions relevant to your environment.
Do not treat a membership screenshot as the entire verification.
The result should show that the correction resolved the stated condition without unnecessarily breaking access for the users who still require it.
State what the corrective test did not cover
A lab may examine one resource and one access mechanism. Say that clearly.
Check whether the exercise excludes:
- Alternate group memberships or permission paths.
- Application-local roles and assignments.
- Existing sessions.
- Other resources affected by a real organizational review.
You don't have to implement every possibility. You do need to avoid calling a narrow correction a complete cleanup.
Understanding the purpose of an access review helps connect the decision, implementation, and follow-through. Removing an assignment in a console is not always the final proof of the intended access outcome.
A bounded exercise is credible when a reader can see both the tested result and its limits. The limitations also give you specific questions to discuss about how comparable work would differ in production.
Present the project as a control story
Organize the writeup around the requirement, finding, evidence, approved correction, retest, and remaining limitations.
That structure shows how technical work connects to an accountable process. It also gives you a useful interview example without inventing a production incident or a compliance achievement.
Keep all names, systems, and records clearly fictional. The project should demonstrate your reasoning, not borrow credibility from confidential organizational material.
The Six-Figure IAM Career Playbook includes identity lifecycle and portfolio guidance alongside a practical 90-day plan. The $9 guide helps you choose projects with a clear career purpose instead of installing another tool without a question to answer.
A useful audit-inspired lab ends with a verified correction and an honest scope—not merely a screenshot labeled “finding closed.”