How to Choose a PCI ASV: 7 Questions to Ask Before You Sign

If you need to meet PCI DSS Requirement 11.3.2, you already know you need an Approved Scanning Vendor. What's less obvious is that the vendor you choose matters quite a bit. The PCI Security Standards Council maintains a list of approved scanning vendors — every company on it has passed the same baseline certification. But certification is a floor, not a ceiling. The quality of support, reporting, remediation guidance, and integration with your broader security program varies considerably across the field.

These seven questions will help you tell the difference before you sign anything.

What Is a PCI Approved Scanning Vendor?

A PCI Approved Scanning Vendor (ASV) is a company whose scanning tools and processes have been tested and approved by the PCI Security Standards Council (PCI SSC). ASVs are authorized to conduct external vulnerability scans and issue the official attestations your acquirer or QSA needs to confirm compliance with PCI DSS Requirement 11.3.2 (previously 11.2.2 in v3.2.1).

To earn that status, a vendor must pass a rigorous remote test against the PCI SSC's own test infrastructure — a simulated network environment that deliberately includes vulnerabilities and misconfigurations. Certification is renewed annually. Only vendors that clear that process appear on the official ASV list.

No other scanner — regardless of how capable it is — can satisfy this specific PCI DSS requirement. Tools like Nessus or OpenVAS are legitimate vulnerability scanners, but they can't issue PCI-compliant attestations. You need an ASV.

One thing worth knowing: with PCI DSS v4.x, the ASV scan requirement now extends to SAQ A merchants whose websites redirect to or embed third-party payment forms. If that describes your environment and you weren't previously required to run quarterly scans, that changed as of April 1, 2025.

Why the Vendor You Choose Actually Matters

Every ASV on the PCI SSC list can run a scan and generate a passing report. That's where the guaranteed similarities end.

What differs: how they handle scope questions, whether their remediation guidance tells you anything actionable, how responsive they are when you have a disputed finding, and whether their platform fits into how your security team actually works. A bad ASV relationship means quarterly scrambles, unexplained failures, and reports that leave your team no better informed than before the scan ran.

Choosing well means treating this like a security partnership, not a commodity purchase.

7 Questions to Ask Before You Sign

1. Are you currently listed on the PCI SSC's ASV list?

This sounds obvious, but it's the first thing to verify. Some vendors use language like "PCI-certified" or "PCI-compliant scanner" in their marketing without holding active ASV status. Those are not the same thing.

Pull up the PCI SSC's official ASV list and search for the vendor by name before any other conversation. The list shows their certificate number, approved tools, and current status. If they're not on it, or if they appear under a parent company name you don't recognize, ask them to clarify exactly which legal entity holds the certification.

For reference: Halo Security operates as TrustedSite, LLC on the PCI SSC ASV list, with certificate number 5078-01-11.

2. How do you handle disputed scan results?

False positives happen in ASV scanning. Automated tools flag vulnerabilities based on banner information and version strings, and they can't always account for backported patches, compensating controls, or configurations that look vulnerable from the outside but aren't exploitable in your environment.

Per the ASV Program Guide, disputes are resolved between you and your ASV directly — they don't go to the PCI SSC. That means the quality of your ASV's dispute process is entirely on them.

Ask specifically: What evidence do you accept for a false positive dispute? What's your typical turnaround on a dispute review? Can I see an example of a dispute report? A vendor with a mature dispute process will have clear answers. One that hasn't thought about it much will hedge.

3. What does your remediation guidance actually look like?

A scan report that hands you a CVSS score list and a CVE number is technically a deliverable. It's not particularly useful to a security team trying to prioritize remediation across a real environment.

Ask to see a sample report. Good remediation guidance explains what the vulnerability is, why it matters in the context of your cardholder data environment, and what a fix actually looks like — not just a pointer to an NVD entry. If you're also integrating Known Exploited Vulnerabilities from the CISA KEV catalog into your prioritization process, ask whether their reporting maps findings to the KEV list.

The difference between a useful report and a checkbox report becomes very clear the first time a finding needs to go to an engineer with no security background.

4. How do you handle assets that aren't in my initial scope?

Scope definition is the customer's responsibility under the PCI DSS. But organizations routinely undercount their external footprint — forgotten subdomains, cloud assets spun up outside the security team's visibility, IP ranges acquired through mergers. If your ASV only scans what you hand them, those gaps stay gaps.

Ask whether the vendor offers any discovery scanning capability to help you identify assets that belong in scope but aren't currently tracked. An ASV that helps you get scope right is more valuable than one that just runs clean scans against an incomplete list. Undiscovered assets don't show up on your report,  but they do show up in breach reports.

This is also where a broader attack surface management program complements your ASV scanning. The ASV validates compliance; continuous asset discovery makes sure the ASV is seeing everything it should be.

5. Can your platform integrate with my existing security stack?

Quarterly compliance scans generate findings. Those findings need to get to the right people, tracked through remediation, and closed before the next scan window. If your ASV's results live in a PDF or a portal that doesn't connect to anything else, that handoff becomes a manual process every quarter.

Ask about integrations with your ticketing system (Jira, ServiceNow), your SIEM, and your notification channels. Ask whether findings can be exported in a format your team can actually use. The more friction there is between scan output and remediation action, the longer vulnerabilities stay open.

6. Do you offer manual penetration testing alongside scanning?

ASV scans are automated. They're good at finding known vulnerabilities on externally reachable systems — the low-hanging fruit that a script or opportunistic attacker could find without much effort. What they don't find: business logic flaws, authentication bypasses, chained vulnerabilities that require a human to connect the dots.

PCI DSS Requirement 11.4 requires penetration testing separately from ASV scanning for a reason. If you're working with two different vendors for these two requirements, ask how results are correlated. If a finding shows up in both the ASV scan and the pentest, you want one clear remediation path, not two parallel reporting tracks.

Working with a vendor that offers both external vulnerability scanning and manual penetration testing in the same platform simplifies that considerably. You get a single view of your external risk posture instead of stitching together two separate reports.

7. What happens to my security posture between scans?

PCI DSS sets quarterly scans as the minimum. It's a requirement, not a security strategy. A lot can change in 90 days — new systems get deployed, software gets updated, cloud infrastructure shifts. Any of those changes can introduce new exposure that won't appear on your compliance record until the next scheduled scan.

Ask whether the vendor offers any continuous monitoring between quarterly scans, and what triggers an out-of-cycle scan recommendation. The PCI DSS already requires scans after significant network changes; a good ASV should make it easy to act on that requirement, not just remind you it exists.

Continuous external vulnerability management between formal ASV scans is one of the clearest signs that a vendor thinks about your security, not just your compliance calendar.

The Bottom Line

Every ASV on the PCI SSC list meets the same baseline standard. The right one for your organization goes beyond that baseline,  helping you get scope right, giving you remediation guidance you can actually act on, handling disputes efficiently, and fitting into your existing security workflow.

The questions above won't take long to ask. The answers will tell you a lot about what the relationship will actually look like once the contract is signed.

If you want to talk through your PCI ASV requirements with a team that's been doing this for a while, we're here to help.

Frequently Asked Questions