Quarterly PCI Scans: Building a Cadence That Doesn't Surprise You on Day 89

Quarterly PCI scans are required under PCI DSS v4.0.1, but quarterly is the minimum frequency, not the operating rhythm. The standard requires an external vulnerability scan by a PCI SSC Approved Scanning Vendor (ASV) at least once every three months, with a passing result. Teams that run ASV scans weekly, review remediation monthly, and submit their compliance report early in the quarterly window treat the formal scan as a confirmation of work already done, not a deadline to scramble against.

What "quarterly" actually means in PCI DSS v4.0.1

Requirement 11.3.2 of PCI DSS v4.0.1 is specific. External vulnerability scans must be performed:

• At least once every three months
• By a PCI SSC Approved Scanning Vendor (ASV)
• With vulnerabilities resolved and ASV Program Guide requirements for a passing scan met
• With rescans performed as needed to confirm passing status

Assessors examine ASV scan reports from the last 12 months to verify that scans occurred at least once every three months in the most recent 12-month period. The standard provides a narrow exception for initial assessments: four passing scans in the first 12 months are not required if the most recent scan passed, the organization has a documented quarterly scanning policy, and prior vulnerabilities were corrected per rescan. After the initial year, passing scans every three months become non-negotiable.

The standard itself recommends more frequent scanning. Its Good Practice note explicitly states that scans more often than every three months are recommended depending on network complexity, frequency of change, and the systems in use.

Why the day-89 fire drill happens

The pattern repeats across merchants every quarter:

• A scan is scheduled for late in the window
• It fails because something new appeared in the last 60 days that nobody caught
• The compliance report is due in days, not weeks
• Remediation, rescanning, and ASV sign-off all have to happen inside that runway

The cause isn't the ASV. It isn't the scan itself. The calendar-driven approach is the problem, where the quarterly scan is treated as a single event instead of a cadence. By the time findings arrive, the rescan window is already closed.

Building an external vulnerability management program around a single quarterly event guarantees the fire drill. Building it around a continuous rhythm prevents it.

A better rhythm: weekly ASV scans, monthly reviews, early submission

Weekly: scan continuously through your ASV

ASV scans run through a continuous scanning service are valid PCI scans. PCI DSS permits multiple scan reports within a three-month cycle to be combined to show that all systems were scanned and that vulnerabilities were resolved as part of the cycle.

Running ASV scans weekly surfaces new CVEs, expired certificates, configuration drift, and newly exposed services within days. Findings stay small and current instead of accumulating into a 90-day backlog.

Monthly: review, prioritize, remediate

A standing monthly remediation review keeps the queue from becoming a quarter-end avalanche. Each review produces two outcomes: confirmed fixes that have been rescanned and closed, and known items with target dates and owners.

Monthly is also when false positives get disputed with the ASV. Letting disputes stack up until quarter-end is one of the most common causes of a "failed" scan that didn't actually need to fail.

Early in the window: submit your compliance report

Submit the formal compliance report well before the end of the quarterly window. The ASV needs time to sign it off, and any issues flagged during sign-off need time to remediate and rescan. Submitting on day 85 leaves nothing. Submitting earlier leaves runway for whatever the scan finds.

This is the discipline most teams skip. Even with weekly scans and monthly reviews in place, sending the report on day 89 puts compliance at the mercy of a single result.

What triggers an off-cycle scan

Requirement 11.3.2.1 of PCI DSS v4.0.1 requires external scans after any significant change, with vulnerabilities scored 4.0 or higher on CVSS resolved. These scans don't have to be performed by an ASV but must be done by qualified personnel who are organizationally independent of the system being scanned.

A weekly scanning cadence catches most of this automatically. The formal scan after a significant change still needs to be documented as part of change control. If a new system goes live or a major architecture change happens, the change-control record should show that a scan was performed and high-risk findings resolved before the change is considered complete.

Common quarterly PCI scan mistakes to avoid

• Running one scan late in the quarter with no rescan runway
• Submitting the compliance report at the deadline instead of early in the window
• Treating scope as static between scans, when new assets appear constantly
• Letting false-positive disputes stack up until quarter-end
• Letting internal scanning under Requirement 11.3.1 drift out of sync with external scanning under 11.3.2

The scope point matters most. Teams that don't continuously monitor all assets on their attack surface discover at quarter-end that the asset list is wrong. New subdomains, new cloud workloads, and shadow IT show up between scans, and the next quarterly report has gaps the ASV will flag.

That's part of why external scanning alone isn't enough. Scanning without continuous discovery scans yesterday's environment.

How Halo Security supports a continuous PCI scanning cadence

Halo Security is a PCI SSC Approved Scanning Vendor. The platform pairs continuous asset discovery with auto-configured scanning, so scope stays accurate and findings surface within days of appearing.

Expert remediation guidance accompanies findings instead of leaving a CSV on your desk. Teams move from "what does this mean?" to "what do I fix first?" without a separate research step.

Ready to build a continuous PCI scanning cadence?
Talk to our PCI ASV team.

FAQ