How I Scope a PCI DSS Penetration Test So It Holds Up in Your QSA Review

Most PCI penetration tests that cause trouble at assessment time don't fail because the testing was weak. They fail because the scope was wrong: a payment API left out, a segmentation control nobody tested, a cloud account that wasn't on the network diagram. By the time your QSA finds the gap, the testing window is closed and the report can't be fixed with a rewrite.

I'm Marcello Duarte, and I scope and lead PCI DSS penetration tests at Radical Security. This is the process I use to make sure the test we run is the test your assessment actually needs, and how we put that in writing before any work starts.

Start with the assessment, not the test

The first question I ask isn't "what do you want tested?" It's "how are you being assessed?" The answer changes what Requirement 11.4 asks of you:

• Report on Compliance (ROC) or SAQ D. The full set of penetration testing requirements applies: internal testing, external testing, segmentation testing if you rely on segmentation, and remediation retesting.
• Other SAQs. Some include parts of 11.4 and some include none of it. If you're not sure which questionnaire you're on, start with choosing the right PCI SAQ before paying for a test you may not need.
• Service providers. Segmentation testing moves from every 12 months to every six months under 11.4.6, and multi-tenant providers have extra obligations under 11.4.7.

If you have a QSA, I'd much rather hear their expectations at the start than at the end. When a client is comfortable with it, I'll talk to their assessor directly during scoping. It's a short call that saves everyone weeks.

What Requirement 11.4 actually requires

PCI DSS v4.0.1 is specific about what a penetration testing program has to include. Requirement 11.4.1 says the methodology must:

• Follow industry-accepted penetration testing approaches.
• Cover the entire CDE perimeter and critical systems.
• Test from both inside and outside the network.
• Test to validate any segmentation and scope-reduction controls.
• Include application-layer testing covering, at minimum, the vulnerabilities listed in Requirement 6.2.4.
• Include network-layer testing of all components that support network functions, as well as operating systems.
• Consider threats and vulnerabilities experienced in the last 12 months.
• Define how exploitable vulnerabilities and security weaknesses are assessed and addressed.
• Retain results and remediation activities for at least 12 months.

Then 11.4.2 and 11.4.3 require internal and external testing at least once every 12 months and after any significant infrastructure or application change, performed by a qualified tester with organizational independence. 11.4.4 requires exploitable findings to be fixed and the testing repeated to verify the fixes. Every item on that list has to show up somewhere in scope, or it won't show up in the report.

The scoping inputs I ask for

A good PCI scope is built from your own scoping documents, not from a list of IP addresses someone exported. Before I write a proposal, I ask for:

1. Your cardholder data flow diagram. Where card data enters, where it moves, where it's stored and where it leaves. Every hop is a candidate for testing.
2. Your network diagram and segmentation design. Which firewalls, ACLs, VLANs, security groups or host-based controls separate the CDE from everything else. These are what segmentation testing has to prove.
3. Your system inventory for the CDE and connected-to systems. Including the shared services people forget: Active Directory, jump hosts, logging, patch management and backups.
4. The applications in scope. Payment pages, APIs, admin portals and anything else that handles or can affect cardholder data. Application-layer testing is mandatory, and it's the area most often under-scoped.
5. Changes since your last test. New infrastructure, migrations, new payment flows. Significant changes trigger testing requirements of their own.
6. Last year's report and findings. 11.4.1 expects the methodology to consider threats and vulnerabilities from the last 12 months, and I want to retest anything that was found before.

If some of those documents don't exist yet, that's useful to know early. It usually means the scoping work in shrinking your cardholder data environment needs to happen first.

Internal, external and application testing

I scope each part of 11.4 as its own line item so nothing gets folded away:

A vulnerability scan is not a substitute for any of these. Scans belong under Requirement 11.3, alongside ASV scans and authenticated internal scanning. Penetration testing under 11.4 has to show what an attacker could actually do.

Writing down the acceptance criteria

This is the step I think matters most, and it's the one that's most often skipped across the industry. Before testing starts, we agree in writing on:

• The exact scope: hosts, ranges, applications, cloud accounts and segmentation boundaries, each tied to the 11.4 requirement it satisfies.
• The methodology: which industry-accepted approach we follow and how it maps to 11.4.1.
• What the report will contain: the sections your assessor will look for, which I cover in detail in what a PCI pentest report needs.
• The retest: how and when we'll verify your fixes, and that the retest is included in the price.
• What "done" means: a final report that covers everything in the agreed scope, a retest letter for remediated findings, and time to answer your QSA's questions about the work.

When both sides have signed off on that list, there's very little room for a surprise at the end. If your QSA has requirements beyond the standard, such as a particular report format or extra evidence, this is where they go.

How we price it and when you pay

Every PCI engagement gets a fixed price based on the written scope. We never ask for money up front, and you pay only once the work is complete. Every engagement is also backed by our 100% money-back guarantee: if you're not satisfied, tell us within 30 days of the final report and you choose whether we fix it at no cost (more testing, a retest or a revised report) or refund every dollar.

I mention this in a post about scoping because the two are connected. We can offer that guarantee because the scope and acceptance criteria are agreed in writing first. You can read more about why we work this way in No Upfront Payment, No Cold Calls and why we back every engagement with a guarantee.

Key takeaways

• Scope the test to your assessment type first: ROC, SAQ D, other SAQs and service providers all have different 11.4 obligations.
• Build scope from your data flow diagram, network diagram and CDE inventory, including connected-to systems and shared services.
• Scope internal, external, application-layer, segmentation and retest work as separate items so none of them gets dropped.
• Agree on scope, methodology, report contents, retest and what "done" means in writing before testing starts.
• At Radical Security, you pay only once the work is complete, and every PCI engagement is covered by our 100% money-back guarantee.