PCI DSS ASV Program and Quarterly External Scans
Browse PCI DSS topics
What the PCI DSS ASV program is
The Approved Scanning Vendor (ASV) program is the PCI Security Standards Council's accreditation scheme for firms that perform the external vulnerability scans PCI DSS requires. Under PCI DSS Requirement 11.3.2, every organization with internet-facing systems in the cardholder data environment must run external vulnerability scans at least quarterly and after any significant change, and those scans must be performed by an ASV. Only firms listed on the PCI SSC's public ASV list can produce reports that satisfy PCI DSS; scans from unaccredited scanners or purely internal tooling do not count.
ASVs earn their status by passing an annual PCI SSC qualification, running their scanning tooling through a rigorous validation environment, and employing certified ASV employees. The PCI SSC maintains the master list of ASVs and publishes updates as firms are added, renewed, or removed. Selecting an ASV is therefore both a PCI DSS compliance decision and a security decision: the ASV's scanners, processes, and analyst capacity materially shape the quality of your external vulnerability data.
How quarterly external scans work
PCI DSS Requirement 11.3.2 mandates external vulnerability scanning at least once every three months, with every quarterly scan producing a passing result. The ASV configures scanning against the internet-facing IP ranges and fully qualified domain names in the cardholder data environment. The ASV runs automated vulnerability checks, produces a scan report, and works with you through dispute and remediation until the scan passes.
A passing PCI DSS ASV scan has:
- No vulnerabilities rated CVSS 4.0 or higher that remain exploitable after validation
- No "automatic failure" findings such as SQL injection, cross-site scripting on sensitive pages, insecure remote access, or default passwords on any accessible service
- No evidence that the scan was inappropriately restricted by firewall rules, rate limiting, or intrusion prevention systems
- All in-scope hosts successfully scanned, not marked as unreachable without documented justification
If any of those conditions fail, the scan fails. You remediate the finding, request a rescan, and repeat until the quarter closes with a clean result. The PCI DSS rule of four is strict: you need four passing quarterly ASV scans per reporting period, not four attempted scans. Missing a quarter is a PCI DSS finding your QSA will flag.
Remediation timelines and workflow
A realistic PCI DSS ASV cadence looks like this:
- Scan window opens at the start of each quarter. You schedule the scan with your ASV, confirm the IP ranges and domains in scope, and update any authentication material the scanner needs.
- Initial scan runs -- typically overnight or over a weekend to avoid business impact.
- Results are delivered within a few business days. Your team reviews findings with the ASV.
- Disputes are raised for false positives, compensating controls, or findings that do not apply in context. The ASV evaluates evidence and either accepts the dispute (the finding is suppressed) or rejects it (you remediate).
- Remediation -- you patch, reconfigure, or retire affected components.
- Rescan -- the ASV reruns the scan or a targeted subset. If clean, the quarter passes. If not, loop back.
- Final passing report is archived for your QSA and retained for at least 12 months.
PCI DSS does not prescribe an absolute remediation deadline inside a quarter, but practical limits apply: the quarter itself is the deadline. If you cannot remediate and rescan to a passing result before the next quarter begins, you have a PCI DSS finding. Well-run programs aim to pass the first scan of every quarter within two to three weeks, leaving buffer for unexpected findings.
Selecting an ASV
The PCI SSC does not rank ASVs, so selection is up to you. Evaluate prospective ASVs against the following criteria:
- PCI SSC listing -- confirm the firm is on the current ASV list. Accreditation lapses.
- Scanning technology -- ask which engine powers their scanning (commercial, open source, proprietary) and how frequently their vulnerability signatures update.
- Coverage of your stack -- if you run container workloads, serverless functions, or unusual platforms, confirm the ASV can scan them.
- Authenticated scan support -- most PCI DSS ASV scans are unauthenticated, but some findings require credentialed validation during dispute.
- Analyst depth -- an ASV with strong analysts accelerates dispute resolution dramatically. Ask how many certified ASV employees they have and what response SLAs they offer.
- Reporting portal -- review the portal used to schedule scans, review findings, manage disputes, and download attestations. Clunky portals waste security team time every quarter.
- Integration options -- API, SSO, ticketing integrations (Jira, ServiceNow), and export formats that feed your evidence system of record.
- Pricing model -- per-IP, per-domain, or flat-rate. Confirm rescan fees and what "significant change" scans cost.
- Dispute and escalation process -- how quickly can you get an analyst on a call when a finding is blocking a passing scan?
- References -- ask for references from organizations of similar size and stack.
Many organizations pair their ASV with the same firm that provides their QSA services, though they are distinct programs with distinct accreditations. If you choose the same firm, confirm they can operationally keep the two functions independent.
Internal scanning and the bigger PCI DSS picture
External ASV scans are only half of PCI DSS Requirement 11.3. You must also perform internal vulnerability scans at least quarterly and after significant change, re-scanning until all high-risk vulnerabilities are resolved. Internal scans can be performed by your own staff with commercial scanning tools -- they do not require an ASV. PCI DSS v4.0 tightens expectations on internal scan coverage, authenticated scanning, and risk-ranking of findings.
Together, ASV scans, internal scans, penetration testing, and segmentation testing make up the testing stack that Requirement 11 demands. ASV reports feed your Attestation of Compliance, your QSA's testing procedures, and your own board reporting on vulnerability posture.
How this fits into PCI DSS compliance
Quarterly ASV scans are one of the most visible artifacts in a PCI DSS program. Your acquirer often reviews ASV attestations alongside your SAQ or ROC, card brands may audit ASV records during a breach investigation, and QSAs use ASV history as an early signal of program maturity. A clean ASV history with promptly resolved findings tells a compelling story. A history of missed quarters, unresolved disputes, or gaps in coverage does the opposite and almost always triggers deeper testing during an assessment.
ASV scanning is also closely tied to PCI DSS scope. Every time your external attack surface changes -- new domains, new public IPs, new cloud environments -- the ASV scope must be updated. Organizations that treat the ASV contract as set-and-forget often discover during an assessment that their ASV has been scanning a stale inventory for quarters, invalidating the PCI DSS evidence they thought they had.
Common mistakes
- Scoping the ASV to a subset of internet-facing assets, leaving cardholder-data-affecting systems unscanned.
- Ignoring new domains and cloud resources until the ASV renewal, creating gaps that a QSA will discover.
- Allowing firewall or WAF rules to block the ASV scanner, producing "unable to scan" findings that invalidate the scan.
- Suppressing findings without documented compensating controls -- ASV disputes must be evidence-backed.
- Missing a quarter because a rescan slipped, which produces a PCI DSS finding that carries into the ROC.
- Treating ASV scans as a substitute for internal scans or penetration testing -- they are not interchangeable under PCI DSS.
- Relying on default credentials or test accounts on any internet-facing system, which is an automatic ASV failure.
- Procuring ASV services purely on price, then discovering the support model cannot keep up with dispute volume.
How episki helps
episki centralizes every ASV scan, dispute, and remediation ticket against the specific PCI DSS requirement it supports, so quarter-over-quarter evidence is always at hand. We connect to your ASV portal, reconcile scanned assets against your cloud inventory, and route findings to engineering owners with remediation SLAs tied back to the PCI DSS requirement they satisfy. See how we support continuous PCI DSS evidence on the PCI DSS hub.
Related topics
Related terms
Frequently asked questions
Continue exploring
PCI DSS Compliance Levels
Framework topic
PCI DSS Network Segmentation
Framework topic
What is PCI DSS?
Framework overview
What is Access Control?
Glossary definition
What is an Approved Scanning Vendor (ASV)?
Glossary definition
Drata vs Secureframe
Head-to-head comparison
episki vs Drata
See how we compare
Defined Roles in PCI: The Compliance Mistakes That Fly Under the Radar
From the blog