Penetration testing

What is a Penetration Testing Report?

13 min read
What should a good penetration test report include?
Stay ahead of the game
Loading

click here to copy URL

What is a Penetration Testing Report?

A penetration testing report outlines the process, findings, and recommendations from a simulated attack on a company’s systems, applications or infrastructure. Its purpose is to help organizations understand how attackers could exploit their weaknesses and what they can do about them.

While the technical test is the core of the engagement, the pentest report is the product that drives internal action. A well-constructed report helps decision-makers prioritize work and allows security teams to focus on remediation. 

What Makes a Good Penetration Test Report?

A good penetration test report balances technical depth with a clear explanation. It should be detailed enough for engineers and IT staff to work from, while remaining accessible to management and other stakeholders.

It’s not just a list of vulnerabilities. It should provide context, highlight potential impact, and recommend realistic next steps. Reports that are too technical without interpretation are often overlooked or misunderstood. Likewise, oversimplified penetration testing reports leave security teams with gaps.

Clarity, structure and real-world relevance are what separate a good pentest report template from a generic one.

How to Write a Pentest Report in 6 Simple Steps

  • Collect and Document Evidence

As you progress through the test, capture technical evidence such as logs, screenshots, and error outputs. To avoid breaking your workflow, consider recording your screen or narrating findings in real time, then pulling screenshots later.

  • Draft the Core Findings First

Start by outlining the most impactful vulnerabilities, their potential consequences, and recommended fixes. Don’t worry about perfect wording at this stage—the goal is to capture the essentials while they’re fresh.

  • Classify and Prioritize Issues

Organise findings by severity, affected systems, and risk level. This helps the reader quickly understand what requires immediate attention versus what can be addressed later.

  • Refine for Clarity

Once the draft is complete, rewrite with precision. Replace jargon-heavy explanations with clear, accessible language so both technical staff and business leaders can interpret the risks.

  • Structure and Polish the Report

Format the document logically with sections for the executive summary, detailed findings, and remediation steps. Move highly technical data or supporting material to appendices so the main report remains concise and easy to understand.

  • Review and Proofread

Finally, check for errors, inconsistencies, or unclear phrasing. A polished, well-structured report reinforces your professionalism and ensures the client can act confidently on your recommendations.

What Does a Strong Pentest Report Look Like?

pentest report

Each penetration test is unique, reflecting an organization’s IT setup, applications, and vulnerabilities. A clear, structured report relies on presenting this information in a consistent and understandable format. Here is what’s typically included in a well-structured penetration test report:

Section

Priority

Placement in Report

Drafting Order

Detail Level

Technical Depth

Executive Summary

Essential

1

5

Low

Low

Key Findings

Essential

2

4

High

High

Engagement Overview

Essential

3

1

Low

Low

Complete Test Results

Essential

4

2

Medium

Medium

Risk Ratings & Scores

Optional

5 (appendix)

Pre-draft

n/a

n/a

Vulnerability Details

Optional

6 (appendix)

Pre-draft

Medium

High

Detailed Test Methods

Optional

7 (appendix)

3

High

High

Acronym Glossary

Optional

8 (appendix)

Pre-draft

n/a

n/a

1. Executive Summary

The executive summary offers a high-level overview of the penetration test report and is intended primarily for non-technical readers. It provides a concise summary of the assessment across one or two pages, highlighting the main findings, the overall risk level, and the scope of the engagement. The dates of the test are noted, along with a brief description of the systems or environments assessed.

Each finding is summarised in a sentence or two, giving decision-makers a quick understanding of the issues identified. Where appropriate, these summaries include links to the full technical details later in the report, allowing technical teams to review individual findings in greater depth.

A risk heat map or severity breakdown is often included, showing the number of vulnerabilities categorised as Critical, High, Medium, or Low.

2. Objectives and Scope

This section details what systems, applications, or environments were tested. It also outlines any exclusions or limitations that were agreed upon before the assessment.

Examples might include:

  • Web application testing of https://example.com
  • Internal infrastructure testing across three office locations
  • External perimeter testing, including exposed cloud services

This section should list the specific IP addresses or hostnames that were authorised for testing. It acts as a formal record of the approved targets and ensures that all testing activities remain within the agreed boundaries. Penetration testers must not engage with systems outside this scope.

