If your organization processes, stores, or transmits payment card data, you already know PCI DSS compliance is non-negotiable. What many organizations underestimate is how specific the standard is about penetration testing, and how easy it is to fail an assessment because the testing was scoped incorrectly.
This guide breaks down exactly what PCI DSS requires for penetration testing, what changed in version 4.0, who qualifies to run the tests, and what your assessor will look for when they review your results.
—
What PCI DSS Says About Penetration Testing
Penetration testing requirements live in Requirement 11.3 of the PCI Data Security Standard. Under PCI DSS v4.0, which became the only accepted version as of March 2024, Requirement 11.3 was reorganized and strengthened compared to v3.2.1.
The core mandate is straightforward: you must conduct penetration testing of your cardholder data environment (CDE) at least once every 12 months, and after any significant infrastructure or application change.
The standard breaks this down into two parallel tracks:
11.3.1 — Internal penetration testing
- Tests must cover all CDE components accessible from inside the network
- Must be performed at least every 12 months
- Must be repeated after any significant change to the CDE
11.3.2 — External penetration testing
- Tests must cover all external-facing CDE components and any supporting infrastructure that could be used to reach the CDE
- Must be performed at least every 12 months
- Must be repeated after significant changes
11.3.3 — Remediation validation
Exploitable vulnerabilities found during penetration testing must be corrected and retested to confirm the remediation is effective. A clean report is not enough if you found something and just patched it without verifying the fix.
11.3.4 — Segmentation testing
If you use network segmentation to reduce the scope of your PCI DSS assessment, you are required to test that the segmentation controls are working. This is one of the most commonly failed requirements. Many organizations assume their segmentation is effective without actually testing it — PCI DSS v4.0 requires you to prove it.
—
What Changed in PCI DSS v4.0
PCI DSS v4.0 did not fundamentally change the penetration testing mandate, but it clarified expectations in ways that affect how assessors evaluate compliance.
More explicit scope definition. v4.0 requires that your penetration testing methodology document clearly define what is in scope, what testing techniques are used, and what constitutes a finding requiring remediation. Generic methodology statements that say “we followed industry best practices” no longer satisfy the requirement without substantiation.
Stronger emphasis on application-layer testing. The updated standard calls out web-facing applications explicitly. If your CDE includes a web application that handles payment data, both network-layer and application-layer testing are required. A network scan alone does not satisfy Requirement 11.3.
Segmentation testing frequency tightened. Under v3.2.1, segmentation testing was required every six months for service providers and annually for merchants. Under v4.0, service providers are still held to the six-month schedule, and the documentation requirements for what the test must cover are more specific.
—
Who Can Perform PCI DSS Penetration Testing
PCI DSS does not require you to hire a Qualified Security Assessor (QSA) to conduct penetration testing. It does require that testers meet two criteria:
- Organizational independence. The tester cannot be responsible for the systems being tested. An internal tester is acceptable as long as they are not the person who manages or administers the systems in scope. In practice, this means your network administrator cannot run the penetration test on their own infrastructure.
- Relevant penetration testing expertise. The standard requires demonstrable expertise. Your assessor will likely ask for resumes, certifications, or evidence of prior engagement experience. Industry-recognized certifications such as OSCP, GPEN, or GWAPT are commonly cited as evidence.
- All CDE components (systems that store, process, or transmit cardholder data)
- Systems directly connected to the CDE
- Systems that could be used to reach the CDE if compromised (jumping-off points)
- Any network segmentation controls used to limit CDE scope
- Adding new CDE components (new servers, databases, or applications that touch cardholder data)
- Major network architecture changes (new firewalls, reconfigurations of CDE segmentation)
- Significant application updates to any system in scope
- Mergers or acquisitions that bring new infrastructure into your environment
- Migration of any CDE component to cloud infrastructure
For most organizations, using an external penetration testing firm eliminates both concerns cleanly. An external firm has no administrative relationship with your environment and can document their qualifications without internal politics.
If you rely on internal staff, document their qualifications carefully and ensure there is a clear organizational separation between the testers and the teams responsible for the CDE.
—
Scope: What Gets Tested
Scoping a PCI DSS penetration test correctly is where most organizations run into trouble. The standard requires testing of:
Common scoping mistakes include:
Excluding jump servers and management systems. If an administrator workstation has network access to CDE systems, that workstation is in scope. A compromise of that machine is a potential path to cardholder data.
Ignoring cloud infrastructure. If any portion of your CDE runs in AWS, Azure, or GCP, the applicable cloud-layer components are in scope. This includes IAM configurations, S3 bucket policies, and network security groups that control access to CDE workloads.
Not testing segmentation. As noted above, if you have defined network segments specifically to reduce your PCI DSS scope, you must test that the segmentation is effective. A VLAN that can be traversed with a misconfigured firewall rule is not effective segmentation.
—
How PCI DSS Penetration Testing Differs from a Vulnerability Scan
This distinction matters because many organizations have quarterly vulnerability scans in their compliance program and mistakenly believe that satisfies the penetration testing requirement. It does not.
A vulnerability scan is an automated process that identifies known vulnerabilities based on signatures. It tells you what software versions are running and flags known CVEs. It does not attempt to exploit anything.
A penetration test involves a human tester actively attempting to exploit identified vulnerabilities to determine whether they can be chained together to achieve a meaningful objective, such as accessing cardholder data or moving laterally from a lower-trust network segment to the CDE.
PCI DSS Requirement 11.3 is explicit: penetration testing must include exploitation attempts, not just vulnerability identification. Your assessor will ask for evidence that testing went beyond scanning.
—
The Penetration Test Report: What Your QSA Expects
Your QSA will review your penetration test report as part of the assessment. Reports that fail to satisfy the standard typically have one of these problems:
Missing methodology documentation. The report must describe the testing approach, tools used, and scope boundaries. A list of findings with no methodology section leaves the QSA unable to evaluate whether the testing was adequate.
No evidence of exploitation attempts. A finding that says “vulnerability identified” without any documentation of exploitation attempts does not demonstrate that the tester actually tested whether the vulnerability was exploitable. Include screenshots, proof-of-concept evidence, and notes on what was and was not achievable.
Remediation not verified. If any vulnerabilities were found, the report must include evidence of retesting after remediation. A single-phase report that identifies findings but has no retest section will require explanation.
Segmentation test results not documented separately. If you are using segmentation to reduce scope, the segmentation test results should be clearly documented and distinguishable from the main penetration test findings.
—
How PCI DSS Penetration Testing Compares to Other Compliance Frameworks
PCI DSS shares the annual penetration testing mandate with several other compliance frameworks, but the specifics vary.
SOC 2 penetration testing requirements under the Trust Services Criteria do not mandate a specific cadence — auditors expect testing that is appropriate to the organization’s risk profile, which in practice often means annual testing.
CMMC penetration testing requirements for CMMC Level 3 require ongoing assessments and specific evidence collection, with Department of Defense oversight of the process.
HIPAA penetration testing requirements stem from the Security Rule’s requirement for periodic technical and non-technical evaluations. Like SOC 2, HIPAA does not specify a frequency, but annual testing is standard.
PCI DSS stands out because it is prescriptive: annual testing is explicitly required, the scope boundary is defined, and the standard specifies what the report must contain. For organizations that handle both payment card data and protected health information, maintaining a single penetration testing program that satisfies both sets of requirements is achievable with careful scoping.
—
How to Prepare for a PCI DSS Penetration Test
Getting the most value from your annual test requires preparation on your end. Before the engagement begins:
Define your CDE boundary clearly. Document which systems are in the CDE and which are out of scope. Provide this to your testing team before the engagement begins. Ambiguous scope leads to incomplete coverage.
Identify your segmentation controls. If you are relying on network segmentation to reduce scope, document exactly what controls are in place and where. Your testers need to know what they are attempting to bypass.
Notify your security monitoring team. Penetration testing will generate alerts. Ensure your SOC or IT team knows testing is happening so they do not waste time responding to simulated attacks as real incidents. (Unannounced red team exercises are a different engagement type — see red team vs. penetration test for more on that distinction.)
Prepare last year’s report. If you have a prior penetration test report, share it with your testing team. Prior findings that were remediated should be retested. Prior findings that were accepted as risks should be revisited in scope.
—
When to Test Beyond the Annual Requirement
PCI DSS requires retesting after significant changes. The standard does not define “significant” precisely, but your QSA will have expectations. Common triggers that warrant retesting before the next scheduled assessment include:
If you wait 12 months after a major architecture change to test, you are accepting risk that your QSA may ask you to explain.
—
Next Steps
PCI DSS penetration testing requirements are specific, and the margin for error in a formal assessment is narrow. Working with a penetration testing firm that understands how QSAs evaluate results — and how to document findings in a way that satisfies the standard — makes the difference between a clean compliance cycle and a finding that delays your certification.
If your next PCI DSS assessment is approaching or you have recently made significant changes to your cardholder data environment, our team can help you scope the engagement correctly, conduct the testing, and produce a report that your QSA will accept.
Schedule a PCI DSS penetration testing consultation with StrikeHaven Security.
—
StrikeHaven Security provides penetration testing services for organizations subject to PCI DSS, HIPAA, CMMC, SOC 2, and other compliance frameworks. Learn more about our penetration testing services or contact us to discuss your compliance requirements.