A penetration test produces one body of work and at least three audiences: the engineer who has to fix it, the executive who has to fund it, and the third party who needs proof it happened without seeing your unpatched vulnerabilities. Sending one document to all three goes wrong in both directions.
The three documents
- Technical report: every finding with a CVSS v4.0 score, evidence, reproduction steps and a specific fix. Internal only.
- Executive summary: two pages, risk in business terms, the three things that matter most. For the people approving remediation time.
- Letter of attestation: scope, dates, methodology, tester credentials and the retest outcome. This is the one that leaves your building.
Two of the three frameworks do not require a pentest at all
This surprises people who have just been told by a customer that they need one. It is worth knowing exactly what each framework says, because it changes what your report has to prove.
- PCI DSS 4.0, requirement 11.4 is the only one of the three that mandates penetration testing outright. Internal and external testing at least every twelve months and after any significant infrastructure or application change. Segmentation testing every twelve months, or every six for service providers.
- ISO 27001:2022 names it nowhere. No Annex A control names penetration testing anywhere. A test is simply the standard way to evidence A.8.8, management of technical vulnerabilities, and A.8.29, security testing in development and acceptance.
- SOC 2 is not a formal requirement either. The Trust Services Criteria do not mandate any specific technical assessment. Auditors expect a test because it is the most convincing evidence available for the vulnerability-management criteria, not because a clause demands it.
The practical consequence is that for two of the three, your report is not ticking a box with a number on it. It is being read as evidence for a control objective, which means the scope statement and the retest record do more work than the findings list.
For SOC 2 and ISO 27001, nobody is checking that you had a pentest. They are checking what it demonstrated.
What an auditor is checking
Not your finding count. They are checking that the test was independent, that its scope covered the system in question, that it happened inside the review period, that the methodology maps to something recognised, and that the issues found were fixed and verified.
- Scope: which hosts, applications and environments, named explicitly, matching the system being certified.
- Dates: when testing started and finished, inside the audit window.
- Independence: who tested, their credentials, and that they do not report to the team that built it.
- Methodology: a named standard such as PTES, OWASP WSTG or NIST SP 800-115, not “industry best practice”.
- Remediation evidence: that findings were fixed and re-verified, with the retest date.
A report with fifteen findings and a completed retest is stronger evidence than a report with two findings and no retest. Which is why a report that finds nothing is usually bad news: it means the scope was too narrow, the credentials were wrong, or the environment was not the one your customers use.
Dates, and the question behind the question
When a questionnaire asks for a test within the last twelve months, it is asking whether your evidence still describes the system you are running now. If you shipped a new authentication flow in March, a January test does not cover it, whatever the date says.
Retest windows exist for this. Ours runs ninety days and includes the same tester, so the person verifying the fix is the person who found the bug. That also means the verification is not a fresh reader guessing at what the original finding meant.