How to Read a Penetration Test Report

A penetration test report is only as useful as the reader's ability to tell what was tested, what was missed and which findings actually matter. Security teams receive these reports from their own testers, and third-party risk teams receive them from suppliers as evidence of assurance, often as a two-page summary letter with a reassuring "no critical findings" line. Neither is worth much without reading the scope, the limitations, the severity rationale and the retest status. This guide is a reading method: how a good report is structured, what to check in each part, how to judge findings and severities, and the questions to send back to a vendor whose report you are relying on. It is for security engineers, risk and assurance analysts, procurement and third-party risk teams, and managers who sign off on residual risk.

Key takeaways

Read scope and limitations before findings. A clean report on a narrow scope says nothing about the systems you care about; check which assets, environments, accounts and dates were covered, and what was blocked.
Severity is the tester's view, not your risk. The NCSC notes testers may rate issues lower or higher than you would because they lack business context; re-rate against your own environment, but never to downplay.
Look for attack paths, not a list. The most valuable part of a good report is the narrative showing how medium findings chained to a serious outcome, because one fix can break several paths.
A summary letter is not a report. For a supplier, ask for the executive summary, scope, findings summary table and retest evidence under NDA, and treat a refusal to share any of it as a finding in your own assessment.
The report should validate your vulnerability management. The NCSC frames testing as assurance for your own processes; surprises are signals that something upstream (scanning, asset inventory, configuration standards) is not working.

Anatomy of a good report

Methodologies differ, but well-regarded guidance converges on the same parts. The OWASP Web Security Testing Guide proposes an introduction (version control, team, scope, limitations, timeline, disclaimer), an executive summary for non-technical readers, and findings with a summary table and per-finding detail. The Penetration Testing Execution Standard (PTES) splits the report into an executive summary (background, overall posture, risk ranking, general findings, recommendation summary, strategic roadmap) and a technical report. Use this table as the checklist for what should be present.

Section	What it should contain	What to check	Warning signs
Document control	Version, dates, authors, distribution	Report version matches the retest; authors are the testers, not only sales	Undated, or one version covering test and retest with no change history
Team and qualifications	Who tested and their credentials	Relevant qualifications for the scope (web, cloud, OT)	No named or described testers
Scope	Assets, URLs, IP ranges, applications, environments, roles and accounts used	Matches what you or the vendor contracted, and the production system you depend on	"Customer environment" without a list; staging only
Limitations	Out-of-bounds areas, broken functions, missing credentials, time limits	Whether a limitation removed the part you care about	No limitations section at all
Timeline	Test dates and effort	Recency; effort proportionate to scope	A large estate tested in one or two days
Disclaimer	Point-in-time statement	Present and plain	Wording that implies a guarantee
Executive summary	Objective, business impact, strategic recommendations	Consistency with the findings detail	"Strong posture" with several highs below
Findings summary	Reference ID, title, risk level for every finding	Counts by severity; status after retest	Findings mentioned in narrative but missing from the table
Finding detail	Likelihood, impact, risk rating, description, evidence, remediation, references	Evidence that the issue was confirmed, not just scanner output	Copied scanner text with no affected asset
Appendices	Methodology, rating definitions, tests performed, cleaned tool output	A defined severity scale; coverage of what was tested and passed	No rating definitions

For the wider context of commissioning, methodologies and scheme accreditation, see the Penetration Testing Guide. This page starts once the report has arrived.

Step 1: establish what was actually tested

Read the scope as a contract. The questions below decide whether the rest of the report is relevant to your decision.

Assets: are the specific applications, APIs, cloud accounts, hostnames or ranges you rely on listed by name? A supplier test of its marketing site is not evidence about its customer platform.
Environment: production, a production-like staging environment, or a test build? If staging, ask how it differs from production in configuration, identity provider and data.
Perspective: external unauthenticated, authenticated as which roles, internal network, assumed breach. An application tested without a customer-tenant user account cannot show cross-tenant access flaws.
Knowledge level: black, grey or white box. White-box tests with source or configuration access find more per day; black-box results understate risk for a given effort.
Dates and effort: when testing ended, how many tester days, and whether the system has had major releases since.
Exclusions and limitations: denial of service, social engineering, third-party services and specific modules are often excluded. Check whether any blocked area overlaps with the data or function you care about.

For your own tests, the Penetration Test Scoping Checklist sets this up before the test; when reading a report, use it in reverse to spot gaps.

