.svg)
The deliverable from a pentest engagement is the report. Everything before the report — scoping calls, testing windows, status updates — is process. Everything after the report — remediation work, retest coordination, audit submission — depends on what the report actually contains.
If you are paying $3,000 for a manual pentest, you should know what that money is buying. This piece walks through the structure of a real pentest report, what each section should contain, and the red flags that signal the report is not what you paid for.
The cover and confidentiality markings
The cover page seems trivial but it sets the tone. A real pentest report has:
The client’s name and the engagement scope identifier (e.g., “External Network Penetration Test — Q2 2026”). The testing firm’s name, with the lead operator named on the cover or the inside leaf. Engagement dates — both the testing window and the report delivery date. A confidentiality marking (typically “Confidential — Restricted Distribution”) and a document control reference.
Reports without confidentiality markings, version numbers, or operator names tend to be lower-touch deliverables — usually scanner output dressed up. Auditors notice; clients should too.
The executive summary
The executive summary is one to two pages. It is the section a CFO, audit committee, or non-technical board member will read. The job of the summary is to convey three things in plain language:
What was tested, in terms that match how your business describes the system. If the test covered the production application, the summary should name that application, not just say “the customer’s web environment.”
What the overall security posture looks like. A real pentest report leads with this. “The application demonstrates strong defensive controls. Two findings rated high require remediation before production deployment, and four findings rated medium are recommended for improvement during the next development cycle.” Compare to a weak summary that just lists CVSS counts: “14 vulnerabilities identified including 2 high, 7 medium, and 5 low.” The first tells you something useful; the second is bookkeeping.
What the highest-impact findings are, in business terms. Each top finding gets one sentence. “An authentication bypass on the password reset endpoint allows an unauthenticated attacker to take over any user account, including administrator accounts.” That sentence belongs in the executive summary. The technical detail — the HTTP requests, the parameter manipulation, the proof-of-concept payload — belongs in the findings section.
Red flag: an executive summary that reads as identical paragraphs across multiple reports. Auditors review enough pentest reports that template summaries are obvious. Your pentest vendor should be writing the summary fresh each engagement, not pulling from a copy library.
The scope and methodology section
This section is where the report establishes credibility. It should include:
The exact scope of testing — URLs, IP ranges, application versions, user roles tested, environment (production, staging, or development). Vague scope statements (“tested the customer’s web application”) are not acceptable.
The methodology used, with reference to recognized standards. Most reputable pentests reference PTES, OWASP Testing Guide, NIST SP 800-115, or OSSTMM. The reference should be specific (“PTES with OWASP Testing Guide v4.2 for application-layer testing”) rather than vague (“industry-standard testing techniques”).
The testing constraints — what was out of scope, what testing windows were used, what techniques were excluded. A pentest where DDoS testing was excluded by client request should say so, so a future reviewer understands why those findings are absent.
The names and certifications of the operators who performed the testing. PCI DSS specifically requires this for compliance pentests. SOC 2 auditors prefer it. Look for OSCP, OSCE, GPEN, GWAPT, or equivalent certifications named explicitly.
The findings section
This is the body of the report. Each finding should include:
Title and severity. A clear, descriptive title (“Authentication Bypass via Password Reset Token Reuse”), a CVSS score with version (CVSS v3.1: 8.6 High), and a one-line risk statement.
Affected components. The specific URL, endpoint, IP, hostname, or application component affected. Not “the application” — the specific component.
Description. A few paragraphs describing the vulnerability, the exploitation conditions, and the business impact. The business impact section is what most low-quality reports skip.
Proof of concept. Step-by-step reproduction. Screenshots where appropriate. The exact HTTP request and response, the exact command and output. A reader should be able to verify the finding from the proof of concept alone.
Remediation guidance. Specific, actionable steps. Not “apply security patches and follow defense in depth principles.” Specific remediation looks like: “Implement single-use password reset tokens with a 15-minute expiration. Tokens should be invalidated after first use and after a successful password change. Verify implementation by attempting to reuse a token after a password change.”
References. Links to OWASP, CWE, MITRE ATT&CK, vendor advisories, or other authoritative sources. References ground the finding in established security knowledge.
Red flag: findings that read identically across multiple reports. CVSS scores without specific exploitation details. Generic remediation language. These signal scanner output that has been lightly edited rather than manually-validated findings.
The compliance mapping appendix
If you are pursuing SOC 2, HIPAA, PCI DSS, ISO 27001, NIST 800-53, or any other framework, a good pentest report includes an appendix or column that maps each finding to the relevant framework controls. SOC 2 maps to Trust Service Criteria common criteria. PCI DSS maps to specific requirement numbers. HIPAA maps to Security Rule technical safeguards.
Without this mapping, your auditor has to do the work themselves — or push back to you for a rewritten report. Both outcomes cost time. The mapping should be there from the start.
Red flag: a report that calls itself “SOC 2 ready” or “PCI compliant” but does not actually map findings to specific controls. The label without the mapping is marketing.
The remediation summary and retest path
The closing section of the report should summarize:
The total findings count by severity. The percentage of findings the client should prioritize for immediate remediation. The expected timeline for remediation based on finding complexity. The path to retest — when, what scope, what evidence the retest will produce.
For SOC 2 Type II in particular, the retest is part of the audit evidence package. A pentest report without a clear retest path leaves an evidence gap.
What you should not see in a real pentest report
Three patterns that signal a low-quality report:
Findings that are pure CVE lookups without exploitation context. “CVE-2021-44228 detected on host 10.0.1.5.” That is scanner output. A pentest finding should describe the actual exploitation attempt, the result, and the business impact in your specific environment.
Generic remediation language across multiple findings. “Apply security best practices” on five different findings means the report was generated rather than written. Each finding should have remediation specific to that finding.
No proof of concept. A finding that says “authentication bypass possible” without showing the request that triggered the bypass is not a verified finding. It is a guess. Your auditor will treat it as a guess.
What to do when the report is bad
If you receive a pentest report that has these problems, push back to the vendor before paying. A reputable vendor will rewrite the report to add specificity, fix the executive summary, add the compliance mapping, and provide proper proof of concept. A vendor that cannot or will not do this is selling commodity scanner output, and you should not use the report as audit evidence.
The pentest you paid for is the report. If the report does not meet quality standards, the engagement was not what you paid for, regardless of how thorough the actual testing was.
If you want to see what a quality pentest report looks like before you commission one, our sample report is available on request. The format we use for SOC 2, HIPAA, PCI DSS, ISO 27001, and NIST mapping is what the auditors who review our clients’ reports have asked us to deliver. If your current pentest vendor produces something different, that is a signal worth weighing.