The Essential Guide to PCI Pen Testing Requirements [Updated for 4.0]

Time’s Up. PCI DSS v4.0 Isn’t Coming—It’s Already Here.

PCI DSS v3.2.1 officially retired on March 31, 2024. That ship sailed over a year ago. Now we’re in the era of v4.0—and if you’re still treating it like a future project, you’re already behind.

This isn’t just a version bump. It’s the biggest overhaul in PCI history, packed with 63 new requirements built for today’s threat landscape. And right at the center? Penetration testing. What used to be a checkbox (Requirement 11.3) is now the backbone of your security validation under 11.4.

Still relying on automated scans to stay compliant? That won’t cut it. Scans find the easy stuff. Pen tests simulate real-world attacks—showing exactly how a hacker could break in and how far they’d get.

If you haven’t already locked in a real pen testing methodology—NIST, OSSTMM, OWASP, PTES—you’re gambling with your compliance.
And the grace period? Over. The final enforcement deadline was March 31, 2025. That means every new control is now fair game for audit.

Tick-tock’s done. Time to prove your systems can actually take a hit.

What Is PCI DSS Penetration Testing (And Why It’s a Big Deal Now)

Penetration testing is no longer just a checkbox in your compliance doc. It’s now one of the core ways PCI DSS v4.0 validates whether your defenses actually work.

So what is it?

Unlike vulnerability scans (which are automated and rule-based), penetration tests are manual, creative, and adversarial. Security professionals simulate real-world attacks—trying to break into your systems the same way threat actors would.

Scans tell you what might be vulnerable. Pen tests show how far an attacker could get if they actually exploited that weakness. It’s not theoretical. It’s proof.

v4.0 raises the bar. You’re now required to test both:

• Externally—Targeting the public-facing perimeter of your trusted networks
• Internally—Simulating attacks inside the cardholder data environment (CDE), from both trusted and untrusted sources

And it’s not just about fixing what’s exploitable. v4.0 demands you fix all security weaknesses—misconfigurations, encryption gaps, anything that could open a door, even if it hasn’t been exploited yet.

One test a year is the bare minimum. Major change to your network or systems? That triggers another test.

It’s no longer “check it off and move on.”
Penetration testing is now how you prove you’re secure.

Types of PCI DSS Pentests: Internal, External, and Segmentation

PCI DSS mandates all three types of penetration testing—no exceptions. Each targets vulnerabilities from a different angle. Miss one, and you're out of compliance.

1. Internal Testing: What if They’re Already In?

Internal tests simulate an attacker who’s gained access to your internal network—whether through a malicious insider, compromised credentials, or a breached device. The goal? Identify gaps in your CDE’s internal security.

Look for:

• Over-permissioned users
• Unpatched systems
• Misconfigured internal apps
• Weak segmentation

CISA reports over 54% of threat actors now use valid credentials. Your internal network isn’t as secure as you think.

2. External Testing: What the Internet Sees

External tests hit your internet-facing assets—cloud systems, web apps, VPNs, remote access points, and more. If it’s exposed, it’s tested.

Targets include:

• Open ports and misconfigured firewalls
• Public systems leaking internal data
• Apps vulnerable to injection, auth bypass, etc.

Even systems behind IP filtering aren’t exempt. PCI DSS requires both network and application-layer testing—no shortcuts.

3. Segmentation Testing: Are Your Walls Real?

If you’re segmenting the CDE to reduce scope, you must prove those boundaries work.

This test ensures:

• VLANs, ACLs, and firewalls block unauthorized access
• Out-of-scope systems can’t talk to CDE assets
• Controls withstand tampering or misconfig

Merchants test annually. Service providers: every six months. Major infra changes? Retest within 30 days.

Bottom line: These three tests cover the inside, outside, and everything in between. Skip one, and your entire PCI compliance falls apart.

PCI Penetration Testing Requirements Under 4.0

March 2025 came and went.

If you’re still treating PCI DSS v4.0 like it’s on the horizon, you’ve already missed the train. Every penetration testing requirement is now live, enforceable, and very much on your auditor’s radar.

v3.2.1 kept things simple. One vague checkbox. But v4.0 split it wide open—with sharper controls, stricter scopes, and zero tolerance for hand-wavy testing.

Requirements 11.4.2 & 11.4.3: Internal + External Pen Testing