Step 2: judge the findings and their severity

Read each finding for evidence, reach and fixability, then decide your own priority. Severity scales vary: the NCSC describes ratings of high, medium, low and informational, optionally alongside CVSS; the OWASP guide uses informational to critical with the scale defined in an appendix. If CVSS is used, check which version and which metric groups. FIRST's CVSS v4.0 specification asks that scores are labelled CVSS-B (base only), CVSS-BT (with threat), CVSS-BE (with environmental) or CVSS-BTE, and maps scores to None (0.0), Low (0.1 to 3.9), Medium (4.0 to 6.9), High (7.0 to 8.9) and Critical (9.0 to 10.0). A bare base score says nothing about your environment.

Question per finding	Good answer	Weak answer
Was it confirmed?	Evidence: screenshot, request and response summary, data accessed (masked)	"Potentially vulnerable" from a version banner
What can an attacker reach?	Impact described in terms of data, accounts or systems	Generic impact text copied from a database
Which assets are affected?	Every instance listed, or a clear sampling statement	One example, implying the rest
Why this rating?	Likelihood and impact rationale; deviations from the standard scale justified	Rating with no reasoning
How to fix it?	Specific change, plus the broader practice that would stop recurrence	"Apply best practice" or "patch"
Is it fixed?	Retest date and result per finding	"Remediation in progress" with no date

Re-rating: the NCSC expects the customer to own risk decisions, notes that testers may rate lower or higher than you, and warns that re-rating should find real risk and not be used to downplay issues. Raise a rating where a finding touches identity infrastructure, regulated data or an internet-facing path; lower it only with a written reason, such as a compensating control you have verified. Use your environmental context the way CVSS environmental metrics intend. See the CVSS v4 Guide and the EPSS Guide for prioritising against exploitation likelihood.

Attack narratives: look for a section that tells the story of how access was gained and extended. Three medium findings (for example, a readable file share, a reused service account password and excess group membership) can form a path to domain control that no single finding conveys. When the narrative shows a chain, fix the link that breaks the most paths first. The Top 10 Penetration Test Findings lists the patterns that most often appear in those chains.

Step 3: read what the report says about your own processes

The NCSC positions penetration testing as a way of gaining assurance in your own vulnerability assessment and management processes rather than as the primary way of finding vulnerabilities, and expects the report to give an opinion on the accuracy of your vulnerability assessment. Read the findings with that lens:

Expected findings: issues already in your vulnerability backlog show the backlog is accurate; check whether their age breaches your remediation SLA.
Unexpected findings: each one is a process failure upstream. A missing patch your scanner did not report suggests a scanning gap; an unknown host suggests an asset inventory gap; a default credential suggests a build standard gap.
Detection notes: if the report records what your monitoring saw, compare it with your SOC's alerts for the test window. Actions that went unseen are detection engineering work.
Repeat findings: the same issue across successive annual reports points to an ownership or architecture problem, not a patching one.

Reading a supplier's report for third-party risk

When the report comes from a vendor as assurance evidence, you usually get less than the full document. That is reasonable, because a full report is a roadmap to the vendor's weaknesses, but you still need enough to make a risk decision.

What you are offered	What it tells you	What to ask for
Summary or attestation letter from the testing firm	A test happened, roughly when, by whom	Scope list, limitations, findings summary table with severities and retest status
Executive summary only	Overall posture as the tester saw it	Scope, findings summary, retest letter
Redacted full report under NDA	Most of what you need	Retest results and the remediation plan for open items
A test performed by the vendor's own staff	Internal assurance only	Independence of testers; whether an external test also exists (see NIST SP 800-53 CA-8(1))
Results from a platform or scanner labelled "pen test"	Automated vulnerability scanning	Evidence of manual testing and exploitation of findings

Questions to send the vendor

Which of the services we use were in scope, by name, and was testing done against production or an equivalent environment?
Was the application tested with authenticated customer-level accounts, including attempts to reach another tenant's data?
What were the limitations or exclusions, and do any affect the service we buy?
Who performed the test, are they independent of the development team, and what accreditation does the firm hold?
How many critical and high findings were raised, how many remain open, and what are the target dates?
Can you share the retest letter or retest section showing closure of critical and high findings?
How often do you test, and what triggers an additional test (major release, new hosting, acquisition)?
Were any findings accepted as risk rather than fixed, and who approved that?
Were there findings involving secrets, API keys, service accounts or customer integration credentials, and were exposed credentials rotated?
Do the dates and scope align with the period and system description in your SOC 2 report or ISO certificate?

