Approved Scanning Vendor (ASV) Guide: Requirements, Scans, and How to Choose One

You’ve probably been in the situation when your acquirer bounced a quarterly submission. And there’s a reason for that. Your scan results came from a vendor that probably lost its ASV certification three months earlier. The submission doesn’t count, the quarter resets, and a Level 1 merchant now faces a compliance gap with card brands.

That scenario isn’t hypothetical. The PCI SSC’s vendor list changes continuously, and teams that verify a vendor once and never check again are the ones it catches. For CTOs, compliance leads, and product owners at payment companies, getting this right determines whether your quarterly evidence holds up when an acquirer or QSA reviews it.

This article covers what the process requires, who needs it, how scans work, what trips up most teams, and how to evaluate vendors beyond bare certification.

What Is an Approved Scanning Vendor?

An approved scanning vendor is an organization with a set of security services and tools, formally called an ASV scan solution, used to conduct external vulnerability scanning services that validate adherence to PCI DSS Requirement 11.3.2. The role of a PCI DSS approved scanning vendor is defined in the PCI ASV Program Guide. It conducts external scans and produces passing reports that serve as quarterly compliance evidence. Before a vendor is added to the official list, its scan solution must pass independent technical testing against a controlled PCI SSC test environment.

ASV status expires every 12 months. A vendor that fails re-approval is removed from the list immediately. Scans produced by a removed vendor no longer count as compliance evidence, regardless of when the engagement was purchased or when the scan ran.

One distinction matters here: an ASV certifies external scans. A QSA assesses full PCI DSS compliance. Conflating the two creates gaps that surface at the worst possible time, during an assessment or post-breach forensic review. Teams building infrastructure for licensed PSPs and EMIs typically hit this scope question first. It surfaces before the assessment cycle begins.

For financial institutions looking beyond perimeter compliance, adopting effective cybersecurity strategies for banks ensures external scan findings feed into a comprehensive threat prevention model.

A PCI SSC approval confirms that a vendor’s tool met a technical standard at a point in time. It isn’t an endorsement of support quality, reporting depth, pricing, or dispute-handling capability.

Who Needs These Scans?

PCI DSS Requirement 11.3.2 applies to any merchant or service provider with internet-facing systems within their cardholder data environment (CDE). That covers more organizations than most assume.

The clearest cases:

• Level 1 and Level 2 merchants across all card brands
• Payment service providers and gateways handling card data on behalf of merchants
• E-commerce merchants under SAQ A whose checkout page redirects to, or embeds, a third-party payment form, a requirement that became mandatory after March 31, 2025, under PCI DSS v4.0.1

That last category is where the most compliance surprises appear in 2025 and 2026. SAQ A merchants previously assumed that outsourcing their checkout flow removed all scanning obligations. Under PCI DSS v4.0.1, it doesn’t. If your website initiates the payment interaction, even via an iframe or redirect, quarterly external scans are required.

The requirement applies regardless of transaction volume. Level 4 merchants, those processing fewer than 20,000 e-commerce transactions annually, or up to one million total card transactions, still need quarterly evidence alongside their Self-Assessment Questionnaire and Attestation of Compliance.

For teams building infrastructure for licensed PSPs and EMIs, this scope question is often the first compliance pressure test before an assessment cycle begins.

While quarterly vulnerability scans validate network security, payment platforms must also evaluate top KYC providers to ensure customer identity verification operates securely outside the cardholder data environment.

PCI DSS v4.0.1 Scanning Requirements at a Glance

PCI DSS v4.0.1 became the sole active standard on December 31, 2024. The remaining future-dated v4.0 requirements became fully mandatory on March 31, 2025. There are no remaining deadlines ahead, and there is no transitional leniency still available.

A significant change includes new firewall deployments, added web servers, major software upgrades, and network re-segmentation. Internal vulnerability scans under Requirement 11.3.1 don’t require an ASV and are managed separately.

How a PCI ASV Scan Works

Scoping

The scan customer defines the scope: all externally facing IP addresses, domains, and URLs within the CDE boundary. Missing a single in-scope asset, a forgotten staging environment, a cloud instance added mid-quarter, or a third-party integration running on your IP range can cause a compliance gap even if every other component passes cleanly. Asset inventory discipline is a prerequisite.

