What PCI DSS Penetration Testing Requirements Actually Mean for Your Business

Most organizations that process payment card data have heard of Requirement 11.4. Fewer understand what it actually demands. That distinction matters more in 2026 than it did in previous years because PCI DSS v4.0 is now fully enforced, the grace period ended on March 31, 2025, and Qualified Security Assessors are applying the new standard directly. What was acceptable under v3.2.1 is no longer acceptable under v4.0. And the gap between what organizations think their penetration test covers and what the standard actually requires is precisely why Requirement 11 has the highest partial compliance rate of any section in PCI DSS, sitting at 40% across audited organizations.

This is not a gap that exists because organizations don’t care about security. It exists because the difference between a technically sound penetration test and a PCI DSS-compliant penetration test involves specific documentation, scope, methodology, and retesting requirements that most generic tests don’t address. The result is organizations that run security assessments every year, believe they are covered, and then discover during a QSA review that their test doesn’t satisfy the standard.

This guide covers what Requirement 11.4 actually requires, where organizations most consistently fall short, and what a compliant test looks like in practice.

Key Takeaways

• PCI DSS v4.0 Requirement 11.4 mandates annual internal and external penetration testing of the entire cardholder data environment, with a documented methodology, CVSS-rated findings, and verified remediation through retesting.
• Requirement 11 shows the highest partial compliance rate of any PCI DSS section at 40%, making it the most commonly failed control category in audits.
• Service providers must test segmentation controls every six months under Requirement 11.4.6, not annually like standard merchants.
• Non-compliance fines start at $5,000 to $10,000 per month and escalate to $100,000 per month after six months, with additional per-record costs of $50 to $90 following a breach.
• A passing vulnerability scan does not replace a penetration test. Both are required under separate sub-requirements and serve different purposes under the standard.

What Does PCI DSS Requirement 11.4 Actually Say?

PCI DSS v4.0 Requirement 11.4 states that external and internal penetration testing must be regularly performed and that exploitable vulnerabilities and security weaknesses must be corrected. That top-level statement operationalizes into seven distinct sub-requirements, each one checked individually by a Qualified Security Assessor during your audit.

Understanding the sub-requirements matters because organizations frequently satisfy some and miss others without realizing it. Passing 11.4.2 and 11.4.3 by running internal and external tests is not the same as passing 11.4. A QSA checks each sub-requirement against separate evidence artifacts. Missing any one of them is a finding.

Sub-Requirement	What It Requires	Frequency
11.4.1	Documented penetration testing methodology	Ongoing, maintained
11.4.2	Internal penetration testing	Annually + after significant changes
11.4.3	External penetration testing	Annually + after significant changes
11.4.4	Remediation of findings and retesting to confirm	After each finding
11.4.5	Segmentation control testing (all entities)	Annually
11.4.6	Segmentation control testing (service providers)	Every 6 months
11.4.7	Multi-tenant SPs support customers for external testing	As requested

The requirement moved from 11.3 in PCI DSS v3.2.1 to 11.4 in v4.x. If your team or your penetration test reports still reference 11.3, that is a direct signal that your testing program has not been updated to the current standard. QSAs will identify this immediately.

What Is the Scope of a PCI DSS Penetration Test?

The cardholder data environment defines the primary scope boundary, covering all systems that store, process, or transmit cardholder data, plus any connected systems that could be used to reach those environments. Scoping the CDE accurately is the single most consequential decision in a PCI DSS penetration test. Underscoping can invalidate the entire assessment.

What that means in practice is that scope is almost always larger than it appears on paper. A single payment application connects to card networks, banking partners, fraud detection services, identity verification providers, mobile SDKs, and internal tooling with access to cardholder records. Each of those connections is potentially in scope. And in a typical engagement, connected systems like internal admin dashboards, support ticketing tools, or API gateways are routinely missed in scope documentation because they don’t directly store card data, even though a lateral movement path from them to the CDE is demonstrably exploitable.

