PCI DSS Requirement 11.4: Penetration Testing Guide

PCI DSS Requirement 11.4: What Your Penetration Test Must Cover

A practical, requirement-level guide to PCI DSS v4.0.1 penetration testing, including methodology, internal and external scope, segmentation, retesting, significant changes and the evidence your QSA needs to see.

PCI DSS v4.0.1 Requirement 11.4 requires a defined penetration testing methodology, internal and external penetration testing at least every 12 months and after significant infrastructure or application changes, remediation and retesting of exploitable weaknesses, and segmentation testing where segmentation is used to isolate the cardholder data environment (CDE).

The difficult part is rarely proving that a penetration test happened. It is proving that the right environment was tested from the right perspectives, with a methodology and evidence trail that support the PCI DSS assessment. A technically strong test can still leave a QSA with an evidence gap if scope, timing, segmentation or retesting is unclear.

The version dates are worth getting right. PCI DSS v4.0.1 (direct PDF) was published in June 2024. PCI DSS v4.0 was retired on 31 December 2024, leaving v4.0.1 as the only active version supported by PCI SSC. The future-dated requirements in PCI DSS v4.x became effective on 31 March 2025. In 2026 there is no remaining grace period for the applicable parts of Requirement 11.4.

PCI SSC also ran a six-week request for comments on PCI DSS v4.0.1 from 3 June to 20 July 2026. That shows the standard is continuing to evolve, but v4.0.1 remains the current active version and PCI SSC has not announced a replacement date.

Requirement 11.4 at a glance

The wording above is summarised from PCI DSS v4.0.1 Requirements and Testing Procedures. Applicability still matters. For example, 11.4.5 only applies where segmentation is being relied on to isolate the CDE, 11.4.6 is an additional service-provider requirement, and 11.4.7 is specific to multi-tenant service providers.

11.4.1 is the foundation: the methodology has nine required elements

The most important clause is also the one that is easiest to reduce to a vague sentence in a scope document. Requirement 11.4.1 does not merely ask for a named pentesting standard. It requires the entity to define, document and implement a methodology containing nine specific elements. (PCI DSS v4.0.1, Requirement 11.4.1.)

• Use industry-accepted penetration testing approaches.
• Cover the entire CDE perimeter and critical systems.
• Test from both inside and outside the network.
• Validate segmentation and other scope-reduction controls.
• Perform application-layer testing that identifies, at a minimum, the vulnerability classes referenced in Requirement 6.2.4.
• Perform network-layer testing across components supporting network functions and operating systems.
• Review and consider threats and vulnerabilities experienced during the previous 12 months.
• Use a documented approach to assess and address the risk from exploitable vulnerabilities and security weaknesses found during testing.
• Retain penetration testing results and remediation activity results for at least 12 months.

That is why simply writing "OWASP", "NIST" or another framework name in the methodology section is not enough. Recognised references such as NIST SP 800-115, the OWASP Web Security Testing Guide and OSSTMM can help shape a defensible methodology. PCI SSC also provides Penetration Testing Guidance, but that guidance dates from 2017 and predates PCI DSS v4.x. It is supplemental material, not a substitute for the current requirement text. The methodology still has to show how all nine elements of 11.4.1 are covered in the environment being assessed.

Application-layer testing means more than scanning the public website

Requirement 11.4.1 ties application-layer penetration testing to the vulnerability classes in Requirement 6.2.4. That includes injection attacks, attacks on data and data structures, weaknesses in cryptographic use, business-logic abuse, access-control attacks and high-risk vulnerabilities identified through the entity's vulnerability management process. (PCI DSS v4.0.1, Requirements 11.4.1 and 6.2.4.)

For a modern payment environment, that can mean web applications, APIs, administrative interfaces, client-side functionality and the business processes that connect them. A test that only probes a login page and runs automated checks against public endpoints may leave material parts of the application-layer attack surface untested.

Does PCI DSS 11.4 explicitly require authenticated penetration testing?

No, not as a separately worded requirement. This is an area where online guidance often becomes more definite than the standard itself. Requirement 11.4 does not contain a standalone instruction saying that every penetration test must be "authenticated".

