How to read a penetration test report
The report arrives, it is sixty pages, and the person who has to act on it has an hour. Read it in a fixed order, run five checks on the way through, and decide within that hour whether you bought a penetration test or a formatted scan.
Read the scope section first, the findings second, and the executive summary last. The scope tells you what was tested, which determines whether the report answers the question you bought it to answer. The executive summary is written for a reader who will not read the rest, and it is the most generous section. If you have one hour, spend forty minutes in the findings and twenty on scope and coverage.
5 checks Enough to tell a test from a scan export
Scope first Not the executive summary
Every finding Needs a reproduction and a CVSS vector
What each section is for
| Section | Written for | What to check |
|---|---|---|
| Executive summary | Your board, your customer, your insurer | That it matches the findings. Read it last |
| Scope and assets tested | You, and your auditor | Every asset you asked for appears, with identifiers |
| Methodology | Your auditor | Named standard, named sections, manual against automated split |
| Findings | Your engineers | Reproduction steps, evidence, CVSS vector, specific remediation |
| Coverage or attack narrative | You | What was attempted and did not work |
| Appendices | Nobody, usually | Whether raw scanner output is padding the page count |
Check one: does the scope match what you bought
Put your own scope document beside the report and compare line by line. Every hostname, IP range, application role and cloud account you listed should appear. Three failures are common, and all of them are the buyer's problem to catch. The firm tested what the signed scope said.
The role question decides whether the report is worth anything for a multi-tenant application. Unauthenticated testing of a SaaS product finds the login page and little else. What matters is whether a low-privilege user in tenant A can reach data in tenant B. That takes two accounts and a tester with the patience to compare, which is the argument on web application security testing.
Comparing firms for this? Tell us what you need and it goes to the ones in the directory that do this work. No charge, and no phone number required.
Check two: the methodology names something
You want a named standard with the applicable sections identified: the OWASP Web Security Testing Guide for a web application, the OWASP Mobile Application Security Testing Guide for iOS and Android, PTES for a network engagement, NIST SP 800-115 as the process frame. A list of every acronym in the industry with no statement of which parts applied to your surface is a marketing paragraph.
Look for a statement of what was automated and what was manual. Its absence is not damning alone. Combined with a finding list of nothing but scanner categories, it is the pattern described on vulnerability assessment against penetration test.
Check three: the shape of the findings tells you who tested
Scanners find missing headers, outdated libraries, weak ciphers, expired certificates and default pages. Those are real findings and belong in a report. What a scanner cannot find is a flaw that requires understanding what your application is for.
| Surface | The finding that proves a human tested |
|---|---|
| Web application | A low-privilege user reaching another tenant's records by changing an identifier |
| API | An endpoint that checks authentication but not ownership of the object requested |
| Mobile | A control enforced in the client that the backend does not re-check |
| Internal network | A path from an ordinary domain account to domain administrator |
| Cloud | A role trust policy or permission chain that allows privilege escalation |
| Business logic | A discount, refund or workflow step applied out of order to gain something |
If your report contains none of these and your scope included the matching surface, put that to the firm. There is a legitimate answer: sometimes an application is well built and the tester says so in the coverage narrative. The illegitimate answer is silence.
Check four: what every individual finding needs
- A reproduction. The request, the response, the screenshot or the exact steps. Your engineer must be able to see it happen without emailing the tester.
- Evidence that it worked. Not "may allow" or "could potentially permit". A penetration test proves exploitation. Where a finding was identified but not proved, the report should say so plainly and rate it accordingly.
- A full CVSS vector, not just a number. The vector is auditable and the number is not, and disagreements are almost always about one metric. Score it yourself in the CVSS calculator and see where you differ.
- Remediation specific to your system. "Implement input validation" is a category. "Validate the tenant identifier on the server in the order lookup handler rather than trusting the client-supplied value" is advice.
- Affected locations, enumerated. One finding covering fourteen endpoints should list the fourteen, or your fix will cover three.
Every finding critical or high is a warning sign
Sometimes it is true, on a system nobody has tested before. More often it is severity inflation, which makes the report feel valuable and useless for prioritisation. A list where everything is urgent has no order. The opposite pattern exists too and is rarer: a firm rating a genuine tenant-isolation failure as medium because it required a valid account. Score the ones that matter to you yourself.
Check five: read what did not work
The most underrated section of a good report is the narrative of what was attempted and failed. It is the only evidence you have of coverage. A report that says the tester attempted SQL injection across forty-one parameters, tested authorisation on every endpoint with two accounts in two tenants, and attempted password spraying against the VPN without success has told you what it covered. A report with eleven findings and no negatives has told you what it found, which is a different and much smaller claim.
It also answers the question your auditor asks, which is not "how many findings" but "what was in scope and how do you know it was covered". That framing is on SOC 2 penetration testing.
What to do in the first week
- Raise one ticket per finding within five working days, with the CVSS vector in the ticket. Auditors look for the ticket trail more than the report.
- Disagree in writing where you disagree. A finding you have decided to accept needs a documented risk acceptance at the right level of seniority, not silence.
- Work out the date fixes must ship to stay inside the free retest window. The retest planner does the arithmetic and retest and remediation verification covers the terms.
- Ask for the attestation letter now, while the engagement is warm. It is the artifact your customer actually wants, per report against attestation letter.
- Book the readout with the engineers who will fix things, if it has not happened. An hour with the tester saves days of interpretation.
When a thin report is the correct outcome
A six-finding report on a small, well-maintained external perimeter that has been tested annually for four years is not evidence of a lazy firm. It is what a mature estate looks like, and demanding a longer report from the next vendor is how buyers train firms to pad. Judge coverage and evidence quality, not page count or finding count. The one number that should worry you is zero findings with no coverage narrative.
Not sure the report you got is a test
Tell us what was tested and who asked for it, and we will put one scope in front of Canadian firms.
Get matchedCommon questions
How do I tell if my penetration test report is really just a scan?
Look at the findings for anything that required understanding what the application does: a user reaching another tenant's data, an endpoint that authenticates but does not authorise, a privilege escalation path. If every finding is a missing header, an outdated library, a weak cipher or a default page, and there is no coverage narrative describing what was attempted, you have a scan with a cover page.
Which section of a pentest report should I read first?
The scope and tested-assets section, compared against your own scope document. It determines whether anything else in the report answers your question. Read the executive summary last, because it is written for someone who will not read the findings and tends to be the most generous section.
Is it normal for a report to have no critical findings?
Yes, particularly on an estate that has been tested before. What is not normal is a report with no findings and no description of what was attempted. Ask for the coverage narrative. A firm that tested thoroughly and found little can always tell you what it tried.
Can I give this report to a customer who asked for it?
Check the ownership clause first, because some firms licence the report rather than transferring it. Even where you own it, most companies send an attestation letter instead, because the report contains a map of your weaknesses. The letter names the date, scope, methodology and firm, which is what the customer's security review actually needs.
What if we disagree with a severity rating?
Score the finding yourself from the vector and compare metric by metric. The disagreement will almost always be one metric, usually privileges required or scope, and it can be resolved in one sentence rather than a meeting. Ask the firm to adjust the report where you are right, and record a written note where you have simply decided differently for your environment.
How long should a penetration test report be?
Long enough to reproduce every finding and describe coverage, which for a typical web application engagement is usually 25 to 60 pages. Page count is not a quality signal in either direction. Raw scanner output pasted into an appendix inflates it, and a genuinely clean estate compresses it.