PCI ASV Certification: How It Differs From PCI Certified and PCI Compliant
PCI ASV certification explained: how it differs from PCI certified and PCI compliant, who validates each, and how to verify a PCI approved scanning vendor.
• The sample PDF holds all three ASV report documents: a 1-page Attestation, a 14-page Executive Summary and an 8-page excerpt of the 200-page Vulnerability Details report.
• The Attestation (Section A.3) and the Executive Summary (Part 2) state the verdict. The Vulnerability Details show the evidence.
• A scan fails if any finding scores CVSS 4.0 or higher, or is flagged as an automatic failure.
• The sample has 28 failing rows, but only 14 distinct findings. The same flaw is reported once per port.
• Most failures trace back to four root causes: transport security, input handling, page hardening and exposed files.
• Every report carries a scan date and a 90-day expiry. Check the date format before you trust it.
• Send your acquirer the Attestation (after checking their rules). Keep the detail report for fixing and rescanning.
This ASV scan report sample walks you through a full-length PCI external scan report, section by section. It covers all three report documents for a fictitious customer, generated against a demo environment, so every finding is deliberate. Customer and vendor details are removed, and no real data appears.
Download the sample ASV scan report (PDF, 23 pages) and follow along.
Reports like this are long, repetitive and full of scanner jargon. First-time readers either jump straight to pass or fail or get lost in the detail. We parsed all 200 pages and grouped the 111 line items, so you can see what actually matters.
If you want the basic definition first, read what an ASV report is. If your question is whether your bank will accept the report, see ASV report acquirer acceptance.
ASV (Approved Scanning Vendor): a company approved by the PCI Security Standards Council to run external vulnerability scans.
Component: any host, IP address, domain or other entry point into a system or cardholder data environment that is included in the scan.
CVSS base score: a 0.0 to 10.0 severity rating. PCI uses it to decide pass or fail.
Automatic failure: a finding that fails the scan, whatever its score.
Attestation of Scan Compliance: the one-page document that states the overall result and carries the customer’s and the ASV’s attestations.
Cardholder Data Environment (CDE): the systems that store, process or transmit cardholder data. Internet-facing parts of it are the main scan targets.
The sample PDF has three parts: a 1-page Attestation of Scan Compliance, a 14-page Executive Summary and an 8-page excerpt of the 200-page Vulnerability Details report
• Attestation of Scan Compliance (1 page): customer and vendor details, scan status, and both attestations.
• Executive Summary (14 pages): Parts 1 to 4: scan information, component summary, vulnerabilities per component, special notes and scope.
• Vulnerability Details (8 of 200 pages): the evidence: scan information, findings with full detail, and port scan results.
Across the full report there are 111 line items: 28 fail and 83 pass. The full Vulnerability Details report runs to 200 pages because its detail block repeats for every finding on every port. The PDF keeps eight of those pages. The Vulnerability Details report has no overall pass or fail banner. The verdict sits in the Attestation (Section A.3) and in the Executive Summary (Part 2).
Run a PCI ASV scan and receive the full three-part report.
A complete ASV report set has three documents: the Attestation (the verdict), the Executive Summary (status per component) and the Vulnerability Details (the evidence).
Only scans by a PCI SSC-approved vendor count. Under PCI DSS Requirement 11.3.2, external scans must run at least once every three months and after significant changes. Our guide to PCI DSS 11.3.2 covers the rule itself. The ASV Program Guide defines what each document must contain, which is why reports from different vendors look alike. The attestation wording also makes clear that a scan result alone is not proof of overall PCI DSS compliance.
The one-page Attestation states the result. Section A.3 shows the compliance status, dates and failing count. Sections A.4 and A.5 are the customer’s and the ASV’s attestation statements.
Section | What it shows | What to check | |
|---|---|---|---|
SA.1 Scan Customer Information | Company, contact, address, website | The details match the entity you scanned | |
A.2 Approved Scanning Vendor Information | The ASV company and its contact | The vendor is a PCI SSC-approved ASV | |
A.3 Scan Status | Scan date, expiry, compliance status, report type, components scanned, failing vulnerabilities | Yes, quarterlyStatus, dates and counts | |
A.4 Scan Customer Attestation | Customer confirms scope is complete, out-of-scope parts are segmented and evidence is accurate | Scoping is your responsibility | |
A.5 ASV Attestation | ASV confirms the scan followed PCI DSS 11.3.2 and the ASV Program Guide, with a quality assurance process | The ASV certificate number is stated |
In this sample, A.3 reads Fail, with 28 identified failing vulnerabilities, one in-scope component scanned and none found but left unscanned. The report type is Full scan. Customer and vendor names and contact details are removed from the PDF.
The 90-day clock: A.3 shows the scan completed on 09-12-2025 and expiring on 09-03-2026. The dates are day-month-year. The expiry is 90 days after completion, which only works as 9 December 2025 to 9 March 2026. A US reader could easily misread the first date as September 12.
What to do: confirm your report’s date format, then plan the next scan well before day 90. Our guide to how often you need an ASV scan explains the cadence.
What A.4 means for you: the customer attests that scoping is their responsibility and that the result covers only the external scan requirement, not overall PCI DSS compliance.
The 14-page Executive Summary is the condensed view. It repeats the Fail status per component, lists every finding with its score, and ends with one consolidated fix list and the scan scope.
Part | What it shows | In this sample | |
|---|---|---|---|
Part 1. Scan Information | Customer, ASV, scan date, expiry | Same dates as the Attestation | |
Part 2. Component Compliance Summary | Pass or fail for each component | One component: Fail | |
Part 3a. Vulnerabilities Noted for each Component | Every finding with port, severity, CVSS score and status | 111 rows, 28 of them Fail | |
Consolidated Solution/Correction Plan | One fix list covering all findings for the component | Starts with escaping CGI script arguments and ends with filtering ICMP timestamps | |
Part 3b. Special Notes to Scan Customer | Notes where the customer declares software is needed and secure, or removed (ASV Program Guide, section 7.2) | Empty | |
Part 3c. Special Notes – Full Text | Full text of any special notes | Empty | |
Part 4a to 4c. Scan scope | Scope submitted, in-scope components scanned, out-of-scope components | One host submitted, one component scanned, no out-of-scope components found |
Part 3a adds one column the Vulnerability Details table lacks: Exceptions, False Positives, or Compensating Controls, noted by the ASV. It is blank here, so nothing was disputed or excepted.
Read each row left to right: where, what, how severe, score, verdict. Any Medium or High row means Fail.
What it tells you | Sample example | ||
|---|---|---|---|
Component | The IP or host scanned | [redacted IP / host] | |
Detected Open Ports/Protocol/Services | Where the finding lives | 443/tcp/www | |
Vulnerability | Name of the finding | CGI Generic SQL Injection (blind) | |
Severity Level | High, Medium or Low | High | |
CVE Number | Public identifier, if one exists | Mostly blank; CVE-2015-4000 on one Low row | |
CVSS Score | Base score used for the verdict | 8.3 | |
Compliance Status | Pass or Fail | Fail |
Reading order that saves time: score first, then component, then CVE, then the solution text. A score under 4.0 does not affect the verdict. The component column tells you which team owns the fix.
Pattern in this sample: every Low row passes, and every Medium and High row fails. See how the ASV passing score works for the 4.0 rule.
Each finding then expands into a detail block:
• Automatic Failure / Special Note: both read “-” on every row, so no finding here was flagged as an automatic failure.
• Description, Synopsis, Solution: the problem and the fix, in the scanner’s words.
• Output: the evidence, such as the request and response that triggered the finding.
• CVSS v3 and v2 scores and vectors: the table shows the v3 score (8.3 for the SQL injection, against 7.5 on v2).
The PDF excerpt shows this detail block for five findings: the SQL injection, TLS 1.0, script integrity and sensitive file disclosure failures, plus the weak Diffie-Hellman row, which passes at 3.7.
Work through your failing findings and fix them in order.
The 28 failing rows collapse into 14 distinct findings, and those into four root causes plus one roll-up entry.
Root cause | Findings (score) | Fix in one line | |
|---|---|---|---|
Transport security | TLS 1.0, two entries (8.2, 6.5); TLS 1.1, two entries (8.2, 6.5); discouraged cipher suites (4.8); insecure communication on ports 80 and 8080 (5.3); HSTS missing (6.5) | Disable TLS 1.0/1.1, allow only recommended ciphers, encrypt authenticated traffic, enable HSTS | |
Application input handling | Blind SQL injection (8.3); cross-site request forgery, potential (6.5); cross-site scripting (4.3) | Fix the code: escape and validate parameters, add anti-CSRF controls | |
Page and response hardening | Script source integrity (7.1); clickjacking (4.3) | Add integrity attributes or remove the script; send X-Frame-Options or CSP frame-ancestors | |
Exposed content | Sensitive file disclosure (5.3) | Remove unneeded files from the web root, or require authentication | |
Roll-up entry | “PCI DSS compliance” (High, 0.0) | Not a separate flaw: the scanner’s overall non-compliance statement |
Why the count drops: the SQL injection, CSRF, clickjacking, script integrity and file disclosure findings each appear on ports 80, 443 and 8080. Fix each once per application, then confirm on every port.
For the transport rows, our TLS and cypher fix guide has configuration steps. The script integrity flag is worth reading alongside PCI 6.4.3 and 11.6.1, because a scan flag is not the same as meeting those requirements.
Rows below CVSS 4.0 pass but still map your exposure. Part 3 lists every open port, so check it against what you expect to be reachable.
• Weak Diffie-Hellman (CVE-2015-4000, 3.7): passes on score, but is worth cleaning up while you are in the TLS config.
• ICMP timestamp request (CVE-1999-0524, 2.1): low and passing.
• Web server transmits cleartext (2.6): passes, yet sits beside the failing insecure communication finding.
• Informational rows (0.0): firewall, SNMP and OS detection. They describe what an outsider can see.
Part 3 lists ICMP, TCP and UDP checks (port 0), plus 80/tcp, 443/tcp, 8080/tcp (all www) and 161/udp (SNMP). SNMP was detected and passed here, but you would still ask why it is reachable from outside. An unexpected entry means scope or firewall rules need review. Our guide to open ports and scan failures shows how to handle them.
A passing report has no unresolved finding at CVSS 4.0 or higher and no automatic failure. A failing report has one or more, and stays failed until a rescan clears them.
A passing report can still list many Low rows. Having findings is not the same as failing. The Attestation states the result in Section A.3, and the Executive Summary repeats it per component in Part 2. For a pass, the findings table shows nothing at or above the threshold.
Our sample is a failing PCI ASV scan report example: the Attestation shows Fail with 28 identified failing vulnerabilities. Its blind SQL injection (8.3), TLS 1.0 and 1.1 support (8.2) and script integrity flag (7.1) are each enough to fail it alone.
The report does not set a remediation deadline. That is up to you. Extract every failing finding, assign an owner, fix and rescan. Our guides on what to do after a failed ASV scan and passing the first time cover the next steps
Fix real findings and rescan, dispute false positives through your ASV with evidence, and send your acquirer the Attestation after checking what they accept.
• Disputes: automated scanners sometimes flag things wrongly. Raise it with your ASV and supply proof. The outcome is noted in the Executive Summary’s exceptions column. See disputing a false positive.
• Acquirers: most ask for the Attestation, but rules differ. Check before you send anything.
• Evidence: keep every report, dated and filed. Our audit trail guide shows what auditors expect.
• Limits: a pass is one control, not proof of security. See what a passing scan misses.
Where to find a sample ASV report: the ASV Program Guide defines the required content, but a real example is easier to learn from. Download the sample PDF and read it alongside this page. You can also ask your ASV for a sample before your first scan.
An ASV report looks daunting, but this ASV scan report sample shows how little of it drives the result. Check the dates, find the failing rows, group them by root cause and fix each cause once. Then rescan and keep the Attestation for your acquirer. Treat the report as a working document rather than a file to park. The same findings that fail a scan also show where your external exposure is weakest.
See what an ASV scan costs for your IPs before you commit.
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.