Yet plenty of organizations still get this wrong. Teams confuse an automated vulnerability scan with a real penetration test. Others misjudge which systems fall in scope, how often testing needs to happen, or who's actually qualified to run it. The result: failed assessments, bounced Reports on Compliance, and last-minute scrambles before an audit deadline.
This guide breaks down what Requirement 11.4 actually demands, how scoping and frequency rules work, which methodologies auditors expect, and how to pick a tester who won't leave you with an unusable report.
Key Takeaways
- Requirement 11.4 (formerly 11.3) covers methodology, internal/external testing, remediation, and segmentation validation.
- Only SAQ D merchants and service providers need full internal and external testing; SAQ B-IP and C need segmentation tests when scope is reduced.
- Run internal/external pentests and merchant segmentation checks annually; service-provider segmentation testing is every six months.
- Vulnerability scanning and penetration testing are separate PCI DSS mandates—one never replaces the other.
- A clean report with no unresolved exploitable findings is required before compliance can be validated.
What Is PCI DSS Penetration Testing?
PCI DSS is the global security standard for any organization that stores, processes, or transmits cardholder data. It's maintained by the PCI Security Standards Council (PCI SSC), the industry body that brings together payment brands, banks, and merchants to set a common baseline for protecting account data.
PCI DSS penetration testing is a simulated attack exercise. A tester actively tries to exploit weaknesses in your Cardholder Data Environment (CDE), going well beyond flagging known vulnerabilities.
Per PCI SSC guidance, these tests simulate real-world attacks to show how far an attacker could move through a network. They typically involve exploitation, not just detection.
The goal is to verify whether your controls hold up under real attack techniques:
- Do your firewalls actually block what they're supposed to block?
- Does network segmentation genuinely isolate the CDE from everything else?
- Can access controls withstand credential attacks, privilege escalation, or lateral movement attempts?
A scan tells you a door might be unlocked. A pentest tells you whether someone can actually walk through it, take what's inside, and move to the next room.
PCI DSS Requirement 11.4: What It Actually Requires
Penetration testing sits under Requirement 11.4 in PCI DSS v4.x. Under v3.2.1, the same obligation lived in Requirement 11.3. Don't be thrown off by conflicting numbering in older resources written before the v4.0 transition.
The sub-requirements, broken down
| Sub-requirement | What it covers |
|---|---|
| 11.4.1 | Documented methodology covering the CDE perimeter, critical systems, internal and external testing, and segmentation validation |
| 11.4.2 | Internal penetration testing, at least every 12 months and after significant changes |
| 11.4.3 | External penetration testing, same cadence and qualification rules as 11.4.2 |
| 11.4.4 | Correction of exploitable vulnerabilities and security weaknesses, followed by retesting |
| 11.4.5 | Segmentation testing for merchants using segmentation to reduce scope, at least annually |
| 11.4.6 | Segmentation testing for service providers using segmentation, every six months |
| 11.4.7 | Multi-tenant service providers must support customers' external testing requests |
v4.0 also introduced "security weaknesses" as a distinct remediation category alongside exploitable vulnerabilities. Even findings that aren't directly exploitable now require a documented risk evaluation under Requirement 6.3.1. You can't wave off a weak finding just because nobody proved it's exploitable yet.
Not every SAQ needs the same testing
This is where a lot of confusion happens. Only SAQ D (merchant or service provider) requires the full internal and external testing under 11.4.1 through 11.4.4.
- SAQ A, B, C-VT, and P2PE: no Requirement 11.4 obligation at all.
- SAQ B-IP and C: segmentation testing under 11.4.5 only applies if you're actually using segmentation to shrink your scope.
- SAQ D (merchant): full 11.4.1–11.4.5 applies.
- SAQ D (service provider): 11.4.1–11.4.6 applies, plus 11.4.7 for multi-tenant providers.
Enforcement timeline
Per PCI SSC's transition guidance, 51 of the 64 future-dated requirements in v4.0 became mandatory as of March 31, 2025. In the 11.4 family, multi-tenant support under 11.4.7 carried its own future-dated note tied to that same deadline. Any v4.0 assessment from that point forward must reflect it.
A completely clean report—zero open exploitable findings—is required for compliant validation. Remediation and retesting aren't optional add-ons; they're baked into the requirement itself.
Scope of a PCI DSS Penetration Test
PCI DSS penetration test scope isn't limited to systems that store, process, or transmit cardholder data. Per PCI SSC's penetration testing guidance, it must cover the entire CDE perimeter plus any system that could impact CDE security, even systems that sit outside the CDE boundary.
External attack surface
- Public-facing web applications
- APIs exposed to the internet
- VPN endpoints
- Reporting servers and other externally reachable assets
Internal network scope
- Workstations and servers with CDE connectivity
- Internal web applications and authentication systems
- Databases, both inside the CDE and on connected non-CDE networks
- Firewalls, IDS/IPS, and admin systems used by privileged CDE staff
Segmentation testing: when it applies
Segmentation testing is only required if you're using segmentation to reduce PCI scope. No segmentation means your entire routable network is in scope by default.
A segmentation test fails when unauthenticated or unprotected services are reachable from outside the CDE, or when untrusted networks can reach into the CDE without proper controls.
Access from a non-CDE network isn't an automatic failure if that path has been properly assessed and controlled. Testing cadence depends on entity type: merchants must test segmentation at least annually; service providers must test every six months.
Before your next engagement, ask your assessor or provider for a sample PCI penetration test report structure. Seeing what a compliant scope statement actually looks like on paper will save you a round of scope disputes later.
Penetration Testing Methodologies, Types & Frequency
PCI DSS recognizes three testing approaches, each with different tradeoffs:
- Black-box: tester has no internal knowledge, simulating an outside attacker with zero insider access
- White-box: tester has full system knowledge, giving the deepest possible coverage
- Gray-box: tester has partial knowledge, balancing realism against efficiency
Most PCI engagements lean toward white-box or gray-box testing. Full visibility lets testers dig into segmentation controls and internal logic that a black-box approach might miss entirely.
Methodologies auditors expect to see
Your documented methodology should reference recognized frameworks, not an ad-hoc process invented for the audit. PCI SSC names four explicitly:
- NIST SP 800-115: a structured technical guide to security testing and assessment
- OWASP Testing Guide: focused heavily on web application attack surfaces
- OSSTMM: the Open Source Security Testing Methodology Manual
- PTES: the Penetration Testing Execution Standard, covering everything from pre-engagement scoping through reporting
Frequency baseline
Testing happens at least annually. That's a floor, not a ceiling.
Retesting is also required after any significant change to systems, applications, or infrastructure that could affect the CDE. Common triggers include:
- A new payment integration
- A major network re-architecture
- A cloud migration
PCI Penetration Testing vs. Vulnerability Scanning
Vulnerability scanning and penetration testing get confused constantly, and mixing them up is one of the fastest ways to fail an assessment.
| Dimension | Vulnerability Scanning | Penetration Testing |
|---|---|---|
| Method | Automated, broad | Manual, targeted |
| Governed by | Requirement 11.3 | Requirement 11.4 |
| Who performs it | ASV (external) or qualified staff (internal) | Qualified internal team or third party |
| Frequency | At least every 3 months | At least annually |
| Goal | Identify known weaknesses | Prove real-world exploitability |
A vulnerability scan checks for known signatures across a broad surface. A penetration test manually attempts to exploit what it finds, proving whether a weakness actually translates into unauthorized access.
PCI DSS treats these as two separate mandatory activities. Passing your ASV scan doesn't get you out of a pentest, and vice versa.
Why does exploitation testing matter beyond scanning? Verizon's 2025 Data Breach Investigations Report, which analyzed more than 22,000 incidents, found that vulnerability exploitation as an initial attack vector rose 34% year over year. Known flaws sitting unpatched are increasingly the entry point attackers actually use, not a theoretical risk on a scan report.
Who Can Perform Your PCI DSS Pentest: Choosing the Right Provider
PCI DSS requires qualification and organizational independence, not a QSA or ASV credential for the tester. An in-house team can run the test only if the testers hold relevant credentials and sit organizationally apart from the systems they're assessing. If that separation doesn't exist, you need a qualified third party.
What to look for in an external provider
- Relevant certifications: OSCP, CREST, GPEN, GWAPT, or CEH (PCI SSC treats these as skill signals, not hard mandates)
- Documented PCI DSS experience, not just general infrastructure testing
- A track record of producing QSA-ready reports your assessor can actually work with
What a compliance-ready engagement includes
- Clear scoping aligned to your CDE and any critical connected systems
- Application-layer and network-layer coverage, not just one or the other
- Segmentation validation, where segmentation is actually used to reduce scope
- A retest of every finding before final sign-off, no exceptions
This is where a lot of providers fall short: they hand over a findings list and disappear, leaving remediation and retesting entirely on your team's plate.
Vynox Security covers network, cloud (AWS, GCP, Azure), web application, and mobile scope in one engagement—the mix Requirement 11.4 expects across a CDE and its connected systems. Engagements run 5–15 business days, faster than the 4–8 week timelines common among traditional firms.
Every finding includes developer-ready remediation guidance mapped to your stack. Once a fix ships to staging, Vynox verifies it with a same-day retest, closing the loop Requirement 11.4.4 demands.
If you're also pursuing SOC 2 or ISO 27001 alongside PCI DSS, look for a provider that maps findings across multiple frameworks in a single engagement. It cuts down on duplicate testing effort and gives auditors one consistent evidence trail instead of three disconnected ones. Raise multi-framework mapping on a discovery call before you lock scope.
Frequently Asked Questions
Does PCI require penetration testing?
Yes. Requirement 11.4 (formerly 11.3 under v3.2.1) mandates regular internal and external penetration testing for any organization whose SAQ type requires it, typically SAQ D merchants and most service providers.
What is PCI in cybersecurity?
PCI refers to the Payment Card Industry Data Security Standard (PCI DSS), a security framework created by the PCI Security Standards Council to protect cardholder data across merchants, processors, and service providers.
How often must PCI DSS penetration testing be performed?
At least annually, plus after any significant change to systems or infrastructure. Segmentation testing runs twice yearly for service providers and annually for merchants.
What's the difference between a PCI penetration test and a vulnerability scan?
A scan automatically identifies known weaknesses; a penetration test manually attempts to exploit them to prove real-world risk. PCI DSS requires both as separate, non-substitutable activities.
Who can perform a PCI DSS penetration test?
Testers must be qualified and organizationally independent from the systems being tested, either an internal team meeting both criteria or a qualified external firm.
Does every organization need network segmentation testing for PCI DSS?
No. Segmentation testing is only required if an organization uses segmentation to reduce PCI scope. Without it, the entire routable network is considered in-scope by default.
