PCI DSS 4.0 Penetration Testing Requirements: What Changed and What You Need to Do

PCI DSS 3.2.1 is gone. The Payment Card Industry Data Security Standard moved to version 4.0, and with it came real changes to how organizations must approach penetration testing. If you process, store, or transmit cardholder data, this affects you directly.

We run PCI penetration tests regularly, and we see the same confusion from clients every time a standard version changes. This post breaks down exactly what's different under PCI DSS 4.0, what stayed the same, and what you need to do about it.

What PCI DSS 4.0 Changed

PCI DSS 4.0 was released in March 2022 with a transition period that has now passed. Organizations must be fully compliant with all 4.0 requirements, including the future-dated requirements that became mandatory on March 31, 2025. If you're still operating under 3.2.1 assumptions, you're out of compliance.

The changes that matter most for penetration testing fall under Requirement 11.4. Here's what's different.

Requirement 11.4.1: A Defined Methodology

PCI DSS 4.0 now explicitly requires that your penetration testing follow a defined, documented methodology. The standard calls out industry-accepted approaches (NIST SP 800-115, OWASP Testing Guide, PTES, among others). This isn't optional language. Your pentest provider needs to follow a recognized methodology and document it in the report.

Under 3.2.1, methodology was mentioned but loosely enforced. Under 4.0, QSAs are looking for it.

Requirement 11.4.1: Internal and External Testing Annually

This hasn't changed in principle. You still need both internal and external penetration tests at least once every 12 months. But the emphasis is sharper. The test must cover the entire cardholder data environment (CDE), including systems connected to the CDE and any systems that could affect its security.

Requirement 11.4.2: After Significant Changes

You must also run penetration tests after any "significant change" to your environment. This was in 3.2.1 as well, but 4.0 provides more clarity on what counts. We'll cover that in detail below.

Segmentation Testing: Every Six Months

If you use network segmentation to reduce your PCI scope (and most organizations do), Requirements 11.4.5 and 11.4.6 apply to you.

Segmentation controls must be tested every six months, not annually. This is one of the most commonly missed requirements we see. Organizations run their annual pentest and assume they're covered. They're not.

Segmentation testing verifies that the controls isolating your CDE from the rest of your network actually work. The tester attempts to cross segmentation boundaries, from non-CDE segments into the CDE, to confirm that traffic is properly blocked.

For service providers, this requirement is even stricter. Service providers must perform segmentation testing every six months and after any changes to segmentation controls or methods.

What Segmentation Testing Actually Involves

• Port and protocol testing across segment boundaries
• Attempting lateral movement from out-of-scope networks into the CDE
• Validating firewall rules and ACLs that enforce segmentation
• Testing both inbound and outbound traffic restrictions

If your segmentation fails the test, your entire network may be considered in-scope for PCI. That dramatically increases the cost and complexity of compliance.

Authenticated Internal Scanning

PCI DSS 4.0 introduced a new emphasis on authenticated internal vulnerability scanning under Requirement 11.3.1.2. While this is technically a scanning requirement rather than a pentest requirement, it directly affects how penetration testers approach internal assessments.

Authenticated scans use credentials to log into systems and inspect them from the inside. They catch vulnerabilities that unauthenticated scans miss entirely: missing patches, misconfigurations, weak local policies. Under 4.0, organizations must perform authenticated scans or document why they can't for specific systems.

In practice, this means your internal penetration test should also incorporate authenticated testing. A tester who only runs unauthenticated attacks against your internal network is leaving gaps that your QSA will question.

Quarterly ASV Scans: Still Required

Quarterly external vulnerability scans by an Approved Scanning Vendor (ASV) remain a requirement under 11.3.2. These are separate from penetration tests. An ASV scan checks your external-facing systems for known vulnerabilities and produces a pass/fail result.

Don't confuse ASV scans with penetration testing. They serve different purposes. ASV scans are automated and check for known issues. Penetration tests are manual, go deeper, and test whether an attacker could actually exploit weaknesses in your environment.

You need both. Four ASV scans per year (quarterly) plus at least one full penetration test annually, plus segmentation testing every six months if applicable. Our PCI ASV scanning service covers the quarterly scan requirement, and our penetration testing service covers the pentest and segmentation components.

What Counts as a "Significant Change"

Requirement 11.4.2 says you must retest after significant changes, but "significant" has always been vague. PCI DSS 4.0 gives more guidance. A significant change is anything that could affect the security of the CDE or the effectiveness of PCI controls.

In practice, that includes:

• New systems added to the CDE, such as new servers, databases, or applications that process cardholder data
• Network architecture changes, including new firewall rules, re-segmented networks, VPN changes, or cloud migrations
• Major application updates: new payment flows, changes to how cardholder data is captured or stored, API changes
• Operating system or platform changes, such as migrating from on-prem to cloud or changing hosting providers
• New third-party connections: new payment processors, service integrations that touch the CDE
• Changes to segmentation controls, including modified firewall rules, updated ACLs, or new VLANs

A routine software patch typically doesn't qualify. But upgrading your e-commerce platform or moving your card processing to a new cloud environment does. When in doubt, test. The cost of a targeted pentest after a change is always less than the cost of a breach or failed audit.

Common PCI Pentest Failures

We've run hundreds of PCI penetration tests. These are the issues we find most often.

Flat Networks

No segmentation at all. The POS system sits on the same network as the receptionist's workstation. Once an attacker gets into any system, they can reach the CDE without restriction. This is the single most common critical finding in PCI pentests.

Segmentation That Doesn't Work

The network diagram shows segmentation. The firewall rules are supposed to enforce it. But when we test, traffic passes freely between segments. Misconfigured rules, overly broad exceptions, and forgotten temporary access entries are usually the cause.

Default Credentials

Network devices, database servers, and management interfaces running with factory-default usernames and passwords. Under PCI DSS 4.0 Requirement 2.2.2, all default credentials must be changed before systems enter the CDE. We still find them regularly.

Unencrypted Cardholder Data in Transit

Cardholder data moving between systems without TLS or with outdated TLS versions. PCI DSS 4.0 Requirement 4.2.1 requires strong cryptography for cardholder data transmitted over open, public networks. We also find unencrypted internal transmissions that organizations assumed were safe because they were "inside the firewall."

Weak Access Controls

Shared accounts, excessive privileges, and missing multi-factor authentication on administrative access to the CDE. PCI DSS 4.0 strengthened MFA requirements under 8.4.2, requiring MFA for all access into the CDE, not just remote access.

Customized Approach vs. Defined Approach

PCI DSS 4.0 introduced a new option: the customized approach. Under the defined approach, you implement controls exactly as the standard describes. Under the customized approach, you can meet the security objective using different controls, as long as you can prove they work.

This directly affects penetration testing scope. If your organization uses the customized approach for any requirements, your pentest must validate that your custom controls actually achieve the stated security objective. This typically means a broader, more detailed test.

For most organizations, especially those at SAQ levels or going through their first PCI assessment, the defined approach is simpler. The customized approach is best suited for large organizations with mature security programs that need flexibility.

Regardless of which approach you take, the penetration testing requirements under 11.4 apply the same way. You still need annual testing, segmentation validation, and post-change testing.

What to Look for in a PCI Pentest Provider

Not every penetration testing firm understands PCI. Here's what matters when choosing a provider for PCI DSS 4.0 testing:

• PCI-specific experience. Your tester should know the CDE, segmentation requirements, and how QSAs evaluate pentest reports
• Documented methodology. 4.0 requires it, so make sure your provider delivers it
• Manual testing. Automated scans alone won't satisfy Requirement 11.4
• Retesting included. You need evidence that findings were remediated, and that should be part of the engagement
• Industry certifications. OSCP, CISSP, OSWA, or equivalent credentials on the actual testers (not just the company)
• Clear reporting. Findings mapped to PCI requirements so your QSA can trace the results directly

At Voke Cyber, we handle all of this. Every PCI penetration test we deliver includes a methodology section mapped to industry standards, manual testing by certified professionals, and free retesting within 30 days. We work with your QSA to make sure the report gives them exactly what they need.

Timeline: Where You Should Be Right Now

The transition period is over. All PCI DSS 4.0 requirements, including the future-dated requirements, are now mandatory. If your last pentest was performed under 3.2.1 standards, it may not meet the 4.0 requirements for methodology documentation, authenticated scanning, or segmentation testing frequency.

Here's what to do:

1. Review your last pentest report. Does it document the methodology used? Does it cover both internal and external testing? Did it include segmentation validation?
2. Check your segmentation testing schedule. If you're only testing segmentation annually, you're out of compliance. Move to every six months.
3. Confirm your ASV scan schedule. Quarterly scans must be current with passing results.
4. Identify any significant changes. If you've made changes to your CDE since your last pentest, you need a new test.
5. Schedule your next pentest under 4.0 standards. Make sure your provider explicitly tests against PCI DSS 4.0 requirements.

If any of these items are unresolved, don't wait for your next assessment cycle. The cost of a failed PCI audit, or worse, a cardholder data breach, far exceeds the cost of testing.