Penetration Testing for PCI Scope: Verdicts for 2026

Penetration testing for PCI scope isn't one test — it's four or five overlapping requirements buried inside PCI DSS 11.4, and most UK merchants either buy too little or pay for testing that sits outside their actual cardholder data environment.

Why this matters

A QSA doesn't care how good your firewall rules look on paper. They want a report proving someone tried to break through them in 2026, mapped to the exact PCI DSS requirement it satisfies.

Get the scope wrong and you pay for a test that doesn't count, then pay again for the one that does. Scoping a penetration test correctly before you sign anything is the single decision that determines whether the report survives an audit.

Who this is for

This is for merchants, payment service providers, and SaaS platforms that store, process, or transmit cardholder data and need penetration testing evidence for a PCI DSS assessment. If your cardholder data environment (CDE) includes a payment page, an API that touches card data, or a network segment carrying card traffic, this applies to you directly.

What to look for in penetration testing for PCI scope

Coverage of the full CDE, not a sample

A test that samples "representative" systems doesn't satisfy PCI DSS 11.4. Your CDE boundary, every in-scope system, and every connected segment need testing, not a convenient subset the vendor picked to save hours.

Testers who understand segmentation, not just infrastructure

A generic infrastructure tester can miss the difference between properly isolated CDE segments and segments that only look isolated on a network diagram. Ask for CREST or OSCP-qualified testers with documented PCI DSS project history.

A report mapped to PCI DSS requirement numbers

A report that says "3 critical, 5 high, 12 medium" without mapping findings to 11.4.1 through 11.4.5 forces your QSA to do that mapping themselves — and QSAs bill by the hour for that.

Retest included, not an upsell

PCI DSS expects critical and high findings remediated and retested before the assessment closes. If retesting isn't in the original quote, you're paying twice for one requirement.

Segmentation testing as a distinct line item

Segmentation testing verifies that out-of-scope systems genuinely can't reach the CDE. It's a different exercise from a network penetration test and needs its own scope statement in the engagement letter.

Timing that survives your renewal cycle

PCI DSS 11.4.1 requires annual external and internal testing at minimum, plus testing after any significant change to the CDE. A vendor who can't turn a report around inside your assessment window isn't the right fit regardless of price.

Top picks: penetration testing for PCI scope by test type

External network penetration test — the mandatory baseline. This targets everything internet-facing that touches your CDE: firewalls, VPN endpoints, exposed services. PCI DSS 11.4.1 requires it annually at minimum. Verdict: Buy — there's no version of PCI compliance without this.

Internal network penetration test — the overlooked half. Attackers who get past your perimeter or arrive via a compromised laptop move laterally inside the network. An internal network penetration test checks whether they can reach the CDE from inside. Most SMEs budget for external only and get flagged in review for it. Verdict: Buy.

Web application penetration test — the one merchants skip. If your payment flow runs through a hosted page or your own checkout, application-layer flaws (injection, broken auth, insecure API calls) are the most common route into cardholder data in 2026. A web application penetration test covers what a network scan never will. Verdict: Buy if any part of your CDE is customer-facing.

Cloud infrastructure test — the wildcard for SaaS platforms. If your CDE runs on AWS or another cloud provider, misconfigured security groups and IAM roles are a bigger risk than the underlying network stack. Cloud-hosted CDEs need a tester who understands cloud-native attack paths, not a rebadged on-prem methodology. Verdict: Consider — mandatory if any CDE component is cloud-hosted, otherwise skip this line item.

Segmentation test — the scope-shrinker. Done right, this proves systems you've marked out-of-scope genuinely can't reach the CDE, which shrinks the size (and cost) of everything else you test. Done wrong, it gives you false confidence that a flat network is actually segmented. Verdict: Buy — the ROI shows up in every future test's reduced scope.

What to avoid

• Vulnerability scans marketed as penetration testing. An automated scan finds known CVEs; it doesn't attempt exploitation or chain findings the way a manual tester does. QSAs reject scan-only reports against 11.4 requirements routinely.
• Testers with no PCI-specific experience. A tester who's never scoped a CDE will miss segmentation nuances that a generalist infrastructure test wasn't built to catch.
• Reports without a remediation timeline. A report that lists findings without severity-based remediation deadlines leaves you guessing what your QSA will actually flag.

Verdict comparison

One last thing

Segmentation testing is the line item most merchants cut to save money, and it's the one that quietly doubles the cost of everything else. A CDE that isn't properly segmented means every connected system becomes in-scope for every future test — external, internal, application, all of it.

Get segmentation right once and every subsequent 11.4 test gets smaller, faster, and cheaper. That's the whole point of Seriously Simple Cyber Compliance: fix the thing that compounds, not the thing that's loudest.

Related guides

• E-commerce and Shopify store penetration testing
• Best PCI DSS compliance software for UK online retailers