How to Prepare for Your First PCI ASV Scan (and Avoid the Most Common Failures)

If you've just been handed PCI compliance at your company, the ASV scan is probably the first concrete deliverable on your list. The good news: it's a defined process with clear rules. The less-good news: PCI ASV scanning operates on a "guilty until proven innocent" model, and first-time scans almost always surface findings you'll need to dispute, document, or remediate before you get a passing report.

This guide walks through how to prepare, what causes most first scans to fail, and how a good ASV makes the dispute process less painful so you're not relitigating the same false positives every quarter.

What a PCI ASV scan is (and what "passing" actually means)

A PCI ASV scan is an external vulnerability scan performed by an Approved Scanning Vendor, which the PCI Security Standards Council defines as a company it has approved to conduct external vulnerability scanning services. ASV scans satisfy PCI DSS Requirement 11.3.2, which requires merchants and service providers to run quarterly external scans on every internet-facing system in or connected to the cardholder data environment (PCI DSS v4.0.1, 2024).

A passing scan, per the PCI ASV Program Guide v4.0 r2, means no vulnerabilities scored CVSS 4.0 or higher remain, and no automatic-fail conditions are present. Anything in the medium range (4.0 to 6.9) or high range (7.0 to 10.0) blocks compliance until it's resolved or successfully disputed.

One thing worth flagging up front: the merchant defines the scope, not the ASV. Per the ASV Program Guide, every public IP address routed to your in-scope environment and every URL pointing to those IPs must be included. If you miss something, the scan still passes, but the report doesn't reflect reality.

When you need your first scan

If you're going through your initial PCI DSS assessment, you don't actually need four passing scans on the books before you can attest. The PCI DSS v4.0.1 Applicability Notes for Requirement 11.3.2 allow first-time assessment with three things in place: a most-recent passing scan, a documented policy requiring quarterly scans, and evidence that any vulnerabilities found in the scan have been corrected via rescan.

After your first year, that grace period ends. From that point on, you need four passing scans in any rolling 12-month period.

ASV scans are also required after any significant change to your external environment, though that requirement (11.3.2.1) allows non-ASV scanners as long as the same CVSS 4.0 threshold is met.

A 5-step preparation checklist

Before you schedule the scan, work through these in order.

1. Inventory every internet-facing asset in your cardholder data environment

This is the single most important step and the one most first-timers underestimate. Pull together every public IP, every domain and subdomain, every web application, and every third-party service that touches cardholder data. If you can't confidently say what's in scope, an external attack surface discovery process will find what you've missed before the scanner does.

2. Confirm scope with your acquirer or QSA

Scope disputes are easier to settle in advance than after the report is issued. If you're working with a Qualified Security Assessor, share your asset inventory and ask them to confirm scope before the scan runs. If you're going through SAQ self-assessment, your acquirer is the right contact.

3. Whitelist your ASV's scan IPs and disable active blocking

This is where a lot of first scans get bogged down. Your firewall, IPS, and WAF will see scan traffic as an attack and may start blocking it midway through. We'll come back to this in the failures section, since it's the number one technical reason scans go sideways.

4. Run a pre-scan against yourself first

You don't want to find out about a CVSS 7.5 finding on your payment page from your ASV. Use your existing external vulnerability management tooling, or any reputable scanner, and patch what you find before the official scan starts. The goal is to make the ASV scan a confirmation, not a discovery.

5. Line up remediation owners before the scan starts

When the scan comes back with findings (and on a first scan, it will), you don't want to be hunting down the right person to patch a server while the clock runs. Identify who owns each system in scope, and give them a heads-up that scan results may need their attention within a few days.

Why first scans feel harder than they should: guilty until proven innocent

Here's the part that catches most first-timers off guard. PCI ASV scanning is not a binary pass/fail event. It's a process built on the assumption that any flagged finding is a real issue until you prove otherwise.

The scan engine identifies vulnerabilities based on banner detection, version inference, and signature matching. It doesn't confirm exploitability. That means a server running a backported patch will often get flagged as vulnerable because the version banner still reads as the old one. A configuration that mitigates a CVE will get flagged as a finding because the underlying software is in the affected version range. Anything tagged as a "Special Note" in the ASV Program Guide requires a customer-supplied declaration before the ASV can issue a passing report.

Every one of these is a finding you'll need to dispute. The dispute process itself is straightforward: you provide evidence (compensating control documentation, configuration screenshots, vendor advisories confirming a backport, etc.), the ASV reviews and accepts or rejects it, and the finding is either cleared or remains.

