1 | Why PCI DSS Requires Pen Tests
The current standard, PCI DSS v4.0 (and its minor update v4.0.1), makes penetration testing a mandatory, annual activity under Requirement 11.4.
- 11.4.2 – Internal penetration testing (inside the card-holder-data environment, or CDE)
- 11.4.3 – External penetration testing (Internet-facing systems that touch the CDE)
- 11.4.5/11.4.6 – Segmentation testing to prove that “out-of-scope” networks really are isolated
Important date: PCI DSS v3.2.1 was retired on 31 March 2024; v4.0+ is now the only active version
2 | Start by Mapping Your Cardholder Data Environment (CDE)
Think of the CDE as every place that stores, processes, or transmits payment-card data—including any system that can reach those places. Anything that can “talk to” the CDE (even a jump-box or a reporting database) is in scope until you can cryptographically or physically prove otherwise.
3 | Typical Merchant Set-ups & What Must Be Tested
| Scenario | What’s in Scope for PCI Pen Testing | Notes |
|---|---|---|
| A. Hosted Payment Page (you redirect shoppers to a provider such as Stripe Checkout) | • Company website front-end (external test) • Segmentation controls that keep the site away from back-office networks | Usually no internal test if card data never touches your servers, but you must prove that via segmentation testing. |
| B. Direct-Post / JavaScript Payment Form (card data passes through your web server) | • External & internal networks where the web server lives • Web application/API penetration test• Segmentation between CDE and corporate LAN | Even transient card data makes the web and DB tiers part of the CDE. |
| C. Full Web-App that Stores CHD (e-commerce, subscription platform, etc.) | Everything in B plus: • Database clusters • Backup storage • Admin consoles • Any jump boxes or developer VPNs | Expect both grey-box app testing and deeper internal testing. |
| D. Cloud-Native Micro-services (AWS, Azure, GCP) | • VPCs/VNETs containing CDE workloads (internal) • Public endpoints (external) • IAM roles, container registries, serverless functions that handle CHD | Make sure your provider lets testers in; cloud responsibility is shared |
| E. Colocation / On-prem Data Center | • All racks, switches, firewalls in the CDE VLANs (internal) • External perimeter firewalls, VPNs, WAFs (external) • Wireless networks that touch the CDE | Physical security and wireless are often overlooked but still in scope. |
4 | Types of PCI Pen Testing (and When to Use Them)
| Test Type | Purpose | Typical Depth |
|---|---|---|
| External Network Test | Simulate an Internet attacker; find paths into the CDE | Usually grey-box (basic target list, no creds) |
| Internal Network Test | Assume attacker already breached perimeter; validate lateral movement defenses | Grey-box or white-box (limited creds & diagrams accelerate the test) |
| Segmentation Validation | Prove that “out-of-scope” networks can’t reach the CDE | Always white-box—tester needs diagrams and access to routers/firewalls |
| Application Pen Test (web, mobile, APIs) | Identify auth, logic, and data-handling flaws in payment applications | Black, grey, or white box depending on risk and budget |
| Wireless Pen Test | Ensure rogue APs or weak encryption don’t bridge into the CDE | Required if you use or allow Wi-Fi anywhere near the CDE |
Black-box vs. Grey-box vs. White-box
- Black-box (“no inside knowledge”) looks realistic but is time-intensive – NOT recommended for PCI compliance
- Grey-box (limited knowledge such as an IP list and one low-priv credential) gives the best bang-for-the-buck for PCI.
- White-box (full diagrams, full creds) is essential for segmentation tests and for tightly scoped internal reviews.
5 | How Often? Who Can Perform the Test?
- Frequency: at least every 12 months and after any “significant change” (new data center, major app release, firewall swap, etc.)
- Independence: the tester must be organizationally separate from the team that maintains the CDE; they do not have to be a QSA or ASV
6 | Key Deliverables You Should Expect
- Executive Summary – risk-ranked, jargon-free overview for leadership.
- Technical Findings – each vuln with proof-of-concept, CVSS/CWEs, and remediation steps.
- Segmentation-Validation Letter – proves out-of-scope networks are isolated.
- Retest / Closure Report – evidence that critical issues were fixed.
- Attestation for Your QSA or Bank – many providers supply a formal “letter of attestation” referencing PCI DSS 11.4.
7 | Your Pre-Engagement Checklist
| Item | Why the Tester Needs It |
|---|---|
| Network diagrams & cloud account IDs | To map internal & external attack paths |
| Public IP ranges, domains, sub-domains | For external scoping; avoid hitting third-party assets |
| VLAN / VPC segmentation rules | For segmentation validation |
| Test credentials (least-priv & admin) | For grey/white-box depth without wasting test hours |
| Change-freeze & maintenance windows | To avoid disrupting production |
| Contact list for live incident handling | Required by PCI pen-test “Rules of Engagement” |
8 | Frequently Asked Questions
“Can I just run a vulnerability scan instead?”
No. Scans are automated and required quarterly under PCI Requirement 11.3, but pen-testing (11.4) is deeper and manual.
“Do home-grown staging sites count?”
If they can reach production CHD systems (or vice-versa), they’re in scope. Isolate them or include them in the test.
“What if I outsource everything to the cloud?”
You still own PCI compliance. Cloud providers supply infrastructure security, but you must test your virtual networks, workloads, and segmentation.
Takeaways
- Define the CDE first; scope follows.
- Minimum tests: annual external, internal, and segmentation.
- Choose grey-box for efficiency, white-box for segmentation
- Keep evidence for at least 12 months—your QSA will ask.
By understanding why each piece of your environment is in (or out of) scope, you’ll be able to request the right penetration test, avoid surprise costs, and – most importantly – protect your customers’ card data while meeting PCI DSS requirements.
