Key Takeaways:
A real penetration test report tells an attacker story, not just a vulnerability list. It should document the scope, methods, exploits, outcomes, and the full Path to Compromise showing how an adversary could move through your environment toward valuable systems or data.
Context determines value. Strong findings reference your actual assets, applications, credentials, business processes, topology, and operational constraints. A flat scanner-ordered list with generic findings and boilerplate remediation is closer to a vulnerability assessment than a true penetration test.
CVSS is not business risk. Base CVSS scores measure technical severity independent of environment; teams should prioritize findings by exploit chains, asset criticality, exposed credentials, likely threat actors, and potential business damage – not score alone.
The report must work for multiple audiences. Executives need concrete outcomes and risk decisions; technical teams need validated evidence and actionable fixes; compliance and legal teams need relevant control mappings and proof that issues were addressed. A vendor-led readout helps turn the document into shared understanding.
Security improvement happens after delivery. Convert findings into owned remediation work with deadlines, dependencies, validation criteria, and cross-functional participation. Retest fixes to confirm closure, preserve an audit trail, and ensure the remediation did not introduce regressions.
What a real penetration test report contains, how to read one, and how to tell the difference between a report that improves security versus one that checks a compliance box.
Most penetration test reports get filed and forgotten. Not because the buyer doesn’t care, but because the report doesn’t give them much value to act on. Findings are generic. Remediation reads like it was copy-pasted from a vendor knowledge base. The narrative of what an attacker actually did is missing.
A real penetration test report does the opposite. It tells you, in concrete terms, how an adversary moved through your specific environment, what they were able to reach, what impeded them, and what your team should do about it. The difference between the two kinds of reports shows up in the document itself, if you know what to look for.
This article walks through what’s inside a real penetration test report, how to read each section, and how to turn findings into actual security improvements. Along the way it points out the tells that separate real human work from automated output dressed up to look like a bona fide test.
What Is a Penetration Test Result Report?
A real penetration test report guides you toward better security by showing you both what to fix and what attacker behavior to disrupt before damages are realized.
Every recommendation should be unique to your environment, and every finding should matter to your business. A real report transfers the testing team’s expert knowledge to yours in a form you can act on now and in the future.
The report should be the written record of an authorized attack against your environment, performed in a way that emulates real-world threat capabilities and accounts for your specific threat model.
It should document:
- What was tested
- How it was tested
- What was discovered
- What was exploited
- What was achieved as a result
- What disruptors you can deploy to prevent damages in the event of a future attack
A real penetration test report accounts for attacker behavior, not just vulnerabilities, and the distinction is operational. An attacker who wants your data may have to compromise a web server, pivot to a desktop, and only then reach what they came for. That sequence is a Path to Compromise (P2C), or attack chain. Its shape is constrained by your environment, which makes it predictable and easy to defeat. A customer who knows their P2Cs can build effective and efficient threat informed defenses and knows exactly where to lay the traps.
Who Should Review the Report?
A penetration test report should be written with multiple audiences in mind. The technical findings need to land with engineering and security teams who will own remediation. The executive summary needs to land with leadership who will own budget and risk. Compliance and legal need enough detail to answer auditors. If the report only speaks to one of these audiences, half of your organization can’t act on it. Critically, your penetration testing vendor should do a readout of the report to answer questions, provide clarity, and close any gaps that might exist in the report.
Penetration Testing Report Formats
There isn’t a single industry-standard format, but there is a recognizable minimal structure.
Most professional penetration test reports follow a structure built up over years of industry practice. The exact section names vary, but the minimum components are consistent. A typical report contains:
- Executive summary
- Description of scope and methodology
- List of technical findings with methods for remediation
- Risk ratings
- Raw evidence like screenshots and tool output
- Compliance mappings (where relevant)
Compliance frameworks influence the format. PCI DSS, HIPAA, SOC 2, GDPR, and DORA each have their own expectations about what a penetration test report should contain. None of them prescribe a single rigid format, but they all expect the report to demonstrate that the testing actually happened and that the findings were addressed. A vendor whose report can’t satisfy your specific compliance framework is a vendor who hasn’t done this work before.
The format itself is a tell. A report that’s clearly the output of a single scanner, with findings listed in the order the scanner produced them, is a vulnerability scan with a cover sheet. A report that’s organized around your environment, with findings grouped by attack path or by impacted asset is the output of a human operator who understood what they were looking at.
Components of a Penetration Testing Report
Every section serves a purpose. Knowing what each section should contain tells you immediately whether the section was written for you or generated for everyone.
Executive Summary
The executive summary is the only section most executives will read. It needs to answer three questions in plain language: what was tested, what are the highest impact findings, and what needs to happen next. A real executive summary speaks in the context of your organization. It names specific business risks, ties findings to specific assets that matter, and translates technical outcomes into language an executive can act on. A generic executive summary speaks only in the context of vulnerabilities. It catalogs weaknesses in the abstract, without organizational context, and could have been written before the test started.
Scope and Methodology
Scope describes exactly what was in bounds. Methodology describes how the team approached it. Both sections should be specific. The scope section should list the actual IP ranges, applications, accounts, and rules of engagement that governed the test. The methodology section should describe how the team adapted to what they found, not just which framework they followed. Generic methodology language like ‘we followed OWASP and OSSTMM’ without saying what that meant for your engagement is a sign the methodology was boilerplate.
Technical Findings
The technical findings section is the heart of the report. Each finding should include what was discovered, how it was exploited or validated, evidence proving it exists in your environment, what an attacker could do with it, and how to remediate. Generic findings copied from scanner output or template libraries are easy to spot. Specific findings that reference your hostnames, your applications, your business processes, and your data are what a real test produces.
CVSS Scores and Risk Ratings
The Common Vulnerability Scoring System (CVSS) quantifies the severity of a vulnerability across three metric groups: Base, Temporal, and Environmental. The Base Score captures the intrinsic characteristics of the vulnerability and is intentionally environment-independent. The Environmental Score lets a reviewer adjust the score for the specific organization, but in practice it is rarely applied. Most CVSS scores published in vulnerability databases and pentest reports are Base Scores only.
That distinction matters because a Base Score alone is not the same as risk to your business. A CVSS 9.8 on an isolated test server can be lower business risk than a 6.0 on a system that holds your customer data. A real report doesn’t stop at the Base Score. It applies the Environmental metrics, or its own business-context analysis, to turn abstract severity into actual risk for your organization. A report that treats the Base Score as the final word is a report that doesn’t understand your environment.
Compliance Considerations
If the test was driven by a compliance framework, the report should map findings to the relevant controls. PCI DSS, HIPAA, SOC 2, GDPR, DORA, GLBA, and similar frameworks each have specific requirements about what should be tested and what should be reported. A real report demonstrates that the test satisfied those requirements and notes any gaps. Don’t accept a report that hand-waves compliance language without specific control mappings.
Remediation and Retesting Plan
Every finding should have remediation guidance that fits your stack and your operational reality. Generic remediation language like ‘apply the latest patch’ or ‘follow vendor hardening guidance’ is useless. Specific remediation language like ‘upgrade the affected Apache instances on hosts A, B, and C to version X, then restart the load balancer in the maintenance window’ is what your team needs to actually fix the issue. The plan should also describe how the vendor will validate the fix, either through a retest or through evidence review.
How to Interpret Penetration Test Results
Reading a report well means reading it for what it tells you about your defenses, not just for the list of things that are broken.
Review the Executive Summary
Start with the executive summary, but read it skeptically. The summary should describe the worst thing that was achieved during the test in concrete terms. If the summary talks about ‘multiple vulnerabilities of varying severity’ without saying what an attacker could do with them, the test didn’t reach a meaningful conclusion. A real summary names the worst-case outcome. Something like ‘a Path to Compromise was demonstrated from the external perimeter to the customer database with full read access’ tells you something. ‘Several medium-severity findings were identified’ does not.
Verify Severity and Impact of Findings
Don’t accept severity ratings at face value. Walk through each high-severity finding and ask whether the impact described in the report matches the impact in your environment. A finding rated critical that affects an isolated lab server probably isn’t critical to your business. A finding rated medium that exposes production credentials probably is. Use the report’s severity as a starting point, not as the final answer.
Understand Root Causes of Issues
Every finding has a surface-level cause and an underlying root cause. A real report identifies both. The surface cause might be that a specific service was misconfigured. The root cause might be that no one owns the configuration baseline for that service class, or that the patching cadence for legacy infrastructure has slipped. Fixing the surface cause closes one finding. Fixing the root cause closes the class of finding. A good report helps you decide which to do.
Prioritize Fixes Based on Risk
Not every finding is worth fixing immediately, and some are worth fixing even if their severity rating is low. Prioritize by what an attacker could chain into a Path to Compromise, what an attacker would target in your environment given the threat actors most likely to come for you, and what would cause the most damage if exploited. Treat the report as input to that conversation, not as the conclusion.
Collaborate Across Teams
Findings cross team boundaries. A web application vulnerability might require coordination between application engineering, infrastructure, identity, and security operations to remediate fully. The report is most useful when it’s read as a shared artifact that drives a cross-functional remediation plan, not as a security team task list. Bring application owners, infrastructure leads, incident response, and the executive sponsor into the conversation. The cross-team conversation is also where the report’s value compounds.
How to Act on Pentesting Results
A report drives action or it doesn’t. The difference is structure, ownership, and validation.
Develop a Structured Remediation Plan
Every finding that you intend to remediate needs a structured plan. The plan should name the owner, the target completion date, the validation method, and any dependencies. Without a structured plan, remediation drifts. With one, the report turns into measurable security improvement. Track the plan in whatever system your organization uses for engineering work, not in a one-off spreadsheet that gets forgotten.
Implement Fixes and Security Controls
Implementation is where most remediation breaks down. The fix described in the report might require an architectural change, a configuration management update, a vendor patch, or a workflow change. Some fixes will fail the first time, either because the patch didn’t apply cleanly, the configuration didn’t propagate, or the underlying assumption in the remediation guidance didn’t match your environment. Plan for iteration. A real penetration testing vendor expects iteration and supports you through it.
Validate and Retest Vulnerabilities
A fix isn’t a fix until it’s been validated. A real vendor offers retesting either as part of the original engagement or as a follow-on. Retesting verifies that the specific issue has been closed and that the fix didn’t introduce a regression. Retesting also produces a clean audit trail showing that the finding was addressed, which is what auditors and executive stakeholders want to see.
Developing a Pentesting Schedule
A single test is a snapshot. A program of tests is a posture. Most organizations should run a full-depth penetration test at least annually and after any significant change to their environment. Build a schedule that aligns with your release cadence, your compliance calendar, and your threat landscape. The report you just received is most valuable when it’s one in a series of tests that show how your posture is moving over time.
Common Mistakes When Reviewing Penetration Test Reports
The mistakes that hurt the most all share a common shape. They treat the report as a document instead of as an input to decision making.
Several recurring patterns rob organizations of the value they paid for. Watch for these:
- Reading only the executive summary. The summary is the briefing, not the test. The technical findings and Path to Compromise narrative are where the real intelligence lives. Skip them and you’ve paid for a deliverable you never opened.
- Treating CVSS as the final ranking. CVSS scores severity. They don’t score business risk. Use them as a starting point, then translate severity into your context.
- Filing the report instead of acting on it. A report that goes into a SharePoint folder and never resurfaces is money spent for an artifact, not security. Build the remediation plan the same week the report lands.
- Skipping retesting. Without retesting, you don’t know whether the fix worked. Auditors don’t accept your word that the finding is closed. Neither should you.
- Reading the report in isolation. Findings often touch multiple teams. Reading the report alone in the security organization is how findings stall.
- Accepting templated remediation. If the remediation guidance could have been pulled from a vendor knowledge base without the tester ever looking at your environment, it probably was. Real remediation references your stack, your topology, and your operational constraints.
If your report contains a flat list of vulnerabilities with no chained reasoning, generic remediation guidance, and no documented Path to Compromise, the work was scoped to discover, not to test. That’s a vulnerability assessment, not a penetration test.
Case Study: How a Real Penetration Test Report Drove Remediation
One Netragard engagement against a well-known casino shows how a report turns testing into action.
During one Netragard engagement against a well-known casino, our operators began with open source intelligence collection. We extracted employee information from LinkedIn, registered a doppelganger domain to impersonate the casino’s legitimate domain, used a technique called email seeding to plant our address in recipients’ auto complete caches, and delivered a zero-day Microsoft Word exploit through the trust relationship we had built. Within 30 minutes of initial access we had more control over the casino’s network than its own IT department.
What made the engagement valuable was not the exploit. It was the report. The report contained a fully narrated Path to Compromise that started with the OSINT collection and ended at the casino’s most sensitive systems, naming every step, every credential harvested, every misconfiguration leveraged, and every detection control that should have caught us but didn’t. The client’s remediation plan came directly out of that narrative.
Reading the report, the client could see exactly:
- where their detection capability had failed
- which trust relationships had been weaponized
- which third-party tooling had inherited unsafe defaults.
The remediation was specific:
- Tighten the email infrastructure to block the doppelganger pattern.
- Reconfigure the third-party support tooling to remove stored credentials.
- Re-tune the detection rules to surface the chain of behaviors the operators had used.
None of these were generic fixes. They came directly from the contextualized threat intelligence the report contained.
Six months later, an actual threat actor attempted a similar campaign against the casino. The detection controls fired. The doppelganger domain was blocked at the email gateway. The trust relationship couldn’t be re-established. The damage was bounded because the report had been treated as intelligence, not as an artifact.
That’s what a real penetration test report does. It turns adversary tradecraft into actionable defense.
Getting Started with Penetration Testing
If you’re commissioning a test for the first time, scope and provider selection determine whether the report you eventually receive is worth reading.
The quality of the report you’ll receive is determined long before the test starts. It’s determined by scope, by provider selection, by the questions your provider asks you during scoping, and by whether the engagement is structured as adversary emulation or as compliance scanning. If you’re starting your first penetration test, the most important decisions are upfront.
Scope the engagement around what an attacker would actually target, not around what’s easiest to test. Pick a provider whose methodology emphasizes adversary emulation over vulnerability enumeration. Make sure the engagement includes a documented Path to Compromise where scope and engagement type permit one. Then, when the report arrives, read it the way this article describes.
FAQ
What are the results of penetration testing?
The results of a penetration test are documented in a written report that describes what was tested, how it was tested, what was discovered, what was exploited, what was achieved as a result, and what disruptors you can deploy to prevent damages in the event of a future attack. A real test produces contextualized threat intelligence: a documented Path to Compromise (P2C), or kill-chain, where scope permits; validated findings with evidence; prioritized remediation guidance unique to your environment; and an audit trail of operator activity. A test that produces only a list of vulnerabilities, without context, evidence, or any account of attacker behavior, is a vulnerability scan with a cover sheet, not a penetration test.
Does PCI Compliance Require a Specific Pentest Report Format?
PCI DSS does not mandate a single rigid report template, but it does require specific content. The report must describe the scope of the test, the methodology used, the findings identified, the exploitability of each finding, and the remediation status. PCI DSS v4.0 also expects evidence that segmentation controls were tested and that the test was performed by qualified personnel. A report that doesn’t satisfy these requirements won’t satisfy a PCI assessor.
Does NIST Compliance Require a Specific Pentest Report Format?
NIST guidance, particularly NIST SP 800-115, provides recommendations for the structure and content of a penetration test report rather than mandating a specific format. The guidance expects the report to include an executive summary, a description of methodology, technical findings, risk analysis, and remediation recommendations. Federal agencies and organizations operating under FISMA or FedRAMP often align their reporting expectations with NIST SP 800-115.
Does HIPAA Compliance Require a Specific Pentest Report Format?
HIPAA does not explicitly require penetration testing, but the Security Rule requires covered entities and business associates to conduct accurate and thorough risk assessments. In practice, this means most organizations subject to HIPAA include penetration testing in their security program and document the findings in a format that supports their risk assessment. The report should clearly identify findings that touch electronic protected health information (ePHI) and describe the remediation plan.