The catch is that first scans typically generate a lot of these. A merchant running a few dozen internet-facing assets can easily see dozens of findings on a first scan, and a meaningful chunk will be false positives or findings that resolve to compensating controls rather than patches.

This is where the experience of your ASV matters more than almost anything else. A good ASV has seen these patterns before. They know what evidence is acceptable for each common false positive. And, critically, they configure those dispute resolutions so they persist across future scans. Your second scan should have a fraction of the disputes your first one did, because the noise has been cleared once and set not to come back. We've seen merchants stuck in a cycle of disputing the same five findings every quarter because their previous ASV never persisted the resolutions. That's not how it should work.

The most common reasons first ASV scans fail

Setting false positives aside, here are the technical issues that produce real failing findings on first scans.

1. Active IPS/WAF blocking the scan and producing inconclusive results

The ASV Program Guide specifically flags this. Network security controls that shun or block IP addresses based on perceived attack patterns can cause inaccurate scan results, because they react differently to a scanner than they would to a real attacker. If your IPS sees the scan traffic and blocks the ASV's IPs partway through, the scan can't complete cleanly. Whitelist your ASV's source IPs before the scan starts. Your ASV will provide the IP ranges.

2. Unpatched CVEs in web servers, frameworks, and third-party software

This is the bread and butter of ASV scan findings. Apache, Nginx, Microsoft IIS, OpenSSL, PHP, WordPress, Node.js, jQuery. Anything in your stack that's a version or two behind. The scan engine checks the banner or version against CVE databases and flags anything at CVSS 4.0 or higher. The fix is to actually patch, but a meaningful percentage will resolve as backport disputes or mitigated configurations once your ASV reviews the evidence.

3. Outdated TLS versions and weak ciphers

TLS 1.0 and 1.1 are deprecated and will fail. Weak ciphers (anything supporting RC4, 3DES, export-grade crypto, or known weak Diffie-Hellman groups) will fail. SSL/TLS findings are extremely common on first scans because legacy endpoints, mail servers, and admin panels often haven't been touched in years. Audit your TLS configuration on every endpoint in scope before the scan, not after.

4. Default credentials or exposed admin interfaces

The scanner will check for known default credentials on common services (router admin pages, database management interfaces, BMC/iLO/iDRAC, etc.) and will flag any management interface reachable from the public internet. If a router admin panel is exposed on port 8443 because someone enabled it for remote access two years ago and forgot, the scan will find it.

The failure mode most first-timers miss: an incomplete asset list

A scan can come back clean and still leave you non-compliant. If the scope was wrong, a passing report doesn't actually mean what you think it means.

The most common gaps we see are forgotten subdomains from old marketing campaigns, dev and staging environments still resolving on public DNS, third-party services that handle cardholder data but never got formally added to the inventory, and shadow IT spun up by other teams outside of IT's view. Any of these could be in scope under PCI DSS, and any of them being absent from your scan list is a finding waiting to happen at your next assessment.

This is why continuous attack surface discovery matters more than a one-time inventory. Your environment changes between quarterly scans. The point of pairing ASV scanning with continuous EASM is to catch the new asset that got spun up two weeks after your last passing scan, not three months later when the next one starts.

What to expect after the scan

When the scan completes, you'll get a draft scan report with all findings, severity ratings, and recommended remediation. From there:

• Review every finding. Decide whether to remediate, dispute, or accept (acceptance only applies if it's a false positive or compensating control).
• For disputes, gather your evidence and submit it through the ASV's dispute resolution process. A responsive ASV turns these around in days, not weeks.
• For remediation, patch or reconfigure, then request a rescan. Rescans against affected systems are typically possible the same week with a responsive ASV.
• Once everything is cleared, the ASV issues the Attestation of Scan Compliance, which is the document your acquirer or QSA wants to see.

The first time through this loop is the longest. Once your environment and dispute resolutions are dialed in, ongoing quarterly scans should be much shorter.

How Halo Security approaches your first scan

We've been a PCI ASV for years, and most of our first-scan engagements start the same way: with a merchant who's nervous about how many findings they'll see and how long the dispute process will take.

Our approach: pair the ASV scan with continuous external attack surface discovery so you catch scope drift between scans, and work through your initial false positives with you so they're documented, accepted, and set not to come back next quarter. The point isn't to make compliance painless, because nothing involving PCI is painless. The point is to make it predictable.

If you're staring down your first ASV scan and want to talk through scope, timing, or what to expect, meet with our PCI team. No pressure, no jargon, just a conversation with people who've done this a few thousand times.

FAQ