Which Compliance Standards Require Penetration Testing (and Which Are Vague About It)?

Ask five compliance professionals whether a particular standard requires a penetration test, and you’ll probably get several different answers. Part of the reason is that the standards themselves are written very differently. 

Some name penetration testing outright and tell you how often to do it. Others describe outcomes, such as “manage technical vulnerabilities”, and leave you to work out how to evidence them. A few simply ask for “regular testing” and never explain what that means.

This guide sorts the most common standards and regulations UK organisations deal with into three groups: those that explicitly require penetration testing, those that strongly imply it, and those that are vague about it. For each one, we explain what the text actually says, what auditors and regulators tend to expect in practice, and where to read more.

A quick note before we start: this is a practical overview, not legal advice, and the details of any standard can change, so it’s always sensible to confirm your obligations with your auditor, assessor, or legal adviser.

Penetration Testing Compliance at a Glance

If you only need the headline view, this is how the main penetration testing standards and regulations compare.

Group One: Standards That Explicitly Require Penetration Testing

These are the easy ones because they require no interpretation. If the standard applies to you, you need a penetration test, and the standard tells you how often.

PCI DSS

PCI DSS is the clearest example of a standard that mandates penetration testing. Under version 4.0.1, which you can download from the PCI Security Standards Council’s document library, Requirement 11.4 sets out the rules:

• A documented penetration testing methodology based on an industry-accepted approach (11.4.1).
• Internal and external penetration testing at least once every 12 months, and after any significant change to the in-scope environment (11.4.2 and 11.4.3).
• Exploitable vulnerabilities found during testing must be corrected and then retested (11.4.4).
• Where segmentation is used to reduce scope, segmentation controls must be tested at least every 12 months, or every six months for service providers (11.4.5 and 11.4.6).

Notably, PCI DSS is a contractual standard rather than a law, meaning that the obligation comes through your relationship with your acquiring bank and the card brands. 

That doesn’t make it any softer in practice, because failing an assessment can lead to fines passed on by your acquirer and, in the worst case, the loss of your ability to take card payments. 

We cover each sub-requirement in detail in our guide to PCI DSS penetration testing.

DORA, for firms designated for TLPT

The Digital Operational Resilience Act (DORA), which is Regulation (EU) 2022/2554 and is available in full on EUR-Lex, has applied since the 17th of January, 2025. It includes two layers of testing, and only the top layer explicitly mandates penetration testing.

That top layer is threat-led penetration testing, or TLPT, and under Article 26, financial entities identified by their competent authority must carry out TLPT at least every three years. 

TLPT is a full, intelligence-led red team exercise against live production systems, built on the TIBER-EU framework, and the detailed rules are set out in the regulatory technical standards on TLPT (Commission Delegated Regulation (EU) 2025/1190), which entered into force on the 8th of July, 2025. Firms don’t typically choose to be in this group. Instead, the relevant TLPT authority notifies them based on criteria such as size, systemic importance, and risk profile.

For UK firms, DORA is only directly relevant if you operate in the EU or provide services to EU financial entities. A firm operating purely in the UK sits under the FCA and PRA regime instead, and the largest UK firms may be asked by the Bank of England to take part in CBEST, which is its own intelligence-led testing scheme.

Group Two: Standards That Imply Penetration Testing

This is where most of the confusion lies because none of these standards contains a sentence saying, “you must commission a penetration test”, but each one asks you to evidence something that, in practice, is hard to do without one.

DORA, for everyone else in scope

The second layer of DORA applies to almost every in-scope financial entity, not just the designated few. Article 24 requires a digital operational resilience testing programme, and all ICT systems and applications supporting critical or important functions must be tested at least once a year. Article 25 then lists the kinds of tests that programme should include, such as vulnerability assessments, network security assessments, scenario-based tests and penetration testing.

Crucially, penetration testing appears in that list as an example (“such as”) rather than as a standalone obligation, which is why we’ve placed this layer of DORA in the implied group. 

In reality, it’s hard to show a regulator that your critical systems have been properly tested every year without some form of penetration testing. Our DORA compliance guide covers the wider regulation.

