Strictly read, the trust services criteria ask you to identify and manage vulnerabilities — they never prescribe how. In theory a company could argue that scanning, code review, and monitoring cover it. In practice, penetration testing has become the artifact auditors reach for when testing those criteria, and declining to have one means arguing the substitute with your auditor mid-engagement — a debate that costs more than the test and can end up noted in the report.
The second source of the requirement is commercial. The security teams that read SOC 2 reports habitually ask for the latest pen test in the same breath, and treat its absence as a signal about engineering culture. So the practical package a mature vendor ships is: current report, bridge letter if there’s a gap, and a pen-test attestation letter dated within the last year. For a Type 2, schedule the test inside the observation window with room to remediate and retest — one well-placed date satisfies the auditor and keeps the artifact fresh for buyers.
What the deliverable contains, what reviewers check, and why you share the attestation letter instead of the full report are covered on the penetration test report page. How Agency scopes and delivers testing inside compliance programs — including in startup packages — is on pen testing for compliance.
Sometimes technically, rarely comfortably. Scans are automated breadth; a pen test adds human depth against your actual application logic, and both auditors and buyers know the difference. Teams that substitute scanning usually field the pen-test question again in the next security review, having saved nothing.
Scope it to the system your report describes — the production application, its APIs, and supporting infrastructure. Testing only peripheral assets is the classic false economy: the PDF exists, but the buyer whose data lives in the product will notice the product wasn’t tested.
