Keep three decisions separate: is the issue real, how severe is the technical behavior, and how urgently should this business address it? Document the evidence behind each one.
First, establish what was observed
Start with the original request and response, the tested application version, the time, and the account context. Reproduce the behavior in an approved environment using the smallest test that can demonstrate the issue. If a tool’s original evidence is missing, mark the result as unverified instead of filling in the gaps with a confident narrative.
Use a control request. When an access-control test succeeds, compare it with a request that should be permitted and one that should be denied. Check the returned data, not just the status code. An error template, cached response, or public resource can look like unauthorized access until you inspect it closely.
Give the engineer a complete reproduction
Write the steps so another person can repeat them without guessing which account, role, or object was involved. State the expected behavior, then the observed behavior. Keep credentials and customer data redacted while preserving enough structure to understand the result.
OWASP’s Web Security Testing Guide reporting guidance recommends giving readers the information needed to understand, reproduce, and remediate a finding. It also calls for masking sensitive information. A useful report is an engineering handover, not a raw export of every tool message.
| Include | What it should answer |
|---|---|
| Affected surface | Which host, route, component, and tested version? |
| Prerequisites | Which role, tenant, access, and test data were required? |
| Evidence | Which minimal request and response demonstrate the issue? |
| Impact | What was observed, and what remains an assumption? |
| Fix and retest | Which control should change, and how will it be verified? |
Separate observed impact from possible impact
Describe the demonstrated effect precisely: a synthetic invoice was readable across test tenants, a lower-privilege role performed a restricted action, or a secret appeared in a response. Then state what was not tested. Broad claims such as complete account takeover need evidence for the entire chain, not just the first weak control.
Ask the application owner what the affected data and workflow mean to the business. Is the endpoint internet-facing? Does it hold customer data? Is the vulnerable feature enabled for all customers? Are effective compensating controls in place? These answers often change urgency more than another page of generic vulnerability description.
OWASP’s Risk Rating Methodology combines likelihood and impact and emphasizes business context. It also notes limitations and points to alternative methodologies. Choose a consistent approach your organization understands, and document uncertainty rather than treating a numerical score as a complete risk decision.
Turn severity into an owned decision
Keep the technical severity beside the remediation priority rather than using one label for both. If you include a CVSS score, include its version, vector, and scoring rationale. Then capture the context that drives your internal deadline: exposure, data sensitivity, exploit prerequisites, known abuse, and available mitigation.
Assign an accountable owner and a target date agreed with the business. If the fix needs time, document the temporary containment and the risk that remains. Avoid promising a universal deadline for every finding with the same color; a repeatable decision is more useful than a rule that nobody can follow.
- Confirmed issue: record the evidence and affected versions.
- Action: choose a fix, containment, or explicitly accepted risk.
- Ownership: name the team responsible and the person who can approve closure.
- Verification: define the retest before changing the implementation.
Close the finding with a retest
Re-run the original reproduction against the changed build, using the same account boundaries. Also confirm that the legitimate workflow still works. For an ownership issue, that means checking that the wrong user is denied and the correct owner can still access the record.
Check nearby paths that may share the same failed control, such as an export endpoint or a bulk operation. Capture the new build identifier, test date, and result. If the original path is blocked but related paths remain vulnerable, describe the fix as partial instead of closing the issue prematurely.
Finally, connect the finding to a regression check and the relevant development guidance. OWASP’s Authorization Cheat Sheet recommends authorization tests and permission checks on every request. The durable outcome is a verified boundary that the team can keep checking as the application changes.
A reliable assessment starts before the first result. Use our authenticated scanning preparation checklist to make sure the intended accounts and workflows are actually covered.
Published by Sectiv editorial. Educational guidance for authorized security testing; examples describe preparation and review methods, not customer assessment results.