ISO 27001

ISO/IEC 27001:2022 doesn’t mention penetration testing as a requirement. What it does do is set out Annex A controls that a penetration test is very well suited to evidencing, including:

• Control 8.8, management of technical vulnerabilities, which expects you to identify technical vulnerabilities, evaluate your exposure to them and take appropriate action.
• Control 8.29, security testing in development and acceptance, which expects security testing to be defined and carried out as part of the development life cycle.

ISO 27001 is a risk-based standard, meaning you decide which controls apply, how you’ll meet them, and justify those decisions in your Statement of Applicability. In theory, you could meet control 8.8 with vulnerability scanning and a good patching process alone. In practice, many certification auditors expect to see independent penetration testing for internet-facing systems and anything that holds sensitive data, and an organisation with no testing at all will usually struggle to show that its controls are effective. We explain the standard in more detail in our guide to ISO 27001.

SOC 2

SOC 2 is an attestation framework from the AICPA, built around the Trust Services Criteria, and it’s most relevant to UK software companies selling to US customers. As the Cloud Security Alliance points out, SOC 2 contains no explicit requirement for penetration testing, or indeed for any specific control. Instead, the auditor evaluates the controls you’ve chosen against the criteria.

Interestingly, penetration testing still appears in a large share of SOC 2 audits because it’s one of the most straightforward ways to meet criteria such as CC4.1, which asks organisations to carry out ongoing or separate evaluations of whether their controls are present and functioning. 

Customers reviewing your SOC 2 report often ask for a pen test summary too, so sales conversations usually create more pressure than the framework itself.

One that gets mistaken for a penetration test: Cyber Essentials Plus

Cyber Essentials doesn’t really fit into any of the three groups, but it’s worth mentioning because so many businesses assume Cyber Essentials Plus covers their penetration testing needs.

It doesn’t. 

Cyber Essentials Plus adds hands-on technical verification of the five Cyber Essentials controls, which is valuable, but it’s much narrower than a penetration test and doesn’t try to find and exploit weaknesses the way an attacker would.

Group Three: Requirements That Are Vague About Testing

These are the hardest to plan around, because the obligation is real but the method is left entirely open. Perhaps most importantly, “vague” doesn’t mean “optional”; it means that if something goes wrong, you’ll need to show that your approach was reasonable, without a clear checklist to point to.

UK GDPR

Article 32 of the UK GDPR requires organisations to implement security measures appropriate to the risk, and Article 32(1)(d) adds “a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing”. It doesn’t say what “regularly” means, and it doesn’t mention penetration testing.

The ICO’s enforcement history does fill in some of the gap because, in a reprimand letter to the Chartered Institute for Securities & Investment dated the 21st of February, 2023, the ICO looked at a 2020 attack in which a criminal exploited a known vulnerability in unsupported website software and captured the payment details of an estimated 3,883 people.

The ICO noted that “no penetration testing or web application scanning had been conducted”, and its recommendations included implementing “a testing procedure which sets out the timings and nature of testing to be conducted”. 

So, while the law doesn’t name penetration testing, the regulator clearly treats its absence as a sign that Article 32 wasn’t being taken seriously.

FCA expectations

The FCA doesn’t publish a rule requiring regulated firms to commission penetration tests. Instead, firms are expected to maintain adequate systems and controls under the SYSC sourcebook, and the operational resilience rules require firms to identify their important business services, set impact tolerances and test that they can stay within those tolerances in severe but plausible scenarios. The transition period for those rules ended on the 31st of March, 2025.

A cyber attack is one of the most obvious severe but plausible scenarios, which is where penetration testing naturally fits, but the choice of testing method is left to each firm. As a result, two firms of similar size can take very different approaches, and both claim to meet expectations, at least until something goes wrong. Our guide to what the FCA and DORA expect covers where pen testing sits within that regime.

Requirements That Aren’t Standards at All

Some of the strongest pressure to test comes from outside formal compliance. Cyber insurers increasingly ask about penetration testing at renewal, and enterprise customers often write testing requirements straight into their contracts or supplier questionnaires. 

