Penetration Testing Results: How to Read a Pentest Report and Act on It

Penetration testing results tell you what an attacker could do to your systems, how serious each weakness is in your environment, and what to fix first. Read the report in this order: the overall risk and scope, the coverage note for what was attempted and held up, the findings sorted by adjusted severity rather than raw CVSS, and the attack narrative that shows how findings chain. Then turn it into a plan: confirm or dispute each finding within a week, fix by risk, get the fixes retested, and give each audience the document it needs, which is rarely the full report.

This guide is for whoever received the report; if you write reports, use our penetration testing report template. The worked example is our sample penetration testing report, the format our penetration tests deliver at the fixed prices on our pricing page.

Read the report in this order

Reports are laid out for completeness, not for reading.

Step	Section	The question it answers	Red flag
1	Executive summary	How exposed are we, and what is the worst issue?	Boilerplate, or scanner counts with no attack path
2	Scope	Was our system tested, logged in, in every role?	Differs from what you bought
3	Coverage note	What was attempted and held up?	Missing, so “tested and fine” looks like “never reached”
4	Summary of findings	How much is there to fix?	Severities identical to a scanner’s defaults
5	Attack narrative	How do findings combine into a breach?	Missing on a network or red team test
6	Detailed findings	How do we reproduce and fix each one?	No evidence, no reproduction steps
7	Retest and attestation letter	What is verified fixed, and what can we share?	Retest billed extra; letter hides open findings

How penetration test results differ by test type

The reading order holds for every report, but what the findings look like, and which page matters most, changes with what was tested.

Test type	What the findings look like	Read this first
Web application and API	Tied to a request and a user role: broken authorization, injection, session and business-logic flaws	Which role found it, and whether it crosses customers or tenants
External network	Exposed services, known CVEs on edge systems, weak remote access	Whether exploitation was shown or the finding rests on a version number
Internal network and Active Directory	Chains from one foothold to credentials to privileged access	The attack narrative, then the links it depends on
Cloud	Identity and configuration: over-permissive roles, exposed storage, reachable credentials	What one compromised identity or workload could reach

Severity and CVSS: decoding the numbers

Most reports rate findings with the Common Vulnerability Scoring System. The CVSS v3.1 bands are 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 (FIRST, CVSS v3.1 specification).

The vector string beside the score matters more: it says why the score is what it is. Finding F-01 in our sample report, a broken object-level authorization flaw on an invoices API, scored 7.1 (High) with the vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N:

Metric	Value	What it tells you
Attack Vector	Network	Exploitable remotely
Attack Complexity	Low	No special conditions needed
Privileges Required	Low	The attacker needs an ordinary user account
User Interaction	None	No victim has to click anything
Scope	Unchanged	Impact stays under the same security authority (the API and its data)
Confidentiality	High	Every customer’s invoices are readable
Integrity	Low	Limited tampering: notes on other customers’ invoices
Availability	None	No effect on uptime

Preconditions matter more than the score: “needs an account” is no barrier if anyone can sign up for a free trial. Impact ratings tell you the kind of incident: high confidentiality impact on billing data can become a reportable breach, depending on the data and the notification laws that apply, while high availability impact on an internal tool means an outage.

CVSS v4.0 (FIRST, November 1, 2023) keeps the same bands, drops Scope and adds Attack Requirements.

Risk vs severity: why a good report re-rates findings

Severity describes the flaw. Risk describes what it means to you: how likely exploitation is and what it would reach. FIRST says CVSS “should not be used alone to assess risk” (CVSS v3.1 User Guide, section 2.1), and our threat vs vulnerability vs risk explainer covers the vocabulary.

A good report shows two ratings, the CVSS base score and a severity adjusted for your environment, and explains any difference. A Critical with no explanation of why it is critical on this asset is a scanner rating in a nicer font. The Center for Internet Security’s Essential Guide to Election Security gives the classic case on its page about remediating penetration test findings: a 5/10 issue on an internet-exposed production system holding sensitive data can matter more than a 7/10 on an internal test system with none.

You can re-rank findings yourself if you write down why. For PCI DSS, the Council confirms that “Requirement 6.3.1 does not require that an entity accepts risk rankings assigned by external sources” (PCI SSC FAQ 1597). For findings tied to a published CVE, active exploitation matters more than the score; our guide to vulnerability remediation shows how to use CISA’s KEV catalog and EPSS to set the fix order, and risk-based vulnerability management turns that into a standing model.

Attack chains: when moderate findings add up to a critical

CVSS scores one vulnerability at a time. Its user guide says so (section 3.4) and asks anyone scoring a chain to list each link’s score beside the chained result. Attackers chain, which is why the attack narrative is often the most important page of a network report. A typical chain from an internal network penetration test, at a high level:

