PCI DSS penetration testing requirements

PCI DSS is unusual among the standards a growing company meets, in that it does not leave testing to interpretation. Requirement 11 covers testing the security of systems and networks, and within it requirement 11.4 is penetration testing specifically. It is written as a set of sub-requirements with defined approach testing procedures behind each one, which means a QSA is checking named things rather than forming a general impression.

Two boundaries are worth fixing before reading any of it. The first is that penetration testing under 11.4 is separate from vulnerability scanning under 11.3, which has its own cadence and, for external scans, has to be performed by an Approved Scanning Vendor. Passing your quarterly scans is not an answer to 11.4 and never has been. If that distinction is still fuzzy in your organisation, the comparison of testing against scanning is the shortest way to settle it.

The second is scope. The cardholder data environment is made up of the systems that store, process or transmit account data, together with systems connected to them or that could affect their security. Requirement 11.4 applies to the CDE perimeter and the critical systems within it, so the practical question at scoping time is always which systems are in the CDE and what sits next to them. Getting that wrong is the most expensive mistake available here, because everything downstream inherits it.

This is the sub-requirement organisations most often fail on paper while passing in practice. The testing gets done properly and nobody ever wrote the methodology down, so there is nothing for a QSA to review. The methodology is a document you own, not something your testing supplier owns on your behalf, although a good supplier will provide the technical part of it.

What the methodology has to address

• Industry-accepted penetration testing approaches, named rather than implied.
• Coverage of the entire CDE perimeter and the critical systems inside it.
• Testing from both inside and outside the network.
• Testing that validates any segmentation and scope-reduction controls in use.
• Application-layer testing that covers, at minimum, the software attack techniques listed in requirement 6.2.4.
• Network-layer testing covering the components supporting network functions as well as the operating systems.
• Review and consideration of threats and vulnerabilities experienced in the last twelve months.
• A documented approach to assessing and addressing the risk posed by exploitable vulnerabilities and security weaknesses found.
• Retention of penetration testing results and remediation activity results for at least twelve months.

The clause about the last twelve months is easy to skim past and is genuinely useful. It says the test should be informed by what actually happened to you: the incidents, the near misses, the vulnerabilities you had to patch in a hurry. A test scoped without reference to any of that is a generic test, and generic is exactly what the requirement is trying to prevent.

Requirement 6.2.4 sits in the software development section and enumerates the attack techniques that software engineering practices must prevent or mitigate in bespoke and custom software. Requirement 11.4.1 then points application-layer testing at that same list, which makes 6.2.4 the closest thing PCI DSS has to a required coverage list for application testing.

• Injection attacks, including SQL, LDAP and XPath, and other command, parameter, object, fault or injection-type flaws.
• Attacks on data and data structures, including attempts to manipulate buffers, pointers, input data or shared data.
• Attacks on cryptography usage, including attempts to exploit weak, insecure or inappropriate cryptographic implementations, algorithms, cipher suites or modes of operation.
• Attacks on business logic, including attempts to abuse or bypass application features through manipulation of APIs, communication protocols and channels, client-side functionality or other application functions and resources.
• Attacks on access control mechanisms, including attempts to bypass or abuse identification, authentication or authorisation, or to exploit weaknesses in how they are implemented.
• Attacks via any high-risk vulnerabilities identified in the vulnerability identification process defined in requirement 6.3.1.

Two of those categories are the reason automated tooling cannot satisfy this on its own. Business logic abuse and access control bypass both require somebody who understands what the application is supposed to permit, because a scanner sees two well-formed requests and has no basis for deciding that one of them should have been refused. That is the same argument set out in more depth in the comparison between manual testing and scanning, and it is why application testing and API testing are usually both in scope where a payment flow is involved.

These two are deliberately separate because they answer different questions. External testing asks what somebody on the internet can reach and do. Internal testing asks what somebody who is already inside the network, whether an attacker who got a foothold or an employee who should not have that access, can reach and do. Passing one says nothing about the other, and a great many organisations have a strong perimeter and a flat internal network behind it.

Who is allowed to perform them

The standard requires a qualified internal resource or a qualified external third party, with organisational independence of the tester. Independence here does not require the tester to be an employee of a different company: it requires that they are not the person who built or operates the system being tested. Notably, the tester does not have to be a QSA or an ASV. That is a common misreading, and it costs organisations money by narrowing the supplier list unnecessarily.

