Penetration Testing Report: What It Includes and How to Read One

A penetration testing report is the primary deliverable produced after a security assessment. It documents what was tested, how the testing was performed, which vulnerabilities were identified, how those vulnerabilities could affect the organization, and what to do to remediate them.

If your pentesting report is weak, you have a lot at stake. Your organization’s security is at risk, with stalled audits, unverified fixes, and real exposures that the report has missed. A penetration testing report is not just a PDF that lists vulnerabilities; it should be much more than that.

Key Takeaways

• A strong pentest report goes beyond vulnerability lists to explain real security risks.
• It should clearly document scope, methodology, findings, severity, and business impact.
• Proof of concept and reproduction steps help teams validate and understand vulnerabilities.
• Effective reports provide specific and actionable remediation guidance.
• Risk scoring and framework mapping help teams prioritize and communicate findings.
• Retesting verifies remediation and confirms vulnerabilities are actually closed.

What is a Pentesting Report?

A pentest report shouldn't just list vulnerabilities. It should help different stakeholders answer different questions:

• Security leaders: What is our overall security risk?
• Engineers: What exactly is vulnerable and how can we reproduce it?
• Developers: What needs to be fixed?
• Management: Which issues should be prioritized?
• Auditors and customers: What was tested and what were the results?
• Security teams: Has the vulnerability actually been fixed?

The important distinction is that a pentest report should turn technical testing into actionable security intelligence.

Structure of a Good Penetration Testing Report

While report structures vary between providers, a good penetration testing report generally includes:

1. Executive summary
2. Scope and objectives
3. Testing methodology
4. Assets and technologies tested
5. Risk summary
6. Vulnerability findings
7. Proof of concept (PoC)
8. Steps to reproduce
9. Business and technical impact
10. Remediation recommendations
11. Retest status
12. Compliance and security framework mappings
13. Appendices and testing references

A good report should follow this layered approach, moving from executive-level risk analysis to detailed findings, then into methodology and scoring appendices.

Siemba's pentest report provides an example of this structure, covering web applications, mobile applications, MCP servers, chatbots/AI agents, LLMs, and APIs. The scope identifies assets, asset criticality, testing type, testing mode, user roles, and other engagement parameters.

1. Executive Summary: The Part Leadership Reads First

The executive summary translates technical penetration testing results into a high-level view of the organization's security posture.

It should answer:

• What was tested?
• Why was it tested?
• What was discovered?
• What is the overall risk?
• Which findings require immediate attention?
• What does management need to do next?

Example: Siemba's Executive-Level Finding Summary

The report breaks down vulnerabilities by asset and severity. For example, the web application contains findings across multiple severity levels, while the mobile application and API show no findings in the summarized table.

This view is useful because executives don't need to read every technical finding. They need to understand where the greatest exposure exists.

2. Scope: What Was Actually Tested?

One of the most important sections of a pentest report is the scope.

Without a clearly defined scope, readers cannot determine what the assessment actually proves.

A scope section should identify applications, APIs, domains and IP addresses, mobile applications, cloud resources, infrastructure, user roles, testing approach, testing location, black-box, gray-box, or white-box methodology, and testing limitations.

This is particularly important when a report is later shared with customers, auditors, compliance teams, procurement teams, boards, and cyber insurance providers.

A statement such as “the application was tested” is not enough.

The report should clearly state which application, interfaces, roles, and attack surface were included.

3. Penetration Testing Methodology

A professional pentest report should explain how the assessment was performed. Testing methodology includes several stages that apply across web applications, mobile apps, APIs, MCP servers, and AI agents.

1. Scope and Reconnaissance: Define objectives, assets, user roles, and identify the attack surface.
2. Attack Surface Mapping: Map application functionality, APIs, authentication, integrations, AI tools, data flows, and permissions.
3. Vulnerability Discovery: Combine automated scanning with manual testing to identify technical and business logic vulnerabilities.
4. Exploitation and Validation: Safely validate vulnerabilities to determine real-world exploitability and impact.
5. Attack-path Analysis: Identify how vulnerabilities can be chained to achieve unauthorized access, privilege escalation, or data exposure.
6. Reporting and Remediation: Document findings with evidence, reproduction steps, impact, and actionable remediation.
7. DREAD Scoring and RCA: Apply DREAD-based risk scoring and perform Root Cause Analysis (RCA) to identify the underlying weakness and prevent recurrence.

4. Risk Scoring: More Than Just a Severity Label

A strong penetration testing report should explain why a vulnerability received its severity or risk rating.

Siemba's pentesting report uses several parameters, including:

• Vulnerability criticality
• Likelihood
• Asset criticality

Siemba's asset risk calculation formula is:

Asset Risk Score = Vulnerability Criticality × Threat Probability × Asset Criticality

The report then maps the resulting score to risk levels ranging from Minimal to Critical.

