PCI DSS penetration testing and scanning — Requirements 11.3 and 11.4 in v4.0.1

PCI DSS v4.0.1, published by the PCI Security Standards Council in June 2024, is the only active version of the standard: v4.0 was retired on 31 December 2024. PCI SSC describes v4.0.1 as a limited revision with corrections and clarifications and no added or deleted requirements; the examples of changes it highlights publicly are in Requirements 3, 6, 8 and 12 and the appendices. The 51 future-dated requirements of v4.x became mandatory on 31 March 2025. In June 2026 PCI SSC ran a request for comments on v4.0.1 to begin work on the next version, which has not been published.

The full standard is free, but it is downloaded from the PCI SSC Document Library after accepting a license agreement. The requirement wording quoted below was read in the v4.0 edition published by PCI SSC in March 2022, and the frequencies and conditions match the public PCI SSC FAQs cited here; check the v4.0.1 text before you quote it in a policy.

Two framing points from PCI SSC itself. It does not enforce compliance: whether an entity must validate compliance, how and with whom is set by the payment brands and acquirers (FAQ 1212). And an ASV scan report is not a statement that any other PCI DSS requirement is in place (FAQ 1234).

11.3.1, internal scans, are performed:

• at least once every three months;
• with high-risk and critical vulnerabilities, per your risk rankings under Requirement 6.3.1, resolved;
• with rescans confirming that all high-risk and critical vulnerabilities have been resolved;
• with the scan tool kept up to date;
• by qualified personnel, with organizational independence of the tester. The applicability notes say a QSA or ASV is not required and that internal staff can scan if they are reasonably independent of the systems scanned; a network administrator should not scan the network they run.

11.3.1.1 covers every other vulnerability: address it based on the risk defined in your targeted risk analysis (Requirement 12.3.1) and rescan as needed. 11.3.1.2 requires authenticated internal scanning with sufficient privileges, a documented list of systems that cannot accept credentials, and management of scan accounts that allow interactive login. Both were future-dated and have applied since 31 March 2025. 11.3.1.3 requires internal scans after any significant change, with high-risk and critical findings resolved.

11.3.2, external scans, are performed at least once every three months by a PCI SSC Approved Scanning Vendor (ASV), with vulnerabilities resolved and the ASV Program Guide requirements for a passing scan met, and rescans as needed. This requirement is not eligible for the customized approach. 11.3.2.1 requires external scans after any significant change, resolving vulnerabilities scored 4.0 or higher by CVSS; these do not have to be run by an ASV.

PCI SSC's FAQs add the operational detail. “At least once every three months” means no more than 90 days between scans, and scans after a significant change come on top of the quarterly ones (FAQ 1087). You need four passing scans over the last 12 months, although a collection of scan and rescan results can show that; missing quarters because scans were not scheduled, were incomplete or found the same unaddressed vulnerabilities means the requirement is not met (FAQ 1152). A passing external scan generally has no automatic-failure conditions and no vulnerabilities scored 4.0 or higher. Since v4.x, SAQ A merchants whose webpages redirect to or embed a third-party payment page also need ASV scans.

11.4.1 requires a penetration testing methodology that is defined, documented and implemented, and includes:

• industry-accepted penetration testing approaches;
• coverage of the entire CDE perimeter and critical systems;
• testing from both inside and outside the network;
• testing to validate any segmentation and scope-reduction controls;
• application-layer testing covering, at a minimum, the vulnerabilities listed in Requirement 6.2.4;
• network-layer tests of all components that support network functions, and of operating systems;
• review of threats and vulnerabilities experienced in the last 12 months;
• a documented approach to assessing and addressing the risk of exploitable vulnerabilities found;
• retention of penetration testing results and remediation results for at least 12 months.

Internal testing means testing from inside the CDE and into the CDE from trusted and untrusted internal networks; external testing means testing the exposed external perimeter of trusted networks and critical systems reachable from public networks.

