Penetration testing for ISO 27001, SOC 2 and GDPR: what each actually requires
Do ISO 27001, SOC 2 and GDPR require a pentest? What each framework actually asks for, what auditors look for, and how one well-scoped test becomes evidence for all of them.
Summary: ISO 27001, SOC 2 and GDPR do not say "penetration testing is mandatory" — but all three require you to test and prove the effectiveness of your security controls, and a pentest is the evidence auditors, customers and regulators recognise most. GDPR is explicit: Article 32(1)(d) calls for "a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures". The one standard with a direct, periodic pentest requirement is PCI DSS (requirement 11.4).
"Do we need a pentest for certification?" is one of the most common questions from teams going through ISO 27001 or SOC 2. The short answer: in the letter of the standard, not always; in audit and sales practice, almost always.
ISO/IEC 27001:2022
What the standard asks: risk management and Annex A controls proportionate to risk. Three controls touch security testing directly:
- A.8.8 — Management of technical vulnerabilities.
- A.8.29 — Security testing in development and acceptance of new and changed systems.
- A.5.35 — Independent review of information security.
What the auditor looks for: evidence that vulnerabilities are identified systematically beyond scanners, that findings become risk treatment with an owner and a deadline, and that significant changes are tested. A recent report with a remediation plan and a retest covers all three.
SOC 2
SOC 2 assesses controls against the AICPA Trust Services Criteria. CC4.1 (monitoring activities) lists penetration testing among separate evaluations; CC7.1 covers detecting vulnerabilities and configuration changes. There is no literal mandate, but an annual pentest is the market standard and SOC 2 Type II auditors ask for it.
What the auditor looks for: a pentest within the Type II observation period, by an independent third party, with findings tracked to resolution. Customers reading your SOC 2 report will also ask for the pentest executive summary. Tip: schedule the test at the start of the observation window so fixes land inside it.
GDPR
What it asks: Article 32 requires technical and organisational measures appropriate to the risk, explicitly including a process for regularly testing their effectiveness. Article 25 (data protection by design) and Articles 33–34 (breach notification) complete the picture.
Why a pentest matters: after a breach, the regulator will ask "what measures did you have and how did you verify they worked?". Fines for Article 32 infringements reach €10 million or 2% of worldwide annual turnover, and €20 million or 4% for the most serious infringements.
HIPAA (US healthcare)
The HIPAA Security Rule requires periodic technical and non-technical evaluation of safeguards (45 CFR 164.308(a)(8)) and risk analysis. HHS has proposed updates that would make vulnerability scanning and annual penetration testing explicit; even before that, a pentest is the standard way to evidence the evaluation.
PCI DSS 4.0 — the explicit one
PCI DSS requires internal and external penetration testing at least annually and after significant changes, segmentation testing and a documented methodology. See what assessors expect from a PCI DSS 4.0 pentest report. In EU finance and essential sectors, add DORA and NIS2.
One pentest, several pieces of evidence
| Requirement | Where the pentest fits | What to keep |
|---|---|---|
| ISO 27001 A.8.8 / A.8.29 | vulnerability identification, testing changes | report, treatment plan, retest |
| SOC 2 CC4.1 / CC7.1 | independent evaluation of controls | report within Type II period, remediation tickets |
| GDPR Art. 32 | regular testing of effectiveness | report, fixes, decision log |
| HIPAA 164.308(a)(8) | periodic technical evaluation | report, risk analysis update |
| PCI DSS 11.4 | direct requirement | report with methodology, segmentation, retest |
Ask your vendor for scope and methodology in the report, justified severity, a retest with an updated report and an attestation letter you can share with customers without exposing technical detail.
Mistakes that make a pentest worthless as evidence
- A scanner-only report. Experienced auditors recognise it.
- Scope that does not match the certification scope — testing the marketing site and skipping the app that handles data.
- Critical findings with no fix and no formal risk acceptance.
- A report older than 12 months at audit time.
- No retest — you say it is fixed but cannot prove it.
Frequently asked questions
Does ISO 27001 require penetration testing?
Not in those words. It requires managing technical vulnerabilities and security testing of new and changed systems; a pentest is the most accepted way to evidence both.
Does SOC 2 require a penetration test?
The criteria mention penetration testing as a form of evaluation without mandating it, but an annual pentest is expected by auditors and customers, especially for Type II.
Does GDPR require penetration testing?
Article 32 requires a process for regularly testing the effectiveness of security measures. For applications processing personal data, a pentest is the most direct way to meet and demonstrate it.
Can one pentest cover ISO 27001, SOC 2 and GDPR?
Yes, if the scope covers the relevant systems and the report includes methodology, traceability and a retest. See also how much a penetration test costs and our checklist for hiring a pentest.