PCI DSS Requirement 11 Guide: Scans, Penetration Tests and Intrusion Detection in v4.0.1

Requirement 11 is the part of PCI DSS that proves the other controls actually work, through a fixed calendar of wireless checks, internal and external scans, penetration tests, segmentation tests and continuous intrusion and change detection. This guide works through PCI DSS v4.0.1 Requirement 11, "Test Security of Systems and Networks Regularly", section by section: wireless access points (11.2), vulnerability scanning (11.3), penetration and segmentation testing (11.4) and intrusion and change detection (11.5). It is written for vulnerability management leads, penetration test coordinators and PCI programme owners who need a testing calendar an assessor will accept. Payment page tamper detection (11.6.1) has its own page and is only summarised. Requirement wording is summarised, not quoted, because the standard is distributed as a PDF through the PCI SSC Document Library; confirm frequencies and applicability against the current standard before relying on them.

Source note: this page summarises the official text and the sources listed at the end. Confirm against the official text before relying on it.

Key takeaways

• Four passing scans a year, inside and out: PCI SSC FAQ 1152 says entities generally need clean or passing internal and external scans at least once every three months across the previous four quarters, and missed or incomplete quarters mean the requirement is not met.
• Internal scans must be authenticated: since 31 March 2025, 11.3.1.2 requires authenticated internal scanning with sufficient privileges, and the scan credentials are themselves managed accounts.
• Your ranking decides what must be fixed: FAQ 1597 says critical and high-risk vulnerabilities from internal scans are resolved, while lower-ranked ones are addressed according to a targeted risk analysis (11.3.1.1).
• Segmentation is tested, not assumed: if segmentation reduces scope, 11.4.5 requires penetration tests of the segmentation controls, and FAQ 1447 confirms service providers must test at least once every six months under 11.4.6.
• Detection is part of testing: 11.5 requires intrusion detection or prevention at the CDE perimeter and critical points, and change detection on critical files, both feeding the incident response process.

How Requirement 11 is structured

The wider standard is summarised in the PCI DSS 4.0 Guide. Frequencies below are as commonly applied to v4.0.1; check each against the standard and your targeted risk analyses.

11.2: wireless access points

11.2.1 requires authorised and unauthorised wireless access points to be managed: the entity tests for the presence of wireless access points, detects and identifies all authorised and unauthorised ones, and does so at least once every three months, or continuously with automated monitoring that generates alerts. This applies even where the entity has no wireless in the CDE, because a rogue access point plugged into a CDE switch bridges the segmentation. 11.2.2 requires an inventory of authorised wireless access points with a documented business justification.

• Methods: wireless intrusion prevention (WIPS) sensors, controller-based rogue detection, quarterly walk-through scans with a wireless analyser, switch port and NAC checks for unknown devices, or a combination.
• What fails assessments: scanning only for SSIDs (rogue devices can be hidden or wired-side only), and treating every unknown neighbouring network as noise without classifying it.
• Response: an unauthorised access point found in or connected to the CDE is an incident; see the Rogue Device on Network Playbook. Authorised enterprise Wi-Fi should use certificate-based authentication; see the 802.1X and EAP-TLS Enterprise Wi-Fi Guide.

11.3: internal and external vulnerability scans

Timing: PCI SSC FAQ 1087 explains that "quarterly" means scans roughly three months apart, as close to that interval as possible, with remediation completed within the cycle; if a scan is disrupted, run it as soon as possible, and if a change freeze is known in advance, scan before it. Scans after significant changes are in addition to the quarterly cycle.

Composite passing scans: FAQ 1152 accepts a collection of scan results rather than one clean environment-wide scan, provided all in-scope systems are scanned each quarter, rescans confirm the fixes, and remediation is effective. Keep the rescans: they are the evidence.

Ranking and remediation: scan findings feed the 6.3.1 ranking process. FAQ 1597 defines "resolved" as fixed and "addressed" as either fixed or mitigated another way, such as disabling the vulnerable service. See the PCI DSS Requirement 6 Guide for ranking and patch timeframes, and the PCI Approved Scanning Vendor Scans Guide for ASV mechanics.

