PCI DSS Penetration Testing Requirements Explained

PCI DSS penetration testing is not simply an annual external security test. Under PCI DSS v4.0.1, organizations in scope for Requirement 11.4 need a documented penetration-testing methodology, internal and external testing at least once every 12 months and after significant changes, remediation and retesting of exploitable findings, and additional testing when network segmentation is used to reduce PCI scope.

Copy the finding-to-retest handoff record to distinguish a deployed fix from verified correction.

Service providers face an additional wrinkle: when segmentation is used to isolate the cardholder data environment, their segmentation controls generally need penetration testing at least every six months rather than every 12 months. Multi-tenant service providers also have specific obligations to support customers that need external penetration-testing evidence or access.

As of September 2026, PCI DSS v4.0.1 is the current PCI DSS standard. PCI DSS v4.0 was retired at the end of 2024, and requirements that had been future-dated until March 31, 2025 are now effective. PCI DSS is a global payment-security standard rather than a US- or UK-specific statute, although payment brands, acquiring banks, processors, contracts, and local laws can create additional obligations.

Before you act: This guide explains the PCI DSS requirements and practical preparation issues. It does not determine the PCI scope, SAQ, reporting route, or validation obligations of a particular business. Confirm material scoping decisions with the organization accepting your PCI DSS validation and, where appropriate, a Qualified Security Assessor.

What PCI DSS Requirement 11.4 actually requires

Requirement 11 is concerned with regularly testing the security of systems and networks. Penetration testing sits primarily in Requirement 11.4, but it works alongside vulnerability scanning, change management, application security, scoping, and remediation requirements elsewhere in the standard.

The table is a planning summary rather than a substitute for the standard. The PCI Security Standards Council’s penetration-testing guidance provides additional context on scoping, internal and external tests, segmentation, tester competence, methodology, and reporting. Its older requirement numbering reflects the PCI DSS version in force when the guidance was published, so use v4.0.1 for current requirement numbers.

Requirement 11.4.1 starts with the methodology, not the scanner

A PCI penetration test should not begin with someone pointing a tool at a subnet and seeing what happens. Requirement 11.4.1 expects the entity to define, document, and implement its penetration-testing methodology first.

That methodology needs to cover the entire cardholder data environment perimeter and critical systems, testing from inside and outside the network, validation of segmentation and other scope-reduction controls, application-layer testing, and network-layer testing of relevant network-function components and operating systems. It also needs to consider threats and vulnerabilities experienced during the previous 12 months.

The methodology should additionally describe how the organization evaluates and addresses the risk created by exploitable findings and how penetration-test and remediation records are retained. Requirement 11.4.1 calls for penetration-testing results and remediation-activity results to be retained for at least 12 months.

PCI DSS refers to industry-accepted approaches rather than prescribing one proprietary penetration-testing recipe. For web applications, the OWASP Web Security Testing Guide provides a detailed testing framework covering areas such as authentication, authorization, session management, input validation, business logic, client-side behavior, and APIs. For broader technical security-assessment planning, NIST SP 800-115 describes methods for planning assessments, conducting technical tests, analyzing findings, and developing mitigation strategies.

This is also where the distinction between human-led testing and automated scanning becomes important. If you are deciding what type of engagement to purchase, the Kioptrix guide to manual penetration testing versus automated scanners explains why the two activities answer different security questions.

Internal and external penetration tests are both required

Requirements 11.4.2 and 11.4.3 separate internal and external penetration testing. An organization should therefore be wary of a proposal that promises a single vague “PCI pentest” without identifying which perspective, systems, trust boundaries, applications, and network paths are covered.

Internal penetration testing

Internal testing examines the environment from inside the network. The PCI guidance describes this as including testing from inside the CDE as well as attempts to reach the CDE from trusted and untrusted internal networks where applicable.

The purpose is not merely to prove that an internal server contains a vulnerability. The test can examine whether internal access controls, trust relationships, network boundaries, privileges, and attack paths allow an attacker who has gained an internal foothold to move toward systems that store, process, or transmit cardholder data.

External penetration testing

External testing evaluates the exposed perimeter and critical systems reachable through public network infrastructure. Depending on the environment, that can include Internet-facing applications, APIs, gateways, remote-access services, and other exposed pathways associated with the PCI scope.

