salman
Author
Table of Contents
16
Read this in 30 seconds: If you process, store, or transmit cardholder data, PCI DSS penetration testing is mandatory, not optional. Under PCI DSS 4.0.1, Requirement 11.4 spells it out plainly: documented methodology, internal and external testing at least every 12 months and after any significant change, remediation with retesting, and segmentation testing (annually for most, every 6 months for service providers). The future-dated 4.0 requirements became mandatory on March 31, 2025, so a scanner export with a cover page will get rejected by your QSA. This guide breaks down every sub-requirement, what a qualified tester means, what your report must include, and how to scope a test that passes the first time.
The days of running an automated scanner, exporting the output with a cover page, and calling it a penetration test are over. Your QSA will reject it, and you’ll pay twice.
PCI DSS 4.0 made the penetration testing requirements significantly more prescriptive, and they’ve been fully mandatory since March 31, 2025. If your last test followed the old 3.2.1 format, you’re already behind.
Here’s the reality every organization handling cardholder data faces in 2026. PCI DSS penetration testing is one of the few security requirements that’s spelled out explicitly rather than left to interpretation. Unlike SOC 2 or HIPAA, which describe outcomes and let you figure out the testing, PCI DSS names penetration testing outright and tells you exactly what’s required. Requirement 11.4 is a prescriptive control that a Qualified Security Assessor checks directly against your evidence.
That precision cuts both ways. It means you know exactly what’s required, but it also means there’s nowhere to hide. A QSA trained to spot box-checking programs will reject a test that doesn’t meet every sub-requirement, and a rejected test costs far more than doing it right the first time. We’ve seen a $3,000 “pentest” get bounced by a QSA, forcing the organization to pay again for a proper engagement, plus the delay to their assessment.
This guide breaks down exactly what PCI DSS penetration testing requires in 2026, what your QSA actually wants to see, and how to scope an engagement that passes the first time.
PCI DSS penetration testing is governed primarily by Requirement 11.4 in PCI DSS version 4.0.1. The high-level statement is simple: “External and internal penetration testing is regularly performed, and exploitable vulnerabilities and security weaknesses are corrected.”
That one sentence is operationalized through seven sub-requirements, each of which a QSA checks directly. Understanding the structure matters, because partial compliance fails. Here’s the breakdown.
A quick note on numbering first, because it trips people up. In the old PCI DSS 3.2.1, penetration testing lived under Requirement 11.3. In PCI DSS 4.x, it moved to Requirement 11.4. If your compliance documentation still references 11.3 for penetration testing, you’re working from the outdated standard, and your QSA will notice immediately.
The cardholder data environment, or CDE, is the scope of all this. That means every system that stores, processes, or transmits cardholder data, plus any connected or security-impacting systems. Scoping the CDE accurately is the single biggest challenge in PCI DSS penetration testing, because underscoping can invalidate your entire assessment.
Here’s what each piece of Requirement 11.4 demands, in plain language.
11.4.1 – Documented methodology. You must have a defined, documented penetration testing methodology based on an industry-accepted approach such as NIST SP 800-115, OWASP, OSSTMM, or PTES. The methodology must cover the entire CDE perimeter and critical systems, include both network-layer and application-layer testing, test from inside and outside the network, validate segmentation controls, and cover the application vulnerabilities listed in Requirement 6.2.4. A network-only methodology leaves this requirement partially unmet, which is where many programs lose points.
11.4.2 – Internal penetration testing. You must perform internal PCI DSS penetration testing at least once every 12 months and after any significant change. The internal test simulates an attacker who has already gained a foothold inside your network, whether through a phishing attack, a compromised workstation, or a rogue insider. The tester attempts to move laterally, escalate privileges, and reach the cardholder data environment from a starting point outside it.
11.4.3 – External penetration testing. You must perform external PCI DSS penetration testing at least every 12 months and after any significant change. The external test evaluates the attack surface visible from the internet, targeting all internet-facing systems within the CDE scope, including web applications, APIs, firewalls, and remote access points.
11.4.4 – Remediation and retesting. Exploitable vulnerabilities and security weaknesses found during PCI DSS penetration testing must be corrected, and then retested to verify the corrections worked. A finding isn’t closed until the fix is confirmed. This retesting requirement is one of the most common places organizations fall short, because they fix the issue but never document the verification.
11.4.5 – Segmentation testing (all entities). If you use network segmentation to reduce your PCI scope, you must test those segmentation controls at least every 12 months to verify they actually work and can’t be bypassed. Segmentation is how you shrink your CDE, so proving it holds is essential.
11.4.6 – Segmentation testing (service providers). If you’re a service provider, segmentation testing must happen every six months rather than annually. This tighter cadence reflects the elevated risk service providers carry.
11.4.7 – Multi-tenant service provider support. If you’re a multi-tenant service provider, such as a SaaS platform or hosting provider, you must support your customers in conducting their own external penetration testing, so they can validate their own compliance without being blocked by your infrastructure policies.
The frequency rules for PCI DSS penetration testing are clear, which is refreshing in the compliance world. Here’s the cadence.
| Test Type | Frequency | Applies To |
|---|---|---|
| Internal penetration testing | At least every 12 months + after significant change | All entities |
| External penetration testing | At least every 12 months + after significant change | All entities |
| Segmentation testing | At least every 12 months | All entities using segmentation |
| Segmentation testing | Every 6 months | Service providers |
| Remediation retesting | After each remediation | All entities (for exploitable findings) |
The “after significant change” trigger is independent of the annual calendar, and this catches a lot of organizations off guard. A significant change includes things like a new payment application, a major application release, a new payment API, a cloud migration, firewall or segmentation changes, new third-party connectivity, or any change affecting how cardholder data is stored, processed, transmitted, or protected. If you make a significant change, you need PCI DSS penetration testing even if your annual test was last month.
A practical tip: schedule your PCI DSS penetration testing at least three months before your annual assessment date. This gives you time to receive the report, remediate critical findings, perform the required retesting, and compile the documentation your QSA needs. Leaving it to the last minute is how organizations end up with a rushed, incomplete test that stalls their assessment.
PCI DSS 4.0.1 requires that penetration testing be performed by a “qualified internal resource or qualified external third party” with organizational independence. The standard doesn’t mandate specific certifications, but QSAs consistently evaluate tester qualifications as a proxy for competence.
Two things matter here. First, organizational independence. The tester cannot be responsible for managing the environment they’re testing. They don’t have to be external to your company, but they can’t be the same people who built and run the systems. For most organizations, especially Level 1 merchants and service providers, using a qualified external provider is the cleanest way to satisfy this requirement and eliminate any questions about independence.
Second, demonstrated competence. While PCI DSS doesn’t name certifications, QSAs look favorably on recognized credentials like OSCP, OSWE, GWAPT, and CREST. More importantly, the tester needs genuine application security expertise, not just network skills, because PCI DSS penetration testing explicitly requires application-layer testing covering the vulnerabilities in Requirement 6.2.4. A tester who only knows network infrastructure will produce a test that fails the methodology requirement.
This is exactly why so many organizations use qualified third-party providers for PCI DSS penetration testing. It satisfies the independence requirement automatically and brings the application and network expertise the standard demands.
A critical point of confusion: PCI DSS requires both penetration testing and vulnerability scanning, and they are not interchangeable. Mixing them up is a fast way to fail an assessment.
Vulnerability scanning, required quarterly under Requirement 11.3, is an automated, tool-driven sweep that identifies known weaknesses without exploiting them. External scans often must be performed by an Approved Scanning Vendor (ASV). These scans find known CVEs and misconfigurations across your environment on a quarterly cadence.
PCI DSS penetration testing, required annually under Requirement 11.4, is a deeper, manual exercise where skilled testers actively exploit vulnerabilities to prove real impact against the cardholder data environment. It combines automated and manual techniques, but the manual exploitation is what makes it a penetration test rather than a scan.
| Factor | Vulnerability Scan (11.3) | PCI DSS Penetration Testing (11.4) |
|---|---|---|
| Nature | Automated only | Manual exploitation + automated |
| Frequency | Quarterly | Annually + after significant change |
| Objective | Identify known CVEs | Prove exploitability and business impact |
| Depth | Surface-level detection | Deep, validates real attack paths |
| Who performs it | ASV for external scans | Qualified independent tester |
Both are mandatory. A quarterly scan does not satisfy the annual penetration testing requirement, and a penetration test does not replace the quarterly scans. Your QSA expects to see both.
The report is the primary evidence artifact your QSA evaluates, and a weak report sinks an otherwise good test. For PCI DSS penetration testing to count as compliance evidence, the report must include several specific elements.
The test scope, clearly documenting which systems were tested, the testing period, and the tester credentials and independence. The documented methodology, showing it’s based on an industry-accepted approach and covers both network and application layers. The findings, with each vulnerability detailed and scored, typically using CVSS. The exploitation results, documenting which vulnerabilities were successfully exploited and what access was obtained, because proving exploitability is the whole point. Specific, actionable remediation recommendations for each finding. And the retest results, confirming that exploitable findings were remediated, or formal documented risk acceptance for any findings not remediated.
Some QSAs ask for granular detail, like the exact date each vulnerability was discovered and when it was fixed and retested. Providing that level of documentation demonstrates diligence and smooths your assessment. The key principle is that QSA-ready evidence is more than a PDF from your pentester. It’s the full package: methodology documentation, findings, exploitation proof, remediation guidance, retest confirmation, and independent tester sign-off.
Here are the mistakes that trip up organizations most often, so you can avoid them.
Buying a scan dressed up as a pentest. The single most common and most expensive mistake. A cheap automated scan with a cover page gets rejected by the QSA, and you pay again for a real test plus the assessment delay. A rejected $3,000 test costs far more than a proper engagement that passes the first time.
Underscoping the CDE. Defining your cardholder data environment too narrowly to reduce testing scope can invalidate your entire assessment when the QSA finds systems you should have included. Scope accurately.
Skipping application-layer testing. A network-only test fails the 11.4.1 methodology requirement, which explicitly demands application-layer coverage of the Requirement 6.2.4 vulnerabilities. Your tester needs application security expertise.
Forgetting the retest. Finding and fixing vulnerabilities isn’t enough. Requirement 11.4.4 demands documented retesting to verify the fixes worked. Many organizations remediate but never document the verification, leaving a gap in their evidence.
Missing the significant-change trigger. Organizations test annually and forget that significant changes require additional testing. A cloud migration or new payment API mid-year triggers a new PCI DSS penetration testing requirement regardless of when your annual test happened.
Leaving it too late. Scheduling the test right before your assessment leaves no time for remediation and retesting. Schedule at least three months ahead.
Since this guide is about getting PCI DSS penetration testing right, here’s how XHack approaches it.
XHack delivers PCI DSS penetration testing aligned to Requirement 11.4, combining expert human testers with autonomous AI coverage. Our testers bring both the network and application security expertise the standard demands, with the organizational independence QSAs require. We cover internal testing, external testing, and segmentation validation, with application-layer testing that addresses the Requirement 6.2.4 vulnerabilities so your methodology requirement is fully met, not partially.
Critically, we deliver what your QSA actually wants to see: a documented methodology based on industry-accepted approaches, CVSS-scored findings with exploitation evidence, specific remediation guidance, and retesting to confirm your fixes worked. The report comes in QSA-ready format that maps to the current 4.x requirement numbers, so your assessor isn’t cross-referencing outdated 3.2.1 numbering. And findings can feed into our security platform for the continuous monitoring that supports the broader Requirement 10 and 11 controls.
Our PCI DSS penetration testing runs $3,000 to $12,000 per engagement, combining human testers with XHack AI agents when the client authorizes AI-agent involvement, with final pricing scoped to your cardholder data environment, complexity, and assessment timeline. We scope it to what your environment actually needs to pass, not a flat rate that leaves gaps.
If you have a PCI assessment coming up, the time to act is now, not three weeks before your QSA arrives. Get a quote scoped to your CDE, or book a free consultation and we’ll help you understand exactly what your PCI DSS penetration testing scope should be, including how segmentation can shrink what you have to test.
PCI DSS penetration testing is required at least every 12 months for both internal and external testing, plus after any significant infrastructure or application change. Segmentation testing is required every 12 months for most entities and every 6 months for service providers. The after-change trigger is independent of the annual calendar, so a significant change like a cloud migration or new payment API requires testing even if your annual test was recent. Schedule your test at least three months before your assessment to allow time for remediation and retesting.
No. PCI DSS requires both, and they are not interchangeable. Vulnerability scanning under Requirement 11.3 is an automated quarterly sweep that identifies known weaknesses without exploiting them, often performed by an Approved Scanning Vendor for external scans. PCI DSS penetration testing under Requirement 11.4 is an annual manual exercise where qualified testers actively exploit vulnerabilities to prove real impact. A scan does not satisfy the penetration testing requirement, and a pentest does not replace the quarterly scans. Your QSA expects evidence of both.
PCI DSS 4.0.1 requires a qualified internal resource or qualified external third party with organizational independence, meaning the tester cannot manage the environment they’re testing. The standard doesn’t mandate specific certifications, but QSAs evaluate credentials like OSCP, OSWE, and CREST as proxies for competence. The tester also needs application security expertise, not just network skills, because the methodology must cover application-layer testing. Most organizations use a qualified external provider to satisfy the independence requirement automatically and bring the necessary expertise.
The penetration testing requirement moved from Requirement 11.3 in the old 3.2.1 to a restructured Requirement 11.4 in version 4.x, with more explicit methodology documentation, clearer segmentation testing, and a dedicated 6-month cadence for service providers. Version 4.0.1 was a 2024 maintenance update that clarified wording without loosening controls. All future-dated 4.0 requirements became mandatory on March 31, 2025, so QSAs no longer accept reports following the old 3.2.1 format. If your last test used 3.2.1 numbering and methodology, you need to update your program.
PCI DSS penetration testing typically starts around $5,000 for a focused single-asset engagement, with most comprehensive CDE assessments running higher depending on environment complexity, the number of systems in scope, and whether segmentation testing is required. Be very cautious of quotes in the $1,000 to $3,000 range advertised as PCI pentests, because these are usually automated scans that QSAs reject. A rejected cheap test costs far more than a proper engagement once you factor in paying twice plus the assessment delay. Scope and qualified testing drive the real price.
If your QSA rejects the test, typically because it was an automated scan dressed up as a pentest, used outdated 3.2.1 methodology, skipped application-layer testing, or lacked required documentation, your assessment stalls until you provide a compliant test. You pay for a proper engagement on top of what you already spent, and the delay can push your compliance timeline back significantly. This is why getting PCI DSS penetration testing right the first time, with a qualified independent tester and QSA-ready documentation, is far cheaper than the bargain option that fails.
That’s what PCI DSS penetration testing actually requires in 2026.
The standard is unusually clear: Requirement 11.4 mandates documented methodology, internal and external testing at least annually and after significant changes, remediation with retesting, and segmentation validation. The future-dated 4.0 requirements have been mandatory since March 31, 2025, and QSAs no longer accept the old scanner-with-a-cover-page approach. PCI DSS penetration testing is prescriptive, checked directly, and unforgiving of shortcuts.
The organizations that get this right treat PCI DSS penetration testing as a real security exercise that happens to satisfy compliance, not a checkbox to clear as cheaply as possible. They scope accurately, use qualified independent testers, cover both network and application layers, document everything their QSA needs, and schedule with time to remediate and retest.
If you have a PCI assessment ahead and want PCI DSS penetration testing that passes the first time, get a quote scoped to your cardholder data environment, or book a free consultation to map out your scope. The cheap test that gets rejected is the most expensive option there is.
Follow Us on LinkedIn: XHack
Related articles
Read this in 30 seconds: AI exploit development is the use of large language models and autonomous agents to accelerate ...
Read this in 30 seconds: Agentic pentesting is penetration testing run by goal-directed AI agents that plan, execute, ad...
Read this in 30 seconds: “Uncensored AI for hacking” is searched by three very different crowds: curious peo...
