PCI DSS penetration testing requirements (2025): What you need to know

Consider this: you’ve safely walled off your cardholder data environment (CDE) from other network components. Just then, your team adds a new third-party tool to your tech stack. To test the segmentation, they quickly review existing diagrams and firewall rules. 

However, they overlook the fact that the new tool inadvertently created a backdoor directly to your CDE.

This, and other such slips, could lead to non-compliance with PCI DSS 4.0, the global payment data security standard that took full effect on March 31, 2025. Not only that, it could result in unresolved vulnerabilities, data breaches, and reputational damage.

That’s where PCI DSS penetration testing comes in. With it, you can simulate real-world cyberattacks to find and fix security vulnerabilities within your critical systems before cybercriminals do.

Besides protecting your CDE, regular penetration testing allows you to comply with PCI DSS 4.0 requirements, such as:

• Aligning your security policies with evolving threats.
• Validating segmentation and scope reduction.
• Maintaining more detailed documentation.

This blog is your ultimate guide to PCI DSS penetration testing and segmentation, what’s new in PCI DSS 4.0, and overcoming common compliance challenges.

Penetration testing vs. vulnerability scanning

More often than not, businesses have a common question: “Aren’t vulnerability scans and penetration tests the same thing?”

It’s a fair question, as both are similar and key to your IT security. But, in practice, they are distinct processes with different approaches and end goals.

Vulnerability scans

A vulnerability scan uses automated tools to quickly identify known weaknesses or misconfigurations across your IT systems and networks. Much like an X-ray shows only skeletal issues, it provides a quick, high-level security overview of your digital infrastructure. It only reports known issues that undermine your CDE’s security.

Vulnerability scans typically identify broad security gaps, such as:

• Outdated software or unpatched systems.
• Open ports with unnecessary services.
• Misconfigured security settings or weak passwords.

Penetration tests

A penetration test (or pen test), on the other hand, is more like an MRI that reveals intricate details and problems that an X-ray would miss. It involves a much more thorough and manual examination of your CDE and other systems. It helps gauge the actual risk and potential business impact of exploitable vulnerabilities.

It involves hiring ethical hackers to simulate a real attack on your infrastructure, especially the CDE. They don’t just find vulnerabilities; they exploit them to see how far they can break into your system and what data they can access.

Unlike vulnerability scans, pen tests cannot be fully automated. They need experts to employ manual hacking techniques to systematically check every potential point of failure and assess the impact of a breach.

For example, pen testers may focus on specific vulnerability areas, such as:

• Attempt SQL injection or cross-site scripting (XSS) on a web application.
• Test segmentation controls to see if out-of-scope systems can access the CDE.
• Simulate a phishing scam to assess employee awareness and test incident response procedures.
• Exploit cloud applications to detect misconfigurations, such as unsecured APIs or exposed payment account data.

Let’s have a quick comparison of both approaches:

Why are both required for PCI DSS compliance

Another question that might come to your mind is, “Which is better: vulnerability scan or pen test?”

The answer is that you need both of them.

Let’s look at some recent statistics:

• From 2023 to 2024, the volume of publicly disclosed vulnerabilities in the Common Vulnerabilities and Exposures (CVE) database surged by a staggering 38%. The same catalog registered, on average, 110 new vulnerabilities every day in 2024.
• Verizon’s 2025 DBIR revealed a 34% year-on-year increase in the exploitation of vulnerabilities by attackers to gain initial access and execute breaches.

Cyber threats are evolving at an unprecedented pace. That’s why both frequent scans and intermittent pen tests are vital to uncover as many weaknesses as possible.

Even the PCI Security Standards Council (PCI SSC) recognizes that these two activities work in tandem. It mandates conducting both, as they serve distinct yet complementary functions to ensure a robust security posture.

Compliance with one of its requirements involves running quarterly vulnerability scans to identify potential security gaps across your CDE and associated systems.

In effect, a vulnerability scan serves as the starting point for meeting the PCI DSS penetration testing requirements. By using the scan’s findings, you can identify specific areas where in-depth pen tests can go deeper and pinpoint the exact attack paths a malicious actor can take to break into the CDE. Further, the pen test provides insights into how you can close those gaps to prevent attackers from exploiting them.