Pen testing is now a two-front war—inside and out. But the rules of engagement are the same:

• Run tests at least once a year
• Test again after any major change (infra, apps, firewall, topology—you name it)
• Use qualified testers with independence from the systems they assess

Internal testing means hitting your CDE from within. That includes trusted networks and rogue internal access.

External testing is all about perimeter control—probing what’s exposed to the public internet, including any system connected to external infrastructure.

But the real kicker? v4.0 isn’t just about catching what's exploitable.
You're now required to fix all security weaknesses—misconfigurations, weak encryption, default settings, anything that weakens your posture.

And yes, you need a risk-based process to document how you triage and fix those findings.

Requirement 11.4.5: Segmentation or Bust

Relying on segmentation to reduce PCI scope? Then you’re on the hook for more than just firewalls.

You must:

• Test segmentation controls annually (and after every change)
• Prove they isolate the CDE from out-of-scope systems
• Show they hold up even when security levels differ across systems

And if you’re a service provider?
Double the pressure. Testing is now required every six months. No grace. No loopholes.

Requirement 6.4.2: Web Apps + APIs Are Now Under the Microscope

Web apps and APIs are no longer off to the side—they’re now front and centre in your compliance strategy.

v4.0 demands:

• Automated protection against XSS, injection, and other web-based attacks
• Continuous monitoring of APIs and app endpoints
• Security baked into your SDLC—not slapped on post-deploy

Hackers don’t wait for quarterly reviews. Your defenses can’t either.

Requirement 11.3: Vulnerability Scanning Grows Up

Scanning isn’t a box to tick anymore. It’s now deep, continuous, and unavoidable:

• 11.3.1.1: You must fix non-high-risk internal vulnerabilities, not just the scary ones

• 11.3.1.2: Internal scans must be authenticated, so you’re not just scratching the surface

• 11.3.2: ASV external scans? Still required, still quarterly

Even SAQ A merchants—those with minimal PCI scope—are now pulled into external scan territory.

Authenticated scanning brings real visibility into API security gaps, broken access controls, and bad defaults. And if you’re still running unauthenticated scans? You're flying blind.

Tools and Techniques Used in PCI DSS Penetration Testing

Great pen tests aren’t about brute force—they’re about precision. And that starts with the right tools.

Under PCI DSS v4.0, it’s not enough to find vulnerabilities. You have to prove they’re real, exploitable, and tied to risk. That’s how you earn trust with your QSA—and stay compliant.

Here are the tools every PCI-ready pen test should include:

1. Nmap
2. Burp Suite + OWASP ZAP
3. Nessus + Nikto
4. Metasploit
5. Wireshark

Let’s break down what each tool brings to the table.

1. Nmap: Your Network X-Ray

Nmap is essential for mapping the Cardholder Data Environment (CDE). It finds hosts, open ports, running services, and OS details. It's also used heavily in segmentation testing to validate isolation controls.

Command tip: nmap -sV -O 192.168.1.10 reveals service versions and OS in one go.

2. Burp Suite + OWASP ZAP: Web App Defense

Web apps remain a top attack vector.
Burp Suite Pro gives you automated scans, CVSS scores, request interception, and PCI-specific reports.

OWASP ZAP brings speed and CI/CD integration, helping you test apps before they go live.
Together, they cover both manual testing and automated pipelines.

3. Nessus + Nikto: Vulnerability Scanners

Nessus digs deep into systems, services, and endpoints—finding CVEs, patch gaps, and config errors.

Nikto complements it by scanning for over 3,500 risky files, directories, and SSL issues.
Paired, they reduce triage time and give you clean, exportable reports for auditors.

4. Metasploit: Exploitation with Control

Found a critical vulnerability? Metasploit confirms if it’s exploitable—safely.

It aligns with PCI requirements like 6.1 and 8.5.x and includes templated reports for compliance.
Proof > assumption. That’s what your QSA wants.

5. Wireshark: Packet-Level Visibility

Wireshark inspects live traffic to spot plaintext cardholder data, weak encryption, and misconfigurations.

For PCI Req. 4.1 (data encryption in transit), it’s your best validator—and a favorite of many QSAs.
If your tester isn’t analyzing traffic, they’re missing the last mile.

Bottom line: The right tools don’t just help you pass—they help you prove. In PCI 4.0, real risk is what matters.

