PCI Penetration Testing Requirements

PCI penetration testing evaluates whether attackers can exploit weaknesses in systems that store, process, or transmit payment card data. PCI DSS 4.0.1 requires internal and external penetration testing at least annually and after significant changes. This guide explains the requirements and how to distinguish a genuine penetration test from a scanner-driven compliance engagement.

This guide is for buyers required to perform PCI penetration testing. Its purpose is to help you tell compliance vendors from genuine ones.

PCI DSS 4.0.1 Penetration Testing Requirements

PCI DSS 4.0.1, published in June 2024, defines the penetration testing obligation in requirement 11.4. It calls for external penetration testing, internal penetration testing, segmentation testing, and application penetration testing. It also specifies the testing cadence which is an area that many organizations struggle with.

How Often Is PCI Penetration Testing Required?

Testing must be conducted annually, at minimum, and after any significant change. The “significant change” clause is where most organizations fall out of compliance.

Significant changes include:

• Major infrastructure modifications (new segments, replaced firewalls, new DMZ)
• New applications added to the CDE
• Significant upgrades or replacements of existing applications
• Changes to network boundaries that affect scope
• Major configuration changes to in-scope systems
• Acquisition or divestiture that changes the attack surface
• Migration to, from, or between cloud providers for in-scope systems

When any of these happen between annual tests, a new test on the affected scope is owed immediately, not next quarter and not next year.

The following section provides a brief comparative overview of each test type and methodology.

External penetration testing (PCI-DSS 11.4.3)

Testing of externally facing systems in scope for the Cardholder Data Environment (CDE) is required.

• Compliance version: An automated scanner runs against the external IP range. An engineer reviews the output, filters obvious false positives, and formats the result. Exploitation, if any, is confined to known tools. Risk scores come from scanner defaults, not from tester calculations against the environment. The report typically contains false positives and higher rates of false negatives.
• Genuine version: A human operator drives the engagement. Scanners handle reconnaissance under human direction for efficiency and only as needed. Testers exploit known and novel vulnerabilities to confirm impact, chain findings into attack paths to cardholder data, and document the attack disruptors that would break each path. The deliverable tells you how an attacker would get in and what to change to make them fail. False positives are eliminated, false negatives are reduced, and risk scores reflect your actual environment and business.

Internal penetration testing (11.4.2)

Testing of internal systems in scope for the Cardholder Data Environment (CDE) is required.

• Compliance version: A scanner runs against internal IP ranges. An engineer filters and formats the output. Little or no testing of credential abuse, lateral movement, privilege escalation, or chained attack paths. Risk scores come from scanner defaults and the attestation gets signed.
• Genuine version: A human operator drives the engagement from an assumed-compromise position. Testers exercise credential abuse, lateral movement, privilege escalation, and both known and novel techniques to reach cardholder data. Testing is calibrated for fragile systems because scanners can crash legacy applications, so a competent team uses lower-impact methods and coordinates with operations where appropriate. The deliverable explains how an attacker would move through the environment and names the controls that would break each path. Again, risk scores take the customer environment and business into account.

Segmentation testing (11.4.5)

If segmentation reduces the scope of your CDE then PCI requires that segmentation be tested. This is the most mishandled test type in the market.

• Compliance version: The vendor confirms that firewall rules match the segmentation diagram and that documented controls are configured. Few or no active bypass attempts are made during testing.
• Genuine version: Operators attempt real segmentation bypasses using techniques like VLAN hopping, routing abuse, protocol tunneling, dual-homed hosts, misconfigured trust relationships, and lateral movement through systems that bridge zones. The point is whether the segmentation holds against an attacker inside the lower-trust side, not whether the rules on paper match the rules in production.

Application-layer penetration testing (11.4.2 and 11.4.3)

Tests of custom and public-facing applications in scope. Application vulnerabilities are often the root cause of the most impactful breaches, and scanner-only testing will fail here.

