PCI DSS 4.0 Changed the Penetration Testing Rules
PCI DSS 4.0 replaced version 3.2.1 as the only active standard on 31 March 2024. The future-dated requirements became mandatory on 31 March 2025. If your organization processes, stores or transmits cardholder data, the penetration testing requirements that apply to you right now are different from what they were two years ago.
The changes are not cosmetic. PCI DSS 4.0 renumbered, restructured and expanded the penetration testing requirements. Requirement 11.3 became Requirement 11.4. New language was added around methodology documentation, segmentation validation and tester qualifications. QSAs are now asking harder questions about your pentest report than they did under 3.2.1.
This article covers exactly what changed, what your pentest must include and what your QSA will look for when they review the report.
Requirement 11.4: The Core Pentest Mandate
Under PCI DSS 4.0, Requirement 11.4 is the primary control governing penetration testing. Here is what it requires:
- 11.4.1 - Penetration Testing Methodology
- A defined, documented and implemented penetration testing methodology must be in place. The methodology must cover industry-accepted approaches (such as PTES or NIST SP 800-115), include testing from both inside and outside the network, and address the entire CDE perimeter and critical systems.
- 11.4.2 - Internal Penetration Testing
- Internal penetration testing must be performed at least annually and after any significant changes to infrastructure, applications or network segmentation controls.
- 11.4.3 - External Penetration Testing
- External penetration testing must be performed at least annually and after any significant changes. External testing must cover all internet-facing systems within the CDE scope.
- 11.4.4 - Remediation and Retesting
- Exploitable vulnerabilities found during penetration testing must be corrected and retested to verify the corrections. This is not optional guidance. The standard requires documented evidence of both the fix and the retest.
- 11.4.5 - Segmentation Testing
- If network segmentation is used to reduce PCI DSS scope, penetration testing must validate that the segmentation controls are operational and effective. Service providers must perform segmentation testing every six months. All other entities must test annually.
What Actually Changed from PCI DSS 3.2.1
The requirement to perform penetration testing existed in 3.2.1 under Requirement 11.3. But PCI DSS 4.0 added specificity that QSAs are now enforcing. The key differences:
| Area | PCI DSS 3.2.1 | PCI DSS 4.0 |
|---|---|---|
| Requirement number | 11.3 | 11.4 |
| Methodology documentation | Referenced but not detailed | Must be defined, documented and implemented |
| Tester independence | Implied | Explicitly required: organizational independence from the environment |
| Remediation retesting | Recommended | Mandatory with documented evidence |
| Segmentation validation | Required but less prescriptive | Must use penetration testing techniques, not just configuration review |
| Customized approach | Not available | Organizations can meet the objective through alternative controls if validated |
The biggest operational change is mandatory retesting. Under 3.2.1, many organizations received their pentest report, documented a remediation plan and moved on. Under 4.0, the QSA will ask for evidence that vulnerabilities were actually fixed and that the fix was confirmed through a retest. Plan your engagement timeline accordingly.
Internal vs. External Testing Requirements
PCI DSS 4.0 requires both internal and external penetration testing. These are separate tests with different objectives.
External Penetration Testing
External testing simulates an attacker on the internet targeting your public-facing systems. The scope must include:
- All internet-facing IP addresses and domains associated with the CDE
- Web applications that process or redirect to payment pages
- External APIs that interact with cardholder data systems
- VPN and remote access endpoints
- Email servers and DNS infrastructure within the CDE boundary
The external test must attempt to breach the perimeter and access the CDE from the outside. A vulnerability scan is not sufficient. The tester must attempt exploitation of discovered vulnerabilities to determine the actual risk.
Internal Penetration Testing
Internal testing simulates a threat actor who has already gained access to your internal network. This is where most organizations underestimate the scope. The internal test must cover:
- Lateral movement from non-CDE network segments toward the CDE
- Privilege escalation from standard user accounts
- Access to stored cardholder data from compromised internal systems
- Exploitation of trust relationships between CDE and non-CDE systems
- Testing of internal application interfaces that process cardholder data
The internal test is frequently where the most critical findings emerge. External perimeters tend to be better defended. Internal networks often contain flat segments, shared credentials and unpatched systems that provide direct paths to cardholder data.
Scoping Guidance for PCI-Compliant Pentests
Incorrect scoping is the single most common reason a pentest report fails QSA review. The pentest scope must align precisely with your PCI DSS scope, which is determined by your cardholder data environment.
Step 1: Identify the CDE. The cardholder data environment includes every system that stores, processes or transmits cardholder data, plus every system directly connected to those systems. If a server can communicate with your payment processing application without passing through a segmentation control, that server is in scope.
Step 2: Map connected systems. Systems that provide security services to the CDE (firewalls, authentication servers, logging infrastructure) are in scope even if they do not handle cardholder data directly. These are often missed in scoping.
Step 3: Validate segmentation boundaries. If you use network segmentation to reduce your PCI scope, the boundaries between in-scope and out-of-scope networks must be tested. The pentest must confirm that out-of-scope systems cannot reach the CDE through any route, including indirect paths through shared management networks or jump servers.
Step 4: Document exclusions. Any system excluded from testing scope must be documented with a justification. Your QSA will review exclusions. "We excluded it because it was hard to test" is not an acceptable justification.
At Sherlock Forensics, we perform a scoping review with your team before every PCI engagement. This review maps the CDE, identifies connected systems and confirms segmentation boundaries. The scoping document becomes part of the final report so your QSA can verify alignment.
Timeline for Compliance
The compliance timeline for PCI DSS 4.0 penetration testing is now fully in effect:
- 31 March 2024: PCI DSS 3.2.1 retired. All assessments must use PCI DSS 4.0.
- 31 March 2025: All future-dated requirements in PCI DSS 4.0 became mandatory. This includes the enhanced documentation and retesting requirements under 11.4.
- Now (April 2026): Organizations must demonstrate full compliance with all 4.0 penetration testing requirements. QSAs will not accept reports that follow the 3.2.1 format or methodology.
If you have not updated your penetration testing program since the transition, you are already behind. Schedule a gap assessment with your QSA and a compliant penetration test before your next assessment date.
For organizations planning their testing calendar: schedule the penetration test at least 3 months before your annual PCI assessment. This provides time to receive the report, remediate critical findings, perform retesting and compile documentation for the QSA.
What QSAs Want in the Pentest Report
We have delivered penetration test reports reviewed by dozens of QSAs across North America. Here is what they consistently require:
1. Documented Methodology
The report must name the testing methodology and explain how it was applied. Acceptable methodologies include PTES (Penetration Testing Execution Standard), NIST SP 800-115, OWASP Testing Guide for web application components and OSSTMM. A report that says "we performed a penetration test" without describing the methodology will be rejected.
2. Scope Documentation with CDE Mapping
The report must list every system tested and map it back to the CDE. QSAs compare the pentest scope against the entity's documented CDE. If your CDE includes 15 IP addresses and the pentest only tested 8, the QSA will flag the gap. Include IP addresses, hostnames, application URLs and network ranges.
3. Findings with CVSS Ratings
Every finding needs a severity rating. PCI DSS 4.0 does not mandate a specific scoring system, but CVSS (Common Vulnerability Scoring System) is the standard QSAs expect. Each finding should include the CVSS base score, a description of the vulnerability, evidence of exploitation or exploitation potential and the affected system.
4. Segmentation Test Results
If network segmentation reduces your PCI scope, the report must include a dedicated section on segmentation testing. The tester must demonstrate that traffic from out-of-scope networks cannot reach the CDE. Include the test methods used (port scanning, routing analysis, exploitation attempts across segments) and results for each segmentation boundary.
5. Remediation Status and Retest Evidence
Under PCI DSS 4.0, the report (or a supplemental retest report) must confirm that exploitable vulnerabilities were corrected. For each critical and high finding, document the remediation action taken, the date of the fix and the retest result. QSAs will specifically look for this. A report with open critical findings and no remediation plan will result in a non-compliant assessment.
6. Tester Qualifications
The report should identify the testing firm and individual testers, including relevant certifications and experience. QSAs look for evidence that the tester is organizationally independent and qualified. Include certifications (CISSP, ISSAP, ISSMP) and a brief firm profile.
Common Reasons PCI Pentest Reports Fail QSA Review
Incomplete scope. The pentest tested the web application but missed internal CDE components, network infrastructure or connected systems. Always validate scope against your documented CDE before testing begins.
No segmentation testing. Organizations that use segmentation to reduce PCI scope but did not include segmentation validation in the penetration test. This is a separate test requirement under 11.4.5, not optional.
Vulnerability scan disguised as a pentest. An automated Nessus or Qualys report is not a penetration test. QSAs know the difference. A penetration test involves manual exploitation attempts, business logic testing and attack chain analysis. Read our guide on pentest vs. vulnerability scan for the full distinction.
No remediation evidence. Findings were identified but there is no documentation showing they were fixed and retested. Under 4.0, this is a compliance failure.
Missing methodology. The report describes findings but does not explain the testing approach. Without a documented methodology, the QSA cannot verify that testing was adequate.
How Sherlock's Methodology Aligns with PCI DSS 4.0
Sherlock Forensics has been delivering PCI-compliant penetration tests since 2006. Our methodology was updated for PCI DSS 4.0 when the standard was published and has been validated through QSA review across multiple assessment cycles.
Methodology: We follow PTES and NIST SP 800-115, adapted specifically for PCI DSS environments. Every test includes reconnaissance, vulnerability identification, manual exploitation, post-exploitation analysis and segmentation validation where applicable.
Scope validation: Before testing begins, we conduct a scoping review that maps your CDE and confirms alignment with your PCI scope documentation. The scoping document is included in the final report for QSA reference.
Both internal and external: Every PCI engagement includes both internal and external penetration testing as required by 11.4.2 and 11.4.3. We do not treat these as optional add-ons.
CVSS-rated findings: All findings are rated using CVSS v3.1 with base scores, attack vectors and impact assessments. Each finding includes evidence screenshots, reproduction steps and remediation guidance.
Remediation retesting: We include one round of retesting at no additional cost for critical and high findings. The retest results are documented in a supplemental report that your QSA can review alongside the original findings.
QSA-ready format: Our reports include requirement mapping that cross-references findings to PCI DSS 4.0 requirements. QSAs can verify compliance without translating between the pentest report and the standard.
We hold CISSP, ISSAP and ISSMP certifications. Our testers are organizationally independent from every client environment we assess. We carry professional liability insurance and follow responsible disclosure practices. These are the qualifications QSAs verify, and we document them in every report.
For detailed methodology information and pricing, visit our PCI penetration testing service page or order online.
Frequently Asked Questions
What is Requirement 11.4 in PCI DSS 4.0?
Requirement 11.4 is the PCI DSS 4.0 control that mandates penetration testing. It replaced Requirement 11.3 from PCI DSS 3.2.1. It requires annual internal and external penetration testing using a documented methodology, mandatory remediation retesting, tester organizational independence and segmentation validation through penetration testing techniques. Service providers must validate segmentation every six months.
What must a PCI DSS 4.0 pentest report include for QSA review?
The report must include the testing methodology, full scope with CDE mapping, all findings rated using CVSS or equivalent scoring, evidence of exploitation attempts, segmentation test results (if applicable), remediation status for each finding and retest confirmation for corrected vulnerabilities. Reports that omit methodology documentation or segmentation testing will not satisfy QSA requirements.
Can internal staff perform PCI DSS 4.0 penetration testing?
Requirement 11.4.1 requires organizational independence from the environment being tested. Internal staff can technically perform the test if they are independent of the in-scope systems and hold verifiable qualifications. In practice, most QSAs prefer an external firm with documented penetration testing experience and certifications such as CISSP or ISSAP.
How does PCI DSS 4.0 handle segmentation testing differently?
PCI DSS 4.0 Requirement 11.4.5 requires that segmentation controls be validated through penetration testing techniques. Configuration review alone is not sufficient. The tester must actively attempt to traverse segmentation boundaries. Service providers must test every six months. All other entities must test annually. The test must confirm that no path exists from out-of-scope networks to the CDE, including indirect routes.
What is the deadline for PCI DSS 4.0 penetration testing compliance?
PCI DSS 3.2.1 expired on 31 March 2024. The future-dated requirements in PCI DSS 4.0, including enhanced penetration testing documentation under 11.4, became mandatory on 31 March 2025. Organizations assessed after that date must demonstrate full compliance with all 4.0 requirements. If you have not updated your penetration testing program, you are already past the deadline.