The scope must align with the approved Rules of Engagement (ROE), a separate and legally binding document that defines what may be tested, how testing will be conducted, and any applicable restrictions. The scope detailed here should mirror the scope outlined in the ROE.

Where relevant, a Scope Exclusions section should also be included. This outlines any prohibited testing activities, such as Denial of Service (DoS) testing, which are often excluded due to the potential impact on business operations.

More details on specific testing types, such as external penetration testing or physical penetration testing, can influence the structure and findings of the report. 

3. Methodology

Explains the methodologies used and references any recognised frameworks or standards (e.g. OWASP, NIST, OSSTMM).

It should also outline the tools used and testing techniques, though not necessarily every command or line of code.

4. Findings and Risk Ratings

This is the main body of the pentesting report, where each vulnerability is documented in detail. The following information should be included for every finding:

  • Title of the issue (e.g. SQL Injection on login page)
  • Severity rating (e.g. High)
  • Description of the vulnerability
  • Affected assets or endpoints
  • Proof of concept (evidence that the flaw is real)
  • Risk or business impact
  • Remediation advice
  • References for further reading (e.g. CVE identifiers or OWASP resources. 

Each finding should follow a consistent format, combining technical accuracy with clear explanations that are understandable to a broader audience.

The severity rating assigned to each issue reflects the potential impact and likelihood of exploitation. This is typically illustrated using a severity chart.

However, the structure of these charts can vary between penetration testing providers. While many use categories such as Critical, High, Medium, and Low, others may apply different naming conventions or risk scoring methods. These classifications are not standardised across the industry, so the specific model used should be clearly outlined in the pentest report.

5. Screenshots or Proof of Concept (PoC)

Where appropriate, screenshots or excerpts from tool outputs can help reinforce findings and offer validation. These are especially useful in a sample pentest report for internal stakeholders who want assurance that the issue was confirmed. 

6. Remediation Advice

Each issue in a penetration test report should include clear remediation guidance. It should outline what needs to be changed, removed, or reconfigured to reduce or eliminate the risk. Where possible, offer safer alternatives or recommended settings. 

7. Post-Engagement Summary

A short section summarising any progress made during testing, such as vulnerabilities fixed in real time or retesting outcomes. It might also include a statement on whether further testing is advised.

8. Appendices

Optional but useful, this could include:

  • List of tools used
  • Glossary of terms
  • Full vulnerability scans (if relevant)
  • Detailed methodology
  • User credentials or test accounts provided (and confirmation they’ve been disabled)

What Is the Standard Penetration Test Report?

report

Most penetration testing reports follow established frameworks such as:. 

  • OWASP Testing Guide (for web applications)
  • CREST reporting standards
  • NIST SP 800-115 guidelines

A standard pen test report aims to offer clarity across three main audiences:

  • Executives and decision-makers
  • IT and security teams
  • Compliance or audit departments

If compliance requirements are involved (e.g. ISO 27001, PCI-DSS), the report should include specific evidence to demonstrate that relevant controls have been tested.

What Are The 5 Stages of Penetration Testing?

Understanding the five core phases of a penetration test helps clarify both the testing process and what appears in a penetration testing report. Each stage builds on the previous one, ensuring a structured and thorough assessment of an organization’s security posture.

1. Planning and Reconnaissance

This is the foundational stage where the scope of the test is defined, authorised targets are identified, and rules of engagement are established. The tester gathers preliminary information about the organization’s systems, network, and applications. Techniques can include passive reconnaissance, such as examining public records or social media, and active reconnaissance, like network mapping. 

2. Scanning

In this stage, testers use a combination of automated tools and manual techniques to identify vulnerabilities. Scanning helps map the attack surface and find weaknesses that could be exploited. Typical activities include vulnerability scanning, network mapping, and enumeration of services or applications. 

3. Gaining Access

Here, the tester attempts to exploit identified vulnerabilities to gain access to systems, applications, or sensitive data. This may involve techniques such as SQL injection, phishing, password attacks, or exploiting misconfigured services. The goal is to simulate real-world attacks and understand how an adversary could compromise systems. Evidence collected during this stage forms the basis for many of the findings in the final pen test report.

4. Maintaining Access

In certain penetration tests, testers assess the ability to maintain persistence on compromised systems. This simulates scenarios where an attacker remains undetected over an extended period, moving laterally across networks or escalating privileges. Techniques used in this stage help organizations understand the risks associated with long-term breaches and the effectiveness of monitoring controls.

5. Analysis and Reporting

The final stage involves consolidating all findings into a structured report. Each vulnerability is documented with detailed evidence, potential impact, risk rating, and remediation advice. This stage translates technical testing into insights for IT teams, executives, and compliance stakeholders, forming the core of the penetration testing report.

Penetration Testing vs Vulnerability Assessment

critical risk report

Penetration testing and vulnerability scanning are invaluable tools for organizations looking to assess the security of their IT networks.

During a penetration test, a qualified, independent expert uses a combination of manual and automated methods to simulate a real-world attack on an organization’s systems. The frequency of penetration tests is important for maintaining security; we recommend conducting tests at least annually.

Although the two are often confused, a vulnerability assessment (VA) is not the same as a penetration test.

Aspect

Vulnerability Assessment

Penetration Testing

Purpose

Identify known weaknesses

Simulate real-world attacks

Approach

Mostly automated scans

Manual and targeted testing

Depth

Surface-level

In-depth exploitation

Output

List of vulnerabilities

Exploitable paths with impact

Skill

Low to medium

High (requires specialist expertise) 

A vulnerability assessment might show that a server is running outdated software. A penetration test goes further by trying to exploit it and demonstrating what an attacker could do next.

This difference affects the reporting style too. Vulnerability assessment reports tend to be longer lists generated by tools, whereas penetration test reports include more context, structure, and interpretation.

The Importance of a Strong Penetration Testing Report

internal report

Penetration testing goes beyond merely exploiting weaknesses; it’s about delivering a clear, actionable assessment of an organization’s security.

A well-crafted penetration testing report serves as a tool for clients to improve their security strategy. It provides insights to determine:

  • Remediations: Specific actions to address and mitigate identified vulnerabilities.

  • Security Budgeting: Guidance on the resources and personnel required to strengthen the security team.

  • Tool and Process Investments: Recommendations for new defensive tools and strategies to bolster overall protection.

  • Training Needs: Identifying areas where the security team would benefit from further cybersecurity training.

A penetration testing report is not just a list of findings but a roadmap for improvement. Clear reporting helps security teams and organizations communicate technical issues in a way that is easily understood, particularly by non-technical stakeholders such as executives.

Turn Penetration Test Results into Real Security Improvements

A good penetration test is only as valuable as the report that follows. Without clear documentation, actionable insights, and proper context, even the most advanced testing can fail to drive meaningful change.

That’s why at Rootshell, we take a better approach. Instead of delivering a static report, we provide results through the interactive Rootshell platform. This cloud-based platform gives clients real-time access to findings, threat prioritisation, and remediation guidance all in one place.

At Rootshell Security, we don’t just identify risks; we help you understand and act on them. Book a demo to see how our penetration testing services and Platform can help transform the way you manage and remediate vulnerabilities.

Frequently Asked Questions

What does a penetration testing report include?

A penetration testing report typically includes the executive summary, objectives and scope, methodology, detailed findings and risk ratings, screenshots or proof of concept, remediation advice, post-engagement summary, and optional appendices.

A vulnerability assessment report identifies known weaknesses, often via automated scans, while a penetration test report simulates real-world attacks, providing actionable insights and demonstrating the potential impact of vulnerabilities.

A good pentest report balances technical depth with clarity. It should provide context, explain the potential impact of vulnerabilities, recommend remediation steps, and be accessible to both technical teams and executives.

The length varies depending on the scope of testing, but most reports range from 15 to 50 pages. Appendices with detailed scans or technical data can be included separately to keep the main report concise.

It is recommended to conduct penetration tests at least annually, or whenever significant changes are made to IT systems, applications, or network infrastructure.

A pentest report is intended for executives, IT and security teams, and compliance or audit departments. It should communicate technical findings in a way that is understandable and actionable for all stakeholders.

Picture of Shaun Peapell
Shaun Peapell
Shaun Peapell is the Vice President of Global Threat Services at Rootshell Security, leading efforts in penetration testing and threat intelligence. He is actively involved in industry discussions on continuous testing methodologies.​

Other posts you might like