Do you need a penetration test for ISO 27001, SOC 2, PCI DSS or NHS DTAC?

ISO 27001 never uses the words “penetration test”. SOC 2 does not formally require one either. You will still fail to get through either audit comfortably without evidence of technical vulnerability testing, and neither standard requires the tester to be CREST accredited.

ISO 27001

The control that matters is Annex A 8.8, formerly A.12.6.1 in the 2013 version: information about technical vulnerabilities must be obtained in a timely manner, exposure evaluated, and appropriate measures taken.

The standard prescribes no method and no cadence. What happens in practice is that an auditor asks how you satisfy 8.8, and a current penetration test report with remediation evidence is the cleanest possible answer. Annual testing aligned to the certification cycle has become the baseline expectation.

The trap is thinking a vulnerability scan closes it. A scan is evidence you looked for known issues in known software. It is not evidence you evaluated your exposure, because it cannot reason about your business logic.

SOC 2

SOC 2 does not mandate a penetration test, and an auditor will not fail you purely for skipping one. In practice most auditors expect a recent third party test as supporting evidence, and its absence tends to trigger requests for supplemental evidence that slow the audit down.

The stronger pressure is commercial rather than audit. Enterprise buyers expect to see a recent penetration test report alongside the SOC 2 report, and for many it is a hard requirement in their vendor security questionnaire. That is where deals stall.

PCI DSS, where it genuinely is mandatory

If you store, process or transmit cardholder data, this one is not a matter of expectation. Requirement 11.4 of PCI DSS v4.0 requires internal and external penetration testing at least annually and after any significant change, using a documented methodology, with findings remediated and retested. All future dated requirements became mandatory on 31 March 2025.

The methodology must be industry accepted, and PCI names PTES and NIST SP 800-115 explicitly. Automated scanning alone does not satisfy 11.4: it requires human led testing.

In the UK, PCI DSS is a contractual obligation rather than statute. The consequences of ignoring it are fines and losing the ability to accept cards, which for most businesses is worse than a regulator.

NHS DTAC

Selling a digital product into the NHS means passing the Digital Technology Assessment Criteria. It asks for two distinct things: Cyber Essentials certification, and evidence the solution has been penetration tested within the last 12 months with priority vulnerabilities fixed.

This is also the one place where the CREST question genuinely bites. DTAC guidance steers buyers towards CREST approved providers. If you are selling to the NHS, check your specific requirement before commissioning anything.

So do you need CREST?

For ISO 27001 and SOC 2, no. Neither framework requires it. What is expected is a qualified third party following a recognised methodology, with the methodology named in the report. The standards people cite are the OWASP Web Security Testing Guide, PTES and NIST SP 800-115.

Where CREST does matter: some public sector contracts, NHS DTAC, and any contract whose clause names it specifically. Read the clause before paying a premium for a badge your contract never asked for.

What to ask a prospective tester

• Which methodology do you follow, and will it be named in the report
• Will the report contain evidence per finding, not just a severity label
• Is a re-test of our fixes included, and within what window
• Will I get something I can hand to an auditor and something my developers can act on
• What are you not able to do

That last question is the most revealing. Anyone who claims no limits has not been doing this long enough.