Adhering to the Payment Card Industry Data Security Standard (PCI DSS) is required for organizations that store, process, or transmit cardholder data, or that can impact its security.
For many merchants, payment processors, SaaS companies, fintech platforms, and service providers, this means running regular security testing against the cardholder data environment (CDE). Two of the most common testing activities are vulnerability scanning and penetration testing.
They are related, but they are not the same.
A PCI DSS vulnerability scan helps identify known vulnerabilities, misconfigurations, and exposed services. A PCI DSS penetration test goes further by validating whether weaknesses can be exploited and whether an attacker could use them to compromise systems, move through the environment, or access cardholder data.
In this guide, we explain how PCI DSS penetration testing works, what Requirement 11.4 expects, how penetration testing differs from vulnerability scanning, how often testing is required, and what your report should include for compliance and audit readiness.
We have also published a separate article on the common vulnerabilities and findings we encounter in PCI DSS penetration testing assessments, based on a study of more than 660 pentests performed by Blaze in 2025.
What is PCI penetration testing?
PCI penetration testing is a security assessment focused on the systems, applications, networks, APIs, and segmentation controls that make up or support an organization’s cardholder data environment.
The goal is to test whether exploitable vulnerabilities or security weaknesses could affect the confidentiality, integrity, or availability of cardholder data.
In PCI DSS v4.x, penetration testing is primarily addressed under Requirement 11.4: external and internal penetration testing is regularly performed, and exploitable vulnerabilities and security weaknesses are corrected.
A PCI DSS penetration test usually includes:
- Internal penetration testing
- External penetration testing
- Application-layer testing
- Network-layer testing
- Segmentation testing, if segmentation is used to reduce the PCI scope
- Retesting of exploitable findings after remediation
- Documentation suitable for audit or QSA review
The main objectives of PCI DSS penetration testing are:
Identifying exploitable vulnerabilities
A PCI penetration test should identify weaknesses that could be exploited to compromise systems in or connected to the CDE. This includes exposed services, insecure applications, weak access controls, misconfigurations, authentication flaws, and network paths that should not exist.
Validating security controls
A penetration test helps verify whether security controls are working as intended. This includes network segmentation, firewall rules, authentication controls, access restrictions, monitoring coverage, and application-layer defenses.
Supporting PCI DSS compliance
The test provides evidence that the organization has conducted internal and external penetration testing in accordance with a defined methodology and has corrected exploitable weaknesses.
Prioritizing remediation
A PCI DSS penetration test should help teams focus on the issues that matter most. Findings should be ranked by risk, exploitability, business impact, and potential effect on cardholder data.
Improving security over time
PCI DSS penetration testing is not only an audit exercise. When done properly, it helps teams understand how their environment can be attacked and how to reduce real risk across applications, infrastructure, and payment flows.
PCI penetration testing process
Scope definition
Every PCI DSS penetration test should start with a scope. Before testing begins, the organization and penetration testing provider need to identify the systems, applications, APIs, networks, cloud assets, endpoints, and third-party connections that store, process, transmit, or could impact the security of cardholder data.
This is where many PCI testing projects go wrong. If the scope is too narrow, the test may miss systems that can affect the CDE. For example, testing only a public-facing payment page may not be enough if internal APIs, administrative interfaces, cloud networks, or segmentation controls also support the payment environment.
The scope should include the CDE itself, the CDE perimeter, critical systems, and any connected systems that could create a path into the CDE. It should also define what is out of scope and why.
External and internal penetration testing (networks and applications)
PCI DSS-focused penetration testing should evaluate external and internal attack surfaces to identify potential vulnerabilities and validate security controls, following the pentesting guidance outlined by the PCI Security Standards Council
External penetration testing targets systems and services at the perimeter that are accessible from the internet, such as public-facing networks, servers, web applications, and APIs. This type of testing helps uncover security risks that external attackers could exploit to gain unauthorized access to cardholder data or disrupt services.
Internal testing, as the name implies, focuses on the organization’s internal network, applications, and critical systems in the CDE scope. This testing aims to identify flaws that could be exploited by insiders and threat actors who have breached the external perimeter.
Network segmentation testing
Segmentation testing is an essential component of PCI DSS, specifically targeting organizations that implement network segmentation to isolate their CDEs from other networks. The primary goal of segmentation testing is to verify the effectiveness of the implemented controls and ensure they are robust enough to prevent unauthorized access to the CDE.
Segmentation tests must be executed twice per year. The PCI Security Standards Council created comprehensive guidance on segmentation, which is the authoritative reference on the topic.
Documentation and reporting
Maintaining detailed documentation and reporting of the assessment is crucial for demonstrating PCI DSS compliance. The PCI penetration test report should include clear information about the test scope, penetration testing methodology, details about all identified vulnerabilities, remediation recommendations, and retest results. Organizations should retain these reports as evidence of compliance during PCI DSS audits.
In our experience, some auditors may also request that the report include the exact date and time a vulnerability was identified and exploited, as well as the same information for when it was marked as fixed after retesting.
Understanding PCI penetration testing requirements
PCI DSS Requirement 11 focuses on regularly testing the security of systems and networks within the CDE environment for organizations that handle cardholder data.
For PCI DSS penetration testing, the most relevant section is Requirement 11.4.
A common source of confusion is the change in numbering between PCI DSS 3.2.1 and PCI DSS v4.x. In PCI DSS 3.2.1, penetration testing was covered under Requirement 11.3. In PCI DSS v4.x, penetration testing moved to Requirement 11.4.
This means older articles, reports, and audit notes may still refer to Requirement 11.3 when discussing penetration testing. For current PCI DSS v4.x assessments, the key penetration testing requirement is 11.4.
For the purposes of pentesting, the following sub-items of Requirement 11 are important to be addressed:
PCI DSS Requirement 11.3 is the cornerstone of penetration testing within PCI DSS 3.2.1, ensuring organizations safeguard their CDEs through comprehensive and regular security assessments. The norm says that security testing must be performed based on recognized industry methodologies – it explicitly mentions NIST SP 800-115, but others, such as OSSTMM, OWASP and PTES, also apply, per 4.4 in Penetration Testing Guidance.
The requirement is divided into three primary components: addressing network penetration testing, internal penetration testing, and segmentation controls.
Firstly, Requirement 11.3.1 focuses on external network penetration testing, emphasizing that organizations must test their internet-facing servers and networks to identify vulnerabilities that could be exploited by external adversaries. By conducting an annual network penetration test, businesses can proactively identify security weaknesses and implement appropriate measures to protect sensitive cardholder data.
Next, Requirement 11.3.2 pertains to internal penetration testing, requiring organizations to evaluate their internal systems, networks, and applications for potential security gaps. Internal penetration testing plays a crucial role in uncovering risks that may not be visible from the outside but could be exploited by an insider or an attacker who has already gained access to the internal network. It needs to be done at least once per year.
Requirement 11.3.3 addresses retesting and emphasizes the need for timely remediation.
Finally, Requirement 11.3.4 addresses the need to test segmentation controls if an organization uses network segmentation as a method to isolate its CDE from other networks. This requirement ensures that network isolation controls are functioning effectively and that there is no unauthorized access to the CDE.
Other security-relevant requirements of item 11 are the following:
Requirement 11.1 intends to ensure the security of an organization’s wireless networks within or connected to the cardholder data environment. The main focus is on rogue access points, and sweeps must be conducted quarterly.
Requirement 11.2 defines rules for running internal and external network vulnerability scans at least quarterly and after any significant change in the network. There are rules that require (or allow) the use of a PCI-approved scanning vendor to perform such scans.
Requirement 6 (Develop and maintain secure systems and applications) of PCI DSS is equally important for security testing, particularly requirements 6.5.1 through 6.5.6 (based on secure development practices) and 6.6 (testing).
Requirement 6.6 explicitly mentions that companies seeking PCI DSS compliance must perform security evaluations of public-facing web applications (and APIs, per 4.2.1 Application Layer) using manual testing or automated tools for application vulnerability scanning at least annually and after any relevant changes.
OWASP Top 10 and OWASP ASVS are the most popular methodologies for application-layer testing and security of web applications/APIs, and they are, without a doubt, the most relevant penetration testing methodologies for this item.
An important note above is that the vulnerability scans in Requirement 11.2 are not the same as the assessments needed to address 6.6.
In PCI DSS 4.0, the requirement for web application security testing has changed to Requirement 6.4 (Public-facing web applications are protected against attacks).
We have created an infographic to visually illustrate these requirements:
PCI penetration testing frequency
PCI DSS penetration testing should generally be performed at least once every 12 months and after any significant infrastructure or application upgrade or change.
A significant change could include a new payment application, a major application release, a new payment API, a cloud migration, firewall or segmentation changes, new third-party connectivity, a major platform upgrade, or any change that affects how cardholder data is stored, processed, transmitted, or protected.
The exact definition depends on the environment. A useful rule is this: if a change could affect the security of the CDE or create a new path to cardholder data, it should be reviewed for its impact on PCI DSS testing.
Remediation and retesting process
After the penetration test, the organization should prioritize and remediate findings based on risk, exploitability, and potential impact on the CDE.
Fixing the issue is only part of the process. The fix should also be validated. Retesting provides evidence that exploitable vulnerabilities and security weaknesses were corrected.
This evidence is important for compliance review. A report that lists findings but does not indicate whether exploitable issues have been fixed may create problems during an audit or QSA assessment.
What is the difference between a PCI penetration test and a regular pentest?
A PCI penetration test and a regular penetration test use many of the same testing techniques, but they differ in scope, purpose, reporting, and compliance expectations.
A regular penetration test may focus on a single application, API, cloud environment, network, product, or business-critical system. The scope is usually defined by the organization’s security priorities.
A PCI penetration test focuses on the cardholder data environment and systems that can affect cardholder data security. It must address PCI DSS expectations for internal testing, external testing, segmentation testing where applicable, methodology, remediation, and evidence retention.
Key differences between PCI DSS penetration testing and regular penetration testing
| Area | PCI DSS penetration test | Regular penetration test |
| Primary purpose | Validate the security of the CDE and support PCI DSS compliance | Identify security weaknesses in a defined target or environment |
| Scope | CDE, CDE perimeter, critical systems, connected systems, segmentation controls | Defined by business risk, product scope, or security objectives |
| Frequency | At least annually and after significant changes | Based on the internal security program, risk appetite, customer requirements, or release cadence |
| Reporting | Must support compliance and audit review | May be more flexible depending on the audience |
| Retesting | Expected for exploitable findings | Strongly recommended, but not always required by a framework |
| Segmentation testing | Required if segmentation is used to reduce PCI DSS scope | Usually not required unless included in scope |
| Methodology | Must be defined, documented, and aligned with accepted approaches | Methodology may vary by provider and objective |
Both types of testing are valuable. The key is to make sure the PCI DSS penetration test is scoped and reported in a way that satisfies Requirement 11.4, rather than treating a generic pentest report as automatically PCI-ready.
PCI penetration testing vs PCI vulnerability scanning
A PCI vulnerability scan is not the same as a PCI penetration test.
Vulnerability scanning is usually broader and more automated. It identifies known vulnerabilities, missing patches, weak configurations, exposed services, and other security issues.
Penetration testing is more manual and adversarial. It attempts to validate exploitability, link chain weaknesses, and determine what an attacker could actually achieve.
| Area | Vulnerability scan | Penetration test |
| Main goal | Identify known vulnerabilities and misconfigurations | Validate exploitability and attack paths |
| PCI DSS section | Requirement 11.3 | Requirement 11.4 |
| Frequency | At least quarterly and after significant changes, depending on scan type | At least annually and after significant changes |
| External requirement | External scans may require an ASV | Tester must be qualified and independent; not required to be a QSA or ASV |
| Method | Mostly automated, with validation | Manual testing supported by tools |
| Output | Vulnerability scan report | Exploitation evidence, impact analysis, remediation guidance, and retest evidence |
| Compliance role | Required security testing activity | Separate required security testing activity |
Most organizations subject to PCI DSS need both activities. A passing ASV scan does not prove that a penetration test was performed, and a penetration test does not replace required vulnerability scans.
Key differences between PCI DSS 4.x and PCI DSS 3.2.1
The core idea behind PCI penetration testing has not changed: organizations need to test their environments, identify exploitable weaknesses, fix them, and verify remediation.
However, PCI DSS v4.x changed how the requirements are organized and clarified several expectations.
The most important change is numbering. Penetration testing moved from Requirement 11.3 in PCI DSS 3.2.1 to Requirement 11.4 in PCI DSS v4.x.
Other important changes and clarifications include:
- More explicit expectations for a documented penetration testing methodology
- Clearer internal and external testing requirements
- Clearer segmentation testing expectations
- More emphasis on application-layer and network-layer testing
- Retention of penetration testing and remediation results for at least 12 months
- Explicit use of authenticated internal vulnerability scanning under Requirement 11.3.1.2
- Newer requirements around payment page change and tamper detection under Requirement 11.6
- More focus on roles, responsibilities, targeted risk analysis, and continuous security processes
For current assessments, organizations should work from PCI DSS v4.0.1 or the version in force at the time of assessment. References to PCI DSS 3.2.1 should be treated as historical unless an auditor is reviewing older evidence.
For instance, it now states, “Testing from inside the network (or ‘internal penetration testing’) means testing from both inside the CDE and into the CDE from trusted and untrusted internal networks” and “Testing from outside the network (or ‘external penetration testing’) means testing the exposed external perimeter of trusted networks, and critical systems connected to or accessible to public network infrastructures.”, to properly define what PCI means when it says internal and external pentesting and from which vantage point it must be executed.
Another item worth mentioning is “11.3.1.2 Internal vulnerability scans are performed via authenticated scanning.” – before that, there was no explicit requirement for grey-box automated testing or for scans to be authenticated; now it ensures the vulnerability scanner covers a larger surface area.
In our opinion, the most significant introduction in 4.0 was 11.6, Unauthorized changes on payment pages are detected and responded to. This item was introduced to prevent code tampering in e-commerce platforms and combat JavaScript-based skimming, known as Magecart attacks, such as the one that impacted British Airways in 2020.
Common tools used in PCI penetration testing
In PCI penetration testing, a wide range of tools is employed to assess the security of the CDE environment and identify potential vulnerabilities that attackers could exploit.
These tools are crucial in evaluating various aspects of an organization’s security posture, including network configurations, web applications, wireless networks, and system vulnerabilities. The choice of tools may vary depending on the specific needs and goals of the penetration test, but some commonly used tools in a PCI penetration test include:
- Nmap: For network scanning and discovery of open ports and services, as well as segmentation checks.
- Nessus: To automate the process of identifying known vulnerabilities in systems, networks, and applications. It can also be used for ASV scans, as it can perform PCI vulnerability scanning.
- Metasploit: A comprehensive exploitation framework for developing and executing exploit code against identified vulnerabilities.
- Burp Suite: A powerful web application security testing tool with features such as an intercepting proxy, web vulnerability scanning, and session manipulation.
- Wireshark: A network protocol analyzer for capturing and analyzing network traffic, providing valuable insights into potential vulnerabilities and attack vectors. Particularly useful for verifying whether card data is traversing the network unencrypted.
- Memory scraping tool: A regex-based RAM scraping tool can be useful in PCI security testing to identify credit card data temporarily stored in the memory of a CDE-located server once the pentester has compromised it.
The list above is non-exhaustive, and several other tools can be used depending on the assessment’s needs.
What should a PCI penetration test report include?
A PCI DSS penetration test report should help three audiences:
- Technical teams that need to fix the issues
- Security leaders who need to understand risk
- Auditors or QSAs who need evidence that testing was performed properly
At a minimum, the report should include the scope, test dates, rules of engagement, methodology, internal and external testing coverage, application and network testing coverage, segmentation testing details where applicable, findings, evidence, impact, severity, remediation guidance, and retest status.
For PCI DSS, reporting should be specific enough to show that testing covered the CDE, critical systems, and segmentation controls where applicable.
Engaging a qualified penetration testing company
PCI DSS does not require the penetration tester to be a QSA or ASV. However, the tester must be qualified, and organizational independence must exist.
That means the test should not be performed by someone responsible for managing, developing, or maintaining the systems being tested.
When choosing a PCI penetration testing provider, look for experience in testing payment environments, familiarity with PCI DSS Requirement 11.4, application and network testing capability, segmentation testing experience, clear rules of engagement, evidence-based reporting, retesting support, and relevant credentials such as CREST, OSCP, OSWE, GPEN, GWAPT, or similar.
A good provider should help you scope the engagement properly, explain what evidence the report will contain, and avoid treating a generic vulnerability scan as a PCI DSS penetration test.
To help organizations navigate supplier selection, we have created a complete guide to choosing the right penetration testing company.
Read our guide to choosing a penetration testing company.
How can Blaze help with your PCI penetration testing requirements?
At Blaze, we have our roots in providing penetration testing services for the financial sector, including banking and payments. We have performed dozens of PCI pentesting assessments throughout the years.
Blaze can support PCI DSS internal penetration testing, external penetration testing, segmentation testing, web application and API penetration testing, network penetration testing, cloud environment testing, retesting, remediation validation, QSA-ready reporting, and CREST-accredited penetration testing engagements.
If you’re ready to invest in your business’s security and compliance and are looking for a pentesting provider with relevant experience conducting PCI DSS assessments, we invite you to contact our experts to discuss how we can help you achieve your security objectives.
Conclusion
PCI DSS penetration testing is a core part of protecting cardholder data and demonstrating compliance.
Under PCI DSS v4.x, organizations need to pay close attention to Requirement 11.4, which covers internal and external penetration testing, methodology, remediation, retesting, segmentation testing, and evidence retention.
The most common mistake is treating a vulnerability scan, ASV scan, or generic pentest as a complete PCI DSS penetration test. These activities overlap, but they do not serve the same purpose.
A strong PCI DSS penetration test should be properly scoped around the cardholder data environment, performed by qualified and independent testers, include application-layer and network-layer testing, validate segmentation where applicable, and provide clear evidence that exploitable weaknesses were corrected.
For merchants, service providers, SaaS companies, fintech platforms, and any organization handling payment data, PCI penetration testing should be treated as both a compliance requirement and a practical way to reduce payment security risk.
FAQ
Does PCI require penetration testing?
Yes, PCI requires penetration testing per Requirements 11.3 and 6.6 in PCI 3.2.1, and per Requirements 11.4 and 6.4 in PCI 4.0.
How often does PCI require penetration testing?
PCI pentesting is mandatory once a year or whenever there is a major change to networks, servers or systems.
When does PCI DSS 4.0 go into effect?
PCI DSS 4.0 went into effect on March 31, 2024, and organizations had until March 31, 2025, to phase in new requirements.
What PCI DSS requirement covers penetration testing?
In PCI DSS v4.x, penetration testing is covered under Requirement 11.4. In PCI DSS 3.2.1, penetration testing was covered under Requirement 11.3. This numbering change is important because older reports, guides, and audit notes may still refer to Requirement 11.3 when discussing penetration testing.
Is a PCI vulnerability scan the same as a PCI penetration test?
No. A vulnerability scan identifies known vulnerabilities and misconfigurations. A penetration test validates whether weaknesses can be exploited and whether an attacker could use them to compromise systems or access cardholder data. PCI DSS treats vulnerability scanning and penetration testing as separate security testing activities.
Is an ASV scan enough for PCI DSS penetration testing?
No. An ASV scan is an external vulnerability scan performed by a PCI SSC-approved scanning vendor. It does not replace the need for penetration testing under Requirement 11.4 where penetration testing applies.
Who can perform a PCI DSS penetration test?
A PCI DSS penetration test can be performed by a qualified internal resource or a qualified external third party, provided organizational independence exists. The tester does not need to be a QSA or ASV, but they should have relevant penetration testing skills, experience, and methodology.
What changed from PCI DSS 3.2.1 to PCI DSS v4.x for penetration testing?
The core requirement to perform penetration testing remains, but the numbering changed from Requirement 11.3 in PCI DSS 3.2.1 to Requirement 11.4 in PCI DSS v4.x. PCI DSS v4.x also provides clearer expectations for methodology, internal and external testing, segmentation validation, risk-based remediation, evidence retention, and payment page security.
