PCI DSS 4.0 introduced the most significant changes to payment card security standards in over a decade. With PCI DSS 4.1 now in effect (released June 2024), organizations handling cardholder data face updated penetration testing requirements that go beyond the previous version's scope.
This guide breaks down exactly what's required, what changed, and how to ensure your penetration testing program meets the new standard.
What Changed in PCI DSS 4.1
PCI DSS 4.1 is a minor update to 4.0 that primarily clarifies requirements and fixes errata. However, the core penetration testing changes from 4.0 remain significant. Here's what organizations need to know:
Segmentation Testing Methodology
Requirement 11.4.5 now explicitly requires testing of segmentation controls at least every six months, with documented methodology proving isolation effectiveness.
Application Penetration Testing
Requirement 11.4.2 requires testing of custom application security controls, including authentication, access control, and input validation—not just vulnerability scanning.
Documentation Standards
Reports must now include detailed methodology descriptions, tools used, tester qualifications, and evidence of exploitation attempts—not just findings lists.
Risk-Based Approach
Targeted Risk Analysis (TRA) now influences testing scope. Organizations must document why certain systems are in or out of scope based on risk assessment.
Penetration Testing Requirements Breakdown
The penetration testing requirements in PCI DSS 4.1 are found primarily in Requirement 11.4. Here's a detailed breakdown of each sub-requirement:
Penetration Testing Methodology
A penetration testing methodology must be defined, documented, and implemented that includes:
- Industry-accepted penetration testing approaches (e.g., NIST SP 800-115, OWASP Testing Guide, PTES)
- Coverage for the entire CDE perimeter and critical systems
- Testing from both inside and outside the network
- Testing to validate segmentation and scope-reduction controls
- Application-layer testing (at minimum, the vulnerabilities in Requirement 6.2.4)
- Network-layer testing including operating systems, network devices, and other system components
Internal Penetration Testing
Internal penetration testing must be performed:
- At least
- After any significant infrastructure or application changes
- By a qualified internal resource or external third party
- Organizational independence must exist (testers cannot test their own work)
External Penetration Testing
External penetration testing must be performed:
- At least once every 12 months
- After any significant infrastructure or application changes
- By a qualified external third party (cannot be internal staff)
Remediation and Retesting
Exploitable vulnerabilities and security weaknesses found during penetration testing must be:
- Corrected in accordance with the entity's risk assessment
- Retested to verify that the correction was successful
Segmentation Testing
Critical for Scope ReductionIf segmentation is used to reduce PCI DSS scope, penetration testing must:
- Be performed at least every six months
- Test all segmentation controls/methods to confirm they are operational and effective
- Isolate the CDE from all out-of-scope systems
Testing Frequency Requirements
PCI DSS 4.1 doesn't just require annual testing—the frequency depends on what you're testing and whether you use network segmentation:
| Test Type | Minimum Frequency | Additional Triggers |
|---|---|---|
| External Penetration Test | Annually (12 months) | After significant changes to external-facing systems |
| Internal Penetration Test | Annually (12 months) | After significant infrastructure/application changes |
| Segmentation Testing | Semi-annually (6 months) | After changes to segmentation controls |
| Application Security Testing | Annually (12 months) | After significant application changes |
What Counts as a "Significant Change"?
PCI DSS 4.1 doesn't define "significant change"—that's intentional. Your organization must document criteria in your change management policy. Common triggers include: new system deployments, major version upgrades, network architecture changes, and new integrations with the CDE.
Documentation Requirements for Auditors
QSAs (Qualified Security Assessors) evaluating your penetration testing program will look for specific evidence. Here's what your reports and documentation must include:
Defined Scope Statement
Clear documentation of what was tested (IP ranges, applications, URLs) and what was explicitly excluded with justification.
Testing Methodology
Reference to industry-standard methodology used (PTES, OWASP, NIST). Custom methodologies require detailed documentation.
Tester Qualifications
Evidence that testers hold relevant certifications (CREST, OSCP, GPEN) or have equivalent experience. QSAs increasingly expect
Tools and Techniques
List of tools used during testing. Manual testing techniques should be documented separately from automated scanning.
Findings with Evidence
Each vulnerability must include proof-of-concept evidence (screenshots, request/response pairs, exploitation steps). Risk ratings should align with CVSS or a documented risk framework.
Remediation Verification
Evidence that exploitable findings were retested after remediation. Reports must show successful verification, not just "marked as fixed."
Common Compliance Gaps (And How to Fix Them)
Based on QSA findings and failed assessments, here are the most common penetration testing compliance gaps organizations face—and how to address them:
Gap: Missing Semi-Annual Segmentation Tests
Many organizations perform annual pentests but forget segmentation testing must happen every six months.
Gap: No Retest Evidence
Findings are marked "remediated" in tracking systems, but there's no evidence the fix was actually verified through testing.
Gap: Scope Doesn't Match CDE
Pentest scope was defined arbitrarily rather than derived from the documented CDE. Systems were excluded without documented justification.
Gap: Vulnerability Scan Presented as Pentest
Organizations submit automated vulnerability scan reports as "penetration test" evidence. QSAs reject these.
Gap: Testing After Changes Not Documented
Significant changes occurred, but there's no evidence of subsequent penetration testing.
Meeting PCI DSS 4.1 Requirements with ManticoreAI
Traditional penetration testing makes PCI compliance expensive and slow. Each test cycle takes weeks, retesting requires new engagements, and the 6-month segmentation testing cadence doubles your annual testing burden.
ManticoreAI addresses these challenges directly:
48-Hour Results
Get audit-grade penetration testing results in 48 hours instead of 6-8 weeks. Meet tight compliance deadlines without scrambling.
Unlimited Retesting
Verify remediation instantly without scheduling new engagements. Requirement 11.4.4 evidence is always available.
CREST-Validated
All findings validated by CREST-certified consultants. Reports meet QSA expectations for methodology and evidence.
Flexible Scheduling
Run segmentation tests every 6 months and application tests after changes without procurement delays.
Preparing for Your Next PCI Assessment
PCI DSS 4.1 penetration testing requirements are more demanding than previous versions, but they're achievable with the right approach:
The March 2025 deadline is approaching. If your penetration testing program needs updating, now is the time to act.
Get PCI-Compliant Pentesting in 48 Hours
ManticoreAI delivers audit-grade penetration testing that meets PCI DSS 4.1 requirements. CREST-validated findings, unlimited retesting, and reports QSAs accept.