10 min read

PCI DSS ASV Scans Explained: Costs, Requirements, Passing Criteria & Real-World Limitations (2026)

PCI DSS ASV Scans Explained: Costs, Requirements, Passing Criteria & Real-World Limitations (2026)

If your organization has internet-facing systems that touch cardholder data, you probably need ASV scans. Banks and payment brands require them as proof that your public infrastructure is reasonably secure from the outside.

But here is what most guides skip: ASV scans are a compliance checkbox, not a security silver bullet. They catch some things well, miss a lot, and create their own headaches.

This guide walks through what ASV scans actually are, what they cost in 2026, how to pass them, and the real frustrations merchants deal with every quarter.

What Is a PCI DSS ASV Scan?

An ASV (Approved Scanning Vendor) scan is a standardized external vulnerability scan run against your public-facing IP addresses and domains. Only vendors approved by the PCI Security Standards Council can perform these scans and issue official attestations.

Think of it as a basic security health check from the internet. It looks for known vulnerabilities and weak configurations that an attacker could spot without any special access.

Why PCI DSS Requires ASV Scans

Payment data is a prime target. Even small oversights on public systems can lead to big problems. External ASV scans help organizations:

  • Spot known vulnerabilities on internet-facing assets
  • Confirm secure configurations on exposed services
  • Keep a consistent baseline through regular testing
  • Give acquirers and card brands clear, attestable evidence

In PCI DSS v4.x, this falls under Requirement 11.3.2. You need to do these scans at least quarterly and after any significant change, such as:

  • Adding new public hosts
  • Major upgrades or patches
  • Network architecture changes
  • New WAF/CDN setups

The Often-Ignored Requirement: Scanning After Significant Change

Quarterly scanning gets all the attention. The “after significant change” requirement is where teams quietly fall out of compliance.

If you:

  • Deploy new public infrastructure
  • Change firewall rules
  • Move to a new CDN or WAF
  • Upgrade core web frameworks
  • Expose new APIs

PCI expects an external scan after those changes.

Many teams deploy continuously but only scan on a quarterly schedule. Technically, that can leave you non-compliant for months.

Compliance isn't just every 90 days; it's triggered by infrastructure evolution. If you deploy a new API or change a firewall rule in Q2, you need a scan immediately, not just at the end of the quarter.

PCI DSS ASV Scanning Timeline 2026 showing quarterly scans and ad-hoc scans after significant infrastructure changes.

If the change affects public exposure, plan for a scan.

What ASV Scans Actually Do (and don’t)

ASV scans are fully automated tests run from outside your network. They try to see what a random internet attacker would see.

The ASV process isn't a "one-and-done" button click. The cycle often stalls at the remediation and dispute phase, which is why starting early in the quarter is critical.

Flowchart of the PCI DSS ASV scan lifecycle: Scope, Scan, Analysis, Remediation, and Attestation.

Here is the typical flow:

  1. Asset discovery (finding your public IPs and domains)
  2. Port and service enumeration
  3. Version detection and banner grabbing
  4. Vulnerability checks against known issues
  5. TLS/SSL and certificate testing
  6. Report and attestation generation

What they don’t do is equally important

ASV scans generally cannot:

  • Log into your applications or test authenticated flows
  • Check business logic or authorization controls
  • Perform deep application-layer testing (SQL injection, XSS, CSRF)
  • Evaluate how well your internal network is segmented
  • Chain multiple small issues into a realistic attack path

Segmentation Assumptions Can Be Dangerous

If your PCI scope relies on network segmentation, understand this:

ASV scans do not validate whether segmentation is actually working.

They only test what is externally reachable.

If internal systems are assumed to be isolated but aren’t, ASV scans will not detect that failure. That gap is often where breaches happen.

Segmentation effectiveness requires internal testing, not external scanning.

In practice, ASV scans give you a solid external baseline. They are not a full security assessment.

Who Needs ASV Scans? Breaking Down PCI DSS Levels

All merchant levels require quarterly ASV scans, but the broader compliance requirements differ based on transaction volume.

PCI DSS Merchant Levels

Level

Annual Transaction Volume

ASV Scans

Other Requirements

Level 1

6M+ transactions/year

Quarterly

Annual QSA audit, penetration testing, ROC

Level 2

1M–6M transactions/year

Quarterly

Annual SAQ, attestation, often pentest required by bank

Level 3

20K–1M e-commerce transactions/year

Quarterly

Annual SAQ, attestation

Level 4

<20K e-commerce or <1M total transactions/year

Quarterly

Annual SAQ (enforcement varies by bank)

What Actually Needs Scanning

In practice, if a system is publicly reachable and could affect the security of cardholder data, it usually needs to be scanned.

This includes:

  • Payment pages and APIs
  • Public admin portals
  • VPN or remote access gateways used by admins
  • Any exposed service that touches the cardholder data environment