What it does require is meaningful application-layer coverage, the full CDE perimeter and critical systems, and testing from the relevant internal and external perspectives. If important in-scope functionality only exists behind authentication, a credible test will often need suitable accounts, roles or session context to assess it properly. That is a scoping and coverage conclusion, not a separate PCI clause called authenticated penetration testing.

This distinction matters because authenticated vulnerability scanning is explicitly addressed elsewhere in PCI DSS, under Requirement 11.3.1.2 for internal vulnerability scanning. Conflating that language with Requirement 11.4 can make an otherwise accurate pentest report harder to defend. (PCI DSS v4.0.1, Requirement 11.3.1.2.)

11.4.2 and 11.4.3: internal and external testing are separate obligations

PCI DSS separates internal and external penetration testing for a reason. An external test asks what can be reached and exploited from public network infrastructure. An internal test asks what can be reached from inside the environment, including paths into the CDE from trusted and untrusted internal networks.

The current standard defines internal penetration testing as testing from both inside the CDE and into the CDE from trusted and untrusted internal networks. External penetration testing covers the exposed external perimeter of trusted networks and critical systems connected to, or accessible from, public network infrastructure. (PCI DSS v4.0.1, Requirements 11.4.2 and 11.4.3.)

Both 11.4.2 and 11.4.3 require testing at least once every 12 months and again after a significant infrastructure or application upgrade or change. Both allow a qualified internal resource or qualified external third party, provided organisational independence exists. The tester is explicitly not required to be a QSA or ASV. (PCI DSS v4.0.1, Requirements 11.4.2 and 11.4.3.)

Who can perform a PCI DSS penetration test?

PCI DSS does not force you to hire an external pentesting company. A qualified internal resource is permitted. The important conditions are competence and organisational independence.

In practice, an organisation should be able to explain why the tester is suitably qualified and sufficiently separate from responsibility for the systems and controls being assessed. An internal security team can therefore be entirely valid where that independence is defensible. Conversely, simply buying an external test does not compensate for weak scope, shallow methodology or poor evidence.

What should be in scope before testing starts?

A defensible Requirement 11.4 scope starts with the CDE and the paths that can affect it, not with a list of public IP addresses. Before testing begins, the entity and tester should be able to reconcile the penetration-test scope with the current PCI DSS scope and account-data flows.

• CDE boundaries and critical systems, including systems that store, process or transmit account data and systems that can affect their security.
• Externally accessible infrastructure, applications, APIs and administrative interfaces connected to or supporting the in-scope environment.
• Internal trusted and untrusted network paths into the CDE, including relevant user, server, management and wireless segments where applicable.
• Segmentation controls and every scope-reduction method being relied on to keep systems outside the CDE.
• Authentication roles or test accounts needed to exercise material in-scope functionality, plus documented exclusions, constraints and third-party dependencies.

For example, a card-not-present environment may include the checkout application, payment APIs, administrative portal, supporting cloud or network components, internal management paths and the segmentation boundary around the CDE. The exact scope depends on the architecture, but the key test is whether every relevant attack path and scope-reduction assumption can be defended from the evidence.

What counts as a significant change?

The annual cadence is only the baseline. Requirement 11.4.2 and 11.4.3 also trigger testing after a significant infrastructure or application upgrade or change.

PCI DSS v4.0.1 guidance provides the primary current context for evaluating significant changes. Examples that warrant assessment include changes to in-scope hardware, software or networks, account-data flows or storage, CDE boundaries, supporting infrastructure and third-party services that affect the CDE or PCI DSS controls. PCI SSC FAQ 1317 provides additional, older supplemental context on the concept of a significant change.

• New or materially changed hardware, software or networking components in or supporting the CDE.
• Major upgrades or replacements that materially change how in-scope systems operate or are protected.
• Changes to account-data flow, processing or storage.
• Changes to CDE boundaries, segmentation assumptions or PCI DSS assessment scope.
• Changes to supporting security or infrastructure services, including identity, logging, monitoring or time services.
• Changes to third-party providers or services that support the CDE or perform PCI DSS control functions on the entity's behalf.

Not every change is automatically significant. PCI SSC is clear that significance depends on the environment. The defensible approach is to evaluate changes against documented criteria when they happen, rather than waiting until the annual assessment and deciding retrospectively whether testing should have been triggered.

11.4.4: finding the weakness is only half the job

