PCI DSS 4.0 Penetration Testing Requirements

What Changed in PCI DSS 4.0

PCI DSS 4.0 replaced version 3.2.1 on March 31, 2024, with all requirements becoming mandatory by March 31, 2025. The penetration testing requirements stayed mostly intact, but the way organizations need to approach and document testing shifted in a few meaningful ways.

The biggest change is the move toward a “customized approach.” Under 3.2.1, organizations followed a defined set of testing procedures. Version 4.0 introduces the option to meet requirements through alternative controls, as long as you can demonstrate those controls meet the stated security objective. For penetration testing, this means you can adjust your methodology, but you need to clearly document how your approach satisfies the requirement’s intent.

Version 4.0 also puts more weight on authenticated testing and internal assessment. The standard now explicitly expects testing from the perspective of an authenticated user, not just an external attacker probing the perimeter.

Who Needs a PCI DSS Penetration Test

Any organization that stores, processes, or transmits cardholder data needs to comply with PCI DSS. That includes merchants, payment processors, fintech companies, e-commerce platforms, and service providers that handle card data on behalf of others.

The specific penetration testing requirements depend on your SAQ (Self-Assessment Questionnaire) type or whether you’re a Level 1 merchant or service provider undergoing a Report on Compliance (ROC).

If you’re unsure which SAQ applies to your organization, your Qualified Security Assessor (QSA) or payment brand can help clarify. For SaaS companies processing payments, our guide on penetration testing for SaaS companies covers the broader testing scope beyond PCI DSS. Fintech companies handling card data should also review our fintech penetration testing guide.

Requirement 11.4: The Penetration Testing Standard

PCI DSS 4.0 Requirement 11.4 spells out exactly what your penetration test must cover. This isn’t optional. If your pen test doesn’t meet these sub-requirements, your QSA will flag it during assessment.

11.4.1: A Defined Methodology

Your pen test must follow a recognized, documented methodology. The standard references NIST SP 800-115, the OWASP Testing Guide, PTES, and CREST as acceptable options. A purely ad-hoc approach without documented methodology won’t pass.

The methodology must cover testing from both inside and outside the network, and it needs to address all of the cardholder data environment (CDE), including systems, networks, and applications.

11.4.2: Internal Network Testing

The pen test must include testing from inside the network. This means simulating an attacker who already has a foothold, whether through a compromised employee workstation, a breached vendor VPN connection, or physical access to the office. The test should attempt lateral movement toward the CDE and demonstrate whether network segmentation actually contains an attacker.

DarkPoint’s internal network penetration testing covers Active Directory attacks, privilege escalation, lateral movement, and segmentation bypass attempts.

11.4.3: External Network Testing

External testing targets everything reachable from the internet. This includes web applications, APIs, VPN endpoints, email gateways, DNS servers, and any public-facing infrastructure. The goal is to breach the perimeter and access the CDE from the outside.

Your external network attack surface often includes systems you’ve forgotten about: staging environments, legacy portals, development servers sitting on production networks.

11.4.4: Remediation and Retesting

When the pen test finds exploitable vulnerabilities, PCI DSS 4.0 requires you to fix them and retest. You can’t just acknowledge findings and move on. The remediation must be verified through retesting, and the results need to be documented in your pen test report.

11.4.5: Customized Approach Validation

If your organization uses the customized approach for any PCI DSS requirement, you need a targeted risk analysis that justifies your alternative controls. Your pen tester should understand the customized approach well enough to validate that alternative controls actually achieve the security objective.

Segmentation Testing

This catches organizations off guard more than any other requirement.

If you use network segmentation to isolate your CDE from the rest of your network (and you almost certainly do), Requirement 11.4.6 requires you to test that segmentation every six months for service providers and annually for merchants.

Segmentation testing is not the same as a network penetration test. It specifically validates that traffic from out-of-scope networks cannot reach the CDE. Every segment, every VLAN, every firewall rule that’s supposed to keep non-CDE systems away from cardholder data needs to be verified.

Organizations that fail segmentation testing face a painful outcome: their entire network may be pulled into PCI scope. That means every system, every workstation, every server now needs to meet PCI DSS requirements. The cost difference between a segmented CDE and a flat network in PCI scope is enormous.

How Often You Need to Test

PCI DSS 4.0 sets clear testing frequencies:

• Full internal and external penetration testing at least once every twelve months
• After any significant change to infrastructure, applications, or network architecture
• Segmentation testing every six months for service providers, annually for merchants

“Significant change” is where many organizations get tripped up. PCI DSS 4.0 defines this broadly. A major application update, a network redesign, a cloud migration, adding a new payment channel, replacing your firewall — all of these qualify. If the change touches the CDE or anything that protects it, you probably need to retest.

Common Reasons Organizations Fail PCI Pen Tests

Weak Network Segmentation