Why Asset Context Matters

Imagine the same vulnerability exists in two systems:

System A: Internal development server

System B: Internet-facing production payment application

The vulnerability itself may be identical, but the organizational risk can be very different.

This is why a useful pentest report should connect:

Vulnerability → Likelihood → Asset → Business Impact

rather than simply stating: CVSS = 8.2.

5. Detailed Vulnerability Findings

The detailed findings section is where the report becomes actionable for engineering and security teams.

Each finding should ideally contain:

1. Finding title
2. Severity
3. Likelihood
4. Status
5. Affected asset
6. Vulnerability description
7. Technical explanation
8. Impact
9. Proof of concept
10. Steps to reproduce
11. Remediation solution
12. References
13. Security framework mappings
14. Retest status

The finding includes severity, likelihood, status, CVSS/DREAD fields, and mappings to OWASP, NIST, WASC, and CWE.

Explain the Vulnerability in Context

A good finding should explain what the vulnerability means, rather than simply naming it.

For example, a finding explains that missing security headers such as Content-Security-Policy and Strict-Transport-Security represent defense-in-depth weaknesses. It explains that the missing headers cannot themselves be directly exploited to compromise the application, but they can increase the impact of other vulnerabilities.

Importantly, the report does not overstate the finding. Not every security weakness should be presented as an immediately exploitable critical vulnerability.

The report should distinguish between:

• Direct vulnerabilities
• Defense-in-depth weaknesses
• Configuration issues
• Exploitable findings
• Findings that become dangerous when chained with another vulnerability

6. Proof of Concept and Steps to Reproduce

One of the most valuable components of a penetration testing report is the proof of concept (PoC).

A PoC shows the tester didn't just identify a theoretical vulnerability.

For example, the PoC mentions that the Weak JWT Signing Secret is practically exploitable.

The report should document:

1. Authenticate as a low-privileged user and capture a JWT.
2. Confirm the token uses HS256.
3. Perform an offline dictionary attack to recover the weak signing secret.
4. Modify JWT claims such as role or sub.
5. Re-sign the modified token using the recovered secret.
6. Replay the forged token against a privileged endpoint and verify unauthorized access.

This demonstrates that the weak secret can allow JWT forgery and privilege escalation, rather than merely representing a theoretical weakness. The steps instruct the tester to inspect the response headers and verify that the expected security headers are absent.

For engineering teams, this can dramatically reduce remediation time, as they receive the following information:

• Where it occurs

• How to reproduce it

• Why it matters

• What to change

Siemba is designed to fit into your existing security workflow without requiring a separate identity system. Log in through your organization’s own identity provider using Single Sign-On (SSO), giving security and engineering teams a familiar and controlled way to access the platform.

Every confirmed finding is backed by clear evidence, rather than relying on a description of what might happen. Findings can include screenshots, video proof, reproduction steps, and supporting technical details, helping your team understand exactly how the vulnerability was exploited and what was affected.

7. Remediation Guidance

A pentest report should not stop at vulnerability discovery.

The report should tell engineering teams how to fix the problem. Good remediation guidance should be specific, technically accurate, practical, relevant to the affected technology, clear about compensating controls, and finally actionable for developers.

In our example finding ‘Weak JWT Signing Secret’, remediation should address both the strength and lifecycle of the signing key. Replace the weak JWT secret with a cryptographically random, high-entropy secret of at least 32 bytes.

The secret should:

• Be generated using a secure random generator.
• Never be hardcoded or committed to source control.
• Be stored securely using a secrets-management mechanism.
• Be rotated immediately if compromise is suspected.
• Invalidate tokens signed with the compromised secret where appropriate.

For example, a secure secret can be generated using openssl rand -base64 48.

8. Security Framework Mapping

Security teams increasingly need to map penetration testing findings to recognized security and compliance frameworks. While security frameworks help identify, assess, and mitigate technical security risks, compliance frameworks define requirements organizations must meet to satisfy regulatory, contractual, or industry obligations.

A finding may be mapped to security frameworks such as OWASP, CWE, WASC, NIST, and MITRE ATT&CK, as well as compliance frameworks and standards such as PCI DSS, SOC 2, ISO 27001, GDPR, CMMC, and HIPAA.

The Weak JWT Signing Secret finding can be mapped to:

Security Frameworks

• OWASP A02:2021 – Cryptographic Failures
• WASC-14 – Server Misconfiguration
• CWE-326 – Inadequate Encryption Strength
• NIST SP 800-53 – Configuration Management (CM)
• MITRE ATT&CK – T1552.004: Private Keys, where weak or exposed signing secrets could enable credential or key compromise

Compliance Frameworks (If JWT has related data/system affected)

