PCI Quarterly Scans: How ASV Scans Work and Pass

PCI quarterly scans are external vulnerability scans of your internet-facing systems. An Approved Scanning Vendor (ASV) must run them, and you need a passing result at least once every three months. If you take card payments and complete certain Self-Assessment Questionnaires, or you are a service provider, this requirement applies to you. This guide covers who is in scope, what a pass looks like, what to do when a scan fails, and what to keep on file.

TL;DR

• PCI DSS Requirement 11.3.2 calls for a passing external vulnerability scan by an ASV at least once every three months, so "quarterly" is the minimum rhythm.
• A passing report contains no vulnerabilities ranked medium or high. If findings appear, you fix them and rescan with the ASV until the report passes.
• The scan covers internet-facing components in your cardholder data environment or with a path to it. A missed system is a gap in your compliance, not a shortcut.
• For a first PCI DSS assessment you do not need four passing scans on file, but you do need a clear scan history from then on.

Table of Contents

• What PCI quarterly scans are
• Who needs quarterly ASV scans
• What is in scope for an external scan
• What a passing scan looks like
• What to do when a scan fails
• Evidence to keep
• Building a scanning rhythm that does not surprise you
• Common reasons quarterly scans go wrong
• Perspective: why one accountable team makes scanning easier
• How Nexus supports quarterly PCI scanning
• A simple quarterly calendar
• FAQ
• Sources

What PCI quarterly scans are

A quarterly scan is an external vulnerability assessment. A scanning tool probes the public-facing side of your environment, such as web servers, payment pages, VPN gateways and mail hosts. It looks for known weaknesses an attacker could reach from the internet. The PCI Security Standards Council (PCI SSC) describes an ASV scan as a required assessment performed by a vendor the Council has qualified. You cannot run it yourself with a free tool and count it.

People use "PCI quarterly scans" and "PCI ASV scans" for the same thing. "Quarterly" describes how often. "ASV" describes who performs the scan. Both halves of the requirement matter: the scan must be done by an approved vendor, and it must be done at least every three months.

The control sits under PCI DSS Requirement 11.3.2. The ASV Resource Guide states that the requirement mandates a passing external scan by an ASV at least once every three months. The wording says passing. A scan that runs on schedule but still shows unresolved findings does not meet it, a point the PCI Compliance Hub also makes about the control's phrasing.

Who needs quarterly ASV scans

The ASV Resource Guide lists who is expected to complete them. Quarterly ASV scans are included for merchants completing SAQ A, A-EP, B-IP, C and D, and for service providers completing SAQ D.

In practice that covers a wide range of businesses:

• E-commerce merchants that host their own checkout or run a site that affects how payment pages are delivered.
• Retailers and restaurants with internet-connected payment terminals or point-of-sale systems.
• Healthcare practices that take card payments from patients and also have to meet HIPAA.
• Service providers such as billing platforms, hosting companies and managed payment services that handle card data for others.

Your SAQ type is the first thing to confirm. It depends on how you accept cards, and your acquiring bank or payment processor can tell you which one you were assigned. If you are unsure whether scanning applies, ask them before you buy a scan. If you are on an assessor-led Report on Compliance, your assessor will test the same requirement.

If you want to see how scanning fits the rest of the standard, our guide to PCI DSS requirements and the evidence auditors want covers the other controls an assessor will ask about.

What is in scope for an external scan

Scope is where most scanning problems start. The ASV program guide defines the scope as all internet-facing system components owned or used by the customer that are part of the cardholder data environment or that provide a path to it. That second clause catches systems people forget.

Typical in-scope items:

Two habits keep scope accurate. First, keep a current inventory of public IP addresses and domains, including those that cloud teams create outside of a formal change process. Second, review the inventory before each scan, not only once a year. Our piece on attack surface management explains how to keep that list from drifting.

Leaving a required component out of the scan creates real exposure. An unscanned gateway can be the weak point even when every scanned host is clean. For a plain-language look at what happens to a small business when a connected system is overlooked, see this practical cybersecurity guide for SMEs.

What a passing scan looks like

The rule is simple to state. According to the ASV Resource Guide, a report passes only when it contains no vulnerabilities ranked as medium or high severity. Low-severity findings alone do not stop you passing.

Three things follow from that:

1. One medium finding fails the scan. There is no scoring that lets a good average offset a bad item.
2. The scan is a snapshot. A pass shows the state of your systems on the day of the scan. Systems can change the next day.
3. A pass covers one requirement. It shows you met the external scanning requirement. It is not a certificate of full PCI DSS compliance, and your assessor or acquirer will still ask for the rest of your evidence.

What to do when a scan fails

A failed scan is routine, not a crisis. The guide is direct about the response: you must fix the vulnerabilities and rescan with the ASV until you get a passing result.

A workable sequence:

1. Read the report by system, not by severity alone. Group findings by host so one change can close several items.
2. Assign an owner and a due date to each failing finding. Unowned findings are the ones that survive to the next scan.
3. Fix the cause. Typical fixes are patching software, closing an exposed service, replacing an outdated TLS configuration or removing a default page.
4. Rescan with your ASV. Keep rescanning until the report passes.
5. Save the failing report, the fix records and the passing report together. They show an assessor that your process works.

A note on timing. Do not wait until the last week of the quarter for your first scan. If the first run fails, you need time to patch, test and rescan, and some fixes need a maintenance window. Running the first scan early in each quarter gives you room.

Prioritisation helps when a report has many items. Our article on why KEV beats CVSS alone shows how to rank fixes by real-world exploitation, and the vulnerability remediation process guide covers how to turn findings into tracked work. A written patch management policy makes the fixes faster and easier to evidence.

Evidence to keep

