Why penetration testing is on every compliance checklist
Penetration testing has become table stakes for SaaS compliance. SOC 2, ISO 27001, PCI DSS, NIS2 — all of them ask about pen testing, either explicitly or through auditor sampling. Enterprise customers ask about it in vendor questionnaires. Cyber insurers ask about it during underwriting. If you're building a SaaS business that sells to other businesses, the question isn't whether you need a pen test — it's what kind, how often, and how to make one test satisfy multiple frameworks.
This guide breaks down exactly what each major framework requires, what evidence auditors actually check, and how to structure a proportionate programme that works across all of them.
Framework requirements: what's actually mandated
| Framework | Requirement | Frequency | Provider |
|---|---|---|---|
| SOC 2 | CC4.1/CC4.2 — monitoring controls for operating effectiveness. Pen test is the most common evidence. Auditors sample the report and finding remediation. | Annual minimum; after major changes | Third-party strongly preferred |
| ISO 27001:2022 | A.8.8 — management of technical vulnerabilities. Pen testing is primary evidence. Internal audit (Clause 9.2) will check for evidence of testing. | No mandated frequency; annual typical | Internal or third-party |
| PCI DSS v4.0 | Req 11.3: annual external pen test of network and applications. Req 11.4: segmentation test to validate CDE isolation. Findings tracked to remediation. | Annual; after significant changes to CDE | Qualified tester (internal independence or external) |
| NIS2 | Art. 21(2)(e) — regular testing and auditing of security measures. Pen testing is the primary recognised method. | Regular; frequency not specified | Internal or external |
| DORA | Art. 24–26: Threat-Led Penetration Testing (TLPT) for significant financial entities. Intelligence-led red team (TIBER-EU/CBEST methodology). | Every 3 years | External only; intelligence-led |
| HIPAA | §164.312 evaluation of technical safeguards. OCR expects periodic testing of controls protecting ePHI. Pen testing satisfies this. | Periodic; no defined frequency | Internal or external |
SOC 2: what CC4.1 auditors actually check
SOC 2 doesn't say "you must have an annual pen test." It says controls must be monitored for operating effectiveness. But in practice, every SOC 2 auditor expects to see a penetration test report during Type II fieldwork — because it's the clearest independent evidence that your security controls actually work.
What auditors specifically look at:
- The report itself — is it from a credible third-party provider? Is the scope adequate (external perimeter, web application, API at minimum)?
- Finding severity — were any Critical or High findings identified?
- Remediation evidence — for every Critical and High finding, auditors want to see it was remediated within your stated SLA. A git commit or configuration change with a date.
- Recurrence tracking — if the same finding appeared in the previous report and this one, that's a significant deficiency.
- Timing — the test should cover the audit period. A test conducted before the examination period starts has limited value for a Type II report.
The practical implication: schedule your pen test to fall within the SOC 2 examination period. If your audit period is January–December, a November pen test is fine. A pen test from the previous December is too old for a Type II auditor to rely on without explanation.
ISO 27001: A.8.8 and the internal audit requirement
ISO 27001 A.8.8 (management of technical vulnerabilities) covers vulnerability scanning, patch management, and penetration testing together. Your Statement of Applicability (SoA) will include A.8.8 as applicable, and your auditor will check:
- Is there a documented procedure for technical vulnerability management?
- Is penetration testing included as a control activity?
- Are findings tracked and remediated? (Risk Treatment Plan or equivalent)
- Is the scope appropriate to the ISMS boundary defined in Clause 4.3?
The internal audit programme (Clause 9.2) should include a check on A.8.8 controls annually. Your internal audit report should reference the pen test and its findings. The certification body's external auditor will look for consistency between the SoA, internal audit findings, and the actual pen test report.
PCI DSS Req 11: the most prescriptive pen test requirement
PCI DSS v4.0 is the most specific of the major frameworks. Requirement 11.3 requires:
- Annual external pen test covering the external network and application layer of the CDE perimeter
- Annual internal pen test covering the internal network within the CDE
- Testing to include web application attacks (OWASP Top 10 at minimum)
- Findings ranked by risk and remediated within defined timelines
- Retesting to confirm remediation
Requirement 11.4 adds segmentation testing: if you use network segmentation to reduce PCI DSS scope, you must pen test the segmentation controls at least annually (and after any significant changes). This confirms that out-of-scope systems genuinely cannot communicate with the CDE — it's not enough to assert this.
The qualified pen tester requirement: the tester must be organisationally independent from the systems being tested. For most SaaS companies, this means external. Internal testers are only acceptable if there's genuine organisational independence.
Pen test scope: what to include
For most SaaS companies, a proportionate annual pen test includes:
- External network perimeter — internet-facing infrastructure, exposed ports, cloud security groups
- Web application — OWASP Top 10 testing (injection, broken auth, IDOR, SSRF, etc.)
- API — OWASP API Security Top 10 (mass assignment, broken object-level auth, lack of rate limiting)
- Authentication mechanisms — MFA bypass attempts, password reset flows, session management
- Cloud configuration review — AWS/GCP/Azure misconfiguration checks (public S3 buckets, overpermissive IAM, exposed metadata endpoints)
What you don't necessarily need for SOC 2/ISO 27001:
- Social engineering / phishing simulations (useful but separate)
- Physical penetration testing (unless you have physical premises in scope)
- Full red team engagement (this is DORA TLPT territory — complex, expensive, not required for standard SaaS compliance)
Finding classification and remediation timelines
Most frameworks don't mandate specific remediation timelines. PCI DSS is closest — it requires "risk ranking" and addressing high-risk findings "promptly." Industry standard timelines (CVSS-based) that auditors expect:
| Severity | CVSS Range | Standard Remediation SLA | Auditor Expectation |
|---|---|---|---|
| 🔴 Critical | 9.0–10.0 | 7–14 days | Evidence of fix within audit period; retest confirmation |
| 🟠 High | 7.0–8.9 | 30 days | Remediation evidence; may accept POA&M with timeline |
| 🟡 Medium | 4.0–6.9 | 90 days | Tracked in vuln management; evidence of progress |
| ⚪ Low / Info | 0.1–3.9 | 180 days / next cycle | Tracked; risk-accepted if not remediated |
What the pen test report must contain for auditors
A pen test report that satisfies SOC 2, ISO 27001, and PCI DSS auditors should include:
- Scope statement — exactly what was tested (IP ranges, domains, application URLs, API endpoints)
- Methodology — OWASP, PTES, NIST SP 800-115, or equivalent
- Testing approach — black-box, grey-box, or white-box (with credentials)
- Findings list — each finding with CVSS score, description, evidence (screenshot or PoC), affected component
- Risk rating — Clear Critical/High/Medium/Low classification
- Recommendations — specific remediation guidance per finding
- Executive summary — for board/management reporting
- Tester credentials — CREST, OSCP, or equivalent certification listed
Raw automated scanner output (Nessus, Qualys dumps) does not satisfy these requirements. Auditors distinguish between vulnerability scanning (automated) and penetration testing (manual exploitation).
Provider selection: what qualifications matter
For most SaaS companies, a CREST-accredited firm (UK) or one staffed by OSCP/GPEN-certified testers (US) is sufficient. What to look for:
- Experience with SaaS / web application testing (not just network perimeter)
- Methodology matched to scope (OWASP for web apps, OWASP API Security for APIs)
- Sample report quality — ask for a redacted sample before engaging
- Clear scope of work document before testing begins
- NDA covering findings confidentiality
- Retesting included or priced separately
Price ranges (UK/US, 2026): external network + web application pen test typically £3,000–£8,000 for a small SaaS with limited scope. API testing adds £1,000–£3,000. Full cloud config review adds £2,000–£5,000. Annual total for a comprehensive test: £6,000–£15,000 depending on scope complexity.
When to test: timing your pen test for maximum compliance value
- For SOC 2: schedule within the examination period. If your audit period ends December 31, a test in October or November gives you time to remediate Critical findings before the period closes.
- For ISO 27001: align with the management review cycle. Test in Q3, present results at Q4 management review, feed findings into the risk register and risk treatment plan for the following year.
- For PCI DSS: after the last significant change to the CDE scope. If you moved to a new payment processor or migrated cloud regions, retest promptly.
- After major releases: a significant new feature that handles sensitive data or changes authentication flows warrants an ad-hoc test, not waiting for the annual schedule.
Use the free Penetration Testing Policy Generator to create a formal policy covering scope, methodology, CVSS-based remediation timelines, provider requirements, and responsible disclosure. For vulnerability management between pen tests, see the Vulnerability Management Policy Generator. For SOC 2 audit preparation, use the SOC 2 Gap Assessment Generator.