PCI-DSS
PCI-DSS Penetration Testing Requirements
The most prescriptive of the frameworks, and the one where a generic web application test most often fails to close the requirement. Requirement 11.4 asks for several distinct things.
- Scoped against Requirement 11.4 specifically
- Includes segmentation validation, not just application testing
- Methodology aligned to NIST SP 800-115
What Requirement 11.4 asks for
PCI-DSS treats penetration testing as several obligations rather than one. Buying "a penetration test" without reading the requirement is the most common way organisations arrive at an assessment with a gap.
- A defined methodology that is industry-accepted and documented, covering scope, testing approach and how findings are rated
- External penetration testing of the perimeter of the cardholder data environment
- Internal penetration testing from inside the network, which is frequently the part organisations omit
- Testing at least annually and after any significant change to infrastructure or applications
- Segmentation testing to confirm that systems outside the cardholder data environment cannot reach systems inside it
- Correction and retesting of exploitable vulnerabilities found, rather than reporting alone
- Coverage of the application layer as well as the network layer, including the risks in Requirement 6
Segmentation testing is separate, and it is where gaps appear
If you rely on segmentation to reduce your PCI scope — and almost everyone does, because the alternative is bringing the entire network into scope — then the effectiveness of that segmentation has to be demonstrated, not asserted.
This means testing from outside the cardholder data environment towards it, attempting to reach in-scope systems from out-of-scope networks. Service providers face a more frequent obligation here than merchants. A standard application penetration test does not produce this evidence, which is why organisations that bought one arrive at their assessment with a finding.
Scanning is not testing
Requirement 11.3 covers vulnerability scanning, including quarterly external scans performed by an Approved Scanning Vendor. Requirement 11.4 covers penetration testing. They are separate obligations satisfied by different work, and a passing ASV scan does not contribute to your penetration testing requirement.
Conversely, our penetration test does not replace your ASV scans, because those must be performed by an approved vendor. We will tell you plainly which of your obligations an engagement with us does and does not close.
What your assessor will ask for
- The documented methodology used, and evidence it is industry-accepted
- A scope statement identifying which systems were in scope and the basis for that scope
- Evidence of tester competence and organisational independence
- Results for external, internal and segmentation testing as distinguishable components
- Evidence that exploitable findings were corrected and retested, with dates
- The date of the test relative to your significant changes during the period
How we scope it
We start from your cardholder data flow and your current scope reduction argument, because those determine what has to be tested. Where your segmentation assumptions turn out to be weaker than believed, it is much better to learn that from us than from your assessor, and there is usually time to fix it.
Common questions
Does a PCI-DSS penetration test have to be performed by a QSA?
No. The penetration testing requirement does not mandate a Qualified Security Assessor, unlike the assessment itself. It requires a qualified, organisationally independent tester using a documented, industry-accepted methodology. Your assessor will review the tester's competence and independence as part of validating the evidence.
How often is segmentation testing required?
At least annually for merchants and at least every six months for service providers, and additionally after any change to segmentation controls. This is more frequent than the general penetration testing obligation, and the difference is a common source of findings.
Do our quarterly ASV scans cover the penetration testing requirement?
No. ASV scanning sits under Requirement 11.3 and penetration testing under 11.4. They are separate obligations: scanning is automated and quarterly, penetration testing is manual and at least annual, and each must be evidenced independently.
What counts as a significant change requiring a retest?
The standard leaves it to you to define and then holds you to your definition. In practice: new or modified network segmentation, a new system component in the cardholder data environment, an upgrade or replacement of infrastructure, a new application handling card data, or a change in hosting or cloud architecture. Write the definition down, because your assessor will ask which changes you assessed against it.
Does PCI-DSS apply if we use a hosted payment page?
It still applies, with a substantially reduced scope. Fully outsourcing card entry to a provider's redirect or iframe removes card data from your systems but not your obligations: the page that redirects, the systems that could alter it, and your segmentation all remain in scope. Reduced scope is the goal and it is worth confirming which self-assessment questionnaire you actually qualify for.
Do you test the cardholder data environment only, or everything connected to it?
Both, and the connected systems are the part teams underestimate. Any system that can affect the security of the cardholder data environment is in scope, which typically pulls in administrative jump hosts, monitoring, backup and identity infrastructure. Testing the environment while ignoring what can reach it produces evidence your assessor will question.
Can we use the same test for PCI-DSS and our other frameworks?
Usually yes, if the scope is drawn to cover what each framework cares about and the report maps findings to each set of control references. The PCI-specific requirements — internal, external and segmentation testing as distinguishable components — have to be met explicitly rather than assumed to fall out of a general application test.
Let's scope your infrastructure.
Tell us what you have built and what you are testing against. You will speak to a Lead Security Architect, not a sales desk, and you will get a written scope with a fixed price before any work begins.