Where identity fits: the scanning account

11.3.1.2 makes the scanner a privileged non-human identity on every in-scope host. Treat its credentials accordingly: store them in a vault or the scanner's credential manager, never in scan policy exports; scope privileges to what the scanner needs; restrict where the account may log on from (the scanner hosts only); and alert on any interactive use. If the account is capable of interactive login, PCI DSS Requirement 8.2.2 and 8.6 controls apply; see the PCI DSS Requirements for Service Accounts and NHIs Guide (8.6). Systems that cannot accept credentials must be documented. General technique is in the Authenticated vs Unauthenticated Scanning Guide.

11.4: penetration and segmentation testing

11.4.1 requires a documented penetration testing methodology. Assessors expect it to be based on industry-accepted approaches, cover the whole CDE perimeter and critical systems, test from inside and outside the network, test segmentation and scope-reduction controls, include application-layer testing against at least the 6.2.4 attack classes, include network-layer testing of components supporting network functions and operating systems, consider threats and vulnerabilities experienced in the last 12 months, define how findings are risk-assessed, and retain results and remediation records for at least 12 months.

The PCI SSC segmentation FAQ describes adequate segmentation as isolation strong enough that compromise of an out-of-scope system would not affect CDE security, and says penetration testing must confirm segmentation controls are operational and effective. Scoping detail is in the PCI DSS Scoping and Network Segmentation Guide. For test planning see the Penetration Test Scoping Checklist and, for tracking findings to closure under 11.4.4, the Penetration Test Remediation Tracker Template.

11.5 and 11.6: intrusion and change detection

• 11.5.1 IDS or IPS: intrusion detection or prevention monitors all traffic at the CDE perimeter and at critical points in the CDE, alerts personnel to suspected compromise, and keeps engines, baselines and signatures up to date. In cloud environments this is often provider traffic mirroring or a managed network detection service. See the IDS and IPS Guide.
• 11.5.1.1 covert channels (service providers): detection of, alerting on or prevention of covert malware communication channels such as DNS tunnelling, with a response process.
• 11.5.2 change detection: a change-detection mechanism such as file integrity monitoring alerts on unauthorised modification of critical files and performs critical file comparisons at least once a week. See the File Integrity Monitoring Guide and the Linux File Integrity Monitoring Guide.
• 11.6.1 payment page tamper detection: detects unauthorised changes to HTTP headers and payment page content as received by the consumer's browser. Covered in the PCI DSS for E-commerce Payment Page Scripts Guide.

Decision guidance

• Internal or external testers: PCI DSS allows qualified internal testers with organisational independence. Internal teams test more often and know the estate; external firms bring a fresh view and are easier to defend as independent. Many entities use internal staff for change-driven tests and an external firm for the annual tests. See the Penetration Testing Provider Buyer's Guide.
• Quarterly walk-through or WIPS for 11.2.1: a quarterly scan suits a few small sites; many stores or offices make continuous WIPS or controller-based detection cheaper and stronger.
• Continuous scanning: scanning weekly or continuously does not remove the need for documented quarterly passing results, but it makes passing scans far easier to show and shortens exposure.
• Segmentation versus flat scope: segmentation shrinks scope but adds 11.4.5 (and 11.4.6) testing; a very small estate may find it simpler to keep everything in scope.
• Service providers: budget for six-monthly segmentation tests, covert channel detection and multi-tenant test support on top of the merchant baseline.

How to implement Requirement 11

