What does PCI DSS require for penetration testing?

Unlike SOC 2 or ISO 27001, PCI DSS flatly requires a penetration test. Requirement 11.4 mandates internal and external tests every 12 months and after significant changes, a retest to verify fixes, and segmentation tests every 6 months for service providers. What it does not require is a QSA, an ASV, or an outside firm.

On this page: what 11.4 says · the mandatory retest · who may test · service providers · scans are separate · what it costs · why teams fail it

What Requirement 11.4 actually says

Most pages about PCI penetration testing paraphrase a paraphrase. The requirement itself is short and unambiguous, and you can download the standard from the PCI SSC document library to read it in full. Here is the structure:

Two things in that table surprise people. The cadence is not simply annual: “after any significant infrastructure or application upgrade or change” means a re-architecture in March obliges a test in March, not next January. And 11.4.4 makes the retest part of the requirement, not an upsell.

What counts as a significant change

The standard leaves this to you, which teams read as permission to ignore it. Your QSA will not. In practice, treat a new external service, a change to authentication or authorization, a move between cloud accounts or regions, a new component inside the cardholder data environment, or a change to segmentation as significant, and write that definition into the 11.4.1 methodology document before an assessor writes it for you. Deciding after the fact looks like a decision made to avoid a test.

The retest is mandatory, and usually unpriced

Requirement 11.4.4 is the clause that quietly doubles engagements. CompliancePoint, a QSA, quotes it as:

Exploitable vulnerabilities and security weaknesses found during penetration testing are corrected as follows…

with corrections risk-ranked through your Requirement 6.3.1 process, and testing repeated to verify them. Schellman, another QSA, is blunt about what that means in practice: after fixing, “you’ll of course need to have another pen test performed, also called a retest.” A remediation with no documented retest does not satisfy 11.4.4.

Most firms bill that retest separately at 10 to 25 percent of the original fee, so the honest annual number is higher than the quote you were given. The full cost breakdown is here. Continuous testing sidesteps the issue structurally: if the test never stops, the fix gets re-attacked as a matter of course rather than as a change order.

Who is actually allowed to test

This is where most vendor content overstates the requirement, and where a QSA-literate CTO will catch you.

PCI DSS asks for a tester who is “qualified by experience or training” and who has organizational independence from the systems being tested. It does not ask for a certification. The parenthetical:

(not required to be a QSA or ASV)

appears repeatedly through Requirement 11.4 and the SAQs. Testing may be performed by a qualified internal resource or a qualified external third party.

Why independence still pushes the test outside

Organizational independence is the real constraint, and it is stricter than it sounds: the tester cannot assess systems they build, run, or maintain. At seed and Series A, with one platform team, there is no internal resource who clears that bar, so the test goes outside for structural reasons rather than regulatory ones. That is a more honest argument than claiming PCI demands a third party, and it survives contact with someone who has read the standard.

What your QSA will actually read

The methodology document from 11.4.1, and the evidence. Reviewers look for scope coverage of the whole cardholder data environment perimeter, testing from inside and outside, application-layer and network-layer work, findings that are validated as genuinely exploitable, and the retest. That is the same bar described in our methodology pages, and it is why an unvalidated scanner dump fails review no matter who ran it.

Service providers owe roughly double

If you sell software that sits inside someone else’s cardholder data environment, three things change:

• 11.4.6 puts segmentation testing on a 6-month clock instead of the annual cadence merchants get.
• 11.4.7 obliges multi-tenant providers to support their customers’ external testing. You inherit an obligation to enable testing you do not control or schedule.
• Level 1 starts at 300,000 transactions a year, roughly 822 a day, counted across all your customers combined rather than per customer. A Series A fintech crosses into full QSA-assessed territory earlier than founders expect.

Counted honestly, a segmented service provider owes at least four penetration tests a year (internal, external, and two segmentation tests), plus every retest, plus four quarterly ASV scans.

ASV scans are a different obligation

Requirement 11.3.2 requires external vulnerability scans every 90 days by a PCI SSC Approved Scanning Vendor, and unlike almost everything else in v4.x it cannot be met through the customized approach. This is the one place PCI truly does mandate a certified outside party.

It is also the most common confusion in the market: a passing quarterly ASV scan is not evidence for 11.4. Scans enumerate known vulnerabilities; a penetration test exploits them and chains them. The difference in what each one finds is the whole reason the standard has both, and the customized approach objective for 11.4.1 is framed around resisting a competent manual attacker rather than a tool.

What this costs in practice

For a typical segmented environment, budget $8,000 to $30,000 a year across the internal test, the external test, segmentation testing, and retests, with ASV scanning billed separately. Our own numbers are public and the full market bands are here:

Where the money actually goes

The cost driver you actually control is scope. Every system that can affect the security of the cardholder data environment is in scope, so segmenting aggressively and keeping card data out of your own systems shrinks the testable surface and the bill with it. That work pays for itself in the first assessment.

Why this is the requirement teams fail

Requirement 11 has been the worst-performing requirement in PCI for years. Reporting on Verizon’s Payment Security Report, SecurityWeek summarised it plainly:

Requirement 11 continues to lag at the back of the pack when it comes to full compliance

with the widest control gap of any requirement. The same body of research produced the line worth keeping in mind before treating this as paperwork:

At the time of a breach, no organization was compliant across all 12 PCI DSS requirements.

The pattern behind the failures is consistent: teams test once a year, re-architect in month four, and never test again, which fails the significant-change clause. Or they remediate and never document a retest, which fails 11.4.4. Both are cadence problems, not capability problems, which is the argument for testing continuously rather than annually. It is also why we publish our benchmark results rather than asking anyone to take the cadence claim on faith.

The short version

• PCI DSS genuinely requires penetration testing, unlike SOC 2: internal and external, every 12 months and after significant change.
• The tester needs organizational independence and competence, not a QSA or ASV badge.
• The retest in 11.4.4 is mandatory. Check whether it is in your quote.
• Service providers owe segmentation tests every 6 months and must support their customers’ testing.
• Quarterly ASV scanning under 11.3.2 is a separate obligation and does need a certified vendor.
• Budget $8,000 to $30,000 a year for a segmented environment, or start from $299 a month on continuous testing.