PCI DSS Penetration Testing (Requirement 11.4)

Why PCI DSS penetration testing matters

PCI DSS treats penetration testing as the ground-truth check on every other control in the program. ASV scans are automated and narrow. Internal vulnerability scans are deeper but still automated. Penetration testing puts a human adversary's perspective on your cardholder data environment and answers the only question that really matters: can an attacker actually reach cardholder data? PCI DSS Requirement 11.4 operationalizes that question into a set of testing obligations that apply to every organization subject to PCI DSS -- not just Level 1 merchants.

Penetration testing is also the requirement most often misinterpreted during a PCI DSS assessment. Organizations substitute vulnerability scans for penetration tests. They test application layers but skip the network layer. They skip segmentation validation. They engage a firm that produces a generic report with no evidence of hands-on testing. Each of these shortcuts is visible to a trained QSA and becomes a PCI DSS finding.

What Requirement 11.4 actually demands

PCI DSS Requirement 11.4 has several sub-requirements:

• 11.4.1 -- a documented penetration testing methodology that is industry-accepted (NIST SP 800-115, OWASP Testing Guide, PTES, OSSTMM), covers the entire CDE perimeter and critical systems, includes testing from inside and outside the network, validates segmentation and scope-reduction controls, covers application-layer testing (at minimum, the OWASP Top 10 risks), and accounts for threats and vulnerabilities encountered in the past 12 months.
• 11.4.2 -- internal penetration testing at least annually and after any significant change.
• 11.4.3 -- external penetration testing at least annually and after any significant change.
• 11.4.4 -- exploitable vulnerabilities found during penetration testing are corrected and the testing is repeated to verify the corrections.
• 11.4.5 -- for organizations using network segmentation to reduce PCI DSS scope, segmentation controls are tested at least every 12 months for merchants and every 6 months for service providers, and after any change to segmentation controls.
• 11.4.6 -- additional service-provider testing obligations for multi-tenant environments.
• 11.4.7 -- multi-tenant service providers support customer penetration testing.

Every one of those sub-requirements has dedicated testing procedures that your QSA follows. Evidence includes the documented methodology, scoping documentation, tester qualifications, the final report, remediation tracking, and the rescan or retest results.

Internal vs external penetration testing

PCI DSS splits penetration testing into two perspectives.

External penetration testing simulates an adversary on the public internet. The tester has only what an outsider would have: public IP ranges, domain names, public-facing applications, and open-source intelligence. External tests exercise the perimeter -- firewalls, web applications, remote access portals, e-commerce checkouts -- and map what an attacker can reach from outside your network. External testing must cover the entire CDE perimeter plus any critical systems exposed to the internet.

Internal penetration testing simulates an adversary who has already gained a foothold inside the network, whether through a phished employee, a compromised contractor, or an insider threat. Internal testing exercises the defenses that stand between that foothold and the cardholder data environment: segmentation, privileged access controls, lateral-movement detection, hardening of jump hosts, and monitoring. Internal testing is where segmentation actually gets validated.

PCI DSS requires both perspectives. An organization that only runs external testing is missing half of the Requirement 11.4 obligation and creating a blind spot for exactly the attack path most commonly used in card-data breaches.

Segmentation testing (Requirement 11.4.5)

If you rely on network segmentation to reduce your PCI DSS scope, segmentation testing is non-negotiable. PCI DSS Requirement 11.4.5 requires that the segmentation controls isolating the CDE are tested at least annually for merchants, at least every six months for service providers, and after any change to segmentation. The testing must confirm that out-of-scope networks cannot reach the CDE and that the segmentation controls are operating as documented.

A good segmentation test looks like this:

• The tester is placed on every out-of-scope network segment that is supposed to be isolated from the CDE.
• From each segment, the tester attempts to reach every CDE system by any protocol.
• Any connectivity discovered is flagged as a segmentation finding.
• Findings are remediated, and the test is repeated until isolation is confirmed.

Segmentation testing does not require an attempt to compromise the CDE -- it is about reachability. A segmentation test where the tester merely ran a port scan from one corporate subnet is not sufficient. The test must cover every out-of-scope segment that could affect CDE isolation.

Frequency, change-driven testing, and retesting

PCI DSS penetration testing is at least annual. But the real test frequency is driven by change. Any significant change to the CDE -- architecture changes, major software releases, new third-party integrations, new locations, new acquisition integrations, material infrastructure migration -- triggers a new test. Service providers have shorter mandatory cycles on segmentation testing (every six months).

Retesting is a specific PCI DSS obligation. Once a penetration test finds an exploitable vulnerability, you remediate it and then retest to confirm the fix. A report that lists findings but never shows retesting results is incomplete evidence under PCI DSS Requirement 11.4.4.

Tester qualifications

PCI DSS does not name specific certifications but requires testers to be "qualified" and "organizationally independent." In practice that means:

• Certifications such as OSCP, OSEP, OSWE, GPEN, GWAPT, GXPN, CRTO, or CREST tester grades, backed by evidence of real engagement experience.
• Organizational independence -- testers do not test systems they built, manage, or rely on day to day.
• Methodology discipline -- the tester follows the documented methodology and produces evidence of hands-on testing, not just tool output.

For internal teams, separation between build and test functions plus documented qualifications can satisfy PCI DSS. For external engagements, request the CVs and certifications of the specific individuals who will do the testing, not just the firm's credentials.

How this fits into PCI DSS compliance

Penetration testing is where every other PCI DSS control gets pressure-tested. Requirement 1 firewalls are validated during external testing. Requirement 2 hardening and Requirement 6 secure development are validated during application and internal testing. Requirement 8 authentication is validated at every stage. Requirement 10 logging and monitoring is validated when the tester's activity is (or is not) detected. Requirement 11.3 scanning programs are validated by comparing scan output to pen-test findings. A well-run PCI DSS penetration test is therefore not just a 11.4 artifact -- it is the feedback loop for the entire PCI DSS program.

Your QSA will pay particular attention to the pen-test report during every PCI DSS assessment. They will compare the scope to your documented CDE, check that findings have been remediated and retested, and look for the patterns that signal low-quality testing (no evidence of exploitation, no enumeration of internal hosts, no segmentation testing, boilerplate executive summary).

Common mistakes

• Substituting vulnerability scanning for penetration testing. Scans detect vulnerabilities; tests exploit them to produce impact evidence. PCI DSS distinguishes the two.
• Skipping internal testing and presenting only external pen-test reports.
• Segmentation testing that does not cover every out-of-scope segment -- a subset test is not a PCI DSS segmentation test.
• Missing change-driven retests after material CDE changes throughout the year.
• Failing to retest remediated findings, leaving a gap in Requirement 11.4.4 evidence.
• Engaging testers without verifying qualifications or organizational independence.
• Pen-test reports that lack evidence of hands-on testing -- the report must show what the tester did, not just what the tools found.
• Treating PCI DSS pen testing as a once-a-year event disconnected from vulnerability management, change control, and application security.
• Limiting scope to the easiest systems to test rather than the full CDE perimeter and critical systems.

How episki helps

episki maps every penetration testing finding to the specific PCI DSS requirement it affects, routes remediation tasks to the right engineering owner, and tracks retesting evidence automatically. Your QSA sees a clean chain from finding to fix to retest, without you digging through email or shared drives. See the PCI DSS hub to learn more.