What counts as a significant change

The standard does not enumerate this, which means you have to define it and be able to defend the definition. A workable definition includes a new or substantially modified application in the CDE, a change to the network architecture or to the components enforcing segmentation, a new system component added to the CDE, an upgrade to an operating system or platform underneath it, and a move to a new hosting arrangement or data centre. Write it down in your methodology, because a QSA will ask how you decide when the after-a-change test is triggered.

This sub-requirement is short and has more teeth than any of the others. Exploitable vulnerabilities and security weaknesses found during penetration testing are to be corrected in accordance with the entity assessment of the risk posed, as defined in requirement 6.3.1, and penetration testing is repeated to verify the corrections.

Two things follow. First, remediation is judged against your own documented risk process rather than against a fixed severity threshold, so that process needs to exist and needs to be applied consistently. Second, and this is the part that costs money in the traditional delivery model, verification is a repeat test rather than a statement from your engineering team that the issue is fixed. Where retesting is quoted as separate work it frequently does not happen, which is precisely the gap this sub-requirement closes. Retests are included in our engagements and the outcome is recorded as a tester verdict, either verified or failed with a reason.

Segmentation is how most organisations keep PCI DSS scope manageable. If the systems handling account data are isolated from the rest of the estate, the rest of the estate falls outside the assessment. That is a large financial saving, and it is entirely dependent on the isolation actually working, which is why the standard requires it to be tested rather than asserted.

What segmentation testing actually involves

It is a different exercise from an application test. The tester places themselves in each out-of-scope network segment in turn and attempts to reach systems in the cardholder data environment, enumerating what is permitted through the controls and confirming that nothing beyond the documented exceptions gets through. The output is a statement about isolation: which paths exist, which are intended, and whether any unintended path was found.

• All segmentation controls and methods in use are covered, not a sample of them.
• Testing confirms the controls are operational and effective and isolate all out-of-scope systems from systems in the CDE.
• Performed by a qualified resource with organisational independence.
• Repeated after any change to segmentation controls or methods, in addition to the periodic cycle.
• At least once every twelve months for merchants, and at least once every six months for service providers under 11.4.6.

The six-month cycle for service providers is the single most commonly missed obligation in this part of the standard, usually because an organisation classified as a service provider is still working to a merchant calendar. If you process, store or transmit account data on behalf of another entity, or you could affect the security of another entity cardholder data, check your classification before you build the testing schedule. Our network testing service covers segmentation work, and the payments sector page has more on the surrounding surface.

• The documented methodology, and evidence that the testing performed followed it.
• The internal and external test reports, dated, covering the CDE perimeter and critical systems.
• Evidence of the tester qualifications and of their organisational independence.
• The segmentation test report, on the correct cycle for your classification.
• Remediation records for exploitable findings, assessed against your documented risk process.
• Retest evidence showing corrections were verified rather than asserted.
• Twelve months of retained results, covering both testing and remediation activity.
• Your definition of significant change, and evidence that a test followed one where a significant change occurred.

Reports produced from our engagements can be exported against PCI DSS requirement areas, with findings grouped under them and the software weakness classes from 6.2.4 reflected in the mapping. As with every framework export, a penetration test is evidence that may support an assessment. It is not a certification or an attestation, and your QSA decides what satisfies the standard. There is more detail on how the framework exports work.

1. 1Treating quarterly ASV scanning as though it covers 11.4. It covers 11.3. They are separate requirements with separate evidence.
2. 2Skipping segmentation testing because the annual penetration test touched the network. Segmentation testing is its own sub-requirement with its own scope and its own report.
3. 3A service provider working to the twelve-month segmentation cycle instead of six months.
4. 4No documented methodology, so the testing cannot be shown to have followed one.
5. 5No definition of significant change, so the after-a-change trigger is never demonstrably met.
6. 6Correcting findings and never repeating the test, which leaves 11.4.4 half satisfied.
7. 7Scoping the test to the payment application and omitting the connected systems that could affect the security of the CDE.
8. 8Discarding evidence before the twelve months are up, particularly the remediation records rather than the report itself.