The application-layer testing scope is where the most significant gaps appear. Requirement 11.4.1 mandates coverage of the vulnerabilities listed in Requirement 6.2.4, which maps closely to the OWASP Top 10 and includes injection flaws, broken authentication, cross-site scripting, insecure direct object references, and business logic weaknesses. A test that focuses on network-layer testing and treats application-layer coverage as secondary will fail this sub-requirement. For organizations with custom payment applications, e-commerce platforms, or patient portals built on top of payment systems, the tester needs genuine application security expertise, not just infrastructure skills.

At Bugstrix, we’ve seen scoping errors in over 60% of payment environment assessments, most of them in a consistent direction: organizations scope the CDE to the payment application itself and stop there, without mapping the systems that can reach that application through trust relationships and API calls.

What Does “Qualified Tester” Mean Under PCI DSS v4.0?

PCI DSS v4.0 requires penetration testing to be performed by a qualified internal resource or a qualified external third party with organizational independence from the systems being tested. The standard does not mandate specific certifications, but QSAs consistently evaluate tester qualifications as a proxy for test quality, and a tester who cannot demonstrate hands-on experience with methodology-driven assessment will raise questions during the audit review.

Organizational independence means the tester cannot be responsible for managing or maintaining the environment they are testing. An internal security engineer who owns the firewall rules cannot be the person testing whether those firewall rules can be bypassed. For most organizations, this means either engaging an external provider or maintaining a clearly separated internal security team with no operational ownership of the CDE. For Level 1 merchants and large service providers, external testing from an established provider removes any ambiguity about independence that a QSA might otherwise explore.

Industry credentials that QSAs recognize as markers of competence include OSCP, CREST CRT/CCT, GPEN, and GXPN. But certification alone is not what the standard looks for. The PCI Council has been explicit that penetration testing requires human analysis, creative exploitation, and scenario-based testing that automated tools cannot replicate. A tester who runs a scanner and wraps the output in a methodology template does not satisfy the qualified tester requirement, regardless of what certifications are listed on the report cover page.

For web application penetration testing within a PCI DSS scope, that expertise requirement is particularly important given that Requirement 6.2.4 mandates specific application-layer vulnerability coverage that only a tester with real application security experience can adequately address.

What Is the Difference Between a Vulnerability Scan and a Penetration Test Under PCI DSS?

PCI DSS requires both activities, and they are governed by separate requirements, run on different cadences, use different methodologies, and produce different evidence artifacts. A passing scan does not replace a penetration test, and a penetration test does not replace quarterly scans. Organizations that submit scan results as evidence of Requirement 11.4 compliance are making one of the most common and most consequential mistakes in PCI audit preparation.

Vulnerability scanning is governed by Requirement 11.3. It requires quarterly external scans by an Approved Scanning Vendor and additional scans following significant changes. Scanning is automated, broad, and focused on identifying known CVEs and common misconfigurations against a catalog of known weaknesses. A clean scan result means your environment doesn’t have known, unpatched vulnerabilities that a scanner can detect.

Penetration testing is governed by Requirement 11.4. It is manual, adversarial, and focused on testing whether a skilled attacker can actually exploit what is present in your environment, chain weaknesses together into meaningful attack paths, and reach cardholder data through combinations of vulnerabilities that no single scan would surface. A penetration tester goes beyond identifying what is present and tests what is actually reachable and exploitable given your specific environment, architecture, and business logic.

The distinction matters practically because a payment environment can pass all its quarterly scans and still have critical exploitable vulnerabilities in its API authorization logic, its payment flow business logic, or its segmentation controls. Those vulnerabilities don’t appear in scanner output because they require a human to recognize and test them. They appear in penetration tests. And they are exactly what QSAs expect a compliant Requirement 11.4 test to cover.

What Are the Most Common PCI DSS Penetration Testing Failures?

The highest partial compliance rate of any PCI DSS requirement section belongs to Requirement 11, at 40% across audited organizations. That number reflects a consistent pattern of how organizations approach penetration testing relative to what the standard actually requires. The failures are not random. They cluster around the same gaps across organizations of different sizes and industries.

