How to Write a Penetration Test Report

Why Most Penetration Test Reports Fall Short

In my experience of working with many different consultants across a wide range of engagements, I’ve seen my fair share of both good and bad pentest reports. A few former colleagues would somewhat jokingly say that if they could get a report through my QA process without much feedback, it would make their week.

Whilst I’ve certainly been known to be a stickler for quality, most reports I’ve reviewed had some common issues that could be easily addressed with a bit more attention to what they’re trying to communicate and who they’re trying to communicate it to.

Some of the most common issues I’ve seen have been:

Generic, copy-pasted findings: Many reports include findings that are lifted directly from vulnerability databases or standard templates, without tailoring the description, risk assessment, or remediation guidance to the specific context of the client’s environment. This can make it difficult for clients to understand the real-world implications of the finding and how to fix it.

Poorly grouped findings: Findings are often presented in a long list without any logical grouping or prioritisation. An example of this would be where a chained attack path is reported as multiple separate findings, but from a reporting perspective the client would be better served by seeing the attack path as a single finding with multiple steps, rather than a list of individual vulnerabilities.

Mixed tense and perspective: Some reports switch between past and present tense, or between first and third person, which can be confusing for readers.

Improper grammar and spelling: Simple grammar and spelling mistakes can undermine the professionalism of a report and make it harder to read. When clients may have English as a second language, correct grammar becomes even more important.

It’s no secret that the majority of penetration testers come from a technical background, and many have limited experience writing prose. It’s a skill, like anything, that takes time to develop. However, the people on the receiving end who read penetration test reports are often not technical experts. They may be security managers, IT directors, or even C-level executives who need to understand the business risk without wading through technical jargon.

Report Structure

Cover Page

Established consultancies will have a standard cover page in their branding and style format. If you’re writing your own reports, a simple cover page with the following information is a good starting point:

• Client name and logo
• Your company name and logo
• Engagement type (e.g. Web Application Penetration Test , Network Penetration Test, etc.)
• Report date (and version if applicable)
• Classification (e.g. Confidential, Internal Use Only, etc.)
• Report author(s) and any testers involved in the engagement, along with their relevant certifications or qualifications

Some of this information may be included in a separate report section before the executive summary. How a report is structured can vary, but the key is to ensure that the basic information about the engagement and the report is clearly presented at the beginning.

Executive Summary

The most important part of the report is by far the executive summary. This will generally be the only section that non-technical stakeholders will read and, in my experience of reviewing peer reports, is generally the area where consultants struggle to write to the right audience.

An executive summary should really be no more than one page (two at most). It must be readable by someone with no technical background, who doesn’t need to know what a protocol, port, or a URL is. The aim of this section is to translate the technical findings into your understanding of the business risk, highlight areas where the business should focus remediation efforts on, and summarise the overall security posture of the environment that you observed during testing.

Some of the key elements to include in an executive summary are:

1. The purpose and scope of the engagement
2. An overall assessment of the security posture (e.g. “The [environment] was found to have a number of critical vulnerabilities that could be exploited by unauthenticated internet-based attackers…”)
3. A very high level summary of the most critical findings, which indicate what impact they could have if exploited (e.g. “A critical vulnerability was found in the customer-facing web application that could allow an attacker to steal sensitive customer data.”)
4. A summary of the overall risk level (e.g. “Based on the findings, the overall risk level for [business name] is considered high, and immediate remediation of [critical asset or vulnerability] is recommended.”)
5. Any recommendations for next steps, such as prioritising remediation of critical vulnerabilities, implementing additional security controls, or conducting further testing.

Pentest reports are often focused on the negative, and all clients will usually see is a long list of vulnerabilities and issues. However, it’s also important to highlight what worked well during testing, such as effective security controls that were in place, or areas where the client’s security posture was strong.

This can help provide a more balanced view of the overall security posture and also give credit and recognition to the client’s efforts in securing their environment. It can also help build a positive relationship with the client and encourage them to continue investing in their security programme.

What to avoid in an executive summary:

