Table of contents
16
By Salman Khan, OSCP+, Founder of XHack, SRT (Synack Red Team member)
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 is the reality every organization handling cardholder data faces in 2026. Most compliance frameworks describe an outcome and leave you to figure out the testing. SOC 2 and HIPAA both work that way. PCI DSS does not. It names penetration testing outright and spells out exactly what is required, in Requirement 11.4, and a Qualified Security Assessor checks your evidence against it directly. (If you are working through several frameworks at once, our guide to penetration testing for compliance covers how they compare.)
That clarity cuts both ways. You know exactly what is required, but there is nowhere to hide either. A QSA who knows what a box-checking test looks like will reject anything that misses a sub-requirement, and a rejected test costs more than doing it right the first time. We have seen a $3,000 “pentest” get bounced, forcing the organization to pay again for a real engagement, plus the delay to their assessment.
This guide covers 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.”
Seven sub-requirements turn that one sentence into specific rules, and a QSA checks each one directly. Meeting most of them is not enough, since partial compliance still fails. Here is the breakdown.
One quick note on numbering, since it trips people up constantly. 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, and 11.3 now means something different: quarterly vulnerability scanning. If your documentation still cites 11.3 for penetration testing, it is written against the old standard, and your QSA will notice immediately.
The cardholder data environment, or CDE, is what all of this tests. It covers every system that stores, processes or transmits cardholder data, plus anything connected to those systems or able to affect their security. Scoping the CDE accurately is the single biggest challenge here, because scoping it too narrowly can invalidate your whole 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 does not require a specific certification, and it explicitly does not require the tester to be a QSA or an Approved Scanning Vendor. In practice, QSAs still look at a tester’s credentials and experience as a sign of competence.
Two things matter here. The first is independence: the tester cannot be the same person or team that manages the systems being tested. They do not have to work outside your company, but they cannot be the people who built and run those systems. For most organizations, especially Level 1 merchants and service providers, hiring a qualified outside provider is the simplest way to satisfy this and remove any doubt about independence.
The second is real skill. PCI DSS names no required certification, but QSAs look favorably on credentials like OSCP, OSWE, GWAPT and CREST. What matters more is application security experience, not just network testing, because Requirement 11.4.1 explicitly requires application-layer testing that covers the vulnerabilities listed in Requirement 6.2.4. A tester who only knows network infrastructure will produce a test that fails the methodology requirement.
That is why most organizations hire a qualified third-party provider for PCI DSS penetration testing. It satisfies the independence requirement automatically and brings both the application and network expertise the standard demands. Our guide to choosing a pentest provider covers what else to check before you sign anything.
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 main evidence your QSA reviews, and a weak report can sink an otherwise good test. For it to count as compliance evidence, it needs to include several specific things.
That means the test scope (which systems were tested, over what period, and who tested them), the methodology used and why it counts as industry-accepted, every finding with a severity score (usually CVSS), proof of what was actually exploited and what access it gave, clear remediation steps for each finding, and retest results showing exploitable findings got fixed, or a documented, signed-off decision to accept the risk instead.
Some QSAs ask for finer detail still, like the exact date each finding was discovered, fixed and retested. Providing it upfront speeds up your assessment. The point is that QSA-ready evidence is more than a PDF from your pentester. See our penetration testing checklist for what a complete engagement looks like from scoping through the final report.
Here are the mistakes that trip up organizations most often, so you can avoid them.
Buying a scan dressed up as a pentest. This is the single most common, most expensive mistake. A cheap automated scan with a cover page gets rejected by the QSA, and you pay for a real test on top of it, plus the delay to your assessment. A rejected $3,000 test ends up costing more than a proper engagement done once.
Underscoping the CDE. Drawing your cardholder data environment too narrowly to shrink the test can invalidate your whole assessment once the QSA finds systems you left out. Scope it honestly the first time.
Skipping application-layer testing. A network-only test fails Requirement 11.4.1, which explicitly demands application-layer coverage of the vulnerabilities listed in Requirement 6.2.4. Your tester needs real application security skill, not just network testing.
Forgetting the retest. Finding and fixing vulnerabilities is not enough on its own. Requirement 11.4.4 requires a documented retest that proves the fix worked. Many teams fix the issue but never document that step, which leaves a gap in their evidence.
Missing the significant-change trigger. Teams test once a year and forget that a significant change resets the clock. A cloud migration or a new payment API partway through the year triggers a fresh testing requirement no matter when your last annual test ran.
Leaving it too late. Booking the test right before your assessment leaves no time to fix anything and retest it. Book at least three months out.
So yeah, here is how XHack approaches PCI DSS penetration testing.
Our human testers cover the network and application security work Requirement 11.4 demands, with the organizational independence QSAs check for, and our AI agents can run alongside them if you give the go-ahead, at no extra cost. That covers internal testing, external testing, and segmentation validation, with application-layer testing against the Requirement 6.2.4 vulnerabilities, so your methodology requirement is fully met, not partly.
What we hand over is what your QSA actually wants: a documented methodology, CVSS-scored findings with proof of exploitation, clear remediation guidance, and a retest confirming your fixes held. The report maps to the current 4.x requirement numbers, so your assessor is not cross-referencing outdated 3.2.1 numbering. Findings can also feed into our security platform, so the monitoring between engagements supports the broader Requirement 10 and 11 controls, not just the annual test.
Our pricing runs $2,500 to $12,000 per engagement, scoped to your cardholder data environment, its complexity, and your assessment timeline. See the full breakdown on our services pricing page. We scope 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 will help you work out exactly what your 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.
Scope drives the price. Our own engagements start at $2,500 for a focused single-asset test covering one web application or up to 50 host IPs, $5,000 for up to three applications across web, host, API and mobile, and $12,000 for larger internal and external programmes, each with a retest included. A full CDE assessment costs more as environment complexity, the number of in-scope systems and segmentation testing are added. The tiers are published on our services pricing page.
What gets a PCI pentest rejected is not its price, it is its method. QSAs reject automated scans presented as penetration tests, and a rejection costs you the fee plus the delay plus a second engagement. So ask what is actually manual, whether segmentation testing is included where Requirement 11.4.6 applies, who the tester is and what they hold, and whether you get a retest after remediation. Those four answers tell you far more than the number on the quote.
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 is 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 box to check as cheaply as possible. They scope it accurately, use qualified independent testers, cover both network and application layers, document what their QSA needs, and leave time to fix 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.
Related articles
