PCI DSS Penetration Testing Requirements, in Plain Terms

PCI DSS requires internal and external penetration testing at least annually and after any significant change, following a documented methodology, covering the cardholder data environment perimeter and critical systems at both network and application layer, with segmentation tested and exploitable findings fixed and retested. Unlike most standards, which ask you to manage risk and leave the method to you, it names penetration testing outright, and it is where the "annual test" convention everyone else quotes came from.

What the requirement asks for

Requirement 11.4 covers penetration testing in PCI DSS v4.0.1, the current version, published by the PCI Security Standards Council in June 2024. Version 4.0 was retired on 31 December 2024, and the requirements version 4 introduced as future-dated became effective on 31 March 2025, so anything your last assessment treated as best practice is now assessed. The substance of the testing requirement is consistent with what requirement 11.3 asked in version 3.2.1. In plain terms it requires:

• A defined methodology, written down, that your testing follows.
• External and internal penetration testing, both, as described in internal or external penetration testing.
• Testing at least annually, and after any significant change to infrastructure or applications.
• Coverage of the entire cardholder data environment perimeter and any critical systems.
• Application-layer and network-layer testing.
• Correction of exploitable vulnerabilities and repeat testing to verify the correction.
• Retention of the results and the remediation record.

The last two are what separate PCI from the standards that merely encourage testing. Finding the issue is not the requirement. Fixing it and proving the fix is.

Significant change is the phrase that catches people

Annual is the floor, not the schedule. A significant change to the environment restarts the clock for the affected parts, and organisations shipping continuously find that their idea of significant and their assessor’s differ.

The workable answer is to define it yourself, in writing, before anybody asks: a new system in scope, a change to the segmentation, a new payment flow, an upgrade of a component in the cardholder path. Then test against your own definition and you are auditing to a standard you set rather than arguing about one you did not.

Who is allowed to do it

PCI does not require a QSA to perform the testing. It requires organisational independence from the people who manage the systems, and a tester with appropriate qualification and experience. An internal team can satisfy that if it does not report to the team that built or runs the environment.

In practice many organisations use an external firm for the external test and for segmentation testing, because independence is easier to evidence and because a customer or acquirer often expects it regardless of what the standard says.

Scope, and the reason it is bigger than people expect

The cardholder data environment is not only the systems that store card numbers. It includes systems that process or transmit them, and any system connected to or able to affect the security of those systems. That last clause is where assessments go wrong: a jump host, a monitoring agent, a directory service or a CI pipeline with access can pull a system into scope even though no card number ever touches it.

Draw the diagram before scoping the test rather than after, and have the tester state in the report which parts of it were covered. An assessor comparing a scope diagram against a test scope is a routine exercise and a mismatch is a routine finding.

Application-layer testing is a separate obligation

The requirement asks for network-layer and application-layer testing, and organisations with a small cardholder environment often satisfy the first and assume it covers the second. It does not. A network test of the hosts a payment page runs on says nothing about whether the payment page itself can be manipulated.

If cardholder data passes through an application you wrote, that application needs testing at the application layer, with authenticated roles, in the same cycle. Where you have outsourced payment entry to a hosted page, the scope shrinks considerably, but the integration point does not disappear: how your application redirects to that page, and what it trusts on the way back, remains yours.

The methodology requirement is not decoration

PCI asks for a documented methodology that the testing follows, and assessors do ask to see it. It does not need to be long. It needs to say which industry approach you follow, what is in scope, how coverage is decided, how findings are rated, and how retesting works.

The efficient move is to adopt your tester’s methodology and reference it, rather than writing one that describes something nobody does. What fails an assessment is a methodology that says one thing and reports that show another.

What to keep

The report itself, the methodology it followed, evidence that exploitable findings were corrected, the results of the repeat testing, and the dates of all of it. Keep it for at least the retention period your programme requires and expect to be asked for the previous cycle as well as the current one.

The most common gap is not the absence of a test. It is a test with no corresponding retest evidence, which leaves a documented list of exploitable weaknesses and nothing showing they were addressed. That is worse than not having tested, and it is entirely avoidable if the retest is run properly.

If you are not in scope for PCI

Requirement 11.4 is still the best free specification of what a testing programme should look like. Annual as a floor, after significant change, internal as well as external, application as well as network, and a retest that proves the fix. Adopting that shape without the certification is a defensible position under almost any other framework, including ISO 27001 and SOC 2, neither of which prescribes a frequency of its own.