Key Takeaways
- Internal and external penetration tests are due at least every 12 months and after any significant change, following a documented methodology (11.4.1 to 11.4.3)
- The tester must be qualified and organisationally independent, but does not have to be a QSA, an ASV or hold any named accreditation
- Exploitable findings must be corrected according to their risk and retested; the retest evidence is part of the requirement, not an optional extra (11.4.4)
- If segmentation reduces your scope, the segmentation controls are tested every 12 months, and every six months for service providers (11.4.5, 11.4.6)
- Multi-tenant service providers have been required to support customer external testing since 31 March 2025 (11.4.7)
What Does PCI DSS Requirement 11.4 Require?
Requirement 11.4 requires that external and internal vulnerabilities are regularly identified, prioritised and addressed through penetration testing. In practice it means seven things: a documented methodology; an internal test and an external test at least every 12 months and after significant changes; correction and retest of what the tests find; testing of any segmentation you rely on to keep systems out of scope; a six-monthly segmentation cadence for service providers; and, for multi-tenant service providers, support for their customers' own external tests. The table below summarises each sub-requirement as written in PCI DSS v4.0.1.
| Requirement | What it means | Applies to | Cadence |
|---|---|---|---|
| 11.4.1 | A penetration testing methodology is defined, documented and implemented. | All entities | Standing requirement |
| 11.4.2 | Internal penetration testing is performed per the methodology by a qualified, organisationally independent internal resource or external third party. | All entities | At least every 12 months and after significant change |
| 11.4.3 | External penetration testing is performed per the methodology, with the same qualification and independence conditions. | All entities | At least every 12 months and after significant change |
| 11.4.4 | Exploitable vulnerabilities and security weaknesses found are corrected according to the risk they pose (per 6.3.1) and the test is repeated to verify the corrections. | All entities | After every test |
| 11.4.5 | If segmentation isolates the CDE, penetration tests confirm every segmentation control is operational, effective and isolates the CDE from all out-of-scope systems. | Entities using segmentation | At least every 12 months and after changes to segmentation controls |
| 11.4.6 | Service providers using segmentation test it on the same terms, and confirm any isolation used to separate systems of differing security levels. | Service providers only | At least every six months and after changes |
| 11.4.7 | Multi-tenant service providers support their customers’ external penetration testing under 11.4.3 and 11.4.4. | Multi-tenant service providers only | Required since 31 March 2025 |
Two points are commonly misread. First, 11.4 is about penetration testing only; vulnerability scanning lives in Requirement 11.3 and is a separate obligation. Second, "after significant change" is not a suggestion. If your change process cannot tell you which changes were significant, the QSA will ask how you know no retest was due.
What Must the Penetration Testing Methodology Include? (11.4.1)
The methodology is your document, not your tester's. Requirement 11.4.1 expects the assessed entity to define, document and implement a penetration testing methodology, and it lists what that methodology must include. A tester's proposal or report can evidence parts of it, but the QSA will look for an entity-owned document that covers all of the following:
The methodology is based on recognised approaches. PCI SSC names none as mandatory; NIST SP 800-115, the OWASP Testing Guide, PTES and the PCI SSC Penetration Testing Guidance information supplement are the ones assessors expect to see referenced.
Every system that stores, processes or transmits account data, every connected-to system, and every system that could affect the security of the CDE.
External testing from the internet-facing perimeter and internal testing from within the network, or, in cloud environments, from an assumed-breach position inside the virtual network.
If any control is used to keep systems out of scope, the methodology must include testing that the control works.
Injection, attacks on data and data structures, attacks on cryptography usage, business-logic attacks, attacks on access-control mechanisms, and high-risk vulnerabilities identified through 6.3.1.
Firewalls, routers, switches, load balancers, wireless, and the operating systems of in-scope hosts.
Incidents, scan findings and previous test results feed the next test’s scope and emphasis.
How findings are rated and prioritised, consistent with the risk ranking used under 6.3.1.
The previous cycle’s report, findings, remediation evidence and retest results are kept and available to the assessor.
The PCI SSC's Penetration Testing Guidance information supplement, available from the PCI SSC document library, is the reference most QSAs use to judge whether a methodology is adequate. It is guidance rather than requirement, but a methodology that follows its structure rarely draws findings.
How Often Is Penetration Testing Required? (11.4.2, 11.4.3)
At least once every 12 months, and after any significant infrastructure or application upgrade or change. Both the internal test (11.4.2) and the external test (11.4.3) carry the same cadence. "Every 12 months" is measured from the previous test, so a test performed in January that is next performed the following March is late.
What counts as a significant change. PCI DSS v4.0.1 describes a significant change as one that could affect the security of the CDE or the applicability of PCI DSS requirements, and gives examples: new hardware, software or networking equipment added to the CDE; replacement or major upgrades of hardware or software; changes in the flow or storage of account data; changes to the boundary of the CDE or its scope; changes to underlying supporting infrastructure such as directory services, logging or time synchronisation; and changes to third-party vendors or service providers that support the CDE. Your methodology should say which of these apply to you and how a change is flagged for retesting. A retest after a significant change may be limited to the components affected, provided the scope is documented and justified.
Segmentation cadence. Segmentation controls are tested at least every 12 months and after any change to them (11.4.5). Service providers test every six months (11.4.6). Both apply only where segmentation is used to reduce scope.
Multi-tenant service providers. Requirement 11.4.7 has been in force since 31 March 2025. Providers that host multiple customers' environments must support those customers' external penetration testing under 11.4.3 and 11.4.4, which in practice means a documented process for authorising and scheduling customer tests, and for handling findings that touch shared infrastructure.
Who Can Perform a PCI DSS Penetration Test?
A qualified internal resource or a qualified external third party, with organisational independence. PCI DSS states explicitly that the tester is not required to be a QSA or an ASV. It also does not name any accreditation body. CREST Accredited firms, for example, can evidence methodology and tester qualification through an independent audit, and many buyers require it, but the standard itself does not.
Organisational independence means the tester is not part of the team that designs, builds, operates or maintains the systems being tested. An external firm satisfies this directly. An internal security team can satisfy it if it reports separately from the system owners and has no operational responsibility for the targets; a network engineer testing their own firewalls does not.
What "qualified" looks like to a QSA. Assessors look for evidence rather than assertion: individual certifications relevant to the test type (OSCP, CREST CRT or CCT, GPEN and similar), documented prior experience with comparable environments, and a methodology that follows recognised standards. A one-page CV appendix in the report is usually enough, and its absence is a common reason reports are queried.
Correction and Retest (11.4.4)
Exploitable vulnerabilities and security weaknesses found during testing must be corrected according to the risk they pose, and the test repeated to verify the corrections. Two details matter. The phrase is broader than "critical and high findings": a weakness that was exploitable during the test, or that contributed to a successful attack chain, is in scope for correction whatever its standalone severity rating. And the retest is not the next annual test; it is a targeted re-execution of the relevant test cases once remediation is complete.
The QSA checks three things: that each exploitable finding has a documented risk assessment consistent with 6.3.1, that remediation was completed in line with that risk, and that a retest report, dated after remediation, confirms the finding is closed. Findings accepted as a risk rather than fixed need a documented decision by management with a rationale, and the QSA will decide whether that rationale is reasonable. A retest report that simply lists "fixed" against each finding with no evidence of re-execution is routinely rejected.
ASV Scans vs Penetration Tests
Requirement 11.3 and Requirement 11.4 are separate obligations that are often confused because both involve looking for vulnerabilities. The differences the standard cares about:
| Vulnerability scanning (11.3) | Penetration testing (11.4) | |
|---|---|---|
| Method | Automated tools comparing systems against known vulnerability signatures | Manual, methodology-driven attempts to exploit weaknesses and chain them to reach account data |
| Cadence | Internal (11.3.1) and external (11.3.2) at least every three months, and after significant change | Internal and external at least every 12 months, and after significant change |
| Who | Internal scans by qualified personnel; external scans by a PCI SSC Approved Scanning Vendor (ASV) | Qualified, organisationally independent internal or external tester; QSA or ASV status not required |
| Output | Vulnerability list with severity ratings; passing ASV scan report | Report with methodology, scope, attack narrative, findings, risk ratings, remediation and retest evidence |
| Substitutes for the other? | No | No |
What the QSA Checks in Your Penetration Test Report
When a report reaches the assessor, these are the points that decide whether it is accepted as evidence for 11.4. A report can be technically excellent and still fail on several of them.
- Scope matches the current CDE network diagram and data-flow diagram, including connected-to systems
- Test dates fall within the last 12 months and after the most recent significant change
- The methodology is stated and is consistent with the entity’s documented methodology under 11.4.1
- Testers are named with qualifications, and a statement of organisational independence is included
- Both internal and external testing are covered, or two reports are provided
- Application-layer testing addresses at least the 6.2.4 vulnerability classes; network-layer testing covers network components and operating systems
- Segmentation testing results are included where segmentation is used, covering every segmentation method and every out-of-scope segment
- Findings carry risk ratings consistent with the entity’s 6.3.1 ranking, with remediation status and retest evidence per finding
- The threat and vulnerability review for the previous 12 months is referenced
- The previous cycle’s report and remediation records are retained and available
EIC's PCI DSS penetration testing service is built around this list, so the report can be handed to any QSA, not only ours. Findings, remediation status and retest evidence can also be tracked in Complium alongside every other v4.0.1 requirement, with read-only Azure and AWS integrations supplying the configuration evidence that sits next to the test results.
Cloud and Kubernetes Cardholder Data Environments
Requirement 11.4 applies unchanged to cloud-hosted CDEs, but the mechanics differ. "Internal" testing becomes an assumed-breach test from a low-privilege identity inside the virtual network, where the attack paths are identity and configuration rather than unpatched software. Segmentation is implemented with security groups, firewall policies, peering and private endpoints, and 11.4.5 requires each of those methods to be tested. Each provider also publishes rules your tester must follow. Our cloud penetration testing service covers AWS, Azure, Google Cloud and Alibaba Cloud; the PCI DSS in the Cloud guide explains scoping across all four; and PCI DSS on Kubernetes covers what a cluster adds to scope and to the test.
Frequently Asked Questions
Is penetration testing mandatory under PCI DSS v4.0.1?
Yes. Requirement 11.4 requires internal and external penetration testing at least once every 12 months and after any significant infrastructure or application change, performed according to a documented methodology by a qualified, organisationally independent tester. If segmentation is used to reduce scope, the segmentation controls must also be tested (11.4.5), every six months for service providers (11.4.6).
Does the penetration tester have to be a QSA or an ASV?
No. PCI DSS states that the tester is not required to be a QSA or an ASV. The requirement is that the tester is qualified, meaning they have the skills and experience to perform the test properly, and organisationally independent, meaning they are not part of the team that builds, operates or maintains the systems being tested. An external firm satisfies independence directly; an internal team can too, if it is independent of the system owners.
What counts as a "significant change" that triggers a new penetration test?
PCI DSS v4.0.1 describes significant changes as those that could affect the security of the cardholder data environment or the applicability of PCI DSS controls. Examples include adding new hardware, software or networking equipment to the CDE, replacing or upgrading major components, changes in how account data flows or is stored, changes to the CDE boundary or scope, changes to supporting infrastructure such as directory services or logging, and changes to third-party providers that support the CDE. Your methodology should define what your organisation treats as significant, and your change process should flag it.
Is an ASV scan the same as a penetration test?
No. An ASV scan (Requirement 11.3.2) is an automated external vulnerability scan performed at least once every three months by a PCI SSC Approved Scanning Vendor. A penetration test (11.4) is a manual, methodology-driven attempt to exploit weaknesses, chain findings and reach cardholder data, covering the application and network layers from inside and outside the network. Both are required; neither substitutes for the other.
What is segmentation testing and when is it required?
Segmentation testing verifies that the controls used to isolate the CDE from out-of-scope networks actually work. The tester attempts to reach CDE systems from every out-of-scope segment, using every segmentation method in use. It is required at least every 12 months and after any change to segmentation controls (11.4.5), and at least every six months for service providers (11.4.6). If you do not use segmentation to reduce scope, 11.4.5 does not apply, but then your entire network is in scope.
How recent does my penetration test report need to be for my assessment?
The QSA will expect the most recent test to fall within the last 12 months and to reflect the environment as it exists at assessment time. If a significant change occurred after the test, the QSA will expect evidence that the affected components were retested. Results and remediation records must be retained for at least 12 months, so the previous cycle should still be available.
For the standard as a whole, see our complete PCI DSS v4.0.1 guide; for how to scope and commission any penetration test, the penetration testing guide; and for the assessment itself, our PCI DSS compliance assessment service.