Compliance Artifacts

The penetration test report, explained (with example findings)

A penetration test report documents an authorized simulated attack on your systems: scope, methodology, findings ranked by severity, remediation guidance, and — after fixes — retest results. Buyers and auditors read it differently, and you almost never share the full report externally. Here’s what’s inside, what reviewers check, and what to send instead.

Talk to a Compliance Engineer

Last updated July 26, 2026

What’s inside a penetration test report

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.

What buyers and SOC 2 auditors actually look for

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.

What findings look like on the page

Example findings excerpt (condensed from a web application test)

PT-01 · High · Remediated and retested. Broken object-level authorization on a reporting endpoint: an authenticated user could read another tenant’s report metadata by iterating record identifiers. Remediation: per-object authorization checks enforced at the API layer; fix verified in retest.

PT-02 · Medium · Remediated and retested. Sessions remained valid after password reset, leaving stolen sessions usable after account recovery. Remediation: all active sessions invalidated on any credential change; verified in retest.

PT-03 · Low · Risk accepted. Verbose error responses disclosed framework version details on a non-production endpoint. Compensating factors documented; acceptance approved by the security owner with a revisit date next test cycle.

In the full report, each finding carries reproduction steps, request and response evidence, and a severity justification — the excerpt above shows only the summary rows a reviewer skims first.

The full report vs the attestation letter

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.

From delivered report to closed findings

The report’s delivery is the start of the artifact’s life, not the end.

Debrief while the testers are still engaged

Walk every finding with the firm in the readout call: confirm severity reasoning, real-world exploitability, and what a complete fix looks like. Clarifications are free this week and expensive in three months.
Triage findings into your tracker

One ticket per finding with severity, an owner, and a due date that matches your vulnerability-management commitments — that mapping is exactly what a SOC 2 auditor will sample.
Fix criticals and highs first; mitigate where fixes lag

Ship real remediation for the top severities. Where a fix requires an architecture change, document the interim mitigation and the date it retires.
Document any risk acceptances

For low-severity items you won’t fix, record the rationale, compensating controls, the approver, and a revisit date. An owned acceptance reads fine; a silently open finding doesn’t.
Schedule the retest and collect the closing artifacts

Have the firm verify the fixes, then gather the updated report or retest letter plus the attestation letter for external sharing.
File the package where it gets reused

Report, tickets, retest letter, attestation letter — one bundle that answers the auditor’s evidence request and the next three security questionnaires.

How Agency handles penetration testing

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.

Frequently asked questions

Should we share the full pen test report with customers?

Rarely. Default to the attestation letter, which confirms the test, scope, dates, and remediation summary without shipping reproduction steps. Reserve the full report for enterprise deals or regulators that genuinely require it, under NDA — with a redacted version as the middle step.

How recent does a pen test need to be?

Twelve months is the working convention for buyers and auditors alike, with a fresh test after major architecture changes. For a SOC 2 Type II the date matters twice: reviewers want it recent, and your auditor wants it inside the observation period.

Does SOC 2 require a penetration test?

No criterion requires one outright — penetration testing appears in the points of focus as example evidence, not as a mandate. The criteria require vulnerability management and monitoring, and a pen test is what auditors have standardized on. Plan for one per audit period; the alternative is debating equivalence with your auditor and your buyers at the same time.

What if the test finds critical issues right before an audit or a deal?

Fix, retest, disclose — in that order. A critical finding remediated quickly, verified in a retest letter, and disclosed with dates is a survivable story in both audits and sales. An aging critical, or one a buyer discovers you sat on, is not. Speed of response is the real signal reviewers take away.

What does a retest actually produce?

Independent verification that your fixes hold, delivered as an updated report with per-finding statuses or a standalone retest letter. It’s the closing artifact reviewers look for — findings without a retest read as open, whatever your internal tickets say.

Keep going

ISO 27001 Framework Questionnaire Fatigue Trust & Transparency SOC 2 in Due Diligence

Get the pen test your audit actually needs

Scoped, delivered, remediated, and retested inside your compliance program — with the attestation letter ready for buyers. Top-ranked Vanta & Drata partner · 1,000+ companies served since 2021 · 4.9/5 on G2.