For fintechs expanding across jurisdictions, scope complexity compounds quickly. A new market launch typically means new IP ranges, additional CDN edge nodes, and local payment endpoints. Each of which must be inventoried and submitted before the next scan cycle. Teams that manage scope as a static document and update it annually, rather than as a living asset tied to infrastructure changes, regularly discover mid-cycle that their submitted scope is already stale.

Understanding modern digital wallet tokenization helps engineering teams design architecture that keeps sensitive card data off public endpoints, drastically reducing the overall CDE footprint before scoping even begins.

External vulnerability scanning

The vendor runs its solution against the submitted scope from an external position, simulating an attacker without internal access. ASV scanning covers known vulnerabilities, misconfigurations, exposed services, and outdated software versions. This is what PCI scanning means at the network layer. It doesn’t test application logic, internal systems, or social engineering vectors. For those, you need penetration testing services that go well beyond automated network scanning.

The passing threshold

The result is binary: pass or fail. A single vulnerability scored CVSS 4.0 or higher fails the entire report. Medium-severity findings fail the scan. Teams that expect only critical and high findings to matter regularly fail first attempts on medium-severity items they deprioritized.

For licensed PSPs and EMIs, a failed scan also triggers ICT risk documentation obligations under DORA compliance. The frameworks overlap at exactly this point.

Dispute and remediation

Not every finding reflects an actual vulnerability. False positives occur when a system reports an outdated software version in its banner after patching or when a scanner flags a component based on version string rather than confirmed exposure. When this happens, the merchant provides evidence: configuration files, screen captures, or documentation showing the finding doesn’t reflect a real risk. The vendor reviews the dispute and, if the evidence holds up, marks the finding resolved in the final report.

This process stays between the scan customer and the ASV. If evidence is insufficient, remediation is required before a passing report can be issued. This is why the quality of a vendor’s dispute-handling team matters as much as the quality of its scan tool. If you have not yet mapped your response process, a well-structured cybersecurity incident response plan gives the remediation workflow the structure that findings need to feed into.

The compliance gap is almost never the vulnerability itself. It’s the 10-business-day report cycle you didn’t account for when you had five days left in the quarter.

Most Common Reasons Scans Fail

Teams that fail their first PCI vulnerability scan almost always trace the failure to one of these causes:

Incomplete scope. Staging environments and cloud instances not included in the submitted scope are the most common blind spot.

Outdated TLS configurations. TLS 1.0 and 1.1 are flagged under PCI DSS v4.0.1 even on servers where card data doesn’t flow. The requirement is blanket.

Banner-based false positives without evidence. Teams that can’t quickly produce configuration documentation lose dispute resolutions and must remediate what may be a false finding.

Delayed scanning. Running the scan in the final week of a quarter leaves no time for remediation and rescan within the same quarter if the first attempt fails.

Missed post-change scans. Infrastructure teams ship a firewall change and move on. Requirement 11.3.2.1 doesn’t wait for the next quarterly cycle.

Payment tokenization reduces CDE scope directly. Fewer in-scope assets means fewer scan components and fewer scope gaps.

For teams building digital wallet infrastructure, understanding how tokenization shifts scope boundaries, and which assets drop out of the CDE as a result, is worth doing before the asset inventory conversation starts.

How to Choose a PCI Approved Scanning Vendor

Every vendor on the PCI SSC list has cleared the same baseline technical test. That baseline is where comparability ends. Below are the criteria that differentiate vendors in production.

Verify current list status

Only reports from a vendor currently on the official PCI SSC list are accepted by acquirers and card brands. Verify the vendor’s status directly at the time of selection, not based on marketing claims or on a check you ran six months ago.

The PCI SSC list also shows an “In Remediation” status. A distinct flag that means the vendor has violated one or more qualification requirements and is actively under remediation by the Council. An “In Remediation” vendor hasn’t been fully removed from the list, but the status signals an active compliance failure. Scans produced during a remediation period carry the risk that a status check done at contract-signing wouldn’t have surfaced. Check the vendor’s current status immediately before each scan engagement.

Evaluate dispute-handling capability

ASV PCI compliance hinges as much on dispute resolution as on scan quality. Before signing, ask: how does your team evaluate dispute evidence? What is your average resolution time? What documentation formats do you accept?