The Critical Detail: Your Bank Makes the Final Call

While PCI DSS sets the baseline, your acquiring bank often requires more:

  • Monthly scans instead of quarterly
  • Zero tolerance for medium findings (not just critical/high)
  • Specific approved ASV vendors only
  • 30-day remediation windows instead of 90

Always verify your specific requirements in writing from your acquiring bank.

What Counts as “Passing” an ASV Scan?

A scan passes when:

  • No vulnerabilities with a CVSS base score of 4.0 or higher on in-scope assets
  • No automatic-fail conditions are present

Automatic fails often include

  • Old TLS/SSL protocols still enabled (SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.1)
  • Weak or legacy cipher suites (DES, 3DES, RC4)
  • Broken or misconfigured certificates
  • Exposed admin services without proper hardening

Important: You can still pass with findings

A typical passing scan might show:

  • 0 Critical vulnerabilities (CVSS 9.0-10.0)
  • 0 High vulnerabilities (CVSS 7.0-8.9)
  • 0 Medium vulnerabilities (CVSS 4.0-6.9)
  • 12 Low vulnerabilities (CVSS 2.0-3.9) ✅ Allowed
  • 34 Informational findings ✅ Allowed
Status: PASS

The key is that nothing meets the PCI threshold for a fail. But you should still address those low/medium findings proactively.

The Acquirer Factor: Portals, Rules, and Exceptions

Your acquiring bank ultimately decides what counts.

Each bank has its own compliance portal and slightly different rules. Some let you upload ASV reports directly. Others require you to log into their specific portal, upload the report, and sometimes answer extra questions.

Common portal variations:

  • Direct PDF upload with automated acceptance
  • Manual review by compliance team (3-7 business days)
  • Additional questionnaires about remediation plans
  • Requirement to categorize each finding and provide evidence

Exceptions and remediation timelines vary wildly

One bank might accept a compensating control for a medium finding. Another might reject the same report and demand a full fix within 30 days.

Always check your acquirer’s portal and rules first. PCI DSS sets the minimum, but your bank sets the bar you actually have to clear.

How Much Do ASV Scans Cost in 2026?

Costs depend on the number of IPs or domains, how complex your setup is, and the level of support you need.

The Real Problems Teams Face (and How to Avoid Them)

These are the issues merchants complain about most in forums and Reddit threads like r/pcicompliance.

  1. False positives are the biggest ongoing headache

Scanners frequently flag a “vulnerable” version even when the fix has been backported or the feature is disabled. You submit evidence, wait days for review, and sometimes the ASV or your bank still rejects it.

Example: Scanner reports “Apache 2.4.41 - CVE-2019-XXXX (CVSS 7.5)” but your vendor backported the security fix without changing the version number. You spend 5 days gathering patch documentation, only to have the ASV request more proof.

In some cases, compensating controls are accepted. In others they are not, and you are forced to implement a full fix even when the risk is theoretical.

Maintain detailed documentation of all patches and backports. Work with ASVs that have responsive dispute processes.

  1. Scope mistakes cause most outright rejections

Forgetting a subdomain, a new CDN endpoint, or an old cloud IP leads to acquirers rejecting the report. You then spend time explaining why the scan was incomplete.

Teams scan only IPs but forget domain names like api.example.com or checkout.example.com. New cloud instances spun up mid-quarter get missed. Dev or staging environments that accidentally went public are not included. Third-party hosted services that touch the CDE are overlooked.

Maintain a living asset inventory. Review scope before each quarterly scan. Document any exclusions with your QSA.

  1. WAF and CDN interference adds friction

Security tools block the scanner or change responses, leading to incomplete scans or false results. You end up whitelisting IPs and coordinating scan windows every quarter.

Cloudflare blocks ASV scanner IPs. AWS WAF rate-limits scan attempts. Load balancers return different responses to scanners. CDN caching masks actual vulnerabilities.

Get ASV scanner IP ranges and whitelist them permanently. Schedule scans during low-traffic windows. Test scan accessibility before each quarter.

  1. Remediation limbo is exhausting

Even after a passing scan, your acquirer may ask for change logs, screenshots, or proof the fix is permanent. One missed step and you are back to square one.

Before/after screenshots of configuration changes. Change control tickets showing approval. Vendor documentation proving patch effectiveness. Signed attestation from IT manager. Timeline showing fix was implemented before rescan.

Create a remediation evidence template. Document everything during the fix process, not after.

  1. Last-minute panic is common

Waiting until the end of the quarter to scan leaves no runway if something fails.

Scan in the first month of each quarter. This gives you 60+ days for remediation if needed. Allows time for multiple rescans without stress. Prevents missed quarterly deadlines.

  1. Acquirer portal headaches make everything worse

Different banks have different upload requirements, exception processes, and response times. What works for one merchant can fail for another with the same report.