Neither is a regulator, but both can have very real consequences, such as a declined claim or a lost deal.

Does an AI Pentest Count?

Automated vulnerability scanners and AI-led pentests are often sold as a faster, cheaper route to compliance, and as far as most auditors and regulators are concerned, they sit in the same bracket. 

None of the standards above bans them outright, but PCI DSS makes it clear they aren’t enough on their own. It treats vulnerability scanning (Requirement 11.3) and penetration testing (Requirement 11.4) as separate obligations, and it expects a penetration test to be carried out by a qualified, independent tester following a documented methodology.

The less prescriptive standards, such as ISO 27001, SOC 2 and UK GDPR, leave more room for interpretation, but an auditor will still expect your testing to have been meaningful. That’s hard to show if nobody looked at your business logic, your access controls or how weaknesses could be chained together, which are exactly the areas that largely automated tools tend to miss.

Crucially, the safest approach is to treat scanners and AI as tools that support a qualified tester, not as a replacement for one. We explain the difference in automated vs manual penetration testing.

The best advice is to always check with your auditor whether AI and automated tests count, and get written confirmation. If this doesn’t yield clear results, a human-led pentest is always safer. 

After all, every LLM comes with a disclaimer saying that it can get things wrong. That’s not exactly the sort of disclaimer you want to trust with your company’s security.

What This Means for Your Testing Programme

If you’re subject to more than one of these standards, which is very common, it usually makes sense to plan one compliance penetration testing programme that satisfies all of them, instead of commissioning separate tests for each. 

A well-scoped annual test from a CREST-accredited provider, with retesting after significant changes, will meet the PCI DSS baseline and provide strong evidence for ISO 27001, SOC 2, UK GDPR, and the FCA at the same time.

There are a few things worth building in from the start:

• A documented scope and methodology, because almost every auditor will ask to see them.
• A remediation and retest record, since finding vulnerabilities is only half of the evidence. If you can’t fix every finding straight away, our guide on what to do if you can’t fix everything explains how to handle the rest.
• A report written with auditors in mind. Again, talking to your auditor and passing on their recommendations to your pentest provider can help.

Above all, don’t let compliance be the only thing deciding your scope. A test designed purely to satisfy an auditor tends to cover the same systems every year, which is exactly how organisations end up in the Pentest Trap, where they hold a clean report while their real exposure sits somewhere nobody looked.

Mapping Your Testing to Your Obligations with Fortifi

Fortifi is a CREST-accredited penetration testing company, and our UK penetration testing services are regularly used to support PCI DSS, ISO 27001, SOC 2, DORA and UK GDPR obligations.

Because we don’t do sales calls, you’ll speak directly with a cybersecurity expert who can help you determine which obligations require testing and scope a single programme that covers them, so you don’t pay twice for the same work.

Book a call with our team to talk through your compliance requirements.

Penetration Testing Compliance FAQs

Which compliance standards legally require penetration testing?

Of the standards covered here, DORA is the only one that is law and names penetration testing as a firm obligation, and even then only threat-led testing for designated firms. PCI DSS names it explicitly too, but it’s a contractual standard rather than a law. The UK GDPR is law, but it only asks for “regular testing” without specifying the method.

Does ISO 27001 require a penetration test?

Not explicitly. ISO 27001:2022 requires you to manage technical vulnerabilities and carry out security testing, and penetration testing is one of the most common ways of evidencing those controls. Many certification auditors expect to see it for internet-facing systems.

How often should penetration testing be done for compliance?

PCI DSS sets the clearest rule: at least every 12 months and after any significant change, and that has become the widely accepted baseline for other standards, too. DORA’s threat-led testing runs on a three-year cycle for designated firms, alongside annual testing of critical systems.

Can one penetration test satisfy several standards at once?

Often, yes. A single test with a well-planned scope, documented methodology, and remediation record can provide evidence for PCI DSS, ISO 27001, SOC 2, and UK GDPR. The key is agreeing on the scope with all of those requirements in mind before testing starts.