Both internal and external penetration tests under Requirements 11.4.2 and 11.4.3 must be performed at least once every 12 months and after a significant infrastructure or application upgrade or change.

Significant changes can trigger additional testing

The annual test is a minimum cadence, not a permission slip to ignore the environment for the next 364 days. PCI DSS also requires internal and external penetration testing after a significant infrastructure or application upgrade or change.

What qualifies as significant depends on whether the change could materially affect the security of the CDE. A major application release, important network redesign, new payment architecture, substantial cloud migration, or another change that alters attack paths may trigger additional testing. Changes to segmentation controls receive their own explicit post-change testing requirement.

A practical approach is to connect PCI testing decisions to the change-management process. Each meaningful change can then answer a simple question before closure: Does this alter the CDE, its perimeter, a critical system, an application attack surface, or the controls that keep other systems out of PCI scope?

If the answer is yes or is genuinely uncertain, document the decision and determine whether additional penetration testing is required. Waiting until the annual assessment to reconstruct six months of undocumented architecture changes is compliance archaeology, and archaeology is an expensive way to run security.

PCI DSS requires remediation and retesting, not just a report

A penetration-test PDF is not the finish line. Requirement 11.4.4 requires exploitable vulnerabilities and security weaknesses identified during penetration testing to be corrected in accordance with the organization’s assessment of risk under Requirement 6.3.1. Testing is then repeated to verify the corrections.

This distinction matters when buying a test. A low initial quote can become less attractive if remediation validation is excluded, if each retest is billed separately, or if the provider gives you scanner output without enough evidence to reproduce and verify findings.

Before procurement, ask what the deliverable will show after remediation: the original finding, affected assets, evidence, remediation status, retest date, verification method, and final outcome. Kioptrix’s guide on how to read a penetration test report can help security and compliance owners distinguish actual tested scope and evidence from a polished executive summary that says very little.

Segmentation testing is where PCI scope meets reality

Network segmentation is not universally required by PCI DSS, but organizations frequently use it to separate the CDE from other systems and reduce the number of systems to which PCI DSS requirements apply.

If segmentation is being relied upon to isolate the CDE, Requirement 11.4.5 requires penetration testing of those controls at least every 12 months and after changes to the segmentation controls or methods. The test needs to cover the segmentation controls and methods being used and confirm that they are operational, effective, and actually isolate the CDE from systems considered out of scope.

This makes segmentation testing more than another firewall scan. The real question is whether a system that the organization has declared outside PCI scope can nevertheless communicate with, reach, or influence the CDE in a way that defeats the intended isolation.

The PCI SSC’s newer scoping and segmentation guidance for modern network architectures addresses the challenges created by multi-cloud systems, micro-segmentation, zero-trust architectures, and ephemeral infrastructure. These environments make a stale network diagram particularly dangerous because the technical boundary can move while the compliance documentation remains frozen in time.

Service providers have a six-month segmentation requirement

Requirement 11.4.6 adds a stricter cadence for service providers that use segmentation to isolate the CDE from other networks. Their segmentation controls must be penetration tested at least once every six months and after changes to the segmentation controls or methods.

This should not be confused with saying every PCI penetration test for every service provider must occur every six months. The six-month frequency in Requirement 11.4.6 specifically addresses the applicable segmentation-control testing requirement for service providers.

Multi-tenant service providers also need to consider Requirement 11.4.7. Since its March 31, 2025 effective date, applicable providers must support customers that need external penetration testing under Requirements 11.4.3 and 11.4.4. PCI DSS allows this to be addressed through sufficient evidence that appropriate testing was performed on the customer’s subscribed infrastructure or by providing prompt access so the customer can conduct its own testing, subject to the applicable arrangements.

A PCI penetration test is not the same as an ASV scan

One of the most expensive misunderstandings in PCI testing is treating vulnerability scanning and penetration testing as interchangeable.

Requirement 11.3.2 addresses external vulnerability scanning and, where applicable, requires passing external scans by a PCI SSC Approved Scanning Vendor at least once every three months. Requirement 11.4 addresses penetration testing. They are different activities with different purposes, methodologies, evidence, and qualification rules.