Portal interfaces are often non-intuitive and require multiple attempts. Rejection reasons are vague like “additional documentation needed.” No direct contact with the reviewer. Response times stretch to 2-3 weeks during busy periods.

But here is the real issue: your bank can reject an ASV scan from a PCI SSC-approved vendor like Qualys even though it is technically valid. If you did not use their portal or their preferred ASV, they can send you back to redo everything.

Submit early. Keep detailed notes on your acquirer’s specific requirements. Build relationships with compliance contacts when possible.

  1. Scan completion times can stretch for days or weeks

This is one of the most frustrating issues that does not get enough attention.

ASV scans are supposed to take a few hours. In practice, scans can sit in “pending” or “incomplete” status for days. Sometimes weeks.

The ASV vendor is waiting for additional information. Network issues cause incomplete scans. WAF blocks require back-and-forth coordination. Large or complex environments take longer to process. ASV review queues back up during end-of-quarter rushes.

By the time you get results, you are already halfway through the quarter. If you fail, the remediation timeline becomes compressed.

Start scans early in the quarter. Follow up proactively if you do not see results within 48 hours. Have ASV contact information ready. Do not assume “submitted” means “being processed.”

ASV Scans vs. Penetration Testing: Why You Need Both

ASV scans are great at finding known external issues. Penetration testing goes much deeper.

What ASV Scans Find

  • Known CVEs on public systems
  • SSL/TLS misconfigurations
  • Missing patches on external servers
  • Weak ciphers and protocols
  • Certificate issues

What Penetration Testing Finds

  • SQL injection, XSS, authentication bypasses
  • Business logic flaws (price manipulation, workflow bypasses)
  • API vulnerabilities and authorization issues
  • Attack chains combining multiple weaknesses
  • Internal lateral movement possibilities
  • Social engineering vulnerabilities

7 Key Takeaways

  1. ASV scans are required for most organizations with public-facing in-scope assets
  2. You need them quarterly, plus after significant changes
  3. Passing means no CVSS 4.0+ vulnerabilities on scanned assets
  4. Your acquirer’s portal and rules are what really matter, they often exceed PCI DSS minimums
  5. False positives and scope issues cause most headaches plan extra time
  6. Passing an ASV scan does not mean you are secure, it means you met minimum external requirements
  7. The fastest way to make this painless is repeatable process and early scanning (first month of quarter)

When You Need Help

If you are tired of fighting false positives, scope battles, or bank rejections, you are not alone. Most teams hit this wall eventually.

At RedSecLabs, we help organizations:

  • Clean up ASV scope
  • Resolve disputed findings
  • Align reports with acquirer requirements
  • And strengthen real-world security beyond compliance checkboxes

If you want clarity before your next quarterly deadline, send your latest ASV report to [email protected].

We will review it and tell you:

  • What actually matters
  • What will block a pass
  • And what you can safely deprioritize

No fluff. Just a clear path forward.

FAQ

Can I use any scanner for PCI compliance?
No. Only a PCI SSC-approved ASV can issue official attestations. Regular vulnerability scanners like Nessus or OpenVAS don’t satisfy PCI DSS requirements.

How long does a scan take?
Usually a few hours, but WAFs, CDNs, and large scopes can stretch it out. Complex environments with 20+ IPs might take 6-8 hours.

What if I fail?
Fix the blocking issues, gather evidence, and rescan. Most vendors include several rescans in their pricing. The key is fixing issues quickly to stay within the quarter.

Do I need ASV scans if I use Stripe or Square?
It depends on your integration and what remains in your environment. SAQ A (full redirect) usually doesn’t require ASV scans. SAQ A-EP and SAQ D typically do. Check your SAQ type and acquirer rules.

How do I define scan scope?
Start with every public asset that could affect the CDE payment pages, APIs, admin portals, VPN gateways. Document everything and confirm with your QSA or acquirer when in doubt. Better to over-scope initially than miss something.

What’s the difference between PCI DSS 3.2.1 and 4.0 for ASV scans?
The core requirement hasn’t changed quarterly external scans are still mandatory. PCI DSS 4.0 (Requirement 11.3.2) adds more emphasis on continuous monitoring and targeted risk analysis, but the ASV scan frequency and passing criteria remain the same.

Can I dispute ASV findings?
Yes. If you believe a finding is a false positive, you can provide evidence to the ASV. Common evidence includes: vendor documentation showing backported patches, configuration exports proving the vulnerability isn’t exploitable, compensating controls documentation, or network diagrams showing the system isn’t actually exposed.

Why does my acquirer reject passing scans?
Banks can impose stricter requirements than PCI DSS minimums. Common reasons: incomplete scope (missing domains or IPs), too many medium/low findings per bank policy, lack of remediation documentation, or scan from non-approved ASV vendor (per bank’s list).

Contact: www.redseclabs.com | [email protected]