An “Access denied” message doesn't automatically prove your permission rule worked. The resource might be unavailable, the wrong account might be in use, or the request might have failed before reaching the control.
A useful denial test explains why the action failed. Check the resource, identity, session, and relevant permission before drawing a conclusion.
That makes a small negative test a practical IAM project. You can demonstrate careful troubleshooting without adding another system, provided the evidence supports the access boundary you're claiming to have tested.
Define the action that should fail
Use a specific claim. A fictional warehouse employee should be unable to modify the payroll training document in your isolated lab.
Name the identity, resource, and action. “Shouldn't have access” is too vague when the person might be allowed to read but not modify, or use one feature but not another.
Write the expected result before running the test. That helps you avoid treating whichever failure appears as a success simply because the screen contains an error.
Also record the control you believe should cause the denial. Your test needs to reach that control to support the claim.
Prove the resource is functioning
Use an appropriately authorized test identity to perform the intended action under comparable conditions.
If the authorized identity cannot complete it either, you may have a resource, connectivity, application, or configuration problem unrelated to the boundary you intended to test.
Investigate that problem before interpreting the unauthorized user's failure.
The comparison doesn't have to be elaborate. It needs to establish that the action is possible in the environment and that the difference you are testing is meaningful.
Be careful not to use a broad administrator as your only comparison when the project concerns ordinary user permissions. The administrator may reach the resource through a different privilege path.
Verify the identity and session
A test performed under the wrong account can invalidate an otherwise careful setup.
Confirm which identity is active and whether recent membership or policy changes require a fresh session or another platform-specific step before they affect the test.
Record the conditions rather than assuming the interface is showing the state you expect. When the result is surprising, inspect the account and session before changing permissions.
In a public write-up, use fictional identifiers that remain consistent across the diagram, configuration, and evidence. Consistency lets a reader follow which account produced which result without exposing real identities.
Change one permission-related condition and repeat the test
In an isolated lab, use a controlled comparison:
- Keep the action constant: Use the same resource and attempted task.
- Change one relevant condition: Assign the required permission through the intended mechanism.
- Refresh the test conditions as needed: Establish the appropriate session state for the platform.
- Retest and record: Note whether the action now succeeds.
- Remove and verify again where supported: Check whether the expected boundary returns.
Keep unrelated configuration stable. Changing the account, network, policy, and application together makes it hard to explain which change produced the result.
This exercise can connect a particular permission condition with the observed behavior. It doesn't prove every possible access path is controlled.
Write the conclusion at that level. A narrow, supported claim is more useful than calling the whole environment secure after one denial.
Write a conclusion no larger than the evidence
A defensible conclusion might say that the fictional warehouse user could not modify the specific document under the tested conditions, while the intended role could.
It should not say the organization is secure or that unauthorized access is impossible.
Include the test steps, expected and actual outcomes, and the limitations. Explain any unexpected result and how you investigated it. That explanation often reveals more understanding than a perfect-looking screenshot.
The Six-Figure IAM Career Playbook uses practical identity projects to help you build evidence for your next role. Learning to defend a denial result is one way to make that evidence technically meaningful rather than merely impressive at a glance. The ebook is $9.