PCI Compliant Checkout: Hosted, iFrame or API? Which SAQ
Hosted page, iFrame or API? See which SAQ each PCI compliant checkout option triggers, which scans and scripts you must cover, and how to choose
Failing a PCI ASV scan is rarely a mystery once you look at the report. It’s almost always one of a handful of predictable, preventable issues: a port that should have been closed, a TLS version that should have been retired, or a patch that should have shipped weeks earlier. Yet many businesses walk into their first scan with no preparation and a false sense that everything is probably fine. It isn’t always fine, but it’s fixable.
This guide walks through exactly what an ASV scan checks, why most first attempts fail, and the step-by-step preparation that gets you a clean pass on your first try.
PCI ASV Scan: A quarterly external vulnerability scan performed by a PCI SSC-certified Approved Scanning Vendor (ASV), required under PCI DSS Requirement 11.3.2. It examines every externally facing IP, port, and service tied to your cardholder data environment (CDE).
CDE (Cardholder Data Environment): The systems, networks, and infrastructure that store, process, or transmit cardholder data, plus anything that can reach those systems.
CVSS Score: The Common Vulnerability Scoring System rates the severity of a finding from 0 to 10. A score of 4.0 or above results in an automatic ASV scan failure.
AOC (Attestation of Scan Compliance): The document your ASV issues confirming a passing scan, typically required by your acquiring bank.
Scope Creep: When public-facing infrastructure, CDN edge nodes, load balancers, staging servers are left out of the declared scan scope, whether by oversight or by choice.
Secusy ASV delivers fast turnaround, transparent pricing, and expert support from day one.
A PCI ASV scan is a mandatory quarterly external vulnerability check of every public-facing IP tied to your cardholder data environment. Most businesses fail it the first time because of open ports, outdated TLS, or unpatched software, not because of anything exotic.
The scan doesn’t factor in how secure your environment has “generally” been. It evaluates what’s live and externally reachable right now. Anything with a CVSS score of 4.0 or higher is flagged as an automatic fail, regardless of how minor it may seem in context. The uncomfortable truth is that most first-time ASV scan failures are caused by the same three things; open ports that shouldn’t be open, unpatched software components, and SSL/TLS misconfigurations. All three are preventable before the scan ever runs.
Open or unnecessary ports, outdated TLS versions, and unpatched web server software account for the overwhelming majority of first-time failures, with scope creep close behind as a distinct, separate problem.
|
Failure Cause
|
Frequency
|
Severity
|
|---|---|---|
|
Open or unnecessary ports (22, 23, 3389)
|
Very common
|
High
|
|
Outdated TLS versions (TLS 1.0 / 1.1)
|
Very common
|
High
|
|
Unpatched web server software (Apache, Nginx, IIS)
|
Common
|
High
|
|
Default credentials on devices
|
Occasional
|
Critical
|
|
Scope creep, IPs not included in scan scope
|
Common
|
Medium
|
|
Missing or expired SSL certificates
|
Occasional
|
Medium
|
Scope creep deserves particular attention. Businesses often submit only their primary application IP, forgetting load balancers, CDN edge nodes, or staging environments sitting on the same public subnet. The scan will find them regardless, and an incomplete declared scope is arguably a bigger compliance issue than the vulnerabilities it might otherwise flag.
Start 2–3 weeks before your scheduled scan date and work through scope, ports, TLS, patching, perimeter firewalls, banner suppression, and dispute readiness in that order, this isn't a checklist to run through five minutes before your scan.
List every IP address, hostname, and domain that touches cardholder data, directly or indirectly. Include payment gateways, APIs, CDN endpoints, and any infrastructure your hosting provider exposes to the public internet. When in doubt, include it. Excluding IPs from scope to avoid failures is a compliance violation, not a shortcut.
SSH (22), RDP (3389), Telnet (23), FTP (21), if these are open externally, close them now. If you need SSH or RDP for admin access, restrict it to specific IP ranges using firewall rules, not open to 0.0.0.0/0. An open RDP port is close to a guaranteed ASV failure, and an immediate red flag for any QSA reviewing your report.
Disable TLS 1.0 and TLS 1.1. Support TLS 1.2 minimum, TLS 1.3 is strongly recommended. Disable weak cipher suites: RC4, DES, 3DES, NULL ciphers. A free tool like SSL Labs' server test lets you validate your configuration before submitting to your ASV. An A or A+ rating there typically maps well to a clean ASV result on TLS-related findings.
Apache, Nginx, IIS, PHP, OpenSSL, WordPress plugins, anything exposed to the public internet needs to be on a current, non-EOL version. ASV scans cross-reference discovered version banners against CVE databases. Patch first, scan second.
Cloud-layer rules like AWS Security Groups, Azure NSGs, and GCP firewall rules operate at the cloud layer, but your hosting provider's network perimeter rules may override or supplement them. Confirm that your cloud-layer restrictions are actually effective from outside your VPC. A common mistake: a developer opens a port directly on an instance for testing, three months later, it's still open, still public, and now it's in your scan scope.
Server headers, error pages, and default "Welcome" pages often expose version information that ASV scanners use to match against CVE databases. Suppress Server: headers in your web server config, disable directory listing, and replace default error pages with custom ones. This won't fix an underlying vulnerability, but it eliminates a category of informational findings.
If your ASV returns findings you believe are false positives, you can submit a dispute with supporting evidence, patch notes, configuration screenshots, and vendor advisories. Good ASV providers process disputes quickly, but the documentation needs to be ready before you submit.
Our team reviews your scan scope and flags likely issues before your official scan runs.
The most common causes of repeat failures are scoping only what you assume is relevant, treating ASV scanning as a one-time event, skipping your own report before your QSA sees it, and dismissing low-severity findings.
PCI SSC certification is table stakes, it doesn't standardize turnaround time, support quality, or how quickly a dispute gets resolved, so those are the things worth evaluating before you commit to a provider.
A competent ASV provider should deliver:
Watch for the opposite signals too: generic support tickets with multi-day response times, opaque pricing with add-on rescan fees, reports that require a forensics background to interpret, and no pre-scan consultation or scope review. For US-based businesses, UK merchants, and globally distributed SaaS platforms, turnaround time on your AOC directly affects how quickly your acquirer can move.
Passing your first scan is step one, staying compliant means building patch discipline, port audits, certificate monitoring, and scope reviews into your regular operational rhythm, not just your pre-scan checklist.
A few practices that make quarterly scans dramatically easier:
Businesses that build these practices into their operational rhythm rarely fail a quarterly scan. The ones that treat compliance as a one-time event fail repeatedly, and pay for it in both rescan fees and audit delays.
Passing a PCI ASV scan on the first attempt isn’t about luck; it’s about closing the same handful of gaps that trip up most businesses: unnecessary open ports, outdated TLS, unpatched software, and incomplete scope. Start preparation 2–3 weeks out, work through each step methodically, and treat the scan as recurring operational hygiene rather than a quarterly fire drill. Businesses that build these habits into their deployment process rarely fail a scan twice.
Get your Attestation of Scan Compliance faster with a provider built for growing teams.
Close unnecessary ports, patch your TLS configuration, update internet-facing software, and lock down your scan scope 2–3 weeks before your scheduled scan date, the seven-step process covered above.
Yes. If you believe a finding is a false positive, submit a dispute to your ASV provider along with supporting evidence such as patch notes, configuration screenshots, or vendor advisories.
PCI DSS requires an external ASV scan at least once every 90 days quarterly, for any environment that stores, processes, or transmits cardholder data.
An ASV scan is an automated, external vulnerability scan required quarterly under PCI DSS 11.3.2. A penetration test is a manual, in-depth security assessment, required annually, that actively attempts to exploit vulnerabilities rather than just identify them.
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.