1. Legacy name resolution (LLMNR and NBT-NS) lets a tester on the network capture a user’s NTLMv2 authentication response, which can be cracked offline or relayed. Medium; our Responder explainer covers the attack and the fix.
2. The password is weak enough to crack offline. Low or Medium.
3. Any domain user can request a Kerberos service ticket for a service account and crack it offline if the account’s password is weak and years old (Kerberoasting). Medium.
4. That service account has administrative rights over the domain: Domain Admin.

None is Critical alone; together they hand over the domain. Look for two links: the cheapest to break now (turning off LLMNR and NetBIOS name resolution is a configuration change, not a project), and the one that breaks the most paths (service accounts and privileged groups, which BloodHound maps across a domain). Good narratives map each step to MITRE ATT&CK, showing defenders where detection should have fired.

False positives: how to dispute a finding properly

In a manual test, false positives should be rare, because every finding carries its own proof. NIST lists identifying false positives as a primary goal of analysis and notes that manual examination typically gives more accurate results than comparing tools (NIST SP 800-115, section 7.3).

They do appear in version-based findings, where a scanner reads an old version string and reports every CVE filed against it. Linux vendors backport fixes into older packages, so the version string stays old after the patch; Red Hat warns that such tools produce “false positives as the tools do not take into account backported security fixes” (Red Hat, Backporting Security Fixes). Raw scanner output belongs in an appendix marked unvalidated. If the whole report reads that way, you bought an unvalidated scan, not a penetration test; our vulnerability assessment report template shows what a validated assessment contains.

When you disagree, say which kind of disagreement it is; each ends differently:

Your position	Evidence to send	How the reissued report shows it
False positive: the weakness does not exist	The backported package, or config showing the feature off	Withdrawn, with a note
Not exploitable here: a control blocks it	The control and how you verified it	Severity lowered, reason stated
Accepted risk	A signed decision: owner, reason, review date	Stays open, marked accepted
Same root cause as another finding	The shared component	Grouped under one fix
Out of scope	The signed scope	Removed, or moved to an out-of-scope note

Raise scope disputes the day you notice them. Do not argue findings down before an audit: a withdrawn finding with no evidence trail raises more questions than an open one with a plan.

Common penetration testing findings and what they say about you

Findings get fixed one by one; patterns tell you what is broken in the process that produced them. NIST calls this root cause analysis, because “a root cause can often be traced to program-level weaknesses” (SP 800-115, section 7.3). Common findings and the gap each usually points to:

Common finding	Where	What it usually says about the process
One user reads another’s data (IDOR)	Web apps, APIs	Authorization not enforced on the server for every object
Known CVEs on internet-facing systems, sometimes remote code execution	External network	Edge appliances sit outside the patch process
LLMNR, NBT-NS and relay weaknesses such as SMB signing not required	Internal network	Windows defaults never revisited
Weak service account passwords, over-privileged groups	Active Directory	Nobody owns service accounts or reviews privileged groups
Over-permissive cloud identities, exposed storage	Cloud	Permissions granted for convenience, never reviewed
Reusable reset links, no rate limiting, MFA gaps	Apps, remote access	Authentication built feature by feature without a standard

If a pattern repeats across two reports, fix the process; NIST’s own example is updating the patch management process (section 8.1). Read tool names in a finding the same way: the tool is not the problem, the control that let it work is. Our explainer on what an msfvenom finding means walks through one example.

What clean penetration testing results actually mean

Penetration test results with few or no high findings are good news only if the test could have found them. Check that the scope covered the systems holding sensitive data, that testing was authenticated in every role, and that the coverage note lists what was attempted and held. A short report with a thorough coverage note is a strong result; without one it tells you little. Year over year, track repeat findings and time to verified fix, not the raw count, which a narrower scope also lowers.

From report to retest: a remediation timeline

This assumes criticals were escalated during testing; ours are escalated the day they are confirmed and appear on the findings platform at once, so urgent fixes often start before the report arrives.

When	What happens	Output
Days 1-3	Readout with the testers; raise any finding you doubt	Disputes raised with evidence
Days 3-7	Confirm findings, group by root cause, assign owners and dates	Tickets, draft risk acceptances
Weeks 1-4	Critical and high findings fixed or mitigated, criticals first	Change records linked to finding IDs
Weeks 2-8	Mediums and lows fixed where possible; root-cause projects scheduled	Updated status
By week 8	Retest of remediated findings	Fixed, partially fixed or not fixed, with evidence
After the retest	Reissued report and attestation letter	What auditors and customers receive

The free retest sets the pace: request it within two months of delivery and fix what you can first. Anything still open is marked not fixed, so give it an owner and target date or a signed risk acceptance.

