Requirement 11: Test Security of Systems and Networks Regularly

PCI DSS v4.0.1 Requirement 11: vulnerability scanning cadence, ASV scans, penetration testing scope, and the 11.6.1 payment page change detection control.

PCIComplianceHubLast updated Last reviewed against PCI DSS v4.0.1

Requirement 11 is where the standard asks you to attack yourself on a schedule and act on what you find.

PCI DSS v4.0.1 breaks this requirement into 6 sections containing 21 individual controls.

What this requirement is actually asking

11.3.1 requires internal vulnerability scans at least every three months, with high-risk and critical findings resolved and a rescan confirming it. 11.3.2 requires external scans on the same cadence performed by a PCI SSC Approved Scanning Vendor (ASV). A formal accreditation, and the scan is only valid if the vendor holds it. Internal scans are also authenticated (11.3.1.2) and repeated after any significant change (11.3.1.3), and vulnerabilities ranked below high-risk are addressed on the timescale set in a targeted risk analysis (11.3.1.1).

11.6.1 is the second anti-skimming control. Changes to the security-impacting HTTP headers and script contents of payment pages, as received by the consumer browser, raise an alert. The check runs at least weekly, or at a frequency set in a targeted risk analysis under 12.3.1. It pairs with 6.4.3: 6.4.3 authorises what should be there, 11.6.1 detects when that changes. Both became mandatory on 31 March 2025.

Internal and external penetration testing (11.4) is done at least once every 12 months and after any significant infrastructure or application upgrade or change. Where segmentation isolates the CDE, the segmentation controls are tested at least once every 12 months and after any change to them (11.4.5). Service providers test them at least once every six months and after any change (11.4.6).

Does it apply to you?

All in-scope systems. If you rely on segmentation to reduce scope, the segmentation itself becomes a test target.

The controls

Requirement 11 contains 21 controls across 6 sections. Each links to its own page with the requirement in full and the testing procedures an assessor uses to verify it.

11.1: Governance for security testing

Control What it requires Guidance
11.1.1 All security policies and operational procedures that are identified in Requirement 11… Yes
11.1.2 Roles and responsibilities for performing activities in Requirement 11 are documented… Yes

11.2: Detecting unauthorised wireless access points

Control What it requires Guidance
11.2.1 Authorized and unauthorized wireless access points… Yes
11.2.2 An inventory of authorized wireless access points is maintained… Yes

11.3: Internal and external vulnerability scanning, including ASV scans

Control What it requires Guidance
11.3.1 Internal vulnerability scans… Yes
11.3.1.1 All other applicable vulnerabilities… Yes
11.3.1.2 Internal vulnerability scans are performed via authenticated scanning… Yes
11.3.1.3 Internal vulnerability scans are performed after any significant change… Yes
11.3.2 External vulnerability scans… Yes
11.3.2.1 External vulnerability scans are performed after any significant change… Yes

11.4: Penetration testing, including segmentation validation

Control What it requires Guidance
11.4.1 A penetration testing methodology is defined, documented, and implemented by the entity… Yes
11.4.2 Internal penetration testing is performed… Yes
11.4.3 External penetration testing is performed… Yes
11.4.4 Exploitable vulnerabilities and security weaknesses found during penetration testing… Yes
11.4.5 If segmentation is used to isolate the CDE from other networks… Yes
11.4.6 Service providers: If segmentation is used to isolate the CDE from other networks… Yes
11.4.7 Multi-tenant service providers support their customers for external penetration testing per… Yes

11.5: Intrusion detection and file integrity monitoring

Control What it requires Guidance
11.5.1 Intrusion-detection and/or intrusion-prevention techniques are used to detect and/or prevent… Yes
11.5.1.1 Service providers: Intrusion-detection and/or intrusion-prevention techniques detect, alert on/prevent… Yes
11.5.2 A change-detection mechanism (for example, file integrity monitoring tools)… Yes

11.6: Detecting unauthorised change to payment pages (new in v4)

Control What it requires Guidance
11.6.1 A change- and tamper-detection mechanism… Yes

Evidence your assessor will ask for

  • Passing ASV scan reports at least once every three months over the last 12 months (at a first assessment, the latest passing scan, a policy requiring that cadence and rescans showing the fixes can stand in for four), plus internal scan output on the same cadence
  • Rescan evidence showing high-risk findings were resolved, not just recorded
  • A penetration test report scoped to the CDE, with retest evidence for findings
  • Change-detection alerts and their disposition for payment pages

Where this commonly fails

  • Assuming any vulnerability scanner satisfies 11.3.2. It must be an ASV, and the ASV must be listed by PCI SSC
  • Scans that pass because the scanner could not reach the target
  • Treating 11.6.1 as covered by a generic uptime monitor

An important limitation

PCIComplianceHub is not an Approved Scanning Vendor. ASV scans under 11.3.2 must be performed by a vendor listed on the PCI SSC website; PCIComplianceHub's TLS scanner and payment-page change detection support your own testing and evidence gathering, and do not substitute for an ASV scan.

Terms

Glossary entries that name a control in this requirement:

Official source

The commentary on this page is our own. The requirement title, and the control text in the tables above (shortened where it ends in an ellipsis), are reproduced from PCI DSS v4.0.1 (June 2024), ©2006-2024 PCI Security Standards Council, LLC. All rights reserved. Each control's own page carries its requirement text in full. For the authoritative wording, including each testing procedure and the customized approach objective, download the standard from the PCI Security Standards Council document library.

PCI DSS is a registered standard of the PCI Security Standards Council, LLC, which does not endorse this site.