PCI DSS Penetration Testing Cost

What the requirement actually says

PCI DSS is unusually specific about penetration testing, which makes it one of the easier frameworks to budget for. Requirement 11.4 in version 4.0 breaks into distinct obligations:

• 11.4.1 - a penetration testing methodology defined and documented. This is paperwork, but it is paperwork an assessor will ask for, and it should describe the approach, the scope coverage, the testing from inside and outside, and how findings are handled.
• 11.4.2 - internal penetration testing, at least once every twelve months and after any significant infrastructure or application change.
• 11.4.3 - external penetration testing, on the same cadence and with the same change trigger.
• 11.4.4 - exploitable vulnerabilities and security weaknesses found during testing corrected, and the testing repeated to verify the correction. The retest is not optional here; it is written into the requirement.
• 11.4.5 - where segmentation is used to isolate the cardholder data environment from other networks, the segmentation controls tested at least once every twelve months.
• 11.4.6 - for service providers, that segmentation testing moves to at least once every six months.

PCI DSS versions and their dated requirements change over time. Confirm the current applicable text with your QSA rather than relying on any summary, including this one.

The three things you are actually buying

Most PCI budgeting goes wrong because people price "a penetration test" as a single item when the requirement describes three different exercises.

External testing

Attacking the perimeter from outside: internet-facing systems, remote access, anything exposed to the public network that could lead toward the cardholder data environment. Scoped by the size of the external footprint.

Internal testing

Assuming a foothold inside the network and seeing how far it goes. For most organisations this is where the serious findings are, because internal networks are usually flatter than their diagrams suggest. Scoped by host count, domain size and trust relationships. In practice this is network and Active Directory testing.

Segmentation validation

The one that gets forgotten. This is not testing the systems, it is specifically attempting to reach the cardholder data environment from networks that are supposed to be out of scope, in order to prove the isolation actually holds. It is separately required, it is the control your entire scope reduction depends on, and if you are a service provider you owe it twice a year rather than once. A failure here is expensive in a way the others are not, because it means your scope was wrong and everything out of scope may now be in it.

How scope reduction changes the price

The cheapest way to reduce PCI testing cost is to reduce the cardholder data environment itself, and that is an architecture decision rather than a procurement one. Every system that stores, processes or transmits cardholder data, and every system connected to those, is in scope. Segmentation is what keeps the rest of your estate out.

Two practical consequences. First, if segmentation is working, your tested scope is small and the testing is correspondingly inexpensive, but you must pay for segmentation validation to prove it. Second, if segmentation is not working, you do not have a testing problem, you have a scope problem, and no amount of testing budget fixes it. Finding that out during an assessment is considerably worse than finding it out during a test.

Merchants and service providers are not the same purchase

Service providers carry the heavier obligation. The six-month segmentation cadence under 11.4.6 means two engagements a year where a merchant has one, and multi-tenant service providers have further obligations around supporting their customers' own testing. If you process on behalf of others, budget for that cadence from the start rather than discovering it mid-year.

Merchants completing a self-assessment questionnaire are in a different position again. The SAQ types vary substantially in which requirements they pull in, and not all of them include 11.4. Which SAQ applies to you is determined by your acquirer or QSA, and that determination is where your answer comes from. It is worth getting in writing before you buy anything.

What it costs

Because PCI separates the exercises, it is worth pricing them the same way. An application-scope engagement starts at $500 where the in-scope environment is a single payment application. Internal and external network testing, which is where most cardholder data environments actually sit, starts at $1,500 and is scoped to host count, domain size and trust relationships. Segmentation validation is scoped alongside the internal test, since it uses the same access and the same window, which makes buying them together substantially cheaper than buying them apart.

Retesting after remediation is written into 11.4.4, and it is included in my engagements rather than billed separately, as are remediation support and the attestation letter. The PCI DSS penetration testing service page covers the methodology, penetration testing cost explains the general model, and the sample report shows what a QSA will be handed.

If SOC 2 is also in play, the two frequently share a single engagement when scoped together from the start - see SOC 2 penetration testing cost. For regional regimes that stack on top of PCI, particularly in the Gulf, compliance-driven testing covers how the overlaps work.