What to do with penetration test results

Start with the affected route, the account or role used, the request that failed, and what the tester observed. A severity label helps sort a report, but it cannot tell an engineer which check to change. If a finding lacks a repeatable path, ask the tester for it before the details go cold.

Keep the observed result separate from the possible impact. A test account reading one record from another test organization proves that boundary failed for that request. It does not prove that every customer record was read.

Check whether the affected feature is reachable in production, which roles can use it, and what data or action sits behind it. A temporary restriction may be appropriate while an engineer builds the fix. Record that decision and who made it. Do not wait for a polished long-term patch before addressing a reachable, serious exposure.

One issue should point to the evidence, the affected product flow, the person implementing the change, and the person who will verify it. Keep the tester's original request and response in the restricted issue or report, not in a public bug tracker. If the same authorization decision is made in several routes, list those routes so a fix to one endpoint does not leave its siblings open.

Repeat the original request with test accounts after the fix. Then check the nearby operations that use the same record. For example, if a user in organization A could read organization B's invoice, test the detail view, export, and update routes with A's session and B's test invoice. Confirm that the same routes still work for an authorized user.

OWASP's authorization testing guidance describes testing permissions across roles, services, and data. Add a regression check for the failed boundary when the product has a test suite for that flow. Mark the finding resolved only after the retest result is recorded.

• What the tester observed, with a link to the restricted evidence.
• What was contained, fixed, or accepted, and who owns that decision.
• The exact request or workflow used to verify the change.
• Any related routes that still need checking.

Our fictional sample report shows how a finding can carry evidence and remediation steps. For what to ask for in the report itself, read what makes a penetration test report useful to engineers.