PCI Segmentation Testing: Who Needs It and How Often?

If you use network segmentation to reduce PCI DSS scope, you have to prove the segmentation works, and the proof is a penetration test. Requirement 11.4.5 requires that test at least once every 12 months and after any change to segmentation controls or methods; Requirement 11.4.6 tightens the same obligation to at least once every six months for service providers, which means two engagements a year rather than one. The test is narrower than a full penetration test and correspondingly smaller: its single objective is to confirm that systems outside your cardholder data environment cannot reach systems inside it. And it carries a consequence most buyers do not price in, because a failed segmentation test does not just produce a finding, it expands your assessment scope to include everything the tester reached.

What follows: what the test actually does, which cadence binds you, why service providers are the group most often caught out, who is allowed to perform it, and what it costs you when it fails.

Key takeaways

• Segmentation testing is required only if you rely on segmentation to reduce scope. If your whole network is in scope, the requirement does not apply and buying the test is wasted money.
• Requirement 11.4.5 sets the cadence at least every 12 months plus after any change to segmentation controls; 11.4.6 makes it every six months for service providers.
• It does not replace the internal and external penetration tests required by 11.4.2 and 11.4.3. It is a third, narrower engagement.
• A failed test expands your assessment scope to whatever the tester reached, which is the expensive outcome, not the finding itself.
• The tester must be qualified and organizationally independent from the team that manages the systems under test, and PCI DSS does not require that person to be a QSA.

What a segmentation test actually proves

Scope reduction is the single largest lever in a PCI budget. Assessment effort scales with the number of system components in the cardholder data environment, so companies isolate that environment behind firewalls, VLANs, access control lists and cloud security groups, and then assess only what remains inside.

That reduction is a claim about your network. A segmentation test is the evidence for the claim.

The exercise is deliberately narrow. A tester is placed on each out-of-scope network segment in turn and attempts to reach the cardholder data environment from there: enumerating what is reachable, testing whether the isolation controls behave as documented, and probing the paths that documentation tends to miss. Management networks. Jump hosts. Backup infrastructure that touches both sides. Monitoring agents with credentials in both zones. Shared authentication. A cloud security group that permits an entire virtual private cloud because someone was debugging in 2024.

The pass condition is boring and absolute: no traffic that should be blocked gets through, and the isolation is confirmed from every out-of-scope segment rather than from one representative sample.

The two cadences, and which one is yours

Requirement 11.4.5 applies to any entity that uses segmentation to isolate the cardholder data environment from other networks. Testing runs at least once every 12 months and after any changes to segmentation controls or methods, and it must confirm that the segmentation is operational and effective, isolating all out-of-scope systems from systems in the cardholder data environment.

Requirement 11.4.6 applies to service providers and sets the interval at least once every six months, with the same after-change trigger.

Note that the after-change trigger is not the annual clock in disguise. A firewall rule change that touches a scope boundary is a testing event on its own, and it is the one companies forget, because the change goes through a change advisory board that has no reason to think about PCI testing obligations. Write the trigger into your change process rather than into a compliance calendar. Requirement 11.4.1 already requires a documented methodology including a written definition of significant change, so the definition exists; the work is connecting it to the people who approve changes.

The full 11.4.x family, including the internal and external cadences, is set out in how often should you do penetration testing, which is the canonical page on this site for the whole family.

Why service providers get caught out

The six-month cadence is the single most missed obligation in the requirement family, for a structural reason: many companies do not know they are service providers.

The Council's definition covers any business entity, other than a payment brand, directly involved in the processing, storage or transmission of cardholder data on behalf of another entity, and it reaches entities that can affect the security of that data without touching it. A hosted checkout component rendered on a customer's payment page qualifies. So does administering the infrastructure where a customer's cardholder data environment runs. We treat the classification question in full in merchant or service provider, and it is worth settling before you build a testing calendar, because the answer doubles the cadence.

There is a second obligation that lands specifically on multi-tenant providers. Requirement 11.4.7 requires multi-tenant service providers to support their customers for external penetration testing under 11.4.3 and 11.4.4. In practice that means having a written process for customer testing requests, and answering them in less time than the customer's audit deadline allows. Vendors that have not thought about it discover the requirement through an angry customer email.

What it is not: a substitute for the other tests

Segmentation testing sits alongside the internal and external penetration testing required by 11.4.2 and 11.4.3. It does not replace either.

The confusion is understandable, because the segmentation test is performed from internal network positions and looks superficially like an internal penetration test. The objectives are different. An internal penetration test asks how far an attacker inside your network gets, across the whole environment, exploiting what it finds. A segmentation test asks one question about one boundary and stops. It is not a coverage exercise, and a report that reads like one has probably been mis-scoped.

The related mix-up is between the 11.3.x scanning requirements and the 11.4.x testing requirements, which is expensive in both directions and which we cover in PCI ASV scans explained. A QSA will not accept a scan report as evidence for 11.4, and will not accept a penetration test report as evidence for 11.3.2.

Because the objective is narrow, the engagement is narrow: fewer days, less reporting, and a scope document that fits on a page. That is also why it is easy to under-buy. A segmentation test that samples one out-of-scope segment out of six has tested one sixth of your claim.

Who is allowed to perform it

PCI DSS requires that testing be performed by a qualified internal resource or a qualified external third party, and that organizational independence of the tester exists, which does not require the tester to be a QSA.

