Penetration Testing Hub › Penetration Testing Explained

Penetration Testing & PCI DSS 11.4

If your business takes card payments, PCI DSS applies, and unlike most frameworks it names penetration testing explicitly. Requirement 11.4 (in PCI DSS v4.0) is prescriptive about what testing you need and how often. This page explains what it actually asks for, so you can scope a test that satisfies your assessor rather than one that misses the mark.

What requirement 11.4 asks for

In plain terms, PCI DSS v4.0 requirement 11.4 expects:

• A defined penetration testing methodology you follow consistently.
• External and internal penetration testing.
• Testing at least annually and after any significant change to the environment.
• Testing that covers the cardholder data environment (CDE) perimeter and critical systems.
• Segmentation testing — proving that whatever separates your CDE from the rest of your network actually holds (more frequently for service providers).
• Correction of findings and re-testing to confirm they're fixed.

The exact clause numbers and service-provider specifics live in the standard itself; confirm the current version's wording, as PCI DSS is periodically revised.

Segmentation testing — the part people miss

The single most PCI-specific piece is segmentation testing. If you reduce your PCI scope by isolating the cardholder data environment from the rest of your network — which almost everyone does, because it makes compliance far cheaper — you have to prove that isolation works. A tester attempts to reach the CDE from outside its boundary. If they can, your scope reduction is invalid and your whole assessment is affected. This is where a cheap, scan-only 'pentest' fails you: it won't rigorously test segmentation.

Scope: what's actually in

PCI testing centres on the cardholder data environment and everything that can affect its security: the systems that store, process or transmit card data, plus the systems connected to them. Getting scope right is the whole game — too narrow and you fail your assessment, too wide and you pay for testing you didn't need. Segmentation is what lets you keep scope small and defensible.

How often

At least annually, and after any significant change — a new payment channel, a network redesign, a major application update. Service providers face more frequent segmentation testing. 'Annually' is a floor, not a target: if your environment changes often, test more often.

Making the test satisfy your assessor

• Use a provider who follows a recognised methodology and can state it.
• Ensure the report explicitly covers external, internal and segmentation testing.
• Keep the findings, remediation and re-test evidence together for your QSA.
• Match the testing dates to your assessment cycle so nothing is out of date.
• Confirm the tester understands PCI scope — a general pentester who's never done PCI may test the wrong boundary.

A note on right-sizing

PCI is one of the few cases where a test is genuinely required rather than advisable, so the 'do you need one yet' question doesn't apply — if you take card payments and store, process or transmit card data, you need this. What you can control is scope: the smaller and better-segmented your cardholder data environment, the cheaper and simpler every annual test becomes.

This page is educational and not legal advice. Only test systems you own or are explicitly authorised to test.  ·  ↑ Back to top