A good pentest report includes an executive summary, detailed findings with proof of concept screenshots, CVSS or OWASP risk ratings, step by step reproduction instructions, actionable remediation guidance, and compliance mapping to frameworks like SOC 2 or ISO 27001. A typical single scope report runs 40 to 80 pages.
You paid for a penetration test. A week later, you get a PDF. Maybe it’s 20 pages. Maybe it’s 120. You skim the executive summary, forward it to your CTO, and file it under “compliance done.”
Six months later, an auditor asks to review the report. They flip through it and say: “This is a scanner dump. We need evidence of manual testing.”
The report you paid for just failed its one job.
A pentest is only as useful as the report it produces. The report is what your engineering team uses to fix vulnerabilities. It’s what your auditor reviews during SOC 2 or ISO 27001 assessments. It’s what your enterprise customer’s security team evaluates before signing the contract. If the report is weak, the entire engagement was a waste.
Here is what a good report looks like, what makes a bad one, and how to tell the difference before you buy.
What You Actually Receive
A pentest report is a structured document that covers the entire engagement: what was tested, how it was tested, what was found, and what to do about it. It is not a list of CVEs exported from a scanner.
At minimum, a complete report contains these sections:
1. Executive Summary
This is the section your CEO, investor, or enterprise customer reads. It should answer three questions in plain language:
- What was tested? (scope, environment, testing window)
- What was the overall risk posture? (critical issues found or not, business impact)
- What should leadership do next? (prioritize fixes, schedule retest, address systemic patterns)
A good executive summary is 2 to 3 pages. It uses business language, not CVE numbers. It tells a story: here’s where you stand, here’s what matters most, here’s the path forward.
A bad executive summary is a paragraph that says “we found 3 critical, 7 high, 12 medium, and 18 low findings” with no context about what any of them mean for the business.
2. Methodology
This section documents what the testers did and how. It should reference specific testing frameworks:
- OWASP Web Security Testing Guide (WSTG) v4.2
- OWASP API Security Top 10
- PTES (Penetration Testing Execution Standard)
- NIST SP 800-115
It should also list the tools used (Burp Suite Professional, Nuclei, custom scripts, Postman) and the testing approach (grey-box, black-box, or white-box).
Why this matters: auditors check methodology to verify the pentest was structured, not ad hoc. If the methodology section is vague or missing, the report loses credibility as audit evidence.
3. Findings with Proof of Concept
Each finding should be a self-contained section covering:
- Title: Clear, specific. “Broken Object-Level Authorization in /api/v2/users endpoint” not “Access Control Issue.”
- Risk rating: CVSS v3.1 score with vector string, or OWASP Risk Rating with likelihood and impact assessment.
- Description: What the vulnerability is and why it exists.
- Business impact: What an attacker could do with this. “An authenticated user can access any other user’s billing records, invoices, and payment method details by modifying the user ID parameter.”
- Proof of concept: Step-by-step reproduction with screenshots, HTTP request/response pairs, and the exact inputs used. Your engineering team should be able to reproduce the issue in 5 minutes.
- Remediation guidance: Specific, actionable fix. Not “improve input validation” but “implement server-side authorization checks on the /api/v2/users/{id} endpoint to verify that the authenticated user has permission to access the requested user record.”
- References: Links to OWASP, CWE entries, or vendor documentation.
4. Risk Ratings
Findings should use a recognized framework for severity:
- CVSS v3.1 is the most common. It produces a numeric score (0 to 10) and a severity label (None, Low, Medium, High, Critical).
- OWASP Risk Rating considers both technical severity and business impact, which gives more useful prioritization for product teams.
Good reports include both the score and the context. A CVSS 9.8 on an internal admin panel with IP restrictions is different from a CVSS 9.8 on a public-facing payment API.
5. Remediation Guidance
Every finding should include fix guidance that your engineering team can act on without guessing. This means:
- Specific code-level recommendations (not just “patch the issue”)
- Framework-specific guidance where applicable (“in Django, use
get_object_or_404with the authenticated user’s queryset”) - Configuration changes with exact settings
- References to vendor documentation
6. Compliance Mapping
If you’re pursuing SOC 2, ISO 27001, or need to demonstrate compliance with India’s DPDP Act or CERT-In guidelines (including the 6-hour incident reporting rule), the report should map each finding to the relevant control.
For example: a finding about missing encryption at rest maps to ISO 27001 Annex A 8.24 (Use of cryptography) and SOC 2 CC6.1 (Logical and physical access controls). This mapping saves your compliance team hours of cross-referencing.
Good Report vs Bad Report
Here is what separates a report worth paying for from one that wastes your money:
| Dimension | Good Report | Bad Report |
|---|---|---|
| Executive summary | 2-3 pages, business language, risk narrative, prioritized recommendations | One paragraph with finding counts, no business context |
| Findings | Specific titles, detailed PoC with screenshots and HTTP requests | Generic titles (“XSS Found”), no reproduction steps |
| Risk ratings | CVSS with context, business impact explained | CVSS scores only, no explanation of real-world impact |
| Remediation | Code-level fix guidance, framework-specific recommendations | ”Apply the latest patch” or “improve input validation” |
| Business logic | Tested and documented: IDOR, BOLA, payment flow abuse, privilege escalation | Not tested, or listed as “out of scope” |
| Compliance mapping | Findings mapped to SOC 2, ISO 27001, DPDP Act controls | No mapping, left to the client to figure out |
| Methodology | Named frameworks (OWASP WSTG v4.2, PTES), tools listed, testing hours documented | ”Industry-standard tools and techniques” |
| False positives | Every finding manually verified before it reaches the report | Scanner output included without verification, so a meaningful share of findings are false positives |
| Retest evidence | Retest results included showing fixed vs still-open findings | No retest, or automated re-scan passed off as verification |
| Readability | Clean layout, consistent formatting, usable table of contents | Inconsistent formatting, scanner-generated layout, hard to read |
How to Read the Executive Summary as a Founder
You don’t need to understand every technical finding. That’s your engineering team’s job. But you need to understand the executive summary because it tells you three things:
1. Are there critical issues that need immediate attention?
Look for findings rated Critical or High that affect production systems. If the report says “unauthenticated access to customer data is possible through the public API,” that’s a board-level issue, not a backlog item.
2. Are there systemic patterns?
If five different endpoints all have the same authorization flaw, that’s not five bugs. That’s a missing security control in your architecture. The executive summary should call this out as a pattern, not just list individual findings.
3. What should you do next?
A good executive summary ends with prioritized recommendations. Fix the critical items this week. Address the highs this sprint. Schedule the mediums for next quarter. Accept or mitigate the lows based on risk appetite.
What Auditors and Investors Expect
If you’re going through SOC 2, ISO 27001, or investor due diligence, here’s what the people reviewing your pentest report look for:
SOC 2 auditors check that:
- The pentest was conducted by an independent third party (not your internal team)
- The scope covers the systems in your SOC 2 boundary
- Findings are risk-rated using a recognized framework
- Remediation status is documented (fixed, accepted, in progress)
- The methodology references a recognized standard
ISO 27001 auditors verify:
- The pentest satisfies control A.8.8 (Management of technical vulnerabilities)
- The scope aligns with your ISMS boundary
- Risk treatment decisions are documented and justified
- Retesting evidence confirms remediation effectiveness
Investors look for:
- Whether the pentest was done at all (many startups skip it)
- The overall severity distribution (lots of criticals is a red flag)
- Whether the company acted on findings (fixed vs ignored)
- Evidence of ongoing security testing, not just a one-time check
The Cost of a Bad Report
A bad report doesn’t just waste the ₹40,000 to ₹80,000 you paid for the engagement (see what a pentest costs in India for how pricing maps to quality across firm tiers). It creates downstream costs:
- Failed audit evidence: Your SOC 2 auditor rejects the report, and you pay for another pentest from a firm that delivers audit-grade work.
- Missed vulnerabilities: The scanner found the outdated jQuery version but missed the IDOR that exposes customer data. You learn about it from a researcher or a breach, not from the report.
- Wasted engineering time: Your team spends days triaging scanner findings, half of which are false positives. The real issues aren’t even in the report.
- Lost enterprise deals: Your prospect’s security team reviews the report, sees it’s a scanner dump, and asks for a “real pentest.” You’ve delayed the deal by a month.
How to Evaluate Report Quality Before You Buy
Before you sign a pentest engagement, ask for a sample report. Any firm confident in their deliverables will share one. Ours is published in full: read our redacted penetration testing report example and compare it against whatever your shortlisted vendor sends you.
When you review the sample, check:
- Is the executive summary written for a non-technical reader? Or is it just a chart of CVSS scores?
- Do findings include step-by-step reproduction? Can you follow the PoC without being a security engineer?
- Is remediation guidance specific? Or is it generic advice that could apply to any application?
- Is there compliance mapping? Do findings reference SOC 2, ISO 27001, or other frameworks?
- Are business logic findings included? Or is every finding a scanner-detectable issue like missing headers and outdated TLS?
If the firm won’t share a sample report, that tells you everything you need to know about the quality of their deliverables.
What Our Reports Include
Every pentest engagement at Cybersecify, whether it’s the Startup plan at ₹74,999 or the Growth plan at ₹1,79,999, includes a report with:
- Executive summary written for founders, investors, and enterprise buyers
- Findings with full proof-of-concept evidence and step-by-step reproduction
- CVSS v3.1 risk ratings with business impact context
- Remediation guidance specific to your tech stack
- Compliance mapping to SOC 2, ISO 27001, and DPDP Act controls
- Retest results after your team remediates (included at no extra cost)
The Growth plan also includes SOC 2 + ISO 27001 audit prep evidence, formatted specifically for auditor review.
Not sure what plan fits? Read our guide on how to evaluate a pentesting firm or see how manual testing compares to automated scanning. You can also book a free 30-min discovery call with the founders to scope the right engagement.
For scope-specific details, see our web application pentest service page.
Corrections
- 2026-08-09: Removed the “30-60% false positives” and “under 5% false positive rate” figures from the report comparison table. Neither had a published source. The distinction the row makes, between manually verified findings and unverified scanner output, is unchanged.