PCI DSS 4.0 Penetration Testing Requirements in 2026: What You Need to Know

PCI DSS 4.0 raised the bar on penetration testing. If your security program still runs one annual test and calls it done, you have a gap, and your next QSA review will likely surface it.

This post covers what PCI DSS 4.0 expects from penetration testing in 2026, where most programs fall short, and how penetration testing as a service (PTaaS) closes the gap without doubling headcount or budget.

What PCI DSS 4.0 Actually Requires for Penetration Testing

The tightened requirements sit under Requirement 11.4. At a general level, here is what the standard expects. Exact sub-clause numbers and wording should be confirmed against the current official PCI DSS 4.0.1 document, since PCI SSC periodically issues clarifications.

A documented penetration testing methodology must exist. It should cover the full cardholder data environment (CDE), include both network-layer and application-layer testing, and align with an industry-accepted approach such as NIST SP 800-115 or PTES.

External and internal penetration testing must occur at least annually. Testing must also run after any significant infrastructure or application change. “Significant change” is defined broadly, which means fast-moving dev teams can trigger retesting obligations multiple times a year.

Exploitable vulnerabilities found during testing must be corrected, and retesting must confirm the fix. You cannot close a finding in a spreadsheet and move on. A QSA will look for evidence that the exploit no longer works.

Where segmentation controls isolate the CDE, testing must validate that segmentation is effective. This runs on a defined periodic cadence, commonly cited as at least every six months, and after any change to those controls. Service providers face this cadence as well.

Multi-tenant service providers must support their customers’ penetration testing. This one catches SaaS companies off guard.

The shift from PCI DSS 3.2.1 to 4.0 is not subtle. Annual testing is now the floor, not the ceiling. Remediation must be verified. Segmentation validation runs on a recurring cycle. Every requirement expects documented evidence, not a PDF report sitting in a shared drive.

Where Most PCI Programs Break Down

Annual testing does not match the actual change cadence

Your development team ships code weekly. Your cloud infrastructure changes constantly. PCI 4.0 requires retesting after significant changes, but most teams have no practical way to trigger a pentest in under two weeks. By the time a manual engagement starts, the environment has already moved on.

DAST scanners do not satisfy the requirement

A surprising number of security teams try to satisfy Requirement 11.4 with a DAST scanner. QSAs increasingly push back on this. DAST produces a list of potential findings, not validated exploits. PCI 4.0 expects evidence that vulnerabilities are exploitable and that remediations actually work. A scanner alert is not proof of exploit.

DAST tools also carry false positive rates between 40 and 70 percent. When your team spends two weeks triaging scanner noise, they are not doing the work that satisfies the standard.

Segmentation validation is manual and expensive

Testing segmentation controls on a recurring cadence requires scoping, scheduling, and executing a targeted engagement. For service providers, that repeats every year, with documentation each time. Most teams either skip it, do it superficially, or pay consulting rates that make the CFO uncomfortable.

Remediation evidence is weak

PCI 4.0 is explicit: you must retest after fixing a finding. Manual pentest firms typically charge for retest engagements separately, and turnaround is slow. Teams end up with findings marked “fixed” based on developer confirmation rather than verified exploit failure.

How Penetration Testing as a Service Addresses These Requirements

PTaaS replaces the annual engagement model with continuous, on-demand testing that produces audit-ready evidence. The differences matter directly for PCI programs.

Testing runs on your schedule, not a vendor’s calendar

With PTaaS, you trigger a test when a significant change happens. No lead time, no two-week scheduling window. The test runs, findings come back with working proof-of-concept exploits, and your team can fix and retest in the same week. That is the cadence PCI 4.0 actually expects.

Every finding ships with a working exploit

PCI 4.0 expects you to demonstrate that vulnerabilities are exploitable and that remediations work. A PTaaS platform that delivers a working proof-of-concept with every finding gives you the kind of evidence a QSA looks for. The finding is not a theoretical risk. It is a demonstrated exploit with steps to reproduce.

Remediation retesting is built in

Continuous testing means you can retest right after a fix is deployed, without scheduling a separate engagement or paying an additional fee. The audit trail shows the original finding, the fix date, and the confirmed remediation, all in one place.

Segmentation testing runs on a defined cadence

A PTaaS platform can run segmentation validation on a recurring schedule instead of a one-off annual scramble. For service providers facing a tighter cadence, this reduces the operational burden of manually tracking and scheduling those engagements. Whether a specific cadence satisfies your QSA’s expectations is a scoping conversation with your assessor, not something a platform certifies on its own.

The audit trail is continuous, not point-in-time

QSAs want to see that your security posture is maintained over time, not just validated once a year. Full logging of every test, every finding, and every remediation gives you a continuous evidence record that a single annual report cannot match.

What to Look for in a PTaaS Platform for PCI Compliance

Not every PTaaS offering is built to support PCI 4.0 evidence requirements. Here is what actually matters:

Application-layer coverage. PCI 4.0 explicitly expects application-layer testing. A platform that only covers network infrastructure will leave gaps your QSA will find.

Authenticated testing. Business logic flaws and access control vulnerabilities, common in payment applications, only surface under authenticated conditions. Unauthenticated-only scans miss the attacks that matter most in a cardholder data environment.

Working proof-of-concept exploits. Every finding should be exploitable, not theoretical. The platform should deliver a working exploit, not just a CVSS score and a description.

Remediation verification. The platform should confirm that a fix works, not just accept a developer’s word for it. Retesting should be fast and documented.

Full audit trail. Every test, every agent action, every finding, and every remediation needs to be logged with timestamps. QSAs will ask for this.

