PCI DSS v4.0 Penetration Testing Requirements

PCI DSS Penetration Testing Requirements: The Direct Answer

PCI DSS v4.0 Requirement 11.4 mandates that every entity in scope for PCI DSS — merchants, service providers, and their technology vendors — must conduct penetration testing at least annually and after any significant infrastructure or application change. The test must cover both external and internal attack surfaces, follow an industry-accepted methodology, be performed by a qualified tester who is organizationally independent from the environment being tested, and produce documented evidence that your QSA (Qualified Security Assessor) can review.

Findings rated as high-risk or critical must be remediated and retested before you can claim compliance. If you process, store, or transmit cardholder data and you are not doing all of the above, you are out of compliance — regardless of whether any other control is in place.

Why Penetration Testing Is Central to PCI DSS

PCI DSS distinguishes between vulnerability scanning (automated, required quarterly) and penetration testing (human-driven, required annually). Vulnerability scans identify known weaknesses against a signature database. Penetration tests go further: a skilled tester chains together vulnerabilities, misconfigurations, and business logic flaws to demonstrate actual exploitability — specifically, whether an attacker could reach cardholder data (CHD) or the cardholder data environment (CDE). A rigorous web application penetration test following OWASP methodology is typically the foundation of PCI DSS application-layer testing.

The Council's rationale is straightforward: an attacker does not care about your patch cadence in isolation; they care about whether they can pivot from a compromised system to your card data. Only a real penetration test answers that question.

Requirement 11.4 in Detail

11.4.1 — Documented Methodology

Requirement 11.4.1 requires the entity to define, document, and use an industry-accepted penetration testing methodology (see the methodology table below) that is available for QSA review before any test begins.

11.4.3 — External Penetration Test

An external penetration test must:

Target all external-facing components of the CDE and systems that could affect the security of the CDE (perimeter firewalls, web application servers, API gateways, DNS, email gateways, VPN endpoints).
Be performed at least once every 12 months.
Be repeated after any significant change to the external attack surface — a new public-facing service, a network architecture change, a major software upgrade.
Follow the industry-accepted penetration testing methodology documented under 11.4.1.
Be conducted by a qualified internal resource or a qualified external penetration testing company.

11.4.2 — Internal Penetration Test

The internal test mirrors the external test but from inside the network perimeter:

Targets all internal components in scope: servers in the CDE, internal-facing applications, segmentation controls, internal network paths that touch CHD.
Same annual cadence and post-significant-change trigger.
Must test whether an internal attacker (or a compromised insider account) can reach cardholder data.
Must include testing of segmentation controls to validate they actually prevent access between out-of-scope networks and the CDE.

11.4.5 / 11.4.6 — Segmentation Testing

Segmentation is one of the most important PCI DSS cost-reduction levers: if you can provably isolate your CDE from the rest of your network, you reduce the scope of every other PCI DSS requirement. But segmentation claims must be validated.

Requirements 11.4.5 and 11.4.6 mandate:

Annual segmentation testing (11.4.5) to confirm that out-of-scope systems cannot communicate with in-scope CDE systems.
Every six months for service providers (11.4.6) — more frequent because service providers handle multiple customers' data.
Coverage of all segmentation methods — firewall rules, VLANs, network access control, micro-segmentation.
Documentation of the test approach, systems tested, and results.

A segmentation test failure is a scope expansion event: every system that can reach the CDE must now be treated as in-scope.

11.4.4 — Retesting After Remediation

This sub-requirement closes a gap that many organizations miss. When the penetration test identifies vulnerabilities:

High-risk and critical findings must be remediated.
A retest must be performed to confirm that the remediation is effective.
The retest results must be documented.
The QSA needs evidence of both the original finding and the confirmed remediation.

Simply patching a system and closing a ticket in your issue tracker is not sufficient. You need a tester to confirm that the vulnerability no longer exists or can no longer be exploited in the way originally demonstrated.

Who Qualifies as a Penetration Tester?

PCI DSS v4.0 does not mandate a specific certification, but it does mandate organizational independence and demonstrable competency. The standard allows two paths:

Internal tester — an employee or contractor who:

Is independent from the systems and teams responsible for managing the CDE (cannot test their own work).
Has verifiable penetration testing skills (certifications such as OSCP, CEH, GPEN, or equivalent documented experience are accepted as evidence of competency).
Is not managed by the team responsible for security of the CDE.

External qualified company — a specialized firm that:

Has no financial or operational conflict of interest with your organization.
Can demonstrate tester credentials and methodology.
Provides a formal, signed penetration test report.

For most organizations, using an external firm is the cleaner path: the independence requirement is easier to satisfy, the methodology documentation is the firm's standard deliverable, and the QSA has a third-party report to review rather than an internal document. Network penetration testing addresses the internal and segmentation test requirements under Requirement 11.4 that many organizations underscope.

Accepted Penetration Testing Methodologies

PCI DSS v4.0 requires an industry-accepted methodology. The following are explicitly recognized or widely accepted by QSAs:

Methodology	Scope	Notes
NIST SP 800-115	Technical penetration testing	US government standard; thorough documentation requirements
PTES (Penetration Testing Execution Standard)	Full lifecycle	Covers scoping through reporting; widely used by commercial firms
OWASP Testing Guide	Web applications	Required when web apps process card data
OSSTMM	Network and infrastructure	Metrics-driven; good for segmentation testing evidence

Your report must reference the methodology used. A report that describes ad-hoc testing with no methodology reference will raise a flag with your QSA.

Scoping Considerations

Getting scope wrong is the most expensive penetration testing mistake in PCI DSS. Scope is defined by your CDE and all systems that:

Store, process, or transmit CHD or sensitive authentication data (SAD).
Can affect the security of the CDE (connected systems, management interfaces, authentication systems, logging systems that capture CHD).
Provide security controls for the CDE (firewalls, IDS/IPS, WAF, HSMs).

Systems that are NOT segmented from the CDE are in scope by default, even if they never touch card data directly.

Before your penetration test begins, document your scope in writing and have it reviewed. If your scoping is challenged by a QSA after testing, you may need to retest a larger scope — at significant additional cost.

Documentation Your QSA Will Need

Build your evidence package as you go. For each penetration test cycle, your QSA will typically expect:

Scope document — written agreement on what is in scope, signed by a responsible owner.
Penetration test report — including executive summary, methodology, scope, findings (with risk ratings), proof of exploitation, remediation recommendations.
Retest report — for every high/critical finding, evidence that the finding was retested and confirmed remediated.
Tester qualifications — CV or credentials of the tester(s), or firm profile of the external company.
Segmentation test results — separate documentation of segmentation validation, distinct from the main pentest report.
Change evidence — if the test was triggered by a significant change, documentation of what changed and when.

Retain all evidence for at least 12 months (one full PCI DSS assessment cycle). Many QSAs recommend retaining three years.

PCI DSS Requirement 11.4 Compliance Checklist

Use this checklist before your QSA assessment:

Requirement → Need → Common Mistake

Requirement	What's Required	Common Mistake
11.4.3 External pentest	Annual + after significant changes; industry methodology	Testing only the web app and missing network perimeter, API endpoints, or VPN
11.4.2 Internal pentest	Annual + after significant changes; internal attacker perspective	Scoping too narrowly — missing management interfaces, jump hosts, AD/LDAP systems
11.4.5/11.4.6 Segmentation testing	Annual (6-month for service providers); validate CDE isolation	Treating VLAN separation as sufficient without testing; no documentation of what was tested
11.4.4 Retesting	Retest all high/critical findings after remediation	Closing findings in a tracker without a formal retest; no documented retest report
Qualified tester	Independence + demonstrable competency	Internal IT staff testing systems they manage; no tester credentials on file
Methodology	Industry-accepted (NIST, PTES, OWASP, OSSTMM)	Proprietary or undocumented approach; QSA cannot validate coverage
Scope	CDE + connected systems + security controls	Under-scoping — excluding connected systems that are not segmented
Evidence retention	12 months minimum; accessible to QSA	Reports stored locally, lost during staff turnover, or not produced in a reviewable format

Common Compliance Failures

