PCI DSS Requirement 11.4 breakdown

Requirement 11.4 mandates penetration testing to validate that security controls protecting cardholder data actually work. It’s not optional—your QSA will ask for penetration test reports during assessment, and you can’t pass certification without them.

What we actually test

External testing

We attack your internet-facing infrastructure from outside your network the same way an external attacker would. This covers everything in your CDE that’s reachable from the internet.

• Payment gateway and processor connections: API endpoints, tokenization services, 3DS authentication, webhook handlers
• E-commerce applications: Checkout flows, payment forms, session management, authentication, account takeover vectors
• Web application vulnerabilities: SQL injection, XSS, CSRF, authentication bypass, authorization flaws, business logic issues
• Network infrastructure: Firewalls, VPN endpoints, load balancers, exposed management interfaces
• SSL/TLS configuration: Certificate validation, cipher suites, protocol versions, forward secrecy

Internal testing

We test from inside your network assuming an attacker has already gained initial access (phishing, compromised vendor, rogue employee). Goal is to see if they can reach cardholder data.

• Active Directory attacks: Kerberoasting, AS-REP roasting, privilege escalation, domain admin compromise
• Lateral movement: Pass-the-hash, credential reuse, SMB relay, RDP pivoting to CDE systems
• Database security: Direct access to databases storing PAN, authentication bypass, SQL injection from internal apps, insufficient access controls
• Application servers: Payment processing systems, POS backend infrastructure, card data transmission paths
• Sensitive data discovery: Unencrypted cardholder data in file shares, backups, log files, memory dumps

Segmentation testing (if applicable)

If you’re using network segmentation to reduce PCI scope, we validate that the segmentation actually works. This is critical—if segmentation fails, your entire network might be in scope.

• Firewall bypass attempts: Testing ACLs, NAT configurations, routing misconfigurations that could allow unauthorised access to CDE
• VLAN hopping: Double tagging, switch spoofing, attacking trunk ports
• Physical segmentation validation: Verifying CDE is on separate switches/routers, not just logical VLANs
• Connect-back testing: We use custom hardware devices placed in non-CDE networks, attempting to establish connections to CDE systems
• Wireless network isolation: Testing if guest WiFi or corporate WiFi can reach CDE when it shouldn’t

What’s different about our approach

We’ve worked with multiple QSAs: We know what they look for in penetration test reports. Our documentation format matches what assessors expect, which means you won’t be asked to redo testing because the report format was wrong.

Manual testing, not just automated scans: Vulnerability scanners are required for PCI (Requirement 11.3), but they’re not sufficient for penetration testing. We perform manual exploitation, business-logic testing, and attack-chain development that scanners miss. For example: scanner finds SQLi, we exploit it to dump the customer database, including masked PANs and encryption keys.

Segmentation testing experience: We’ve built custom hardware connect-back devices for segmentation testing on multiple engagements. Most pentest firms don’t have this capability and just test firewall rules remotely, which doesn’t properly validate physical segmentation.

Understanding of payment systems: We’ve tested payment gateways, tokenisation services, POS systems, and e-commerce platforms across Stripe, Adyen, Worldpay, and custom payment processors. We know payment-specific attack vectors like race conditions in refund processing, amount manipulation, and token substitution attacks.

Cloud environment expertise: Many payment environments now run on AWS, Azure, or GCP. We test cloud-specific risks: S3 buckets with cardholder data, overly permissive IAM roles, Lambda functions processing payments, API Gateway misconfigurations, and container escape to access payment databases.

Pricing and timeline

Cost depends on CDE scope—how many applications, how many network segments, whether segmentation testing is needed, cloud vs on-premise infrastructure.

Scope	Typical price	Timeline
Small (single payment app, simple network)	€3,000 – €5,000	1-2 weeks
Medium (multiple apps, internal network, basic segmentation)	€5,000 – €10,000	2-4 weeks
Large (complex e-commerce, multi-site, extensive segmentation)	€10,000 – €25,000	3-6 weeks
Enterprise (multiple brands, cloud + on-prem, global infrastructure)	€25,000+	6-8 weeks

All prices include initial testing, comprehensive report, one round of remediation retesting, and final attestation documentation. Additional retesting rounds (if you need to retest more than once) are billed separately at daily rates.

Timeline assumes you can provide CDE access and answer scoping questions promptly. Add 1-2 weeks if we need to wait for credentials, firewall rules, or approvals from third-party providers.

Frequently Asked Questions

Get started

Contact us with information about your CDE scope, timeline for QSA assessment (if scheduled), and whether you’re using network segmentation. We’ll provide a detailed quote within 48 hours and can usually start testing within 2-3 weeks.