The penetration test report, explained (with example findings)

A penetration test report is the deliverable from an authorized, simulated attack against a defined slice of your environment — typically the web application, its APIs, and the supporting cloud infrastructure. The standard anatomy: an executive summary readable by non-engineers; the scope and rules of engagement (what was tested, from what access level, during what window); the methodology the testers followed; the findings, each with a severity rating, reproduction steps, and supporting evidence; remediation guidance per finding; and appendices covering tooling and test notes.

Severity is the load-bearing part. Most firms rate findings critical, high, medium, low, or informational — often anchored to CVSS scoring — and the executive summary rolls that into the one line everyone quotes: how many findings, at which severities, and whether anything critical was actually exploitable. A good report also separates exploited from theoretical; “we retrieved another tenant’s data” and “a security header is missing” should never carry the same tone.

Buyer security teams read your pen test as a proxy for engineering culture, and they check four things fast: recency (a test within the last twelve months), scope (does it cover the product they’re buying — a test of the marketing site proves nothing), the independence and qualifications of the testing team, and the remediation story. Counterintuitively, a report with several findings fixed and retested reads stronger than a spotless one — it shows the test had teeth and your team closes loops. The same logic drives security reviews during due diligence.

SOC 2 auditors read it differently. No trust services criterion requires a penetration test, but it has become the standard evidence for the vulnerability-management and monitoring criteria, so auditors expect one: dated inside the observation period, scoped to the audited system, with findings triaged into your tracker and remediation tied to tickets. To an auditor, the report alone isn’t the control — the report plus your documented response is.

Treat the full report as sensitive: it’s a curated map of where your defenses bent, complete with reproduction steps. What you share externally is the attestation letter (sometimes called a summary letter) — one to two pages from the testing firm confirming that a test was performed, its scope and dates, the methodology, and a summary of results and remediation status, with no exploit detail. That’s the artifact for trust centers, security questionnaires, and the default answer to “can we see your pen test?”

Some enterprise buyers and regulators will insist on more, and the usual ladder holds: attestation letter first, then a redacted or summary version of the report, then the full report under NDA — ideally reviewed in a meeting rather than emailed into someone’s inbox forever. Retesting produces its own closing artifact: once you remediate, the firm verifies the fixes and issues an updated report with per-finding statuses or a standalone retest letter. A report with several highs plus a retest letter showing them closed is a stronger package than a clean report nobody probed hard for.

Agency delivers penetration testing inside its compliance programs rather than as a bolt-on purchase: scoped to what your audit and your buyers will actually scrutinize, timed to land within your observation period, and debriefed by the same engineers who run your program. Findings flow straight into the remediation and evidence workflow, so the report, the tickets, and the retest letter reach your auditor as one coherent story instead of three disconnected PDFs. The mechanics are on the pen testing for compliance page, and startup program packages include a penetration test.

If SOC 2 is what’s driving the request, the framework overview shows where the pen test sits among the rest of the evidence your auditor will ask for.