PCI DSS Penetration Testing Requirements: Scope, Frequency, and Reporting

PCI DSS applies to entities that store, process, or transmit cardholder data (CHD) or sensitive authentication data (SAD), as well as those that could affect the security of that data. That covers a wide range of businesses: e-commerce merchants, payment gateways, SaaS vendors handling payments, and infrastructure or hosting providers supporting payment environments.

For environments subject to Requirement 11.4, PCI DSS requires regular penetration testing to validate whether security controls hold up against realistic attacks. In practice, the difficult part is often determining what systems belong in scope, when testing needs to happen, how segmentation should be validated, and what evidence an assessor needs to see.

This article covers PCI DSS Requirement 11.4 as it stands in v4.0.1: how to scope a penetration test against the cardholder data environment (CDE), how often each activity must run, who is qualified to perform it, and what the resulting evidence should contain for a Qualified Security Assessor (QSA) review.

What PCI DSS v4.0.1 Requirement 11.4 requires

Requirement 11.4 is a family of related obligations rather than a single instruction. Read together, they describe a repeatable testing process that covers methodology, internal and external testing, segmentation, remediation, retesting, and additional requirements for service providers.

The methodology requirements in 11.4.1 include the entire CDE perimeter and critical systems, testing from inside and outside the network, application- and network-layer coverage, segmentation validation, consideration of threats and vulnerabilities experienced during the previous 12 months, a risk-based approach to findings, and retention of testing and remediation results for at least 12 months.

Two points on version and status are worth clarifying. Penetration testing lived under Requirement 11.3 in PCI DSS v3.2.1 and moved to Requirement 11.4 in v4.x. Requirement 11.4.7 was a best practice until 31 March 2025. It is now required for applicable multi-tenant service providers, which may either provide customers with sufficient evidence of comparable testing or give them prompt access to perform their own external penetration testing.

How should you define PCI DSS penetration test scope?

Getting the scope right is the first step in a PCI DSS penetration test. Before testing starts, the organization and the testing provider need to map the systems that store, process, or transmit cardholder data and the components that can affect the security of that environment.

A defensible scope covers the CDE, its perimeter, critical systems, and connected or security-impacting components that could provide a path toward the CDE. It should also document what has been excluded and why.

Start with the CDE perimeter and critical systems

Requirement 11.4.1 calls for coverage of the entire CDE perimeter and critical systems. Scope should therefore be built from current cardholder-data flows, network and data-flow diagrams, connected systems, access paths, and components that can affect the security of CHD or SAD.

In practice, that usually reaches beyond the payment page itself. Payment applications and APIs, databases, firewalls, identity and directory services, administrative access systems, cloud control-plane components, logging and monitoring infrastructure, and third-party connections may all be relevant.

Management assets are easy to overlook. An administrator workstation or management jump host that can manage CDE systems, expose privileged credentials, or otherwise affect CDE security needs to be considered during scoping even when it sits outside the CDE itself.

Cover both attack perspectives and both technical layers

Requirement 11.4.1 requires testing from both inside and outside the network, together with application-layer and network-layer penetration testing. PCI SSC also distinguishes clearly between internal and external testing: internal testing includes testing from inside the CDE and into it from trusted and untrusted internal networks, while external testing covers the exposed perimeter and critical systems connected to or accessible from public network infrastructure.

An external-only engagement, however thorough, does not cover the full methodology expected by Requirement 11.4.1.

On the application layer, reducing the scope to the OWASP Top 10 is also insufficient. Requirement 11.4.1 points directly to the vulnerability categories in Requirement 6.2.4. These include injection attacks; attacks on data and data structures; attacks on cryptographic usage; attacks on business logic; client-side attacks such as cross-site scripting (XSS) and cross-site request forgery (CSRF); attacks on access-control mechanisms; and attacks through high-risk vulnerabilities identified under Requirement 6.3.1.

For an authenticated application assessment, this normally means testing the relevant application roles with the credentials and access needed to check authorization boundaries properly. Accounts with different privilege levels should not be able to escalate privileges or reach data they are not permitted to access. In multi-tenant applications where tenant isolation is in scope, the same principle applies between customers: one tenant’s credentials should not provide access to another tenant’s data.

Remediation also differs depending on the weakness. Application-layer findings may require code or design changes, while network-layer issues often involve configuration changes, patching, hardening, or architecture.

Treat segmentation validation as a distinct scope claim

Segmentation is an architectural choice rather than a PCI DSS requirement by itself. Once it is used to isolate the CDE and reduce assessment scope, however, its effectiveness has to be validated under Requirement 11.4.5.

Testing must cover all segmentation controls and methods in use and confirm that they are operational, effective, and isolate the CDE from all out-of-scope systems. Requirement 11.4.5 also requires validation of isolation used under Requirement 2.2.3 to separate systems with different security levels.

