Introduction
The Payment Card Industry Data Security Standard (PCI DSS) stands apart from many compliance frameworks: penetration testing isn't optional or implied—it's explicitly mandated. Requirement 11.3 spells out exactly what's expected, making PCI DSS one of the most prescriptive standards when it comes to security testing.
For organizations that store, process, or transmit cardholder data, understanding these requirements is essential. A failed penetration test or insufficient evidence can delay certification and prevent you from processing card payments.
Understanding PCI DSS Requirement 11.3
PCI DSS 4.0 includes explicit penetration testing requirements, with transition timelines and applicability that have evolved over time. Always confirm the current effective dates and applicability details in the official standard and any guidance from your QSA.
- Document a penetration testing methodology covering the CDE perimeter, critical systems, and testing from both inside and outside the network
- Remediate and retest vulnerabilities identified by penetration testing
- Perform internal and external penetration testing at least annually and after significant changes
Segmentation Testing Requirements
If you use network segmentation to reduce your PCI DSS scope, PCI DSS includes additional requirements to validate segmentation effectiveness. Refer to the official standard for the exact requirement numbers and service provider applicability.
- Segmentation tests should verify that out-of-scope systems cannot access systems in the CDE
- Test at least annually and after any changes to segmentation controls
- Service providers may have a more frequent segmentation-testing requirement (commonly at least every six months when segmentation is used)
This requirement catches many organizations off guard. Standard network penetration testing doesn't automatically validate segmentation—you need specific tests designed to attempt access from out-of-scope networks into the cardholder data environment.
Testing Frequency Requirements
Annual Requirements
- External penetration testing at least every 12 months
- Internal penetration testing at least every 12 months
- Segmentation testing at least every 12 months (if applicable)
Event-Triggered Requirements
Testing is also required after:
- Significant infrastructure changes (new systems, network modifications)
- Significant application changes (major updates to payment applications)
- Significant changes to segmentation controls or methods
- Any upgrade or modification affecting the CDE
Service Provider Additional Requirements
Service providers face more stringent requirements with segmentation testing every six months.
Scope Requirements
Your penetration testing scope must cover:
Cardholder Data Environment (CDE)
- Payment application servers
- Database servers containing cardholder data
- Web servers handling card transactions
- Point-of-sale systems and payment terminals
Connected Systems
- Authentication servers
- Logging and monitoring systems
- DNS servers and web proxies
- Management systems
Attack Vectors
Testing must cover both network-layer and application-layer attack vectors:
- Network infrastructure vulnerabilities
- Operating system weaknesses
- Web application vulnerabilities (per OWASP)
- API security issues
- Authentication and authorization flaws
What QSAs Actually Evaluate
Methodology Documentation
QSAs expect documented methodology including:
- Industry-accepted approaches (NIST SP 800-115, OWASP, PTES)
- Testing scope covering entire CDE perimeter
- Coverage of both internal and external testing
- Application-layer and network-layer approaches
Testing Evidence
Your documentation should include:
- Clear scope definition mapping to your CDE
- Testing dates and duration
- Methodology description
- Detailed findings with severity ratings
- Evidence of exploitation (screenshots, data samples)
- Remediation recommendations
- Retest results confirming fixes
Remediation Tracking
QSAs verify that:
- All high and critical findings remediated before assessment
- Lower-severity findings have documented plans
- Retesting confirms vulnerabilities are fixed
- Risk acceptance documented for any exceptions
Tester Qualifications
Testing teams should demonstrate independence from systems tested, relevant certifications, and experience with payment card environments.
Common PCI DSS Testing Failures
Incomplete Scope: Testing covered the main payment application but excluded admin interfaces, APIs, or supporting infrastructure.
Missing Segmentation Validation: Network segmentation reduced scope, but no specific testing validated it works.
No Retest Evidence: Critical vulnerabilities found but no evidence they were fixed and verified.
Outdated Testing: Significant changes occurred after the last test with no follow-up testing.
Internal Testing Gaps: External testing was thorough, but internal testing was superficial.
PCI DSS Penetration Testing Checklist
- Penetration testing methodology documented
- External penetration test completed within 12 months
- Internal penetration test completed within 12 months
- Testing performed after all significant changes
- Segmentation testing completed (if applicable)
- All CDE systems included in scope
- Connected systems included in scope
- Application-layer testing performed
- Network-layer testing performed
- All high/critical findings remediated
- Retest evidence for remediated findings
- Risk acceptance for any open findings
- Tester qualifications documented
- Reports ready for QSA review
Segmentation Testing Deep Dive
Segmentation testing validates:
- Out-of-scope systems cannot reach CDE systems
- CDE systems are isolated from less secure networks
- Segmentation controls function as designed
- No bypass paths exist through misconfigured devices
Common Segmentation Failures
- Overly permissive firewall rules
- Management interfaces accessible across segments
- Shared services (DNS, NTP, logging) creating bypass paths
- VLAN hopping vulnerabilities
Conclusion
PCI DSS penetration testing requirements are explicit. The standard tells you what to test, how often, and what evidence to maintain. Success requires treating penetration testing as an ongoing program rather than an annual project.
With on-demand testing capabilities, you can validate security after every significant change, maintain audit-ready evidence, and demonstrate to QSAs that security validation is embedded in your operations.
RedVeil helps organizations meet PCI DSS Requirement 11.3 with on-demand penetration testing for payment applications, APIs, and network infrastructure. Generate QSA-ready reports with validated findings, built-in remediation tracking, and one-click retesting.