PCI ASV Vulnerability Scan: A Complete Guide for Merchants and Service Providers

If you accept credit or debit card payments and store, process, or transmit cardholder data, PCI DSS requires quarterly external vulnerability scans conducted by an Approved Scanning Vendor. This is Requirement 11.3.2 in PCI DSS v4.x. It is not optional, and it is not satisfiable by running your own internal tools. The scan must come from a vendor that the PCI Security Standards Council has tested, certified, and placed on its official ASV list.

PCI DSS v4.0, which became mandatory as of April 1, 2025, expanded ASV scan requirements significantly. SAQ A merchants, who were previously exempt from ASV scanning, are now required to meet Requirement 11.3.2 if their e-commerce environment hosts the page that redirects or embeds a third-party payment form. This change brought a substantial new population of merchants into ASV scanning scope for the first time.

This guide covers what an ASV scan is, how it differs from internal vulnerability scans and penetration tests, what needs to be included in scope, how the scan works, what passing means, and what to do when findings include SSL/TLS vulnerabilities that directly affect your web server’s certificate configuration.

Three Types of Scans: ASV, Internal, and Penetration Test

Merchants and service providers regularly confuse three distinct PCI DSS scanning requirements. They test different things, use different methodologies, can be performed by different parties, and satisfy different requirements. Performing one does not satisfy the others.

A penetration test is not a vulnerability scan. A vulnerability scan identifies and catalogs known vulnerabilities using automated signature matching. A penetration test attempts to exploit vulnerabilities to demonstrate real-world attack paths. PCI DSS requires both. Many organizations perform only one and believe they have satisfied both requirements. They have not.

What an Approved Scanning Vendor Is and Why You Cannot Substitute

An Approved Scanning Vendor is an organization that has had its scanning tools and processes tested and certified by the PCI SSC. The PCI SSC maintains a public list of ASVs at pcisecuritystandards.org. To appear on this list, a vendor must pass the ASV qualification program, which tests their scanning solution against a defined set of test cases and validates that their report output meets PCI SSC requirements. ASV certification is renewed annually.

The scan cannot be performed by your own staff, regardless of their qualifications, and cannot be performed using tools you purchased and run yourself. This is not a bureaucratic technicality. The independence requirement exists because an internal team scanning its own environment has obvious incentive to configure the scan narrowly or interpret findings favorably. The ASV’s scanning solution has been independently validated; your internal tools have not.

Any company on the PCI SSC ASV list can legally satisfy Requirement 11.3.2. The ASV list contains hundreds of vendors ranging from large security firms to specialist compliance scanning services. All have passed the same baseline certification. The quality of remediation guidance, reporting clarity, dispute handling, and customer support varies considerably beyond the baseline certification requirements.

PCI DSS v4.0 Changes That Affect ASV Scanning (Mandatory Since April 2025)

PCI DSS v4.0 made several changes to scanning requirements that took effect April 1, 2025. Organizations still operating under v3.2.1 compliance postures are now non-compliant.

SAQ A merchants now require ASV scans

This is the most significant change in terms of merchant impact. SAQ A is the self-assessment questionnaire for merchants whose e-commerce environment redirects all payment transactions to a third-party service provider, or that use an embedded payment form from a PCI-compliant third party. These merchants have minimal cardholder data exposure on their own systems.

Previously, SAQ A merchants were not required to perform ASV scans because their direct cardholder data exposure was considered negligible. However, analysis of breach patterns showed that SAQ A merchant websites were being compromised through Magecart-style script injection attacks that modified the payment redirect page to capture card data before the redirect occurred. The compromise was at the merchant’s website, not at the third-party processor.

PCI DSS v4.0 added Requirement 11.3.2 to SAQ A for the specific system that hosts the payment redirect or embedded payment form page. Any e-commerce merchant using an iframe or redirect payment integration must now have that page’s hosting environment scanned quarterly by an ASV. This applies even if the merchant never touches cardholder data directly.

If you are a small e-commerce merchant using Stripe, PayPal, Square, or any similar payment processor that uses an iframe or redirect, and you have never performed an ASV scan because you assumed your SAQ A status exempted you, review your SAQ A compliance obligations under PCI DSS v4.0. The exemption no longer applies to the page hosting the payment form. You now need quarterly ASV scans of that system.

