The must-haves and nice-to-haves from a professional penetration testing report
What is a penetration testing report?
A penetration testing report is the final stage of a pentest, created by the team at the end of the security assessment. The document includes a high-level executive summary of the impact of the issues, all relevant details discussing the process, tools, and techniques used during the evaluation, the technical details and root causes of each security issue, and suggestions for vulnerability remediation and risk mitigation.
The report is often helpful in obtaining certifications such as ISO 27001 or SOC 2. It may also serve as proof of the robust cybersecurity measures of an organization to be shown to clients, vendors, or potential partners. Before deciding on a penetration testing provider, it is worth asking for a sample pentest report to see if it contains all the necessary components.
Below we’ll discuss the anatomy of a pentest report focusing on the elements most advantageous from a client’s point of view.
Ideal penetration testing report structure (and contents)
Introduction, Scope, Engagement Summary
The introductory sections should summarize the engagement. In a professional penetration testing report, the following items are usually present:
- Objectives of the project, approach, and type of assessment (ex: gray-box mobile app pentest)
- A document distribution list and version control (changelog)
- The names of the security engineers who performed the pentest
- A clear outline of the project scope
- Duration of the engagement, including starting and finishing dates
The pentest methodology used
The section on methodology should explain the pentesting process, from application and functionality mapping to exploitation and reporting. It will also mention the tools and techniques used.
Most pentests are based on industry-standard methodologies, such as OWASP Top 10, OWASP ASVS, PTES, and NIST SP 800-115; however, depending on the nature of the assessment, the methodology may have different requirements, such as IEC 62443 for operational technology cybersecurity, or Germany’s BSI for DiGA and DiPA healthcare app security testing.
This section summarizes the document for the senior management and stakeholders who don’t necessarily have the technical knowledge or time necessary to go through the whole document. It presents the main points, the most severe threats that were found, their impact, and the risk they bring to the organization.
- Vulnerable surface
- Main threats
- Vulnerabilities table with the severity of the threat
As an example of this section, below you can see what the section “Main threats” usually looks like and a table with all the vulnerabilities found during the engagement:
A section worth having to make your security team’s job easier. It brings attention to the most severe threats.
The technical summary should serve as a short storytelling section of the report where the team describes their assumptions based on threat models, test cases, and attack vectors attempted during the security assessment. It also should discuss the overall attack surface coverage, as well as which areas the system proved to be resilient against attacks and where its security fell short:
The audience for this section is the technical team, so they can be confident about the coverage and that the attack scenarios devised for the penetration testing were appropriate and matched the threat profile of the scope.
Vulnerabilities and solutions
This section is the most technical part of the report, where the exact details of each vulnerability, and their suggestions for fixing, are outlined.
Each issue typically contains the following information:
- Risk severity
- CWE and CVSS score
- The affected point (URL, parameter, which area of the API or application where the flaw was found)
- The mapping to OWASP Top 10 or equivalent
- A thorough description of the vulnerability using technical jargon
- Proof of evidence of vulnerability with screenshots of tools used, also a clear display of the before and after the exploit
- Steps to reproduce the vulnerability
- A clear explanation of the impact the issue may bring on the system
All issues found should be accompanied by a risk severity rating (preferably descriptive and following Common Vulnerability Scoring System, also known as CVSS score) and, whenever possible, also by a working exploit code. Apart from CVSS, which can sometimes be too rigid and not always take into consideration risk-based nuances and context, the vulnerability’s severity classification criteria should also be based on its potential to provide means for fraud, data leakage, and other harmful events that may have a direct adverse impact on the business.
Below there is a clear example of this section:
This part of a pentest report should also include suggested solutions to each vulnerability. After all, it is the whole point of the assessment – to find and fix vulnerabilities.
Organizations undergoing a pentest often want to know not only their vulnerabilities but also the areas and types of attacks to which they were resilient. It is, therefore, beneficial for this section of a report to include information that offers insight into your existing resilience.
The recommendations section should name steps a company should take next to further enhance its security posture, such as:
- Regular penetration testing
- Increase in secure development practices
- Team education
Ideally, the section will also include vulnerabilities listed in the order in which they should be fixed. Such prioritization of fixes enables the technical team to make faster decisions regarding remediation, especially if there are many critical vulnerabilities.
Other post-pentesting documents
Penetration testing attestation letter
This type of document is also something that a pentest provider should issue next to the pentesting report. It may be presented to shareholders, clients, or prospective partners as a confirmation of a robust security posture – proof that a company took steps to fix the issues or that there are no critical vulnerabilities that could immediately jeopardize the organization’s security.
What does an attestation letter look like? We have published a sample cybersecurity attestation letter so customers can get an understanding of what to expect from such documents.
Bonus: What does a penetration testing report look like in real life?
For those wanting to see some authentic penetration testing documentation, Public Pentesting Reports on Github is the first-ever curated repository of hundreds of public penetration testing reports published by major cybersecurity firms, including some of our own reports.
The repository, incidentally created by Blaze’s managing partner Julio Fort, served as a source in constructing our own pentesting report model. We have carefully studied reports from dozens of companies and created a unique document structure that allows our clients to get the most out of this final stage of penetration testing. We aim for our documentation to be as practical as possible; that’s why our reports include, for example, a technical summary for the technical team next to a standard executive summary and recommendations on the prioritization of fixes.
If you are curious to see what Blaze’s latest penetration testing report model looks like, we have published sample reports for web application and mobile pentesting, so customers know exactly what to expect from our deliverables for such services.
To get the most out of your pentest, choose the penetration testing provider that offers good quality, easy-to-navigate, practical documentation loaded with actionable advice.
Check if their reports contain both executive and technical summaries and offer insights into the severity of threats, but also into the areas that proved robust against attacks. Finally, make sure the pentest provider suggests solutions to the issues discovered, offers insights into which fixes should be prioritized, and provides recommendations to further strengthen your company’s security posture.