Shieldome SiegeShieldome Siege
For Clients

How to Read a Penetration Test Report

A penetration test report can be twenty pages of genuinely useful, actionable findings, or twenty pages that look thorough but tell you very little. The difference is often invisible unless you know what to check.

Start with scope and dates, not the findings

Before reading a single finding, confirm what was actually tested and when. A report covering a narrower scope than you expected, or one that ran during a testing window that has since expired without a retest, tells you something important before you even reach the results section.

Check confidence, not just severity

Severity tells you how bad a finding would be if it is real. Confidence tells you how sure the tester actually is that it is real. A "critical, confirmed" finding and a "critical, possible" finding call for very different next steps, and a report that only shows severity is hiding half the picture. See our piece on vulnerability scanning versus penetration testing for why that distinction exists in the first place.

A good report shows its work. For a confirmed finding, expect to see the actual evidence: the request and response that proved it, not just a description of the vulnerability class.

Look for who approved what

If any exploitation happened during the engagement, a report worth trusting should be able to show that a specific action was proposed, approved by a named person, and then executed, not just that "the finding was confirmed" with no record of the decision behind it. That chain of custody matters if the report is ever going to support a compliance audit or a legal conversation.

Findings should map to something you already recognize

A report that invents its own severity scale or its own vulnerability taxonomy from scratch is harder to act on than one that maps findings to a widely used framework like the OWASP Top 10, or explicitly ties findings to compliance controls under GDPR, PCI-DSS, or SOC 2 when that is relevant to your business.

Ask what did not get tested

A report's scope section should be explicit about exclusions, not just inclusions. Knowing what was deliberately left out, and why, is just as important as knowing what was covered, particularly if you are relying on the report to satisfy a compliance requirement that expects a specific range to have been tested.

If you are the one commissioning the test

If a report format, or a whole engagement's structure, matters enough to your business that you want your own branding on the final document your client sees, that is a reasonable ask of whoever runs the test for you. See why agencies need white-label reports.

See it in an actual tool

Shieldome Siege enforces scope on every action and gates exploit confirmation behind a human approval, with a tamper-evident audit log of the whole engagement.

Read the documentation