PCI DSS SAQ Types Explained: Which One Actually Needs an ASV Scan?
PCI DSS SAQ types explained: compare SAQ A, SAQ A-EP, and SAQ D, and find out exactly which one requires a quarterly ASV scan. Get scan-ready today.
Most PCI compliance content out there answers one question: which ASV should I pick? That’s a fair question, but it skips over something worth understanding first: what the ASV Program actually is, who runs it, and what “approved” is supposed to guarantee.
The PCI-ASV Program is the certification system behind every name on the official scanning vendor list. It defines how a company earns the right to run PCI-recognized external vulnerability scans, what counts as a pass, who must comply, and what happens when a vendor or a scan falls short.
Understanding the program itself, separate from any single vendor’s marketing, makes it much easier to judge whether a scan report actually means what you think it does.
PCI SSC (PCI Security Standards Council): The body that owns, maintains, and enforces the ASV Program, along with PCI DSS itself.
ASV (Approved Scanning Vendor): A company whose external vulnerability scanning solution has been tested and approved by PCI SSC.
ASV Program Guide: The primary document defining how ASV scans must be scoped, executed, and reported.
Qualification Requirements for ASVs: The companion document covering how a company qualifies, requalifies, and stays in good standing as an ASV.
Requirement 11.3.2 / 11.3.2.1: The PCI DSS clauses requiring quarterly external scans by an approved vendor, plus a rescan after any significant change to internet-facing systems.
CVSS (Common Vulnerability Scoring System): The severity scale ASVs use to grade findings; a score of 4.0 or higher on any in-scope component fails the scan.
QSA (Qualified Security Assessor): A separate PCI SSC-certified role that assesses full PCI DSS compliance and signs off on a Report on Compliance (ROC).
PCI SSC owns and manages the ASV Program. It was created so that any company claiming to do "PCI scanning" had to prove its tool actually detects what matters for payment security, instead of just marketing itself as compliant.
Before the program existed, there was no independent check on whether a vulnerability scanner was fit for PCI purposes. Any tool could call itself a compliance scanner. PCI SSC, founded by the major payment brands, set out to standardize that, so a passing scan report means the same thing regardless of which approved vendor issued it.
That’s also why only vendors on PCI SSC’s official list can produce a scan report your acquirer or QSA will accept, a scan run by an unlisted tool, however capable, doesn’t satisfy the requirement.
Get set up in minutes with a scan solution built for the ASV Program's testing standards.
A candidate submits its scan solution for remote testing against PCI SSC's controlled test infrastructure, which is deliberately built with known vulnerabilities and misconfigurations the tool must detect and report correctly. At least two employees must also complete ASV training and pass a qualifying exam.
The process runs in roughly this order:
It checks whether the vendor's tool can accurately find and classify vulnerabilities on a network built to resemble a real scan customer's environment, not just whether the vendor says it can.
The test infrastructure exists specifically to remove guesswork from the process. Rather than taking a vendor’s word for its own capability, PCI SSC puts every candidate’s tool through the same simulated network, seeded with specific flaws, and grades what comes back. This is the step that separates an “ASV” from any other vulnerability scanning company.
A scan passes only when no in-scope component has a vulnerability scoring 4.0 or higher on the CVSS scale. That threshold catches medium-severity findings, not just critical or high ones; one qualifying vulnerability fails the entire scan.
This is a stricter bar than a lot of businesses expect going in. It’s common to assume a “fail” means something dramatic, an exposed database, or a critical remote-code-execution flaw. In practice, a single misconfigured TLS setting or an outdated library flagged at medium severity is enough to fail the scan and trigger the remediation cycle. Once findings are fixed, the environment has to be rescanned and come back clean before a passing report can be issued. (If you’re dealing with a failed result right now, see what to do after a failed ASV scan; if you’d rather avoid one, see how to pass a PCI ASV scan the first time.)
There’s also a formal path for handling findings a merchant believes are wrong. If a result looks like a false positive; a flaw on a component that’s actually patched, or that doesn’t exist as described, the ASV Program Guide requires the ASV to have a documented process for reviewing and resolving that dispute, rather than leaving the merchant stuck remediating something that isn’t really there.
Under PCI DSS v4.0.1, external ASV scanning applies to organizations with internet-facing systems in their cardholder data environment. That now includes a specific slice of SAQ A merchants, e-commerce sellers whose checkout page redirects to, or embeds, a third-party payment page, who weren't previously in scope for quarterly scanning.
This is one of the more consequential changes in the v4.0.1 update, and it’s also one of the most commonly misunderstood. SAQ A has historically been the category for merchants who’ve outsourced payment handling almost entirely, and many of those merchants assumed that outsourcing also meant no scanning obligation. That’s no longer a safe assumption: if your checkout flow hosts the page that redirects to, or embeds, a compliant third-party payment processor, that hosting page itself is now in scope for scanning, because it’s a link in the chain an attacker could tamper with, even though your servers never touch card data directly.
The practical takeaway isn’t “every SAQ A merchant now needs scans”; it’s “confirm with your acquirer or QSA whether your specific checkout setup falls under 11.3.2 before you assume it doesn’t.” Getting this wrong tends to surface at the worst possible time: when an acquirer bounces a submission back.
Unsure where you stand? Start with, do I need PCI ASV scanning? and the full breakdown of PCI ASV scan requirements.
It's the document that defines how ASV scans must be scoped, executed, and reported; it's what keeps a scan from Vendor A comparable to a scan from Vendor B.
Without a shared rulebook, “quarterly external scan” could mean wildly different things depending on who ran it. The Program Guide standardizes scan scope definition, how findings are scored and reported, how disputes over false positives are handled, and how special cases (like load balancers or hosting providers) are treated. It works alongside PCI DSS itself, translating Requirement 11.3.2 into concrete scanning mechanics. (New to the basics? Start with what an ASV scan is.)
Confirm your scope before your acquirer catches a gap for you.
ASV status isn't permanent. Every year, the vendor's scan solution is re-tested against PCI SSC's current testing procedures, and its employees have to complete refresher training and pass a new exam.
This matters because the threat landscape doesn’t stand still, and neither does the testing bar. Annual requalification means a vendor’s tooling is checked against current attack patterns and detection standards each year, not just once at initial approval. It also gives PCI SSC a yearly checkpoint to reassess the vendor company as a whole, not only its scanning technology.
PCI SSC can place a vendor into Remediation, typically giving it 90 days to resolve the issue and return to Good Standing. If the vendor doesn't resolve it, PCI SSC can revoke ASV status and remove the company from the official list entirely.
This is part of why the list itself matters more than any individual vendor’s claims. A company that was ASV-approved last year isn’t guaranteed to still hold that status today; it’s worth verifying current listing status at the time you’re evaluating a provider, rather than relying on older marketing material.
SV scans satisfy one specific control, Requirement 11.3.2, inside the broader PCI DSS framework. Passing a scan doesn't mean you're fully PCI compliant; it means you've met the external scanning piece of it.
Under PCI DSS v4.0.1, organizations in scope must run external vulnerability scans at least every three months, plus after any significant change to internet-facing systems (that’s the 11.3.2.1 sub-requirement), see how often ASV scans are required for the full cadence rules, using a currently listed ASV. That scan data then feeds into your SAQ (Self-Assessment Questionnaire) or, for larger merchants, the QSA-led Report on Compliance; it’s one input into a much larger assessment, not a stand-in for it. (It’s also worth knowing how ASV scanning differs from a penetration test, since the two get confused often.)
An ASV runs and certifies the external scan itself. A QSA is a separate PCI SSC-certified assessor who evaluates your organization's overall PCI DSS compliance and signs the formal Report on Compliance.
The two roles are often confused because both are “PCI SSC certified”, but they cover different scopes. Your ASV scan report is one input a QSA reviews; it doesn’t replace the broader assessment a QSA performs for organizations required to complete a full ROC.
The ASV Program is PCI SSC’s answer to a simple problem: how do you make sure a “PCI scan” from any vendor actually means something consistent? It does that through independent technical testing before approval, a strict pass/fail bar based on CVSS scoring, a shared rulebook in the ASV Program Guide, and mandatory annual requalification that keeps vendors accountable over time, not just at signup.
Knowing how the program works, including who’s actually in scope under v4.0.1, is what lets you evaluate a scan report and your own obligations accurately instead of by assumption.
Straightforward pricing, no hidden setup fees.
Every year, both the scan solution and the vendor's staff are re-tested.
Some do, specifically those whose checkout redirects to or embeds a third-party payment page.
No. An ASV certifies external scans; a QSA assesses full PCI DSS compliance.
Binoy Koonammavu, is the Founder and CEO of Secusy ASV, where he helps SMBs and fintech companies meet PCI DSS scanning requirements without the complexity of enterprise-grade tools. His writing focuses on making ASV compliance straightforward for growing businesses.