The testing is over, and a 60-page PDF lands in your inbox. Engineering wants the list of things to fix. Your SOC 2 auditor wants to know if the test counts as evidence, and a big customer you’re trying to close just wants proof you had a test done. That customer shouldn’t see the details of what’s broken. Three readers, one report. This guide walks through a typical penetration test report section by section: what each part says, who it’s written for, and what an auditor checks before accepting it.
Quick Answers
What’s in a penetration test report?
Two reports bound together. An executive summary explains the scope, the method, who did the testing, and the overall risk in plain language. The technical findings give engineers one detailed entry per security issue, with evidence and a fix.
Which part does the auditor read?
The executive half first, since scope, dates, method, and the retest results decide whether the test counts. Auditors then sample individual findings to confirm the fixes happened.
What can be shared with customers?
A letter of attestation: a one- or two-page summary signed by the testing firm, with no vulnerability details. The full report stays inside the company.
Two Reports in One File
Most reports are labeled as one document but read like two. The front section is written for leadership, the board, and the auditor. Everything behind it is written for the engineers who will do the fixing, and it carries enough detail to reproduce each attack. That second half is sensitive. Some firms deliver it as a separate appendix for that reason, and it’s the part you never attach to a sales email.
Larger engagements often split again by asset. A test that covers your customer-facing web app, the internal office network, and an AWS account may come back as three reports, or as one report with a section for each. The split pays off later. A SaaS buyer only cares about the web app, while an ISO 27001 auditor may want all three, and separate reports let you hand each reader only what applies to them.
The Letter of Attestation
Think of the letter as a trimmed copy of the executive summary with the findings removed. It names the testing firm and the testers, states the test dates and what was in scope, names the method, and usually shows a count of issues by severity. A signature from the firm closes it.
Prospects ask for it during vendor review, and some auditors request it before the full report. One timing detail trips companies up: a letter issued right after testing shows every open critical. Ask for an updated letter after the retest, so the prospect sees the fixed state. CYBRI’s guide to letters of attestation covers the format in more depth.
The Executive Summary, Part by Part
Who tested, and for which framework
Near the front, a good report names the people who did the work, their roles, and their certifications (OSCP, a hands-on hacking exam, is the one buyers see most often). Auditors look at this page for two reasons. Qualified testers make the results believable, and independence matters: PCI DSS, the card-payment security standard, requires a tester who is organizationally independent from the people who run the environment, and many SOC 2 auditors look for the same separation.
The summary itself states who ran the test, for whom, when, and why. It should also say which compliance expectations the test supports. This is the compliance mapping, and it saves your auditor an afternoon. A SOC 2 audit reads pentest results as monitoring evidence under criterion CC4.1. ISO 27001 auditors file them under the vulnerability management and security testing controls (A.8.8 and A.8.29). PCI DSS covers penetration testing in Requirement 11.4. HIPAA doesn’t name pentesting, but healthcare companies use it toward the Security Rule’s periodic evaluation requirement, and an ISO 42001 test maps findings to the AI control areas in Annex A.
The risk summary
Board members tend to read this paragraph and stop. It gives a single overall rating for each tested system after testing, a one-line verdict on its security posture, usually backed by a count of findings at each severity level. If the rating says “High,” the next question in the room will be what it takes to bring it down, so the recommendations section should answer that.
Scope and coverage
The scope section lists exactly what was tested: domains, IP ranges, apps, APIs, cloud accounts, and the user roles the testers logged in as. It also lists what was left out, the dates, and whether the work ran against production or a staging copy. A statement that the testing was authorized, and what the testers were allowed to do, belongs here too. Written permission is the legal line between a penetration test and a break-in.
Auditors spend more time on this page than on any finding. They hold it up against the scope of your audit (the system description in SOC 2, the certificate scope in ISO 27001). A clean test of the marketing site says nothing about the product an enterprise customer logs into. For a SOC 2 Type 2 audit, auditors also expect the test dates to fall inside the observation period (the months the audit covers).
Methodology
This section names the public testing standard the work followed. For web applications that’s usually the OWASP Web Security Testing Guide, a free, community-maintained guide to how web apps get attacked, often alongside NIST SP 800-115 or PTES. A test built on it typically moves through three broad phases: getting oriented (mapping the app, its roles, and where it accepts input), testing, and then rating each risk and writing it up.
A named method shows the work is repeatable and wasn’t just someone pressing “run” on a scanner. PCI DSS goes further and requires a documented, industry-accepted methodology. A report that can’t say how the testing was done invites the question of whether it was done by hand at all, which is the gap between a manual penetration test and a scan with a cover page.
Summary of findings
Charts live here. Expect findings by severity, findings by asset, and, once the retest is done, a side-by-side of the initial test against the remediation test (the second pass where testers check your fixes). For an auditor, the before-and-after chart may be the most valuable image in the document. It shows problems were found, fixed, and verified, which is the corrective-action trail SOC 2 Type 2 and ISO 27001 auditors want to see over time. CYBRI’s SOC 2 report anatomy covers how that trail fits a Type 2 audit.
Recommendations
Individual findings each come with their own fix. The recommendations section steps back and names patterns. Four access-control findings on four different endpoints usually trace back to one missing authorization check in shared code, and fixing that check once beats closing four tickets. Good recommendations read like a short roadmap your CTO can put on the next sprint plan.
The Technical Findings, Field by Field
Each issue gets its own entry, ordered from most to least severe. The fields stay the same from finding to finding:
| Field | What it tells you |
| Severity | How serious the flaw is on a standard scale (CVSS 4.0: Critical, High, Medium, Low) |
| Risk | How much it matters in your environment, given what’s exposed and how likely an attack is |
| Asset | Which system: the web app, an API, the internal network, a cloud account |
| Host | The exact URL, IP address, or endpoint |
| Status | Open, fixed and verified, partly fixed, or accepted as a known risk |
| Details and evidence | Step-by-step reproduction, with screenshots and the actual requests and responses |
| Resolution | How to fix it in your stack |
| References | Public catalog entries: OWASP, CWE, MITRE ATT&CK |
Severity and risk look like duplicates, and they aren’t. CVSS (the Common Vulnerability Scoring System, the industry’s 0 to 10 severity scale) rates the flaw in general terms. Risk adjusts for your business. A flaw scored 9.1 on a forgotten test server with no data can rate as medium risk; a 6.5 that exposes every customer’s billing records can rate high. Engineers prioritize by risk. Auditors check that the reasoning holds.
Status is the field auditors sample. When they pick a high-severity finding from March, they expect to see “fixed,” a retest date, and evidence the fix held. Anything left open needs a documented risk acceptance: who signed off, why, and when it gets reviewed again. A finding marked “closed” with nothing behind it is one of the first things auditors question.
The references connect each finding to shared vocabularies. CWE is MITRE’s catalog of software weakness types. MITRE ATT&CK catalogs real attacker techniques and shows up mostly in internal network findings. Compliance tools and auditors use these IDs to map findings consistently across reports and years.
A typical finding, in plain terms: a customer could download another customer’s invoice by changing a number in the URL. Severity: High. Risk: High, since it exposes financial records. Asset: the customer web app. Host: the invoice download endpoint. Evidence: two test accounts, with screenshots of one pulling the other’s invoice. Resolution: check on the server that the invoice belongs to the logged-in customer. References: OWASP’s Broken Access Control category and CWE-639. Status: fixed, verified in the retest. The flaw is a classic IDOR, and it’s one of the most common findings in web app reports.
What Makes an Auditor Push Back
Most auditor pushback starts with the executive half. The usual problems:
- Test dates outside the audit period, or a report more than about 12 months old
- A scope that doesn’t match the system under audit
- Scanner output with a pentest label: no named method, no tester names, no manual evidence
- Critical or high findings with no retest and no signed risk acceptance
- A letter or cover page with no full report behind it when the auditor asks
What a CYBRI Report Includes
CYBRI reports run 30 to 100 pages depending on scope, with findings ordered by severity. Each report contains:
- An executive summary written for leadership and the auditor, with scope, method, and an overall risk rating
- Tester profiles for the senior, OSCP-certified team that ran the engagement
- Technical findings scored on CVSS 4.0, each with evidence and stack-specific fix steps
- Compliance mapping to the frameworks on your audit calendar (SOC 2, ISO 27001, PCI DSS, HIPAA)
- Same-day alerts for critical issues, before the final report
- A retest of your fixes and an updated report showing the before-and-after state
- A letter of attestation for prospects and partners
- A walkthrough call where the testers take your team through the findings
To scope a test around your next audit, contact CYBRI.
Frequently Asked Questions
Can I send the full report to a customer?
Usually not, and you shouldn’t need to. The technical findings show exactly how to attack your system. Send the letter of attestation. If a large customer insists on more, share the executive summary under NDA.
How long is a pentest report valid?
No universal expiry exists, but most auditors and enterprise buyers expect a test from the last 12 months, and PCI DSS requires testing at least once a year and after significant changes. A major release or new infrastructure is a reason to test sooner. The continuous testing guide covers cadence for SOC 2 and ISO 27001.
Does a vulnerability scan report count?
Rarely on its own. A scan lists possible issues from an automated tool. Auditors who ask for a penetration test expect named testers, a documented method, and evidence that each finding was confirmed by hand.
How long until the report arrives?
Active testing usually takes 1 to 3 weeks, with the report following shortly after and critical issues flagged the same day they’re found. The CYBRI testing timeline lays out each stage.
Get a Report Your Auditor Can Use
Bring your audit date and a rough list of systems to the first call. The scope gets drawn to match what your auditor will review, with time left to fix findings and retest before the evidence is due. Book a scoping call with CYBRI.
