After Passing an ASV Scan: What Happens Next?
After passing an ASV scan, here's what to submit, how long results last, and how to set up your next quarterly compliance cycle without gaps.
Ask five merchants on five different platforms whether they need a PCI ASV scan, and you’ll likely get five different answers, most of them wrong. The confusion is understandable. PCI-DSS doesn’t publish a scanning requirement “for Shopify” or “for on-premises servers”. It publishes requirements based on how cardholder data flows through your systems and platform; both the type of infrastructure you run and the checkout technology sitting on top of it simply determine that flow.
This guide is the hub for understanding ASV scan requirements across every platform type a business is likely to operate: e-commerce storefronts, on-premises infrastructure, cloud and hybrid environments, and the specific checkout technologies most online merchants use, Shopify, WooCommerce, Stripe, Cloudflare-fronted architectures, and SaaS commerce platforms.
Each section gives you a direct answer for your setup, and the platform-specific sections link out to a full implementation guide. Use this page to find where you sit, then click through to the guide that matches your infrastructure.
PCI DSS (Payment Card Industry Data Security Standard): The security standard published by the PCI Security Standards Council that applies to any business storing, processing, or transmitting cardholder data.
ASV (Approved Scanning Vendor): A company vetted and approved by the PCI SSC to conduct external vulnerability scans on internet-facing systems as part of PCI DSS compliance validation.
PCI DSS Requirement 11.3: The requirement mandating that internet-facing systems within or connected to the cardholder data environment be scanned at least quarterly, and after any significant network change, by an approved ASV.
SAQ (Self-Assessment Questionnaire): The validation document merchants complete to attest to PCI compliance. The SAQ type (A, A-EP, C, D, etc.) is determined by how a merchant's payment page is built and hosted, and it determines whether ASV scanning applies.
CDE (Cardholder Data Environment): The people, processes, and technology that store, process, or transmit cardholder data, or that could impact the security of that data; this is the scope your ASV scan needs to cover.
External Vulnerability Scan: An automated scan performed from outside your network perimeter to identify vulnerabilities visible to a potential attacker, conducted by a PCI SSC-approved ASV.
Hosted checkout/redirect: A payment flow where the customer is sent to a third-party-hosted payment page (or an iframe/embedded form is loaded directly from that provider), so raw card data never touches the merchant's own server.
Self-hosted/direct integration: A payment flow where the merchant's own server or code plays a more direct role in constructing or handling the payment page, which typically expands PCI scope.
Network segmentation: Isolating the cardholder data environment from the rest of the network using firewalls and access controls, which, when properly implemented and validated, can reduce ASV scan scope.
Any business that stores, processes, or transmits cardholder data must run quarterly external vulnerability scans through a PCI SSC-approved ASV, remediate any high-severity findings, and obtain a passing scan report before that quarter's requirement is satisfied.
This traces back to PCI DSS Requirement 11.3: scans must cover every internet-facing system within or connected to your cardholder data environment, at least once every three months, and again after any significant network change, a new component added, a firewall rule change, or an infrastructure upgrade. It’s not something you can run yourself with an off-the-shelf scanner; it has to come from a vendor holding active ASV status with the PCI SSC. Full requirements are covered in our PCI ASV scan requirements guide.
The process itself is straightforward once scope is defined correctly: your ASV scans all in-scope IP addresses and domains, issues a report, and marks the result as passing or failing. Anything rated high severity or above triggers remediation and a re-scan. What trips businesses up isn’t the scanning; it’s the scoping.
Third-party integrations, connected payment gateways, hosting infrastructure, and remote access points can all fall within scope even when they don’t look like “the website” at first glance.
Secusy ASV maps your exact scan scope in one call, no guesswork, no wasted quarter.
Your platform doesn't set your ASV requirement directly; it sets your SAQ type, and your SAQ type sets your ASV requirement. Hosted, fully-redirected checkouts generally land in SAQ A, which under PCI DSS v4.0.1 now also requires quarterly ASV scanning. Any custom code, embedded form, or self-managed server touching the payment page pushes you toward SAQ A-EP or SAQ D, both of which have always required it.
Under PCI DSS v3.2.1, SAQ A merchants were exempt from ASV scanning entirely. That changed with v4.0.1: SAQ A now includes Requirement 11.3.2, requiring quarterly external scans of the webpage that hosts the redirect or iframe, because that page itself became a documented attack vector for card-skimming (Magecart-style) attacks. This is the single most common source of “I didn’t know I needed this” among merchants on hosted platforms. if you’re unsure, start with do I need PCI ASV scanning.
E-commerce businesses are among the most commonly required to hold PCI ASV compliance, since their payment pages, checkout systems, and hosting infrastructure are directly internet-facing and fall squarely within the cardholder data environment.
If you sell online and accept card payments, your entire public-facing footprint is a potential target: shopfront IPs, payment pages, any API connecting checkout to a gateway, and the hosting environment behind all of it. The scan needs to cover all of these, not just the URL a customer sees in their browser.
Hosted vs. self-managed e-commerce. If you use a fully hosted solution where card data never touches your servers, your scope may be narrower, and your provider’s own compliance documentation can sometimes reduce what you’re directly responsible for. If you run a self-managed platform, open-source CMS, custom application, or dedicated server, your scope is broader by default, and every internet-facing component that touches or could impact cardholder data belongs in your quarterly scan. Assuming a narrower scope without verified evidence is a risk acquiring banks take seriously.
Within e-commerce, the checkout technology you use narrows this further. The platform-specific guides below cover the details:
PCI Compliance for Shopify: Standard Shopify Payments with default checkout is generally covered by Shopify's own quarterly ASV scans under SAQ A. Custom checkout extensions, headless Shopify (Hydrogen), or apps that inject scripts into checkout pull your own domain into scope.
WooCommerce PCI Compliance: WooCommerce is self-hosted, so your server is in scope regardless of gateway. Most merchants land in SAQ A or SAQ A-EP, and quarterly ASV scanning applies under either.
PCI Compliance for Stripe: Stripe Checkout (hosted redirect) supports SAQ A eligibility but still requires quarterly ASV scanning of your webpage under v4.0.1. Stripe Elements typically requires SAQ A-EP with a broader scan scope.
Businesses running their own servers, network hardware, and data centre infrastructure must include every internet-facing IP address connected to or within their cardholder data environment in their quarterly ASV scan, there is no shared provider to offload part of that scope to.
On-premises environments feel the most controllable, and in many ways they are, but that control comes with full responsibility. Unlike cloud-hosted setups where the provider shares part of the compliance burden, on-premises places the entire external perimeter squarely on the business.
Network segmentation and scope reduction. Isolating the cardholder data environment from the rest of the network with firewalls and access controls can meaningfully reduce how many systems fall within the ASV scan scope, fewer IPs to scan, fewer findings to remediate, and a cleaner path to a passing result each quarter. But segmentation only counts if it’s implemented correctly and can be demonstrated as effective; segmentation that exists on paper but hasn’t been technically validated doesn’t reduce your obligations. This is worth reviewing with your ASV before scoping, not after.
Cloud and hybrid environments split compliance responsibility under a shared model: the cloud provider secures the underlying infrastructure, but the business remains responsible for scanning the operating systems, applications, configurations, and internet-facing services it deploys within that environment.
Major cloud platforms secure the physical data centres, networking hardware, and compute resources. Everything you deploy on top of that VMs, load balancers, containerised applications, API gateways, and anything else reachable from the public internet- is yours to scan. Because cloud resources can be spun up and down quickly, keeping an accurate, current inventory of scan targets is one of the more important ongoing tasks here, not a one-time setup step.
Hybrid environments, where some systems sit on-premises and others in the cloud, carry the highest risk of scope gaps; it’s easy for a system to fall between the two inventories. Mapping both environments together, rather than treating them as separate scanning exercises, is the safest way to avoid that.
A CDN or WAF sits inside this picture too. Putting your site behind Cloudflare doesn’t remove your scanning requirement; it changes what needs to be scanned and how. Your ASV still needs to reach the IP addresses and hostnames that are actually internet-facing, whether that means scanning through the CDN as configured or coordinating with your ASV to separate edge-layer findings from origin-server findings.
SaaS commerce and vertical SaaS platforms typically maintain their own PCI DSS compliance and ASV attestations for their core infrastructure, but any custom domain, subdomain, embedded widget, or API integration a customer adds is usually the customer's own responsibility to scan.
This pattern repeats across every platform type covered above: the vendor secures the shared infrastructure, and the tenant is responsible for what they build on top of it. Treating a SaaS vendor’s compliance certificate as covering your own customizations is one of the more common and more consequential assumptions businesses make.
Get a platform-specific ASV scan quote with no setup fees and fast turnaround.
Platform / environment | Typical SAQ type or model | ASV scan required? | What gets scanned |
|---|---|---|---|
Shopify (default checkout, Shopify Payments) | SAQ A | Usually covered by Shopify; scan your own domain if you run apps/scripts on checkout | Merchant domain if in scope </td |
Shopify (custom/headless checkout) | SAQ A-EP | Yes, quarterly | Merchant server, domain, hosting |
WooCommerce + hosted gateway (Stripe/PayPal redirect) | SAQ A | Yes, quarterly | WordPress hosting, server, domain |
WooCommerce + embedded payment form | SAQ A-EP | Yes, quarterly | Full server and application stack |
Stripe Checkout (hosted redirect) | SAQ A | Yes, quarterly | Merchant webpage hosting the redirect |
Stripe Elements (embedded) | SAQ A-EP | Yes, quarterly | Merchant server and hosting |
On-premises infrastructure | Varies (often SAQ D) | Yes, quarterly | All internet-facing IPs within/connected to the CDE |
Cloud-hosted infrastructure | Shared responsibility | Yes, for what you deploy | VMs, load balancers, containers, API gateways you control |
Hybrid (on-prem + cloud) | Varies | Yes, mapped across both environments | Combined inventory across on-prem and cloud scan targets |
Site behind Cloudflare | Depends on underlying setup | Yes, if otherwise required | Internet-facing IPs/hostnames, coordinated with CDN config |
SaaS platform, no custom domain touching checkout | Platform-managed | Usually not for the core platform; check your integration | Custom domains/subdomains you control |
The most common mistakes are assuming a hosted gateway or cloud provider removes all scanning obligation, forgetting that third-party apps and scripts on the checkout page expand scope, treating "segmented" as true without technical validation, and scanning only the primary domain while ignoring subdomains, staging environments, or hybrid systems that are also internet-facing.
Each of these tends to surface at the worst possible time, an acquiring bank review or a breach investigation, rather than during routine planning, which is exactly why scope should be confirmed proactively against your actual infrastructure rather than assumed from your platform’s marketing page.
PCI ASV compliance is not a single, one-size-fits-all checkbox; it’s a requirement that has to be mapped to the platform you actually operate, at two levels. First, the type of infrastructure: e-commerce, on-premises, cloud, or hybrid, each with a different starting scope and a different responsibility split. Second, within e-commerce specifically, the checkout technology: Shopify, WooCommerce, Stripe, a CDN layer like Cloudflare, or a SaaS platform, each of which narrows or widens that scope further based on how much of the payment flow touches your own infrastructure.
What stays constant across all of them is PCI DSS Requirement 11.3: quarterly external scans, by a PCI SSC-approved ASV, with clean remediation before you’re compliant. The businesses that get this wrong are rarely scanning incorrectly; they’re scoping incorrectly, usually because they assumed their platform had it covered.
Secusy ASV delivers fast turnaround, transparent pricing, and expert support from day one.
No. Cloudflare can reduce certain risks, but it doesn't replace the ASV scan requirement, your internet-facing systems still need to be scanned.
You are, for anything you deploy, the cloud provider secures the underlying infrastructure, but your VMs, containers, and API gateways are your responsibility to scan under the shared responsibility model.
Yes, when properly implemented and technically validated, segmentation that isn't validated doesn't count toward reducing scope.
You remediate the flagged vulnerabilities, typically anything rated high severity or above, and undergo a re-scan; only a clean, passing report satisfies that quarter's requirement.
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.