This is a distinct part of the penetration test. The tester actively looks for paths from outside the CDE into it. Firewall-based segmentation, VLAN ACLs, routing controls, and other methods in use need to be represented in the methodology and tested accordingly.

For large environments, testing can be organized around repeated implementations, but the methodology still has to cover all segmentation controls and methods in use and provide evidence that supports the full scope claim. PCI DSS does not provide a blanket exception from the “all controls/methods” requirement simply because the environment is large.

If a segment believed to be out of scope can reach the CDE, the claimed isolation is not effective. The segmentation controls need to be corrected and retested, and the effect on PCI DSS scope should be assessed.

Concrete segmentation test cases worth including in the methodology include:

• Host discovery and service testing: From approved out-of-scope test locations, attempt to discover and connect to CDE systems across relevant protocols and paths. PCI SSC specifically identifies host discovery and port scanning as useful techniques; exact coverage and rate limits should be defined in the rules of engagement.
• Controlled data-path testing: Where authorized, use non-sensitive test data to determine whether unexpected data paths undermine the claimed isolation. There is no reason to use live cardholder data simply to prove reachability.
• Spoofing and pivot testing: Assess whether source-address trust or a compromised connected system could bypass segmentation controls and provide a route toward the CDE.

Document exclusions and dependencies

A defensible scope should describe what is out of scope as clearly as what is included. Maintain a scope record listing the included assets, ranges, and applications; excluded areas and their rationale; testing origin points; supplied credentials and roles; third-party constraints; and every segmentation method in use.

PCI DSS does not mandate one universal penetration-testing report format, so this is practical assessor-ready evidence rather than a prescribed template. The important part is consistency: the testing scope needs to reconcile with the CDE network and data-flow documentation. An unexplained mismatch can undermine the assessment and needs to be resolved.

How often is PCI DSS penetration testing required?

This requirement is often summarized incorrectly because the six-month service-provider rule gets generalized into “service providers test everything twice a year.” The six-month cadence applies specifically to segmentation testing under 11.4.6. Internal and external penetration tests under 11.4.2 and 11.4.3 remain subject to the 12-month baseline and significant-change trigger.

PCI DSS does not give one universal definition of a “significant change” because significance depends on the environment. It does, however, identify changes that must at least be considered: new hardware, software, or networking equipment added to the CDE; replacements or major upgrades of CDE hardware and software; changes to account-data flow or storage; changes to the CDE boundary or assessment scope; changes to supporting infrastructure such as directory services, time servers, logging, and monitoring; and changes to third-party vendors or services supporting the CDE.

The entity then evaluates whether a specific change is significant in the context of PCI DSS scope and control effectiveness. A new payment API, cloud migration, redesign of the CDE network, changed remote-access path, or major payment-application release are practical examples of changes that may trigger testing.

The change-driven trigger is also easy to lose inside an annual testing program. A useful way to make the decision auditable is to keep a change-management record containing the change description, affected CDE components and controls, scope-impact assessment, testing decision, approver, and rationale. This is practical governance rather than a PCI DSS-mandated reporting format.

Who is qualified to perform the test?

PCI DSS accepts two models: a qualified internal resource or a qualified external third party. In both cases, the tester needs the appropriate skills and organizational independence from management of the systems being tested. Requirements 11.4.2, 11.4.3, 11.4.5, and 11.4.6 also state that the tester does not need to be a QSA or Approved Scanning Vendor (ASV).

PCI SSC defines organizational independence in terms of avoiding conflicts of interest and gives the example of people performing assessments being organizationally separate from management of the environment being assessed.

For an internal team, reporting lines and responsibilities therefore matter alongside technical expertise. For an external provider, the same principle applies where that provider is also involved in designing, operating, maintaining, or supporting the target environment: the testing function needs enough separation to provide independent validation.

Qualification itself depends on relevant penetration-testing experience, familiarity with comparable environments, application and network expertise, and the ability to follow the defined methodology. Certifications can support that assessment, but PCI DSS does not require a specific penetration-testing certification. PCI SSC itself highlights both certifications and prior penetration-testing experience as factors to consider when selecting a qualified resource.

The standard also makes an important practical point: a penetration test that identifies nothing at all may say more about the depth of the testing than about the security of the environment. A useful engagement should actively look for weaknesses, attack paths, and combinations of issues rather than stop at scanner results.

What should a PCI DSS penetration testing report contain?

PCI DSS v4.0.1 defines what the entity and assessor need to be able to verify, but it does not prescribe one universal penetration-testing report template. The practical goal is to build a deliverable and supporting evidence package that makes the required elements easy to trace.

Engagement and scope evidence

• Dates and test windows.
• Objectives and rules of engagement.
• The complete in-scope inventory: assets, applications, network ranges, roles, and test origins.
• Exclusions and constraints, each with a rationale.
• References to CDE, network, and data-flow documentation and the segmentation methods in use.
• Tester identity, relevant qualifications, and evidence of organizational independence.

