You just received your PCI ASV scan report. It’s 47 pages long, filled with CVE numbers, CVSS scores, and error codes that read like a foreign language. Your deadline is in two weeks, and your QSA is waiting. Sound familiar?
You’re not alone. For many security teams and compliance managers, the ASV scan report is one of the most confusing artifacts in the entire PCI DSS journey. The data is all there — but making sense of it, knowing what to fix first, and understanding what will actually block your attestation is a different challenge entirely.
This guide cuts through the noise. We’ll walk you through exactly how to read your PCI ASV scan report, decode the most common error codes and fail reasons, and give you a practical remediation roadmap — so you can spend less time deciphering the report and more time actually fixing things.
What Is a PCI ASV Scan — and Why Does It Matter?
PCI DSS Requirement 11.3.2 mandates that any organization that stores, processes, or transmits cardholder data must conduct quarterly external vulnerability scans using an Approved Scanning Vendor (ASV). The ASV is a company certified by the PCI Security Standards Council (PCI SSC) to perform these scans.
The purpose of an ASV scan is to identify vulnerabilities on your internet-facing systems — IP addresses, domains, and services that are in scope for cardholder data. Think of it as a methodical, standardized probe of your external attack surface, run by a neutral third party.
Failing to pass your ASV scan on time doesn’t just create a compliance gap — it can affect your ability to process card payments, your relationships with acquiring banks, and your standing with card brands like Visa and Mastercard.
| WHY IT MATTERS: The ASV doesn’t just find vulnerabilities. It issues a formal verdict: Pass or Fail. That verdict becomes part of your compliance record. Understanding why a scan fails — and how to resolve each finding — is critical to maintaining continuous compliance. |
Anatomy of a PCI ASV Scan Report
Before diving into error codes, it helps to understand how an ASV report is structured. While each ASV vendor has its own reporting interface, all PCI-compliant reports must follow the ASV Program Guide published by the PCI SSC. Here’s what you’ll typically find:
Executive Summary
This is the top-level verdict. It shows overall scan status (Pass or Fail), total number of components scanned, number of findings by severity, and the date of the scan. If you have a Fail, this section tells you how many failing components contributed to it.
Component Scan Details
Each IP address or hostname in scope gets its own section. Here you’ll find the open ports discovered, services identified, and each vulnerability detected on that component. This is where you’ll spend most of your time when remediating.
Vulnerability Findings Table
The core of the report. Each finding includes a CVE identifier (if applicable), a CVSS score, a severity level, a description of the vulnerability, and remediation guidance. This table drives the Pass/Fail decision.
Attestation of Scan Compliance (AOC)
The formal document that gets submitted to your acquirer or payment brand. It certifies the scan result and is signed by the ASV. You can only submit this if your scan has achieved a passing status.
| Report Section | What to Look For |
|---|---|
| Executive Summary | Overall Pass/Fail status, number of failing components |
| Component Details | Per-IP breakdown of open ports, services, and vulnerabilities |
| Vulnerability Findings | CVE IDs, CVSS scores, severity, and remediation steps |
| Special Notes / Exceptions | Any findings marked as exceptions or disputed by the ASV |
| Attestation of Scan Compliance (AOC) | The formal compliance certificate — only present on a passing scan |
How the Pass/Fail Decision Is Made
This is where many organizations get confused. Not every vulnerability causes a scan to fail. The PCI ASV Program Guide uses a specific set of rules to determine whether a finding is a mandatory failure.
A finding will cause an automatic failure if it meets any of the following criteria:
- CVSS base score of 4.0 or higher
- The vulnerability falls within a defined set of “automatic failure” conditions regardless of CVSS score
- A backdoor, malware, or suspicious file is detected
- The component is directly accessible from the internet and the vulnerability exposes cardholder data
The Automatic Failure Conditions
PCI ASV requirements define specific vulnerability types that automatically fail a scan, even when the CVSS score might be below 4.0. These include:
- Web application firewall (WAF) bypass vulnerabilities
- Cross-site scripting (XSS) that allows session hijacking
- SQL injection vulnerabilities
- Remote code execution (RCE) flaws
- Authentication bypass vulnerabilities
- Outdated SSL/TLS versions (SSLv2, SSLv3, TLS 1.0 in most cases)
- Expired or self-signed SSL certificates on in-scope components
- Vulnerabilities with active, publicly available exploits
| IMPORTANT: A CVSS score of 3.9 with an active public exploit is more dangerous than a CVSS 8.0 theoretical flaw. The ASV evaluates exploitability, not just severity numbers. Always read the finding description alongside the score. |
Decoding Common PCI ASV Error Codes and Fail Reasons
Here’s the part most guides skip: what these codes and findings actually mean in plain English, and what you should do about each one.
SSL/TLS-Related Failures
SSL and TLS findings are among the most common causes of ASV scan failures, and they tend to cluster together. If you have one TLS issue, you likely have several.
| Finding / Code | What It Means | Remediation |
|---|---|---|
| SSLv2 / SSLv3 Enabled | Outdated protocols with known cryptographic weaknesses (POODLE, DROWN attacks). Automatic scan failure. | Disable SSLv2 and SSLv3 at the web server or load balancer level. Enforce TLS 1.2 minimum, TLS 1.3 preferred. |
| TLS 1.0 Enabled | TLS 1.0 is deprecated and vulnerable to BEAST and POODLE attacks. As of PCI DSS v4.0, TLS 1.0 is not permitted for protecting cardholder data. | Disable TLS 1.0. Enable TLS 1.2 and TLS 1.3. Update cipher suites. |
| Weak Cipher Suites | Ciphers like RC4, DES, 3DES, EXPORT-grade, or NULL ciphers are cryptographically broken or inadequate. | Configure your server to use only strong ciphers. Follow Mozilla’s SSL Configuration Generator for your server type. |
| Expired SSL Certificate | The certificate on a scanned component is past its expiration date. | Renew the certificate immediately. Implement automated certificate renewal (e.g., Let’s Encrypt with auto-renewal). |
| Self-Signed Certificate | Certificate is not issued by a trusted Certificate Authority (CA). | Replace with a certificate from a trusted public CA. Self-signed certs are acceptable only in non-public environments. |
| Certificate Hostname Mismatch | The Common Name (CN) or Subject Alternative Name (SAN) in the certificate does not match the scanned hostname. | Reissue the certificate with the correct hostname. Check for wildcard coverage if multiple subdomains are involved. |
Network and Port-Related Failures
These findings relate to open ports, services, and network-level exposures that increase your attack surface.
| Finding / Code | What It Means | Remediation |
|---|---|---|
| Unnecessary Open Ports | Services running on ports that should not be publicly accessible (e.g., databases on port 3306, 5432, or 1433; admin interfaces on 8080). | Close or firewall any port not required for cardholder data functionality. Apply the principle of least access. |
| Unencrypted Service Detected (HTTP, FTP, Telnet) | Cleartext protocols transmitting data without encryption, making it vulnerable to interception. | Replace HTTP with HTTPS, FTP with SFTP or FTPS, and Telnet with SSH. Redirect all plaintext traffic. |
| Default Service Banner Exposed | The server is disclosing software name, version, and OS details in service banners. | Suppress or modify banners for Apache, Nginx, IIS, OpenSSH, etc. This reduces information available to attackers. |
| ICMP Timestamp Response | The server responds to ICMP timestamp requests, revealing system time information. | Block ICMP timestamp requests at the firewall level. |
| DNS Zone Transfer Allowed | The DNS server accepts AXFR requests, potentially revealing your full DNS record set. | Restrict zone transfers to authorized secondary DNS servers only. Deny AXFR from all other sources. |
Application-Layer Failures
These are vulnerabilities discovered in web applications or application services exposed on in-scope systems.
| Finding / Code | What It Means | Remediation |
|---|---|---|
| SQL Injection (SQLi) | User-supplied input is passed directly to database queries without sanitization. One of the highest-risk findings. | Use parameterized queries or prepared statements. Implement input validation and a WAF. Conduct a code review. |
| Cross-Site Scripting (XSS) | Malicious scripts can be injected into web pages viewed by other users. | Implement output encoding, Content Security Policy (CSP) headers, and input validation. Use a WAF. |
| Cross-Site Request Forgery (CSRF) | Attackers can trick authenticated users into performing unintended actions. | Implement anti-CSRF tokens. Validate the Origin and Referer headers. Use SameSite cookie attributes. |
| Directory Traversal | An attacker can access files outside the web root by manipulating file path parameters. | Validate and sanitize file path inputs. Use chroot jails and proper server configuration to restrict file access. |
| HTTP Security Headers Missing | Headers like X-Frame-Options, X-Content-Type-Options, Content-Security-Policy, and Strict-Transport-Security (HSTS) are absent. | Add the appropriate security headers in your web server or application configuration. HSTS is particularly critical for in-scope systems. |
| Insecure Direct Object Reference (IDOR) | Application exposes internal object identifiers (e.g., user IDs, order numbers) without access control. | Implement access control checks on every request. Use indirect references or GUIDs instead of sequential integers. |
Software and Patch-Related Failures
Unpatched software is one of the most common and most avoidable causes of ASV scan failures. These findings reference specific CVEs tied to known vulnerabilities in software versions.
| Finding / Code | What It Means | Remediation |
|---|---|---|
| Outdated Web Server Version | Apache, Nginx, IIS, or another web server is running a version with known CVEs. | Update to the latest stable version. Subscribe to the vendor’s security advisory feed. |
| Outdated CMS / Application Framework | WordPress, Drupal, Joomla, or a custom framework is out of date with known vulnerabilities. | Update core, themes, and plugins. Remove unused plugins and themes. Enable automatic security updates where possible. |
| End-of-Life (EOL) Operating System | The operating system is no longer receiving security patches from the vendor. | Upgrade to a supported OS version. Document a migration plan if immediate upgrade is not feasible — your QSA will need to review. |
| OpenSSL Vulnerability (e.g., CVE-2014-0160 – Heartbleed) | A specific CVE in a cryptography library, often with a CVSS score high enough to trigger automatic failure. | Update OpenSSL or the affected library to the patched version. Regenerate keys and certificates if Heartbleed-era versions are involved. |
| PHP / Python / Java Runtime Outdated | Scripting language runtime has known vulnerabilities. | Update to the latest supported minor version within your major version branch. Test in staging before production. |
The Dispute and Exception Process
Not every finding on your ASV report is a genuine vulnerability in your environment. Sometimes the scanner generates false positives — findings that look like vulnerabilities but aren’t exploitable in your specific configuration. The PCI ASV Program allows you to dispute these findings, but the bar is high.
Types of Acceptable Disputes
The ASV will consider disputes in the following categories:
- False Positive — The vulnerability does not actually exist in your environment (e.g., the software version appears vulnerable but has been back-patched by your OS vendor).
- Compensating Control — You cannot fix the vulnerability directly, but you have controls in place that mitigate the risk to an acceptable level (must be approved by your QSA).
- Business Justification (Limited Scope) — You can demonstrate the finding is outside the cardholder data environment (CDE) scope.
How to File a Dispute
Each ASV has its own dispute workflow, but in general you’ll need to provide:
- The specific finding reference number from the report
- A clear, technical explanation of why the finding is a false positive
- Supporting evidence (configuration exports, vendor documentation, patch notes, OS back-porting documentation)
- A signed statement from your organization confirming the dispute is accurate
| NOTE: Disputes are evaluated by the ASV, not by you. A dispute is not a guaranteed fix — if the ASV disagrees, the finding stands. Budget extra time for disputes when planning your compliance timeline: the back-and-forth can take one to three weeks. |
If a finding is confirmed as a false positive and the dispute is accepted, the ASV will issue an updated report reflecting the disputed status, and the finding will no longer block your pass status.
What Cannot Be Disputed
Certain findings cannot be disputed away, regardless of your argument. These include:
- Any finding where the vulnerability genuinely exists and is exploitable
- Protocol-level failures (SSLv3, TLS 1.0) — the protocol is either enabled or it isn’t
- Expired certificates — the certificate is objectively expired
- Known malware or backdoor detections
- Active exploit code associated with a finding
A Practical Remediation Roadmap
Once you understand your findings, you need a plan. Here’s how to structure your remediation effort to maximize efficiency and minimize the risk of missing your compliance deadline.
Step 1: Triage by Impact
Not all findings are equal. Start by sorting your findings into three groups:
| Priority | Criteria | Examples |
|---|---|---|
| Critical (Fix First) | CVSS 7.0+, automatic failure conditions, active exploits available | SQLi, RCE, SSLv3, expired certificates, EOL OS |
| High (Fix Second) | CVSS 4.0–6.9, may cause scan failure, exploitable under common conditions | Weak cipher suites, missing HSTS, outdated web server versions |
| Medium/Low (Fix or Document) | CVSS below 4.0, informational, may be disputed as false positive | Service banners, ICMP timestamp, informational disclosures |
Step 2: Assign Ownership
Every finding needs a named owner — not a team, but a person. TLS configuration issues typically fall to your infrastructure or DevOps team. Application vulnerabilities (XSS, SQLi) belong to your development team. Certificate renewals may sit with your platform or DevOps team. Patch management may involve your system administrators.
Use a tracking spreadsheet or your existing ticketing system (Jira, ServiceNow, etc.) to assign each finding, set a due date, and track status. Treat these as you would production incidents.
Step 3: Implement Fixes in a Test Environment
Whenever possible, test your fixes before pushing them to production — especially for TLS configuration changes, software upgrades, and firewall rule changes. A misconfigured TLS change can take down your site. An overly aggressive firewall rule can break legitimate services.
| CAUTION: Changes that seem small (disabling a cipher suite, upgrading OpenSSL) can have downstream effects on older clients, mobile apps, and third-party integrations. Test first. Deploy with a rollback plan. |
Step 4: Rescan Early
Don’t wait until all fixes are in place to request a rescan. Most ASV vendors allow multiple rescans within a billing period or charge a nominal fee per rescan. Consider a partial rescan approach:
- Fix and rescan your highest-risk findings first.
- Use the rescan results to verify fixes were effective.
- Continue remediating remaining findings while the rescan is in progress.
- Request a final rescan once all findings are addressed.
This approach reduces the risk of discovering at the last minute that a fix didn’t actually resolve the finding — which happens more often than most teams expect.
Step 5: Document Everything
Your QSA and acquirer may ask for evidence of remediation. Document:
- What the finding was
- What action was taken and when
- Who performed the remediation
- Test results confirming the fix was effective
- Any exceptions granted, with the supporting business justification
Good documentation also protects you if the same finding resurfaces in a future scan. You’ll be able to demonstrate that it was addressed and investigate why it reappeared.
Common Mistakes That Cause Repeat Failures
After remediation, many organizations rescan only to find the same findings again — or new ones they didn’t expect. Here are the most common reasons scans continue to fail:
Fixing the Finding in One Place but Not All
You disabled TLS 1.0 on your primary web server — but forgot the staging server that’s also in scope, or the load balancer that terminates SSL upstream. The scan checks all in-scope IPs, not just the ones you focused on. Maintain a complete, accurate IP inventory and apply fixes consistently.
Overlooking CDN and Third-Party Configurations
If you use a CDN like Cloudflare, Fastly, or AWS CloudFront, TLS settings are often managed at the CDN layer, not at the origin server. Make sure your CDN’s TLS configuration meets PCI requirements. Your origin server may be fine while your CDN-facing endpoints are not.
Updating Software but Not Restarting Services
This is a classic. You patched OpenSSL at the OS level, but the web server process loaded the old library into memory at startup. The scanner still detects the old version because the service hasn’t been restarted. Always restart services after patching libraries.
Treating Informational Findings as Unimportant
Some findings are labeled “informational” or carry a CVSS score below 4.0 — but don’t ignore them entirely. Certain informational findings (like exposed version banners or default error pages) can contribute to disputes being harder to win if you dispute a related higher-severity finding. Address them when time allows.
Letting Your ASV Scope Get Stale
If your organization adds new external IP addresses, spins up new cloud infrastructure, or acquires a new domain, those new components need to be added to your ASV scan scope. A passing scan on your old scope means nothing if there are in-scope systems that were never scanned.
PCI DSS v4.0: What Changed for ASV Scans
PCI DSS v4.0 became the only active standard as of March 31, 2024. Several changes affect how ASV scans are conducted and evaluated:
- TLS 1.0 is now explicitly prohibited for protecting cardholder data under Requirement 4.2.1. Previously deprecated, it’s now a hard requirement. Any in-scope system still accepting TLS 1.0 connections will fail.
- Requirement 11.3.2 now requires organizations to have a documented process for addressing scan failures, including timelines for remediation and rescan.
- Multi-tenant environments have more specific guidance. If you share infrastructure with other tenants, your ASV scan scope documentation must clearly delineate your responsibility from your provider’s.
- Customized Approach: PCI DSS v4.0 introduces the option to implement compensating controls or alternative implementations — but these must be formally documented and approved by your QSA. The ASV still scans; the QSA assesses whether your customized approach is valid.
| PCI DSS v4.0 ALERT: If your organization is still running TLS 1.0 on any in-scope system — for any reason, including legacy client support — you are now out of compliance with PCI DSS v4.0. Plan your migration immediately. |
Frequently Asked Questions
Can I pass my ASV scan with open informational findings?
Yes. Informational findings with a CVSS score below 4.0 that don’t meet any automatic failure conditions will not prevent a pass. However, review them carefully — some ASVs classify findings slightly differently, and your QSA may have opinions on specific informational findings in your environment.
How long does remediation typically take?
It depends heavily on the nature and volume of findings. Simple TLS configuration fixes can be implemented in hours. Application-layer vulnerabilities like SQL injection may require code changes, testing, and deployment cycles that take weeks. Plan for at least two to four weeks of remediation time before your compliance deadline, plus a buffer for rescans.
Do I need a passing scan every quarter, or just once a year?
PCI DSS requires a passing scan every quarter — that’s four passing scans per year. If you fail a quarterly scan and remediate it, the remediated rescan counts as your quarterly result, provided it falls within a reasonable timeframe. Your QSA and acquirer will have specific guidance on timing.
Can my internal security team perform the ASV scan?
No. PCI DSS explicitly requires the use of an Approved Scanning Vendor — a third-party company certified by the PCI SSC. Your internal team can perform additional internal scans as part of a layered security program, but those do not satisfy the PCI ASV requirement.
What if a finding is in a system I don’t manage?
This is a shared responsibility question. If the system is within your CDE scope but managed by a third-party provider (cloud host, managed service provider, etc.), you need to engage that provider to remediate the finding. Make sure your contracts with service providers include obligations around PCI compliance and timely patching.
My ASV report shows a finding as ‘Special Note’ — what does that mean?
A Special Note in an ASV report is used when the ASV has a specific concern about a finding that falls outside the standard vulnerability classification. Examples include detections of potential backdoors, suspicious software, or behaviors that the ASV wants to flag for manual review. Treat Special Notes as high priority and address them proactively.
Final Thoughts: Turn the Report into a Roadmap
A PCI ASV scan report is intimidating the first time you see it. But once you understand how it’s structured, how the Pass/Fail decision is made, and what each category of finding actually means, it becomes something else entirely: a concrete, actionable list of exactly what needs to change in your environment.
The organizations that handle ASV scans smoothly are the ones that treat them as an ongoing process, not a once-a-quarter fire drill. They maintain an accurate scope inventory, keep their systems patched between scans, address TLS and certificate hygiene as part of normal operations, and build remediation workflows that engage the right teams quickly.
Your ASV scan isn’t just a compliance checkbox. It’s a window into your external attack surface — the same surface that attackers are probing every day. The vulnerabilities on that report are real risks, and addressing them systematically protects your customers’ cardholder data as much as it satisfies your auditors.
Use this guide as your reference, work closely with your QSA, and don’t wait until the last minute. The path to a passing scan — and to stronger security overall — is clearer than it looks.
| Quick Reference: ASV Scan Remediation Checklist Confirm all in-scope IPs and domains are included in the scan. Identify all findings that caused a Fail status (CVSS 4.0+ or automatic failure conditions). Assign ownership to each finding with a named individual and a remediation deadline. Disable SSLv2, SSLv3, and TLS 1.0 on all in-scope systems. Renew or replace any expired or self-signed certificates. Apply all available security patches to in-scope systems. Close or firewall any unnecessary open ports and services. Implement missing HTTP security headers (HSTS, CSP, X-Frame-Options). Prepare dispute documentation for any verified false positives. Request a rescan and verify all remediated findings are cleared. Obtain the signed Attestation of Scan Compliance (AOC) from your ASV. Submit the AOC to your acquirer or payment brand as required. |
Disclaimer
This article is intended for informational purposes only and does not constitute legal, financial, or compliance advice. PCI DSS requirements and ASV program rules are subject to change. Always consult with a qualified QSA (Qualified Security Assessor) and your acquiring bank or payment brand for compliance decisions specific to your organization.
