A 200 response is not your proof

Name the fact you are trying to change

Suppose a low-privilege user sends a request to update an administrative setting and the server returns 200. That proves the server accepted a request. It does not yet prove that the setting changed, that the change survived, or that the same user can benefit from it.

Write the final fact before the test. For a write, it may be “the protected object now contains this value when read through a fresh low-privilege session”. For a detection test, it may be “the responder received an alert containing this actor, target and timestamp”. If the final fact is vague, the evidence will be vague too.

Check it where the fact is owned

A browser toast is a poor place to verify a database change. Read the object again, preferably through a separate request. A generated endpoint event does not prove that an analytic fired; follow the marker into the alert queue. A mail API response does not prove delivery; check the receiving mailbox or delivery record.

This extra read often changes the finding. Some applications acknowledge a write and reject it later. Others update a cache but not the underlying record. Detection pipelines may preserve the event but discard the field the rule relies on. The final check tells you which result you actually have.

• Record the actor, object and starting privilege.
• Capture the state before the test.
• Change one condition.
• Read the final state through the system responsible for it.

Keep the cause readable

Run a known-good or expected-denial case first. Then repeat it with one relevant change. If the account, request body, endpoint and timing all change together, the result may be real but the cause is hard to defend.

Use a unique, harmless marker on test objects. Keep the request, response, timestamps and final read together. A reviewer should not need a video or an explanation of what happened between two screenshots.

Stop before the proof becomes the incident

Sometimes the cleanest final check would delete data, message another person, change production access or affect availability. Do not take that step merely to make the report look complete. Show the prerequisites, identify the exact withheld action and state what remains uncertain.

That is still useful evidence. It tells the sponsor what has been shown, what has not, and what additional risk an approved test would remove. The strength of a finding comes from a clear boundary, not from the amount of damage permitted during testing.