PCI DSS penetration testing requirements: A 4.0 Guide

Penetration testing is not the same as running a vulnerability scan. A scan identifies potential weaknesses, while a penetration test attempts to exploit them and show their real impact. For organizations that store, process, or transmit payment card data, that distinction affects both technical coverage and the evidence prepared for assessment.

Explore Penti's AI penetration testing capability for a more continuous approach to security testing.

PCI DSS 4.0 keeps the focus on demonstrating that security controls work in practice, while placing greater emphasis on methodology, documented outcomes, and security weaknesses. The details begin with how Requirement 11.4 defines the work and how its subrequirements shape a defensible testing plan. See the compliance penetration testing requirements guide for broader framework context.

What are the PCI DSS penetration testing requirements in v4.0?

PCI DSS 4.0 requires organizations to maintain a documented penetration testing process for the systems and networks that protect cardholder data. The core requirement sits in Requirement 11, which addresses regular testing of security controls. Requirement 11.4 focuses specifically on internal and external penetration testing, rather than treating a vulnerability scan as equivalent evidence.

What Requirement 11.4 requires

Requirement 11.4.1 is described as requiring a documented penetration testing methodology that covers the entire cardholder data environment perimeter and critical systems that could affect its security. In practice, that methodology should make the test repeatable and explain how the organization identifies scope, evaluates attack paths, records findings, and validates remediation.

The requirement is not satisfied by a generic security statement or a scan report alone. A penetration test is intended to examine whether weaknesses can be exploited and what impact that exploitation could have. The exact validation obligations depend on the organization, its PCI DSS scope, and the assessment path being used. Confirm the current interpretation and evidence expectations with your qualified security assessor (QSA) or acquiring bank, using the official PCI Security Standards Council PCI DSS standards page as the primary reference.

Requirement 11.4 also connects testing to remediation. Findings need an accountable response, and the organization should be able to show what was tested, what was found, and how material issues were addressed. That evidence is different from a broad claim that the environment is secure.

For a wider explanation of how testing maps to different frameworks, see Penti's compliance penetration testing requirements guide. This article stays focused on PCI DSS Requirement 11.4, including its scope, testing cadence, documentation, and relationship to ongoing security monitoring.

What must be in scope for a PCI DSS penetration test?

The scope should cover the full cardholder data environment (CDE) perimeter, plus any critical system that could affect CDE security. That means starting with an accurate inventory of data flows, trust boundaries, supporting infrastructure, and routes into the environment, rather than selecting a few convenient assets for testing.

A practical scope review should identify both external and internal attack surfaces. External testing can include public-facing web applications, APIs, VPN endpoints, remote access services, and reporting servers. Internal testing may include workstations, servers, internal applications, authentication services, databases, and the network paths that connect them. These examples are not a universal checklist. The systems in scope depend on how each organization stores, processes, transmits, and protects cardholder data. Use a PCI compliance checklist as a planning aid, then confirm the final boundary with the organization's QSA or acquiring bank.

Test the boundaries, not just the obvious assets

If network segmentation is used to isolate the CDE, the assessment should test whether those controls actually prevent unauthorized paths into the cardholder environment. This can require testing routes between the CDE and connected networks, not simply scanning devices inside the segmented zone. Where segmentation is not effective or is not used, more of the routable environment may remain in scope.

The scope should also account for systems that do not handle cardholder data directly but could materially affect its security. Examples include identity and access management, administrative interfaces, deployment systems, monitoring platforms, cloud controls, and shared services. The final test plan should document why each included or excluded asset belongs inside or outside the boundary.

Use qualified and independent testers

Testing may be performed by internal personnel when they are qualified. But the people conducting the assessment should be organizationally separate from the management of the environment being tested. That separation helps reduce conflicts of interest and makes the results more credible. An external provider can also be used, provided its personnel and methods meet the applicable requirements.

Because scope and interpretation can vary by environment and validation approach, treat these elements as a planning framework, not a compliance determination. Record the CDE boundary, critical dependencies, external and internal targets, segmentation assumptions, and tester independence in the test documentation before execution.

How often does PCI DSS require penetration testing?