Compliance sets floors: PCI DSS Requirement 11.4.4 requires exploitable findings to be corrected per your risk ranking and the test repeated to verify them; our PCI DSS penetration testing page covers the Requirement 11.4 test itself.

New York’s cybersecurity regulation requires covered entities to “timely remediate vulnerabilities, giving priority to vulnerabilities based on the risk they pose” (23 NYCRR 500.5(c)); our NYDFS 500.5 penetration testing page covers the annual test the same section requires.

The retest verifies the findings you fixed, not the whole scope, so anything shipped since is untested. NIST says verification works “only if a mirror copy of the original test is performed” (SP 800-115, section 8.3). Partial fixes are common when one flaw sits on several routes (F-01 in our sample sat on two) and the fix reaches only one.

The attestation letter: what it proves and what it does not

The attestation letter is a one-page statement from the testing firm. Ours states who tested what and when, the standards followed, the number of findings by severity and the retest outcome, and leaves out vulnerability details so you can share it.

It is not a certification, a pass mark or an audit opinion: no recognized body certifies that a system passed a penetration test, whatever a vendor’s certificate says, and a SOC 2 opinion comes only from a CPA firm. Read any letter for dates that match the report, a scope naming the systems the reader cares about, and an honest status for open findings. Ask for it after the retest, so it reports outcomes, not an open list.

What to send auditors, customers, insurers and acquirers

The full report is a map of how to attack you. NIST warns that inappropriate release of assessment data can “increase the likelihood of exploitation” (SP 800-115, section 7.4.2). Send each reader the least that answers their question:

Reader	What to send
Board and leadership	Executive summary and the trend against last year
SOC 2 auditor	Full report, retest results, tickets linking findings to fixes, risk acceptances
PCI DSS assessor	Full report (with segmentation results if you segment), methodology, retest evidence for 11.4.4
ISO 27001 certification body	Report and retest as evidence for technical vulnerability management (Annex A 8.8)
Enterprise customer	Attestation letter; more only under NDA if the contract requires it
Cyber insurer	Attestation letter and answers to the application questionnaire
Acquirer	Full report and retest results, under NDA in the data room

SOC 2 does not make a penetration test mandatory; the Trust Services Criteria list it among the ongoing and separate evaluations management can use (a CC4.1 point of focus), and auditors look for the loop from finding to fix to retest; our SOC 2 penetration testing page covers the test itself. The SOC 2 evidence checklist lists every item; see also PCI DSS penetration testing requirements, cyber insurance and cybersecurity due diligence.

Penetration testing reporting at Invadel, and what it costs

Every Invadel penetration test except a phishing campaign, which reports click and credential metrics, ends in this format: CVSS v3.1 scores and vectors, an adjusted severity with the reason for any change, an attack narrative, and findings mapped to the controls your auditor examines, ready to upload into Vanta, Drata and Secureframe. The retest is free (phishing excepted): request it within two months of report delivery, and we reissue the report and letter with each finding marked fixed, partially fixed or not fixed.

Published starting prices, fixed in writing from the scoping questionnaire with no sales call: API testing from $4,000, external network from $4,200, web application from $5,200 and internal network from $6,000. Every engagement type is on our penetration testing services page, with size bands on penetration testing pricing. Our anonymized case studies show how real findings were sequenced and fixed.

Frequently asked questions

What do penetration testing results include? An executive summary, the scope, a findings table by severity, each finding with evidence, reproduction steps and a fix, and an attack narrative. After remediation, retest results and an attestation letter.

How do I know if a pentest finding is a false positive? A real finding from a manual test shows evidence: the request, the response or the data reached. If the only evidence is a version number, ask the tester to confirm exploitability; backported patches often make such findings wrong.

What is the difference between severity and risk in a penetration test report? Severity, usually a CVSS score, rates the flaw in general. Risk rates it in your environment: exposure, the data at stake and active exploitation. A good report shows both.

How long should we take to fix penetration test findings? Agree a target date per finding at the readout, following your written remediation policy, and fix what you can before the free retest, requested within two months of delivery. Our remediation guide has a severity-based target table to copy into that policy.

Can we share the full penetration test report with a customer? You can, but it is rarely the right document: the full report is a map of how to attack you. Send the attestation letter first, and release the full report only under NDA when a contract requires it, after the retest so it shows what was fixed.

What is a good penetration test result? One whose scope covered the systems holding sensitive data, with authenticated testing in every role, a coverage note showing what held, and every fix verified on the retest. A low finding count alone proves little.

The short version

Read the scope, coverage note, adjusted severities and attack narrative before the finding count. Dispute findings with evidence, fix by risk rather than raw CVSS, break chains at the cheapest link first, and get every fix retested before the attestation letter goes out. See the format on the sample report, compare fixed prices across our penetration testing services on the pricing page, then scope your test for a written price the same day.