Together, vulnerability assessment and pen testing (VAPT) help protect your entire IT infrastructure, including network devices, access points, servers, databases, applications, and cloud environments, from unauthorized access.

PCI DSS penetration testing requirements

PCI has updated its penetration testing requirements in the latest 4.0 version. But the overarching goals remain the same. Here they are:

Internal and external testing requirements

At a minimum, the PCI DSS requires you to conduct penetration testing at least annually, both internally and externally.

• Internal: An internal penetration test enables you to identify and mitigate threats that could lead to a breach of your CDE from within your internal network. These tests simulate various insider attacks, including:
  
  • Privilege escalation.
  • Pivoting.
  • Social engineering.
  • Impersonating personnel.
• External: An external penetration test simulates attacks from an external network like the Internet. It aims to find exploitable vulnerabilities in your public-facing applications, such as e-commerce websites, email servers, and APIs.

Apart from the once-a-year test, you must also perform pen tests after any significant changes to your CDE or connected systems. Think of any change that could potentially introduce new vulnerabilities or alter your security posture. It could be:

• A new application rollout.
• Major network infrastructure upgrades.
• Adding new system components in CDE.
• Significant modifications to existing systems.

Segmentation testing for out-of-scope systems

Another PCI DSS penetration testing requirement is about validating your network segmentation. Let’s say you’ve used segmentation to reduce the PCI DSS scope. In that case, you must perform penetration tests to prove that out-of-scope systems are effectively isolated. This can be done by a qualified in-house expert with extensive experience or qualified third-party testers.

Documenting testing and remediation efforts

You can’t simply prove compliance by identifying and resolving vulnerabilities; you must also demonstrate it to auditors. For that, PCI DSS requires you to document:

• Testing policies and methodologies.
• Test narrative.
• Test outcomes.
• Remediation actions.

After addressing any identified gaps, you must retest and maintain detailed records. These records serve as essential audit evidence that verifies your compliance efforts from start to finish.

What’s new in PCI DSS 4.0 for penetration testing

PCI DSS has almost always required pen tests for in-scope systems. However, the PCI SSC has made some significant updates in its latest 4.0 version.

Adapting to these changes demonstrates your commitment to continuous security (aligned with evolving threats), builds lasting stakeholder trust, and accelerates business growth.

Let’s have a quick look at the key updates in the PCI DSS penetration testing requirements:

Emphasis on testing methodology

This update clearly states that you must define and document the pen testing methodology, according to which your testers will perform the tests.

Your outlined methodology must also document an approach to evaluate and remediate all identified “security weaknesses” (besides exploitable vulnerabilities). This must be done based on your risk and impact assessment.

Additionally, PCI DSS penetration testing requirements stipulate the use of standard industry pen testing methodologies, including OSSTMM and OWASP. You must also ensure that the scope includes the entire CDE and any connected systems that could impact its security, both at the network and application layers.

What these changes mean is that you must shift your security focus towards a more systematic penetration testing approach.

More detailed documentation

The updated PCI DSS 4.0 mandates detailed and specific documentation for your penetration testing efforts. To better perform at PCI audits, you must have a thorough pen testing report that includes:

• Test scope and methodology.
• List of identified vulnerabilities with detailed descriptions.
• Risk and impact assessment of each vulnerability.
• Recommendations to remediate security gaps.
• Re-test outcomes to prove effective mitigation.

You can use this detailed report to:

• Demonstrate compliance with the new requirements.
• Gain enhanced insights into your CDE’s security status.
• Make informed decisions to strengthen your defenses.

Clarified segmentation requirements

Many businesses use segmentation to separate the CDE from other systems and reduce the PCI DSS scope. In case you’re doing it, you must, according to the new requirement, document and validate the effectiveness of all segmentation controls:

• At least every 12 months, or
• After any significant change to your segmentation controls or techniques.

Additionally, the new PCI DSS requirements state that service providers using segmentation must validate it by performing half-yearly penetration tests on segmentation controls. And whenever they are updated or modified.

Customized approach guidance

PCI DSS 4.0 has introduced a new customized approach as one of the most significant updates. With it, you can be more flexible in how you meet your security objectives, including pen testing methods.

It allows you to design and implement pen testing and scope validation methodologies tailored to your specific environments. However, you can only do it if they meet the intent of the PCI DSS 4.0 penetration testing requirements.