• PCI DSS – Requirements related to protecting authentication credentials and cryptographic keys
• SOC 2 – Controls covering logical access, authentication, and protection of sensitive information
• ISO/IEC 27001 – Controls related to cryptography, access control, and secure authentication
• HIPAA – Safeguards related to access control, authentication, and protection of electronic protected health information
• GDPR – Requirements for appropriate technical and organizational measures to protect personal data
• CMMC – Security practices covering identification, authentication, access control, and protection of controlled information (potential impact if system handles CUI - Controlled Unclassified Information)

These mappings connect the technical weakness to broader security practices and control requirements, helping security, engineering, and compliance teams understand its impact and prioritize remediation.

9. Retesting: The Step Many Pentest Reports Miss

A penetration testing report should ideally track what happens after the original test.

A finding should not simply disappear because a developer says: “Fixed.”

The security team needs evidence that the vulnerability has actually been remediated.

Siemba's report structure includes retest status alongside findings, while its broader PTaaS model tracks findings through states such as Open → Retest Ready → Remediated/Verified Closed.

This creates an important distinction: Remediation claimed is NOT the same as remediation verified.

The retest should determine whether:

• The original vulnerability is fixed
• The attack still works
• A workaround was introduced
• The fix created another vulnerability
• Compensating controls are sufficient

Siemba’s seamless integration with CI/CD, AI and LLMs, issue tracking, communication, vulnerability intel, and network access tools makes it easy and faster to retest. Connect Siemba to your existing stack. Findings, tickets, and alerts flow seamlessly across your tools, so your team can stay in sync without switching between systems.

What Should You Ask for Before Choosing a Pentesting Provider?

Before purchasing a penetration test, ask the provider for a sample report.

Look for the following answers:

1. Clear Scope: Can you tell exactly what was tested?

2. Technical Evidence: Does every meaningful finding include evidence?

3. Reproduction Steps: Can your engineers reproduce the issue?

4. Business Impact: Does the report explain why the vulnerability matters?

5. Risk Methodology: Does the provider explain how severity and risk are determined?

6. Remediation Guidance: Does the report tell your team how to fix the issue?

7. Framework Mapping: Can findings be mapped to relevant security standards?

8. Retesting: Does the provider verify that vulnerabilities have actually been fixed?

9. Human Expertise: Are findings manually validated rather than simply copied from automated scanners?

10. Actionability: Can your engineering and security teams actually use the report to reduce risk?

What Makes Siemba's Penetration Testing Reports Different?

At Siemba, the objective is not simply to generate a PDF containing vulnerabilities. Siemba's penetration testing report follows a layered approach, including scope, executive summary, risk analysis, detailed findings, remediation guidance, methodology, DREAD and CVSS criteria, and test cases.

A penetration test is only as useful as the insight your team can take from it.

Instead of relying on isolated reports or manually reviewing dashboards, security teams can use Siemba’s AISO (AI Security Officer) to connect vulnerabilities, threats, asset exposure, remediation progress, and business impact. Because AISO is embedded across Siemba's CTEM platform, its insights extend beyond vulnerability management. It connects visibility across EASM, vulnerability assessment, penetration testing, GenPT, and PTaaS, giving security teams a more unified view of their exposure.

Siemba combines expert-led penetration testing with detailed technical findings, attack evidence, remediation guidance, business risk scoring, and verified retesting. So, your team knows not only what is vulnerable, but what to fix and whether the fix worked.

That is the difference between a report that documents a security exercise and one that helps an organization reduce real security risk.

Ready to see what a professional penetration testing report looks like? Download a sample report or explore Siemba's Penetration Testing as a Service → Book a Demo.

Frequently Asked Questions

How long should a penetration testing report be?

There is no ideal page count. The report should contain enough technical evidence and context for engineers to remediate vulnerabilities while providing a concise executive view for leadership.

What is the difference between a vulnerability assessment report and a pentest report?

A vulnerability assessment report is an automated assessment of potential weaknesses. A penetration testing report documents vulnerabilities that have been investigated and, where applicable, validated through controlled exploitation and manual testing. A pentesting report mentions how vulnerabilities can be exploited and mitigated.

Why are reproduction steps important in a pentest report?

They let engineers and security teams independently verify the vulnerability, understand the attack path, and confirm that remediation addressed the underlying issue.

What is a pentest retest report?

A retest validates whether previously reported vulnerabilities have been successfully remediated. It provides evidence that a finding is actually closed rather than simply marked as fixed.

What compliance certifications and government mandates require penetration testing reports?

Several compliance standards and regulatory programs require organizations to conduct penetration testing or maintain evidence of security testing. Common examples include SOC 2, PCI DSS, HIPAA, ISO 27001, CMMC, and certain government or healthcare requirements such as CMS-related programs.

The exact requirement varies by framework, but organizations may need to provide a penetration testing report, documented findings, remediation evidence, or proof of follow-up testing during audits or assessments.