PCI ASV Certification: How It Differs From PCI Certified and PCI Compliant
PCI ASV certification explained: how it differs from PCI certified and PCI compliant, who validates each, and how to verify a PCI approved scanning vendor.
SAQ A vs SAQ D is one of the most searched PCI DSS comparisons, and one of the most misunderstood. Merchants and even experienced IT teams often assume that once they’ve picked an SAQ type, the question of whether they need an Approved Scanning Vendor (ASV) scan is automatically settled. It isn’t.
SAQ type and ASV scope are two related but separate questions that happen to overlap for a lot of merchants, which is exactly why they get confused. Your SAQ type reflects how your business handles cardholder data. Your ASV scanning obligation reflects your network architecture. This article works through both ends of the SAQ spectrum, clarifies where ASV scanning enters the picture for each type, and gives you a complete view across all nine PCI DSS self-assessment categories, not just the two everyone talks about.
SAQ (Self-Assessment Questionnaire): A PCI DSS validation tool issued by the PCI Security Standards Council that allows eligible merchants and service providers to self-certify compliance rather than undergoing a formal assessment by a Qualified Security Assessor (QSA).
SAQ A: The shortest and least demanding SAQ, for merchants who have fully outsourced all cardholder data functions to PCI DSS-validated third parties and retain no electronic storage, processing, or transmission of cardholder data on their own systems.
SAQ D: The longest and most comprehensive SAQ, covering the full PCI DSS requirement set. It applies to merchants who don't qualify for any other SAQ type and to virtually all service providers.
ASV (Approved Scanning Vendor): A company certified by the PCI Security Standards Council to perform external vulnerability scans of internet-facing IP addresses, as required under PCI DSS Requirement 11.3.2.
Cardholder Data Environment (CDE): The people, processes, and technology that store, process, or transmit cardholder data, or that are connected to systems that do. The scope of your CDE directly determines which SAQ applies and whether an ASV scan is required.
Card-Not-Present (CNP) Merchant: A merchant who accepts card payments without the cardholder being physically present, typically through e-commerce or phone-based transactions.
SAQ A applies to card-not-present merchants who have outsourced all cardholder data handling to validated third parties and keep no cardholder data functions on their own infrastructure, which is why most SAQ A merchants have no external-facing CDE component to scan.
SAQ A was built for a specific scenario: e-commerce or mail/telephone-order merchants who redirect or fully hand off payment processing to a third party, a hosted payment page, for instance, and never touch card data themselves. Because the merchant’s own systems aren’t part of the CDE, there’s typically no in-scope external-facing IP address to scan, and the standard SAQ A form doesn’t include an ASV scanning question.
This is where the confusion starts. Merchants assume “SAQ A” means no ASV scan, full stop. That’s usually true, but not always. SAQ A qualification is stricter than most businesses assume: if your website uses JavaScript, you control rendering any part of the payment form, or if your systems interact with the payment flow in any technical capacity, you’re likely out of SAQ A eligibility and into SAQ A-EP territory instead, where the scanning obligation reappears. Learn if you actually need PCI ASV scanning before assuming your outsourcing setup qualifies.
Get a free scoping review before you file your next self-assessment.
SAQ D applies to merchants who don't fit any narrower SAQ category and to nearly all service providers, and it requires evaluation against the full set of PCI DSS requirements, which in nearly every real-world case includes quarterly ASV scanning of all external-facing IP addresses in the CDE.
SAQ D is the default landing spot. If a merchant processes, stores, or transmits cardholder data directly, uses a mix of payment channels, or operates infrastructure that touches the CDE in a way that doesn’t match a narrower SAQ, they end up here. Service providers, payment gateways, hosting providers, and SaaS platforms handling transactions are almost always SAQ D as well.
Because SAQ D environments retain in-scope, internet-facing systems, Requirement 11.3.2 applies in the overwhelming majority of cases. Quarterly ASV scans, and rescans until a passing result is achieved, are a standard and expected part of SAQ D compliance. If you’ve had a scan come back with findings before, our guide on what to do after a failed ASV scan walks through the remediation and rescan cycle.
SAQ A-EP does require ASV scanning, and this surprises many merchants who assumed their use of a third-party payment provider placed them safely in SAQ A.
SAQ A-EP exists precisely because a large share of e-commerce merchants sit in a middle ground: they use a third-party processor, but their own website scripts or serve elements of the payment page, often through JavaScript that calls external payment libraries or renders an in-page form. Because the merchant’s website is technically involved in the payment flow, even if cardholder data ultimately flows to the processor, the merchant’s systems are considered part of the CDE. That brings their internet-facing web presence into ASV scanning scope.
For SAQ A-EP merchants, quarterly ASV scans are mandatory. Any internet-facing system that could influence the integrity of the payment page, including the web server hosting the storefront, must pass a clean scan. This matters most for merchants on platforms like Shopify, WooCommerce, Magento, or BigCommerce, where checkout customisation is common; our breakdown of PCI ASV compliance by platform covers how this plays out for each.
Both SAQ C and SAQ D require ASV scanning, but they apply to different environments: SAQ C covers merchants with internet-connected payment application systems but no electronic cardholder data storage, while SAQ D applies to merchants who store cardholder data or operate more complex, broader environments.
SAQ C applies to merchants using payment application systems, such as point-of-sale software, connected to the internet, without storing cardholder data electronically. A retail merchant running a cloud-connected POS terminal is a typical example. Because that system has internet-facing exposure, ASV scanning comes into scope.
The distinction between SAQ C and SAQ D is mainly about cardholder data storage and environment complexity. SAQ C merchants generally have a narrower CDE, limited to the payment application and its connection to the processor. SAQ D merchants may have cardholder data residing on their own systems, wider network exposure, and more interconnections requiring a broader scan footprint. Both require quarterly scanning; the difference is how many systems fall inside that scope. If you’re unsure how to scope a scan correctly across a mixed environment, see our guide on choosing an ASV vendor that can help define scope accurately.
ASV scanning applies whenever an SAQ type's environment includes an internet-facing system connected to or part of the CDE, which rules out most standalone-terminal and fully outsourced SAQs, but applies to the majority of internet-connected ones.
SAQ A and SAQ D get the most attention because they sit at the two extremes, but PCI DSS actually defines nine SAQ types, and each carries a different default answer on ASV scope:
|
SAQ Type
|
Typical Use Case
|
ASV Scan Generally Required?
|
|---|---|---|
|
SAQ A
|
Card-not-present merchants, fully outsourced, no CDE on their own systems
|
No, no in-scope external-facing IPs.
|
|
SAQ A-EP
|
E-commerce merchants who partially outsource (e.g., redirect/iframe) but whose website still affects transaction security
|
Yes, the merchant’s own internet-facing systems are in scope.
|
|
SAQ B
|
Standalone, dial-out payment terminals with no internet connection
|
No, no internet-facing component exists.
|
|
SAQ B-IP
|
Standalone, PTS-approved terminals with an IP connection, not connected to other systems
|
Usually no, but scope should be verified.
|
|
SAQ C
|
Payment application systems connected to the internet, no electronic cardholder data storage
|
Yes, internet connectivity typically brings components into scope.
|
|
SAQ C-VT
|
Manual, one-at-a-time entry via virtual terminal on an isolated, non-connected computer
|
No, isolation generally removes external-facing exposure.
|
|
SAQ P2PE
|
Varies (often SAQ D). Merchants using only PCI-listed, validated Point-to-Point Encryption solutions
|
No, validated P2PE removes the merchant’s systems from CDE scope.
|
|
SAQ D (Merchant)
|
Catch-all for merchants not covered by any other SAQ
|
Yes, almost always.
|
|
SAQ D (Service Provider)
|
Service providers are eligible to self-assess rather than complete a full compliance report.
|
Yes, virtually always
|
The pattern is consistent throughout: it’s never the SAQ letter itself that triggers the ASV requirement; it’s whether that SAQ type’s environment, in practice, includes an external-facing system in or connected to the CDE.
SAQs built around full outsourcing, terminal isolation, or validated P2PE tend to remove that exposure by design. SAQs built around direct internet connectivity (A-EP, C, and D) tend to retain it. SAQ B-IP is the one case worth double-checking rather than assuming: an IP-connected terminal sits closer to internet exposure than a dial-out one, so verify actual network segmentation before ruling out a scan. For a broader look at how scanning fits into the wider compliance picture, see external vulnerability scans vs. penetration tests.
PCI-approved scanning from Secusy ASV, with no long-term contracts.
Validate your SAQ selection by mapping how cardholder data actually flows through and around your systems, then checking that flow against the PCI SSC's published eligibility criteria for each SAQ type, not by assuming your setup matches the SAQ you've always filed.
The PCI Security Standards Council publishes explicit eligibility criteria for every SAQ type. Before completing any self-assessment, map your payment data flows: trace exactly where card data enters your environment, how it moves, and where it exits or is handed to a third party. That map will tell you, with reasonable clarity, which SAQ you belong in, and by extension, whether ASV scan requirements apply to you.
For many SMBs, this exercise reveals that their original SAQ classification was based on a surface-level read of their payment setup rather than a technical review of actual data flows. A merchant who believed they qualified for SAQ A because they use a third-party processor may discover their checkout page includes scripts that interact with the payment form, placing them in SAQ A-EP territory and triggering a scanning obligation they didn’t know they had.
Merchants either pay for ASV scanning they don't need under an overly cautious SAQ D assumption, or skip scanning they do need because they assumed SAQ A exempted them, and the second mistake is the one that causes audit failures.
We regularly see two failure patterns:
Both are avoidable with a proper scoping exercise before deciding which SAQ to file, not after. If you’re preparing for your first scan cycle, how to pass a PCI ASV scan the first time is a useful next step once scope is confirmed.
SAQ A and SAQ D represent opposite ends of the PCI DSS self-assessment spectrum, but neither one directly answers whether you need ASV scanning. That answer comes from your actual network architecture: whether you have internet-facing systems in or connected to your Cardholder Data Environment. Most SAQ A merchants don’t need ASV scans because they’ve architected their way out of that exposure; SAQ A-EP, SAQ C, and SAQ D merchants typically retain it. The SAQ label is a symptom of your architecture, not the cause of the scanning requirement. Scope your environment first, then treat your SAQ type and your ASV obligation as related but separate outcomes of that scoping exercise, not as the same decision.
Walk through SAQ selection and ASV scoping step by step.
Yes, by fully outsourcing payment processing to a PCI DSS-compliant provider and removing all direct cardholder data handling from its own systems, typically by replacing a self-hosted checkout with a compliant redirect or iframe solution.
Because SAQ A-EP merchants have website elements, such as JavaScript rendering part of the payment form, that are technically involved in the payment flow, bringing their internet-facing systems into CDE scope even though a third party still processes the transaction.
Check whether any system you control, including your marketing website, touches, scripts, or influences the payment page in any way. If it does, you likely don't qualify for standard SAQ A and should reassess against SAQ A-EP criteria.
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.