PCI DSS has some of the most precise penetration testing requirements of any compliance framework. Unlike SOC 2, which creates the obligation indirectly through Trust Service Criteria, PCI DSS spells out what must be tested, how often, by whom, and what the test must cover. The specificity is an advantage: if you understand Requirement 11.4 in detail, you know exactly what evidence your QSA will look for.
This post covers every sub-requirement under Requirement 11.4 in PCI DSS v4.0, explains what each demands in practice, clarifies the significant-change trigger that catches many organisations off guard, and maps what a compliant testing program needs to produce as evidence.
PCI DSS v4.0 became effective in March 2024, with PCI DSS v3.2.1 retiring in March 2024. The penetration testing requirements moved from Requirement 11.3 in v3.2.1 to Requirement 11.4 in v4.0 with several material changes.
The most significant v4.0 update is the explicit requirement that penetration testing methodology be documented and that the organisation's approach to testing be validated against a recognised methodology such as the PTES (Penetration Testing Execution Standard), OWASP Testing Guide, NIST SP 800-115, or the PCI Security Standards Council's own Penetration Testing Guidance document.
v4.0 also strengthened the requirements around who can conduct the test. External penetration testing must be performed by a qualified internal resource with organisational independence or by a qualified external third-party. Internal penetration testing has the same independence requirement. The days of a developer testing the system they built satisfying PCI penetration testing requirements are over.
What it requires: External penetration testing must be performed at least once every twelve months and after any significant infrastructure or application upgrade or change.
External penetration testing under PCI DSS must test from an external, internet-facing perspective. The scope includes all external-facing components of the cardholder data environment (CDE) and systems that could be used to reach the CDE from outside the organisation's network perimeter: web applications, APIs, authentication endpoints, remote access solutions, and any internet-accessible service that connects to or could be pivoted toward systems that store, process, or transmit cardholder data.
What QSAs examine: QSAs reviewing the external penetration test evidence look for scope documentation that maps tested systems to the systems described in the CDE scope. If the network diagram shows ten internet-facing systems in or connecting to the CDE and the penetration test covers three of them, the QSA will ask why. Systems excluded from scope require explicit documented justification.
The test must also cover the application layer, not just the network perimeter. A firewall and port scan is not an external penetration test under PCI DSS. Web application security testing, API security testing, and authentication mechanism testing are all components of a complete external assessment. What a real web application penetration test should cover maps the twelve dimensions that thoroughness requires, all of which are relevant to PCI external testing scope.
What it requires: Internal penetration testing must be performed at least once every twelve months and after any significant infrastructure or application upgrade or change.
Internal penetration testing tests from within the network, simulating an attacker who has already gained access to the internal environment. The scope covers the internal network segments containing the CDE and the pathways between those segments and the rest of the network.
What QSAs examine: Internal testing is where many PCI penetration testing programs are thinnest. Organisations frequently conduct thorough external testing and cursory internal testing, operating on the assumption that their network perimeter is their primary defence.
QSAs reviewing internal testing evidence look for whether the test actually attempted to reach CDE systems from inside the network, whether it tested the effectiveness of network segmentation controls that are supposed to limit lateral movement toward CDE systems, and whether it covered authentication mechanisms governing internal access to cardholder data.
API layers connecting internal systems to the CDE are a frequent gap in PCI internal testing. Payment processing applications often expose internal APIs that receive card data from point-of-sale systems or e-commerce platforms. API vulnerabilities standard penetration tests miss covers the eight classes most likely to be absent from internal PCI test scopes.
What it requires: If network segmentation is used to reduce the scope of the CDE, penetration testing must be performed on segmentation controls at least once every six months and after any changes to segmentation controls or methods.
This is the requirement that most organisations outside the payment card industry do not anticipate. If an organisation has scoped down its CDE by segmenting payment systems from the rest of the network, that segmentation is only valid as a scope-reduction mechanism if it is tested and proven effective. Untested segmentation is not segmentation for PCI purposes.
What QSAs examine: The segmentation test must demonstrate that an attacker positioned in the non-CDE network cannot reach CDE systems. This requires actually attempting to cross the segmentation boundaries from non-CDE network positions and confirming that the segmentation controls prevent access. A policy document stating that segmentation is in place is not evidence. A penetration test report demonstrating that crossing the boundary was attempted and failed is evidence.
The six-month cadence is worth noting: segmentation testing is required twice as frequently as external and internal testing. For organisations that rely on segmentation to keep their CDE scope manageable, this creates a testing frequency obligation that annual-only engagement planning does not satisfy.
What they require: Exploitable vulnerabilities found during penetration testing must be corrected, and testing must be repeated to verify the corrections have been implemented. The retest must confirm that the specific vulnerability is closed, not just that a subsequent scan produced no findings.
What QSAs examine: This is the requirement that generates the most audit challenges. Many organisations conduct penetration testing, identify findings, remediate some of them, and submit the penetration test report as their PCI evidence without a companion remediation tracking record showing which findings were closed and when.
QSAs reviewing Requirement 11.4.4 and 11.4.5 compliance want to see the penetration test report plus the remediation tracking record plus evidence of retesting that confirms identified vulnerabilities were closed. A finding marked "remediated" in a spreadsheet without a retest confirming the specific exploit path is no longer viable does not satisfy the remediation verification requirement.
What is inside a VAPT report covers how remediation tracking and retest confirmation should be structured in the evidence package, which is directly relevant to what QSAs expect to see under 11.4.4 and 11.4.5.
Every sub-requirement in Requirement 11.4 includes the language "after any significant infrastructure or application upgrade or change." This is the provision that generates the most confusion, and the Reddit threads at position nine in search results for this topic exist precisely because of it.
A "significant change" under PCI DSS is defined as a change that could affect the security of the CDE. This deliberately broad definition means that QSAs have latitude to determine what qualifies. In practice, the following have been treated as significant changes requiring penetration testing:
A cloud migration affecting systems in or connecting to the CDE. A major application version update for software that handles cardholder data. A new integration with a third-party payment processor. Network segmentation changes that affect how the CDE boundary is defined. A new API endpoint that receives or transmits cardholder data.
The practical implication is that organisations with active development environments cannot treat PCI penetration testing as a once-per-year event. Every time a significant change is deployed to systems in or connecting to the CDE, a penetration test is required. For organisations deploying weekly or more often, this creates a testing frequency demand that periodic manual engagement scheduling cannot satisfy operationally or economically.
Continuous penetration testing and how it differs from annual pentests covers the operational model that addresses this. Deployment-triggered agentic testing runs automatically when changes reach the CDE-adjacent systems, producing the evidence that satisfies the significant-change requirement without requiring a separate scheduling cycle for each deployment.
PCI DSS v4.0 Requirement 11.4.1 and 11.4.2 both specify that penetration testing must be performed by a qualified internal resource with organisational independence or by a qualified external third party. v4.0 strengthened this language compared to v3.2.1.
"Organisational independence" means the tester is not responsible for the systems being tested and does not report to someone responsible for those systems. An internal tester who is part of the team that manages the CDE does not satisfy the independence requirement.
"Qualified" is not specifically defined in the standard, but PCI Security Standards Council guidance and QSA practice have consistently treated industry certifications (OSCP, CREST, GPEN, GWAPT) and demonstrated penetration testing experience as indicators of qualification. A developer who runs a scanner against the application they built does not satisfy either the independence or qualification requirement.
PCI DSS Requirement 11.3 covers vulnerability scanning, and Requirement 11.4 covers penetration testing. They are different requirements with different purposes and different evidence standards.
Requirement 11.3 requires quarterly external vulnerability scanning by an Approved Scanning Vendor (ASV) and internal vulnerability scans. These are automated scans run on a schedule to detect known vulnerability signatures.
Requirement 11.4 requires penetration testing: active exploitation attempts against identified vulnerabilities to confirm which are genuinely at risk and to demonstrate what an attacker could achieve. A vulnerability scan report submitted as penetration testing evidence does not satisfy Requirement 11.4. QSAs are familiar with the distinction and will probe the evidence package if the report looks like scanner output rather than penetration testing documentation.
The security gaps that distinguish penetration testing from vulnerability scanning in practice are covered in the security gaps DAST and standard testing misses, which maps each category of vulnerability that signature matching cannot find but genuine penetration testing can.
PCI DSS Requirement 11.4's combination of annual testing, six-month segmentation testing, and significant-change-triggered testing creates a testing frequency and evidence production requirement that periodic manual engagement scheduling manages poorly for organisations with active development programs.
Agentic pentesting and continuous security validation addresses the PCI obligations operationally:
For the annual requirements (11.4.1 and 11.4.2), continuous testing produces a running record of external and internal assessment throughout the year rather than a single point-in-time report.
For the segmentation testing requirement (11.4.3), periodic automated segmentation validation confirms that boundary controls remain effective between the semi-annual testing cycles.
For the significant-change trigger, deployment-triggered testing runs automatically when CDE-adjacent systems change, producing evidence that testing occurred after the change without requiring a separate engagement scheduling process.
For remediation verification (11.4.4 and 11.4.5), automatic retesting when fixes are deployed confirms closure the same day rather than at the next scheduled engagement.
How autonomous pentesting produces a continuous compliance evidence record covers how the continuous model generates the evidence portfolio that QSAs need: not just reports, but timestamped records of testing, findings, remediation, and closure confirmation across the full PCI DSS audit period.
For penetration testing services in the US structured for PCI DSS compliance evidence production, or continuous PTaaS and agentic penetration testing for the full-period coverage model, the 10x Pentest platform produces findings with proof-of-exploitation evidence, IDS-independent retesting, and the remediation closure documentation QSAs require under 11.4.4 and 11.4.5. See pricing or get in touch to discuss a PCI DSS testing program aligned to your audit timeline.
For organisations managing multiple compliance frameworks, SOC 2 penetration testing: what auditors actually require covers the SOC 2 criteria that create parallel testing obligations, and for healthcare organisations processing payments, HIPAA penetration testing requirements covers the seven gaps that the healthcare-specific testing obligation adds beyond standard PCI scope.
Q1. How often does PCI DSS require penetration testing?
PCI DSS v4.0 requires external and internal penetration testing at least annually (Requirement 11.4.1 and 11.4.2). Segmentation testing, if segmentation is used to reduce the CDE scope, must be performed at least every six months (Requirement 11.4.3). In addition, all three types of testing are required after any significant infrastructure or application change that could affect CDE security. For organisations with active development environments, the significant-change trigger means effective testing frequency is higher than once per year.
Q2. Who can perform PCI DSS penetration testing?
PCI DSS v4.0 requires that penetration testing be performed by a qualified internal resource with organisational independence or by a qualified external third party. Organisational independence means the tester is not responsible for the systems being tested and does not report to someone responsible for those systems. Qualification is typically evidenced by industry certifications such as OSCP, CREST membership, GPEN, or GWAPT, along with demonstrated penetration testing experience. An internal developer testing their own application does not satisfy either requirement.
Q3. What is the difference between PCI DSS vulnerability scanning and penetration testing?
Requirement 11.3 covers vulnerability scanning: quarterly external scans by an ASV and internal scans to detect known vulnerability signatures. Requirement 11.4 covers penetration testing: active exploitation attempts to confirm which vulnerabilities are genuinely at risk and to demonstrate attacker impact. Vulnerability scan output submitted as penetration testing evidence does not satisfy Requirement 11.4. QSAs are trained to distinguish between the two and will probe the evidence package if the report looks like scanner output.
Q4. What is a "significant change" that triggers PCI penetration testing?
PCI DSS defines a significant change as one that could affect the security of the CDE. QSA interpretation applies this broadly: cloud migrations affecting CDE systems, major application updates for software handling cardholder data, new payment processor integrations, new API endpoints that receive or transmit cardholder data, and network segmentation changes affecting CDE boundary definition have all been treated as significant changes requiring penetration testing. When in doubt, assume that a change affecting systems in or connecting to the CDE constitutes a significant change and consult your QSA before the change rather than after.
Q5. Does PCI DSS require segmentation penetration testing?
Yes, if segmentation is used to reduce the scope of the CDE. Requirement 11.4.3 requires penetration testing of segmentation controls at least every six months and after any changes to segmentation controls or methods. This testing must demonstrate that an attacker positioned in the non-CDE network cannot reach CDE systems. Organisations that rely on network segmentation to limit their CDE scope must test that segmentation independently of their annual external and internal testing, producing evidence that the boundaries actually prevent CDE access rather than merely asserting that they do.
NESA IAS v2 mandates annual penetration testing with specific evidence requirements. This guide covers exactly what UAE businesses need to satisfy NESA assessors.
Sandeep Aug 4, 2026 
SOC 2 doesn't mandate a pentest by name, but auditors require security testing evidence under CC6 and CC7. Here is exactly what they examine and what passes.
Sandeep Aug 4, 2026 
UAE cybersecurity compliance spans NESA IAS, PDPL, CBUAE, DESC, DIFC, and ADGM frameworks. This CISO guide maps every obligation and what each means for penetration testing.
Sandeep Aug 4, 2026 Schedule a free consultation and see how teams like yours are strengthening their security posture — continuously.