1. Build the calendar: one testing calendar covering quarterly internal and ASV scans, wireless checks, annual internal and external penetration tests and segmentation tests, with owners and due dates set before the three-month or 12-month mark.
2. Define "significant change": agree triggers (new internet-facing service, segmentation rule changes, new CDE platform, major application release) so 11.3.1.3, 11.3.2.1 and 11.4.2 re-tests fire from the change process (6.5.2).
3. Move to authenticated internal scanning: create the scan identity, pilot on a test group, confirm the scanner reports successful authentication per host, then extend; track hosts where authentication failed as a defect, not a pass.
4. Write the methodology (11.4.1): reference an industry-accepted approach, list every element above, and get the tester to confirm it in the statement of work.
5. Test segmentation from every out-of-scope zone: attempt connections from each segment into the CDE on all TCP and UDP ports, record results and keep firewall rule evidence alongside them.
6. Tune detection in alert mode first: deploy IDS or IPS in detection mode at the CDE perimeter, tune, then enable prevention on high-confidence signatures; keep a rollback to detection mode for false-positive outages. Set FIM baselines after a clean build.
7. Close the loop: route findings into the 6.3.1 ranking, retest, and keep results for at least 12 months.

Detection and measurement

• Passing scan continuity: quarters in the last four with a passing internal and external result; target four of four.
• Authenticated scan success rate: share of in-scope hosts where the internal scan authenticated successfully.
• Days to remediate exploitable penetration test findings, and share retested and closed before the next test.
• Segmentation test coverage: out-of-scope segments tested in the period against segments that exist.
• Rogue access points detected and time to removal.
• Detection health: IDS signature age, FIM agent coverage of critical files, and alerts triaged within your target.

Framework mapping

External testing targets MITRE ATT&CK T1190 Exploit Public-Facing Application; authenticated scanning and internal tests surface the weak credentials behind T1078 Valid Accounts. Related deep dives: CIS Control 18 Penetration Testing Guide and CIS Control 7 Continuous Vulnerability Management Guide.

Common failure patterns

• A missed quarter: one late or incomplete scan breaks the four-quarter record that FAQ 1152 describes; schedule before the deadline, not on it.
• Authenticated in name only: credentials configured but failing on half the hosts, so results look clean because the scanner saw less.
• Perimeter appliances left out of testing: VPN and remote access gateways are exactly where attackers go first, as the Ivanti Connect Secure exploitation showed. Keep them in external scans and penetration tests.
• Segmentation tested from one network only: a single test from the corporate LAN misses guest Wi-Fi, OT, cloud and partner connections.
• Findings closed without retest: 11.4.4 expects correction confirmed by repeat testing, not a ticket marked done.
• FIM noise ignored: alerting on every patch day trains teams to ignore 11.5.2 alerts; tie expected changes to approved change tickets.

Practitioner checklist

• Publish a Requirement 11 testing calendar with owners and due dates for every cadence.
• Keep four quarters of passing internal and ASV external scan evidence, including rescans.
• Run authenticated internal scans and track per-host authentication success (11.3.1.2).
• Manage the scan account as a privileged non-human identity with vaulted credentials and restricted logon.
• Document a penetration testing methodology covering every 11.4.1 element.
• Test segmentation from every out-of-scope segment at the required frequency (11.4.5, 11.4.6).
• Detect rogue wireless at least every three months or continuously, with an authorised AP inventory (11.2).
• Run IDS or IPS at the CDE perimeter and critical points with current signatures (11.5.1).
• Run weekly or more frequent critical file comparisons and link alerts to change records (11.5.2).

Standards and references

• PCI SSC: Document Library (PCI DSS v4.0.1, ASV Program Guide, Penetration Testing Guidance)
• PCI SSC FAQ 1152: Four passing scans
• PCI SSC FAQ 1087: Meaning of quarterly scans
• PCI SSC FAQ 1597: Risk ranking and resolving or addressing vulnerabilities
• PCI SSC FAQ 1447: Segmentation testing frequency for service providers
• PCI SSC FAQ: Adequate network segmentation
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls
• NIST: Cybersecurity Framework 2.0

Related NHI Mgmt Group resources: PCI DSS 4.0 Guide, PCI DSS Readiness Checklist, PCI QSA and ASV Selection, Penetration Testing Guide, PCI DSS Requirement 10 Guide. This guide summarises PCI DSS v4.0.1 Requirement 11 and is not legal or assessment advice.