• Compliance version: A web application scanner (Burp Scanner, Acunetix, Invicti, OWASP ZAP) crawls the application and reports findings. These tools find common injection and misconfiguration issues reliably. They miss or incompletely handle business logic flaws, authentication and authorization chaining, and most insecure direct object reference patterns that depend on application-specific context. These tools also produce an abundance of false positives and false negatives.
• Genuine version: Testers understand the application’s business logic and exercise it the way an attacker would. They chain individual weaknesses into complete attack paths such as a predictable identifier that crosses a privilege boundary, combined with an upload feature that stores malicious content, combined with a conditional authorization failure that lets that content be accessed by a privileged user. Together, flaws that look limited in isolation produce unauthorized access, privilege escalation, or data exposure. These are the attack paths behind consequential breaches, and they do not appear in scanner output.

The Difference Between Compliance and Security

Organizations face a major risk when they conflate compliance and security. Compliance sets a minimum baseline while security protects the confidentiality, integrity, and availability of data. Because threats evolve faster than regulations, effective security always far exceeds compliance requirements.

The 2013 Target breachis a textbook example of this. Target had just been certified as PCI compliant when they suffered their now infamous breach. The final damages reached roughly $300 million across settlements, fines, forensic work, and remediation. Gregg Steinhafel, Target’s former Chairman, President and CEO said “Target was certified as meeting the standard for the payment card industry in September 2013. Nonetheless, we suffered a data breach.”

Compliance-testing vendors are incentivized to deliver clean reports because the attestation is what the client is buying, and serious findings make it harder to sign. In a high-volume, automation-driven compliance model, uncovering a genuine attack path consumes vendor time, complicates the client’s renewal, and disrupts the QSA’s preferred handoff. The result is often a report that keeps every party comfortable. Target held a current attestation from Trustwave when the breach occurred. The report was clean because the testing was compliance-focused scanner-driven work that focused on known vulnerabilities on in-scope systems. The attack path that resulted in the breach was never going to be discovered by that level of penetration testing.

By contrast, a genuine penetration test emulates what real threat actors do. The final report reads like a postmortem of a breach, because that is exactly what it is, but at the hands of a team you hired rather than the bad guys. It tells you how the team operated, what opportunities they leveraged, and how to deploy effective attack disruptors to break each path. We call this contextualized threat intelligence. Without it, your defenses rest on assumptions and guesswork. With it, your defenses are threat-informed and actually work.

Choosing a penetration test with price as the most important factor is a high-stakes gamble that might become the most expensive mistake you make. A genuine penetration testing firm may cost more, but they can justify the cost down to the dollar by explaining the technical workload behind it. That workload is dictated by how your environment is configured, and understanding your environment is a hard prerequisite for any genuine firm. If a vendor cannot explain where every dollar is going, they are almost certainly not delivering a genuine product.

Can AI Replace Human Penetration Testing?

Compliance delivery depends on automation. Over the last two decades, the industry has steadily tried to replace human testers with scanners, and more recently with AI. Neither comes close to human capability. This drive is due to the high-volume low-cost business model we described above. Despite how AI penetration testing services are advertised, machine speed is a problem, not a feature. The noise AI-driven testing generates (true of automation in general) is easily detectable and the opposite of what organizations will experience when targeted by skilled threat actors.

Automation is also plagued by false positives and false negatives. A false positive occurs when a vulnerability is reported that doesn’t actually exist. This wastes valuable time by causing the blue team to go on a wild goose chase when they could be focused on real things that actually matter. False negatives are arguably worse because they are real vulnerabilities that never get detected or reported and are what often lead to damaging data breaches. The issues that led to the Target breach were false negatives.

AI-powered pen testing platforms don’t solve this, and arguably make things worse by adding hallucinations to the mix. Even the frontier models produce false claims about systems, generate convincing sounding false positives, describe complex attack paths that they never actually took, etc. Their false negatives are potentially more dangerous when they incorrectly reason against reporting a finding.

That said, automation is effective at uncovering known classes of vulnerabilities. Bug bounty programs and professional software development both validate this. The value is real, but the marketing conflicts with high volume of findings with high-quality findings. That conflation is misleading and simply not true. Most of what automation uncovers are the types of vulnerabilities that would not be of value to threat actors.