This means you can customize how and when you perform these tests. But only if you’ve documented a targeted risk analysis for each custom approach to prove it’s equivalent to standard requirements.

Practical scenario:

Instead of performing a large-scale annual pen test, you could design a customized schedule of more frequent, targeted pen tests. For example, you could test your external network in Q1, web applications in Q2, and internal segmentation in Q3. However, you’d need to document and justify the effectiveness of the alternative testing schedule.

Segmentation testing and scope reduction

What if you could reduce your PCI DSS scope and save tons of time and money on audits? That’s what segmentation is all about.

Network segmentation simply means dividing your entire network into smaller, isolated segments using controls such as firewalls or VLANs.

You can use it to separate systems that handle cardholder data (i.e., the CDE) from those that don’t, thereby preventing access to the CDE from out-of-scope systems. This not only limits the scope of the PCI audit but also prevents attackers from pivoting into the CDE from a connected network, unless it is isolated.

Why segmentation matters

Scope reduction is highly recommended as it offers several security-related and business benefits:

• Reduced compliance burden: With a reduced scope, you can lower the number of systems that need to comply with PCI DSS penetration testing requirements, simplifying compliance efforts.
• Lower audit costs: A smaller scope means you can reduce audit preparation efforts and save significant costs on associated activities.
• Improved time management: Testing fewer systems to validate segmentation enables you to save your team’s valuable time. This frees up their time for higher-value tasks.
• Enhanced security: Segmentation also allows for more granular control over access and data flow. This ensures only authorized access to sensitive data and potentially reduces the attack surface.
• Better incident containment: Even if a security incident occurs, segmentation can help contain it within a specific segment and recover faster from damage. It also prevents the attacker from reaching your CDE, saving your business from costly breaches and system downtimes.

Methods and tools for segmentation testing

However, segmentation is only half the battle. You must validate it, too. Under PCI DSS 4.0, proving that your segmentation truly isolates the CDE from other systems is a critical requirement.

Another PCI DSS requirement explicitly states that the testing entity must be organizationally independent. This means that whoever tests the segmentation should not be involved in its setup, management, or maintenance in any capacity.

To validate the scope, testers primarily employ penetration testing, which uses a combination of tools and techniques:

• Network port scanning and host discovery: In this method, testers conduct port scans from an out-of-scope network (e.g., VLAN, Internet) against the known IP address range of the CDE using an industry-standard tool like Nmap. If a port is found to be open, it means that there is an exploitable gap in the network, and the segmentation test fails.
• Firewall and router rule set review: Here, testers manually review the access control lists (ACLs) and rules on perimeter devices, such as firewalls and routers. They specifically look for overly permissive rules, rules that violate security policies, or misconfigurations that can be exploited to bypass security checks.
• Network traffic analysis: This method enables testers to verify that network traffic flows along the expected paths. And does not take unauthorized detours into the CDE. They use tools like Traceroute or Tracert to map the path of data packets from an out-of-scope system to the CDE. The goal is to check whether proper security controls (e.g., firewalls, routers) exist in the path. A failure would mean that there is a direct path from a segmented network into the CDE that bypasses the controls.

How auditors evaluate segmentation controls

Auditors no longer accept network diagrams alone as proof; they require comprehensive evidence that demonstrates your CDE is truly isolated, not just in theory but in practice.

Besides examining your segmentation approach, the auditor will want to see how you ensure the effectiveness of the controls through regular pen testing. For this, they will request and review documents such as:

• Network and data flow diagrams: Clear illustrations that show the CDE plus connected systems and how data moves between different network segments.
• Asset inventories: A complete list of network and system components with a clear demarcation between in-scope, connected-to, and out-of-scope systems.
• Network configurations: Firewall and router rule sets, VLAN configurations, and cloud environment rules designed to enforce segmentation.
• Access control documentation: The list of authorized personnel, their roles and privileges, and proof that the Principle of Least Privilege is enforced.
• Penetration test reports: Detailed reports of internal and external penetration testing, including scope, methodology, test results, vulnerability descriptions, and remediation suggestions.
• Remediation evidence: Proof that any vulnerabilities and weaknesses found during testing were properly corrected, and evidence of successful re-testing after remediation.

