Why your business needs penetration testing
SOC 2, ISO 27001, PCI-DSS 4.0, HIPAA - the compliance frameworks all converge on the same expectation: third-party penetration testing on a defined cadence. Why scanners aren't a substitute, when to do it, and the five questions every CISO should bring to a scoping call.
The business case in two minutes
Penetration testing exists because automated scanners miss things humans find. The compliance frameworks have all aligned on this point:
- SOC 2 Trust Services Criteria CC4.1: requires independent evaluation of controls
- ISO/IEC 27001:2022 Annex A 8.8: technical vulnerability management
- PCI DSS 4.0 Requirement 11.4: external + internal penetration testing annually and after significant changes
- HIPAA Security Rule §164.308(a)(8): evaluation requirement
Insurers ask for it. Your enterprise customers ask for it in security questionnaires.
But the real reason to do it: you find out what your environment actually looks like, not what your inventory says it looks like.
Why scanners alone aren't enough
| Test layer | Scanner | Pentest |
|---|---|---|
| Known-CVE detection | Strong | Strong |
| Config drift | Partial | Strong |
| Business logic flaws | None | Strong |
| Chain analysis (multi-step exploit) | None | Strong |
| Authorization gaps (BOLA/BFLA) | Limited | Strong |
| False-positive triage | No | Yes |
| MITRE ATT&CK technique coverage | Subset | Tester-driven |
| Cost (per finding) | Low | Moderate |
Scanners and pentests aren't substitutes. Run scanners constantly for known-CVE coverage. Run pentests on a cadence to find the things scanners can't see - logic flaws, chains, authorization gaps. PCI DSS 4.0 explicitly requires both.
When to do it
The traditional answer is "once a year." PCI DSS 4.0 requires that as a minimum (Requirement 11.4.3, 11.4.4). The right additional moments are:
- Pre-launch
Before a major release
New code, new attack surface. Test the new thing before it ships - finding criticals after launch is more expensive in every dimension.
- Post-migration
After an infrastructure change
Cloud migration, new vendor, restructuring. Whatever assumptions held before don't hold now - re-prove them. PCI DSS 4.0 specifically requires re-testing after significant changes.
- Annual
Baseline cadence
Drift detection. Even when nothing notable changed, your dependency tree did. An annual baseline catches it. Required by PCI DSS, SOC 2 audit cycles, and ISO 27001 surveillance audits.
- Post-incident
After an incident
Validate that root cause was actually fixed, not just the symptom. Most repeat incidents we triage skipped this step.
- Quarterly
Smaller scopes, more often
The teams that get the most value run a focused quarterly scope rather than a giant annual one. The findings are fresher and the fixes ship faster.
Questions to bring to a scoping call
If you're shopping for a pentest partner, the answers to these five questions will tell you more than any sales deck.
What's your methodology?
OWASP ASVS, NIST SP 800-115, PTES, MITRE ATT&CK. They should name a framework and explain how their methodology maps to it. "We use a custom approach" is a yellow flag.
Manual vs automated split?
A 90%-automated engagement is just a scan with a report cover. Push for ≥60% manual time. Ask how they audit the manual time - timesheet, ticket log, screen-record.
What does the report look like?
Ask to see a sanitised sample. Executive summary AND technical detail should both be present. Findings should map to business impact, not just CVSS. PCI DSS 4.0 requires findings to be tracked through to remediation - the report needs to support that.
How do you handle business-logic findings?
This is the question that separates testers who understand context from those who don't. Their answer should reference the specific application they're testing, not generic OWASP categories.
What's the re-test policy?
A good vendor includes a verification round after remediation. Without it, "fixed" is the customer's claim; with it, "fixed" is verified. PCI DSS 4.0 explicitly requires verification of remediation.
What we do differently
We're built around manual testing and business-risk reporting. We don't sell scanner output.
Compliance is the floor, not the ceiling. The teams that get the most out of pentests are the ones who use the compliance requirement as the schedule, but write the scope around their actual business risk.
- Staatse engagement framing, 2024
Key takeaways
- Pentests find what scanners can't - logic, chains, authorization - not just CVE coverage.
- SOC 2, ISO 27001, PCI DSS 4.0 and HIPAA all converge on requiring independent penetration testing on a cadence.
- Cadence matters more than scope size. Quarterly small > annual big in every cohort we measured.
- Manual time percentage is the single best signal of engagement quality. ≥60% is the floor.
- Re-test included is non-negotiable - PCI DSS 4.0 requires it explicitly.
Closing
If your team is approaching a compliance deadline or a board-level security review, request a scoping call and we'll come back within two business days with a fixed scope and a fixed quote.
References & further reading
- AICPASOC 2 Trust Services Criteria - 2017 (current)
- ISOISO/IEC 27001:2022 - Information security management
- PCI SSCPCI DSS v4.0 - Requirement 11.4 (penetration testing)
- NISTSP 800-115: Technical guide to information security testing and assessment
- OWASPOWASP Application Security Verification Standard (ASVS)
- PTESPenetration Testing Execution Standard
- MITREMITRE ATT&CK Framework
- HHSHIPAA Security Rule - 45 CFR § 164.308 (evaluation)