Requirement 11.4.4 closes one of the most common gaps in compliance-driven testing. Exploitable vulnerabilities and security weaknesses found during the penetration test must be corrected in line with the entity's assessment of risk under Requirement 6.3.1, and penetration testing must be repeated to verify the corrections. (PCI DSS v4.0.1, Requirement 11.4.4.)

That makes retesting part of the compliance evidence, not an optional commercial add-on. A ticket marked resolved is not the same as technical confirmation that the exploit path has been closed.

The wording also deserves precision. The requirement refers to exploitable vulnerabilities and security weaknesses, with remediation prioritised through the entity's risk assessment. It should not be rewritten as a rule that every informational observation in a penetration test report must be closed before the engagement can support PCI DSS evidence.

Segmentation testing under 11.4.5 and 11.4.6

Segmentation is often where a PCI scope decision becomes financially significant. If an organisation relies on segmentation to keep systems outside the CDE, Requirement 11.4 requires technical testing of those controls.

For entities subject to 11.4.5, the standard is explicit. Segmentation testing has to satisfy all of the following elements:

• At least once every 12 months and after any changes to segmentation controls or methods.
• Cover all segmentation controls and methods in use.
• Follow the entity's defined penetration testing methodology.
• Confirm that the segmentation controls or methods are operational and effective and isolate the CDE from all out-of-scope systems.
• Confirm the effectiveness of any isolation used to separate systems with differing security levels, as referenced by Requirement 2.2.3.
• Be performed by a qualified internal resource or qualified external third party.
• Maintain organisational independence of the tester. The tester is not required to be a QSA or ASV.

(PCI DSS v4.0.1, Requirement 11.4.5.)

Service providers have the additional 11.4.6 requirement. Where segmentation is used, the segmentation controls and methods must be tested at least once every six months and after any changes. The testing must cover the full segmentation control set, confirm that the controls remain operational and effective, and be performed by a qualified independent internal or external resource. (PCI DSS v4.0.1, Requirement 11.4.6.)

A failed segmentation test does not create a magical new scope by itself. What it does is undermine the evidence being used to justify that the affected systems are out of scope. Until the segmentation issue is corrected and the isolation is successfully revalidated, the organisation cannot safely rely on that failed control to support the previous scope conclusion.

11.4.7: the multi-tenant service provider obligation

Requirement 11.4.7 applies only when the assessed entity is a multi-tenant service provider. That classification matters. Processing payments for customers does not, by itself, make every service provider subject to 11.4.7.

The requirement says multi-tenant service providers must support customers with external penetration testing under 11.4.3 and remediation verification under 11.4.4. They can do this by providing sufficient evidence that the required testing was performed on the customer's subscribed infrastructure, or by providing prompt access so the customer can perform its own external penetration test. (PCI DSS v4.0.1, Requirement 11.4.7.)

If results are shared, redaction is acceptable, but the evidence still needs to contain enough information to show that the applicable elements of 11.4.3 and 11.4.4 were met on the customer's behalf.

ASV scanning is not penetration testing

Requirement 11.3 vulnerability scanning and Requirement 11.4 penetration testing are separate PCI DSS controls. An Approved Scanning Vendor (ASV) performs the required external vulnerability scans under Requirement 11.3.2. A clean ASV scan does not satisfy Requirement 11.4, and a penetration tester does not need to be an ASV.

PCI SSC guidance is explicit that vulnerability scanning alone is not a penetration test. It also warns against treating a pentest as nothing more than an attempt to exploit whatever a scanner happened to find. A competent tester uses reconnaissance, manual analysis and the defined methodology to look for security gaps that may never appear in automated scan output. PCI SSC Penetration Testing Guidance.

If you are working through quarterly external scanning as well, see RedSecLabs' PCI DSS ASV scanning requirements guide for the separate Requirement 11.3 obligations. For a framework comparison, our SOC 2 and ISO 27001 penetration testing guide explains where those assurance models differ from PCI DSS.

When might a QSA conclude the penetration test is not sufficient?

A QSA does not simply approve a pentest supplier or accept a report because it is labelled “PCI”. The assessor has to determine whether the evidence demonstrates that the applicable Requirement 11.4 controls were met. A technically useful security test can therefore still be insufficient PCI DSS evidence.