Scope defined too narrowly. The most common failure is scoping the cardholder data environment to the payment application itself, without mapping the connected systems that can reach it. A QSA checks scope documentation directly and will identify systems that should have been included. A test that didn’t cover the full CDE doesn’t satisfy Requirement 11.4.2 or 11.4.3, regardless of how thorough the testing was within the defined scope.

Network-only testing without application-layer coverage. Requirement 11.4.1 mandates application-layer coverage of the vulnerabilities listed in Requirement 6.2.4. Organizations that run strong network and infrastructure tests but treat application-layer testing as optional are leaving 11.4.1 partially unmet. QSAs who review the methodology against the reported findings will identify the gap.

No documented methodology. The tester conducted a thorough assessment, but the methodology was not formally documented in writing against an accepted standard such as NIST SP 800-115, OWASP, or PTES. A verbal description of the approach or a brief paragraph in the report introduction does not satisfy 11.4.1. The methodology must be defined, documented, and implemented as a standing written document.

Missing retest evidence. Findings were remediated, but retesting wasn’t performed and documented. Requirement 11.4.4 requires verification that corrections actually fixed the identified vulnerabilities. A statement in the report that remediation was completed is not sufficient. QSAs expect to see remediation tickets, retest results, and tester sign-off as separate evidence artifacts.

Segmentation not validated. Organizations that use network segmentation to reduce their PCI scope must test that those segmentation controls actually hold under adversarial conditions. Skipping segmentation testing under the assumption that the network diagrams reflect reality is treated as a scope deficiency, not a minor procedural omission.

How Does Bugstrix Structure PCI DSS Penetration Testing Engagements?

The consistent finding across Bugstrix’s 700+ security engagements is that organizations fail PCI audits not because their security posture is weak, but because their testing documentation doesn’t match what the standard requires. The test was conducted. The findings were fixed. But the methodology wasn’t written down correctly, the scope excluded systems that should have been included, or the retest evidence wasn’t packaged in a way a QSA could evaluate directly. A technically strong assessment that fails on documentation grounds produces the same audit outcome as no test at all.

Our PCI DSS penetration testing engagements are structured around what a QSA will check, not what looks thorough in a report.

Scope definition before testing starts. Every engagement begins with a scope definition session that maps the CDE boundary accurately, identifies connected systems that may not store card data but can reach it, and confirms which segmentation controls will need validation. Scope mismatches caught before testing starts are not findings. Scope mismatches identified by a QSA after testing closes are.

Dual-layer testing on every engagement. Network-layer and application-layer testing are not optional add-ons. Every engagement covers both because Requirement 11.4.1 mandates it. For organizations with mobile payment applications, we include mobile testing covering the full OWASP Mobile Top 10 alongside payment flow-specific scenarios.

CVSS-scored findings with exploitation evidence. Every finding is scored using CVSS, documented with evidence of successful exploitation, and mapped to the specific PCI requirement it affects. This gives the QSA a direct line between test findings and compliance controls without requiring interpretation.

Retest included as standard. We include one retest cycle in every engagement to verify that critical and high-severity findings were successfully remediated. The retest report is structured as a standalone evidence artifact for QSA review, not appended as a comment to the original finding.

QSA-ready report from the first draft. Reports are structured with the QSA’s evidence checklist in mind: methodology statement, scope definition, tester credentials, testing period, exploitation results, remediation guidance, and retest results in a format an assessor can evaluate directly. Security teams shouldn’t need to translate a technical findings report into compliance evidence after the fact.

Schedule at least three months before your PCI assessment date. That timeline allows the test to close, critical findings to be remediated, retesting to be completed, and the full documentation package to be assembled before the QSA window opens. Organizations that book a test in the month before their audit consistently run into remediation timeline problems that could have been avoided with earlier scheduling.

View our penetration testing services to get a free quote for your PCI DSS environment.

What Are the Financial Consequences of PCI DSS Non-Compliance?

Non-compliance fines are imposed by acquiring banks and escalate monthly rather than arriving as a single penalty. The escalation structure creates a compounding financial exposure that grows the longer issues remain significantly unaddressed, independent of whether a breach has occurred.