Wrong scope. Organizations frequently exclude systems they consider "not cardholder data systems" without validating that those systems are actually isolated. A jump server used to administer CDE hosts is in scope. An Active Directory used for authentication in the CDE is in scope. A logging server that aggregates CDE logs is in scope.

No post-remediation retest. The most common gap in mature programs. Teams remediate findings and close tickets but never have a tester confirm the fix works. Requirement 11.4.4 is explicit: the retest must happen and must be documented.

Inadequate methodology. Reports that describe a tool output rather than a tested attack path do not satisfy PCI DSS. A Nessus scan is not a penetration test. The report must show that a tester actively attempted exploitation.

Timing gaps. Running a penetration test in January and then deploying a new payment page in August without testing the new surface leaves a compliance gap. Every significant change is a trigger — track your changes and map them to your testing calendar.

Tester independence failures. An internal network engineer who also runs the penetration test on the firewall rules they configured is not independent. Document your independence position clearly before testing begins.

Frequently Asked Questions

Who qualifies as a penetration tester under PCI DSS v4.0?

PCI DSS v4.0 requires organizational independence and demonstrable competency — not a specific certification. An internal tester must be independent from the teams managing the CDE and hold verifiable skills (OSCP, GPEN, CEH, or equivalent). An external firm must have no financial conflict of interest and provide documented tester credentials. Most organizations use external firms because the independence requirement is simpler to satisfy and the methodology documentation is a standard deliverable.

What is the difference between Requirement 11.4.2/11.4.3 and Requirement 11.4.5/11.4.6?

Requirements 11.4.2 and 11.4.3 mandate annual internal and external penetration tests of the CDE and all systems that could affect its security. Requirements 11.4.5 and 11.4.6 specifically mandate segmentation testing — validating that out-of-scope networks are actually isolated from the CDE. Segmentation testing is annual for merchants (11.4.5) and every six months for service providers (11.4.6). A failed segmentation test is a scope expansion event: every system that can reach the CDE becomes in-scope.

How often must PCI DSS penetration testing be performed?

At minimum annually for all three components: external pentest, internal pentest, and segmentation testing — with segmentation testing every six months for service providers. Testing must also occur after any significant change to the CDE or external attack surface: new public-facing services, network architecture changes, or major software upgrades each trigger an additional test regardless of the annual cycle.

What documentation does a QSA need for PCI DSS Requirement 11.4?

A QSA typically requires: a signed scope document, a penetration test report with executive summary and methodology, a retest report confirming remediation of all high and critical findings, tester qualifications (certifications or firm profile), a standalone segmentation test report, and change documentation if the test was triggered by a significant infrastructure change. All evidence must be retained and accessible for at least 12 months.

What happens if critical findings are identified during a PCI DSS penetration test?

Critical and high-risk findings must be remediated before compliance can be claimed under Requirement 11.4.4. A formal retest must confirm that each remediation is effective — closing a ticket in an issue tracker is not sufficient. The retest results must be documented and available for QSA review. Failure to formally retest critical findings is one of the most common gaps QSAs identify even in otherwise mature PCI DSS programs.

Choosing a Provider for PCI DSS Requirement 11.4

If your annual test window is approaching, if you have had a significant infrastructure change, or if your last assessment surfaced findings that were never formally retested, now is the time to act. A gap in your penetration testing evidence can block your QSA assessment and delay your Report on Compliance (ROC) or Self-Assessment Questionnaire (SAQ) submission.

Look for a provider experienced in PCI DSS scoped assessments that delivers QSA-ready documentation covering all of Requirement 11.4 — external and internal penetration testing, segmentation validation, post-remediation retesting, and a final evidence package formatted for your QSA's review. Testers should hold recognized certifications (OSCP, CISSP, CEH, Pentest+) and operate under a documented methodology referencing PTES, NIST SP 800-115, and OWASP, so the QSA has a clear audit trail from scope agreement through remediation confirmation. Among the providers that structure engagements to this standard, WhiteJaguars — a Costa Rica-based pentesting firm — works with merchants, payment processors, and service providers, and includes a pre-engagement scoping workshop, a standalone segmentation test report, retest confirmation for all high and critical findings, and an evidence package summary mapped to specific PCI DSS requirements.

PCI DSS Penetration Testing Requirements Explained