The PCI SSC has a dedicated resource guide explaining vulnerability scans and Approved Scanning Vendors. If you are budgeting both activities, separating them at the procurement stage prevents the classic problem of purchasing a scanner and discovering later that the assessment still requires a penetration test.

Does the PCI pentester have to be a QSA?

No. Requirements 11.4.2 and 11.4.3 allow testing by a qualified internal resource or a qualified external third party, provided organizational independence exists. PCI DSS explicitly notes that the tester does not have to be a Qualified Security Assessor or Approved Scanning Vendor merely to satisfy these penetration-testing requirements.

That does not make qualifications optional. The organization still needs to be able to support why the person conducting the assessment is qualified for the systems, technologies, applications, and testing methods in scope.

For an internal tester, independence also needs to be defensible. Having the person responsible for building and operating a control serve as the sole person objectively testing the effectiveness of that same control can create an obvious independence problem.

What should be in a PCI penetration-testing statement of work?

The safest procurement question is not “How much does a PCI pentest cost?” It is “What exact Requirement 11.4 work is included in this scope?”

• PCI DSS version and applicable requirement references.
• Defined CDE perimeter and critical systems.
• Applications, APIs, hosts, cloud resources, network ranges, and other assets included.
• Internal testing perspective and access assumptions.
• External testing perspective and exposed assets.
• Application-layer and network-layer coverage.
• Segmentation controls and each relevant segmentation method.
• Relevant threats and vulnerabilities from the preceding 12 months.
• Testing windows, prohibited actions, production-safety constraints, and escalation contacts.
• Tester qualifications and organizational-independence considerations.
• Finding severity and risk-assessment method.
• Remediation-verification and retest terms.
• Final report, evidence, and retention expectations.

Pricing varies dramatically because “PCI penetration test” can describe anything from a tightly bounded application and network assessment to a multi-location, cloud-heavy environment with complex internal paths and segmentation. The Kioptrix guide to small-business penetration-testing cost explains the scope variables worth defining before comparing quotes.

What evidence should you keep for the assessment?

A clean evidence package makes the annual PCI review much less theatrical. Instead of hunting through old tickets and inboxes, maintain a coherent record showing what was supposed to be tested, what was actually tested, what was found, what changed, and how remediation was verified.

• The approved penetration-testing methodology.
• The PCI scope and current CDE boundary used to build the test scope.
• Statement of work, rules of engagement, and target inventory.
• Internal penetration-test report.
• External penetration-test report.
• Segmentation-test results when segmentation is used.
• Evidence of tester qualifications and appropriate independence.
• Finding and remediation records.
• Retest results confirming corrections.
• Change records showing whether significant changes triggered additional testing.
• At least 12 months of penetration-test and remediation-activity results as required by the methodology requirement.

For teams building their reporting process from scratch, a structured penetration-test report template can help organize scope, methodology, findings, evidence, impact, remediation, limitations, and retest status. The final PCI evidence still needs to match the actual engagement and applicable requirements rather than merely resemble a professional report.

Common PCI penetration-testing mistakes

Buying a vulnerability scan and calling it a pentest

Automated vulnerability discovery can be part of a penetration-testing workflow, but it does not by itself establish that Requirement 11.4 has been met. Check the methodology and coverage rather than the product name printed on the invoice.

Testing only the Internet-facing perimeter

An external test does not replace the internal test required by 11.4.2. The engagement should clearly identify both perspectives where the requirements apply.

Using last year’s asset list

A penetration test can be technically excellent and still provide weak compliance evidence if its target list no longer matches the CDE. Scope should be reconciled with current systems, data flows, network architecture, cloud resources, critical systems, and segmentation boundaries before testing starts.

Forgetting the post-change trigger

An annual calendar entry is useful but incomplete. Significant infrastructure or application changes can require new internal and external testing, while changes to segmentation controls trigger additional segmentation testing.

Closing findings without retesting

A remediation ticket saying “fixed” is not the same as repeating the relevant penetration testing to verify the correction. Build verification into the engagement before the initial test begins.

Assuming a cloud provider’s PCI status covers everything

A third-party provider can take responsibility for controls it operates, but outsourcing infrastructure does not automatically remove the customer’s systems, configurations, integrations, applications, or responsibilities from consideration. Obtain the provider’s current PCI documentation and responsibility information, then map it to your own scope.

