PCI DSS Penetration Testing: Requirements, Scope, and Best Practices

PCI DSS and penetration testing: what the standard actually mandates

PCI DSS doesn't leave room for interpretation on penetration testing. It's not implied by a control or buried in an annex — it's an explicit, annual requirement with specific methodology, scope, and evidence standards that your QSA will verify.

Under PCI DSS v4.0.1 (now the only active version as of March 2025), Requirement 11.4 governs penetration testing. Get it wrong and you fail your assessment. Get it right — with the right scope, qualified tester, and remediation evidence — and you have one of the strongest proof points in your entire compliance program.

This guide covers what Requirement 11.4 actually demands, how to scope your test to your cardholder data environment, what QSAs look for when they review your evidence, and the mistakes that cause organizations to fail PCI assessments unnecessarily.

What Requirement 11.4 actually says

PCI DSS v4.0 restructured the penetration testing requirements significantly. In v3.2.1, testing requirements were spread across multiple sub-requirements. In v4.0, they're consolidated under 11.4 with more specificity than any previous version.

The core requirements:

11.4.1 — Documented methodology: A defined, documented, and implemented penetration testing methodology must exist. The methodology must cover industry-accepted approaches (PTES, NIST SP 800-115, OWASP Testing Guide), include testing from both inside and outside the network, address the entire CDE perimeter and critical systems, and include application-layer testing for the vulnerability classes in Requirement 6.2.4.

11.4.2 — Internal penetration testing: At minimum annually, and after any significant infrastructure or application change. Tests attacks from inside the network perimeter.

11.4.3 — External penetration testing: At minimum annually, and after any significant change. Tests attacks from outside — the internet-facing attack surface.

11.4.4 — Remediation and retest: Exploitable vulnerabilities and security weaknesses found during testing must be corrected, and testing must be repeated to verify corrections. This retest requirement is one of the most frequently missed.

11.4.5 — Segmentation validation: If network segmentation is used to reduce PCI DSS scope, penetration testing must validate that segmentation controls are operational and effective. At minimum annually and after any changes to segmentation controls.

11.4.6 — Service provider segmentation testing: Same as 11.4.5 but the frequency doubles — service providers must validate segmentation at least every six months.

Worth noting: internal and external tests are distinct requirements. They test different attack paths and cannot substitute for each other. Some organizations assume a single "pentest engagement" covers both — QSAs will check that both perspectives were actually covered.

The CDE: everything starts with scope

PCI DSS scope drives everything. The Cardholder Data Environment is defined as the systems and networks that store, process, or transmit cardholder data — plus any systems that are connected to, or could impact the security of, those systems.

Your pentest scope must cover the entire CDE. If your CDE includes 15 IP addresses and your pentest report shows 8 were tested, that's a gap your QSA will flag. Common scope failures:

Forgetting connected systems: It's not just the payment application. Any system that has network access to CDE components — internal admin tools, jump hosts, monitoring servers, identity providers — is in scope if it could be used to reach cardholder data.

Ignoring the API layer: If your payment processing involves REST APIs between services, those APIs are part of your CDE. Application-layer testing must cover them. Requirement 11.4.1 explicitly requires testing for the vulnerability classes in 6.2.4, which includes injection flaws, authentication issues, and access control failures at the application level.

Cloud environments: If your CDE runs in AWS, Azure, or GCP, the cloud configuration is part of your attack surface. IAM misconfigurations, overly permissive storage buckets, and insecure network security groups can all be paths into your CDE. Your pentest needs to cover them.

Segmentation boundaries: If you're using network segmentation to keep out-of-scope systems from accessing your CDE, that segmentation must be tested. The test must attempt to traverse the boundary — not just confirm the firewall rules look correct on paper.

A practical starting point: sit down with your QSA before scoping and confirm which systems they consider in-scope for your CDE. Most QSAs will give informal guidance, and aligning early saves expensive rescoping later.

What QSAs actually check when reviewing your pentest

QSAs are trained to distinguish real penetration testing from automated scanning reports dressed up as pentests. Here's what they look for:

Methodology documentation: The report must describe the approach used. PTES, NIST SP 800-115, and OWASP are the commonly accepted frameworks. A report that says "we performed a comprehensive penetration test" without describing the methodology will be rejected. QSAs want to see structured phases: reconnaissance, scanning, exploitation, post-exploitation, and reporting.

Manual exploitation evidence: An automated Nessus or Qualys output is not a penetration test. QSAs know the difference. PCI DSS 4.0 requires evidence of manual exploitation attempts, business logic testing, and attack chain analysis — not just a list of CVEs from a scanner.

Complete scope coverage: Every system in the CDE must be listed in the report with IP addresses, hostnames, and application URLs. If your scope statement says 20 systems but only 15 appear in the findings, the QSA will question what happened to the other 5.

CVSS severity ratings: Each finding needs a CVSS base score, description, evidence of exploitation or exploitation potential, and affected system. "High risk — should be fixed" doesn't meet the standard.

Retest evidence: This is where many organizations get tripped up. After remediating findings, you need documented evidence that the fixes were verified. A note in your ticket system saying "fixed" is not enough. QSAs want to see retest output — ideally from the same tester — confirming the vulnerability no longer exists.

