● Australia Based · Operating Internationally · OSCE / OSCP Certified
☏ 1300 859 443

PCI DSS Penetration Testing: What Requirement 11.4 Asks For

Cardholder data environment walled off from the wider network, its segmentation boundary probed from inside and out

PCI DSS v4.0.1 Requirement 11.4 asks for internal and external penetration tests at least once every 12 months and after any significant change, run to a documented, industry-accepted methodology. If you rely on segmentation to shrink your cardholder data environment, that gets tested too. Exploitable findings are corrected in line with your risk ranking, then the test is repeated to confirm the fix.

What is PCI?

Payment Card Industry Data Security Standard (PCI-DSS), or just PCI for short, is a set of security standards designed to ensure that all companies that accept, process, store or transmit credit card information maintain a secure environment.

The PCI DSS standard is administered by the PCI Security Standards Council (PCI-SSC) which is an independent body set up by the major credit card brands; (Visa, MasterCard, American Express, Discover and JCB.) The current version is PCI DSS v4.0.1. PCI SSC retired v4.0 on 31 December 2024, so v4.0.1 is the only active version.

NOTE: It is these credit brands which are responsible for enforcing compliance, and not the PCI-SSC.

What is the penetration testing requirement for PCI?

PCI DSS v4.0.1 Requirement 11.4 says external and internal penetration testing is performed regularly, and exploitable vulnerabilities and security weaknesses are corrected. PCI DSS is meant for every organisation that stores, processes or transmits cardholder data, or could affect its security. Whether you have to validate against it, and how, is set by the card brands and your acquirer. Under v3.2.1 this was Requirement 11.3, which is why older guides still quote that number.

PCI Penetration tests are required for both application and network components of the Cardholder Data Environment (CDE), the entire CDE perimeter, and any critical component which may impact the security of the CDE. This includes testing to ensure the proper segmentation of the CDE from out of scope systems.
The CDE is defined by PCI-DSS as;

“the people, processes, and technology that store, process, or transmit cardholder data or sensitive authentication data”

The requirement also states that a penetration testing methodology must be implemented and based upon an industry accepted model such as NIST SP 800-115, OWASP Testing Guide, Open Source Security Testing Methodology Manual (“OSSTMM”), PTES or PTF.

What sits under 11.4? 11.4.1 defines the methodology: industry-accepted, covering the whole CDE perimeter and critical systems, tested from inside and outside the network, at both the application and network layers, with results kept for at least 12 months. 11.4.2 and 11.4.3 set internal and external testing at least once every 12 months and after significant change. 11.4.4 has exploitable findings corrected according to your risk ranking (Requirement 6.3.1), then retested to confirm the fix. 11.4.5 covers segmentation testing, and 11.4.6 makes it every six months for service providers. 11.4.7 asks multi-tenant service providers to support their customers’ external testing.

In v4.0.1, public-facing web applications are covered by Requirement 6.4. 6.4.1 allowed a review at least once every 12 months and after significant change, or an automated attack-detection solution. From 31 March 2025, 6.4.2 requires the automated solution for public-facing web apps. A web application penetration test is still how you find the flaws a filter only blocks.

Who can perform penetration testing for PCI?

According to Penetration Testing Guidance from the PCI Security Standards Council, the penetration tester must be both qualified and organisationally independent.

Organisationally independent means that the pen tester must not be associated in any way with either the implementation of the PCI environment, or its day to day operations, management, or support.

For the purpose of a qualified penetration tester, PCI DSS does not set a requirement for this, but recommends guidelines such as certifications and past experience of the penetration tester.

PCI references the following penetration testing certifications as indicators of skill level required for PCI penetration testing:

How often does PCI DSS require penetration testing?

Under Requirements 11.4.2 and 11.4.3, internal and external penetration tests run at least once every 12 months and after any significant infrastructure or application upgrade or change. Segmentation tests run every 12 months and after any change to segmentation controls, or every six months if you are a service provider.

PCI penetration testing guidance gives example of what is considered a significant change such as; infrastructure or application upgrade or modification, or new system component installations. But PCI-DSS does not prescribe exactly what defines a significant change as it is variable based upon the risk assessment of the said environment and its configuration.

    If the change could impact the security of the network or allow access to cardholder data, it may be considered significant.
PCI DSS 11.4 cadence: internal, external and segmentation penetration tests every 12 months and after significant change
Requirement 11.4 cadence at a glance (PCI DSS v4.0.1).

How are PCI vulnerability scans different from a penetration test?

In v4.0.1 vulnerability scanning moved to Requirement 11.3: internal scans (11.3.1) and external scans by an Approved Scanning Vendor (11.3.2), each at least once every three months and after significant change. Under v3.2.1 this was 11.2, which the quote below comes from.

Run internal and external network vulnerability scans at least quarterly and after any significant change in the network (such as new system component installations, changes in network topology, firewall rule modifications, product upgrades).”

There is a big difference between internal and external vulnerability scanning for PCI:

For Internal vulnerability scans you must verify that four quarterly internal scans took place in the past 12 months and that rescans occurred until all “high-risk” vulnerabilities as defined by requirement 6.1 were resolved.

External scans, like internal ones, must be done at least quarterly. The difference is that the external scan must be done via an an Approved Scanning Vendor (ASV) approved by the Payment Card Industry Security Standards Council (PCI SSC).

ASV vulnerability scan compared with a PCI DSS penetration test: who runs it, what it covers and how often
A clean ASV scan doesn’t satisfy 11.4.

Summary

Core Sentinel’s penetration tests are scoped to PCI DSS v4.0.1 Requirement 11.4: internal and external infrastructure, segmentation, and web applications.

Our penetration testing consultants meet both the experience, and the certification recommendations as set out in the PCI SSC’s Penetration Testing Guidance. We are able to assist you with both PCI penetration testing, and PCI vulnerability scanning.

Ask one of our OSCE / OSCP qualified consultants for a fixed-price quote scoped to your cardholder data environment.

PCI DSS penetration testing FAQ

Does the tester have to be a QSA?

No. PCI SSC’s Penetration Testing Guidance says a qualified internal resource or a qualified third party can test, as long as they are organisationally independent of the environment.

Can our own IT team do the test?

Only if they are organisationally separate from building, running and supporting the cardholder data environment. Most teams that size can’t show that, which is why the test usually goes to a third party.

Does a quarterly ASV scan count as a penetration test?

No. An ASV scan is automated and covers the external surface (11.3.2). A penetration test is a person trying to exploit what the scan and the design leave open.

What is a “significant change”?

It depends on your environment, but PCI DSS v4.0.1 lists changes you must at least evaluate: new hardware, software or network equipment in the cardholder data environment; replacements or major upgrades; changes to how account data flows or is stored; changes to the environment’s boundary or assessment scope; changes to supporting infrastructure such as directory, time, logging and monitoring services; and changes to third-party providers that support it.

References

Other articles you may like:

Penetration Testing for GDPR Compliance

Definitive Guide to Penetration Testing

Characteristics of a Good Penetration Tester