PCI DSS Penetration Testing: Requirement 11.4, Segmentation, and the Significant-Change Trap

What PCI DSS penetration testing is

Most compliance frameworks make you infer that they want a test. PCI DSS does not. It says so, in print, with a requirement number.

PCI DSS penetration testing is the testing you run to satisfy the Payment Card Industry Data Security Standard, which applies to anyone who stores, processes or transmits cardholder data. If you take card payments, this framework applies to you, and unlike SOC 2 or HIPAA it does not leave the test to interpretation. It names penetration testing as a requirement and describes what that testing must include.

It names the test. That directness is oddly a relief. With PCI DSS penetration testing there is far less arguing about whether a test is needed, and far more clarity about what “done” looks like. The trade is that the requirements are specific, and a QSA — the Qualified Security Assessor who signs off your compliance — will check them against your evidence line by line.

So the goal here is not to convince you a test is required. It plainly is. The goal is to make sure your PCI DSS penetration testing covers everything the standard asks for, in the form the assessor accepts, on the cadence it demands — including the cadence most teams forget.

Requirement 11.4, in plain language

Under PCI DSS v4.0, penetration testing lives in Requirement 11.4. Stripped of the sub-clause numbering, it asks for a handful of concrete things.

A documented methodology, so testing is repeatable and not improvised. External penetration testing, from the internet in. Internal penetration testing, from inside the network out. Correction of exploitable vulnerabilities found, followed by a retest to confirm the fix. And, for organisations relying on segmentation, testing that the segmentation controls actually isolate the cardholder data environment.

That is the spine of PCI DSS penetration testing: methodology, external, internal, fix-and-retest, segmentation. Each is a place a QSA can mark you down if the evidence is missing or thin. None of them is satisfied by a vulnerability scan alone — PCI treats scanning and penetration testing as separate activities, and expects both.

External vs internal testing

PCI DSS penetration testing has to happen from both sides of the perimeter, and the two tell you different things.

External testing takes the attacker’s default position: the internet. It probes the systems exposed to the outside world — the payment pages, the APIs, the infrastructure with a public address — for a way in. This is the test that mirrors how most breaches start.

The two are not interchangeable, and doing one twice does not substitute for the other. Internal testing assumes the attacker already got a foothold, because attackers do. It tests what someone can reach and do once inside the network: whether they can move toward the cardholder data environment, escalate privileges, or pivot between systems. Skipping internal testing assumes your perimeter never fails, and the entire premise of PCI DSS penetration testing is that you cannot assume that.

Together they answer the two questions that matter: can someone get in, and how far can they go once they have. A test that does only the first leaves the more damaging half of the story untold.

Segmentation testing: the PCI-specific one

This is the requirement unique to PCI, and the one that trips up teams who use segmentation to shrink their scope.

Segmentation is the most common way to make a PCI assessment smaller, and the most common way to get one wrong. The logic is sound: if you isolate the cardholder data environment behind strict network segmentation, systems outside that segment fall out of PCI scope, and your assessment gets smaller and cheaper. But there is a condition. You have to prove the segmentation actually works. If a supposedly isolated segment can, in fact, reach the cardholder data environment, then your scope reduction was fiction and everything you excluded was in scope all along.

So PCI DSS penetration testing includes segmentation testing: actively trying to cross from an out-of-scope segment into the cardholder data environment. Merchants must do this at least annually; service providers, every six months. It is not optional if you rely on segmentation, and a QSA will ask for it specifically, because a broken segment quietly re-expands your entire scope.

The significant-change trap

Here is the clause that turns a passed audit into a failed one six months later.

PCI DSS penetration testing is required at least annually and after any significant change to the environment. A significant change means what it sounds like: a new system in the cardholder data environment, a major upgrade, a new network path, a substantial change to the application handling card data. When one happens, the annual test you ran in January does not cover it. You owe a fresh test tied to that change.

Read that clause again, because it is the one that quietly ends compliance between audits. The trap is that “significant change” happens far more often than once a year for any team that ships regularly. Each one resets a clock most organisations are not watching. They test in January, ship a major change in May, and quietly fall out of compliance until someone notices — usually the QSA, at the worst possible moment.

Scoping around the cardholder data environment

Scope in PCI DSS penetration testing starts and ends with one thing: the cardholder data environment, or CDE.

