You have invested in a web application penetration test. In a week or two, you will receive a report that could be 30 to 100 pages long, filled with technical findings, severity ratings, CVSS scores, and remediation recommendations. If you have never received a pentest report before, it can be overwhelming.
This guide walks you through exactly what a quality pentest report contains, how to interpret each section, and how to use the report to actually improve your security posture rather than letting it collect dust in a shared drive.
The anatomy of a pentest report
A professional penetration test report is structured to serve multiple audiences. The executive summary is for leadership and non-technical stakeholders. The methodology section is for auditors and compliance teams. The technical findings are for your engineering team. A quality report serves all three audiences without forcing any of them to read sections that are not relevant to their needs.
Executive summary
The executive summary is typically one to three pages and provides a high-level overview of the engagement. It includes the overall risk rating, a summary of findings by severity, key observations about your security posture, and strategic recommendations. This is the section you share with your board, your investors, and enterprise customers who ask for pentest evidence.
A good executive summary does not just count vulnerabilities. It tells a story about your security posture: what is working well, what needs immediate attention, and what the findings mean for your business risk. If the executive summary reads like a list of technical findings, the report is not well written.
Scope and methodology
This section documents what was tested, how it was tested, and any limitations or constraints. It typically includes the target URLs and IP addresses, the testing dates, the user roles and access levels provided, the methodology followed (usually OWASP Testing Guide or PTES), tools used, and any areas that were excluded from scope.
Compliance auditors pay close attention to this section because it tells them whether the test was comprehensive enough to satisfy their framework's requirements. Enterprise customers look at it to confirm the test covered the features they care about.
Findings summary
Before diving into individual findings, the report provides a summary view. This typically includes a chart showing the distribution of findings by severity and a table listing all findings with their title, severity, status, and location.
| Severity | CVSS Range | What It Means | Remediation Timeline |
|---|---|---|---|
| Critical | 9.0 - 10.0 | Immediate risk of data breach or system compromise | Fix within 1-2 weeks |
| High | 7.0 - 8.9 | Significant risk that requires prompt attention | Fix within 30 days |
| Medium | 4.0 - 6.9 | Moderate risk, should be addressed in normal cycle | Fix within 90 days |
| Low | 0.1 - 3.9 | Minor risk, best practice improvement | Fix within 6 months |
| Informational | 0.0 | Observation or hardening recommendation | Address as capacity allows |
Understanding individual findings
Each finding in the report follows a consistent structure that provides everything your engineering team needs to understand, reproduce, and fix the vulnerability.
Finding title and severity
The title describes the vulnerability in clear terms: "Broken Object Level Authorization in User Profile API" or "Stored Cross-Site Scripting in Comment Field." The severity is assigned based on the CVSS score and the tester's assessment of real-world impact in the context of your application.
Description
A plain-language explanation of what the vulnerability is, why it matters, and what an attacker could do with it. This section should be understandable by someone who is not a security specialist.
Evidence and reproduction steps
This is the most important section for your engineering team. It includes the exact HTTP requests and responses that demonstrate the vulnerability, screenshots where applicable, and step-by-step instructions to reproduce the issue. Your developers should be able to follow these steps and see the vulnerability for themselves.
If a finding does not include clear reproduction steps, the report is incomplete. Your team should not have to guess how to reproduce a vulnerability.
Impact
A description of the business impact if the vulnerability were exploited. This might include data exposure scope (how many records could be accessed), financial impact (potential for fraud or unauthorized transactions), compliance implications (whether the vulnerability constitutes a compliance violation), and reputational risk.
Remediation recommendation
Specific, actionable guidance on how to fix the vulnerability. Good remediation recommendations include code-level suggestions, not just "implement proper authorization." They explain what "proper" means in the context of your application and technology stack. They also reference relevant security standards (CWE IDs, OWASP references) for additional context.
What separates a good report from a great one: A good report tells you what is wrong. A great report tells you what is wrong, shows you exactly how it works, explains why it matters to your business, and gives your developers specific guidance on how to fix it. At Lorikeet Security, our reports are written to be actionable, not just thorough.
How to use the report effectively
Triage and prioritize immediately
Do not wait to read the full report before starting remediation. Critical findings should be assigned to developers within 24 hours of delivery. High findings should be prioritized within the first week. Use the severity ratings as a starting point, but also consider your specific business context. A medium-severity finding that affects your payment processing may warrant higher priority than a high-severity finding on an internal admin page.
Schedule the debrief call
Every quality pentest includes a debrief call where the testing team walks through the findings with your technical team. Use this call to ask questions about reproduction steps, discuss remediation approaches, and understand the root causes behind findings. This call is often more valuable than the report itself.
Track remediation formally
Create tickets in your issue tracker for every finding. Link them to the pentest report. Track them through your normal sprint process. When remediation is complete, schedule the retest to verify that fixes are effective and that no new issues were introduced.
Share the right sections with the right people
Your board gets the executive summary. Your auditor gets the full report or an attestation letter. Your enterprise customers get the executive summary and a description of your remediation process. Your engineering team gets the full technical findings. Not everyone needs to see everything, and sharing the full report externally may expose more detail than necessary.
Red flags in a pentest report
Not all pentest reports indicate quality work. Watch for these warning signs.
- Generic findings with no evidence. If findings read like textbook definitions without specific evidence from your application, the tester may have relied on automated tools without manual verification.
- No reproduction steps. Every finding should include steps your team can follow to reproduce the issue. Without them, the finding is unverifiable and difficult to fix.
- Only automated scanner output. If the report reads like Burp Suite or Nessus output with a cover page, you received a vulnerability scan, not a penetration test.
- No business logic findings. If the report contains only technical vulnerabilities (XSS, SQL injection, misconfigurations) and no business logic findings, the tester likely did not spend time understanding your application's intended behavior.
- Inflated finding counts. Some firms count every instance of a vulnerability as a separate finding to make the report look more comprehensive. Twenty instances of the same missing security header is one finding, not twenty.
What Lorikeet Security reports include
Our pentest reports are designed to be actionable for your engineering team and presentable to your stakeholders. Every report includes:
- Executive summary suitable for board, investor, and customer sharing
- Detailed technical findings with full evidence and step-by-step reproduction
- Remediation guidance specific to your technology stack
- CVSS scoring with contextual severity assessment
- Compliance mapping showing which findings affect SOC 2, ISO 27001, PCI DSS, or HIPAA controls
- Strategic recommendations for improving your overall security program
Critical and high findings are delivered in real time through our PTaaS platform during the engagement. Your team does not have to wait for the final report to start fixing the most important issues.
Get a Pentest Report You Can Actually Use
Actionable findings, clear remediation guidance, real-time delivery. Web application penetration tests starting at $7,500.
