The Payment Card Industry Data Security Standard (PCI DSS) has established rigorous requirements to safeguard sensitive cardholder data and ensure the security of payment systems globally. Among these standards is the PCI Approved Scanning Vendor (ASV) Program, which is vital in identifying and addressing vulnerabilities in external-facing systems. This blog explores the PCI ASV Program, detailing its purpose, scope, importance, and scan reporting requirements. It serves as a roadmap for businesses looking to ensure compliance with PCI DSS and fortify their cybersecurity posture.

---

What Is the PCI ASV Program?

The PCI ASV Program, a structured framework managed by the PCI Security Standards Council (PCI SSC), is crucial to the security of payment systems. It enables qualified companies, known as Approved Scanning Vendors (ASVs), to perform external vulnerability scans on merchants’ and service providers’ systems. These scans, a key component of PCI DSS (PCI Data Security Standard) Requirement 11.3.2, are mandated to be conducted at least once every three months by an ASV.

ASVs, certified by the PCI SSC, use specialized scanning tools, methodologies, and processes to identify vulnerabilities in internet-facing components that could potentially expose sensitive cardholder data. By ensuring entities comply with PCI DSS requirements, ASVs significantly reduce the risk of data breaches.

You can find an updated list of certified ASVs on the PCI SSC website.

---

Why Is the PCI ASV Program Important?

Given the ever-increasing complexity of cyberattacks, the PCI ASV Program is essential for maintaining the security of cardholder data environments (CDEs). Here’s why the program is vital:

1. Compliance with PCI DSS is not just a recommendation; it’s a necessity. Requirement 11.3.2 mandates that an ASV conduct quarterly external vulnerability scans. Non-compliance can result in severe penalties, loss of customer trust, and significant financial liabilities. The ASV Program is a crucial tool in avoiding these risks.
2. Proactive Risk Management: The PCI ASV Program is about meeting compliance requirements and staying ahead of potential threats. By identifying weaknesses in internet-facing systems, businesses can address them before malicious actors can exploit them, giving them a sense of preparedness and control.
3. Standardization and Assurance: The program ensures that scans are performed consistently across entities, providing acquirers, payment brands, and customers with assurance that vulnerabilities are being managed effectively.
4. Enhanced Security Posture: Regular scans help organizations build a robust cybersecurity framework by identifying and mitigating threats, reducing the likelihood of a data breach.
5. Consumer Trust: By demonstrating compliance with PCI DSS, businesses reinforce their commitment to protecting sensitive customer data, fostering trust and loyalty.

---

Can a Merchant or Service Provider Perform its own External Vulnerability Scanning?

The short answer is No. Merchants and service providers must use only ASVs to perform the quarterly external vulnerability scans required by PCI DSS Requirement 11.3.2, and the ASV must manage the ASV scan solution. Some ASV scan solutions may, while still under the control and management of the ASV, be started remotely by a scan customer (for example, via an ASV’s web portal and/or ASV’s scan solution) to allow a scan customer to select the best times to scan their cardholder data environment and define which of the customer’s components are to be scanned. However, only authorized ASV Employees are permitted to configure any settings (for example, modify or disable any vulnerability checks, assign severity levels, alter scan parameters, etc.) or modify the scan output. Additionally, the ASV scan solution must not allow anyone other than an authorized ASV Employee to alter or edit any reports or revise any results.

The approved ASV Companys and the scan solutions are listed here.

Roles and Responsibilities

Approved Scanning Vendors

An ASV is an organization with an ASV scan solution (i.e., a set of security services and tools) used to validate adherence to the external scanning requirements of PCI DSS Requirement 11.3.2. The ASV’s ASV scan solution must be tested by an ASV Validation Lab and approved by PCI SSC before that ASV is added to the list of Approved Scanning Vendors.

ASVs are responsible for the following:

• Performing external vulnerability scans in accordance with PCI DSS Requirement 11.3.2, this document and other supplemental guidance published by PCI SSC.
• Maintaining the security and integrity of systems and tools used to perform such scans is a key responsibility of ASVs. This commitment to security should reassure businesses and instill confidence in the PCI ASV Program.
• Ensuring that such scans:
  • Do not impact the normal operation of the scan customer environment.
  • Do not penetrate or intentionally alter the scan customer environment.
