Website Changes That Trigger a New PCI ASV Scan
Not sure if your website changes require a new PCI ASV scan? See which infrastructure changes trigger a rescan, and which ones don't.
PCI ASV scan frequency sounds like the simplest requirement in PCI DSS 4.0.1: scan every 90 days, done. In practice, it’s one of the most commonly mishandled: merchants track the wrong start date, miss the trigger for a mid-cycle scan after an infrastructure change, or discover during an acquirer review that their “quarterly” scans have quietly drifted past the 90-day mark. None of that shows up until your acquirer asks for scan evidence and your QSA checks the dates, and by then, even a one-week gap can stall your assessment or flag you with your payment brand.
The rule itself is precise; the confusion comes from how it’s applied. This guide walks through exactly what Requirement 11.3.2 says, the specific points where merchants get the timing wrong, and how to build a scan schedule that holds up under review every time.
Requirement 11.3.2: the PCI DSS 4.0.1 clause requiring external vulnerability scans at least once every three months, performed by a PCI SSC Approved Scanning Vendor.
Requirement 11.3.2.1: the companion clause requiring an additional scan after any significant change to your environment, independent of your quarterly cadence.
90-day window: the compliance clock that runs from the date of your last passing scan, not from a fixed calendar quarter.
Rolling 12-month period: the trailing 12 months of your QSA reviews to confirm four passing scans occurred are required from year two of assessment onwards.
ASV (Approved Scanning Vendor): a company on the current PCI SSC list authorised to perform the scans this requirement mandates. See what a PCI ASV scan checks.
Rescan: a follow-up scan confirming that findings from a failed scan have been remediated; the rescan date, not the initial scan date, is what counts against your deadline.
PCI DSS 4.0.1 Requirement 11.3.2 mandates external vulnerability scans at least once every three months, performed by a PCI SSC Approved Scanning Vendor, with four passing scans required per rolling 12-month period.
PCI DSS 4.0.1 Requirement 11.3.2 mandates external vulnerability scans at least once every three months, performed by a PCI SSC Approved Scanning Vendor. The 90-day window runs from the date of your last passing scan; not from a fixed calendar quarter. Additional scans are required after any significant change to your environment. Four passing scans per rolling 12-month period are required for ongoing compliance.
The requirement mandates three things at once: scans at least every 90 days, every scan performed by a PCI SSC-listed ASV, and all vulnerabilities resolved with rescans confirming remediation.
The exact text from the ASV Program Guide is unambiguous: external vulnerability scans must be performed at least once every three months by a PCI SSC Approved Scanning Vendor. The assessment procedure (11.3.2.a) requires your QSA to examine scan reports from the last 12 months to confirm that at least four scans occurred within that period.
Three things that requirement mandates simultaneously:
A scan report from a non-listed vendor, regardless of how thorough it is, does not satisfy this requirement. The ASV’s listing status on the date the scan was performed is what counts, and your QSA will verify it.
The 90-day clock starts from the date of your last passing scan, not from January 1st or a fixed calendar quarter, and it's the rescan date, not the initial scan date, that determines whether you're within the window.
Most merchants think in calendar quarters; Q1, Q2, Q3, Q4. That’s not how Requirement 11.3.2 works, and the distinction trips up a surprising number of otherwise well-run compliance programs.
The clock starts from the date of your last passing scan, not January 1st. If your last passing scan was issued on 15 March, your next scan must produce a passing result by 13 June; 90 days later. Run your scan on 10 June, fail on a medium-severity finding, remediate, and rescan on 20 June: you’ve just missed your window. The rescan date is what matters, not the initial scan date.
This is why unlimited rescans matter operationally, not just financially. If you’re paying per scan, a failed first attempt creates a direct incentive to delay remediation until the next cycle, which is exactly the wrong behaviour from a compliance standpoint. See how PCI ASV scan cost is affected by rescan pricing models.
Scan Event | Date | 90-Day Deadline |
|---|---|---|
Last passing scan | 15 March | — |
Next scan must pass by | — | 13 June |
Initial scan run | 10 June | — |
Rescan passing | 20 June | ❌ Window missed |
Rescan passing | 12 June | ✅ Within window |
The lesson: schedule your initial scan with enough buffer to remediate and rescan before the 90-day mark. For most environments, building in a two-to-three-week remediation window is practical. That means initiating your scan around day 65–70 of your cycle, not day 85. See our pre-scan preparation checklist for how to build that buffer in.
Beyond the quarterly cadence, any significant change to your environment: new IPs, firewall changes, new applications, infrastructure migration, or segmentation changes triggers an additional required scan.
Quarterly cadence is the baseline. PCI DSS 4.0.1 Requirement 11.3.2.1 introduces an additional trigger: significant changes to your environment require an additional external scan.
What counts as a significant change? The standard doesn’t enumerate every scenario, but the intent is clear; any modification that could alter your external attack surface warrants a scan. In practice that includes:
The scan triggered by Requirement 11.3.2.1 is in addition to your quarterly schedule; it doesn’t reset or replace it. Miss this trigger, and you’ve technically failed the requirement, even if your quarterly scans are clean. This is a gap that many merchants and some compliance advisors overlook. If you launched a new payment page, moved to a different hosting provider, or changed your CDN configuration between your standard quarterly scans, an additional scan is required. Reviewing your PCI ASV scan requirements after any infrastructure change is the safest habit here.
In your first 12 months of assessment, you don't need four passing scans on record; one passing scan plus documented scanning policies and corrected vulnerabilities is enough. From year two, four passing scans are a hard requirement.
For entities going through their initial PCI DSS compliance assessment, the standard includes a limited exception: it is not required that four passing scans be completed within the first 12 months, provided the assessor can verify three things:
This exception exists to give newly assessed entities a practical on-ramp. It does not apply in subsequent years. From year two onwards, four passing scans in the preceding 12-month period is a hard requirement with no discretion for the QSA.
No. A passing ASV scan report confirms compliance with Requirement 11.3.2 only; it says nothing about the rest of PCI DSS and doesn't replace your SAQ or ROC.
No, and this is a misconception worth addressing directly. Per PCI SSC guidance, an ASV scan report confirms compliance with Requirement 11.3.2 only. It says nothing about any other PCI DSS requirement. Your scan certificate is one piece of a much larger compliance picture. It does not replace your SAQ, ROC, or any other assessment documentation. Acquirers and payment brands may request scan reports alongside your SAQ submission, but the scan report standing alone is not a compliance declaration.
What a passing scan from a PCI SSC-listed ASV does give you: documented evidence for Requirement 11.3.2 that is accepted by all acquiring banks. One certificate, multiple acquirers; you don’t need to rescan for each relation.
Before each scan cycle, confirm your last passing date, calculate your 90-day deadline, schedule the initial scan by day 65–70, and verify scope, remediation readiness, and rescan timing.
A lapsed scan cadence is a compliance failure; consequences range from a flagged SAQ gap to formal acquirer notification, with the most common real-world impact being a stalled account review.
A lapse in scan cadence is a compliance failure. Depending on your merchant level and payment brand requirements, the consequences range from a compliance gap on your SAQ to formal notification to your acquirer. In worst-case scenarios; particularly where an account data compromise follows a period of lapsed scanning; the exposure is substantial.
The practical risk for most small-to-mid-size merchants is simpler: your acquirer requests scan evidence during an annual review and the dates don’t stack up. That triggers remediation activity, potentially a formal compliance plan, and delay in any account processing agreements you’re trying to expand.
Running scans consistently at a fixed cadence; rather than scrambling quarterly; is the lowest-effort risk mitigation available. At $80/year for a single IP, the cost of maintaining that cadence is trivial against the cost of a compliance gap.
For a deeper look at the full scope of what ASV scanning covers, see PCI ASV Scanning Services: Everything You Need to Know.
The quarterly ASV scan requirement is one of the more mechanical aspects of PCI DSS 4.0.1; the rule is clear, the cadence is fixed, and the consequences of slipping are predictable. What varies is how much friction you introduce into the process. Track your last passing date, build a remediation buffer into your schedule, and treat significant infrastructure changes as their own scan trigger, and PCI ASV scan frequency stops being a compliance risk and becomes routine.
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.