When you give someone read access but not edit access, you're working with authorization: what an identity is allowed to do with a resource.
Explain the decision behind the permission change, not just the click that applied it. Your existing permissions work may already provide relevant IAM experience.
Name the identity, resource, action, and conditions. Then explain who approved the access and how you checked it. That turns “I added the user” into a more useful example without overstating the responsibility you actually held.
Name the action instead of saying only “access”
“Needs access to the finance system” is incomplete. The person may need to view reports, submit a request, approve a payment, or administer the application.
Those actions can require different permissions and different approvals.
In a fictional lab, define one action precisely: a purchasing employee may read approved supplier documents but may not modify them.
That requirement is easier to implement and test than a broad statement that the user should “have access.” It also gives you a clear basis for deciding whether the result is correct.
Identify the identity receiving the permission
The user account matters, but so can the groups or roles through which the permission is assigned.
Microsoft's security group documentation explains one common way to organize Windows permissions.
Your explanation should connect the specific account to the relevant membership and then to the resource permission. Do not assume the relationship is obvious from a screenshot of a directory console.
Also check whether another assignment grants the same capability. Removing one path does not prove the user has no remaining access.
Distinguish authorization from authentication
A user can prove who they are and still be denied a particular action.
That is not necessarily an error. It may be the intended result of the access model.
Conversely, a user who cannot authenticate has not yet reached the point where your resource permission can be tested meaningfully.
In a portfolio, describe which stage you are evaluating. A failed login screenshot is not automatically evidence that your authorization rule worked.
A practical explanation of authentication versus authorization helps make that boundary clear without turning it into a terminology exercise.
Distinguish permission-setting ability from approval authority
Being able to grant access doesn't mean you're authorized to decide it is appropriate. Include the business decision in your scenario:
- Resource owner: Who understands the resource and its sensitivity?
- Approver: Who can authorize the requested action?
- Need: Which responsibility justifies the permission?
- Duration: When should the permission end or be reviewed?
In a lab, use fictional owners and clearly label approval as simulated.
This also explains why copying another user's access is not a reliable decision method. Similar job titles don't establish identical responsibilities.
A temporary project may require an end date or review rather than indefinite access. Authorization concerns continued permission as well as the initial grant.
Document enough for another person to understand why the access exists and what would cause that decision to change.
Demonstrate the boundary with two accounts
Use an ordinary account that should receive the permission and another that should not. Test the same resource and action under comparable conditions.
Then test an action outside the allowed scope, such as editing when only reading should be permitted. Record the results and relevant session conditions.
You now have evidence for a specific authorization claim. You have not proved an entire enterprise security model, and you do not need to pretend you have.
The directory and lifecycle projects in The Six-Figure IAM Career Playbook give familiar permissions work a more deliberate career purpose. The $9 guide helps connect that evidence with roles and positioning.
You may already know the mechanics. Learning to explain the authorization decision is what makes the experience easier for an identity team to recognize.