• Scanning all IP address ranges, domains, components, etc., provided by the scan customer to identify active components and services.
• Consulting with the scan customer to determine whether components found but not provided by the scan customer should be included in the scope of the scan.
• Providing a determination as to whether the scan customer’s components have met the scanning requirements.
• Provide adequate documentation within the scan report to demonstrate compliance or non-compliance of the scan customer’s components with the scanning requirements.
• Submitting (to the scan customer) the ASV Scan Report Attestation of Scan Compliance cover sheet (an “Attestation of Scan Compliance”) and the scan report in accordance with the instructions of the scan customer’s acquirer(s) and/or Participating Payment Brand(s).
• This includes the required scan customer and ASV Company attestations in the scan report in accordance with this document and applicable ASV Program requirements.
• Retaining scan reports and related work papers and work products for three (3) years, as required by the ASV Qualification Requirements.
• Providing the scan customer with a means for disputing findings of scan reports.
• Maintaining an internal quality assurance process for its ASV Program-related efforts in accordance with this document and applicable ASV Program requirements.

Scan Customers

Scan customers are responsible for the following:

• Maintaining compliance with PCI DSS at all times, including properly maintaining the security of their Internet-facing systems, is a crucial responsibility of scan customers. This sense of responsibility and accountability is integral to the success of the PCI ASV Program.
• Selecting an ASV from the list of Approved Scanning Vendors from the Website to conduct quarterly external vulnerability scanning in accordance with PCI DSS Requirement 11.3.2 and this document using an ASV scan solution.
• Per the scan customer’s due diligence processes, perform due diligence in the ASV selection process to obtain assurance as to the ASV’s qualification, capability, experience, and level of trust in performing the scanning services required by PCI DSS.
• Monitoring Internet-facing systems, active protection systems, and network traffic during the scan to the degree deemed appropriate by the scan customer assures an acceptable level of trust is maintained.
• Defining the scope of external vulnerability scanning, which includes:
  • Providing the IP addresses and/or domain names of all Internet-facing systems to the ASV so the ASV can properly conduct a full scan.
  • Implementing proper network segmentation for any external-facing components excluded from the scope.

See “What Is in Scope for PCI ASV Scans” for more information.

• Ensuring that devices do not interfere with the ASV scan, including:
  • Configuring active protection systems so they do not interfere with the ASV’s scan, as required by this document. See Section 5.6, “ASV Scan Interference.”
  • Coordinating with the ASV if the scan customer has load balancers in use.
• Coordinating with the scan customer’s Internet service provider (ISP) and/or hosting providers to allow ASV scans.
• Attesting to proper scoping and network segmentation (if IP addresses or other components are excluded from scan scope) within the ASV scan solution.
• Providing sufficient documentation to the ASV to fully enable the ASV’s investigation and resolution of disputed findings, such as suspected false positives, and providing related attestation.
• Providing sufficient documentation to the ASV to fully enable the ASV’s evaluation of any compensating controls implemented or maintained by the scan customer. See Section 7.8 of the program guide, “Addressing Vulnerabilities with Compensating Controls.”
• Reviewing the scan report and correcting any noted vulnerabilities that result in a non-compliant scan.
• Arrange with the ASV to re-scan any non-compliant systems to verify that all “High” and “Medium” severity vulnerabilities have been resolved to obtain a passing quarterly scan. “Vulnerability Severity Levels Based on the NVD and CVSS.”
• Submitting the completed ASV scan report to the scan customer’s acquirer(s) and/or Participating Payment Brand(s), as directed by the Participating Payment Brands.

What Is in Scope for PCI ASV Scans?

This is one of the biggest sources of confusion regarding ASV scanning. Just as with scoping a PCI DSS assessment, all system components that are not adequately segmented away from the Cardholder Data Environment (CDE) are in scope. This means that if a system can communicate with anything in your CDE or can affect the security of anything in your CDE, it is in scope for ASV scanning.

ALL public IP (Internet Protocol) addresses routed to the in-scope environment and ALL URLs (Uniform Resource Locator) that point to any of the public IP addresses MUST be included in the scans. Failure to do so may result in an inadequate ASV Scan and a non-compliant report.

The scope of an ASV scan is a critical aspect of the PCI ASV Program. It determines which components of a merchant’s or service provider’s infrastructure must be scanned. Here’s a breakdown of what is typically in scope:

• Internet-Facing Components
  • All external components that are connected to or provide access to the CDE must be scanned. This includes:
    • Web servers
    • Mail servers
    • Firewalls and routers
    • Web server URLs to “hidden” directories that cannot be reached by crawling the website from the home page
• Cardholder Data Environment (CDE)
  • The CDE comprises systems, people, and processes that store, process, or transmit cardholder data. This includes any system component that could impact its security.
• Vulnerable Services and Protocols
  • Services such as DNS, mail, and remote access software are assessed for vulnerabilities. Deprecated protocols like SSL or early versions of TLS must also be identified and addressed.
• Embedded Links and Scripts
  • Scripts loaded and executed on payment pages, especially those originating from external domains, must be scanned for vulnerabilities.
• Load Balancers and Network Segmentation
  • Scans must account for load balancers to ensure comprehensive testing. If implemented, network segmentation must be validated to exclude non-CDE components from the scan scope.
• Virtualized and Cloud Environments
  • The scan scope also includes virtual machines, hypervisors, and cloud-based systems that interact with the CDE.

The scan customer (merchant or service provider) must define and attest to the scope of the scan before the ASV finalizes the report. The customer is held accountable if an external-facing system is excluded from the scan and later becomes the source of a data breach.

ASV “Discovery” and Scope Validation

ASVs must, at a minimum, perform the below actions to identify whether any scoping discrepancies exist in the information provided by the scan customer. Information about any scoping discrepancies must be indicated on the Attestation of Scan Compliance under A.3, “Scan Status” (Number of components found by ASV but not scanned because scan customer confirmed components were out of scope). Although this information must be reported as noted above, the ASV should disregard this information in making its PCI DSS compliance determination:

• Include any IP address or domain previously provided to the ASV and still owned or used by the scan customer that has been removed at the request of the scan customer.
• For each domain provided, look up its IP address to determine whether the scan customer already provided it.
• For each domain provided, perform DNS forward and reverse lookups of common host names—such as “www,” “mail,” etc.—that were not provided by the scan customer.
• Identify any IP addresses found during MX record DNS lookup.
• Identify any IP addresses outside the scope reached via web redirects from in-scope web servers (this includes all forms of redirect, including JavaScript, Meta redirect, and HTTP 30x codes).
• Match domains found during crawling to user-supplied domains to find undocumented domains belonging to the scan customer.

FQDNs vs IP

Using an Approved Scanning Vendor (ASV) does not always guarantee that vulnerability scans will be performed correctly. Some ASV solutions fail to handle Fully Qualified Domain Names (FQDNs) properly. Instead of scanning the FQDN, they may only perform a DNS lookup and scan the associated IP address. This approach can lead to significant issues.

When web traffic is directed to an IP address, it often lands on a generic page or a default server response. However, using the correct FQDN ensures that traffic is routed to the intended website via the host header. Host headers are critical for web services that host multiple websites on the same server or for systems like Web Application Firewalls (WAFs), proxy servers, or load balancers. These systems rely on the host header to direct incoming requests to the appropriate internal resources. If an ASV solution cannot handle FQDNs correctly, the scan may only target a landing page, failing to assess the actual website and its vulnerabilities.

The ASV Program Guide, specifically Section 5.5, titled “ASV Scan Scope Definition,” emphasizes the importance of ensuring that scans cover all unique entry points into system components across the entire in-scope infrastructure. This includes properly handling FQDNs to ensure comprehensive and accurate scanning.

In summary, ensuring that your ASV solution can correctly process FQDNs is essential for accurate vulnerability scanning and compliance with PCI DSS requirements.

ASV Scan Interference

Besides defining the scope, this is one of the most significant items of confusion regarding ASV scanning. 

If an ASV detects that an active protection system has actively blocked or filtered a scan, then the ASV must handle it per Section 7.6, “Resolving Inconclusive Scans,” in the program guide.  In order to ensure that reliable scans can be conducted, the ASV scan solution must be allowed to perform scanning without interference from active protection systems, where “active” denotes security systems that dynamically modify their behavior based on information gathered from non-attack network traffic patterns. Non-attack traffic refers to potentially legitimate network traffic patterns that do not indicate malformed or malicious traffic. In contrast, attack traffic includes, for example, malicious network traffic patterns or patterns that match known attack signatures, malware, or packets exceeding the maximum permitted IP packet size.

