Reviewed by Sergio Martin for technical accuracy, clarity, and alignment with authorized security assessment practices.
August 13, 2026
PCI DSS Requirement 11.4 Explained
PCI DSS v4.0.1 addresses penetration testing under Requirement 11.4. Applicable requirements include internal and external penetration testing performed according to the entity’s defined methodology, at least once every 12 months, and after significant infrastructure or application changes.
Where segmentation is used to isolate the cardholder data environment (CDE) or reduce PCI DSS scope, applicable penetration testing must also evaluate the relevant segmentation controls. The testing requirements depend on the segmentation methods and the applicable PCI DSS provisions.
PCI DSS does not require the penetration test to be performed by a QSA or ASV. The testing can be performed by a qualified internal resource or qualified external third party, subject to the organizational independence requirements applicable to the tester.
What’s Covered
Cardholder Data Environment Testing
The assessment can cover systems and infrastructure within the defined cardholder data environment, including relevant network and application components that store, process, or transmit cardholder data.
The exact scope is established before testing begins according to the environment and applicable PCI DSS requirements.
External Penetration Testing
External testing evaluates the exposed perimeter of trusted networks and critical systems connected to or accessible from public network infrastructure.
PCI DSS Requirement 11.4.3 addresses external penetration testing performed at least once every 12 months and after applicable significant infrastructure or application changes.
Internal Penetration Testing
Internal testing evaluates security from inside the network and can include relevant systems, network components, access controls, and other infrastructure within the approved scope.
PCI DSS Requirement 11.4.2 addresses internal penetration testing at least once every 12 months and after applicable significant infrastructure or application changes.
Segmentation Testing
Where segmentation is used to isolate the CDE or reduce PCI DSS scope, penetration testing can evaluate whether the segmentation controls are operating effectively and isolating the CDE as intended.
The applicable testing frequency and scope depend on the segmentation controls and the requirements applicable to the environment.
E-commerce and Web Application Testing
Payment pages, e-commerce applications, and other public-facing applications can form part of the assessment where they are included in scope.
For dedicated application testing, see our web application penetration testing service.
API Security Testing
Applications that process payments through APIs may require API-focused assessment as part of a broader security program.
See our API security testing service for dedicated API assessment.
Network Security Testing
Where network infrastructure forms part of the assessment, internal network testing can help evaluate relevant systems and controls within the approved environment.
See our network penetration testing service for dedicated network assessment.
Our PCI DSS Penetration Testing Process
Scope and Authorization
The assessment begins by defining the applicable CDE, systems, applications, networks, environments, and testing objectives.
Written authorization and testing boundaries are established before testing begins.
Methodology and Planning
The testing methodology is aligned with the approved scope and relevant PCI DSS requirements.
The assessment considers the external and internal perspectives, applicable application-layer testing, network-layer testing, and segmentation controls where relevant. PCI DSS Requirement 11.4.1 addresses the defined penetration testing methodology.
Security Assessment
Testing combines appropriate automated techniques with manual security assessment within the authorized scope.
Potential findings are evaluated in the context of the systems and controls being assessed.
Finding Validation
Potential findings are reviewed and validated before being documented.
This helps reduce false positives and gives the organization clearer information about the security significance of identified weaknesses.
Reporting
The final report can document:
- Assessment scope
- Testing methodology
- Systems assessed
- Identified findings
- Severity or risk information
- Supporting evidence
- Potential impact
- Remediation recommendations
Remediation and Retesting
PCI DSS Requirement 11.4.4 addresses exploitable vulnerabilities and security weaknesses identified during penetration testing. These findings are corrected according to the entity’s assessment of the risk, and the penetration test is repeated to verify the corrections.
The exact retesting process and deliverables should be defined in the engagement.
What You Receive
Depending on the agreed scope, deliverables can include:
- Executive summary
- Detailed penetration testing findings
- Assessment scope and methodology
- Severity or risk information
- Affected systems or applications
- Supporting evidence
- Business impact context
- Remediation recommendations
- Segmentation testing results where applicable
- Retesting results where included
The objective is to provide documentation that can be reviewed by security teams and used as part of the organization’s broader PCI DSS compliance process.
PCI DSS Penetration Testing for Different Environments
PCI DSS environments can vary significantly between organizations.
A merchant or service provider may operate e-commerce applications, internal networks, payment APIs, cloud infrastructure, or a combination of technologies.
The appropriate penetration testing scope should therefore be based on the actual CDE, connected systems, security architecture, and applicable PCI DSS requirements.
Where cloud environments form part of the broader security boundary, cloud security testing can complement PCI-focused testing where appropriate.
PCI DSS Penetration Testing vs ASV Scanning
Penetration testing and ASV vulnerability scanning are separate security activities.
PCI DSS Requirement 11.3.2 addresses applicable external vulnerability scans performed by a PCI SSC Approved Scanning Vendor (ASV). Evidence of passing external scans may be required at least once every three months where the applicable requirement applies.
An ASV scan is not a substitute for penetration testing or for the other applicable PCI DSS requirements.
For that reason, organizations should evaluate their vulnerability scanning and penetration testing requirements separately within their PCI DSS program.
Who Needs PCI DSS Penetration Testing?
PCI DSS penetration testing may be relevant to merchants and service providers whose environments fall within the applicable PCI DSS requirements.
Organizations With Cardholder Data Environments
Businesses that store, process, or transmit payment card data may need to evaluate the systems and controls included within their applicable CDE scope.
E-commerce Businesses
Online businesses with payment-related applications or infrastructure may require assessment of relevant external, internal, and application security controls.
Payment-Related Service Providers
Service providers supporting payment environments may need documented security testing according to their applicable PCI DSS responsibilities.
Organizations Using Segmentation
Organizations relying on segmentation to reduce PCI DSS scope may need testing to validate that the segmentation controls are effective.
Frequently Asked Questions
How Often Does PCI DSS Require Penetration Testing?
Under PCI DSS v4.x, applicable internal and external penetration testing requirements call for testing at least once every 12 months and after applicable significant infrastructure or application changes. The precise requirements depend on the applicable PCI DSS provisions and the organization’s environment.
Is Penetration Testing Required by PCI DSS?
PCI DSS includes penetration testing requirements under Requirement 11.4 for applicable entities and environments. The exact testing obligations depend on the requirements applicable to the organization’s PCI DSS scope.
Does PCI DSS Require a QSA to Perform the Penetration Test?
No. PCI DSS allows penetration testing to be performed by a qualified internal resource or qualified external third party, with the required organizational independence. A QSA or ASV is not specifically required to perform the penetration test.
Do You Test Segmentation?
Segmentation testing can be included where segmentation is used to isolate the CDE or reduce PCI DSS scope.
The assessment should verify whether the relevant segmentation controls are operating effectively according to the applicable PCI DSS requirements.
Is PCI DSS Penetration Testing the Same as an ASV Scan?
No. ASV scanning and penetration testing are separate activities within the PCI DSS framework. Applicable external vulnerability scans must be performed by a PCI SSC Approved Scanning Vendor, while penetration testing follows the applicable Requirement 11.4 requirements.
Can You Test Web Applications and APIs?
Yes, where those applications and APIs are included in the authorized assessment scope.
Web application and API testing can complement broader PCI DSS penetration testing when those components are relevant to the environment.
Do You Test Production Environments?
Production testing may be considered when appropriate, but it should be carefully scoped and performed according to agreed Rules of Engagement and safeguards.
Do You Provide Retesting?
Retesting can be included as part of the engagement to verify that previously identified security weaknesses have been addressed. PCI DSS Requirement 11.4.4 specifically addresses repeating penetration testing to verify corrections.
Request a PCI DSS Penetration Testing Assessment
Preparing for a PCI DSS assessment or need independent testing of your cardholder data environment?
Tell us about your CDE, applications, network infrastructure, segmentation, and assessment objectives.
We can help define an appropriate PCI DSS penetration testing scope based on your environment and applicable requirements.
Confidential consultation · Authorized security testing · Professional reporting