PCI DSS 4.0 Requirements 11.3 and 11.4: What Actually Gets Tested

Most security frameworks talk around penetration testing. They ask for "technical assurance" or "independent verification" and leave the rest to interpretation. PCI DSS does not. It is the only framework in the compliance family that names penetration testing explicitly and fixes a calendar to it — and version 4.0 tightened the screws rather than loosened them. If your assessment window lands this year, the question is no longer whether you need a pentest, but whether the one you have will survive a QSA's reading.

The confusion almost always starts in the same place: teams treat "scanning" and "testing" as two words for the same activity, schedule one, and discover at assessment time that the standard wanted both. Requirements 11.3 and 11.4 are deliberately split for exactly that reason. One is automated, quarterly, and answers a checkbox. The other is manual, annual, and answers a much harder question — can someone actually reach the card data?

What counts as in scope

The perimeter is not "the payment server." It is the cardholder data environment — the CDE — plus every system that can connect to it or influence its security. That second clause is where most scoping arguments are lost. Administrative workstations, authentication systems, monitoring platforms, and connected service providers all sit inside the boundary, because each of them is a plausible route in.

A system that is genuinely outside the perimeter has to be outside it technically, not just on a diagram. And that distinction is proved by segmentation testing, not by documentation. The most common surprise at assessment is a VLAN that the architecture drawing calls "separate" but which still reaches the CDE through a forgotten firewall rule or a hop through an admin workstation. Undemonstrated segmentation does not shrink your perimeter. It quietly enlarges it, and drags every requirement along with it.

Caution: A network diagram showing a clean separation between corporate IT and the CDE proves nothing on its own. If you cannot show a tester trying to cross that boundary and failing, the QSA has to assume the boundary does not exist.

Requirement 11.3: vulnerability scanning

Requirement 11.3 covers scanning, and it is strict about both cadence and authorship. You need internal and external scans at least quarterly, plus a scan after any significant change — a new public-facing service, a re-architected segment, a major application deployment. The clock resets on change, not on the calendar.

External scans must be performed by an ASV, an Approved Scanning Vendor authorised by the PCI Security Standards Council. Internal scans can be run in-house, but by staff independent of the team that administers the systems being scanned. That independence clause is not a formality; it is the difference between a scan and a self-assessment. And a "passing" scan has a specific meaning: zero high-severity vulnerabilities. Not "we logged them all." Not "we accepted the risk." Zero.

This is the requirement teams most often believe they have satisfied when they have not. A quarterly scan report full of unpatched criticals is not evidence of compliance — it is evidence of a known, unaddressed exposure, timestamped by your own vendor.

Requirement 11.4: penetration testing

Here the standard becomes unusually specific, and it is worth reading the sub-requirements as a specification rather than a suggestion. Requirement 11.4 demands a documented methodology, external and internal testing at least annually and after significant infrastructure or application changes, coverage of the entire CDE perimeter across both network and application layers, and remediation of exploitable vulnerabilities followed by retesting.

Two clauses raise the bar further for service providers. Requirement 11.4.6 requires segmentation testing every six months rather than annually. Requirement 11.4.7 adds isolation testing between customers for multi-tenant providers — a requirement that catches up precisely with how SaaS payment platforms actually operate, where one tenant's misconfiguration can become another tenant's breach.

Read that table as a coverage map, not a checklist. A single annual pentest that touches the external web tier and stops there does not satisfy 11.4.2, which explicitly wants the internal network and the application layer as well. The two layers catch different things: network testing finds the path, application testing finds the door left open at the end of it.

What the QSA asks for in the report

The report itself is where engagements are won or lost. A QSA is not reading your findings for entertainment; they are checking whether the work matches the requirement. Six things come up again and again.

• A stated methodology that is recognised in the industry — PTES, OWASP, or NIST SP 800-115 — not a bespoke process invented for the engagement.
• A justification of the perimeter: why these systems and not others, tied to the cardholder data flow diagram.
• Evidence that testing covered both the network layer and the application layer.
• For segmentation: which controls were attempted from outside the CDE, and the result of each attempt.
• Documented retesting for every exploitable vulnerability, with a date and a final status.
• Proof that the tester was independent of the team administering the systems under test.

That last point is the one that quietly disqualifies engagements. If the same engineer who runs the firewalls also runs the test against them, the independence requirement is not met, no matter how good the findings are.

Important: Retesting is not optional cleanup. Requirement 11.4 expects exploitable vulnerabilities to be remediated and then retested, with the retest documented. A finding list with no closure evidence is an open item, not a completed requirement.

Scanning and testing are not substitutes

The single most useful mental model is this: a scan finds known vulnerabilities on exposed services; a penetration test tries to exploit them, chain them together, and actually reach the card data. One is a smoke detector. The other is someone walking the building at night, checking whether the windows you believe are locked really are.

An ASV scan is automated, quarterly, external, and answers 11.3.2. A penetration test is manual, annual, and answers 11.4. The standard requires both because each misses what the other catches. Automation is exhaustive about the known and blind to the novel; a human tester is the reverse. Replacing one with the other is the most common — and most easily caught — shortcut in a PCI DSS assessment.

There is also a practical consequence for how you budget and schedule. Scans are cheap, frequent, and can be largely operational. Penetration tests are expensive, annual, and depend on scarce expertise. Treating them as one line item means one of them gets underfunded, and it is usually the one that takes real skill to do well.

What changed from 3.2.1 to 4.0

The testing requirements were renumbered — 11.3 became scanning, 11.4 became penetration testing — but the more consequential changes were substantive. New requirements appeared for multi-tenant isolation and multi-factor authentication, and a set of items previously treated as "best practice" became mandatory after 31 March 2025. The customised approach also arrived, allowing an entity to meet a requirement's objective through alternative controls, but with documentation and validation demands that are considerably heavier than simply doing the thing as written.

For most organisations, the practical effect is that the grace period is over. Requirements that could be deferred are now assessed, and the segmentation testing that was once a quiet annex to the pentest has become a central deliverable in its own right.

Does this apply to you?

PCI DSS is not a law. It is a contractual requirement imposed by the card schemes through acquiring banks and processors, and it applies to any entity that stores, processes, or transmits card data regardless of country. For companies in Moldova, the obligation typically arrives through the acquiring bank or a partner processor, and the level of validation depends on annual transaction volume. That means the trigger is commercial, not legislative — you can be fully compliant with national law and still be contractually required to produce a pentest report next quarter.

If you are preparing for that conversation, the useful work happens before the tester arrives: draw the real data flow, test whether your segmentation actually holds rather than assuming it, and confirm that whoever runs the test is genuinely independent of whoever runs the systems. Those three things determine more of your assessment outcome than any tool in the report.