The most frequent failure. Organizations set up VLANs and firewall rules to isolate the CDE, but exceptions creep in over time. A temporary rule that was never removed. A management interface that bridges two segments. A misconfigured switch port that allows traffic to leak between VLANs. Segmentation testing catches these.

Default and Weak Credentials

Default credentials on network devices, databases, and application servers within the CDE are still common. Service accounts with passwords that haven’t changed in years. Admin panels with factory defaults. These are easy wins for an attacker and automatic findings in a pen test.

Missing Patches on CDE Systems

Systems in the CDE running outdated software with known vulnerabilities. This includes operating systems, web servers, database servers, and third-party applications. PCI DSS requires timely patching, and a pen test will validate whether unpatched systems are actually exploitable.

Insufficient Access Controls

User accounts with more privileges than they need. Shared accounts. Service accounts with domain admin rights. Lack of multi-factor authentication on remote access to the CDE. Access control failures are among the most common pen test findings in PCI environments.

Application-Layer Vulnerabilities

SQL injection, cross-site scripting, authentication bypasses, and insecure API endpoints in payment applications. If your payment application handles card data directly, web application penetration testing is a required part of your PCI pen test.

What Your QSA Expects to See

Your QSA will review your penetration test report during the PCI DSS assessment. They’re looking for specific elements, and if these are missing, they’ll ask questions you don’t want to answer.

The report must clearly show:

• The scope of testing, mapped to the CDE and connected systems
• The methodology used, referencing one of the accepted industry standards
• Testing dates and duration
• Findings rated by severity with evidence of exploitation
• Remediation steps taken for each finding
• Retesting results confirming fixes were effective
• Segmentation testing results, if applicable
• The tester’s qualifications and independence from the organization being tested

That last point matters. PCI DSS requires the pen tester to be independent from the systems being tested. An internal team can perform the test if they meet independence requirements, but most organizations use an external provider to avoid any question of conflict.

Choosing a PCI DSS Penetration Testing Provider

Not every pen testing firm produces reports that satisfy PCI DSS requirements. A generic pen test report that doesn’t address PCI-specific scope, methodology documentation, and retesting will create problems during your assessment.

What to Look For

• Experience producing PCI DSS-specific pen test reports that QSAs accept without pushback
• Understanding of CDE scoping, segmentation validation, and PCI-specific testing requirements
• Testers with practical offensive certifications (OSCP, OSWE, OSCE) who do manual testing beyond automated scanning
• Retesting included as part of the engagement rather than billed separately
• Willingness to work directly with your QSA if they have questions about findings or methodology

Red Flags

• The provider proposes automated scanning and calls it a penetration test. PCI DSS explicitly requires testing that goes beyond automated tools.
• No experience with PCI DSS engagements or compliance reporting
• Can’t explain how they document methodology, scope, and retesting in their reports
• Flat pricing with no scoping discussion, because PCI pen tests vary significantly based on CDE size, network architecture, and application complexity

For a broader look at the Canadian market, see our guide to the best penetration testing companies in Canada. For pricing context, our breakdown of penetration testing costs in Canada covers what drives engagement pricing. If you’re evaluating providers for the first time, our post on choosing a penetration testing company walks through the full evaluation process.

How DarkPoint Handles PCI DSS Penetration Testing

DarkPoint provides dedicated PCI DSS penetration testing for merchants, service providers, and payment processors across Canada. Every engagement is led by OSCP, OSCE, and OSWE certified consultants who perform the majority of testing manually.

Our PCI DSS engagements include:

• Full internal and external penetration testing scoped to your CDE and connected systems, with clear documentation of what’s in scope and why
• Segmentation testing that validates every boundary between your CDE and out-of-scope networks
• Web application and API testing for payment applications that handle cardholder data directly
• Reports structured for QSA review with methodology documentation, severity-rated findings, exploitation evidence, and remediation retesting results
• Remediation retesting included at no additional cost
• Direct availability to your QSA during assessment season if they have questions about findings or methodology

We also provide SOC 2 penetration testing for organizations that need to satisfy multiple compliance frameworks in a single engagement. Many of our PCI clients also run cloud penetration testing and red team engagements alongside their PCI assessment to get a fuller picture of their exposure.

Bottom Line

PCI DSS 4.0 doesn’t change whether you need a penetration test. It raises the bar on how that test needs to be conducted, documented, and validated. Requirement 11.4 spells out specific expectations for methodology, scope, remediation, and retesting. Segmentation testing alone can make or break your assessment.

The organizations that run into problems aren’t the ones with terrible security. They’re the ones that treated pen testing as a checkbox exercise: run an automated scan, put it in a report, and hope the QSA doesn’t look too closely. That doesn’t work under 4.0.

A properly scoped PCI DSS pen test, conducted by qualified testers and documented for QSA review, is one of the most direct ways to close compliance gaps and actually improve your security at the same time.

Ready to meet your PCI DSS 4.0 penetration testing requirements? Contact us to scope a penetration testing engagement designed for your cardholder data environment.