Assessors ask to see that scans happened on time and ended in a pass. Keep, for each quarter:

• The full ASV scan report and the attestation of scan compliance.
• The date of each scan and rescan.
• The list of IP addresses and domains scanned, matched to your current inventory.
• Remediation tickets or change records for each failing finding.
• The passing rescan report.

For your first assessment, the bar is lower. The ASV Resource Guide says that for an initial PCI DSS assessment an entity does not need evidence of four passing scans. After that, plan to show a continuous history. A typical review looks back across your most recent four quarters, so a missed quarter is hard to repair later.

If you are preparing a first assessment, a short checklist of what reviewers expect from security teams is in this guide to security requirements and a two to four week plan, which helps with setting up repeatable evidence.

Building a scanning rhythm that does not surprise you

Quarterly is a floor. Teams that scan only once every three months tend to find problems at the worst time. A better pattern pairs the formal ASV scan with more frequent checks of your own.

• Continuous or weekly internal checks of your public ranges. These catch new exposures between ASV runs.
• A scan trigger on change. After a new server, a firewall rule change or a cloud deployment, check the external surface.
• A calendar owner. Name one person who books the ASV scan each quarter and reports the result.
• A pre-scan review. Confirm the IP and domain list, and make sure your firewall or web application firewall is not blocking the scanner, which can distort results.

External ASV scans are one part of a wider testing programme. They differ from internal vulnerability scans, which look at systems inside your network, and from penetration testing, which uses a human tester to try to chain weaknesses together. They complement each other. An approved third party performing the external scan also acts as an independent check on an otherwise self-attested report, which is part of why the rule exists.

For the bigger picture of running scanning as a programme, see our enterprise vulnerability management process guide.

Common reasons quarterly scans go wrong

Most failed or rejected scans come from a handful of causes:

• Incomplete scope. A new public IP was added by a cloud team and never reached the scan list.
• Blocked scanner. An intrusion prevention system or firewall interferes, so results do not reflect the real system.
• Skipped rescan. The team fixed the finding but never ran the rescan that produces the passing report.
• Unowned findings. The report went to a shared mailbox and nobody acted.
• Late start. The first scan ran in the final days of the quarter, leaving no time to fix and rescan.
• Mixing up scan types. A vulnerability scan from a general-purpose tool was filed as if it were an ASV report.

Every item on that list is a process failure, not a technology failure. A simple runbook, an owner and a calendar reminder remove most of them.

Perspective: why one accountable team makes scanning easier

Quarterly scans are easy to describe and surprisingly hard to run well when the work is spread across vendors. One team owns the firewall, another owns the cloud account, a third owns patching, and a fourth owns the audit binder. When a medium finding appears, nobody is sure whose fix it is.

We built Nexus around the opposite idea. Cybersecurity, cloud, network, managed IT and compliance sit under one provider with one SLA. That means the person who reads the scan result can reach the practitioner who changes the firewall rule, and the evidence ends up in the same place as the fix.

Our approach is designed so that scanning is a calendar item rather than a scramble: scope reviewed before each scan, findings assigned the same day, rescans scheduled as soon as fixes land, and the reports filed with the remediation records an assessor will ask for. Pricing is flat-rate and monthly, so a failed scan does not turn into a surprise invoice.

If you are tired of chasing three vendors to close one finding, consolidate. It is the fastest route we know to a clean quarterly cycle.

Nick - Sr. Executive

How Nexus supports quarterly PCI scanning

We provide the IT and security work that sits around the scan: keeping your inventory of internet-facing systems accurate, running vulnerability management between scans, remediating findings across cloud and network, and preparing compliance evidence for PCI-DSS alongside SOC 2, HIPAA and ISO 27001 work. Our services run under one SLA with flat-rate monthly pricing, and you work directly with senior practitioners.

If you want one team accountable for scope, fixes and evidence, see our managed IT and cybersecurity services, or start from the Nexus home page. For budgeting the wider programme, our PCI compliance cost guide lays out what US businesses should plan for.

A simple quarterly calendar

A repeatable calendar turns the requirement into routine. One example for a business running on a calendar-year cycle:

This leaves most of the quarter as a buffer for the case where a fix takes longer than expected. Adjust the weeks to your own release and maintenance schedule.

FAQ

How often do I need PCI ASV scans?

At least once every three months. Requirement 11.3.2 calls for a passing external scan by an ASV in that window. You can scan more often, and many teams do so to catch problems early.

Can I run the scan myself?

No. The external scan has to be performed by an Approved Scanning Vendor qualified by the PCI SSC. A scan from a general-purpose tool is useful for your own checks, but it will not satisfy the requirement.

What makes an ASV scan fail?

Any vulnerability ranked medium or high severity. The report passes only when none remain. Fix the findings, then rescan with the ASV until you get a passing report.

Do I need four passing scans for my first assessment?

Not for an initial PCI DSS assessment. The ASV Resource Guide says an entity does not need evidence of four passing scans at that stage. Afterwards you should keep a continuous quarterly record. Confirm the details for your situation with your acquirer or assessor.

Does a passing scan mean I am PCI compliant?

No. It shows you met the external scanning requirement for that period. Full compliance covers the other PCI DSS requirements for your SAQ type or assessment.

Sources

• Vulnerability Scans & Approved Scanning Vendors (PCI SSC ASV Resource Guide v1.2)
• Approved Scanning Vendors Program Guide (PCI SSC)
• PCI DSS 11.3.2 (PCI Compliance Hub)
• ASV Scanning (ABC Financial technical appendix)

Recommended

• PCI Compliance Cost: What US Businesses Should Budget
• PCI DSS Requirements: The Evidence Auditors Want for Security Teams