Tester qualifications: PCI DSS 4.0 requires a "qualified internal resource or qualified external third party" with "organizational independence." The standard doesn't mandate specific certifications, but QSAs consistently look for OSCP, CREST, or equivalent credentials as proxies for genuine exploitation capability. An OSCP holder has passed a 24-hour hands-on exploitation exam — QSAs recognize that as evidence of real skill, not just test-taking.

Internal vs external: understanding the distinction

This distinction matters more than most organizations realize, and conflating the two is a common QSA finding.

External penetration testing simulates an attacker with no prior access — starting from the internet, attempting to breach your perimeter and reach cardholder data. The tester begins with reconnaissance: identifying externally exposed systems, mapping the attack surface, enumerating services. This test validates whether your internet-facing defenses hold under real attack conditions.

Internal penetration testing simulates an attacker who has already breached your perimeter — or a malicious insider. Starting from inside the network, the tester attempts to identify the CDE and reach cardholder data through lateral movement, privilege escalation, and exploitation of internal systems. This tests whether your internal segmentation, access controls, and monitoring would stop an attacker who got in.

Both tests are required annually. For organizations that have already invested in strong perimeter security, the internal test often surfaces more findings — because internal networks tend to be trusted, flat, and under-monitored compared to the hardened external perimeter.

After a significant change: when the annual cycle doesn't matter

"At least annually" is the floor, not the target. PCI DSS 4.0 requires retesting after any "significant change" to the CDE — and significant changes trigger immediate retesting obligations regardless of when you last did your annual test.

Significant changes include:

• New system components added to the CDE
• Upgrades or modifications to in-scope applications
• Network architecture changes (new firewall rules, added network segments, VPN changes)
• New third-party integrations that connect to CDE components
• Migration to cloud infrastructure or new cloud regions
• Changes to segmentation controls

The test doesn't have to cover the entire CDE every time — it can be scoped to the changed systems and the controls that changed. But it needs to happen, and it needs to be documented. QSAs will ask about changes during your assessment period and verify that each significant change triggered appropriate testing.

The retest failure: the gap most organizations miss

This deserves its own section because it's the most common PCI compliance gap we see.

The process sounds straightforward: pentest finds vulnerabilities, your team fixes them, you document the fixes. But under PCI DSS 4.0, that's not enough. Requirement 11.4.4 requires that fixes be verified through retesting.

What this means in practice:

1. Pentest report delivered with findings and severity ratings
2. High and critical findings remediated
3. Retest performed by the same or equivalent tester
4. Retest confirms the vulnerability no longer exists
5. Retest output documented and retained as evidence

Where organizations fail: they remediate (or think they've remediated) findings, close the tickets, and assume the annual pentest next year will catch anything they missed. QSAs will ask for retest evidence for each high and critical finding. "We fixed it" without verification evidence is a failed control.

A practical fix: include a retest clause in your pentest contract. Most providers will include a limited retest for high and critical findings as part of the engagement. If they don't offer it, ask for it — or budget a separate retest engagement. The cost of a targeted retest is small compared to a failed QSA assessment.

PCI DSS vs SOC 2 and ISO 27001: how the requirements compare

If you're managing multiple compliance frameworks simultaneously — which is common for SaaS companies handling payments — it's worth understanding how PCI DSS pentest requirements differ from SOC 2 and ISO 27001.

PCI DSS is the most prescriptive of the three. A pentest that satisfies PCI DSS v4.0 will generate strong evidence for SOC 2 and ISO 27001 as well — the scope, methodology, and report format requirements from PCI exceed what the other two frameworks require. One well-scoped test, three compliance frameworks covered.

As we covered in our penetration testing compliance guide and SOC 2 penetration testing guide, the key difference is that PCI DSS requires you to prove segmentation effectiveness, not just show that controls exist.

Choosing the right tester for PCI compliance

The "organizational independence" requirement in PCI DSS 4.0 means your internal security team cannot conduct the assessment and use it as compliance evidence. The tester must be independent — either an external firm or an internal resource that had no involvement in designing or implementing the systems being tested.

What to look for in a PCI pentest provider:

QSA familiarity: Not all pentesters understand what QSAs need in the report. Ask whether they've worked with QSA-reviewed engagements and whether their reports have passed PCI assessments. Ask to see a sample report.

Certifications: OSCP, CREST, or equivalent. These demonstrate hands-on exploitation capability, not just theoretical knowledge. QSAs recognize these credentials.

Scope coverage: Confirm the provider will cover all layers — network, application, and cloud — and that they understand the CDE boundary requirement. A provider who defaults to a single web application test without asking about your network architecture isn't the right fit for PCI.

Retest included: Get it in writing. Retest coverage for high and critical findings should be part of the contract, not a separate negotiation after findings are delivered.

Report format: The report must support QSA review. It needs to map each finding to affected systems with IP addresses and hostnames, include CVSS scores, document methodology, and provide clear remediation guidance. Ask to see the format before you sign.

---

Need a pentest that satisfies your QSA and generates clean evidence across your entire CDE? Book a free consultation with our team — we'll walk you through scoping an engagement that covers Requirement 11.4 end to end.