How to Read a Penetration Test Report: The 6 Questions That Actually Matter
The fastest way to learn how to read a penetration test report: confirm the scope and methodology first, then work the findings by exploitability. A finding with working proof of exploit and a known exploited match outranks a higher score that only cites a vulnerability ID. Prioritize by what an attacker can actually do in your environment.
The report has arrived. Forty pages, a handful of critical findings, and a CVSS column that looks like a leaderboard. Your team opens it, scrolls to the criticals, and starts triaging by score. That is the most common way a penetration test report gets misread, and it is the reason the same finding classes come back in next year's report. The question this post answers is how to read a penetration test report so that it does the job it is actually for: producing an ordered fix list that a team can execute.
The urgency is real and current. On October 30, 2026, CISA added two Ivanti Connect Secure flaws, CVE-2026-111357 and CVE-2026-118527, to its Known Exploited Vulnerabilities catalog, on top of CVE-2026-104935, which it added on October 13 [4]. The flaws allow unauthenticated remote execution of arbitrary commands, and CISA documented a working chain used for credential theft and data exfiltration, with a remediation due date of November 2, 2026, for CVE-2026-111357 [2]. An environment that read its last pentest report as a findings list and filed it away is the environment where a finding like this surfaces from a breach notification, not from the report.
In our reviews of past engagements, the pattern is consistent. The finding that actually moves a client's remediation budget is rarely the one with the highest CVSS score. It is the finding with working proof of exploit and a short path to the data that matters. Clients are often surprised when the score column and the priority column disagree. Clone Systems' position: a penetration test report is a decision document, not a findings list. If you read it as a CVE inventory, you will under-fix the risks that matter and over-fix the ones that do not.
What Should You Look for in a Penetration Test Report?
The first read is scope and method, not findings. Before you look at a single vulnerability, confirm what the test covered: the environments, the systems, the identities the testers used, and the rules they worked under. A report that does not state its scope is a report you cannot fully trust, because you cannot tell what a clean line means when half the environment was never tested.
NIST SP 800-115, the standards body's technical guide to information security testing and assessment, frames the discipline this way. It exists to help organizations plan and conduct security tests, analyze findings, and develop mitigation strategies, and it is explicit that each testing technique carries benefits and limitations [3]. A report that omits its methodology section is hiding its own limitations from you.
Use the Clone Systems 6-Question Report Read as the order of the first pass. Answer the six before you touch the remediation tracker:
- What was in scope? The environments, systems, and roles the tester worked, in the tester's own words.
- Which findings carry working proof of exploit? A screenshot of a banner is not a finding; demonstrated impact is.
- Which findings match a known exploited vulnerability? A CISA KEV match means the exploit already exists in the wild [2].
- Which findings reach the data that matters? A finding on a shared service often reaches more than the one host it is listed under.
- What changed since the last test? And was last year's fix validated by a retest?
- Who owns each fix, and by when? If the report does not force that answer, the fix list will not survive contact with your team.
The first question is where most reading failures start. Scope is the floor of the report. If your API sits behind the pages you tested, or your cloud account was not on the list, a clean report covers a smaller surface than you believed. Our post on API penetration testing scope covers how a thin scope list shrinks the test, and the web application coverage gap covers the same failure on the application side.
How Do You Prioritize Findings in a Penetration Test Report?
By exploitability and reach, with the score as a tie-breaker rather than a lead. Three tiers separate the findings that need action this week from the ones that can wait for a patch cycle.
Tier 1: Active exploitation. Findings that match the CISA Known Exploited Vulnerabilities catalog, which now lists 1,766 vulnerabilities confirmed as exploited in the wild [2], sit in the top tier regardless of score. The Ivanti chain is the model case: unauthenticated remote command execution, a working chain, credential theft and data exfiltration documented in the alert, and a due date set by CISA [4]. These get a fix or a compensating control in days, not a sprint.
Tier 2: Working proof of exploit. Findings where the tester demonstrated impact, even with no public exploit, are next. This is the tier that score-based triage misorders, because a demonstrated business logic flaw that reads another tenant's records can carry a mid-range score. The report should show the evidence, the request and the response, and the data that moved. If it does not, you are grading a claim, not a result.
Tier 3: Version and configuration findings. The rest. These are real, they feed the patch backlog, and they are the class a vulnerability scanner already tracks on a schedule. They belong in your vulnerability management workflow, not on the first page of the pentest.
Time-on-page drill. Pull out the report from your last engagement, or the one you are reading now, and answer three questions without scrolling to the executive summary. (1) Can you state the scope in one sentence? (2) How many findings show working exploit evidence? (3) Do the top five fixes have a named owner and a date? If any answer is no, the report is not yet ready to drive a fix plan, and you now know which section to ask the vendor to tighten.
If you have not run a test recently, the decision on cadence and the retest that verifies the fix held is covered in how often you should penetration test.
Penetration Test Report vs Vulnerability Scan Report: What's the Difference?
They answer different questions, and mixing them up is how a clean scan gets read as an all-clear. A vulnerability scan report asks what is on your network: the versions, the open ports, the unpatched components. A penetration test report asks what an attacker can do with it: the demonstrated paths, the data that moved, the access that broke.
| Dimension | Vulnerability scan report | Penetration test report |
|---|---|---|
| Question answered | What weaknesses exist | What an attacker can do |
| Evidence | Version and signature match | Demonstrated impact, request and response |
| Cadence | Continuous, on a schedule | Periodic, and after significant changes |
| A clean report means | No known version-based flaw in scope | The tested paths and roles held |
| Primary reader | The patch and platform team | Decision makers and fix owners |
The last row is the one that matters for how you read each document. A scan report is an input to your patch backlog. A test report is an input to your risk decisions, and it needs an executive read as well as a technical one. The fuller boundary between the two disciplines is in Penetration Testing vs Vulnerability Scanning.
The cost context is why the distinction matters beyond the team. IBM's 2026 Cost of a Data Breach report puts the global average breach cost at $4.99 million, a 12 percent increase over the prior year and a record high [1]. The breaches that produce that number rarely start with a mid-score configuration finding. They start with a path that someone, or some threat actor, demonstrated first.
How Do You Turn a Penetration Test Report Into a Fix Plan?
A report is not finished being read until it produces three artifacts: an ordered fix list with owners and dates, a statement of what the test could not say, and a retest commitment. The first is the one most organizations skip.
The fix list should inherit the tiers above: Tier 1 in days, Tier 2 in the current cycle, Tier 3 into the patch backlog with a scanner watching. Assign every line an owner from the team that controls the fix, not the team that was told about it. Compliance-driven tests, whether the requirement is PCI DSS 11.4 or an insurer's questionnaire, read the same way: the assessor cares that the report exists, but the fix list is what protects you.
The second artifact is the limits statement: what the test did not cover. A scope that excluded your API, your cloud account, or your third-party integrations means a clean result is a statement about a smaller surface, and the report should say so in writing. The third is the retest. A fix that is never re-validated is an assumption, and the next test will present it as a new finding. That is the whole subject of our post on what a retest actually proves, and the assessor side of the question is in Your Penetration Test Report Is Evidence, Not a Findings List.
If you want a report built to be read this way, with the scope stated in writing, exploit evidence on every Tier 1 and Tier 2 finding, and a retest that verifies the fix, the managed penetration testing service is the engagement to book. When you are comparing vendors, the cost drivers that move the number and the five signals that separate a test from a report are the two posts to have open in the other tab.
How Clone Systems Can Help
Clone Systems runs penetration tests as manual engagements with a written scope, demonstrated evidence, and a retest. The report is written to be a decision document from page one:
- Scope in writing before the first request. The environments, identities, and flows are named, so a clean line means something.
- Proof of exploit on the findings that matter. Tier 1 and Tier 2 findings carry the request, the response, and the impact, not a signature match.
- Priority by risk, not by score. The report orders findings by exploitability and reach, so the fix list starts from the right end.
- A retest that closes the loop. A second pass scoped to the original findings, so a fix is a fix.
The full engagement is described on the managed penetration testing page.
Frequently Asked Questions
What is a penetration test report? A penetration test report is the written record of a security test: the scope, the methodology, the findings with evidence, and the remediation guidance. Its value is the ordered fix list you extract from it, not the findings list alone.
How long does a penetration test take? Most single-environment tests run one to three weeks from scoping call to final report, and cloud or multi-environment scopes take longer. The report should state what was covered and what was not, so the timeline is only half the story.
What do I do after a penetration test? Turn the report into an ordered fix list with owners and dates, and schedule a retest for the findings you fix. File the scope and the limits in writing, so the next test starts from a known baseline.
How do I present penetration test results to management? Lead with the tiered view: the findings under active exploitation, the findings with demonstrated impact, and the rest as backlog. Close with the ordered fix list, the owners, and the dates, because that is the read that turns a report into a decision.
What is the difference between a penetration test and a vulnerability scan? A vulnerability scan lists known weaknesses by version and signature, while a penetration test demonstrates what an attacker can do with them, including paths a scanner cannot model. A clean scan and a failed test can describe the same environment.
What is proof of exploit in a penetration test report? Proof of exploit is the evidence that the tester actually achieved the impact: the request and the response, the command that ran, the data that was read. It is the difference between a finding you must fix and a finding you can schedule.
Conclusion
A penetration test report is a decision document, and reading it as a findings list is how organizations under-fix the risks that matter. Run the 6-Question Report Read on the report in your inbox: scope first, then exploitability, then reach, then owners and dates. The CISA KEV due dates are counted in days, not sprints, and the findings with working proof of exploit are the ones that become breach notifications. When you are ready for a test whose report is built to be read this way, start with managed penetration testing at Clone Systems.
References
[1] IBM Security and Ponemon Institute, The Cost of a Data Breach Report 2026. IBM. https://www.ibm.com/reports/data-breach [2] CISA, Known Exploited Vulnerabilities Catalog. U.S. Cybersecurity and Infrastructure Security Agency. https://www.cisa.gov/known-exploited-vulnerabilities-catalog [3] NIST SP 800-115, Technical Guide to Information Security Testing and Assessment. National Institute of Standards and Technology. https://csrc.nist.gov/pubs/sp/800/115/final [4] CISA, CISA Urges Patching Newly Exploited Vulnerabilities in Ivanti Connect Secure, October 13, 2026, updated October 30, 2026. https://www.cisa.gov/news-events/alerts/2026/10/13/cisa-urges-patching-newly-exploited-vulnerability-ivanti-connect-secure [5] Clone Systems, How to Choose a Penetration Testing Vendor: The 5 Signals That Separate a Test From a Report. https://www.clone-systems.com/blog/how-to-choose-a-penetration-testing-vendor [6] Clone Systems, How Often Should You Penetration Test? Frequency, Scans, and the Retest Nobody Books. https://www.clone-systems.com/blog/how-often-should-you-penetration-test-frequency-scans-and-the-retest-nobody-books [7] Clone Systems, Why Passing a Penetration Test Retest Isn't the Same as Fixing the Root Cause. https://www.clone-systems.com/blog/why-passing-a-penetration-test-retest-isnt-the-same-as-fixing-the-root-cause [8] Clone Systems, Penetration Testing vs Vulnerability Scanning: Why the Difference Matters. https://www.clone-systems.com/blog/penetration-testing-vs-vulnerability-scanning [9] Clone Systems, Penetration Test Cost: What Moves the Number and Why Two Quotes for the Same Scope Can Differ by 5x. https://www.clone-systems.com/blog/penetration-test-cost-what-moves-the-number [10] Clone Systems, Your Penetration Test Report Is Evidence, Not a Findings List. https://www.clone-systems.com/blog/penetration-test-report-is-evidence-not-a-findings-list [11] Clone Systems, Managed Penetration Testing service page. https://www.clone-systems.com/managed-penetration-testing-services/