PCI-DSS Penetration Testing: Requirement 11.3, v4.0 Changes, and CDE Scoping
PCI-DSS (Payment Card Industry Data Security Standard) — version 4.0 published March 2022, mandatory since March 31, 2024 — contains one of the most prescriptive penetration testing mandates in any global compliance framework. Requirement 11.3 requires annual internal and external penetration tests of all system components in the Cardholder Data Environment (CDE). Requirement 11.4.4 mandates segmentation testing — verifying that your scope-reducing network controls actually prevent non-CDE systems from reaching card data. This page explains the Requirement 11.3 methodology mandates, the key changes in v4.0 vs v3.2.1, how to scope the CDE correctly, when an ASV scan is not sufficient, and how to produce documentation that satisfies a Qualified Security Assessor (QSA).
What PCI-DSS v4.0 actually changed for penetration testing
PCI-DSS v4.0 introduced several materially important changes to penetration testing requirements compared to v3.2.1. The most significant changes: (1) Requirement 11.3.1 now explicitly requires that the test methodology 'includes the entire CDE perimeter and critical systems' — vague annual testing of 'important systems' is no longer sufficient, scope must be explicitly documented and justified. (2) Requirement 11.3.1.1 adds a new obligation for any web-facing applications to be tested using the OWASP Testing Guide methodology or an equivalent. Previously, Requirement 6.6 gave entities the option of either a WAF or application testing — v4.0 removes the WAF-as-substitute option for internet-facing PCI applications. (3) Requirement 11.3.2 (internal penetration testing) must now explicitly test movement from non-CDE systems to CDE systems — simulating an insider threat scenario. (4) Requirement 11.4.4 adds formal segmentation verification: entities using network segmentation to reduce PCI scope must test the effectiveness of that segmentation at least annually — using penetration testing techniques specifically, not just firewall configuration review. A QSA reviewing your PCI assessment without satisfactory penetration test documentation covering all four of these requirements will find a Requirement 11 non-compliance, blocking your Report on Compliance (RoC) or Self-Assessment Questionnaire (SAQ) completion.
- PCI-DSS v4.0 Requirement 11.3.1: annual external penetration test of the CDE perimeter, using an industry-accepted testing methodology (OWASP, PTES, NIST SP 800-115), conducted by a qualified internal or external tester with organisational independence.
- PCI-DSS v4.0 Requirement 11.3.1.1 (NEW in v4.0): internet-facing web applications in the CDE must be tested with OWASP methodology annually — a WAF alone no longer satisfies this requirement.
- PCI-DSS v4.0 Requirement 11.3.2: annual internal penetration test covering all CDE system components, explicitly including tests of movement from non-CDE to CDE network segments.
- PCI-DSS v4.0 Requirement 11.4.4 (segmentation testing): any network segmentation used to reduce PCI scope must be verified by penetration testing at least annually. Segmentation failure — where a tester can pivot from a scoped-out network segment to CDE resources — is the most common cause of PCI scope explosions.
- Tester qualification: PCI-DSS does not require a QSA to perform the test, but the tester must be 'qualified' with 'sufficient understanding' of PCI-DSS v4.0 Req. 11.3. Practical expectation from QSAs: OSCP certification or equivalent experience, familiarity with PCI-DSS scope and controls.
- ASV vs Pentest: Approved Scanning Vendor (ASV) quarterly scans (Requirement 11.2.2) cover external vulnerability scanning — they do not substitute for penetration testing. ASV scans identify known vulnerabilities; penetration tests verify exploitability, privilege escalation paths, and business logic flaws that ASV scans do not detect.
- Remediation and re-test: any exploitable vulnerabilities found during penetration testing must be corrected and the test repeated to verify correction (Requirement 11.3.3). This re-test requirement is often overlooked and flagged by QSAs at assessment time.
What a PCI-DSS Requirement 11.3 penetration test must cover
- External CDE perimeter testing (Req. 11.3.1): all internet-facing IP addresses in the CDE, exposed services, TLS configuration (PCI-DSS requires TLS 1.2 minimum, 1.3 recommended — RC4 and 3DES prohibited), certificate validity, exposed admin interfaces
- Web application testing (Req. 11.3.1.1): OWASP Top 10 full coverage — A01 Broken Access Control (IDOR, BOLA), A02 Cryptographic Failures (weak ciphers, sensitive data exposure), A03 Injection (SQL injection is the primary card-data-theft vector), A07 Identification and Authentication Failures
- Payment flow security: testing of card data capture pages for skimming script injection (CVE-2023-46604 style supply chain attacks via Magecart), JavaScript integrity (SRI), Content Security Policy effectiveness against script injection
- Internal penetration testing and lateral movement (Req. 11.3.2): simulation of attacker who has compromised a non-CDE workstation or server and attempts to reach the CDE — testing firewall rules, VLAN segmentation, ACLs, and east-west traffic controls
- Segmentation testing (Req. 11.4.4): active attempts to cross segmentation controls from all scoped-out network segments to CDE resources — including wireless network access points, third-party vendor networks, call centre environments, and cloud management networks
- API security (Req. 11.3.1.1 scope): payment APIs accepting card data or tokens must be tested against OWASP API Security Top 10 (2023): API1 BOLA, API2 Broken Authentication, API3 Broken Property Level Authorization, API4 Unrestricted Resource Consumption
- Authentication and session management: PCI-DSS Req. 8 controls — MFA bypass for administrative access, session timeout testing, JWT and API key handling, password policy enforcement
- Vulnerability management correlation (Req. 6.3.3): verifying that all known CVEs affecting CDE components are patched — CVE-2024-4577 (PHP-CGI, CVSS 9.8), CVE-2024-21626 (runc container escape, CVSS 8.6), CVE-2023-3519 (Citrix Bleed, CVSS 9.4)
- Third-party payment provider integrations: iframe-based card capture (Stripe, Braintree, Adyen) scope verification, confirmation that PANs never touch the merchant application layer
- Logging and monitoring validation (Req. 10): verifying that attack activity during testing generates SIEM alerts — 'we attacked and it was not logged' is a finding under both Requirement 11 and Requirement 10
Sample finding
SQL injection in order history endpoint exposes PANs — PCI-DSS Req. 6.2.4 violation
The order history endpoint /api/orders/search?customer_id= accepts an unsanitised integer parameter which is concatenated directly into a SQL query. Using a time-based blind SQL injection payload, a tester confirmed full database read access. The orders table contains last-4-digits of PANs stored as cleartext (a Requirement 3.3 violation), and the transactions table contains tokenised PANs with token-to-PAN mapping accessible via a JOIN. While the PANs are tokenised, the tokenisation table was accessible from the same database user account. A complete list of all customer PANs could be reconstructed by an attacker who exploited this endpoint. This violates PCI-DSS v4.0 Requirement 6.2.4 (prevent injection attacks) and Requirement 11.3.1.1 (OWASP-methodology testing requirement for internet-facing applications).
Fix: Use parameterised queries or prepared statements for all database interactions — never concatenate user input into SQL strings. For this endpoint specifically: replace the raw SQL with an ORM-parameterised query or stored procedure. Conduct a code-wide SQL injection audit (SAST with Semgrep rule p/sql-injection or equivalent). Additionally: review the database user privilege model — the application account should have read access only to data required for its function, with no access to the tokenisation mapping table. Implement database activity monitoring to detect anomalous query patterns. Schedule a re-test of this endpoint after fix deployment to satisfy PCI-DSS Req. 11.3.3 remediation verification requirement.
Reference: CVE class: CWE-89 SQL Injection · OWASP A03:2021 Injection · PCI-DSS v4.0 Req. 6.2.4 · PCI-DSS v4.0 Req. 3.3 (truncated PAN storage) · PCI-DSS v4.0 Req. 11.3.3 (remediation re-test)
PCI-DSS penetration testing options
| — | Free scan | Matproof Sentinel | Traditional consultancy |
|---|---|---|---|
| Automated scan engine | ✓ (3-min preview) | ✓ Full scan | ✗ Manual only |
| OWASP Top 10 coverage | Partial | ✓ Complete | ✓ Complete |
| Proof-of-exploit evidence | ✗ | ✓ Per finding | ✓ Per finding |
| Regulatory mapping (DORA/NIS2/ISO 27001) | ✗ | ✓ Automated | ✓ Manual |
| Audit-ready PDF report | ✗ | ✓ Instant | ✓ 2–4 weeks delivery |
| Continuous / recurring scans | ✗ | ✓ Per deploy | ✗ Annual engagement |
| Time to first result | ~3 min | ~30 min full scan | 2–4 weeks |
| Price | €0 | From €149 | €8,000–€25,000 |
| Source code review (SAST) | ✗ | ✓ On Growth plan | ✓ Scoped engagement |
| API testing (REST/GraphQL) | ✗ | ✓ Automated | ✓ Manual |
Matproof Sentinel for PCI-DSS Requirement 11.3
- 1 full pentest scan
- AI-prioritized findings with CVSS 3.1
- Proof-of-exploit per finding
- Audit-ready PDF report
- Regulatory mapping (DORA, NIS2, ISO 27001)
- Unlimited scans (up to 3 domains)
- Continuous monitoring
- CI/CD integration (GitHub, GitLab)
- All regulatory mappings
- Priority support
- Unlimited scans + domains
- Authenticated / White-Box testing
- API & cloud infrastructure tests
- Dedicated security account manager
- 24h SLA response time
Frequently asked questions about PCI-DSS penetration testing
What is the difference between a PCI-DSS ASV scan and a penetration test?
These are two separate, non-interchangeable PCI-DSS requirements. ASV (Approved Scanning Vendor) scans under Requirement 11.2.2 are automated external vulnerability scans conducted quarterly by a PCI-SSC-approved ASV. They identify known vulnerabilities by signature matching against CVE databases and test externally-accessible systems. Penetration tests under Requirement 11.3 are active exploitation tests: a qualified tester attempts to exploit vulnerabilities, chain them together, and demonstrate business impact (e.g., access to card data). Penetration tests uncover logic flaws, misconfigured access controls, segmentation failures, and chained attacks that an ASV scan will never find. Both are required and serve different purposes. PCI-DSS explicitly states in the v4.0 guidance that ASV scans do not satisfy Requirement 11.3.
Who can perform a PCI-DSS penetration test?
PCI-DSS v4.0 Requirement 11.3.1 requires that testing be performed by a qualified internal or external party who possesses 'sufficient understanding' of PCI-DSS requirements, uses an industry-accepted methodology, and is 'organisationally independent' from the systems being tested. There is no PCI-SSC certification specifically for penetration testers (unlike QSAs or ASVs). In practice, QSAs assess tester qualification based on: relevant certifications (OSCP, OSWE, GPEN, CREST CRT), documented methodology (OWASP, PTES, or NIST SP 800-115), and a statement of independence. Internal testers must not be responsible for the systems they test. Many organisations use an external penetration testing firm for the annual PCI test for independence and ease of QSA acceptance.
What is segmentation testing in PCI-DSS and why is it critical?
Network segmentation — isolating CDE systems from other network zones — is not required by PCI-DSS, but it dramatically reduces PCI scope. If you have a properly segmented CDE, only systems within that segment need to be PCI-assessed. Requirement 11.4.4 mandates that any entity using segmentation to reduce scope must verify that segmentation is effective through penetration testing. The test must confirm that from each in-scope scoped-out network zone (DMZ, corporate LAN, wireless network, call centre network, cloud management plane, third-party vendor VPN), an attacker cannot reach CDE resources. Segmentation failures are among the most consequential PCI findings: if a tester can pivot from your corporate network to your CDE, your PCI scope may suddenly expand to include your entire corporate network — potentially requiring full PCI assessment for thousands of systems instead of hundreds.
How does PCI-DSS v4.0 differ from v3.2.1 for penetration testing?
The most material changes are: (1) Req. 11.3.1.1 (new): internet-facing web applications must be tested using OWASP methodology — a WAF alone no longer satisfies this for web app testing. (2) Req. 11.3.2 now explicitly requires testing movement between non-CDE and CDE segments. (3) Req. 11.4.4 (renamed from 11.3.5): segmentation testing must use penetration testing techniques, not just configuration review. (4) Req. 6.4.2: WAFs are now 'automated technical solutions' that must detect and prevent web-based attacks — they remain required but no longer substitute for OWASP-methodology testing. (5) The concept of 'customised approach' (new in v4.0) allows entities to implement alternative controls if they can demonstrate equivalent or superior security — but this requires significantly more documentation and QSA approval. For most entities, the defined approach (following standard requirements) remains simpler.
What documentation does a QSA need to see for Requirement 11.3?
For a QSA to sign off Requirement 11.3 as 'in place', they typically require: (1) a signed penetration testing scope document agreed with the QSA prior to testing, listing all CDE IP ranges, applications, and any scoped-out segments subject to segmentation testing, (2) the full penetration test report including methodology used, tester qualifications, all findings with CVSS ratings and proof-of-exploitation evidence, (3) a remediation log showing status of each finding (exploitable vulnerabilities must be corrected per Req. 11.3.3), (4) re-test report confirming that exploitable vulnerabilities were remediated, (5) for segmentation testing: report specifically documenting the segments tested and the results of each cross-segment traversal attempt, (6) the tester's CV or certification evidence demonstrating qualification. Missing any of these will result in a Requirement 11 finding in the RoC.
Does PCI-DSS require penetration testing of third-party payment processors?
If you use a third-party payment processor or payment page (hosted payment page, iframe solution) and your cardholder data environment is genuinely scoped out as a result, your PCI assessment may be conducted on a SAQ A basis — which does not require penetration testing of your systems at all. However, you must verify that you have correctly implemented the outsourcing scope reduction (no PAN data touches your systems) and that your third-party provider maintains their own PCI certification. For merchants who use hybrid approaches — hosting their own checkout pages but tokenising via a third-party gateway — the scope reduction may be partial and PCI penetration testing obligations remain for the portions of the environment that touch the payment flow.
What is the right cadence for PCI-DSS penetration testing?
PCI-DSS Requirement 11.3 mandates testing 'at least once a year' and 'after any significant changes to the infrastructure or applications'. Significant changes include: new system components in the CDE, software upgrades affecting in-scope systems, infrastructure changes (new network segments, firewall rule modifications), new external connections to the CDE, and changes to application authentication mechanisms. In practice, organisations with active development (multiple releases per month) should implement continuous automated testing (Matproof Sentinel) to catch security regressions between annual structured tests. The annual structured test with an external qualified provider satisfies the Requirement 11.3 documentation requirement; continuous scanning provides the between-cycle assurance.
Can Matproof Sentinel satisfy PCI-DSS Requirement 11.3?
Matproof Sentinel's testing covers the technical scope of Requirement 11.3 (OWASP Top 10, API security, authentication, TLS, configuration). The output report includes: documented methodology, CVSS ratings, proof-of-exploitation, remediation recommendations, and re-test capability — all the documentation elements QSAs need. For SAQ D and RoC-level assessments, QSAs typically expect the external penetration test component to be conducted by an identifiable qualified human tester (not purely automated tooling). The most QSA-accepted approach is: Matproof Sentinel for continuous and pre-release testing, supplemented by an annual external penetration test by a qualified provider who signs the engagement documentation. Sentinel's reports can serve as supporting evidence for the QSA review even in this combined approach.
Go deeper — related blog articles
Start your PCI-DSS Requirement 11.3 penetration test
Matproof Sentinel delivers OWASP-methodology testing with QSA-accepted documentation — CDE-scoped findings, CVSS ratings, proof-of-exploit, and remediation tracking. Start with a free scan or get a full audit-ready report from €149.
Run PCI-DSS scan