Methodology and execution evidence

• The industry-accepted approach used and how it implements Requirement 11.4.1. The methodology may reference frameworks such as the OWASP Web Security Testing Guide, OSSTMM, NIST SP 800-115, or PTES, depending on the environment and engagement.
• The level of knowledge and access provided to the tester, where relevant — for example, black-, gray-, or white-box testing.
• Both internal and external testing perspectives.
• Network-layer and application-layer coverage.
• Manual analysis and exploitation. PCI SSC is explicit that vulnerability scanning alone does not constitute a penetration test and describes penetration testing as a highly manual process, although automated tools may support parts of it.
• Segmentation procedures and results where segmentation is used.
• Consideration of threats and vulnerabilities the entity experienced during the previous 12 months.
• Evidence demonstrating the tested attack paths and impact while limiting unnecessary handling or exfiltration of live cardholder data.

Findings, correction, and repeat testing

• Affected assets and relevant attack paths.
• Reproduction or exploitation evidence and demonstrated impact.
• A risk assessment aligned with the entity’s Requirement 6.3.1 process.
• Actionable remediation guidance.
• Correction status, retest date, retest method, and result.
• For segmentation testing, supporting evidence such as logs or screenshots showing attempted actions and the resulting block or denial, where useful.
• Residual limitations or items that could not be verified.

Requirement 11.4.4 is where a findings-only report falls short. Exploitable vulnerabilities and security weaknesses identified during penetration testing must be corrected according to the entity’s risk assessment, and penetration testing must then be repeated to verify those corrections.

When exploitable issues are found, the evidence package therefore needs to show the retest, rather than ending with remediation tickets or a statement that the issue was fixed. Plan for at least one retest round when scheduling the engagement.

Retention matters too. Requirement 11.4.1 requires penetration-testing results and remediation-activity results to be retained for at least 12 months. A requirement-to-evidence appendix mapping 11.4.1 through 11.4.7 to report sections and supporting records can make the package easier to review, although PCI DSS does not prescribe that terminology or format.

Common gaps that make the evidence incomplete

The same problems tend to appear repeatedly in PCI DSS penetration-testing programs:

• A scan submitted as a penetration test. Automated discovery and vulnerability scanning can support the engagement, but they do not meet the highly manual, active-testing expectation on their own.
• A scope that does not reconcile with CDE documentation. Missing connected or security-impacting components weakens the evidence chain and creates questions when the testing scope is compared with network and data-flow diagrams.
• External-only or application-only testing. Requirement 11.4.1 requires testing from inside and outside the network and coverage of both network and application layers.
• Segmentation assumed rather than tested. Diagrams and firewall-rule reviews do not replace technical validation when segmentation is used to reduce PCI DSS scope.
• No post-change trigger. An annual test does not cover a significant infrastructure or application change that happens afterwards.
• No evidence of independence. Technical skill alone does not resolve a conflict with management of the systems being tested.
• Findings closed without repeat testing. Remediation tickets alone do not satisfy the verification step in Requirement 11.4.4.
• Service-provider frequency misunderstood. The six-month cadence applies to segmentation testing under 11.4.6, rather than every penetration test covered by Requirement 11.4.

How Iterasec supports PCI DSS penetration testing

Iterasec’s role in a PCI DSS program is independent technical validation: testing the environment for real attack paths, documenting their impact, and verifying the fixes.

• Scope and methodology alignment. We reconcile attack surfaces and segmentation claims against the perspectives and technical layers required by 11.4.1 so the engagement reflects the actual CDE and connected environment.
• Internal, external, application, API, and network testing. We test realistic attack paths and chained weaknesses rather than reproducing scanner output.
• Segmentation validation. We test declared segmentation controls and methods from relevant out-of-scope positions and record both the attempted action and the result.
• Remediation validation and reporting. We provide the repeat-testing evidence required by 11.4.4 and structure findings so they are useful both for technical remediation and assessor review.

A clean scan or a findings-only report does not demonstrate that the full PCI DSS penetration-testing cycle has been completed. The evidence needs to reflect the environment’s actual attack paths, the remediation performed, and the results of repeat testing.

Conclusion

Requirement 11.4 is designed to show whether the controls protecting payment data continue to work under realistic attack conditions.

That starts with a scope that matches the CDE and its security dependencies, follows a documented methodology across internal and external perspectives and both technical layers, and continues through remediation and repeat testing. The resulting evidence should make that process traceable during a PCI DSS assessment.

If you are defining CDE scope, validating segmentation, planning testing after a significant change, or preparing for a QSA assessment, contact Iterasec to discuss your PCI DSS penetration-testing requirements and build an engagement around the environment you actually need to validate.