Period of Non-Compliance	Monthly Fine Range
First 3 months	$5,000 to $10,000 per month
Months 4 to 6	$25,000 to $50,000 per month
Beyond 6 months	Up to $100,000 per month

The fines above apply before a breach. If a breach occurs in a non-compliant environment, additional per-record costs of $50 to $90 per affected cardholder apply, alongside forensic investigation costs, mandatory customer notification, and the potential for legal action from affected cardholders. The average breach cost in the financial services sector reaches $5.97 million when all of those elements are aggregated (Clone Systems, 2026). Losing the ability to process credit card payments, the most severe consequence available to acquiring banks, can be activated for persistent non-compliance and represents an existential risk for any business whose revenue depends on accepting card transactions.

The cost calculation is straightforward. A PCI-compliant penetration test costs a fraction of a single month’s escalated fine, before breach remediation, forensic investigation, and notification costs are factored in. Non-compliance is not a lower-cost path.

Get a free quote for a PCI DSS-compliant penetration test scoped to your environment.

Frequently Asked Questions

Does PCI DSS explicitly require penetration testing?

Yes, and unlike SOC 2 or HIPAA, which imply testing through outcome-based language, PCI DSS names it outright. Requirement 11.4 is a prescriptive control that a QSA checks directly against specific evidence. All v4.x requirements became mandatory on March 31, 2025. If your last test followed the v3.2.1 Requirement 11.3 format, your program is not current, and a QSA will identify that during the assessment.

How often does PCI DSS require a penetration test?

At minimum, annually for both internal and external testing under Requirements 11.4.2 and 11.4.3, plus an additional test after any significant infrastructure or application change. Service providers must also test segmentation controls every six months under Requirement 11.4.6. The post-change trigger operates independently of the annual calendar. A major release or new integration in month three of your annual cycle requires a test before the next scheduled date.

Can an internal security team perform PCI DSS penetration testing?

Yes, provided the tester has organizational independence and demonstrated competence. The tester cannot be responsible for managing the environment being tested. For most organizations, this means an external provider or a clearly separated internal security team with no operational ownership of any CDE system. For Level 1 merchants and service providers, external testing removes any ambiguity about independence that a QSA might otherwise pursue during the assessment.

What must a PCI DSS penetration test report include?

The report must include a written methodology statement referencing an accepted standard, the complete scope definition matching the compliance boundary, tester credentials and organizational independence statement, findings with CVSS scores and exploitation evidence, remediation guidance for each finding, and retest results confirming critical issues were fixed. Reports structured for security teams rather than auditors frequently require rework before they satisfy QSA evidence requirements.

What is segmentation testing and when is it required?

Segmentation testing validates that network controls isolating the CDE from other networks actually hold under adversarial conditions and cannot be bypassed. Required annually for all entities using segmentation under Requirement 11.4.5 and every six months for service providers under 11.4.6. Segmentation only reduces PCI scope if the controls are tested and verified. A network diagram showing segmentation is not the same as a test confirming it works.

A Compliant Test and a Good Test Are Not Always the Same Thing

PCI DSS Requirement 11.4 defines a minimum standard. It specifies the methodology must be documented, the scope must cover the CDE, the tester must be qualified and independent, findings must be CVSS-rated, and remediation must be verified through retesting. An organization that meets all of those requirements has satisfied the standard. Whether they’ve identified the most meaningful risks in their environment is a separate question.

The organizations that get the most value from PCI DSS penetration testing are the ones that treat the compliance requirements as a floor rather than a ceiling. The scope requirements point to the right systems to test. The methodology requirements point to the right techniques to use. The cadence requirements reflect a minimum based on what the standard’s authors believed was reasonable, not a cadence based on how fast your environment actually changes.

For most organizations handling payment card data in 2026, that means testing after significant changes even when the annual test date isn’t approaching, validating third-party integrations as part of scope rather than excluding them, and treating the retest cycle as a genuine verification step rather than an administrative formality. That approach produces better security outcomes, cleaner audit evidence, and fewer QSA surprises than the alternative.

Contact us to discuss your PCI DSS penetration testing requirements, or get a free quote and receive a response within 24 hours.