Four passing ASV scans do not satisfy Requirement 11.4. They satisfy Requirement 11.3.2, which is a different obligation with a different method, a different frequency and a different person allowed to sign it.
The two get conflated constantly, usually by somebody who has just paid for the scan and assumes the testing box is ticked. This article sets out what PCI penetration testing actually requires, sub-requirement by sub-requirement. It also covers where the scan stops and the test begins, and the clause about significant changes that quietly turns an annual exercise into several.
- A vulnerability scan is automated and looks for known issues. A penetration test is a person trying to break in.
- Internal and external tests are both required, at least every 12 months and after any significant change.
- If you use segmentation to reduce scope, that segmentation needs its own test. Service providers test it every six months.
- The tester needs organizational independence. A developer testing their own application does not qualify.
- Exploitable findings must be fixed and retested. An unretested fix is an open finding.
Where the ASV scan stops and PCI penetration testing begins
Requirement 11.3.2 asks for external vulnerability scans at least every three months, performed by an Approved Scanning Vendor listed with the Council. The scan is automated. It compares what it can see against a database of known vulnerabilities and produces a pass or fail against defined criteria.
Requirement 11.4 asks for something else entirely: a human being following a documented methodology, chaining weaknesses together, and attempting to reach the cardholder data environment.
A scanner reports that a service is running an outdated version. A tester uses that service to get a shell, pivots to a file server, finds credentials in a script and logs into the database. Only one of those tells you what an attacker would actually achieve.
Both are mandatory. Neither substitutes for the other, and an assessor will ask for both sets of evidence separately.
Requirement 11.4, sub-requirement by sub-requirement
- 11.4.1 Methodology. Defined, documented and implemented, based on an industry-accepted approach. It has to cover the entire perimeter of the cardholder data environment and critical systems. It also has to test from inside and outside the network, include application-layer and network-layer testing, and account for the threats behind Requirement 6. Results and remediation are retained for at least 12 months.
- 11.4.2 Internal testing. Performed per that methodology, at least once every 12 months and after any significant infrastructure or application change, by a qualified resource with organizational independence.
- 11.4.3 External testing. The same, from outside.
- 11.4.4 Correct and retest. Exploitable vulnerabilities and security weaknesses are corrected according to your risk assessment, and the testing is repeated to verify the correction.
- 11.4.5 Segmentation testing. If segmentation isolates the cardholder data environment, it is tested at least once every 12 months and after changes to segmentation controls. The test covers every method in use, and is performed by a qualified resource with organizational independence.
- 11.4.6 Service providers. The same segmentation testing, at least once every six months.
- 11.4.7 Multi-tenant service providers. Support your customers in performing their external testing under 11.4.3 and 11.4.4.
The significant change clause that catches people out
Annual testing is easy to plan. The words after it are not, because they turn PCI penetration testing from a date in the calendar into something event-driven.
The standard does not hand you a list of what counts. You have to define it, and your definition has to be defensible. A new public-facing application is a significant change. So is a cloud migration, a major network redesign, or adding a new data center into scope.
Write the definition down before you need it. The organization that defines significant change during the assessment is negotiating under pressure, and the assessor has seen that conversation before.
Segmentation testing is its own test
This is the most commonly missed piece of PCI penetration testing, because segmentation feels like an architecture decision rather than a control to be tested.
If you have told your assessor that a network is out of scope because it is segmented, you are making a claim that has to be proved. The test tries to reach the cardholder data environment from every out-of-scope network and confirms that it cannot. It checks that the segmentation methods actually in use are the ones documented, which is where drift shows up.
Merchants do this every 12 months. Service providers do it every six. If you are a service provider who also acts as a merchant, the shorter interval wins.
Who is allowed to perform it
The standard does not require a specific certification. It requires two things that are easier to assess honestly.
- 1 Qualified. Demonstrable skill and experience in penetration testing, which in practice means a CV, past reports, and recognized credentials. An internal resource can qualify.
- 2 Organizationally independent. The tester does not report into the team that built or runs the thing being tested. An internal team can satisfy this if the reporting lines are genuinely separate.
The second one is where internal programs usually fail. If the person testing the application sits in the team that wrote it, the finding is not that the test was bad. The finding is that it does not count.
What the report has to contain
An assessor reads the report as evidence, not as a security document. These are the parts they look for, and the parts most reports are thin on.
- The scope tested, stated explicitly, with the addresses and applications in it.
- The methodology followed, and which industry-accepted approach it is based on.
- The dates the testing was performed. Not the date of the report.
- The tester’s qualifications and a statement of organizational independence.
- Findings with enough detail to show exploitability, not just a scanner severity rating.
- Evidence of remediation and the retest that confirmed it.
The four PCI penetration testing failures that cost a quarter
- 1 No retest. The test found something exploitable, the team fixed it, and nobody ran 11.4.4. The finding stays open on paper.
- 2 Scope smaller than the CDE perimeter. The test covered the web application and not the connected systems that can reach it.
- 3 Segmentation never tested. Scope reduction claimed, never proved.
- 4 A test that is really a scan. An automated tool run with a report cover on it. An assessor can tell within two pages.
Where we fit
The quarterly external scan under 11.3.2 can only be attested by a listed Approved Scanning Vendor. Nordstern holds that listing with global scope, certificate 50955001-01, and the scan has pass criteria of its own that are a frequent source of lost quarters.
For 11.4 itself, the testing work sits with adversary simulation and red teaming, and the remediation cycle behind 11.4.4 with vulnerability and exposure management. If you are still working out how much of the standard applies to you, start with the checklist organized around evidence and with PCI DSS consulting. Talk to the team.
Sources
- PCI Security Standards Council, document library: PCI DSS v4.0.1, Requirements 11.3 and 11.4, and the Penetration Testing Guidance information supplement.
