Does PCI DSS require penetration testing? Yes, explicitly. Unlike most compliance frameworks, which expect penetration testing without ever quite naming it, PCI DSS puts it in the rulebook in black and white. Requirement 11.4 mandates internal and external penetration testing at least once every 12 months and after any significant change, backed by a documented methodology, remediation and retesting of anything exploitable, and separate testing of your segmentation controls. It’s the clearest penetration testing mandate of any major standard, and a missing or out-of-date test is a straightforward compliance failure, not a matter of interpretation.

That clarity cuts both ways. It means there’s no ambiguity about whether you need to test, but it also means the requirement is prescriptive: your assessor will check your testing against specific sub-requirements, and “we ran a scan” won’t cut it. This guide explains exactly what PCI DSS asks for, how often, who can do it, and the mistakes that trip organisations up.

Who does this actually apply to?

PCI DSS applies to any organisation that stores, processes or transmits cardholder data, whether you’re a merchant taking payments or a service provider handling card data on someone else’s behalf.

That said, not every business validates against the full standard, and how much of Requirement 11 applies to you depends on the way you handle card data and the validation route you fall under. An online retailer that fully outsources payments to a compliant provider, and never touches card data directly, has lighter obligations than one that processes payments through its own systems. If you validate through a full self-assessment or a formal assessment by a Qualified Security Assessor, the complete Requirement 11.4 applies. The safest move is to confirm your exact scope with your acquiring bank or QSA, because getting this wrong in either direction is expensive.

Requirement 11.4: the heart of PCI DSS penetration testing

First, a point of confusion worth clearing up. In older versions of the standard, penetration testing lived under Requirement 11.3. In the current version it has moved to Requirement 11.4, and 11.3 now covers vulnerability scanning. If you’re reading guidance that references 11.3 for penetration testing, it predates the current standard.

Requirement 11.4 breaks down into a set of sub-requirements your assessor will check directly:

A documented methodology: You need a defined, repeatable penetration testing methodology, not an ad-hoc approach. It has to be based on industry-accepted methods and spell out what you test and how.

Internal penetration testing: Testing from inside your network, performed at least every 12 months and again after any significant infrastructure or application change.

External penetration testing: Testing from outside your network, on the same cadence: at least every 12 months and after any significant change.

Remediation and retesting: Any exploitable vulnerabilities or weaknesses you find must be corrected, and the testing repeated to confirm the fixes actually worked. The test isn’t finished when the report arrives.

Segmentation testing: Where you use segmentation to isolate your cardholder data environment, you have to test that the segmentation genuinely holds. For most organisations that’s at least every 12 months. Service providers face a stricter cadence and must test segmentation at least every six months.

Support for customers’ testing: Multi-tenant service providers, such as hosting platforms and many SaaS businesses, must support their customers in carrying out their own external penetration tests, so those customers can meet their own obligations.

How often is penetration testing required?

The headline cadence is straightforward, but the second half of it catches people out.

Internal and external penetration tests are required at least once every 12 months. That’s the floor, not the ceiling. On top of that, you must test again after any significant infrastructure or application change. Given that most modern businesses ship code and change their cloud environment constantly, that second trigger is where a lot of organisations quietly fall out of compliance. A single annual test doesn’t cover a major release you pushed six months ago.

Segmentation controls follow their own schedule: at least every 12 months for most entities, and at least every six months for service providers, plus a test after any change to how your segmentation works.

What your testing has to cover

A PCI DSS penetration test isn’t a light-touch exercise. To satisfy the methodology requirement, your testing needs to cover the full perimeter of your cardholder data environment and the critical systems that support it. It has to be carried out from both inside and outside the network, at both the network layer and the application layer. The application-layer testing has to look for the vulnerability classes the standard calls out elsewhere, the common web weaknesses like injection and broken access control. Where you rely on segmentation to reduce your scope, that isolation has to be actively validated rather than simply documented. And you’re expected to retain your results and remediation records so an assessor can review them.

The underlying principle is that a diagram showing your CDE is walled off proves nothing. Only testing proves it.

Vulnerability scanning is not penetration testing (and PCI DSS needs both)

This is the single most important distinction to get right, because PCI DSS treats the two as separate requirements.

Requirement 11.3 covers vulnerability scanning. It requires regular internal scans, and external scans carried out by an Approved Scanning Vendor, on a quarterly basis and after significant changes. These are automated checks for known weaknesses.

Requirement 11.4 covers penetration testing, the annual, human-led exercise described above.

They are not interchangeable, and you can’t use one to satisfy the other. Assessors increasingly push back on organisations trying to pass their penetration testing requirement with an automated scanner, because a scanner produces a list of potential issues, not evidence that those issues are genuinely exploitable or that your fixes work. If you want a fuller explanation of why the two are different, we’ve covered it in our guide to vulnerability scanning versus penetration testing. For PCI DSS, the short version is: you need both, and they do different jobs.

Who is allowed to perform the test?

Here’s a detail many people get wrong: PCI DSS does not require your penetration tester to be a QSA or an Approved Scanning Vendor. The standard allows either a qualified internal resource or a qualified external third party, provided there’s genuine organisational independence between the tester and the systems being tested.

In practice, most organisations use an independent external firm, for two reasons. Independence is easier to demonstrate, and specialist testers bring credibility that stands up to an assessor’s scrutiny. Recognised accreditation, such as CREST, is a straightforward way to evidence that the people doing the work are qualified.

A practical tip: reduce your scope, reduce your testing

Because your testing obligations flow from the size of your cardholder data environment, one of the most effective ways to reduce the cost and effort of PCI DSS is to shrink that environment. Good segmentation, isolating the systems that handle card data from everything else, means fewer systems fall in scope and less has to be tested. That’s precisely why the standard insists you validate your segmentation: it’s the control that keeps your scope small, so it has to actually work.

Common pitfalls to avoid

The organisations that struggle with PCI DSS penetration testing tend to make the same handful of mistakes:

• Confusing the quarterly ASV scans with the annual penetration test, and assuming one covers the other. It doesn’t.
• Trying to satisfy Requirement 11.4 with an automated scan. Assessors expect human-led, exploit-based testing.
• Forgetting the “after significant change” test, and relying on the annual test alone despite major releases in between.
• Treating the report as the finish line and skipping the remediation and retesting the standard requires.
• Scoping incorrectly or without a documented methodology, which undermines the whole engagement.