Automation, including AI, is not all bad. A human operator can leverage it to execute specific tasks in parallel while focusing on others. The results feed into the operator’s work; they do not replace it. In a real engagement, the human uses automation as a workforce multiplier gated by expertise. In a compliance engagement, automation does the work and a human only vets the results to produce a report with the appearance of quality. The outputs look very similar, but the depth of testing and security value are not.

A vendor who sells “AI-powered autonomous penetration testing” is selling an advanced automated vulnerability scan. It is dishonest and misleading to suggest that AI powered penetration testing is anything like a genuine human driven test.

How to Choose a PCI Penetration Testing Provider

The hard part is telling them apart. Compliance vendors use the same terminology as genuine firms, which muddies the waters for buyers who are not security experts. The clearest signal is pricing methodology. A genuine firm quotes based on workload and can explain it to you in detail, including what their operators will do, how long each phase will take, and what is driving the cost. A compliance vendor quotes per unit (per IP, per URL, per account) because unit pricing scales with their automation-driven delivery. Ask the question. The answer tells you everything.

Methodology (11.4.1)

In addition, PCI DSS 4.0.1 requires that your vendor document their methodology (requirement 11.4.1). A capable vendor should be able to clearly explain the methodology they use, whether it is an open-source framework like OSSTMM or OWASP, or an internally documented approach. If they claim an open-source methodology, they should be able to answer specific questions about it on the spot. Vague answers mean the methodology is a name on a sales slide, not something that drives the engagement.

Deliverables

There are two types of deliverables depending on the class of service you select.

• Compliance Penetration Testing report: A passing penetration testing report that is the result of minimum baseline testing to satisfy PCI-DSS and produce a passing report.
• Genuine Penetration Testing Report: A genuine penetration testing report that delivers contextualized threat intelligence to help build threat informed defenses that disrupt attacks in their early stages. Satisfying PCI-DSS is a natural byproduct of this report.

The Business Cost of Inadequate PCI Penetration Testing

A breach of a PCI-compliant organization is more expensive than a breach of a non-compliant one. Obtaining an attestation from a compliance-focused vendor amplifies your damages after a breach.

The cost structure of a PCI breach:

• PCI non-compliance fines. Even if you were compliant at breach time, the forensic investigation can trigger non-compliance findings that trigger fines.
• Card brand fines. Visa, Mastercard, Amex, and Discover each levy their own fines separately. These can reach tens of millions for large breaches.
• PFI engagement. Required after a confirmed breach. $500,000 to $5,000,000 depending on scope. Nonnegotiable.
• Mandatory re-assessment. Expect to pay several times the normal rate for your next few QSA assessments.
• Loss of merchant services. If a card brand decides you are a persistent risk, you can lose the ability to process their cards. Business-ending for payment-dependent organizations.
• Class-action exposure. State consumer protection law, federal statute, and common-law negligence all converge on payment card breaches. Target’s class-action exposure alone exceeded $100 million.
• State breach notification penalties. All 50 states have different laws, many of them per-record.
• Reputational damage. Hard to quantify, often the largest long-term cost.

A real engagement that costs $150,000 and prevents a $300,000,000 breach returns 2,000 times its cost. A compliance engagement that costs $50,000 and misses the attack path produces a passing attestation and leaves the exposure intact. The compliance engagement looks cheaper on day one, but it is catastrophically more expensive over the lifetime of the weaknesses it failed to identify.

PCI DSS requires penetration testing because scanning and configuration reviews alone cannot show how an environment holds up against a real attack. Most of the industry sells checkbox engagements that satisfy the letter of Requirement 11.4 while ignoring its intent, because the business model rewards revenue over quality. A smaller segment delivers genuine testing that produces threat intelligence and satisfies the regulation as a natural byproduct.

Choose the engagement that tells you how you would be attacked. Choose the vendor that treats your business as the thing being defended, not as the thing being documented.

If you want a deeper framework for evaluating vendors, our full vendor selection guide, originally featured in Forbes, is available for free here.