PCI DSS Penetration Testing — Requirement 11.4, Delivered by a CREST Accredited PCI QSA Organisation
Internal, external, application-layer and segmentation penetration testing scoped to your cardholder data environment, performed to a documented methodology, and reported in the form a QSA needs to accept it. The testers and the assessors work in the same firm, so the scope is right the first time.
At a Glance
What PCI DSS v4.0.1 Requires for Penetration Testing
Requirement 11.4 is the part of PCI DSS that turns "we test our security" into something a QSA can verify. It is not one test. It is a documented methodology, two annual tests (internal and external), a correction-and-retest loop, and, if you rely on segmentation to keep systems out of scope, a separate test that proves the segmentation holds. Service providers carry two further obligations.
The table below is the plain-English version of the seven sub-requirements. The wording of the standard itself is what your QSA will assess against, so treat this as the map rather than the territory.
| Req. | What it means | Applies to | Cadence |
|---|---|---|---|
| 11.4.1 | A documented penetration testing methodology based on industry-accepted approaches. It must cover the entire CDE perimeter and critical systems, testing from inside and outside the network, application-layer and network-layer testing, review of threats seen in the last 12 months, a documented approach to risk from findings, and retention of results for at least 12 months. | All entities | Maintained continuously |
| 11.4.2 | Internal penetration testing performed according to the methodology by a qualified internal resource or qualified external third party, with organisational independence of the tester. | All entities | At least every 12 months and after significant change |
| 11.4.3 | External penetration testing performed according to the methodology, with the same qualification and independence conditions. | All entities | At least every 12 months and after significant change |
| 11.4.4 | Exploitable vulnerabilities and security weaknesses found are corrected in line with your risk assessment, and testing is repeated to verify the corrections. | All entities | After every test |
| 11.4.5 | Where segmentation isolates the CDE, penetration tests on the segmentation controls confirm they are operational and effective, covering every segmentation method in use. | Entities using segmentation | At least every 12 months and after changes to segmentation |
| 11.4.6 | Segmentation controls are tested on a shorter cycle. This is an additional requirement for service providers only. | Service providers | At least every six months and after changes |
| 11.4.7 | Multi-tenant service providers support their customers’ external penetration testing of the customer’s own environment, in line with 11.4.3 and 11.4.4. | Multi-tenant service providers | On customer request; required since 31 March 2025 |
Scanning is not testing. Requirement 11.3 separately requires internal vulnerability scans (11.3.1) and external scans by a PCI SSC Approved Scanning Vendor (11.3.2), each at least once every three months. Those are automated and detect known weaknesses. Requirement 11.4 is manual exploitation by a qualified tester. A passing ASV scan does not satisfy 11.4, and a penetration test does not satisfy 11.3.
What a PCI DSS Penetration Test Must Cover
Requirement 11.4.1 sets the minimum coverage. Scope is defined by the CDE and the systems that can affect it, which is why the test should start from the same network diagram and data-flow diagram your assessment uses, not from a list of IP addresses.
CDE perimeter and critical systems
Every system that stores, processes, or transmits cardholder data, plus connected-to and security-impacting systems: domain controllers, jump hosts, logging, patching, and CI/CD infrastructure.
Internal testing (11.4.2)
From inside the network, as a compromised workstation or insider would operate. Lateral movement, privilege escalation, and paths into the CDE from corporate networks.
External testing (11.4.3)
From the internet against every externally exposed component in scope: payment pages, APIs, remote access, mail and DNS infrastructure that touches the CDE.
Application-layer testing
At minimum the vulnerability classes listed in Requirement 6.2.4 (injection, broken authentication and access control, insecure cryptography, and others), tested authenticated where the application has user roles.
Network-layer testing
All components that support network functions and the operating systems they run on: firewalls, switches, load balancers, VPN concentrators, and hosts.
Segmentation controls (11.4.5)
Every method used to isolate the CDE, tested from every out-of-scope segment. Covered in detail below.
Cloud-hosted cardholder data environments
A cloud provider's PCI DSS validation covers the platform it operates. Requirement 11.4 still applies to everything you configure on top of it: identity and access, network exposure, storage services, workloads, and the segmentation between the CDE and the rest of your cloud estate. Multi-tenant providers must support your external testing of your own environment (11.4.7). Our cloud penetration testing service covers this in depth, and the QSA guides below explain what is tested on each platform.
Segmentation Testing Explained
Segmentation is how most organisations keep their PCI DSS scope manageable: the CDE sits behind controls that stop the rest of the estate from reaching it, and everything on the far side of those controls is out of scope. That scope reduction is only valid if the controls work, and 11.4.5 requires you to prove it by trying to get through them.
A segmentation test is different from a general internal test. It is a systematic attempt to reach CDE systems from each out-of-scope segment, over every protocol and port, across every segmentation method in use. If any route exists, either the control is fixed or the segment on the other side is brought into scope. Service providers repeat this every six months (11.4.6) because their segmentation usually separates customers as well as scope.
What a QSA needs to see
- A list of every out-of-scope segment and the segmentation method that isolates it from the CDE
- Evidence the test was launched from each of those segments, not from a single test host
- Coverage of all segmentation methods: firewalls, ACLs, VLANs, cloud security groups, private endpoints, VPN policy
- A clear statement that no route to the CDE was found, or the routes that were found and how they were closed
- Test dates within the last 12 months (six for service providers) and after any change to segmentation
- Tester qualifications and a statement of organisational independence
Where segmentation usually fails
- Shared services (DNS, patching, monitoring, backup, CI/CD agents) with reachability into the CDE from flat corporate networks
- VNet or VPC peering and transit gateways added after the last test and never reviewed
- VLANs treated as segmentation when the layer-3 device between them permits any-to-any traffic
- Jump hosts and admin workstations that sit outside the CDE but hold standing access into it
- Cloud security groups referencing large CIDR ranges or the default VPC
- Segmentation tested from one convenient segment and the result generalised to all of them
Why the QSA and the Tester Should Talk
The most common problem with a PCI penetration test is not the testing. It is a report that the assessor cannot use: scope described as a list of hostnames with no link to the CDE diagram, no methodology statement, no dates, no tester qualifications, and critical findings with no evidence of retest. The test then has to be repeated or supplemented weeks before the assessment.
EIC's reports are written to be accepted by a QSA, whether that QSA is EIC or another firm. Every report carries the elements an assessor checks against 11.4.1 through 11.4.4, and the scope section is tied to the same diagrams and inventory the assessment uses.
Report elements your QSA will look for
- Methodology statement naming the industry-accepted approaches followed
- Scope tied to the CDE network and data-flow diagrams, with exclusions justified
- Testing dates and confirmation of internal, external, application and segmentation coverage
- Named testers, their qualifications, and a statement of organisational independence
- Findings rated with CVSS v3.1 and mapped to the risk approach in your methodology
- Retest evidence showing exploitable findings were corrected (11.4.4)
Organisational independence
PCI DSS requires that the tester is organisationally independent from the systems being tested: not part of the team that designs, operates, or maintains them. EIC's testers are external to your organisation, which satisfies this condition directly.
Where EIC is also your QSA, the testers have no role in designing, operating or remediating your environment, which is the independence PCI DSS requires, and the QSA reviews the test report as evidence in the same way it would review any third-party report. Using one firm for both the test and the assessment is permitted under the standard. If you prefer, the test can be delivered on its own and handed to a different QSA; the report is designed for that.
Testers are not required to be a QSA or an ASV under the standard. What matters is documented qualification and independence, and both are stated in every EIC report.
Six Phases, Aligned to Requirement 11.4.1
The methodology follows PCI SSC's Penetration Testing Guidance and industry-accepted approaches (NIST SP 800-115, OWASP Testing Guide and ASVS, PTES). A typical single-environment engagement runs two to three weeks of testing plus the retest window.
Phase 1: Scoping to the cardholder data environment
We start from your PCI DSS scope, not from a target list. The CDE network diagram, cardholder data-flow diagram, system inventory, and segmentation design define what is tested from where. Rules of engagement cover testing windows, exclusions, production safety, and escalation, and are signed before any testing begins. The output is a scope statement your QSA can reconcile against the assessment scope.
Phase 2: Reconnaissance and enumeration
External reconnaissance maps every internet-facing component tied to the CDE. Internal enumeration maps services, trust relationships, and administrative paths from each in-scope and out-of-scope segment. Infiltra, EIC’s testing platform, accelerates enumeration; testers decide what matters.
Phase 3: Vulnerability analysis
Application-layer testing covers the classes in Requirement 6.2.4 and the OWASP Testing Guide, performed authenticated for each user role. Network-layer testing covers hosts, network devices, and operating systems. Every candidate finding is validated manually before it appears in the report.
Phase 4: Controlled exploitation and segmentation testing
Confirmed vulnerabilities are exploited under the agreed rules of engagement to demonstrate real impact, including chained paths into the CDE. Segmentation controls are tested from each out-of-scope segment across every method in use. High-risk techniques are limited to non-production systems unless explicitly authorised.
Phase 5: Reporting
One report serving two readers. The executive summary states risk in business terms for boards, regulators, and acquirers. The technical body gives each finding with proof of concept, CVSS v3.1 score, and specific remediation. The appendix carries the methodology statement, scope reconciliation, dates, and tester qualifications a QSA checks for.
Phase 6: Retest and closure
Within 30 days of report delivery, EIC retests remediated findings at no additional cost and issues a retest report. That report is the evidence for 11.4.4 and is written so it can be attached to the ROC or SAQ without further explanation.
Deliverables Built for the Assessment
Each document maps to a specific sub-requirement, so your assessor can file it directly against the evidence request.
Report Set
Methodology Statement
The documented approach, frameworks followed, and coverage confirmation for 11.4.1.
Internal and External Test Reports
Findings with CVSS v3.1 scores, proof of concept, and remediation, for 11.4.2 and 11.4.3.
Segmentation Test Report
Segments tested, methods covered, routes attempted, and the isolation conclusion, for 11.4.5 and 11.4.6.
Executive Summary
Risk in business terms for boards, acquirers, and regulators.
Retest Report
Before-and-after status of every exploitable finding, for 11.4.4.
QSA Acceptance Checklist
A one-page index showing where each 11.4 evidence item sits in the report set.
Infiltra for Testing, Complium for Evidence
Two EIC platforms sit either side of the test: one to make testing broader, one to make the evidence usable for the rest of the assessment.
AI-assisted reconnaissance and coverage
Infiltra automates enumeration and surfaces candidate attack paths across payment and transaction workflows, so testers spend their time on exploitation and business-logic testing rather than on inventory. Every finding in your report has been validated by a tester.
About Infiltra →Findings, retests, and 11.4 evidence in one place
Complium, EIC's PCI DSS compliance platform, tracks each penetration test finding, its remediation, and its retest alongside every other v4.0.1 requirement, so 11.4 evidence is filed once and reused across the ROC. For cloud CDEs, Complium's read-only integrations with Azure and AWS collect the configuration and logging evidence the test report refers to.
About Complium →Why Choose EIC for PCI DSS Penetration Testing
CREST Accredited and a PCI QSA Organisation
The testers understand what the assessor will ask for, because the assessors sit in the same firm. Scope, methodology, and report format are set with PCI DSS acceptance in mind.
Payment-system focus
Core banking, payment gateways, card management, mobile wallets, and switch infrastructure. Findings in transaction logic, not only generic web vulnerabilities.
Reports your QSA can file
Methodology, scope reconciliation, dates, qualifications, and retest evidence in every report, indexed against 11.4.1 to 11.4.6.
Zero client breaches since 2016
No organisation secured by EIC has suffered a breach. The 30-day retest closes the loop between finding and fix.
PCI DSS Penetration Testing FAQs
Assessment Date Set? Book the Test Now.
A 30-minute scoping call with a CREST-certified tester and a PCI QSA. We confirm what 11.4 requires for your environment and send a fixed-price proposal within 24 hours.
Explore More
PCI DSS Compliance
ROC, AOC, and SAQ assessments by a PCI QSA Organisation. The penetration test is one requirement of twelve.
Penetration Testing
Web, network, mobile, cloud, and red team testing under CREST accreditation, beyond the PCI DSS scope.
Cloud Penetration Testing
Identity, network exposure, storage, and segmentation testing for AWS, Azure, and Google Cloud environments.
Requirement 11.4 Explained
11.4.1 to 11.4.7 in plain English: methodology contents, cadence, tester independence, and what the QSA checks in your report.
Penetration Testing Guide
Types, methodologies, CREST vs non-CREST, and how to read a pen test report.
Complium
Track findings, retests, and Requirement 11.4 evidence alongside every other PCI DSS v4.0.1 requirement.