• Technical jargon or acronyms that non-technical readers won’t understand unless further explained (e.g. “We found a critical CVSS 9.8 vulnerability in the web application that is exploitable via SQL injection .”)
• Detailed descriptions of individual findings (save that for the technical section)
• Overly optimistic language that downplays the severity of findings (e.g. “We found some issues, but overall the environment is in good shape.” when there are critical vulnerabilities present)
• Vague statements that don’t clearly communicate the risk (e.g. “There are several vulnerabilities that should be addressed.” without specifying the severity or impact)

When I approach an executive summary, I often start by writing backwards. I write the last sentence first, which is the overall risk assessment and recommendation, and then work backwards to summarise the key findings that support that conclusion. This helps me ensure that the executive summary is focused on communicating the business risk and the most important information for decision-makers.

Scope and Methodology

A pentest report should include a description of the scope of the engagement, which includes the systems, applications, or networks that were tested, and any exclusions or limitations. The rules of engagement would have been defined as part of the engagement planning phase, so including this helps set expectations for what was covered and what was not.

Depending on how a report is structured the scope section may only provide a high level overview of the systems that were tested, but will provide a full breakdown or table of the assets in an appendix section. This works well as it keeps the main report focused on the findings and risk, but still provides the technical team with the necessary information to understand the context of the findings.

The methodology section should outline the approach taken during testing, the testing phases (e.g. reconnaissance, scanning, exploitation, post-exploitation), and any specific frameworks or standards followed. This provides transparency into how the testing was conducted and can help clients understand the depth and breadth of the assessment.

Try to avoid turning the methodology section into a checklist of every single tool and technique used during testing. Instead, focus on providing a high-level overview of the approach and the key techniques that were used to identify vulnerabilities.

Findings Summary

A table, set of graphs, or charts that summarise the findings by severity, asset, or category can be helpful for providing a quick overview of the results. This section should be concise and visually clear, allowing readers to quickly grasp the distribution of findings and identify areas of concern.

Some clients may want to see a breakdown of findings by asset or category, while others may prefer a simple summary of the number of critical, high, medium, and low severity findings. The key is to present the information in a way that is easy to understand and highlights the most important issues.

Some examples of information to include here are:

• Total number of findings by severity (e.g. 3 critical, 5 high, 10 medium, 20 low)
• Breakdown of findings by asset or category (e.g. 2 critical vulnerabilities in the web application, 1 critical vulnerability in the network, etc.)
• A visual representation of the findings, such as a bar chart or pie chart, to help illustrate the distribution of findings.
• Remediation or current status of findings (e.g. 1 critical vulnerability is currently being remediated, 2 critical vulnerabilities are open and unaddressed, etc.)

Clients often screenshot the findings summary and share it with stakeholders, so it’s important to make this section visually clear and easy to understand at a glance.

Detailed Findings and Remediation Guidance

This is the main body of the report where each finding is described in detail, along with evidence, risk assessment, and specific remediation guidance. Each finding should be clearly numbered or labelled for easy reference.

For each finding, the following information should be included:

Title

A descriptive title that summarises the finding in a few words (e.g. “Critical SQL Injection Vulnerability in Customer Web Application”). A generic title like “SQL Injection Vulnerability” is poor because it doesn’t provide any context about where the vulnerability was found or why it’s important. As a technical reader, you know that SQL injection can be critical, but a non-technical reader may not understand the implications without context.

Severity Rating

The industry standard for severity ratings is the Common Vulnerability Scoring System (CVSS) , which provides a numerical score and a corresponding severity level (e.g. Informational, Low, Medium, High, Critical). The CVSS score should ideally be included with each finding, along with a brief explanation of what the score means in terms of risk.

For example, you could include a table that maps CVSS scores to severity levels:

However, it’s important to also provide a contextual risk assessment that takes into account the specific environment and asset criticality. For example, a CVSS 9.8 vulnerability on a non-critical internal system may be lower risk than a CVSS 7.5 vulnerability on a public-facing application that handles sensitive customer data.

