PCI DSS is more prescriptive about penetration testing than most frameworks, which cuts both ways. There is little ambiguity about what is required, and correspondingly little room to argue that what you did was close enough.
This guide covers what requirement 11.4 actually asks for under version 4.0, and the mistakes that most commonly cause problems at assessment.
The Core Requirement
PCI DSS requires a documented penetration testing methodology and its execution against a defined scope.
External penetration testing at least annually and after any significant change, covering the perimeter of the cardholder data environment from outside.
Internal penetration testing at least annually and after any significant change, covering the cardholder data environment from inside the network.
Application-layer and network-layer testing both, including the vulnerabilities listed in requirement 6.2.4, which covers the common application flaw classes.
Segmentation validation where segmentation is used to reduce scope: at least every twelve months for merchants, and at least every six months for service providers.
Remediation and retesting of exploitable vulnerabilities and security weaknesses found, with the retest documented.
The methodology itself must be documented and must be based on an industry-accepted approach, cover the entire perimeter and critical systems, and define the testing to be performed both from inside and outside the network.
Scanning Is a Separate Obligation
This is the most common misunderstanding and the easiest to avoid.
Requirement 11.3 covers vulnerability scanning: quarterly internal scans, quarterly external scans performed by an Approved Scanning Vendor, and rescanning after significant change until passing results are achieved.
Requirement 11.4 covers penetration testing, annually and after significant change.
They are different requirements, with different frequencies, satisfied by different activities. An organization that runs quarterly ASV scans and treats that as its testing program has met one requirement and missed the other. Assessors notice.
Who Can Perform It
The standard asks for a qualified internal resource or a qualified external third party, with organizational independence from the team that manages the tested systems.
Two things follow. First, no specific certification is mandated, so claims that a particular credential is required by PCI are marketing rather than fact. Second, internal teams may perform the testing, provided they are genuinely qualified and genuinely independent of the systems in scope. A team testing its own infrastructure does not satisfy the independence expectation.
What assessors do examine is evidence of qualification: relevant experience, methodology and the ability to demonstrate competence. Keep that documentation with the report.
Segmentation Validation, Specifically
This requirement causes more assessment problems than the rest of 11.4 combined, and the reason is what happens when it fails.
If you use segmentation to keep systems out of scope, the segmentation is doing significant work: it is the reason most of your estate is not subject to PCI DSS. Testing must confirm that the controls are operational and effective, and that no path exists from out-of-scope systems into the cardholder data environment.
When segmentation validation fails, the finding is not confined to itself. Everything the segmentation was supposed to exclude is now in scope, which can expand an assessment dramatically and late. Service providers face the six-month cycle precisely because the consequence is severe.
Test it properly: from every out-of-scope network segment, attempt to reach the cardholder data environment, and document what was attempted rather than only what succeeded.
Defining Significant Change
The standard requires testing after significant change and leaves the definition to you, which means you need one in writing that your assessor accepts.
A workable definition typically covers new infrastructure added to the cardholder data environment, substantial changes to applications handling card data, network topology or firewall rule changes affecting the environment boundary, operating system or platform upgrades on in-scope systems, and the addition of new components to scope.
Write it before you need it. Deciding retrospectively whether last quarter's migration was significant, while an assessor waits, tends to go badly.
Common Failures
- Scope drawn too narrowly. Testing the cardholder data environment while excluding connected systems that could affect its security. Connected-to systems are in scope, and this is a frequent finding.
- Segmentation asserted rather than tested. A diagram is not validation.
- No retest after remediation. The standard requires that exploitable findings be corrected and the correction verified. A report showing findings and no evidence of retest is incomplete.
- Testing performed too late in the compliance year. Leaving no time to remediate and retest before the assessment date is self-inflicted and common.
- Scan output presented as a penetration test. Covered above, and still the most frequent single error.
Using It Well
PCI DSS testing is a reasonable floor and a poor ceiling. A test scoped exclusively to satisfy requirement 11.4 will examine the cardholder data environment and stop, which tells you about compliance rather than about risk.
Most organizations get better value by scoping the engagement slightly wider than the standard requires, so the report answers both questions: whether the requirement is satisfied, and whether an attacker could reach the card data by a route the requirement did not contemplate. The incremental cost is usually modest compared with running two engagements.
To discuss a PCI DSS penetration test and segmentation validation, get in touch.
Frequently asked questions
How often does PCI DSS require penetration testing?
At least annually for both external and internal penetration testing, and additionally after any significant change to infrastructure or applications. Organizations using segmentation to reduce scope must also validate that segmentation at least every twelve months, or every six months for service providers. These are separate obligations from the quarterly vulnerability scanning requirement.
Who is allowed to perform a PCI penetration test?
The standard requires a qualified internal resource or a qualified external third party, with organizational independence from the team that manages the systems being tested. It does not mandate a specific certification. An internal team may perform the test provided they are qualified and independent of the systems in scope, which is a distinction assessors do examine.
What is segmentation validation and why does it matter?
If you use network segmentation to keep systems out of scope, you must prove the segmentation actually works. Testing confirms that no path exists from out-of-scope networks into the cardholder data environment. It matters because failed segmentation does not just produce a finding, it expands your assessment scope to include everything the segmentation was supposed to exclude.
Does a vulnerability scan satisfy the penetration testing requirement?
No. PCI DSS treats them as distinct requirements with distinct frequencies: quarterly scanning under requirement 11.3, with external scans by an Approved Scanning Vendor, and annual penetration testing under requirement 11.4. Submitting scan output where a penetration test was required is a common and entirely avoidable assessment failure.
What counts as a significant change requiring a new test?
The standard leaves this to the organization to define, which means you need a documented definition your assessor accepts. Typical triggers are new infrastructure in the cardholder data environment, a substantial application change, a network topology change, an operating system upgrade, or a new component added to scope. Define it in writing before you need it.