Examples of active protection systems that dynamically modify their behavior include, but are not limited to:

• Intrusion prevention systems (IPS) that drop non-malicious packets based on previous behavior from the originating IP address (for example, blocking all traffic from the originating IP address for a period of time because it detected one or more systems being scanned from the same IP address)
• Web application firewalls (WAF) block all traffic from an IP address based on the number of events exceeding a defined threshold (for example, more than three requests to a login page per second)
• Network security controls that shun/block an IP address upon detection of a port scan from that IP address
• Network security controls that block IP address ranges because an attack was perceived based on previous network traffic patterns.
• Quality of Service (QoS) devices that limit certain traffic based on traffic volume anomalies (for example, blocking DNS traffic because DNS traffic exceeded a defined threshold)
• Spam filters that blacklist a sending IP address based on certain previous SMTP commands originating from that address

Such systems may react differently to an automated scanning solution than they would react to a targeted hacker attack, which could cause inaccuracies in the scan report.

Systems that consistently block attack traffic while consistently allowing non-attack traffic to pass (even if the non-attack traffic follows directly after attack traffic) typically do not cause ASV scan interference. Examples of these security systems (that do not dynamically modify their behavior; rather, they maintain consistent, static behavior based on rules or signatures) include, but are not limited to:

• Intrusion detection systems (IDS) log events, track context, or have a multifaceted approach to detecting attacks, but action is limited to alerting (there is no intervention).
• Web application firewalls (WAF) detect and block SQL injections but let non-attack traffic from the same source pass.
• Intrusion prevention systems (IPS) that drop all occurrences of a certain attack but let non-attack traffic from the same source pass.
• Network security controls that are configured to always block certain ports but always keep other ports open.
• VPN servers that reject entities with invalid credentials but permit entities with valid credentials.
• Antivirus software that blocks, quarantines, or deletes all known malware based on a database of defined “signatures” but permits all other perceived clean content.
• Logging/monitoring systems, event and log aggregators, reporting engines, etc.

If the ASV scan cannot detect vulnerabilities on Internet-facing systems because an active protection system blocks it, those vulnerabilities will remain uncorrected and may be exploited by an attacker whose attack patterns don’t trigger the active protection mechanism.

Temporary configuration changes may need to be made by the scan customer to remove interference during an ASV scan.

Due to the remote nature of external vulnerability scans and the need mentioned previously to conduct an ASV scan without interference from active protection systems, certain temporary configuration changes to the scan customer’s network devices may be necessary to obtain a scan that accurately assesses the scan customer’s external security posture. Note, per above, that temporary configuration changes are not required for systems that consistently block attack traffic while consistently allowing non-attack traffic to pass (even if the non-attack traffic follows directly after attack traffic).

The changes in this section are considered temporary and are only required for the duration of the ASV scan. They only apply to external-facing components in scope for external vulnerability scans required by PCI DSS Requirement 11.3.2. Scan customers are encouraged to work with the ASV to perform secure scans at least once every three months that do not unnecessarily expose the scan customer’s network—but also do not limit the final results of the ASV scans—as follows:

• Agree on a time for the ASV scan window to minimize how long changed configurations are in place.
• Conduct the ASV scan during a maintenance window under the scan customer’s standard change control processes, with full monitoring during the ASV scan.
• Configure the active protection systems to either Monitor and log, but not act against, the originating IP address(es) of the ASV or
• Allow non-attack traffic to pass consistently (even if the non-attack traffic immediately follows attack traffic)

Reapply the previous configurations as soon as the ASV scan is complete.

Note: The intent of these temporary configuration changes is to ensure that an active protection system, such as an IPS reacting dynamically to traffic patterns, does not interfere with the ASV scan in a manner that would provide the ASV scan solution with a different view of the environment than the view an attacker would have. ASV scans tend to be “noisy” as they generate a lot of traffic in a short period of time. This is generally to ensure that an ASV scan can be completed as quickly as possible. However, this type of approach can also lead to a high rate of reaction by active intrusion-prevention systems. An attacker will generally attempt to restrict the volume of their scans so they are stealthier and less likely to trigger an event that may be noticed. Thus, the high-volume scans typically performed by ASVs are significantly more likely to trigger an active protection mechanism than those of an attacker.

