PCI DSS penetration testing
PCI DSS v4.0.1 (Payment Card Industry Data Security Standard)
Requirement 11.4 penetration testing of the cardholder data environment, including segmentation validation, corrected and retested.
Engagement at a glance
Drives testing
Requirement 11.4: External and internal penetration testing
Cadence
At least every 12 months and after significant change. Segmentation every 12 months, or every 6 months for service providers.
Typical duration
2 to 4 weeks of testing depending on CDE size, plus retest
Region
Global
Issued by
Assessed by a QSA, or self-assessed via SAQ, validated to your acquirer
11.4
Requirement evidenced
2
Perspectives: internal and external
6 mo
Segmentation cadence for service providers
12 mo
Evidence retention
The requirement
What PCI DSS asks for
Requirement 11.4 · External and internal penetration testing
Requirement 11.4 mandates a documented penetration testing methodology (11.4.1), internal testing (11.4.2) and external testing (11.4.3) at least every 12 months and after significant change, correction of exploitable vulnerabilities with testing repeated (11.4.4), and testing of segmentation controls (11.4.5, or every 6 months for service providers under 11.4.6).
PCI DSS is unusually direct about this. Requirement 11.4 spells out exactly what the penetration test has to include: a documented methodology based on an industry accepted approach, internal and external testing, application layer and network layer coverage, the entire cardholder data environment and its perimeter, and validation of the segmentation that keeps everything else out of scope.
It also closes the loop that other frameworks leave open. Requirement 11.4.4 states that exploitable vulnerabilities found during testing must be corrected and the testing repeated. A QSA will ask for evidence of both the correction and the retest, and a report that stops at the findings does not satisfy the requirement.
XHack delivers the Requirement 11.4 report. Internal and external, application and network layer, segmentation validated, every finding corrected and retested, with an attestation letter your QSA can file against the requirement. Your QSA runs the assessment and signs the Attestation of Compliance.
What your auditor checks
The report has to clear every one of these
These are the questions a PCI DSS auditor asks of a penetration test before accepting it as evidence. Every engagement we run is built to answer all of them.
Documented methodology based on NIST SP 800-115, PTES or equivalent (11.4.1)
Coverage of the entire CDE perimeter and critical systems
Internal penetration testing performed (11.4.2)
External penetration testing performed (11.4.3)
Application layer testing covering the Requirement 6.2.4 classes
Network layer testing of operating systems and services
Segmentation controls tested and confirmed effective (11.4.5)
Testing performed by a qualified, organisationally independent tester
Exploitable findings corrected and testing repeated (11.4.4)
Results and remediation documentation retained for 12 months
Signed attestation letter from the testing firm
What we test
Where the testing effort concentrates
The surfaces this engagement covers, weighted by how much of the work they typically represent. Scope is confirmed with you before anything starts.
Segmentation controls
Out of scope networks proven unable to reach the CDE
100%
CDE application and payment flows
Payment pages, APIs, Requirement 6.2.4 classes
95%
External CDE perimeter
Internet-facing services and boundary controls
90%
Internal CDE network
Hosts, services and lateral movement
85%
Critical connected systems
Systems that can impact CDE security
70%
Weights are indicative of typical effort. Your exact scope is agreed and signed before testing begins.
How the engagement runs
Scope, test, close, attest
Typically 2 to 4 weeks of testing depending on cde size, plus retest. The retest is included, because a report full of open findings is not evidence of anything.
Define CDE scope with you
We map cardholder data flows, the CDE, its perimeter, connected critical systems and the segmentation boundary. Getting this right is what keeps the assessment honest and the cost down.
Internal and external testing
Both perspectives, application and network layer, under a signed rules of engagement, following NIST SP 800-115 with the 11.4.1 methodology documented.
Segmentation validation
Active testing from out of scope segments toward the CDE, proving no traffic path exists. This is the piece assessors most often find missing.
Correction and repeat testing
Requirement 11.4.4 is explicit. Your team corrects, we retest each finding with the original proof of concept and record the result.
QSA-ready report and attestation
A report organised by requirement, with the attestation letter and retest evidence your QSA files against 11.4.
Where the effort goes
Share of a typical engagement, by phase
CDE scoping
20%
Internal & external testing
40%
Segmentation validation
15%
Correction, retest & report
25%
What we bring
Built for the PCI DSS auditor specifically
The parts of this engagement that are shaped by the framework rather than copied from a generic testing template.
Segmentation testing done properly
Active reachability testing from every out of scope segment, with results recorded per path. Not a firewall rule review with a cover page.
Both perspectives, both layers
Internal and external, application and network, so 11.4.2, 11.4.3 and the 6.2.4 classes are all covered in one engagement.
11.4.4 closed out
Correction and repeat testing is part of the engagement, not an upsell. The register closes clean.
Organised by requirement
Your QSA finds the evidence for each sub-requirement where they expect it, which shortens fieldwork.
The deliverable
What lands on your auditor's desk
A report structured so the evidence sits where the auditor is already looking, with every finding mapped to the control it touches.
In the report
Signed letter of attestation covering 11.4.1 through 11.4.5
CDE scope, cardholder data flows and segmentation boundary
Documented methodology and Requirement 11.4 coverage matrix
Findings with CVSS v4.0, evidence and reproduction steps
Segmentation test results, path by path
Correction implemented and independent retest result per finding
Per finding mapping to PCI DSS requirements
Control mapping
How the report evidences each control
11.4.1
Documented methodology based on NIST SP 800-115, published in the report.
11.4.2 and 11.4.3
Internal and external testing both performed and evidenced separately.
11.4.4
Every exploitable finding corrected and retested, with the result recorded in line.
11.4.5 and 11.4.6
Segmentation controls actively tested and confirmed effective.
6.2.4
Application layer testing covers the vulnerability classes the requirement names.
Where our work stops, and who takes it from there
XHack provides the penetration testing evidence for Requirement 11.4. We do not issue certificates, attestation opinions or regulatory approvals, and we do not run your wider compliance programme. For PCI DSS, that sits with: Assessed by a QSA, or self-assessed via SAQ, validated to your acquirer. Staying independent of them is exactly what makes our evidence worth something when they review it.
Questions
PCI DSS testing, answered
No. ASV scanning under Requirement 11.3.2 is a separate, quarterly, automated external scan by an Approved Scanning Vendor. Requirement 11.4 penetration testing is manual, internal and external, and at least annual. You need both, and they are not interchangeable.
No. We deliver the Requirement 11.4 penetration testing evidence. Your QSA assesses the full standard and signs the Report on Compliance or Attestation of Compliance. We scope the test so their 11.4 review is straightforward.
At least every 12 months for most entities under 11.4.5, and at least every 6 months for service providers under 11.4.6, plus after any change to segmentation controls. We schedule to whichever applies to you.
New or modified infrastructure in the CDE, an upgrade or new application, changed network topology, or a new location. Any of those triggers retesting under 11.4.2 and 11.4.3, and we plan a lighter scoped follow-up for exactly that.
Other frameworks we test for
Get the PCI DSS evidence sorted
Tell us who is auditing you and when your review period closes. We will scope the test, tell you what it costs, and make sure there is room to remediate and retest before the deadline.