Yes. Unlike ISO 27001, which never uses the words "penetration testing" anywhere in the standard, PCI DSS names it directly. Requirement 11.4 of PCI DSS v4.0.1 spells out exactly what kind of testing you need, how often, and what a tester has to be independent of. There's no ambiguity to argue your way around here.
That specificity is also where most companies trip up. Requirement 11.4 isn't one line, it's seven sub-requirements, and passing an audit means satisfying all of them, not just producing a report with "penetration test" in the title.
What Requirement 11.4 actually says
| Sub-requirement | What it covers | Minimum frequency |
|---|---|---|
| 11.4.1 | Documented testing methodology, covering the full cardholder data environment perimeter and critical systems, both application and network layer | Ongoing, used for every test |
| 11.4.2 | Internal penetration test | Every 12 months, plus after any significant change |
| 11.4.3 | External penetration test | Every 12 months, plus after any significant change |
| 11.4.4 | Remediate exploitable findings and retest to confirm they're fixed | Every time a test finds something exploitable |
| 11.4.5 | Segmentation testing, if you use segmentation to isolate your cardholder data environment | Every 12 months, plus after any change to segmentation |
| 11.4.6 | Segmentation testing for service providers specifically | Every 6 months, plus after any change to segmentation |
| 11.4.7 | Multi-tenant service providers must support their customers' own external testing under 11.4.3 | Tied to the customer's cycle |
Notice 11.4.6 is stricter than 11.4.5. If you're a service provider, meaning you process, store, or transmit cardholder data on behalf of other businesses, you're on a six-month segmentation testing clock, not twelve. A lot of fintechs providing payment infrastructure to other companies fall into this category without realizing the shorter cadence applies to them.
The mix-up that gets people in trouble: scanning vs. testing
Requirement 11.3 covers vulnerability scanning. Requirement 11.4 covers penetration testing. They are not the same requirement, they don't satisfy each other, and QSAs see this confusion constantly.
Vulnerability scanning is largely automated. It runs on a fixed schedule (quarterly, for external scans, done by an Approved Scanning Vendor) and checks for known issues against a signature database. Penetration testing under 11.4 is a manual process. A person actively tries to exploit what they find, chain smaller issues together, and prove real impact, the same distinction that matters for ISO 27001's A.8.29. A clean quarterly scan report does not check the 11.4 box, no matter how thorough the scan was.
Who's allowed to run the test
11.4.2 and 11.4.3 both require the tester to have organizational independence, meaning they can't test systems they're also responsible for managing or maintaining. Your own infrastructure team running a test on their own environment doesn't satisfy this, even if they're technically skilled enough to find real issues.
The tester doesn't have to be a QSA or an ASV specifically for the pentest itself. What matters is qualification and independence, whether that's an internal team with no operational responsibility for the systems in scope, or a third party.
What "significant change" actually triggers a retest
PCI DSS deliberately doesn't give you a strict list here. A new payment integration, a major infrastructure migration, opening up a new API endpoint that touches cardholder data, these are the kinds of changes that should trigger a fresh test rather than waiting for your annual date to roll around. Treating "significant change" as "basically never happens" is how companies end up testing infrastructure that looked nothing like this a year ago.
Building in time to actually fix things
11.4.4 requires you to correct exploitable findings and retest to confirm the fix. That retest isn't optional and it isn't a formality, if a critical finding from your annual test is still open when your assessor reviews your evidence, you've got a real problem. Leave enough runway between your test date and your assessment, ideally a couple of months, to actually remediate and get a documented retest done rather than scrambling the week before.