Details, Evidence, Impact, and Reproduction Steps

At Exploitr we have a standard template for findings that includes the following sections:

• Description: A detailed description of the vulnerability, including what it is, how it was discovered, and why it matters.
• Evidence: Screenshots, logs, or other evidence that demonstrates the existence of the vulnerability and how it can be exploited.
• Impact: An explanation of the potential impact if the vulnerability were to be exploited (e.g. data breach, service disruption, etc.)
• Reproduction Steps: A step-by-step guide on how to reproduce the vulnerability, including any necessary commands, payloads, or configurations.

One of the most common issues I’ve seen in reports is that the reproduction steps are either missing, incomplete, or not clear enough for the client to follow. This can lead to confusion and make it harder for the technical team to understand how to fix the issue.

When I’ve reviewed pentest reports from other consultants when performing a retest, I’ve often come across findings where the reproduction steps are not clear enough to follow, or where the evidence provided doesn’t clearly demonstrate the vulnerability. This made it more difficult to understand how the original issue was identified, and also made it harder to verify that the vulnerability had been effectively remediated during the retest.

Remediation Guidance

Arguably the most important part of a finding is the remediation guidance. This is what the technical teams will rely on to understand how to fix the issue, and they’re basing their actions on the information that’s provided here.

If the remediation guidance is generic, vague, or doesn’t provide enough context, it can mean that the people that are responsible for remediating the issues may not be able to effectively fix the vulnerability, or even make it worse by applying an incorrect fix.

Effective remediation guidance should be specific and tailored to the client’s environment. Guidance on resolving an input validation issue in a web application should include specific recommendations for how to implement proper input validation, such as using parameterised queries, implementing a mitigating control like a web application firewall (WAF), or applying specific patches or updates to the affected software.

References and Further Reading

Where applicable, providing references to relevant documentation, best practices, or external resources can help the technical team understand the finding in more depth and easy access to information that can assist with remediation. This could include links to CVE entries, vendor advisories, OWASP guidelines, or other reputable sources of information.

Many consultancies will provide their own guidance on remediation, but it’s also helpful to include references to external industry-standard resources that the client can refer to for additional information.

Practical Tips for Writing Effective Penetration Test Reports

Write as you test: Don’t wait until the end of the engagement to start writing the report. Write your findings as you discover them (locally or in a reporting platform), and keep notes on the evidence, impact, and remediation guidance for each finding. This will make it easier to compile the report at the end and ensure that you don’t forget important details.

Write for your audience: Always keep in mind who will be reading the report and tailor your language and explanations accordingly. If your client is a small business with a technical founder, they may be able to understand more technical language than a large enterprise with non-technical leadership. However, it’s always better to err on the side of clarity and simplicity, especially in the executive summary.

Handle the report as a deliverable, not just a formality: The report is the main way that you communicate your findings and the value of your work to the client. Treat it as a key deliverable that requires attention to detail, clarity, and professionalism.

Use a consistent format and style: Whether you’re using a standard template or writing your own report, make sure to maintain a consistent format and style throughout the document. This includes things like headings, fonts, spacing, and how you present findings.

Proofread and edit: Always take the time to proofread your report for grammar, spelling, and clarity. Consider having a colleague review the report before you send it to the client to highlight any technical or grammatical mistakes.

Highlight that the report is a snapshot in time: It’s important to communicate to clients that a penetration test report reflects the findings at the time of testing, and that new vulnerabilities may have emerged since then. Encourage clients to view the report as part of an ongoing security programme rather than a one-time assessment.

Final Thoughts on Writing Penetration Test Reports

A penetration test report is a professional deliverable, and not just a CSV export of vulnerabilities and findings. The goal isn’t to purely document every little detail, it’s to transfer and communicate the findings, the risk, and the remediation steps from your perspective to the client’s.

Testers and consultants that can write a great report are the ones that can effectively communicate their testing output in an understandable way. A technically accurate report that is poorly written may not be as effective in helping the client understand their risks and how to fix them, which ultimately reduces the value of the penetration test.