The CDE is everything that stores, processes or transmits cardholder data, plus everything connected to or able to affect it. That last part is where scope quietly grows. A jump box that admins use to reach the CDE is in scope. A logging system that receives data from it is in scope. A shared authentication service is in scope. The CDE is rarely as small as people first draw it. It grows quietly. Assume it is bigger than your diagram.

This is why enumeration matters before scoping. You cannot draw a boundary around systems you have forgotten you run, and the forgotten ones — an old subdomain, a decommissioned-but-still-live server — are exactly where an attacker pivots toward the CDE. Our free security checks guide helps you see your real surface before you commit to a scope you cannot defend.

The methodology a QSA expects

PCI DSS penetration testing requires a documented methodology, and the standard points at industry-accepted approaches rather than inventing its own.

In practice that means a test built on recognised methodology — the kind described in the OWASP testing guides and NIST’s technical assessment guidance — covering reconnaissance, discovery, exploitation of found vulnerabilities, and a clear write-up of impact. The assessor wants to see that the test was systematic, not a tool run once with the defaults.

The methodology also has to include the correction-and-retest loop. Finding an exploitable vulnerability is not the end of PCI DSS penetration testing; correcting it and demonstrating through a retest that the correction worked is. A report that lists findings without evidence they were fixed and re-verified is an incomplete deliverable in PCI terms.

Common findings in PCI DSS penetration testing

The findings that recur in PCI DSS penetration testing are rarely exotic, which is what makes them dangerous — they are easy to overlook and easy to exploit.

Segmentation that leaks is the headline one. A firewall rule that is more permissive than the diagram claims, a management network that can reach the CDE, a forgotten path between segments. These matter enormously because they silently re-expand scope.

Then the familiar set: default or weak credentials on a system inside scope, unpatched services exposed to the internet, injection flaws in the payment application, and over-privileged accounts that turn a small foothold into CDE access. The value of PCI DSS penetration testing is proving that a given weakness actually reaches cardholder data, not merely that it exists in isolation — because a vulnerability that cannot reach the CDE is a different priority from one that can.

How to prepare for PCI DSS penetration testing

Preparation decides whether the test is smooth or painful. It is mostly unglamorous work done before anyone touches a keyboard in anger. Do it well and PCI DSS penetration testing becomes a formality. Skip it and the test spends its budget rediscovering things you already knew.

Get your scope documented first. Draw the cardholder data environment, list every connected system, and write down why each in-scope item is in scope. A QSA respects a defended boundary. They distrust a convenient one.

Confirm your segmentation before the test, not during it. If you rely on segmentation to shrink scope, know exactly which controls enforce it. The test will try to cross them. You want to know the answer first.

Agree the remediation path up front. Findings will appear. Someone has to fix them, and someone has to retest. Decide who, and how fast, before PCI DSS penetration testing starts, so the fix-and-retest loop does not stall waiting for an owner.

And close the obvious doors early. There is no point spending a skilled tester’s time on default passwords and missing patches. Run our free security checks first. Fix the easy things. Let the real test spend its budget on the findings that actually need an adversary to reach.

What PCI DSS penetration testing will not do

It is worth being honest about the limits, because they shape how you use the test.

A passed test is not a guarantee. It describes a defined scope during a defined effort. Something outside that scope is not covered. Something introduced the day after is not covered either. This is the whole reason PCI bolts a significant-change clause onto the annual cadence.

The test also does not maintain your compliance for you. PCI DSS penetration testing is one requirement among many. Firewalls, access control, logging, key management and the rest all sit alongside it. A clean test with weak controls elsewhere still fails.

And it does not fix anything by existing. The finding is a diagnosis. The fix is the cure. The retest is the proof. Teams that expect the report to improve their security are disappointed. Teams that treat it as the start of a loop get the value. A QSA can tell which kind you are from the evidence.

Cadence, and why annual is a floor

PCI sets the cadence more firmly than any other framework: at least annually, plus after significant change, plus segmentation testing on its own schedule. Three overlapping clocks. Most teams watch only one of them.

But “at least annually” is a floor, and PCI’s own significant-change clause admits it. The standard already acknowledges that a year is too long between tests when the environment moves, which is why it bolts on the after-change requirement. For any team shipping regularly, the honest reading is that PCI DSS penetration testing needs to keep pace with change, and change does not happen annually.

The truth is, meeting the significant-change requirement reliably with scheduled manual tests is hard. You have to notice every significant change, decide it qualifies, book a test, and complete it — every time. Miss one and you are out of compliance without knowing. This is the practical case for continuous testing, and PCI’s own structure points straight at it.

How SelfHack AI covers the significant-change gap