Temporary configuration changes do not require the scan customer to “white list” or provide the ASV with a higher level of network access. Rather, the scan customer must ensure that any triggers, such as volume-based or correlated IP address thresholds, are not activated by the ASV scan and that the scan is allowed to complete. The intent is that the ASV be provided the same network-level view as an actual attacker throughout the scan.

---

The ASV Scan Process: Key Phases

The ASV scan process is structured to ensure comprehensive vulnerability assessment and remediation. Below is an overview of the major phases:

1. Scoping

• The scan customer defines the scope of the scan, including all internet-facing IP addresses, domains, and system components. Proper segmentation must be implemented to exclude out-of-scope components.

2. Scanning

• The ASV performs external vulnerability scans using its validated scan solution. The scans must be non-disruptive and should not interfere with the customer’s environment.

3. Reporting and Remediation

• The ASV generates a detailed scan report highlighting vulnerabilities, their severity, and remediation steps. The customer must address all “High” and “Medium” severity vulnerabilities before achieving a passing scan.

4. Dispute Resolution

• If the customer disputes any findings, they must provide evidence to the ASV, which evaluates the dispute and updates the report accordingly.

5. Rescan and Final Reporting

• A rescan is conducted to verify that vulnerabilities have been resolved. The final report is then submitted, indicating whether the scan passed or failed.

Note: To be considered compliant with the external vulnerability scanning requirement of PCI DSS Requirement 11.3.2, the scan customer infrastructure must be tested and shown to be compliant in accordance with this document and applicable ASV Program requirements. Compliance with this external vulnerability scanning requirement only represents compliance with PCI DSS Requirement 11.3.2 and does not represent or indicate compliance with any other PCI DSS requirement.

---

Scan Reporting: What to Expect

A comprehensive scan report is a cornerstone of the ASV Program, providing critical insights into an entity’s vulnerability landscape. The report comprises three main sections:

1. Attestation of Scan Compliance

• This summary indicates whether the scanned infrastructure met the PCI DSS requirements and achieved a passing scan. It includes details about the scan scope, the number of components scanned, and the compliance status.

2. ASV Scan Report Summary

• A high-level summary of vulnerabilities by component, listing compliance-impacting issues and their remediation status. This section also includes “Special Notes to Scan Customer,” highlighting potential risks even if they do not result in automatic failure.

3. ASV Scan Vulnerability Details

• A detailed listing of all vulnerabilities detected during the scan, including severity levels, CVE identifiers, CVSS scores, and compliance status. The report also lists open ports and services detected during the scan.

---

Vulnerability Severity Levels and Compliance

Vulnerabilities identified during ASV scans are categorized by their severity, which determines their impact on compliance:

• High Severity (CVSS Score: 7.0-10.0): Failing vulnerabilities that must be remediated immediately.
• Medium Severity (CVSS Score: 4.0-6.9): Failing vulnerabilities that require remediation before achieving a passing scan.
• Low Severity (CVSS Score: 0.0-3.9): Passing vulnerabilities that do not impact compliance but should still be addressed to improve security.

---

Special Notes to Scan Customers

The scan report may include “Special Notes” for specific configurations or software that pose risks to the CDE. These notes do not result in automatic failure but require the customer to justify the presence of such configurations and confirm their secure implementation.

Examples of “Special Notes” include:

• Embedded scripts on payment pages
• Remote access software
• Insecure services or protocols

The ASV must obtain the customer’s declaration for each special note before issuing a passing scan report.

---

FAQ

Conclusion

The PCI ASV Program is an indispensable component of PCI DSS compliance. It ensures that vulnerabilities in external-facing systems are identified and addressed proactively. By partnering with an Approved Scanning Vendor, businesses can enhance their security posture, mitigate risks, and maintain the trust of their customers and payment partners.

However, achieving compliance is not a one-time effort. It requires ongoing vigilance, regular scans, and a commitment to addressing vulnerabilities promptly. With the right approach and the support of a qualified ASV, businesses can navigate the complexities of PCI DSS and build a secure environment for cardholder data.

By embracing the PCI ASV Program, you’re not just meeting regulatory requirements—you’re investing in your organization’s long-term security and success.

You can find a copy of the ASV Program guide on the PCI Couciles website here. All ASV customers and companies are required to read and understand the guide.