Finally, PCI DSS requires the auditors to interview security personnel to confirm that the tests were performed by a certified in-house expert or a third-party service provider.

Common mistakes and how to avoid them

Even with the best efforts, companies may stumble when it comes to PCI DSS penetration testing. Knowing the common compliance pitfalls can help you overcome them. Let’s have a look at them: 

Confusing scans with pen tests

Many companies, especially those new to handling payment data, still struggle to tell vulnerability scans apart from pen tests. Even some vendors market automated scans as pen tests, misleading their clients and putting their security at risk.

As outlined in the PCI DSS 4.0, it clearly requires conducting both quarterly scans and annual penetration tests with separate reports.

How to overcome: Remember, scans only provide an overview of vulnerabilities; threat actors can combine these weaknesses to successfully create attack paths into the CDE. Conduct yearly or more frequent pen tests to dig deep into how attackers can do it and thoroughly remediate those gaps. Partner with experts if you’re not sure when to conduct which test.

Missing documentation

Meticulous documentation is the cornerstone of a successful PCI DSS 4.0 audit. The new version requires extended documentation for each of its 12 requirements, including penetration testing.

Incomplete or missing documentation leads to non-compliance, while disorganized records can cause chaos during audits.

How to overcome: Use a compliance automation tool with a centralized hub to store and quickly retrieve crucial compliance documentation. Choose a software that also provides detailed audit trails to track changes or updates in policies, methodologies, or IT systems. Regularly review the records and keep them up to date to reflect the latest state of security and compliance efforts.

Failing to retest after remediation

Businesses often fail the PCI audit as they conduct only surface checks after remediating vulnerabilities. This not only puts the CDE at risk but also leads to non-compliance and costly audit failures.

How to overcome: Thoroughly retest the in-scope systems after every remediation action until you close all gaps. Document the retesting results to demonstrate that every vulnerability has been effectively corrected.

Using outdated testing methodologies

Cyber threats are evolving at an unprecedented rate, particularly in recent years. Traditional pen testing methods are no longer sufficient to curb attacks. Pen testers who use outdated techniques run the risk of high-risk vulnerabilities going unnoticed. This increases the likelihood of a breach, potential regulatory fines, and reputational damage.

How to overcome: Consult with security and compliance experts to conduct pen tests using PCI-recommended industry-standard methodologies (OSSTMM, OWASP, NIST 800-115) that reflect the current threat landscape. Conduct more than just once-a-year testing, depending on your company’s security needs and risk profile.

How Scrut helps with PCI DSS penetration testing compliance

Managing the complex PCI DSS penetration testing requirements can be overwhelming, especially if you’re doing it manually. From creating policies to scheduling tests, collecting evidence, and tracking remediation, it takes up a lot of resources.

This is where Scrut, a leading compliance automation platform, comes in. It’s designed to streamline PCI DSS compliance and audit requirements, including those for penetration testing.

Scrut simplifies several compliance tasks with its wide range of automation features, including, but not limited to:

• Centralized evidence storage and mapping: Use Scrut’s central storage hub to store all your security policies, penetration test reports, scope documents, and remediation evidence. Scrut also automatically maps your evidence artefacts directly to PCI DSS requirements so that you can get audit-ready in no time.
• Continuous control monitoring and alerts: Don’t just conduct once-a-year tests. Run automated tests daily to monitor your systems and identify control gaps continuously. Receive non-compliance alerts in real-time to quickly mitigate weaknesses before they become critical.
• Control status and dashboards: Get a clear view of the status of your PCI DSS segmentation and overall security controls in a single window. Scrut’s dashboards enhance visibility into real-time compliance status, tasks that need attention, and the current state of your testing activities.
• Task tracking and audit trails: Assign and track remediation tasks for vulnerabilities found during penetration testing. Scrut automatically creates detailed audit trails of actions taken, allowing you to demonstrate evidence of testing and remediation.
• Policy templates for pen testing documentation: Launch your compliance program in minutes with Scrut’s library of pre-built policies specially developed for PCI DSS controls. Alternatively, you can create and customize your own with Scrut’s policy builder and in-line editor.

Not sure where to start? Schedule your demo to see how it can help jump-start your PCI DSS compliance program.