• The engagement was essentially a fully automated vulnerability scan with little or no manual exploitation, attack-path analysis or tester-led validation. PCI SSC describes penetration testing as a highly manual process; scanning alone is not a penetration test.
• The scope covered only the public website or a list of external IP addresses, while material APIs, administrative interfaces, internal paths, critical systems or other parts of the CDE perimeter were omitted.
• The report does not demonstrate both required testing perspectives: external testing from public network infrastructure and internal testing from inside the CDE and into the CDE from relevant trusted and untrusted internal networks.
• Application-layer or network-layer testing is missing, or the documented methodology does not map to the nine elements required by 11.4.1.
• Segmentation is being relied on to keep systems out of PCI DSS scope, but the segmentation controls and methods were not specifically tested, were tested from the wrong locations, or do not demonstrate that the CDE is isolated from all relevant out-of-scope systems.
• A significant infrastructure or application change occurred after the annual test and there is no documented assessment or additional penetration testing where required.
• Exploitable vulnerabilities or security weaknesses were marked remediated without a penetration retest that verifies the correction.
• Tester competence or organisational independence cannot be demonstrated, particularly where an internal team tested controls for which it has operational responsibility.
• The report and supporting records are too thin to evidence scope, dates, methodology, testing perspective, findings, remediation and retest activity, or the prior 12 months of retained results.

The distinction from ASV scanning is important. An ASV result answers the separate Requirement 11.3 external scanning obligation. Requirement 11.4 asks whether defences were actively tested through a documented penetration-testing methodology. Passing one does not substitute for the other.

What evidence should be ready for your QSA?

The cleanest PCI penetration tests are scoped with the assessment evidence in mind before testing starts. That does not mean testing for the auditor instead of the attacker. It means making sure the technical work leaves a defensible record that shows what was tested, from where, under which methodology, what was found, and how remediation was verified.

• The documented penetration testing methodology, including the nine 11.4.1 elements.
• A clearly defined CDE perimeter, critical systems and testing scope, including documented exclusions and the reason for them.
• Evidence showing internal and external testing was performed from the required perspectives.
• The date of the test and evidence that the annual cadence, and any significant-change triggers, were met.
• Tester qualifications and a defensible statement of organisational independence.
• Application-layer and network-layer coverage appropriate to the in-scope technologies.
• Evidence that threats and vulnerabilities experienced during the prior 12 months were considered.
• Findings with enough technical evidence to show what was exploitable and why it mattered.
• Remediation records and retest results for exploitable vulnerabilities and security weaknesses.
• Segmentation test results where segmentation is being used to reduce PCI DSS scope.
• At least 12 months of retained penetration test and remediation evidence.

The exact evidence set depends on the environment and assessment route, but the standard's own testing procedures repeatedly direct QSAs to examine the methodology, scope of work, recent test results, segmentation controls and remediation evidence, and to confirm tester qualification and independence. (PCI DSS v4.0.1, Requirement 11.4.)

Common reasons PCI DSS penetration tests fail assessor review

The issues we see are usually less dramatic than a missing test. More often, a reasonable engagement leaves one or two unanswered questions that become important during assessment.

• The public web application was tested, but the API, administrative interface or connected CDE system was not included.
• The report says the test followed OWASP or another methodology, but does not show how the required PCI DSS coverage was mapped.
• Internal and external testing are presented as one generic engagement with no clear evidence of the testing perspective.
• A significant change happened after the annual test, but nobody assessed whether it triggered additional testing.
• Segmentation was assumed because firewall rules existed, but the controls were not tested from the relevant out-of-scope networks.
• The original report is detailed, but there is no formal retest evidence after remediation.
• The test was performed internally, but tester independence and qualification were never documented.
• The organisation cannot produce the prior 12 months of test and remediation evidence when the assessor asks for it.

None of these are reasons to turn a pentest into paperwork. They are reasons to scope it properly at the start. RedSecLabs has written separately about why penetration testing scope matters. The same evidence and scoping problems also show up in common PCI DSS assessment failures, particularly when scope, ASV activity and segmentation evidence do not agree.

How RedSecLabs approaches PCI DSS Requirement 11.4

