ASV scan or penetration test? Which one PCI actually asks for

The short answer

An Approved Scanning Vendor scan is automated external vulnerability scanning, performed by a company the PCI Security Standards Council has approved, on a cadence the Council has published: at least once every three months. A penetration test is manual, adversarial work by an independent tester, on a cadence written into a part of the standard that is not publicly readable. You need both. They are not substitutes, and no supplier can sell you one as the other.

The rest of this guide sets out what each one is, quoting the Council wherever the wording matters, and marks clearly where the sourcing runs out.

What an Approved Scanning Vendor actually is

The PCI SSC glossary is terse about it: an ASV is a "Company approved by the PCI SSC to conduct external vulnerability scanning services." The Council's own programme page adds the mechanism, and the mechanism is the interesting part.

An ASV is an organization with a set of security services and tools ("ASV scan solution") to conduct external vulnerability scanning services to validate adherence with the external scanning requirements of PCI DSS Requirement 11.3.2. The scanning vendor's ASV scan solution is tested and approved by PCI SSC before an ASV is added to PCI SSC's List of Approved Scanning Vendors.PCI Security Standards Council, Approved Scanning Vendors programme page

Two things follow from that sentence. First, approval attaches to the scan solution, not just the company: a specific set of tools and methods was tested in a validation laboratory. Second, the approval is narrow. The Council states that approval and re-approval "indicate only that the applicable ASV has successfully met all PCI Security Standards Council requirements to perform PCI data security scanning, and the PCI Security Standards Council does not endorse these security solution providers or their business processes or practices."

Gill Woodcock, then the Council's VP Global Head of Programs, described the human side of it in 2020: candidates "must undergo rigorous testing of their scan solution with a validation laboratory approved by PCI SSC, and at least two employees of the candidate company must complete PCI SSC's ASV training course and pass the applicable exam", with an annual requalification. She also made clear that an ASV scan is not purely a button press: "Although ASVs can use commercially available third-party scan tools, they also use their own tools and methods such as custom scripts and manual analysis to help identify and report vulnerabilities."

How often, and what counts as passing

This is the one number on the whole subject that is unambiguous and publicly sourced. In its 2024 resource guide on vulnerability scans, the Council describes the requirement as follows: Requirement 11.3.2 "requires evidence of passing external scans, performed by an ASV, at least once every three months."

The Council's FAQ puts a boundary on what "every three months" tolerates. The intent is "to have them conducted as close to three months apart as possible", and "at least once every three months, or 90 days, is considered the maximum amount of time that should be allowed to pass between quarterly vulnerability scans." If something unforeseen delays a scan, the Council expects it performed "within a day or two" of the scheduled date, and it expects entities that know about a change freeze in advance to scan earlier rather than run past the limit.

Internal scanning runs on the same clock. The Council states that "to meet the vulnerability scanning requirements in PCI DSS Requirement 11, an entity is required to complete their internal and external scans, and perform any required remediation, at least once every three months."

What a clean scan looks like

A separate FAQ sets out the characteristics of a "clean" or "passing" scan, and the middle line is the one people quote at each other in meetings.

• No configuration or software was detected that results in an automatic failure, such as the presence of default accounts and passwords.
• For external scans, no vulnerabilities with a score of 4.0 or higher on the Common Vulnerability Scoring System.
• For internal scans, vulnerabilities are resolved by the entity according to PCI DSS Requirement 11.3.1.

Note the asymmetry. The external scan has a numeric bar. The internal scan does not: what satisfies it is that you fixed what it found. That is why an internal scanning programme with a large open backlog fails even though every individual report looks the same as last quarter's.

Four quarters, not four perfect reports

The Council is realistic about the fact that new vulnerabilities appear between the scan and the rescan. An entity has to be able to show that "clean" or "passing" scans were performed at least once every three months for the previous four quarters, for both external and internal environments, but it can do that with a collection of scans and rescans rather than one flawless sweep. What it cannot do is drift.

If, however, an entity does not have four passing scans for the last 12 months, performed at least once every three months, because they didn't schedule the scans properly, or the scans are incomplete, or the identified vulnerabilities have not been addressed from one period to the next, then the entity has not met the requirement.PCI Security Standards Council, FAQ 1152

The denial-of-service exception

One quirk worth knowing, because scanning vendors report it inconsistently. The Council has instructed ASVs, through the ASV Program Guide, that a denial-of-service finding "where the vulnerability has both a CVSS Confidentiality Impact of None and a CVSS Integrity Impact of None" must not be ranked as a failure. Availability matters to your business; it is not, on its own, a cardholder data exposure.

The scan applies even when you never touch a payment

This is the change that has caught the most merchants out, and it is recent. In PCI DSS v4.x, external ASV scanning was added to Self-Assessment Questionnaire A, the questionnaire used by merchants whose payment handling is fully outsourced.

