Pentest report checklist: what a good report should include

A report can look impressive and still leave an engineer asking, "Which account did you use?" or "What was the record supposed to contain?" Those missing details turn a fix into another investigation.

Look past the cover and severity chart. A useful report explains the tested scope, gives enough evidence to understand each finding, and says what remains uncertain. The summary helps someone decide what needs attention; the technical detail helps someone do the work.

1. What was tested, and what wasn't

Check the report against the signed scope. It should name the applications and APIs, environment, roles, tenant setup, dates, and assessment type. Excluded infrastructure, clients, third parties, and source code should be easy to spot.

Then look for the interruptions: a role that never worked, an unavailable integration, a build that changed halfway through. A limitation isn't a failed report. Leaving it out gives the reader confidence the testing didn't earn.

The method should explain how the tester covered permissions, workflows, sessions, inputs, and other agreed areas. A list of tool logos doesn't answer that question.

2. A summary that says what needs attention

The summary should answer: what matters most, why does it matter here, and what should we do first? It should explain serious findings without relying on alarmist language or making the reader decode a vulnerability label.

A finding count won't do that. One cross-tenant permission failure may deserve more attention than a dozen low-risk header observations. Look for the conditions needed, the impact actually shown, and any controls that reduce the risk.

"No critical findings observed" can describe a test result. "The application is secure" cannot. That distinction should survive into any summary shared with customers.

3. Findings that another person can reproduce

An engineer may read a finding weeks later, without the original test accounts or any memory of the walkthrough. Each finding needs:

• A precise title, unique identifier, severity, and status. "Broken access control" is too broad; name the action and boundary that failed.
• Affected assets and conditions. List the endpoint, feature, role, environment, authentication state, and any setup required.
• Numbered reproduction steps. Include safe test data and the smallest sequence that consistently demonstrates the issue.
• Relevant request and response evidence. Preserve method, path, parameters, and meaningful headers or body fields while removing live tokens and unnecessary sensitive data.
• Expected and observed behaviour. This makes the failed security boundary explicit.
• Validated impact. Explain what the tester proved, which data or action was reachable, and where testing deliberately stopped.
• Root-cause-oriented remediation. Give the team a control to implement, not only a payload to block.

Screenshots are useful for showing a workflow. For a web or API finding, relevant redacted HTTP can explain details a screenshot misses. Neither needs live credentials or a dump of customer records. Use controlled data and preserve only what's needed to understand the result.

4. Severity tied to realistic impact

A numerical score needs an explanation. What access did the tester start with? Was another user's action required? Which data or operation was affected? What limits the number of affected users?

CVSS gives those judgments a consistent structure, but your product still matters. Keep confirmed consequences separate from possible follow-on harm. A report shouldn't turn a suspected second step into a proven account takeover.

You should be able to challenge the reasoning, not just accept a colour on a chart.

5. A fix your engineer can reason about

"Add authorization" is a starting point, not useful fix guidance. The report should identify the missing decision and where it belongs. For a permissions issue, that means the server checking whether this user may perform this action on this resource, including any legitimate sharing rules.

Separate a temporary restriction from the longer-term repair. Suggest what to verify after the change. If the tester hasn't seen the implementation, the advice should acknowledge that instead of inventing a precise code patch.

6. Where the tester looked

A findings list only shows where something went wrong. Ask for a coverage record too: the features, API groups, roles, and test themes that were tested, partly tested, or excluded.

Negative results can be useful when they're narrow. "The supplied viewer account could not export the tested invoices" tells you something. "No authorization issues exist" overstates what a time-limited assessment can establish.

7. A re-test record that preserves the history

A re-test should add to the record, not erase the original issue. Look for the date, build or environment, what was checked, and the result: fixed, partially fixed, not fixed, or unable to verify. Blocking the original example doesn't establish a fix if the same underlying problem remains.

The re-test covers agreed findings. New features or a major rewrite may need another assessment. Any closure summary should refer back to the original report so the history stays clear.

Signs a report needs more work

Be wary of unverified scanner output, copy-pasted descriptions, unexplained scores, and fix advice that only blocks the example used in testing. Ask about missing evidence while the engagement is still active.

The web and API pentest service page explains how we agree on scope, reporting, and the re-test before work starts.

Who's going to read your report?

Your engineers, a customer, or both? Tell us when you ask about web application penetration testing. It helps us agree on the detail and follow-up you need.

Request a pentest proposal Draft your scope first