RedSecLabs is a PCI SSC-listed Qualified Security Assessor Company and a CREST member company with Penetration Testing listed as a CREST specialism. This combination matters for Requirement 11.4 because the engagement has to work in two directions at once: it must be technically meaningful against the real attack surface, and the scope, methodology, evidence and retesting must also stand up during PCI DSS assessment. For procurement verification, PCI SSC lists the legal entity as REDSECLABS LIMITED in its Qualified Security Assessor directory.

We scope the test against the actual CDE, critical systems, internal and external attack paths, segmentation controls and any applicable service-provider obligations before execution begins. The testing is manual and intelligence-led, with application, API and network coverage selected according to the environment rather than a generic template. For organisations that already know they need testing, our penetration testing services set out the broader technical engagement options.

Retesting of remediated findings is included within the agreed engagement window so that teams can close the technical issue and retain evidence that the fix was verified. Where RedSecLabs is also engaged for formal PCI DSS validation, we handle assessor independence and separation of duties in line with the applicable QSA Programme requirements. RedSecLabs PCI DSS services.

Need to scope a PCI DSS 11.4 penetration test?

Get a PCI DSS 11.4 testing scope and fixed quote through the Penetration Testing Estimator.

Frequently asked questions

Q1: How often does PCI DSS require penetration testing?

Ans: Internal and external penetration testing must be performed at least once every 12 months and after any significant infrastructure or application upgrade or change. If segmentation is used to isolate the CDE, segmentation testing is required at least every 12 months under 11.4.5, and at least every six months for service providers under 11.4.6.

Q2: Does a PCI DSS penetration tester need to be a QSA or ASV?

Ans: No. Requirements 11.4.2, 11.4.3, 11.4.5 and 11.4.6 allow a qualified internal resource or qualified external third party. The standard explicitly states that the tester is not required to be a QSA or ASV, but organisational independence is required.

Q3: Can an internal security team perform the PCI DSS penetration test?

Ans: Yes, provided the internal resource is qualified and organisational independence can be demonstrated. An external supplier is not mandatory simply because the test supports PCI DSS.

Q4: Does PCI DSS Requirement 11.4 require authenticated testing?

Ans: Requirement 11.4 does not use authenticated penetration testing as a standalone requirement. It does require meaningful application-layer coverage and testing of the relevant CDE perimeter and critical systems. Where in-scope functionality exists behind authentication, suitable accounts or roles may be necessary to achieve adequate coverage.

Q5: Does a clean ASV scan satisfy Requirement 11.4?

Ans: No. Vulnerability scanning is addressed under Requirement 11.3. Penetration testing is a separate control under Requirement 11.4 and is a highly manual process that attempts to exploit vulnerabilities and security weaknesses.

Q6: What happens if a penetration test finds exploitable vulnerabilities?

Ans: Under 11.4.4, exploitable vulnerabilities and security weaknesses must be corrected in accordance with the entity's risk assessment under Requirement 6.3.1, and penetration testing must be repeated to verify the corrections.

Q7: What counts as a significant change for PCI DSS pentesting?

Ans: PCI DSS v4.0.1 guidance gives examples including material changes to CDE hardware, software or networks, account-data flows, CDE boundaries, supporting infrastructure and third-party services that affect the CDE or PCI DSS controls. Whether a change is significant still depends on the entity's environment and must be evaluated in context.

Q8: When can a QSA reject or challenge a PCI DSS penetration test?

Ans: A QSA may conclude that Requirement 11.4 is not met where the evidence does not demonstrate the required methodology, scope, testing perspectives, tester qualification and independence, remediation retesting or segmentation validation. Common examples include scan-only engagements, incomplete CDE coverage, missing internal testing, untested segmentation controls and absent retest evidence. A clean ASV scan does not cure these gaps because ASV scanning sits under Requirement 11.3, not 11.4.

Q9: What should a PCI DSS penetration test report include?

Ans: The report and supporting evidence should make the scope, testing perspectives, methodology, dates, tester qualification and independence, application- and network-layer coverage, findings, segmentation results where applicable, and remediation retest status clear enough for the assessment route being used. The exact format is not prescribed, but the evidence should allow the entity and QSA to demonstrate that the applicable parts of Requirement 11.4 were met.

www.redseclabs.com

Media enquiries
[email protected]
+44 20 3996 1505