For most organizations, the baseline cadence is at least once every 12 months for both internal and external penetration testing. Testing may also be required after significant infrastructure or application changes, rather than waiting for the next annual assessment. The exact obligation depends on the organization's PCI DSS scope, merchant or service-provider role, and assessment method.

The annual internal and external cadence, change-triggered testing, and service-provider segmentation interval should be checked against the PCI Security Standards Council PCI DSS standards page. Practical summaries can help with planning, but they are not a substitute for the standard or an assessment decision.

A significant change can alter the systems, applications, connectivity, or controls that support the cardholder data environment. When that happens, the responsible question is not simply whether the last test was recent. It is whether the prior test still represents the current attack surface and segmentation design. Any exploitable vulnerabilities identified during testing must be corrected, with testing repeated to confirm remediation.

Do not assume the same schedule applies to every entity. Merchants and service providers can have different segmentation obligations, and a service provider's assessed services may introduce additional scope considerations. Confirm the applicable requirements, SAQ or ROC path, and testing evidence expectations with your qualified security assessor (QSA) or acquiring bank before finalizing the calendar.

What changed in PCI DSS v4.0 for penetration testing?

PCI DSS v4.0 keeps the core expectation for internal and external testing, but it makes the testing program more explicit. Teams need a documented methodology, a clear treatment of security weaknesses, and evidence that testing covers relevant segmentation controls and critical systems.

One important change is the broader remediation language. The program should address not only exploitable vulnerabilities, but also security weaknesses such as encryption problems and security misconfigurations. A finding does not need to produce a demonstrated compromise to deserve review and remediation. Your report should explain the risk, the affected asset, the corrective action, and the retest outcome.

Document the method, not just the result

A credible methodology defines the objectives, scope, test techniques, limitations, and rules of engagement before testing begins. It should show how the team assessed the CDE perimeter and critical systems that could affect CDE security. Recognized approaches can inform the method, but the documentation should make the actual testing process understandable to a QSA and to the system owners responsible for remediation.

PCI DSS v4.0 also introduces a Customized Approach as an option for meeting security objectives with alternative controls. That option does not eliminate the need for a defensible method or evidence. If your organization uses it, document the security objective, the alternative control design, the testing performed, and how the evidence supports the intended outcome. Confirm the interpretation with your QSA or acquiring bank.

Test segmentation and separate scanning from exploitation

When network segmentation is used to isolate the CDE, testing should examine whether those controls are effective. This is different from assuming that a firewall rule or network diagram proves isolation. The test should consider whether an attacker could cross the intended boundary and reach systems that should remain separated.

Vulnerability scanning is a related but separate activity. PCI DSS Requirement 11.3.1.2 addresses authenticated vulnerability scanning, while external scanning is also distinct from penetration testing. A scan identifies potential issues. A penetration test goes further by attempting to exploit weaknesses and demonstrate their impact. Both activities can support a stronger security program, but one should not be presented as a substitute for the other.

For the current PCI DSS v4.0.1 publication and related clarification, consult the PCI Security Standards Council update. Requirements and validation details can depend on the organization's environment, so treat this section as practical guidance rather than a compliance guarantee.

How should you document PCI DSS penetration test results for a QSA?

Give the QSA an evidence trail that connects the approved scope to the methods used, the findings discovered, and the actions taken afterward. A polished report is useful, but no report format guarantees an assessment outcome. Your QSA or acquiring bank must confirm the evidence and validation details that apply to your environment.

1. Define scope and authorization. Record the assessment window, business owner, systems and networks tested, CDE perimeter, critical systems that could affect CDE security, and any segmentation boundaries. Identify excluded assets and explain why they are out of scope. Include tester qualifications and organizational independence where relevant.
2. Describe the methodology. State whether testing covered external and internal attack surfaces, the entry points assessed, the testing constraints, and the approach to validation. A recognized reference such as NIST SP 800-115 can help structure technical testing, findings analysis, and mitigation planning. The PCI SSC penetration testing guidance provides additional context for planning and reporting.
3. Capture dates and evidence sources. Include the test start and end dates, report issue date, environment version or change reference, tester identity, and the tools or techniques used. Preserve relevant request logs, screenshots, sanitized proof-of-concept details, and evidence that shows what was actually tested. Keep sensitive evidence in an access-controlled repository with retention and handling rules.
4. Document findings and risk. For every finding, record the affected asset, weakness, exploitation path, observed impact, severity rationale, and supporting evidence. Keep vulnerability scanning results distinct from penetration testing results: a scan identifies potential issues, while a test validates weaknesses and demonstrates impact.
5. Track remediation and retesting. Map each exploitable vulnerability to an owner, corrective action, status, and completion date. PCI DSS guidance describes correcting exploitable vulnerabilities and repeating testing to confirm remediation. Attach retest scope, dates, results, and residual limitations rather than simply marking findings closed.
6. Package and control the final record. Keep the signed or approved report, management response, remediation tracker, retest evidence, and exceptions together. Restrict access, record version history, and provide the QSA a read-only or time-limited review path when possible. For broader context on penetration testing for compliance, distinguish evidence that supports an assessment from a claim that testing alone proves compliance.

