PCI DSS Penetration Testing Requirements Explained (2026)
Short answer: PCI DSS Requirement 11.4 (formerly 11.3) requires both internal and external penetration testing at least once a year and after any significant change. If you use network segmentation to reduce scope, you also have to test that the segmentation actually holds. So unlike some standards that only imply it, PCI DSS names penetration testing outright and tells you what to test.
That clarity is good news and a trap at the same time. PCI DSS is specific, which means a QSA knows exactly what to look for. A vague scope or a missing segmentation test will not slide past the assessment. Below is what Requirement 11.4 actually demands, how each piece maps to a real test, and what your report has to prove for the QSA to sign off.
What PCI DSS Actually Requires for Penetration Testing
Penetration testing under PCI DSS v4.0 lives in Requirement 11.4. It is not a single line. It is a set of sub-requirements that together define a complete testing program for the cardholder data environment (CDE) and the systems connected to it.
Here is what the standard demands.
A defined methodology (11.4.1)
You need a documented penetration testing methodology that covers the whole CDE perimeter and critical systems, includes both application-layer and network-layer testing, and uses an industry-accepted approach. The methodology has to be written down, not improvised per engagement.
External penetration testing (11.4.3)
You test from outside the network, the way an internet-based attacker would. This runs at least once every 12 months and after any significant change to the environment.
Internal penetration testing (11.4.2)
You test from inside the network perimeter, simulating an attacker who already has a foothold. Same cadence: at least annually and after significant change.
Segmentation testing (11.4.5)
If you rely on segmentation to keep systems out of PCI scope, you have to prove the segmentation works. That means testing that the controls isolating the CDE from out-of-scope networks cannot be bypassed. Merchants test this at least annually. Service providers test it at least every six months.
Remediation and retesting (11.4.4)
Findings have to be corrected based on risk, and you retest to confirm the fixes actually worked.
So PCI DSS does not leave it to interpretation. It names internal testing, external testing, segmentation testing, a written methodology, and retesting as distinct obligations.
Annual, Plus After Every Significant Change
The cadence catches a lot of companies out. Two triggers reset your testing obligation.
At least once every 12 months. Internal and external tests both run on an annual cycle at minimum. Segmentation testing follows the same annual rule for merchants and a tighter six-month rule for service providers.
A "significant change" is broader than most teams assume. A new system added to the CDE, an upgrade or modification to existing infrastructure, a change to network topology, a new web application in scope, or a move to a new data center can all qualify. After any of these, you do not wait for the annual date. You test again.
The practical risk is a test that goes stale. If you ran your annual pentest in January and then migrated your payment infrastructure in June, the January report no longer describes the environment your QSA is assessing. The migration was a significant change, and the assessment needs a test that reflects it.
Need a PCI DSS-ready pentest? Map your CDE to all five sub-requirements of 11.4 and get a dashboard-delivered report built for your QSA.
Book your PCI DSS pentestMapping Each Requirement to a Real Test
This is where a generic compliance article stops and where the actual work begins. Each sub-requirement maps to something a tester has to do and something the report has to prove.
| PCI DSS sub-requirement | What gets tested | What the report has to show |
|---|---|---|
| 11.4.1 Methodology | Application and network layers across the full CDE perimeter | A documented, industry-accepted methodology applied to the in-scope assets |
| 11.4.2 Internal pentest | The network from an inside-the-perimeter position | Findings, exploit paths, risk ratings for internal exposure |
| 11.4.3 External pentest | Internet-facing systems and the CDE perimeter | Findings and impact for an outside attacker, annually and post-change |
| 11.4.4 Remediation | Re-execution against fixed findings | Proof each corrected issue was retested and resolved |
| 11.4.5 Segmentation | The controls isolating the CDE from out-of-scope networks | Evidence the segmentation cannot be bypassed to reach the CDE |
The recurring failure is partial coverage. A company buys an external web application pentest, then learns at assessment time that internal testing and segmentation testing were never scoped. The QSA cannot sign off on 11.4 with three of five sub-requirements missing.
How Budget Security Scopes a PCI DSS Pentest
Most providers scope from a sales call, where a senior tester estimates your needs from a conversation. That introduces guesswork, and with a requirement as specific as 11.4, guesswork is how sub-requirements get missed. We replaced that with objective, goal-based scoping.
- Register your assets. Your CDE systems, internet-facing services, internal network ranges, and segmentation boundaries, all in one place.
- Pick the goal: PCI DSS readiness. The scoping engine maps your registered assets to all five sub-requirements of 11.4: it plans the external test, the internal test, the segmentation test, and the retest cycle, so none get dropped.
- See the test plan and the tradeoffs live. Add days to deepen coverage on a complex CDE, or trim them and see exactly what gets cut. If a tighter budget would leave segmentation testing or the internal test uncovered, the engine tells you plainly that the scope no longer meets the PCI DSS goal and why.
- Get a dashboard-delivered report built to drop straight into your assessment as 11.4 evidence.
The test itself is run by OSCP-certified veterans. We kept the caliber of a premium consultancy and modernized the scoping, the delivery, and the program management around it. The result maps to the requirement instead of approximating it.
The Report as QSA Evidence
The pentest only counts if the deliverable works as assessment evidence. A QSA validating Requirement 11.4 wants to see the methodology, the scope tested, the internal and external findings with risk ratings, the segmentation test result, and proof of retesting on the issues you corrected. That full trail is what links 11.4 to a working reality.
Budget Security delivers all of it through a dashboard rather than a static PDF buried in an email thread. You get an issue tracker, remediation status per finding, retest results, and a full history across engagements. When your QSA asks for evidence that you tested internally, externally, and across your segmentation, and that you retested the fixes, you open one view that shows the finding, the fix, and the verification.
That continuity matters more under PCI than under almost any other regime, because the requirement explicitly includes retesting (11.4.4). A one-off PDF that documents a single moment cannot easily show the remediation-and-retest loop. A live dashboard can.
Cost and Timeline
Pricing starts from 849 EUR per day, published on the site, with no "contact sales" wall. The day count depends on the size of your CDE, the number of in-scope assets, and whether you carry the merchant annual cadence or the service-provider six-month segmentation rule. The scoping engine sets that transparently rather than guessing. For a full breakdown of what drives the price, see our guide to what a pentest costs.
On timeline: most compliance clients move from booking to test kickoff within 7 days. That matters when your assessment date is fixed and a significant change has just reset your testing obligation.
What a Compliant 11.4 Program Includes
Covered under 11.4
- Documented, industry-accepted methodology (11.4.1)
- Internal penetration test (11.4.2)
- External penetration test (11.4.3)
- Remediation and retesting (11.4.4)
- Segmentation testing (11.4.5)
- Dashboard-delivered QSA evidence
Common gaps that fail assessment
- External-only scope, no internal test
- Segmentation testing never scoped
- No written methodology
- Retesting sold as an add-on, skipped
- Stale report after a significant change
- ASV scan mistaken for a pentest
Get a PCI DSS-Ready Pentest, Scoped in Minutes
Map your CDE to all five sub-requirements of 11.4, then get a dashboard-delivered report built for your QSA. Still planning your cadence? Read how often you should run a pentest to set the right interval against the annual and post-change rules.