Cross-check the answers against the vendor's other assurance. A SOC 2 report describes controls over a period; a penetration test is a point-in-time look at weaknesses. The How to Read a SOC 2 Report Guide covers the first, and reading the two together shows whether the vulnerability management control described in the SOC 2 report actually closed what the testers found. For where this evidence sits in your wider supplier process, see the Third-Party Risk Management Guide and the Security Questionnaires Guide.

Where identity fits

Identity findings deserve a separate pass, because they tend to be the links in attack chains and because their fix is rarely a patch. Look for findings about credentials in files or code, service accounts with interactive logon or excess rights, Kerberos weaknesses, default or shared administrator accounts, token handling and tenant isolation. Check whether the testers were given accounts and whether those were removed afterwards; test accounts and API keys left active after an engagement are themselves a risk. For supplier reports, ask specifically whether any non-human credentials that could reach your data were exposed. See the Service Account Security Guide.

Turning the report into action

Debrief: hold a debrief with the testers, which the NCSC suggests as a way to ask for clarification, to clarify findings, evidence and chains while the work is fresh.
Triage: re-rate each finding against your context, record the reason, and assign an owner and due date by severity.
Consider alternatives: the NCSC suggests options beyond the tester's fix, such as removing unneeded software or adding monitoring; record the chosen treatment.
Feed root causes upstream: for each unexpected finding, open a separate action on the process that missed it.
Track and retest: keep the findings in your remediation tracker until retest confirms closure. See the Penetration Test Remediation Tracker Template.
Handle the report securely: restrict distribution, store it as confidential, and set a retention period; it describes how to attack you.

Detection and measurement

Critical and high findings closed within SLA: percentage, confirmed by retest.
Unexpected finding rate: share of findings not already known to your vulnerability management process; this should fall over time.
Repeat finding rate: findings that reappear from previous tests.
Undetected test activity: share of test actions that monitoring did not alert on, where the SOC took part.
Supplier evidence coverage: percentage of critical suppliers with a current test (within 12 months) whose scope covers the service used and whose criticals are retested closed.

Framework mapping

Framework	Reference	Relevance
NIST SP 800-53 Rev. 5	CA-8, CA-8(1), CA-5, RA-5	Penetration testing, independent testers, plan of action and milestones for findings, vulnerability monitoring
NIST SP 800-53 Rev. 5 (supply chain)	SR-6, SA-9	Supplier assessments and reviews; external system services
NIST CSF 2.0	ID.RA-01, ID.IM-02, GV.SC-07	Vulnerabilities identified and recorded; improvements from security tests; supplier risk assessed and monitored
ISO/IEC 27001:2022 Annex A	8.8, 5.22	Management of technical vulnerabilities; monitoring and review of supplier services
CIS Controls v8.1	Control 18	Penetration testing programme; see the CIS Control 18 Penetration Testing Guide

Common failure patterns

Counting severities instead of reading scope: "zero criticals" on a test that excluded the customer platform is accepted as assurance.
Taking the base score as the priority: a CVSS base score is used unchanged, so an internal medium on the identity provider waits behind an external low-impact high.
Fixing symptoms only: each finding is closed individually while the scanning, inventory or build gap that produced it stays open, and the same class returns next year.
No retest: findings are marked closed on the owner's word; the next test finds them again.
Accepting a letter in place of evidence: a supplier's one-page attestation is filed without scope or retest information, then relied on after an incident.
Leaving test credentials behind: accounts and keys issued to testers stay active after the engagement.

Practitioner checklist

Confirm the report version, test dates, effort and testers before reading findings.
Map the scope, perspective and limitations against the systems and data you care about.
Check that a severity scale is defined and, for CVSS, which version and metric groups were used.
For each finding, confirm evidence, affected assets, rating rationale and specific remediation.
Read the attack narrative and fix the links that break the most paths first.
Re-rate in your context with a written reason, never to downplay.
Open upstream actions for every unexpected finding.
Track findings to retest-confirmed closure, and remove tester accounts and keys.
For suppliers, request scope, findings summary and retest evidence, and send the vendor question set.
Store reports as confidential with restricted access and a retention period.

How to Read a Penetration Test Report: Scope, Findings and Questions for Vendors