Secusy ASV vs Sectigo HackerGuardian: Pricing & Feature Comparison
Secusy ASV vs Sectigo HackerGuardian: compare per-IP pricing, tiers, rescans, and setup to pick the right PCI ASV scanner for your business.
A PCI ASV report shows up in your inbox once a quarter, and for most people, it’s treated as a pass/fail notification to forward to the acquirer and forget. That approach works right up until a finding gets disputed, an auditor asks a follow-up question, or a report gets rejected and you’re suddenly trying to understand a document you’ve never actually opened.
This guide walks through exactly what a PCI ASV report contains, what each section is for, why reports get rejected, and what to do when yours comes back with a failure, so the next report you receive is something you can read and act on yourself, not just file away.
ASV Report: The complete package of documentation an Approved Scanning Vendor issues after a quarterly external vulnerability scan, used as evidence of compliance with PCI DSS Requirement 11.3.2.
Attestation of Scan Compliance (ASC): The formal document stating whether a scan passed or failed. This is the single document most acquirers ask to see first, but it isn't the whole report.
Scan Report Summary: A breakdown of findings organized by host, IP, or component, showing what was found and its severity, without the full technical detail of each vulnerability.
Vulnerability Details: The full technical write-up of each finding, including the CVE or vulnerability description, severity score, and affected component, used by whoever handles remediation.
CVSS (Common Vulnerability Scoring System): The 0-10 scale used to rate how severe a finding is. A passing scan requires nothing scored 4.0 or above.
A PCI ASV report is a standardized, independently produced document that records the results of an external vulnerability scan against your cardholder data environment. It exists because PCI DSS Requirement 11.3.2 requires organisations to demonstrate, through an independent assessment, that their internet-facing systems are free of known high-risk vulnerabilities; self-assessment alone doesn't satisfy the requirement.
The PCI SSC prescribes the exact format and minimum content every ASV must follow, which is why any report from any approved vendor uses the same structure, terminology, and scoring logic. That consistency is what lets an acquirer or QSA review a report from any vendor without needing a translator, and it’s what lets your own team compare results quarter over quarter.
An absent or perpetually failing report isn’t just a paperwork problem; it’s a documented compliance gap that can affect merchant tier status and increase scrutiny in the event of a breach investigation.
For the full technical specification ASVs must follow when producing a report, see the PCI SSC’s ASV Program Guide and their resource guide on vulnerability scans and ASVs.
Secusy ASV reports are built to be readable by anyone, clear pass/fail status, plain-language findings, and the full attestation your acquirer needs in one place.
A compliant ASV report is three separate documents, not one: an Attestation of Scan Compliance stating 'pass', 'fail', or 'pass with exceptions'; a Scan Report Summary (Executive Summary) showing findings by severity and host; and the full Vulnerability Details behind each finding.
Acquirers and assessors are entitled to review all three, not just the top-line attestation. A vendor-issued badge or one-page “certificate” that sits outside these three PCI SSC–defined documents is marketing material, not a substitute for the actual report. If your vendor only hands you a pass/fail certificate, ask for the full report before you need it for a dispute or an audit.
Keep in mind these are meant to be retained, not just reviewed once; PCI DSS record-keeping expectations mean you’ll want each quarter’s full three-document set archived and easy to pull up, not just the pass/fail email forwarded to your acquirer at the time.
The AOC is the signable certification section of the report; the document acquirers and QSAs request most often as proof that a qualifying scan was completed. It records the ASV's name and PCI SSC listing reference, the scan date range, the in-scope IPs and domains, and the overall result.
Both the ASV and a representative of the scanned organization sign the AOC, creating a dual-party record that the scan happened, the scope was accurate, and any exceptions were acknowledged. This is the document your compliance team files, presents to a QSA, and retains, one per quarterly cycle, kept in line with your PCI DSS record-keeping obligations.
Understanding “pass with exceptions”: This status applies when a finding that would normally cause a failure has been formally disputed and accepted under the ASV programme’s exception rules, commonly because a component can’t be patched immediately or a compensating control addresses the risk another way.
It’s a legitimate outcome, not a euphemism for failure. That said, the same exception showing up scan after scan will reasonably prompt an acquirer to ask whether remediation is actually in progress.
A passing ASV report requires no vulnerabilities scored CVSS 4.0 or higher anywhere in scope. A scan that completed without technical errors but still shows findings at or above that threshold is a fail, regardless of how cleanly the scan itself ran.
This is the distinction that trips people up most: “the scan ran” and “the scan passed” are not the same statement. Acquirers only accept a passing AOC; a completed-but-failed scan doesn’t satisfy Requirement 11.3.2, no matter how thorough it was.
There’s also a category of automatic failures that apply regardless of CVSS score, things like unsupported SSL/TLS versions or certain default credentials are treated as an automatic fail even if no CVE is scored 4.0 or above. A report can look clean on scoring and still fail for this reason, which is why the CVSS threshold alone isn’t the full picture.
The Vulnerability Details section lists every finding discovered during the scan, organized by host and ranked by severity using CVSS scoring; including the CVE identifier where applicable, the affected port and service, and recommended remediation steps.
This is where technical teams spend most of their time, and it’s the actionable part of the report. Findings scored below 4.0 are informational and don’t cause a failure on their own, but they still represent real risk worth tracking through your ongoing vulnerability management process. One detail worth watching for: a host that’s unreachable during the scan doesn’t get a pass by default; it stays unresolved and needs to be addressed before the result can be considered complete.
The most effective teams treat this section as the trigger for an already-established remediation workflow, with ownership and timelines assigned before the first scan is even run, not as a to-do list that starts cold once the report lands.
Secusy ASV reports are built to be readable by anyone, clear pass/fail status, plain-language findings, and the full attestation your acquirer needs in one place.
The most common reason an ASV report gets sent back isn't a failed scan; it's an incomplete scope, or a finding still marked unresolved or disputed at the time the report is submitted.
An acquirer reviews the submission, and either the scope looks incomplete relative to what’s actually internet-facing or a flagged finding hasn’t been resolved or formally disputed yet. The report goes back, and you’re now working against a deadline instead of ahead of one.
This is why scope deserves attention before the scan even starts: you define what’s in scope, not the ASV, and an incomplete scope surfaces as a rejection later rather than a problem caught early. If in-scope systems are later found to have been excluded, the validity of the entire quarterly result can be challenged.
A failed ASV report means either remediating the flagged vulnerability and requesting a rescan or formally disputing it as a false positive, then getting the rescan completed before your compliance deadline.
Patch, reconfigure, or otherwise remediate the vulnerability, then request a rescan. Most vendors include at least one rescan without requiring a full new engagement.
PCI DSS explicitly allows disputing findings that don't actually apply, whether due to a backported patch, a compensating control, or a scan misreading your environment. Document the case and submit it through your ASV's dispute process rather than leaving the finding unresolved.
The speed and competence of that dispute process is where ASV quality shows up most clearly. A vendor that treats disputes as routine turns a non-issue into a quick correction; a slow one turns it into a missed quarter.
A good ASV report separates pass from fail at a glance, explains findings in plain language rather than raw technical output, and includes the attestation your acquirer needs without requiring a security specialist to translate it.
Before committing to a vendor, ask to see a sample report. If you can’t tell within the first page whether a sample scan passed or failed, that’s a preview of what every quarter will feel like working with that vendor.
Beyond readability, check three things: how fast the vendor turns around a rescan after remediation, whether the dispute process is documented or something you have to chase over email, and whether the report exports cleanly to PDF for your acquirer rather than living only in a portal you’ll need to grant auditor access to later.
An ASV scan report doesn't exist in isolation; it's a quarterly evidence output that needs to align with your internal vulnerability scanning, penetration testing, and change management processes.
Requirement 11.3.2 (external ASV scanning) complements Requirement 11.3.1 (internal scanning). Internal scans look inward, assessing what would be exploitable by an insider or an attacker who’s already inside the perimeter; external ASV scans simulate an outside attacker targeting internet-facing systems.
Together, they give a more complete picture than either could alone. It’s also worth noting that significant changes – new IP addresses, new internet-facing services, and major infrastructure changes – can trigger the need for an out-of-cycle scan. Discussing these scenarios with your ASV in advance avoids compliance gaps created by undocumented scope changes.
If you run a SaaS platform, your ASV report is just one piece of a larger PCI compliance picture; see our full breakdown of PCI compliance for SaaS platforms.
A PCI ASV report is a three-part package; the Attestation of Scan Compliance, the Scan Report Summary, and the full Vulnerability Details, produced quarterly under PCI DSS Requirement 11.3.2. A completed scan isn't automatically a passing one; only a result free of CVSS 4.0+ findings clears the bar, and "pass with exceptions" is a legitimate middle outcome when disputes are properly documented. Most rejections trace back to scope, not the scan itself, which makes accurate, revisited scope the highest-leverage thing you can get right. A report you can read and act on without outside help is a sign of a good ASV partner; one you can't is worth reconsidering before your next quarter.
Secusy ASV reports are built to be readable by anyone, clear pass/fail status, plain-language findings, and the full attestation your acquirer needs in one place.
It's the documentation your acquirer or QSA requires as evidence you've met PCI DSS Requirement 11.3.2's quarterly external scanning requirement. Without it, or with a failing one, your compliance status is incomplete.
Yes. PCI DSS recognizes that scans can flag false positives, findings that don't actually apply due to a compensating control or an already-applied patch. Your ASV is required to support a documented dispute and rescanning process.
A structured external vulnerability scan conducted by a PCI SSC-approved vendor against internet-facing systems in your cardholder data environment. It produces the formal ASV scan report, including the AOC, and is required quarterly under Requirement 11.3.2.
Approved Scanning Vendor; a company certified by the Payment Card Industry Security Standards Council to conduct external network vulnerability scans and issue reports that satisfy the quarterly scanning requirement.
A straight pass has no failure-level findings at all. "Pass with exceptions" means a finding that would normally fail the scan has been formally disputed and accepted under the ASV programme's rules, a legitimate outcome, provided the same exception isn't recurring quarter after quarter without progress.
Binoy Koonammavu is the Founder and CEO of Secusy ASV, a PCI SSC–listed Approved Scanning Vendor. He works directly with SMBs and fintech companies on PCI DSS Requirement 11.3.2 scanning and reporting, and writes to make ASV compliance understandable without enterprise-security jargon.