PCI DSS Penetration Testing Requirements

Understanding these requirements is essential for organizations completing SAQ A-EP, SAQ C, SAQ D, or undergoing QSA assessments. If you're using SAQ A (fully outsourced e-commerce), penetration testing isn't a formal requirement but is still strongly recommended.

Key Takeaways

Point	Summary
Frequency	At least annually and after significant changes
Scope	Network-layer and application-layer testing of CDE
Segmentation	Must test segmentation controls every 6 months (if using segmentation)
Methodology	Must follow industry-accepted approach
Remediation	Critical findings must be addressed and retested
Who can test	Qualified internal resources or third-party firm

What PCI DSS Requires

PCI DSS v4.0 Requirement 11.4 specifies penetration testing requirements:

11.4.1: Penetration Testing Methodology

You must define and implement a penetration testing methodology that includes:

Element	Requirement
Industry acceptance	Based on industry-accepted approaches (NIST SP 800-115, OWASP, PTES, etc.)
Coverage	Entire CDE perimeter and critical systems
Testing types	Both internal and external testing
Layers	Network-layer and application-layer testing
Review scope	Include review of threats and vulnerabilities from last 12 months

11.4.2: Internal Penetration Testing

• Test from inside your network
• Attempt to exploit vulnerabilities
• Test lateral movement possibilities
• Verify internal segmentation (if used)

11.4.3: External Penetration Testing

• Test from outside your network (internet perspective)
• Attempt to breach perimeter defenses
• Test public-facing applications
• Verify external-facing segmentation

11.4.4: Remediation and Retesting

Severity	Requirement
Critical/High	Must be remediated and retested
Medium	Address per risk-based timeline
Low	Document and track

11.4.5: Segmentation Testing

If you use network segmentation to reduce PCI scope:

• Test segmentation controls at least every 6 months
• Verify segments are truly isolated
• Confirm segmentation effectiveness after changes
• Document testing methodology and results

11.4.6: Service Provider Requirements

Service providers have additional requirements:

• Segmentation testing every 6 months
• Testing after any changes to segmentation controls
• Include testing of segmentation in annual pen test

Penetration Testing vs Vulnerability Scanning

These are often confused but serve different purposes:

Aspect	Vulnerability Scanning	Penetration Testing
Purpose	Identify known vulnerabilities	Exploit vulnerabilities to demonstrate impact
Approach	Automated scanning	Manual testing with automated tools
Frequency	Quarterly (minimum)	Annually (minimum)
Depth	Surface-level identification	Deep exploitation
Output	List of vulnerabilities	Demonstration of attack paths
Risk assessment	Theoretical risk	Proven exploitability
Requirement	11.3	11.4

Key distinction: Vulnerability scanning tells you what might be exploitable. Penetration testing proves what actually is exploitable and demonstrates the real-world impact.

Scope of Testing

Network-Layer Testing

Network-layer testing examines infrastructure and network security:

What to test:

• Firewalls and network security controls
• Network segmentation effectiveness
• Remote access mechanisms
• VPN configurations
• Wireless networks
• Network services and protocols
• DNS, DHCP, and other infrastructure services

Common findings:

• Weak firewall rules
• Unpatched network devices
• Default credentials on network equipment
• Insufficient network segmentation
• Exposed management interfaces

Application-Layer Testing

Application-layer testing focuses on software and web applications:

What to test:

• Web applications in the CDE
• Payment applications
• APIs handling cardholder data
• Custom software
• Third-party applications in scope

Testing methodology should include:

• OWASP Top 10 vulnerabilities
• Authentication and authorization flaws
• Injection vulnerabilities (SQL, command, etc.)
• Cross-site scripting (XSS)
• Insecure cryptographic storage
• Session management weaknesses
• Business logic flaws

What Must Be in Scope

Component	Why It's in Scope
CDE boundary	Entry/exit points for cardholder data
Systems storing CHD	Direct access to sensitive data
Systems processing CHD	Active handling of card data
Systems transmitting CHD	Data in transit
Connected systems	Could provide access to CDE
Segmentation controls	Validate scope reduction
Web applications in CDE	Application-layer attack surface

Planning Your Penetration Test

Step 1: Define Scope

Document exactly what will be tested:

• List all IP addresses and ranges in scope
• Identify all web applications in scope
• Note any systems excluded and why
• Define testing window and timing
• Document any testing restrictions

Step 2: Select Testing Approach

Approach	Description	When to Use
Black box	Tester has no prior knowledge	Simulates external attacker
Gray box	Tester has partial knowledge (credentials, architecture)	Simulates insider or compromised credentials
White box	Tester has full access to documentation and source code	Maximum coverage, identifies hidden issues

PCI recommendation: Gray box testing is often most effective, combining attacker perspective with efficiency.

Step 3: Select Tester

You can use internal resources or external firms:

Internal Testing:

• Tester must be qualified and experienced
• Tester must be independent of the systems being tested
• Organization must demonstrate tester competence

External Testing:

• Consider industry certifications (OSCP, GPEN, CEH, CREST)
• Verify experience with PCI DSS assessments
• Check references and past work
• Ensure appropriate insurance coverage

Conflict of interest: The same firm that implements controls should not be the only tester of those controls. Independence matters.

Step 4: Establish Rules of Engagement

Document in writing:

• Authorized testing scope and methods
• Start and end dates/times
• Communication procedures
• Emergency contacts
• Escalation procedures
• Data handling requirements
• Evidence collection procedures

Step 5: Prepare Environment

• Notify relevant teams
• Ensure monitoring systems are active (to validate detection)
• Have incident response team on standby
• Back up critical systems
• Document baseline system state

During the Test

What Testers Should Document

• Attack methodology and tools used
• Vulnerabilities discovered
• Exploitation attempts (successful and failed)
• Evidence of successful exploitation (screenshots, logs)
• Data accessed (without actually exfiltrating sensitive data)
• Recommendations for remediation

Monitoring During Testing

Use the test to validate your detection capabilities:

• Are intrusion detection systems alerting?
• Are security logs capturing the activity?
• Are incident response procedures triggered?
• How quickly did the security team notice?

After the Test

The Penetration Test Report

A quality report should include:

Section	Content
Executive summary	High-level findings for management
Methodology	Testing approach and tools used
Scope	What was tested (and what wasn't)
Findings	Detailed vulnerability descriptions
Evidence	Screenshots, logs, proof of exploitation
Risk ratings	Severity of each finding
Recommendations	Specific remediation steps
Retesting notes	What needs to be retested

Remediation Process

1. Prioritize: Address critical and high findings first
2. Remediate: Implement fixes for vulnerabilities
3. Verify: Internal verification that fix is effective
4. Retest: Have tester verify remediation
5. Document: Update risk register and close findings

Retesting Requirements

PCI DSS requires retesting to verify remediation:

Severity	Retesting Requirement
Critical	Required before compliance validation
High	Required before compliance validation
Medium	Risk-based decision
Low	Documentation may suffice

Segmentation Testing

If you use network segmentation to reduce PCI scope, additional testing is required:

What to Test

• Can you reach the CDE from out-of-scope networks?
• Are firewall rules effectively enforcing segmentation?
• Can lateral movement bypass segmentation controls?
• Are there any unexpected paths into the CDE?

Testing Frequency

• At least every 6 months
• After any changes to segmentation controls or methods
• After significant infrastructure changes

Segmentation Testing Methodology

1. From each out-of-scope network segment, attempt to connect to CDE systems
2. Test all common protocols (TCP, UDP, ICMP)
3. Test for indirect access paths (through shared services)
4. Document all testing and results

Common Penetration Testing Findings

Network-Layer Findings

Finding	Impact	Remediation
Weak firewall rules	Unauthorized access	Review and tighten rules
Missing patches	Known vulnerabilities exploitable	Implement patch management
Default credentials	Easy system compromise	Change all defaults
Exposed management ports	Direct system access	Restrict access, use jump hosts
Weak segmentation	Expanded scope, lateral movement	Implement proper segmentation

Application-Layer Findings

Finding	Impact	Remediation
SQL injection	Data breach, system compromise	Input validation, parameterized queries
Cross-site scripting	Session hijacking, phishing	Output encoding, CSP
Broken authentication	Account takeover	Strong authentication, MFA
Insecure direct object references	Unauthorized data access	Access control checks
Missing encryption	Data exposure	Implement TLS, encryption at rest

Frequently Asked Questions

Can we use automated tools only?

No. PCI DSS requires penetration testing, not just automated scanning. While automated tools are part of the methodology, manual testing and exploitation are required.

How much does a PCI penetration test cost?

Costs vary widely based on scope. A simple environment might cost less than $10,000, while complex environments with many applications can cost significantly more. Get quotes based on your specific scope.

Can the same firm do our pen test and vulnerability scan?

Yes, but ensure they are providing distinct services. The quarterly vulnerability scan (Requirement 11.3) is different from the annual penetration test (Requirement 11.4).

What if we find a critical vulnerability?

Address it immediately. PCI DSS requires critical and high findings to be remediated before you can attest to compliance. Implement compensating controls if immediate remediation isn't possible.

Do we need to test production systems?

Testing production is most realistic but requires careful planning. Some organizations test production during low-activity windows; others use production-equivalent test environments. Discuss with your QSA if using non-production.

---

Need help planning your PCI penetration test or addressing findings? Talk to our team

---

Sources

• PCI DSS v4.0.1 Requirement 11.4 - Penetration testing requirements
• PCI SSC Penetration Testing Guidance - Supplemental guidance
• NIST SP 800-115 - Technical Guide to Information Security Testing
• OWASP Testing Guide - Web application testing methodology