01. Requirement 11.4 at a Glance
In PCI DSS v4.0.1, penetration testing is structured into seven distinct sub-requirements designed to ensure comprehensive evaluation of the Cardholder Data Environment (CDE):
| Requirement | Subject Matter | Mandatory Cadence & Scope |
|---|---|---|
| 11.4.1 | Documented Testing Methodology | Maintained, documented, and aligned with industry-accepted frameworks (NIST SP 800-115, OWASP). |
| 11.4.2 | Internal Penetration Testing | At least once every 12 months and after any significant infrastructure or application change. |
| 11.4.3 | External Penetration Testing | At least once every 12 months and after any significant change to internet-facing perimeters or APIs. |
| 11.4.4 | Remediation and Delta Retesting | Mandatory retesting to verify that all exploitable vulnerabilities were corrected. |
| 11.4.5 | Segmentation Testing (Merchants) | At least once every 12 months and after any change to segmentation controls or methods. |
| 11.4.6 | Segmentation Testing (Service Providers) | At least once every 6 months and after any change to segmentation controls. |
| 11.4.7 | Multi-Tenant Cloud Isolation | Third-party cloud providers must allow and support tenant-level external penetration testing. |
02. Documented Methodology (Requirement 11.4.1)
PCI DSS does not permit ad-hoc scanning. Requirement 11.4.1 mandates a formal, documented testing methodology incorporating eight explicit criteria:
Mandatory Methodology Components
- Covers the entire CDE perimeter and all critical systems that could impact cardholder data security.
- Testing executed from both inside and outside the corporate network perimeter.
- Active validation of network segmentation and scope-reduction controls.
- Application-layer testing covering at least the common vulnerabilities defined in Requirement 6.2.4 (SQLi, XSS, SSRF, BOLA/IDOR).
- Network-layer testing of all supporting components, firewalls, routers, and host operating systems.
- Incorporation of threats and vulnerabilities identified during the preceding 12 months.
- Documented risk-ranking methodology to classify and remediate exploitable flaws.
- Retention of penetration test reports and retest evidence for at least 12 months.
03. Internal & External Testing (11.4.2 & 11.4.3)
Testing must simulate authentic external and internal threat actors:
Internal Penetration Testing
Evaluates the security of internal corporate LANs, administrative workstations, and developer environments with access to the CDE. Assesses whether an insider or compromised workstation could pivot into cardholder databases.
External Penetration Testing
Evaluates internet-facing payment web portals, checkout pages, and authorization APIs. Tests whether an external attacker could compromise the perimeter, steal card data, or modify checkout scripts.
04. Remediation & Retesting (Requirement 11.4.4)
A penetration test is not complete until every identified exploitable vulnerability has been remediated and independently retested:
Closed-Loop Validation Mandate
Requirement 11.4.4 explicitly mandates that organizations correct all vulnerabilities that allow unauthorized access or compromise of cardholder data, followed by repeated penetration testing to verify the corrections. Providing a QSA with open findings or unvalidated patches will result in non-compliance.
05. Segmentation Validation (11.4.5 & 11.4.6)
If an entity uses network segmentation (VLANs, firewalls, cloud security groups) to isolate the Cardholder Data Environment from out-of-scope networks, segmentation controls must be validated through active penetration testing:
Merchants (11.4.5)
Segmentation controls must be tested at least once every 12 months, and following any change to segmentation controls or methods.
Third-Party Service Providers (11.4.6)
Third-party service providers must test segmentation controls at least once every six months, and following any change to segmentation methods.
06. Multi-Tenant Cloud Providers (Requirement 11.4.7)
In multi-tenant cloud hosting environments, Requirement 11.4.7 mandates that service providers must allow and facilitate tenant-initiated external penetration testing, ensuring that merchants can validate their own application layer without breaching cloud terms of service.
07. What Counts as a Significant Change?
Under PCI DSS v4.0.1, penetration testing cannot remain a once-a-year event. Any "significant change" mandates immediate retesting:
Architectural Upgrades
Migrating payment processing workloads to a new cloud provider or deploying new container clusters.
New API Integrations
Connecting new payment gateways, tokenization providers, or banking webhooks to the CDE.
Major Application Releases
Overhauling checkout flows, customer account authentication logic, or checkout page JavaScript libraries.
08. How Infiltra Automates PCI DSS Penetration Testing
Automated Application-Layer Pentesting
Test payment web applications, checkout flows, and backend APIs on demand after every release, satisfying Requirements 11.4.3 and 6.2.4.
Instant Delta Retesting (11.4.4)
When developers patch a vulnerability, trigger an automated delta retest with 1 click to generate verified proof of fix for your QSA.
Eliminate False Positives
Every vulnerability detected by Infiltra includes verifiable proof-of-concept execution evidence, ensuring zero wasted time triaging scanner noise.
QSA-Ready Letters of Attestation
Export comprehensive technical dossiers and formal Letters of Attestation detailing testing methodologies and vulnerability closure dates.
09. Frequently Asked Questions
Direct technical clarifications on PCI DSS v4.0.1 Requirement 11.4 testing mandates.
Requirement 11.4
How Often Does PCI DSS Require Penetration Testing?
How Often Does PCI DSS Require Penetration Testing?
Under PCI DSS v4.0.1, internal and external penetration testing must be performed at least once every 12 months and after any significant infrastructure or application change. Network segmentation controls must be tested at least every 12 months for merchants, and at least every 6 months for third-party service providers.
Tester Qualifications
Does a PCI DSS Penetration Test Have to Be Done by a QSA?
Does a PCI DSS Penetration Test Have to Be Done by a QSA?
No. The tester does not need to be a Qualified Security Assessor (QSA) or Approved Scanning Vendor (ASV). Testing can be performed by qualified internal personnel or an external firm, provided the tester has demonstrated competence and organizational independence from network administrators.
Scanning vs Testing
Is an ASV Vulnerability Scan the Same as a Penetration Test?
Is an ASV Vulnerability Scan the Same as a Penetration Test?
No, they are separate and complementary requirements. ASV quarterly scans (Requirement 11.3) look for known vulnerability signatures without active exploitation. Penetration testing (Requirement 11.4) actively simulates attacker techniques to exploit weaknesses and test whether segmentation controls hold up against multi-step compromise.
Autonomous Testing
Can Automated AI Penetration Testing Be Used for PCI DSS?
Can Automated AI Penetration Testing Be Used for PCI DSS?
Yes. Autonomous AI testing platforms like Infiltra enable continuous, on-demand testing of payment applications and APIs before release, providing verifiable exploit proof and 1-click delta retests that satisfy Requirement 11.4.4.