What a Good Pentest Report Looks Like

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) v5.0
• 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_404 with 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, 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 v5.0, PTES), tools listed, testing hours documented	”Industry-standard tools and techniques”
False positives	Verified manually, under 5% false positive rate	Scanner output included without verification, 30-60% 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. 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. Here is ours.

When you review the sample, check:

1. Is the executive summary written for a non-technical reader? Or is it just a chart of CVSS scores?
2. Do findings include step-by-step reproduction? Can you follow the PoC without being a security engineer?
3. Is remediation guidance specific? Or is it generic advice that could apply to any application?
4. Is there compliance mapping? Do findings reference SOC 2, ISO 27001, or other frameworks?
5. 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 Cyber Secify, 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)
• Brand Protection Snapshot covering domain squatting and impersonation risks

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 start with a Security on Demand session (₹9,999, 4 hours) to assess your current security posture before committing to a full engagement.

For scope-specific details, see our web application pentest service page.