A practical PCI penetration-testing calendar

For a merchant using segmentation, a simple operating model might place the full internal, external, and applicable segmentation testing on an annual schedule while connecting significant changes and segmentation changes to change-control triggers throughout the year.

A service provider using segmentation needs to accommodate the six-month segmentation cadence in Requirement 11.4.6. A multi-tenant provider should additionally account for customer penetration-testing support and any applicable Appendix A1 requirements.

The important part is that the calendar should not become the control. The environment is the control trigger. A test scheduled for December does not excuse an organization from examining a significant architecture change completed in April.

How much PCI penetration testing should you buy?

Buy enough testing to cover the requirement and the actual environment, not enough pages to make the report look impressive.

A tightly scoped merchant with a small CDE may need a comparatively straightforward engagement. An organization with custom payment applications, multiple cloud environments, complex internal trust paths, numerous critical systems, several segmentation technologies, and frequent releases may need substantially more effort.

Before requesting quotes, map the cardholder-data flow and confirm the current PCI scope. This same principle drives the wider compliance budget. The Kioptrix guide to PCI DSS compliance costs for small businesses explains why payment architecture and scope can influence total cost more than company size alone.

Engagement / report version / finding ID:
Test perspective and affected in-scope assets:
Authorized scope, exclusions and rules-of-engagement reference:
Original evidence and reproduction reference:
Risk evaluation / remediation owner / target date:
Correction and deployed version / change reference:
Retest scope and prerequisites:
Retest date / qualified tester / independence reference:
Verification method / actual result / evidence reference:
Resolved, still reproducible, partly resolved or not retested:
Untested assets or conditions / remaining limitations:
Further correction or test needed / owner / due date:
Updated report / closure reviewer / review date:
Next scheduled assessment or change-trigger review:

FAQ

How often does PCI DSS require a penetration test?

Requirements 11.4.2 and 11.4.3 require internal and external penetration testing at least once every 12 months and after significant infrastructure or application upgrades or changes. Additional schedules apply to segmentation testing. Service providers using segmentation have a six-month segmentation-testing requirement under 11.4.6.

Does PCI DSS require both internal and external penetration testing?

Yes, where Requirements 11.4.2 and 11.4.3 apply. The methodology under 11.4.1 also explicitly encompasses testing from inside and outside the network.

Can an internal employee perform the PCI penetration test?

PCI DSS permits a qualified internal resource or qualified external third party to conduct the applicable penetration testing. The tester must have appropriate organizational independence. The person does not have to be a QSA or ASV simply because the engagement is a PCI DSS penetration test.

Is an ASV scan enough for PCI penetration-testing compliance?

No. External ASV vulnerability scanning under Requirement 11.3.2 and penetration testing under Requirement 11.4 are separate PCI DSS activities. Completing one does not automatically satisfy the other.

Do findings have to be retested?

Requirement 11.4.4 requires applicable exploitable vulnerabilities and security weaknesses to be corrected and penetration testing to be repeated to verify the corrections. Retesting should therefore be considered part of the compliance workflow rather than an optional cosmetic update to the report.

Does segmentation reduce the need for testing?

Segmentation can reduce PCI DSS scope when it effectively isolates the CDE, but using that reduced scope creates a need to validate that the segmentation controls actually work. A smaller claimed scope is valuable only when the boundary survives technical testing.

The simplest way to prepare for PCI penetration testing

Start with scope, not a vendor quote.

Draw the current cardholder-data flow, identify the CDE and critical systems, list internal and external attack surfaces, record every segmentation method being relied upon, and compare that inventory with your last penetration-test report. Then identify significant changes made since that test and unresolved findings that still require verification.

Once those pieces agree, a penetration-testing provider can price and execute a meaningful engagement. When they do not agree, even an excellent tester is being handed the wrong map.

PCI DSS Requirement 11.4 is ultimately less about producing one annual report than maintaining evidence that the boundaries protecting cardholder data have been challenged from the relevant directions, weaknesses have been addressed, and the scope you claim on paper still exists in the network you actually operate.

Workflow aid reviewed: 2026-10-23. Added a finding-to-retest record and clarified the significant-change heading. No penetration test, remediation or assessment conclusion was produced for this update.