PCI DSS 4.0.1 Deadline: What Changes for ASV Scanning in 2026
The PCI DSS 4.0.1 deadline has passed — see what's newly enforced for ASV scanning in 2026, what changed from v4.0, and what merchants must fix now.
Switching ASV vendors mid-cycle is something more organizations should be willing to do when their current provider isn’t delivering, but most hesitate because they’re not sure whether it’s allowed or whether it puts their PCI DSS status at risk. The trigger is usually one of a few familiar problems: a scan that keeps producing false positives, support that’s gone quiet, a pricing jump at renewal, or an acquirer flagging the incumbent vendor directly.
Whatever the reason, the question that follows is the same: can this happen mid-cycle, without breaking PCI DSS Requirement 11.3.2, or do you have to wait for the next quarter? This guide covers exactly what happens when you change ASVs partway through a compliance cycle, what resets, what needs to be transferred, and how to sequence the switch so no quarter goes unscanned.
Approved Scanning Vendor (ASV): An organization approved by the PCI Security Standards Council (PCI SSC) to conduct external vulnerability scans of internet-facing systems under PCI DSS Requirement 11.3.2. Only scans from a currently approved ASV count as valid compliance evidence.
Compliance cycle: The recurring quarterly window in which a passing external scan must be completed. The cycle itself is not vendor-specific; it continues regardless of which ASV performs the scan.
Scan scope: The full inventory of internet-facing IP addresses, domains, and subdomains that must be included in every scan.
ASV rescan: A follow-up scan is required after an initial scan fails once the identified vulnerabilities have been remediated. The same rescan obligation applies no matter which vendor ran the original scan.
Attestation of Scan Compliance (AoSC): The formal report an ASV issues once a scan passes; the evidence submitted to your QSA or acquiring bank.
Yes. PCI SSC does not require you to keep the same ASV for the full duration of a compliance period. You can cancel a contract and onboard a new ASV at any point, as long as a passing scan is still completed within each rolling quarterly window.
This is the point most merchants get wrong: they assume mid-cycle means mid-compliance risk. It doesn’t. Compliance is determined by your scan results and scanning schedule, not by which approved vendor conducted the scan. PCI DSS v4.0 and the ASV Program Guide are explicit that vendor changes are permissible, provided scans stay on schedule and are performed by a currently approved ASV.
Secusy ASV delivers fast turnaround, transparent pricing, and expert support from day one.
Because staying with an underperforming vendor is often the bigger risk. The most common triggers are slow support, inaccurate scan results, non-transparent pricing, and acquirer-driven vendor changes.
Support responsiveness matters more than most merchants expect going in. When a scan returns unexpected findings or an IP range needs updating, you need answers in hours, not days, not a push toward a paid professional-services tier for a routine question. Scan accuracy is the second major driver: an ASV that produces constant false positives creates unnecessary remediation work, while one that’s too permissive can hand you a pass that doesn’t reflect real exposure; the more serious failure mode of the two. Pricing is a legitimate factor as well.
The ASV market has matured, and PCI SSC-approved options now exist at a fraction of legacy pricing without a drop in scan quality. None of these is reasons to tolerate risk; they’re reasons an ASV vendor migration is the right call.
No. Each ASV runs its own scan engine, methodology, and reporting format, so a pass from your old vendor isn't accepted as a substitute by the new one.
Your new ASV will scan your environment independently and issue its own AoSC, this is not a paperwork handoff. Build the time for a fresh scan into your migration timeline rather than assuming continuity. It’s also normal for the first scan with a new vendor to surface findings the old one didn’t flag, or vice versa; different scanning tools can produce somewhat different results, which is an acknowledged reality within the PCI DSS framework. What matters is whether the new vendor explains and categorizes those findings clearly and gives you an actionable remediation path.
Your complete IP inventory, prior passing scan reports, remediation records, and any dispute or exception documentation.
Your IP address inventory is the foundation of every scan, if your new vendor scans an incomplete or outdated list, the report won’t accurately represent your external attack surface and may not satisfy your QSA or acquirer. Before onboarding, run an internal review of every internet-facing IP and domain, including anything added since your last scan. Historical scan reports and remediation notes give your new vendor context: is it a finding of a long-standing known issue or something new? That context keeps you from relitigating resolved findings.
If you’ve previously filed dispute forms or exception requests for false positives or accepted compensating controls, get copies of that documentation before the relationship ends. Well-structured ASV providers will actively request this during onboarding, which is itself a sign of operational maturity worth screening for.
Run an overlap window instead of a hard cutover, keep the outgoing vendor active until the new vendor has completed a passing scan.
The ideal time to start a PCI ASV scan transition is right after completing a passing scan with your current vendor; that gives you maximum runway before the next scan is due. If you’re already mid-quarter with a scan deadline approaching, you can still switch, but move with urgency and confirm upfront that your new vendor can onboard and schedule fast enough to hit the deadline.
Avoid starting a migration while you have open remediation items or a failing scan in progress; finish that rescan cycle, get your passing report, then execute the switch. This costs one extra invoice cycle from the outgoing vendor, but it removes the risk of a quarter closing with no passing scan on file, which is the actual finding an assessor will raise, not the vendor change itself.
They don't change. If your new vendor's first scan returns a failing result, you're required to remediate and undergo a rescan, exactly as you would with any other vendor.
This is where some organizations trip up: switching vendors doesn’t reset the clock or give you a pass on failing findings. PCI DSS Requirement 11.3.2 requires passing results from a currently approved ASV regardless of when in the cycle the scan happened or who ran it. If you’re switching at a point in your cycle when time is tight, factor in the possibility that your new vendor’s first scan won’t pass cleanly; don’t assume it will just because your prior scans did. Rescan pricing also varies significantly across vendors: some charge per rescan, others include them in standard pricing. Confirm this explicitly before signing, since it has a direct cost impact if your environment needs more than one remediation pass.
Audit, vet, overlap-scan, cut over, and archive, in that order.
Pull your full IP/domain inventory and download every prior AoSC and dispute record from the outgoing vendor.
Confirm current PCI SSC approval status, check reporting format, support responsiveness, and rescan pricing, and compare directly against what's failing you with the current vendor.
Onboard the new vendor and complete a passing scan before canceling the old one. Well-run providers can typically schedule this within one to two business days for straightforward environments.
Cancel the outgoing vendor only after the new AoSC is confirmed in hand.
Store both vendors' historical reports together so your compliance record reads as one continuous history, and make sure your QSA or internal compliance team is aware of the vendor change.
They don't change. If your new vendor's first scan returns a failing result, you're required to remediate and undergo a rescan, exactly as you would with any other vendor.
Switching ASV vendors mid-cycle is a routine operational decision, not a compliance violation. PCI DSS Requirement 11.3.2 doesn’t tie you to one vendor for a full period, and the ASV Program Guide confirms vendor changes are permissible as long as scans stay on schedule. What determines whether the switch stays routine is how you sequence it: treat the scan and scope as non-transferable, run an overlap window instead of a hard cutover, and carry your documentation and dispute history forward.
The failure mode to avoid isn’t “wrong vendor”; it’s a quarter that closes with no passing scan because the handoff wasn’t timed. Organizations that treat the migration as a structured project, rather than an afterthought, come through it with a clean compliance record and, usually, a better vendor relationship than the one they left.
This guide reflects PCI DSS v4.0 and PCI SSC’s ASV Program Guide as published by the PCI Security Standards Council. Always verify your prospective vendor’s current approval status directly on the PCI SSC website before completing a migration.
No, not inherently. Compliance is determined by scan results, remediation, and adherence to the scanning schedule, not by which approved vendor performs the scan. Keeping complete documentation through the transition protects your record.
The standard ASV rescan requirements apply: you remediate the flagged vulnerabilities and complete a rescan before the scan counts as passing, the same process as with any vendor, at any point in the cycle.
They can, rescan pricing varies by vendor, with some charging per rescan and others including it in standard pricing. Confirm this before signing so a possible second scan doesn't come as a surprise cost.
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.