Operational guidance, not legal advice. This page distills named public sources (regulator guidance and industry practice). It is not a legal determination, not a notification decision, and not a substitute for your counsel, insurer, or a retained DFIR firm. Verify applicability and current deadlines for your facts and jurisdiction.
Do I need a penetration test?
Last verifiedA penetration test is needed when a contract, framework, or regulation requires one — PCI DSS 11.4, a customer exhibit, or auditor practice around SOC 2 or ISO 27001. Scanning and SAST/DAST do not substitute. This page is not legal advice.
Penetration-test need, last verified 10 September 2026 against PCI DSS v4.0.1 Requirement 11.4 (PCI SSC), AICPA Trust Services Criteria CC4.1 and CC7.1, ISO/IEC 27001:2022 A.8.8 and A.8.29, and NIST SP 800-115 (methodology guidance, not a statute). It is not legal advice, not a determination that a framework applies to YOU, and not a substitute for an independent pen test.
This is a decision tree, not YOUR requirement
Audience: a founder, CTO, CISO, or auditor deciding whether to budget an independent penetration test. This page is not legal advice. Reading it does not start a clock and does not determine that PCI DSS, SOC 2, ISO/IEC 27001, or a customer contract applies to YOU.
Kind of text: PCI DSS Requirement 11.4 is a contractual/program requirement only if YOU are in PCI scope. AICPA Trust Services Criteria are attestation criteria — they do not name an annual pen test. ISO/IEC 27001:2022 names technical vulnerability management and security testing (A.8.8, A.8.29), not “pen test” verbatim. NIST SP 800-115 is technical guidance on planning and scoping tests, not a legal mandate. ShipReady Metrics recommendation: treat continuous scanning and first-party SAST/DAST as the layer between point-in-time tests, not a replacement.
Decision tree — does a contract, framework, or regulation require it?
Walk the tree with counsel or your assessor. A “yes” on any row is a trigger to scope a test, not a finding that this page has applied the rule to YOU. Last verified 10 September 2026. Not legal advice.
| Question | If yes | Kind of text | What this page does not do |
|---|---|---|---|
| Are you in PCI DSS scope and subject to Requirement 11.4? | A penetration test is a program requirement at least annually and after significant change, with re-testing to confirm remediation (Req. 11.4). | Contractual / PCI SSC program requirement — only if PCI applies. | Does not find that YOU are a merchant, service provider, or in PCI scope. |
| Does a customer, insurer, or investor contract require an independent pen test? | The exhibit is the driver. Scope, recency, and retest language in the exhibit control, not this page. | Contractual requirement — only if that exhibit binds YOU. | Does not interpret YOUR contract. |
| Are you preparing a SOC 2 examination? | SOC 2 has no explicit “annual pen test” mandate. Testing supports CC4.1 (monitoring) and CC7.1 (detection) and is common auditor practice. | Attestation criteria (TSC) plus auditor practice — not a named SOC 2 requirement. | Does not find that YOU need SOC 2 or that an auditor will accept a scan in lieu of a test. |
| Are you pursuing ISO/IEC 27001:2022 certification? | Annex A expects technical vulnerability management (A.8.8) and security testing in development and acceptance (A.8.29). A pen test is one way to evidence those controls, not a verbatim mandate. | Normative Annex A controls if they are in YOUR Statement of Applicability; ISO/IEC 27002:2022 is guidance. | Does not write YOUR SoA or decide that a certifier will require a named pen test. |
| None of the above, but you want a maturity signal? | A scoped independent test remains industry best practice (NIST SP 800-115 methodology). It is optional until a driver appears. | Industry best practice / SRM recommendation — not a legal requirement. | Does not treat optional maturity as a mandate. |
Comparison of test triggers
The table contrasts true drivers with optional signals. Do not collapse them. Last verified 10 September 2026. Not legal advice.
| Trigger | What it is | Kind of text | Does a vuln scan substitute? |
|---|---|---|---|
| PCI DSS Req. 11.4 | Internal and external penetration testing at least annually and after significant infrastructure or application change; re-test to confirm fixes. | Program requirement if PCI applies. | No. Req. 11.3 (scanning, including ASV for external) is a different control from 11.4. |
| Customer / insurer exhibit | Whatever the exhibit states — often “independent pen test within 12 months.” | Contract. | Only if the exhibit says so. Most do not treat a scan as a pen test. |
| SOC 2 Type II period | Evidence that detection and monitoring operate. A pen test report is common supporting evidence, not a TSC line item named “pen test.” | Auditor practice supporting TSC CC4.1 / CC7.1. | A scan helps CC7.1; it is not automatically the same evidence as an exploitation-capable test. |
| ISO/IEC 27001:2022 A.8.8 / A.8.29 | Technical vulnerabilities identified and evaluated; security testing in development and acceptance. | Normative if in the SoA. “Pen test” is not the ISO wording. | Scanning supports A.8.8. A.8.29 often expects more than unauthenticated scanning alone. |
| Internal maturity / board request | Point-in-time independent validation of assumptions. | Industry best practice (NIST SP 800-115). | No. Breadth (scan) and depth (pen test) answer different questions. |
What to do now
Operational steps. Not a determination. Not legal advice. Last verified 10 September 2026.
- Ask counsel or your assessor which row in the decision tree, if any, applies to YOU. This page does not run that test.
- If a driver exists, scope methodology using NIST SP 800-115 (rules of engagement, in-scope assets, threat model) before shopping on price.
- Keep continuous scanning and first-party SAST/DAST running between tests. They complement a point-in-time pen test; they do not replace an independent engagement.
- Open the pen-test-versus-scan guide and the SOC 2 / ISO 27001 expectation pages on this site before you brief a vendor.
Checklist
Question list, not YOUR file. Walk it with counsel. Last verified 10 September 2026. Not legal advice.
- Is there a contract exhibit that names a penetration test, recency, and independence?
- Are you in PCI DSS scope for Requirement 11.4? This page does not decide.
- If SOC 2: have you asked the auditor what testing evidence they expect for this period? The TSC does not say “annual pen test.”
- If ISO 27001: are A.8.8 and A.8.29 in the SoA, and how will you evidence them?
- Do you already run vulnerability ingest (Dependabot / code-scanning / secret-scanning) plus first-party SAST/DAST as the continuous layer?
Where this shows up in ShipReady Metrics
Vulnerability ingest (Dependabot, code-scanning, secret-scanning) with KEV, EPSS, and CVSS, cross-source dedup, and blast radius is the continuous scanning layer. First-party SAST and DAST exist in-product. Neither replaces an independent pen test. This product does not file with anyone, does not determine that a framework applies to YOU, and does not start a clock.
If you already have a session: signed-in app → Compliance → Evidence is where a pen-test report can be stored and reviewed with a met-verdict overlay. The obligation map and controls crosswalk (~72 canonical controls, density-honest) do not certify you. Naming signed-in surfaces is not a public href.
Primary sources (last verified 10 September 2026)
PCI DSS v4.0.1 Requirement 11.4 is a PCI SSC program requirement only if PCI applies. AICPA Trust Services Criteria (2017, rev. 2022) CC4.1 and CC7.1 are attestation criteria, not a named pen-test mandate. ISO/IEC 27001:2022 A.8.8 and A.8.29 are normative if included in the SoA; ISO/IEC 27002:2022 is guidance. NIST SP 800-115 is technical guidance on test planning, not a statute. Not legal advice.