ASV scan requirements in SAQ A apply only to an e-commerce merchant system(s) that hosts the webpage that either 1) redirects payment transactions to a PCI DSS compliant third-party service provider (TPSP) or 2) includes an embedded payment page/form from a PCI DSS compliant TPSP. The intent is for merchants to minimize the risk of compromise by scanning for and resolving identified vulnerabilities that could potentially expose their link to the TPSP's payment page.PCI Security Standards Council, ASV resource guide, July 2024

The Council's FAQ answers the question in one word. Do ASV scans in SAQ A apply to merchants whose pages redirect or embed? "Yes." It also states why the requirement was added: to "address risks where a merchant's webpage could be compromised and thereby result in compromise of the payment process." Your page is the thing an attacker edits in order to reach a payment that never passes through your systems.

The same period saw a change in the other direction. In January 2025 the Council removed Requirements 6.4.3 and 11.6.1 for payment page security, and Requirement 12.3.1 for the targeted risk analysis behind 11.6.1, from SAQ A, and added an eligibility criterion instead: the merchant must confirm their site "is not susceptible to attacks from scripts that could affect the merchant's e-commerce system(s)." The Council was explicit that this changes reporting, not the underlying obligation, and that "PCI SSC does not define compliance requirements for any organization or set compliance validation responsibilities."

What a penetration test is, and what this page will not tell you

A penetration test is a person, or a small team, working against your environment with the goal of reaching something they should not be able to reach. It differs from a scan in kind, not in thoroughness. A scanner reports that a component is at a version with a known issue. A tester reports that three individually unremarkable conditions can be chained into access to the cardholder data environment, and shows the steps.

PCI SSC's own material makes the point most clearly in the context of segmentation testing, where the temptation to substitute a scan is strongest. A QSA writing on the Council's blog put it like this:

This needs to involve more than just port scanning from outside network segments to determine if there are any open ports. It should test remote access mechanisms, try to hop through administrator workstations, and look at any shared services networks that might allow an attacker some advantage in getting into the in-scope environment.Jacob Ansari, QSA, published by PCI Security Standards Council

That is a deliberately unsatisfying answer, and it is more useful than a confident one. A merchant who cites a clause number they cannot produce, to an assessor who has the document open, is in a worse position than one who says "our QSA scoped this against the requirement and here is the report".

What each one is evidence for

Both artefacts are evidence, and each is evidence for a different, narrow thing. Buying one to satisfy a whole framework is the most expensive mistake available in a PCI programme.

Which artefact answers which question

Question an assessor asks	ASV scan	Penetration test
Is the internet-facing estate free of known, scored vulnerabilities?	Yes, this is exactly what it measures, against a published bar	Partly, and without a bar
Can an attacker actually get from the internet into the cardholder data environment?	No. A scan reports conditions, not consequences	Yes, and it shows the route it took
Does the segmentation boundary hold?	No. Open ports are one signal among several	Yes, if the engagement was scoped to test it
Is the scanning programme running on time?	Yes, the four quarters of reports are the evidence	No
Were the findings fixed?	Yes, through rescans that reach a pass	Yes, through a separately dated retest
Is the rest of the standard in place?	No, and the Council says so explicitly	No

What resets both clocks

Neither artefact ages purely by the calendar. Several PCI DSS requirements are triggered by a significant change, and the Council publishes the list of what counts, quoted from the "Description of Timeframes Used in PCI DSS Requirements" section of PCI DSS v4.0.

1. New hardware, software, or networking equipment added to the CDE.
2. Any replacement or major upgrades of hardware and software in the CDE.
3. Any changes in the flow or storage of account data.
4. Any changes to the boundary of the CDE and/or to the scope of the PCI DSS assessment.
5. Any changes to the underlying supporting infrastructure of the CDE, including changes to directory services, time servers, logging, and monitoring.
6. Any changes to third party vendors/service providers, or services provided, that support the CDE or meet PCI DSS requirements on behalf of the entity.

A team that migrates its logging pipeline in the second month of a quarter has made a change to the underlying supporting infrastructure of the cardholder data environment. Whether that obliges a rescan or a retest depends on the clause text; that it belongs in the change log is not in doubt.

Buying them well

Three practical points, none of which come from the standard and all of which come from watching the invoices.

• Buy the ASV scan from an ASV and nothing else from them. The scan is a commodity with a published pass mark. Bundling it with advisory work makes it harder to change vendor when the reporting gets sloppy.
• Scope the penetration test from your documented cardholder data environment, not from an asset list. If the two do not match, that mismatch is the first finding and it is free.
• Put the retest in the same purchase order as the test. A finding with no dated retest is an open finding for as long as the report exists, and buying the retest separately six weeks later costs more than including it.

For where the segmentation boundary fits into all of this, see segmentation testing. For who decides which document you file at the end of the year, see merchant levels and validation.