Contents
Introduction
If your business takes card payments, someone has probably asked whether you need a penetration test to stay PCI compliant. The short answer is yes, and the requirement that governs it has changed more than most people realise. This guide walks through what PCI DSS penetration testing actually demands, where teams most often get caught out, and what a tester needs to hand you so an assessor will accept it.
Does PCI DSS require penetration testing?
Yes, unlike some frameworks that only imply it, PCI DSS names penetration testing directly and sets out exactly when and how it has to happen. The control that covers it is Requirement 11.4.
It is worth being clear about what kind of obligation this is. PCI DSS is a contractual standard rather than a law, meaning that you agree to meet it through your relationship with the card brands and your acquiring bank, not because a statute compels you. In practice, though, the distinction rarely offers much comfort, because failing an assessment can lead to fines passed down from your acquirer, and in the worst case the loss of your ability to accept card payments at all, which is usually a bigger problem than any fine.
So while nobody from the government will knock on your door about PCI DSS, the people who let you process payments care a great deal, and they treat Requirement 11.4 as a control an assessor checks head-on.
From Requirement 11.3 to 11.4: what actually changed
Here is where a lot of older advice trips people up. Under the previous version of the standard, PCI DSS v3.2.1, penetration testing lived under Requirement 11.3. In the current version it has moved to Requirement 11.4, and the renumbering came with real changes to substance, not just a new label.
The timeline matters, so it is worth pinning down the dates:
- 31 March 2024 was when PCI DSS v4.0 replaced v3.2.1 as the only active standard. Any assessment from that point had to be run against v4.0.
- 31 March 2025 was the deadline by which every “future-dated” requirement in v4.0 became mandatory. Several of the biggest penetration testing changes sat in that future-dated group, so they are now fully in force.
- v4.0.1, released in 2024, is a maintenance revision that tidied up wording. Crucially, it did not push back the March 2025 deadline or soften any of the controls.
The practical takeaway is simple. If your last penetration test was scoped and reported against the old 11.3 structure, an assessor working in 2026 will not accept it as evidence. Anyone still quoting Requirement 11.3 for pen testing is working from a retired version of the standard.
What Requirement 11.4 actually asks for
Requirement 11.4 breaks down into a set of sub-requirements, and reading them in plain terms is the fastest way to understand what a compliant programme looks like.
- 11.4.1 expects a documented penetration testing methodology, built on an industry-accepted approach. NIST SP 800-115 is the usual reference point for the overall method, with something like the OWASP testing guidance informing the application side.
- 11.4.2 covers internal penetration testing, run at least once every 12 months and again after any significant change.
- 11.4.3 covers external penetration testing, on the same cadence of at least every 12 months and after significant change.
- 11.4.4 is about closing the loop, meaning that exploitable vulnerabilities the test finds have to be corrected and then retested to confirm the fix held.
- 11.4.5 requires segmentation testing at least every 12 months for any organisation that relies on network segmentation to reduce its scope.
- 11.4.6 tightens that segmentation cadence to at least every six months for service providers.
Notably, v4.0 also raised the bar on what counts as a real test. Exporting the output of an automated scanner and adding a cover page no longer passes. The internal test under 11.4.3 is now expected to be authenticated and to cover all in-scope systems rather than a convenient sample, and the report has to show the methodology that was followed. Assessors are specifically trained to spot programmes that tick a box rather than genuinely probe the environment.
Penetration testing is not the same as a vulnerability scan
This is the single most common misunderstanding we see, and it is worth dwelling on because it causes real assessment failures.
Vulnerability scanning sits under a different control, Requirement 11.3, and it is not a substitute for a penetration test. A scan is largely automated, and compares your systems against a database of known issues and flags anything that matches. External scans have to be run at least quarterly by an Approved Scanning Vendor, which is a firm the PCI Security Standards Council has authorised to perform them, and internal scans are expected on a similar quarterly rhythm.
A penetration test is a different exercise, where a qualified tester works by hand, chaining findings together, testing business logic, and attempting to reach cardholder data the way an attacker actually would. Where a scanner reports that a door looks unlocked, a penetration tester walks through it and tells you what was on the other side.
Both are mandatory, and they answer different questions. Quarterly scans give you continuous coverage of known weaknesses, while the annual penetration test tells you if those weaknesses, along with the ones a scanner cannot see, can be strung into a genuine breach. Treating one as the other is a reliable way to fail. If you want the fuller picture of how the two fit together, our penetration testing guide covers the wider discipline in depth.
Getting the scope right: your cardholder data environment
Before any testing begins, you have to define what is being tested. In PCI terms that means your cardholder data environment, usually shortened to the CDE, which is every system that stores, processes or transmits cardholder data, plus anything connected to those systems or capable of affecting their security.
Scope is where costs and outcomes are decided. A sprawling, flat network drags far more into the CDE, which makes the test larger, slower and more expensive. Many organisations deliberately shrink their scope using network segmentation, walling the CDE off from the rest of the business so that fewer systems fall inside it.
That is exactly why segmentation testing exists as its own control. If you claim a system is out of scope because segmentation keeps it away from the CDE, a tester has to prove that separation genuinely holds. A segment that can be crossed is a segment that does not reduce scope. Mapping this honestly at the start is worth the effort, and our attack surface assessment is designed to help you understand what is actually exposed before the formal test begins.
Internal versus external testing
PCI DSS penetration testing asks for both, because they model different attackers.
External testing takes the perspective of someone on the public internet with no prior access, probing your perimeter, your internet-facing applications and anything reachable from outside. It answers the question of whether an outsider can get in.
Internal testing assumes the attacker is already inside, perhaps a malicious insider, a contractor, or an outsider who has landed a foothold through phishing. It answers a harder question, which is how far someone can move once they are past the front door and how close they can get to cardholder data. Given how many real breaches begin with a single compromised laptop, this internal view often surfaces the findings that matter most.
For most environments the external side leans on network penetration testing, while the applications that touch card data are covered by web application penetration testing. A complete PCI programme usually needs both.
How often do you need to test?
The baseline is at least once every 12 months for internal and external testing alike, and that annual rhythm is the part everyone remembers.
The part people forget is the trigger that sits alongside it. A test is also required after any significant change to your in-scope systems, and that clock runs independently of the calendar. Re-platform your payment page, add a new data centre, or restructure the network, and you owe a fresh test regardless of when the last annual one happened. Waiting for the yearly slot is not an option if you have materially changed the environment in between.
Segmentation testing follows its own schedule, which is at least every 12 months for most organisations and at least every six months for service providers. Perhaps most importantly, none of these cadences overlap neatly, so it pays to map your testing calendar for the whole year rather than booking each test in isolation.
What your PCI DSS penetration testing report must contain
A test only helps your compliance if the report stands up to scrutiny. Assessors, and specifically Qualified Security Assessors, are looking for a document that proves a real test happened and that the results were acted on.
At a minimum the report needs to set out the methodology that was followed, the full scope that was tested and any segmentation checks, the findings rated by severity, and clear evidence of remediation with retesting to confirm each fix. A CVSS rating on findings is now the expected way to show severity in a way an assessor can rely on.
The reason this matters is practical because a vague report, however clean it looks, gives an assessor nothing to verify against, and a report that follows the old v3.2.1 format will be rejected outright in a current assessment. Getting the reporting right is as much a part of Requirement 11.4 as the testing itself.
How PCI DSS levels change your obligations
Not every organisation carries the same weight of assessment, and this is where PCI DSS compliance levels come in. The card brands, meaning Visa, Mastercard and the others, sort merchants into levels based on how many transactions they handle each year, and your level decides how you have to prove compliance.
As a broad guide, and the exact thresholds are set by each card brand rather than by a single universal rule:
- Level 1 covers the largest merchants, commonly those above around six million card transactions a year. These organisations face a full onsite assessment that produces a Report on Compliance, signed off by a Qualified Security Assessor.
- Levels 2 to 4 cover progressively smaller merchants, most of whom can validate through a Self-Assessment Questionnaire rather than a full onsite audit, often paired with quarterly scans.
The PCI DSS penetration testing requirement under 11.4 does not disappear as you move down the levels. What changes is the surrounding assessment machinery, meaning that a Level 1 merchant sits under far more external validation than a Level 4 one, even though both still need to test. Your acquiring bank is the right party to confirm exactly which level and which validation route applies to you.
Where Fortifi fits
PCI DSS penetration testing rewards a tester who understands the standard as well as the technical work, because a technically excellent test that ignores the reporting and scoping rules will still fail an assessment. As a CREST-accredited UK penetration testing provider, we scope against your cardholder data environment, run the internal, external and segmentation testing that Requirement 11.4 calls for, and produce reports written to satisfy a QSA rather than just to look thorough.
If card payments are core to your business, it is also worth seeing how PCI sits alongside your wider obligations. Our work in the financial services sector covers the overlapping demands many payment-handling firms face, and if you are weighing PCI against other frameworks, our guide to ISO 27001 is a useful companion.
Ready to talk through your PCI DSS penetration testing? Book a call and we will help you scope it properly.