SelfHack AI is an autonomous penetration testing platform, and for PCI DSS penetration testing it targets the exact clause teams struggle with: significant change.

Because it tests continuously, a change to the cardholder data environment gets tested as it ships, not whenever someone remembers to book an engagement. The after-change requirement stops being a thing to track manually and becomes a property of how testing already works. A new system, a new path, a new version — all tested because everything is.

It also keeps segmentation honest. Continuous testing can repeatedly attempt to cross from out-of-scope segments into the CDE, so a segmentation control that quietly breaks is caught in days, not at the next six-month check. And it produces the fix-and-retest evidence PCI requires, as a standing record rather than a one-off document.

None of this removes your QSA or the value of a skilled human engagement — keep those for depth and sign-off. It removes the gap between scheduled tests, which is where the significant-change trap lives. See how the platform compares in our AI pentest tools overview, and how PCI fits the wider picture in the compliance penetration testing hub.

Related compliance testing

PCI rarely stands alone. A company taking card payments usually needs other reports too, and the same testing capability serves them. Building PCI DSS penetration testing once, as a continuous programme, means the next framework is mostly a matter of re-framing evidence you already produce — not starting over.

If customers ask for a SOC 2 report, SOC 2 penetration testing covers overlapping ground with different framing. If you handle health data alongside payments, HIPAA penetration testing applies. If you sell internationally, ISO 27001 penetration testing is the global equivalent. One programme, several audits. That is the efficient way to run compliance, and it starts by treating PCI DSS penetration testing as a capability rather than a yearly purchase.

FAQ

Is penetration testing mandatory for PCI DSS?

Yes. Unlike some frameworks, PCI DSS names penetration testing as a requirement under Requirement 11.4, including external, internal and — where segmentation is used — segmentation testing. It is not something you can satisfy with a vulnerability scan alone; PCI treats those as separate activities and expects both. Confirm the specifics for your level and version with your QSA.

How often is PCI DSS penetration testing required?

At least annually and after any significant change to the environment. Segmentation testing is required annually for merchants and every six months for service providers. The after-change requirement is the one teams miss most, because significant changes happen far more often than once a year.

What counts as a significant change?

PCI leaves the exact definition to you to document and defend, but it generally means a change that could affect the security of the cardholder data environment — a new in-scope system, a major upgrade, a new network path, or a substantial change to the payment application. When one happens, PCI DSS penetration testing tied to that change is required on top of the annual test.

Does PCI DSS penetration testing need an external tester?

PCI allows a qualified internal resource or an external one, but the tester must be organisationally independent of the systems being tested and demonstrably qualified. Many organisations use an external party for the independence it gives the evidence. What the QSA checks is qualification, independence, methodology and the fix-and-retest loop.

What is the difference between a PCI scan and a PCI penetration test?

A scan (an ASV scan for external-facing systems) is automated and lists potential vulnerabilities. PCI DSS penetration testing is a deeper, methodology-driven exercise that proves what an attacker can actually do, including crossing segmentation and chaining findings toward the CDE. PCI requires both; they are not interchangeable. A common and expensive misunderstanding is to run the quarterly ASV scan, see it pass, and assume PCI DSS penetration testing is therefore covered. It is not. The scan and the test answer different questions, and the QSA expects evidence of each.

The verdict

PCI DSS penetration testing is the most clearly defined of the compliance tests, which makes the requirements easy to read and the significant-change trap easy to fall into anyway.

Every framework has a clause teams underestimate. For PCI, it is significant change. External, internal, segmentation, methodology, fix-and-retest — get those right and the annual audit is straightforward. The gap is between audits, where every significant change quietly resets a clock most teams do not watch. Continuous testing closes that gap by making “test after change” the default instead of a task to remember.

There is a cost argument too. Manual PCI DSS penetration testing priced per engagement, repeated after every significant change, adds up fast — and skipping the after-change tests to save money is how compliance quietly lapses. Continuous testing spreads the cost and removes the temptation to skip. You test everything because testing everything is simply how the platform works.

If you would rather cover the significant-change requirement automatically than track it by hand and hope, talk to us.

Sources & methodology: testing methodology references the OWASP Web Security Testing Guide and NIST SP 800-115. PCI DSS requirements (Requirement 11.4 and segmentation testing cadences) are summarised from PCI DSS v4.0; the authoritative source is the current standard text and your QSA’s interpretation. General guidance, not legal or audit advice. Only test systems you own or are authorised to test.