How to Prepare for a PCI Compliance Penetration Testing Engagement

Here’s the truth: most teams stumble through PCI prep and pay the price later in failed audits or endless remediation. Don’t be one of them. Solid preparation turns penetration testing from a stress point into a strategic win.

These are the steps that set up a smooth, successful PCI DSS penetration test:

1. Define the scope and CDE boundaries
2. Choose the right penetration testing partner
3. Plan pre-engagement details carefully
4. Handle findings and schedule retesting

Let’s dive into each step.

1. Define Scope and CDE Boundaries

Get your scope wrong, and everything else falls apart. You’ll either test systems that don’t matter or miss critical risks entirely.

Start by:

• Inventorying all in-scope assets
• Mapping network boundaries with diagrams
• Including connected systems that impact CDE security

Nearly 50% of companies get this step wrong. Don’t let poor scoping tank your assessment.

2. Choose the Right Testing Partner

Not all pen testers are built the same. Some hand over pretty PDFs that fail to catch real threats.

Look for:

• Certifications like OSCP, CEH, CREST, or GSNA
• Experience in your industry and environment size
• Independence—testers shouldn’t manage your systems

3. Pre-engagement Planning

Before testing begins, lock in:

• Testing windows that avoid peak business hours
• Excluded systems and IPs
• Clear communication for real-time critical findings

This planning avoids surprises—like accidentally taking down your card processing mid-launch.

4. Remediation and Retesting

The report’s in. Now act fast:

• Triage findings by severity and business impact
• Fix high-risk issues ASAP
• Schedule retests to confirm fixes (yes, PCI requires it)

Organizations that follow a structured remediation process are 30% more likely to pass the next PCI assessment. Why? They treat testing as part of continuous improvement—not just compliance.

Prep well, and you’ll make the rest of the PCI journey a whole lot smoother.

Reporting and Documentation for PCI DSS Audit Readiness

Here’s the brutal truth: your pen test is only as good as your documentation. Most teams think they’re done once the testing ends. They’re wrong. The real test comes when your QSA asks for proof—and over 30% of organizations fail this step.

Your pen test report isn’t just a technical summary. It’s your compliance lifeline.

Executive Summary and Technical Findings

Your report should include:

• A clear executive overview
• Defined scope and systems
• Testing methodology and any limitations
• Segmentation results
• A narrative walkthrough of how the test was executed
• Vulnerabilities explained in plain English (jargon goes in the appendix)

CVSS Scoring and Contextual Risk Ratings

Don’t rely on raw CVSS scores alone. Two “medium” risks can mean wildly different things depending on your architecture, controls, and data sensitivity. Make sure your report explains why each finding matters in your context.

Remediation and Retesting

Compliance isn’t just identifying vulnerabilities—it’s proving you’ve fixed them:

• Track fixes with tickets or documentation
• Prioritize remediation based on PCI-defined risk levels
• Schedule retests to validate fixes
• Run quarterly scans until results are clean

Attestation and Audit Readiness

Come audit time, have these on hand:

• Letter of Attestation (LOA)
• Past 12 months of test reports
• Retest validation reports
• Scope definitions and engagement rules

Service providers also need bi-annual segmentation test documentation.

Treat documentation like your compliance depends on it—because it absolutely does.

The PCI 4.0 Deadline Is Here. Are You Ready?

March 2025 wasn’t just a deadline—it was a line in the sand. PCI DSS v4.0 brought 63 new requirements, and many companies are still scrambling to catch up.

Still relying on v3.2.1 practices? You're months behind. Half of all organizations still struggle to scope PCI correctly. And 54.3% of attackers? They get in using stolen credentials bought off the dark web.

Here’s what matters now: vulnerability scans flag risks—but only penetration tests prove them. That’s how you stay audit-ready and breach-resistant.

Your non-negotiables:

• Internal and external pen testing (at least annually)
• Segmentation testing (annually for merchants, bi-annually for service providers)
• Web app and API testing
• Quarterly vulnerability scans
• Clean, audit-ready documentation: summaries, CVSS scores, findings, retest results, attestation letters

The difference between PCI-ready and PCI-failed? Preparation. The smart teams started months ago. The rest? They’re still plugging holes—or failing audits.

This isn’t just about checking boxes. It’s about proving your security posture and protecting customer trust.

You're already five months into PCI 4.0. If you haven’t started, now’s the time.