11.4.2, internal and 11.4.3, external penetration tests are each performed per the methodology, at least once every 12 months, after any significant infrastructure or application upgrade or change, by a qualified internal resource or qualified external third party, with organizational independence of the tester (not required to be a QSA or ASV). 11.4.4 requires exploitable vulnerabilities and security weaknesses to be corrected according to the risk assessment of Requirement 6.3.1, and penetration testing to be repeated to verify the corrections.

11.4.5: if you use segmentation to isolate the CDE, penetration tests on the segmentation controls run at least once every 12 months and after any change to them, cover every segmentation method in use, and confirm that the CDE is isolated from all out-of-scope systems, by a qualified and independent tester. 11.4.6: service providers do the same at least once every six months, and PCI SSC's FAQ on 11.4.6 confirms that the interval must not exceed six months. 11.4.7: multi-tenant service providers support their customers' external penetration testing.

Several of these requirements run on significant changes as well as on the calendar. PCI SSC's FAQ lists what counts, at a minimum, for evaluation: new hardware, software or network equipment in the CDE; replacement or major upgrades of hardware and software in the CDE; changes in the flow or storage of account data; changes to the CDE boundary or to the scope of the assessment; changes to supporting infrastructure such as directory services, time servers, logging and monitoring; and changes to third-party vendors or service providers that support the CDE. Each needs a recorded decision on whether it triggers rescans and re-tests.

The standard does not define “qualified” in a list of certifications. Its guidance points to prior experience, such as years of experience and the type and scope of past engagements, as a way to confirm the tester fits the engagement. Organizational independence means the tester is not part of the team that runs or changes the systems under test. Assessors check both by examining the scope of work and results and by interviewing personnel, so write the tester's qualifications and reporting line into the test report.

PCI DSS does not ban tools; it defines what a penetration test is and who is accountable for it.

What the text says. The customized approach objective for 11.4.1 is a formal methodology “for thorough technical testing that attempts to exploit vulnerabilities and security weaknesses via simulated attack methods by a competent manual attacker”. The guidance adds that scanning for vulnerabilities alone is not a penetration test, that a test is not adequate if it only tries to exploit scanner findings, and that “penetration testing is a highly manual process. While some automated tools may be used, the tester uses their knowledge of systems to gain access into an environment”, often chaining several exploits.

What automation cannot do on its own:

• Be the qualified internal resource or external third party that 11.4.2, 11.4.3 and 11.4.5 name. A platform run by nobody is not a tester with qualifications and independence to show an assessor.
• Replace the ASV for 11.3.2. Only a listed ASV, using its own ASV scan solution, meets that requirement.
• Decide whether your annual test is acceptable. That judgment belongs to your QSA or, for self-assessment, to you and your acquirer.

What it can do well:

• Give the qualified tester a tool that covers the methodology's inside and outside perspectives, network-layer paths and segmentation checks faster and more often, while the tester designs, supervises and signs the test.
• Run the tests required after significant changes (11.3.1.3, 11.3.2.1, 11.4.2, 11.4.3, 11.4.5), which do not wait for the annual cycle and do not require an ASV or QSA.
• Re-test every correction with the same proof that found it, which is what 11.4.4 asks for.
• Keep six-monthly segmentation evidence for service providers (11.4.6) and a continuous record between annual tests.

Whether an internal team using an autonomous platform counts as the qualified internal resource for the annual test is a question for your assessor, answered by the team's qualifications, its independence and the methodology, not by the tool. See automated penetration testing for the general limits.

The annual test is a floor, and the rest of Requirement 11 already assumes more frequent evidence. A structure that is easy to defend in an assessment:

1. Quarterly, and more often where your risk analysis says so: authenticated internal scans and ASV external scans, with rescans until results pass. PCI SSC encourages scanning more often than required.
2. On every significant change: internal and external scans, plus the internal, external and segmentation penetration tests the change affects, recorded against the change ticket.
3. Continuously between tests: autonomous black-box and gray-box campaigns against the CDE perimeter, critical systems and segmentation boundaries, so a regression or a new exposure is found in days rather than at the next annual test. PCI SSC's September 2026 guidance on AI systems stresses frequent, if not continual, monitoring and management of vulnerabilities.
4. Once every 12 months, at least: the internal and external penetration tests led by a qualified, independent tester under the documented methodology, informed by what continuous testing found during the year and by the threats of the last 12 months, as 11.4.1 requires.
5. After every fix: a re-test that closes the finding, and results kept for at least 12 months.

For Requirements 11.3 and 11.4 the file usually needs:

• The penetration testing methodology covering every 11.4.1 element, with its approval and review dates.
• Internal and external penetration test reports for the last 12 months: scope of work, results, tester qualifications and organizational independence.
• Segmentation test results at the required interval (12 months, or six months for service providers), covering every segmentation method.
• Remediation and re-test records showing each exploitable finding corrected per the Requirement 6.3.1 risk ranking and verified by repeated testing.
• Four quarters of ASV scan reports on official templates, with rescans, and four quarters of internal scans with rescans for high-risk and critical findings.
• The targeted risk analysis for lower-ranked vulnerabilities (11.3.1.1) and the list of systems that cannot accept credentials for authenticated scanning (11.3.1.2).
• Change records showing which significant changes triggered scans and tests, and the results.
• Retained results and remediation evidence for at least 12 months.

An autonomous AI red team for networks and infrastructure is not an ASV, is not a QSA, and does not replace the qualified, independent tester PCI DSS names. It gives that tester, and the security team, more evidence between annual tests.

• Inside and outside, on a schedule and after changes. Black-box campaigns against the external perimeter and gray-box campaigns with standard-user access inside the network run once, daily, weekly, monthly or on a custom schedule, and can be launched for a significant change.
• Proof, then re-test. Findings record whether a vulnerability was actually exploited, and each correction can be re-tested with the same proof, the record 11.4.4 asks for.
• Requirement 11 mapping. The engine's PCI DSS 4.0.1 framework, one of the 34 it supports, includes controls for quarterly internal scans and their resolution, authenticated scanning, ASV external scans, internal and external penetration testing, re-testing of corrections and segmentation testing, and it exports compliance reports. The ASV scan itself still has to come from an ASV.
• Human approval of risky steps. Five autonomy levels decide what waits for a person, and exploit proofs of concept can be held for operator review, so testing near production payment systems stays under control. See human in the loop.
• Records that hold up. Every attack attempt is an Ed25519-signed entry in a SHA-256 hash chain, and exported reports are ECDSA-signed.
• No customer data leaves the appliance. Models run on the appliance with no external AI service, so account data a test touches and the map of exploitable CDE systems do not go to another cloud platform that you would have to list and manage as a third-party service provider under Requirement 12.8. See on-premise AI red team.

• PCI Data Security Standard: overview and document access (PCI SSC)
• PCI SSC Document Library: PCI DSS v4.0.1 and the Penetration Testing Guidance information supplement
• Just Published: PCI DSS v4.0.1, 11 June 2024 (PCI SSC blog)
• FAQ: what is meant by “quarterly” or “at least once every three months” (PCI SSC)
• FAQ: four “passing” scans (PCI SSC)
• FAQ: an ASV scan does not mean PCI DSS compliance (PCI SSC)
• FAQ: risk-ranking and resolving vulnerabilities (PCI SSC)
• FAQ: what is meant by “significant change” (PCI SSC)
• FAQ: service provider segmentation testing under 11.4.6 (PCI SSC)
• FAQ: PCI SSC's role in compliance validation (PCI SSC)
• Resource Guide: Vulnerability Scans and Approved Scanning Vendors, July 2024 (PCI SSC blog)
• Request for Comments on PCI DSS v4.0.1, June 2026 (PCI SSC blog)
• Just Published: Security Considerations for AI Systems, September 2026 (PCI SSC blog)