Scope controls. You need to define exactly what is in scope for the CDE and what is not. Configurable scope guardrails prevent tests from running outside the defined environment, which matters for both compliance and operational safety.

Shadow asset discovery. PCI 4.0 expects you to test your actual attack surface. Forgotten subdomains, shadow apps, and API endpoints you did not know existed are still in scope if they touch the CDE. A platform that discovers these assets from your org name alone closes a blind spot that manual scoping consistently misses.

FireCompass and PCI DSS 4.0

To be direct: FireCompass is not a QSA and does not certify PCI compliance. That determination belongs to your Qualified Security Assessor. What FireCompass does is make continuous, exploit-validated web app and API pentesting practical, which is the operational gap most PCI 4.0 programs actually have.

FireCompass is an agentic AI platform for web app and API penetration testing and continuous red teaming. It discovers your real external attack surface from just an org name, including shadow apps, forgotten subdomains, leaked credentials, and API endpoints. It runs authenticated and unauthenticated testing aligned to OWASP Top 10 2025 and delivers a working proof-of-concept exploit with every finding, with steps to reproduce. It also chains findings into multi-stage attack paths, including app-to-network lateral movement, mapped to MITRE ATT&CK.

Testing runs weekly, on-demand, or triggered by a new deployment. No lead time. Every agent action is logged with a full audit trail. Scope guardrails are configurable so testing stays inside the CDE you define. The false positive rate is under 2 percent, compared to 40 to 70 percent for typical DAST tools.

In a Fortune 500 proof-of-value engagement, per-app testing cost dropped from about $5,000 to under $1,000. In internal evaluation, FireCompass agents beat top human researchers 60 to 70 percent of the time while staying under 2 percent false positives.

For PCI programs specifically: every finding ships with a working exploit and steps to reproduce, retesting can happen in the same week as the fix, and the audit trail gives your QSA continuous evidence instead of a single point-in-time report. Because discovery runs automatically, you are testing the attack surface an attacker would actually find, not a stale asset list assembled six months ago.

Map your real attack surface at firecompass.com/explorer. No asset list required.

The Cost of Getting This Wrong

A failed PCI review is not just a compliance problem. It is a business problem. Acquiring banks and card brands can levy non-compliance fees commonly cited in the range of $5,000 to $100,000 per month, depending on the card brand, transaction volume, and severity of the gap. A breach in a non-compliant environment shifts liability more directly onto you.

More practically: if your annual pentest missed an exploitable vulnerability in a payment application, and that vulnerability was used in a breach, the question your QSA and your legal team will ask is why you were only testing once a year.

PCI 4.0 gives you a framework to answer that question with evidence. PTaaS gives you the operational model to actually produce it.

Frequently Asked Questions

What is the minimum penetration testing frequency required under PCI DSS 4.0?

PCI DSS 4.0 Requirement 11.4 expects external and internal penetration testing at least annually, plus retesting after any significant infrastructure or application change. Segmentation validation runs on a recurring cadence, commonly cited as at least every six months, with the same expectation called out for service providers. Confirm exact clause language against the current official PCI DSS 4.0.1 document or your QSA.

Does a DAST scanner satisfy PCI DSS 4.0 penetration testing requirements?

No. DAST scanners produce potential findings, not validated exploits. PCI 4.0 expects you to demonstrate that vulnerabilities are exploitable and that remediations work. QSAs increasingly distinguish between automated scanning and actual penetration testing. A scanner alert does not satisfy the requirement on its own.

What evidence does a QSA need to see for penetration testing compliance?

QSAs typically want a documented methodology, scope definition, test results with exploitable findings, evidence of remediation, and retest results confirming the fix worked. A continuous audit trail from a PTaaS platform is stronger evidence than a single annual PDF report.

What is penetration testing as a service (PTaaS)?

PTaaS replaces the traditional model of scheduling a manual engagement every 12 months with continuous, on-demand testing delivered through a platform. Testing runs on a defined cadence or triggers after changes. Findings come with working exploits and remediation evidence. The audit trail is continuous, not point-in-time.

How does PTaaS handle the “significant change” retesting expectation in PCI 4.0?

A PTaaS platform can trigger testing automatically when a new deployment or infrastructure change is detected, or you can launch a test on-demand with no lead time. This makes it practical to address the significant-change retesting expectation without scheduling a new manual engagement every time your team ships code.

What is segmentation testing under PCI DSS 4.0, and how often is it required?

Segmentation testing validates that your controls actually isolate the cardholder data environment from the rest of your network. Under PCI 4.0, this runs on a recurring cadence, commonly cited as at least every six months, and after any change to segmentation controls. Confirm the exact cadence and clause number against the official standard or your QSA, since requirements can vary by entity type.

Can PTaaS cover both application-layer and network-layer testing for PCI?

It depends on the platform. PCI 4.0 expects both. Some PTaaS platforms cover only web applications. A platform that covers web, API, and network in a single engagement, with app-to-network lateral movement testing, addresses both layers and gives you evidence of how a real attacker would chain findings across your environment.

GARTNER is a registered trademark and service mark of Gartner, Inc. and/or its affiliates in the U.S. and internationally and are used herein with permission. All rights reserved. Gartner does not endorse any vendor, product or service depicted in its research publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner research publications consist of the opinions of Gartner’s research organization and should not be construed as statements of fact. Gartner disclaims all warranties, express or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose.

PCI DSS 4.0 does not reward annual testing anymore. It rewards continuous, verified, evidence-backed security. PTaaS is the operational model that makes that achievable without a team of ten offensive security engineers. The standard is already in effect. The question is whether your testing program can prove it.