Internal scans now require authenticated scanning

Requirement 11.3.1.1 in PCI DSS v4 requires that internal vulnerability scans use authenticated scanning for applicable system components. Authenticated scans log into the target system using provided credentials and can identify vulnerabilities in installed software, configuration settings, and local services that are not visible from the network without authentication. Unauthenticated internal scans miss a significant portion of vulnerabilities. This change requires updating internal scan processes for organizations that previously ran unauthenticated internal scans.

New requirement 11.6.1: Payment page integrity monitoring

Requirement 11.6.1 requires that public-facing payment pages be monitored for unauthorized changes to HTTP headers and payment page content as received by the customer’s browser. This is specifically designed to detect Magecart-style script injections that add malicious JavaScript to payment pages. This is a separate requirement from ASV scanning but addresses the same threat vector that motivated the SAQ A ASV requirement change.

Who Needs ASV Scans: Scope Determination

ASV scan scope includes all external-facing IP addresses and hostnames that could affect the security of cardholder data. Scope determination is one of the most consequential compliance decisions an organization makes, because including unnecessary systems wastes resources and missing in-scope systems creates compliance gaps.

Systems that must be in scope

• All external IP addresses of systems that store, process, or transmit cardholder data
• All external IP addresses of systems that could affect the security of the cardholder data environment, including perimeter security devices, network infrastructure, and web servers
• All DNS names that resolve to in-scope external IP addresses
• Web servers hosting checkout pages, payment forms, or payment redirect pages
• Email and remote access systems that could be used to access the cardholder data environment
• For SAQ A merchants under PCI DSS v4.0: the web server hosting the page containing the payment redirect or iframe

Systems that may be out of scope

Systems that are completely isolated from cardholder data and all paths that could reach cardholder data are out of scope. Scope can be reduced through segmentation: network controls that prevent any connectivity between out-of-scope systems and the cardholder data environment. The segmentation must be tested annually (penetration test requirement 11.4.3 specifically covers segmentation testing).

Cloud-hosted systems present scope complexity. If your web server, database, or any other in-scope system is hosted in AWS, Azure, or GCP, the external IP addresses assigned to those instances are in scope. The cloud provider’s infrastructure itself is not in scope. Your configuration running on that infrastructure is. Cloud provider compliance documentation confirms which responsibilities are shared and which are yours.

Scope creep is a common ASV compliance problem: organizations include too many systems in scope, increasing scan cost and complexity, while still missing genuinely in-scope systems. Work with your ASV or a qualified security assessor to formally document your cardholder data environment, data flows, and network boundaries before determining the scan scope. Including a system that is genuinely out of scope wastes money; excluding a system that is in scope creates a compliance gap.

How the ASV Scan Process Works

The ASV scan process has defined steps that both the merchant and the ASV follow. Understanding the process helps organizations prepare properly and interpret results accurately.

Step 1: Scope submission

You provide the ASV with the list of IP addresses and hostnames to be scanned. This must include all in-scope external addresses. Missing an address that is later found to be in scope invalidates the scan for compliance purposes. The ASV may also request additional context about the environment to configure the scan appropriately.

Step 2: Pre-scan notification

The ASV provides advance notice of the scan window. This allows you to whitelist the ASV’s scanning IP addresses in any rate-limiting or intrusion prevention systems that might block or throttle the scan traffic. Blocking the scan traffic means the ASV cannot fully test the system, which typically results in a failed scan for incomplete coverage. You should not add special permissions or open firewall rules for the scan that would not exist for normal external access; this defeats the purpose of testing the actual security posture.

Step 3: The scan itself

The ASV’s automated scanning tools connect to your external IP addresses and attempt to enumerate services, identify software versions, and test for known vulnerabilities using techniques that approximate what an external attacker would use. The scan covers all in-scope addresses and tests common vulnerabilities including: open ports hosting services that should not be externally accessible, software with known CVEs (Common Vulnerability Enumerations), TLS/SSL misconfigurations, weak cipher suites, missing security headers, and application-layer issues detectable from the outside.