Read both halves of that. You may use internal staff, and plenty of larger organizations do. The independence condition is what constrains it: the person testing the segmentation cannot be the person who configures and manages the firewalls and network controls under test. Someone auditing their own configuration will unconsciously test the paths they designed and miss the ones they did not think of, which is the entire failure mode the requirement exists to prevent.

Requirement 11.4.1 also requires the testing to follow an industry-accepted methodology, which in practice means PTES, NIST SP 800-115 or an equivalent named standard, documented before the test rather than described afterward. The PCI Security Standards Council's own penetration testing guidance information supplement, available in its document library, is the reference most assessors expect a methodology to align with.

What a failed test actually costs

This is the part worth understanding before you treat the test as a formality.

If the tester crosses from an out-of-scope network into the cardholder data environment, the segmentation claim fails, and the systems that provided the path are in scope. Your assessment now covers more system components than the one you budgeted, and every PCI DSS requirement applies to each of them. That is not a finding to remediate at leisure; it is a change to the size of your assessment, discovered at whatever point in the year the test happened to run.

The second-order cost is the timing. Companies schedule segmentation testing close to their assessment, which is exactly when there is no time to remediate a boundary failure and retest. Requirement 11.4.4 requires exploitable findings to be corrected and verified by repeat testing, so a failure late in the cycle means a fix, a retest and a delayed assessment.

The mitigation is unglamorous: test the segmentation early in the cycle, not as the last box before the assessor arrives, and test it again after any change that touches a boundary. Service providers running the six-month cadence get this for free, which is one of the few advantages of the tighter interval.

When you should not buy this test

If you do not use segmentation to reduce scope, you do not need a segmentation test. A small merchant whose entire network is in scope, or a company that has outsourced card handling so completely that no cardholder data environment exists on its own systems, is not covered by 11.4.5 and should not be sold the engagement. The right question is which SAQ applies, which is covered in which PCI SAQ do I need.

If your segmentation exists only on a diagram, the honest first purchase is not a test either. A test will confirm that the diagram is wrong, at testing rates. Fix the controls, verify them yourself, then buy the independent test that proves it.

And if a firm quotes a segmentation test at the price of a full penetration test, ask what is in the scope. The objective is narrow by design, and a quote that does not reflect that is either mis-scoped or is quietly bundling the 11.4.2 internal test into the same number.

Where Top Floor fits

Top Floor is not a QSA firm and does not issue attestations. What we do under PCI DSS is the scope work that sits underneath this requirement: mapping the cardholder data environment, arguing the segmentation boundary, and finding the paths that would fail a test before an assessor's tester does.

Our penetration testing practice runs the 11.4.x engagements themselves, including segmentation testing scoped from every out-of-scope segment rather than a representative sample, with a methodology named in writing and a retest included.

How to decide this week

Answer one question first: do you rely on segmentation to keep systems out of PCI scope? If not, stop here and check your SAQ eligibility instead.

If yes, find the date of your last segmentation test and your service provider status. Twelve months and merchant means you are on the annual clock. Service provider means six months, and if the last test was more than six months ago, that engagement is already overdue.

Then pull your network diagram and count the out-of-scope segments that could plausibly reach the cardholder data environment, including management, backup and monitoring networks. That count is what the scope document should list. If your last test covered fewer segments than your diagram shows, you have your answer about whether it proved anything.

Frequently asked questions

How often is PCI segmentation testing required?

At least once every 12 months, and after any changes to segmentation controls or methods, under PCI DSS Requirement 11.4.5. Service providers are held to at least once every six months under Requirement 11.4.6, with the same after-change trigger. The after-change trigger is the one most often missed, because a firewall or security group change that touches a scope boundary creates a testing obligation independently of the calendar. The requirement applies only to entities that use segmentation to isolate the cardholder data environment from other networks; if everything is in scope, there is no segmentation claim to prove.

Does a segmentation test replace the annual penetration test?

No. Segmentation testing under 11.4.5 and 11.4.6 is a separate obligation from the internal penetration testing required by 11.4.2 and the external penetration testing required by 11.4.3. It has a single narrow objective, confirming that out-of-scope systems cannot reach the cardholder data environment, and it stops there rather than exploring what an attacker could achieve once inside. A QSA reviewing your evidence will expect to see all three, and a segmentation test presented as satisfying 11.4.2 will be rejected.

Who can perform PCI segmentation testing?

A qualified internal resource or a qualified external third party, with organizational independence from the team that manages the systems being tested. PCI DSS does not require the tester to be a QSA or an approved scanning vendor. The independence condition is the operative constraint: the engineer who configures the firewalls and security groups enforcing your segmentation cannot be the person who tests them, because testing your own configuration tends to exercise the paths you designed and miss the ones you never considered. The testing must also follow a documented, industry-accepted methodology under Requirement 11.4.1.

What happens if the segmentation test fails?

The systems that provided the path into the cardholder data environment come into scope, which means every PCI DSS requirement applies to them and your assessment covers more components than you budgeted for. Requirement 11.4.4 then requires the exploitable finding to be corrected and the correction verified by repeating the test. The practical damage is usually schedule rather than remediation effort, because companies tend to run segmentation testing shortly before an assessment, leaving no room to fix a boundary failure and retest. Running the test early in the compliance cycle, and again after any change touching a boundary, is the cheapest insurance available against that outcome.