ASV scan, internal scan, penetration test: three PCI DSS requirements, no substitutes

They are three obligations, not three names for one. PCI DSS v4.0.1 puts internal vulnerability scanning at Requirement 11.3.1, external vulnerability scanning at 11.3.2 and penetration testing at 11.4. Each has its own frequency, its own remediation bar and its own rule about who may perform it. Discharging one contributes nothing towards another, and an assessor examines a different artefact for each.

Only one of them is closed to you. Requirement 11.3.2 — the quarterly external scan — must be performed “By a PCI SSC Approved Scanning Vendor (ASV)”, a phrase that appears in exactly one defined-approach requirement in the entire standard. Everything else in Requirement 11, including the external scan performed after a significant change, is open to any qualified party with organisational independence.

The three requirements side by side

Three clocks, and three definitions of “fixed”: rankings you wrote yourself under 6.3.1 for the internal scans, a CVSS threshold of 4.0 after a significant change, and, for the quarterly external scan, a rulebook you do not write. One remediation policy does not cover all three.

Why a scan and a penetration test are not substitutes

The standard settles this in its own guidance to 11.4.1: “Scanning for vulnerabilities alone is not a penetration test, nor is a penetration test adequate if the focus is solely on trying to exploit vulnerabilities found in a vulnerability scan.” The accompanying definition draws the line at exploitation — a penetration test “is an active process that usually includes exploiting identified vulnerabilities”.

The clearest tell is what each produces. An ASV scan resolves to a passing or failing result under the Program Guide. A penetration test does not, and the standard says so: “A penetration test is not truly a ‘test’ because the outcome of a penetration test is not something that can be classified as a ‘pass’ or a ‘fail.’” It adds, usefully for anyone reviewing a report, that “a penetration test that found nothing is typically indicative of shortcomings of the penetration tester”.

Requirement 11.3.2 is the only locked door

Two things make 11.3.2 unlike anything else in Requirement 11. It names the ASV in the requirement text, and it is the only requirement in the whole of Requirement 11 declared “not eligible for the customized approach” — there is no alternative route to meeting it. Testing procedure 11.3.2.c closes the loop: the assessor must “examine the ASV scan reports to verify that the scans were completed by a PCI SSC Approved Scanning Vendor (ASV)”.

ASV status is held by a company, its named employees and its specific scan solution, all listed by PCI SSC. The ASV Qualification Requirements put the consequence plainly: “If a security company is not on this list, its work product is not recognized by PCI SSC.” A report from a firm not on that list does not satisfy 11.3.2, however good the scan was. Check the list, and check that the solution being sold to you is the listed one. More on the role in what an ASV does, and why 11.3.2 admits nobody else.

The exception: 11.3.2.1 is not ASV-gated

The quarterly external scan is ASV-exclusive. The external scan required after a significant change is not. Verbatim from v4.0.1:

“11.3.2.1 External vulnerability scans are performed after any significant change as follows: Vulnerabilities that are scored 4.0 or higher by the CVSS are resolved. Rescans are conducted as needed. Scans are performed by qualified personnel and organizational independence of the tester exists (not required to be a QSA or ASV).”

That parenthesis appears six times in v4.0.1 — at 11.3.1.3, 11.3.2.1, 11.4.2, 11.4.3, 11.4.5 and 11.4.6. It is the standard stating, repeatedly, that the gate on testing is competence and independence, not a PCI SSC credential.

It matters most at the small end. The SAQ Instructions and Guidelines (v4.0.1 r1, April 2025) record that “to mitigate these common breaches, Requirements 11.3.2 and 11.3.2.1 are included in SAQ A” — the questionnaire for the fully outsourced e-commerce merchant, including one whose page only redirects to a compliant third-party service provider or embeds its payment form in an iframe. The smallest merchant in the standard now carries two external scanning obligations on different terms, and only one of them needs an ASV. Which questionnaire you file is itself a scoping decision: see which SAQ applies to you.

Three of these hang on “significant change”

11.3.1.3, 11.3.2.1 and the change trigger inside 11.4.2 and 11.4.3 fire on the same event. The standard gives a minimum list of what must at least be evaluated as one:

• New hardware, software or networking equipment added to the CDE
• Any replacement or major upgrade of hardware or software in the CDE
• Any change in the flow or storage of account data
• Any change to the boundary of the CDE or to the scope of the assessment
• Any change to the supporting infrastructure of the CDE — directory services, time servers, logging, monitoring
• Any change to third-party vendors or service providers supporting the CDE, or meeting requirements on your behalf

Two details are easy to miss. v4.0 split the old post-change scanning requirement in two: the Summary of Changes records that v3.2.1's Requirement 11.2.3 became “a requirement for internal scans (11.3.1.3) and external scans (11.3.2.1)”, so one scan after a migration does not close both. And authenticated scanning — mandatory for quarterly internal scans under 11.3.1.2 since 31 March 2025 — is expressly not required for the post-change internal scan.

What Requirement 11.4 asks for that no scanner produces

11.4.1 requires a documented methodology the entity itself implements: industry-accepted approaches, coverage of the entire CDE perimeter and critical systems, testing from inside and outside the network, validation of segmentation and scope-reduction controls, application-layer testing for at least the vulnerabilities at 6.2.4, network-layer testing, review of threats experienced in the last 12 months, a documented approach to assessing and addressing the risk posed by what is found, and retention of results and remediation evidence for at least 12 months.

Then 11.4.4 closes it: exploitable findings are corrected per your 6.3.1 risk assessment and “penetration testing is repeated to verify the corrections”. A test with no retest is an unfinished requirement, and one of the commonest reasons a PCI penetration test report is sent back. Service providers run segmentation testing six-monthly under 11.4.6 rather than annually, a cadence that reshapes the engagement calendar and is routinely discovered late; multi-tenant providers carry 11.4.7 on top, and cannot forbid their customers from testing. This is the work Security Brigade does — penetration testing scoped to Requirement 11.4, with the segmentation and retest evidence a QSA will ask to see.

Four conflations worth pricing out

• “Our ASV scan passed, so 11.4 is covered.” Different requirement, different evidence, different assessor procedure: 11.3.2.a examines ASV scan reports, 11.4.2.a examines the scope of work and results of the penetration test.
• “Our external penetration test covered the perimeter, so we can skip a quarter.” 11.3.2 is quarterly, ASV-only and closed to the customised approach. There is no argument available.
• “We used a QSA, so the testing is qualified.” No requirement in Requirement 11 asks for a QSA; six say the opposite in parentheses. And a QSA is not an ASV unless that firm separately holds ASV qualification.
• “Our guide says penetration testing is 11.3.” It was, under v3.2.1, where external scanning sat at 11.2.2 and penetration testing at 11.3. v3.2.1 retired on 31 March 2024 and v4.0 on 31 December 2024; v4.0.1 is the only active version. See what Requirement 11.4 demands, and why you searched for 11.3.

The practical test is simple. Put the artefacts on one page — four quarterly ASV scan reports, four quarterly internal scan reports, the post-change scans tied to your change records, and the penetration test with its retest — and see which column is empty. It is rarely the one that was budgeted for.