PCI DSS Requirement 11: security testing

By Sam Rivera, Founder, SentinelPanda · August 6, 2026 · 3 min read · PCI DSS

Requirement 11 is the one with the most external dependencies and the least forgiving calendar. Four passing ASV scans a year cannot be assembled retroactively.

Scanning: internal, external, and the ASV distinction

Requirement 11.3.1 requires internal vulnerability scans at least once every three months, with high-risk and critical vulnerabilities resolved and rescans performed to confirm. v4.0 added 11.3.1.2, requiring internal scans to be performed via authenticated scanning — credentialed scans see far more than unauthenticated ones, and this closes a long-standing gap where quarterly scans reported very little.

Requirement 11.3.2 requires external scans at least once every three months, performed by an Approved Scanning Vendor. This is not something you can run yourself: the ASV is certified by the PCI SSC and issues the attestation. A passing external scan means no vulnerabilities scored 4.0 or above by CVSS, with rescans as needed until a passing result is achieved.

Both types are also required after any significant change.

The calendar problem

This requirement fails more assessments on scheduling than on findings. Four quarterly ASV scans across the year cannot be reconstructed in month eleven, and a missed quarter is simply a missed quarter. Book them, and treat a failing scan as an incident with a rescan deadline rather than a task to revisit later.

The same discipline applies to penetration testing under 11.4: external and internal testing at least annually and after significant infrastructure or application upgrades or modifications, following an industry-accepted methodology, with exploitable vulnerabilities corrected and testing repeated to verify. Booking a qualified tester takes lead time, and "we could not get a slot" is not an accepted position.

Segmentation testing cadence

• If segmentation is used to reduce scope, testing must confirm it is operational and effective, isolating the CDE from out-of-scope systems.
• Merchants: at least every twelve months and after any change to segmentation controls (11.4.5).
• Service providers: at least every six months and after changes (11.4.6). This doubled cadence is one of the practical costs of being a service provider.
• The test must cover all segmentation controls in use and be performed by a qualified party with organisational independence.

Detection and the payment page control

Requirement 11.5.1 requires intrusion detection or prevention techniques to detect and alert on suspected compromises at the perimeter of and at critical points within the CDE, kept current. Requirement 11.5.2 requires a change-detection mechanism — file integrity monitoring — alerting on unauthorised modification of critical files, with comparisons performed at least weekly.

Requirement 11.6.1, added in v4.0, is the one that most often requires new tooling: a change- and tamper-detection mechanism deployed to alert on unauthorised modification to the HTTP headers and script contents of payment pages as received by the consumer browser, evaluated at least weekly or at a frequency defined by a targeted risk analysis.

It is the detective counterpart to Requirement 6.4.3's preventive script controls, and together they exist because client-side skimming attacks never touch your servers — server-side integrity monitoring will not see them.