This workflow makes the report reviewable without overstating what the test establishes. It also gives the QSA a clear path from requirement, to observed evidence, to remediation and retest.

How does continuous security testing support PCI DSS?

Continuous security testing helps teams spot changes between formal assessments, but it does not replace the penetration test required by the applicable PCI DSS scope. It is best treated as an operational layer that keeps the environment visible and helps the next assessment start with better evidence.

Vulnerability scanning and penetration testing answer different questions. Authenticated scanning, associated with PCI DSS Requirement 11.3.1.2, can identify potential weaknesses across known systems. External vulnerability scanning is also separate from the penetration-testing activity. A penetration test goes further by attempting to exploit a weakness and demonstrate its potential impact. That distinction matters when a scan produces a long list of findings that still require validation and prioritization.

Use monitoring to detect change, not to claim completion

Changes to internet-facing applications, APIs, cloud assets, network paths, authentication controls, or segmentation can alter the attack surface before the next scheduled test. A continuous process can compare asset inventories, flag newly exposed services, and identify changed configurations for review. Those signals can help determine whether a significant change warrants targeted retesting under the organization's PCI DSS process.

Automation still needs human validation. A qualified tester must interpret context, investigate attack paths, distinguish exploitable conditions from noise, and assess business impact. Penti's AI penetration testing capability is positioned around machine-scale testing paired with certified human review, rather than presenting automation as a substitute for expert judgment.

Keep the evidence trail useful to the assessor: record what was monitored, when a change was detected, how it was investigated, which findings were remediated, and what was retested. NIST SP 800-115 describes testing as a process for planning technical tests, analyzing findings, and developing mitigation strategies, while also emphasizing the benefits and limitations of different techniques. Organizations should confirm the exact evidence and retesting expectations with their QSA or acquiring bank, just as they should for other security compliance requirements.

Frequently Asked Questions

How often should PCI DSS penetration testing be conducted?

Plan internal and external penetration testing at least every 12 months, and repeat testing after significant infrastructure or application changes. If segmentation isolates the cardholder data environment, test those controls on the applicable cadence as well. Confirm the exact validation expectations with your QSA or acquiring bank using the PCI DSS standards reference.

What qualifies as a significant change that triggers retesting?

A significant change is an infrastructure, application, network, or segmentation change that could alter the cardholder data environment or its security controls. Examples may include a major application release, a new public-facing entry point, material network redesign, or changed segmentation rules. Document the change assessment and ask your QSA to confirm whether targeted or full retesting is appropriate.

Can an internal tester meet PCI DSS penetration testing requirements?

Yes, an internal team may perform the test when its personnel are qualified and organizationally separate from management of the environment being assessed. Independence should be documented, along with tester qualifications, scope, methodology, findings, remediation, and retest evidence. An external provider may be preferable when internal independence or specialized expertise is difficult to demonstrate.

What evidence should be retained for a PCI DSS penetration test?

Keep the approved scope, test dates, methodology, systems and attack surfaces tested, tester qualifications and independence, findings, risk treatment, remediation records, and retest results. The report should make clear what was tested, how it was tested, and what the testing found. A methodology can be informed by recognized guidance such as NIST SP 800-115.

Explore a More Continuous Approach to Security Testing

PCI DSS penetration testing is one part of an ongoing security program. Penti's AI penetration testing capability can help your team identify issues more continuously while keeping human validation in the process. Book a call with Penti's security team to discuss your testing program and next steps.