The scan generates findings that are assigned CVSS (Common Vulnerability Scoring System) scores from 0 to 10. A CVSS score of 4.0 or higher is a finding that must be resolved before the scan can pass. The PCI SSC ASV Program Guide defines specific findings that are always considered fail conditions regardless of CVSS score (the Special Note Vulnerabilities list).

Step 4: Results review and remediation

The ASV provides a scan report listing all findings with CVSS scores, descriptions, and recommended remediation steps. Your team reviews the findings, identifies which are genuine vulnerabilities versus false positives, implements remediation for genuine findings, and documents false positives with justification for the dispute process.

Step 5: Rescan if necessary

If the initial scan identifies findings at CVSS 4.0 or above, you remediate those findings and request a rescan. The rescan confirms that the vulnerabilities have been resolved. There is no defined limit on rescans; you rescan until all findings are below CVSS 4.0 or have been formally disputed through the exception process. The clock for the quarterly requirement starts from the date of the initial scan, not from the date of the passing rescan.

Step 6: Passing scan report

Once all findings are resolved or formally accepted through the dispute process, the ASV issues a passing Attestation of Scan Compliance (ASC). This document is your compliance evidence for Requirement 11.3.2. You provide it to your acquirer, payment brand, or QSA as part of the compliance validation process.

What ‘Passing’ Actually Means in an ASV Scan

A passing ASV scan is not a scan with zero findings. It is a scan where no findings have a CVSS score of 4.0 or higher that have not been resolved or formally disputed through the exception process.

CVSS scores below 4.0 are informational findings that do not block the scan from passing. They are reported in the findings list and should be reviewed as part of ongoing vulnerability management, but they do not prevent issuance of the passing ASC. Prioritizing remediation of sub-4.0 findings is good security practice but is not required for the scan to pass.

The dispute and exception process

Not every finding reported by an ASV scan is a genuine exploitable vulnerability in your environment. False positives occur when: the scan tool misidentifies a service version based on banner information that has been modified, a vulnerability is present in the installed software version but a backported patch has addressed it without incrementing the version number (common in Linux distributions), or the finding describes a vulnerability in a component that is not actually deployed or reachable in your specific configuration.

The ASV dispute process allows you to challenge findings you believe are false positives. You submit a dispute with evidence supporting your position. The ASV reviews the evidence, applies their own judgment, and either accepts the dispute (removing the finding from the blocking list) or rejects it (requiring remediation). Accepted disputes are documented in the scan report.

Acceptable risk exceptions also exist for findings that represent real vulnerabilities that cannot be remediated in the near term due to business or technical constraints. These require documented compensating controls and are evaluated by your QSA or acquirer for acceptability. They are not within the ASV’s authority to accept unilaterally.

SSL/TLS Findings in ASV Scans: What to Expect and How to Fix Them

SSL and TLS configuration issues are among the most common ASV scan findings. They are also directly addressable and directly relevant to this site’s audience. Addressing SSL/TLS findings before the first ASV scan significantly increases the likelihood of a passing result on the initial scan.

Running your domains through the SSL Labs test (ssllabs.com/ssltest) before scheduling your ASV scan is one of the most practical preparation steps available. SSL Labs evaluates TLS protocol support, cipher suites, certificate chain, HSTS, OCSP stapling, and dozens of other parameters that ASV scanners also test. An A or A+ SSL Labs grade correlates strongly with a clean ASV scan for SSL/TLS findings. Address any SSL Labs warnings before the ASV scan.

Choosing an ASV: What the Certification Covers and What It Does Not

Every ASV on the PCI SSC list has passed the same certification baseline. The certification validates that the ASV’s scanning tools can detect the vulnerabilities in the PCI SSC test cases and generate reports in the required format. It does not certify the quality of the ASV’s remediation guidance, customer support, reporting clarity, dispute handling, or integration with your broader compliance program.

For small merchants doing their first ASV scan, the primary considerations are cost, ease of scheduling, and quality of remediation guidance in the report. A scan report that identifies a finding with a CVSS score but provides no actionable guidance on how to fix it is technically compliant but operationally useless.

For larger organizations or those with complex infrastructure, additional considerations include: the ASV’s experience with your specific technology stack (cloud infrastructure, specific web server and database versions), the quality of the dispute process, integration with your vulnerability management platform, and support for continuous monitoring between quarterly scans.