Assess remediation guidance quality

A report from a first-quality vendor tells you what vulnerabilities exist and exactly where. A minimum-viable vendor gives you a CVSS score and leaves the remediation decision entirely to your team. For fintech companies managing complex multi-service environments, guidance quality is the difference between a one-week remediation and a month-long cycle.

This mirrors our approach to AML compliance for fintechs: prescriptive guidance at the point of a finding.

Match the vendor to your infrastructure

Dynamic IP allocation, containerized services, and CDN-fronted applications create scope problems that static scan configurations don’t handle well. In container-orchestrated environments, service endpoints shift between scan cycles. A component in scope at the start of the quarter may expose a different address by scan day.

CDN-fronted endpoints add an attribution problem: the ASV sees the CDN edge, not the origin, and distinguishing between them requires vendor-side configuration that not every certified tool supports. For licensed PSPs and EMIs running cloud-native infrastructure, confirm the vendor has documented experience with your specific stack before committing.

Pro tip: Ask for a sample failing report and a sample dispute pack before you sign. After 17+ years shipping PCI-adjacent products, the vendors that stall a quarter are the ones that can scan, but cannot explain a CVSS 4.1 in a language your engineers can act on in 48 hours.

Confirm rescan policy and turnaround time

Given that first-attempt failure rates are high, rescan policy has direct cost implications. Get the terms in writing. Also confirm turnaround time: a vendor with a 10-business-day report cycle leaves minimal runway if remediation and a rescan are needed within the same quarter.

External Scanning and Broader PCI Compliance

External vulnerability scanning is one control layer within a broader compliance perimeter. It covers network-layer exposure on internet-facing systems. It doesn’t cover application-layer vulnerabilities in payment flows, internal environment exposure, or identity and access controls.

For a complete view of your payment security posture, external scanning sits alongside other critical controls. 3D Secure vendor selection and authentication controls are separate compliance domains that don’t substitute for quarterly scan evidence.

Similarly, for teams evaluating a KYC integration provider, identity verification remains a distinct operational domain from network scanning.

In Practice: The MuchBetter Build

When MuchBetter came to DashDevs, the brief was to build an award-winning e-wallet from scratch in four months for under $150,000, with no existing product documentation or defined requirements. The security challenge was anything but routine.

MuchBetter needed to operate across 180+ countries, connect with 300+ merchants, and serve users expecting frictionless payments, all while meeting full PCI DSS compliance requirements. DashDevs designed the security architecture from the ground up: device pairing, dynamic security codes, biometric authentication, and dynamic CVV rotation so static card details were never the attack surface. The infrastructure was built as a PCI/DSS-compliant-compatible system from day one.

The product now serves 400,000+ users globally and reduced transaction costs from 3 to 4% per transaction to a few pennies regardless of amount or currency. Read the full story in the MuchBetter case study.

For teams building compliant savings infrastructure, the Chip case study covers how we approached PCI/DSS-compatible development for a savings product operating under similarly tight regulatory expectations.

Compliance Is the Starting Line

A quarterly passing report from a PCI approved scanning vendor confirms that your external perimeter had no exploitable vulnerabilities above CVSS 4.0 on the date the scan ran. What a PCI approved scanning vendor can’t confirm is whether new vulnerabilities were introduced after that date or whether your application layer is secure. While tools like bank fraud prevention and real-time transaction monitoring protect active payment flows, network scanning only checks your perimeter at a single point in time. The gap between those two security layers is where breaches happen.

The IBM Cost of a Data Breach Report 2026 puts the global average breach cost at $4.99 million. That’s a 12% increase over the prior year and the highest figure the study has recorded in its 21-year history. For payment companies, card-brand monthly fines run from $5,000 to $100,000 per merchant ID before card reissuance and forensic investigation costs are included. Quarterly scanning is inexpensive relative to those numbers. The risk isn’t in the scan itself but in the organizational behavior that treats a passing report as permission to stop monitoring.

Teams that build production-grade payment infrastructure treat quarterly scanning as one feedback loop among many, integrated into a continuous security program rather than a quarterly sprint. If you are building or scaling a payment product and want a team that treats security architecture as part of delivery, our fintech consulting services cover compliance strategy from initial scope definition through ongoing assessment cycles.