The PCI SSC publishes the complete ASV list at pcisecuritystandards.org. Verifying that a vendor is on the current list before purchasing scans is mandatory: ASV certification lapses annually and unlisted vendors cannot produce valid compliance documentation.

Managing the Quarterly Scan Cadence

The PCI DSS requirement is quarterly external vulnerability scans, meaning at least once every three months. The quarterly window begins from the date of the previous scan, not from the calendar quarter. Organizations that schedule scans on fixed calendar dates (January, April, July, October) risk falling outside the 90-day window if a scan is delayed.

Planning the quarterly cadence around your change management cycle is operationally sensible. Running an ASV scan immediately after a major infrastructure change (new server deployed, firewall reconfigured, new cloud service added) incorporates the changed surface into the compliance record. Running it immediately before planned maintenance windows means findings identified can be incorporated into the maintenance work rather than requiring a separate remediation effort.

Scan failures due to findings require rescans. The time between the initial scan and the passing rescan can extend beyond the expected quarterly window if remediation takes longer than anticipated. Organizations with historically clean ASV scan records have more flexibility; those with known infrastructure debt in their TLS configuration or exposed services should plan for potential rescan time before the compliance deadline.

Frequently Asked Questions

What is a PCI ASV scan?

A PCI ASV scan is an external vulnerability scan of your internet-facing systems, performed by an Approved Scanning Vendor (ASV) certified by the PCI Security Standards Council. It satisfies PCI DSS Requirement 11.3.2, which mandates quarterly external vulnerability scanning for organizations that store, process, or transmit cardholder data or that operate systems that could affect cardholder data security. The scan tests your external IP addresses for known vulnerabilities that an attacker could exploit from outside your network.

Who needs an ASV scan under PCI DSS v4.0?

Any merchant or service provider required to validate PCI DSS compliance who has external-facing systems in scope for PCI DSS needs quarterly ASV scans. Critically, PCI DSS v4.0 (mandatory since April 1, 2025) added Requirement 11.3.2 to SAQ A for e-commerce merchants whose websites host the page containing a third-party payment redirect or embedded payment form. SAQ A merchants who previously believed they were exempt from ASV scanning should review their obligations under v4.0.

What does a passing ASV scan require?

A passing scan requires that no findings have a CVSS score of 4.0 or higher that have not been resolved or formally disputed through the ASV’s dispute process. Findings below CVSS 4.0 are informational and do not block the scan from passing. Common reasons for initial scan failure include TLS 1.0 or 1.1 still enabled, weak cipher suites, expired certificates, self-signed certificates on public-facing systems, and open ports running services that should not be externally accessible.

Can I perform the ASV scan myself using my own tools?

No. PCI DSS Requirement 11.3.2 explicitly requires scans performed by an ASV on the PCI SSC approved list. You cannot satisfy this requirement using internal staff or tools, regardless of the qualifications of your team or the tools they use. The independence requirement is fundamental to the compliance process: the ASV’s scanning solution has been independently certified; your internal tools have not. Internal vulnerability scanning satisfies the separate Requirement 11.3.1 (quarterly internal scans), which does not require an ASV.

How do SSL certificate issues affect an ASV scan?

SSL/TLS configuration weaknesses are among the most common ASV scan findings and some have CVSS scores above 4.0, meaning they block the scan from passing. TLS 1.0 and TLS 1.1 being enabled, weak cipher suites (RC4, 3DES, export ciphers), SSL 3.0 enabled, and expired or self-signed certificates on public-facing systems all produce failing findings. Running the SSL Labs test on all in-scope domains before the ASV scan is a practical preparation step: an A or A+ SSL Labs grade substantially reduces the likelihood of SSL-related ASV scan failures.

What happens if my ASV scan fails?

Remediate the findings that caused the failure and request a rescan from the ASV. There is no limit on rescans. Once all findings are below CVSS 4.0 or have been formally disputed and accepted, the ASV issues the Attestation of Scan Compliance. For findings you believe are false positives, submit a dispute to the ASV with supporting evidence. The ASV reviews the evidence and either accepts or rejects the dispute. Accepted disputes are documented in the final scan report. The quarterly compliance clock runs from the date of the initial scan; delays in remediation and rescanning do not restart the clock.