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.
PCI ASV scanning on Azure is required no matter how much of the stack Microsoft secures underneath you, and that single fact trips up more Azure-hosted merchants than any other part of PCI DSS. Azure holds strong compliance credentials: Microsoft is independently assessed against PCI DSS, and its Attestation of Compliance (AOC) is genuine, verifiable evidence that the platform itself meets the standard. What that AOC does not do is extend to your virtual machines, your App Service configuration, or your public-facing endpoints. Those remain yours to secure, scope, and scan.
This is where the shared responsibility model gets misread. Teams see “Azure is PCI compliant” and assume the quarterly external scanning obligation under PCI DSS Requirement 11.3.2 is handled somewhere upstream. It isn’t. Requirement 11.3.2 calls for a scan performed and attested by an independent Approved Scanning Vendor (ASV), not by the cloud provider, and not by an internal tool, against every system in your cardholder data environment (CDE) that’s reachable from the internet.
This article maps that boundary precisely: what Azure’s shared responsibility model actually covers, where it stops, which Azure-specific assets are easy to miss in scope, and what typically causes Azure-hosted environments to fail their scans.
PCI ASV (Approved Scanning Vendor): An organisation certified by the PCI Security Standards Council (PCI SSC) to perform external vulnerability scans in accordance with the ASV Program Guide, as required under PCI DSS Requirement 11.3.2.
Shared Responsibility Model: The cloud governance framework that splits security obligations between Microsoft and the customer, covering identity management, data classification, application security, and network configuration, with the exact split shifting depending on whether you're running IaaS, PaaS, or SaaS.
Cardholder Data Environment (CDE): The people, processes, and technology that store, process, or transmit cardholder data, plus any connected system that could affect its security.
Network Security Group (NSG): An Azure resource acting as a virtual firewall that controls inbound and outbound traffic to Azure resources, a configuration element that directly shapes ASV scan scope and results.
ASV Scan: A quarterly external vulnerability scan, required under PCI DSS 11.3.2, run from outside your network against every internet-facing system in or connected to your CDE.
Scoping: The customer-owned exercise of identifying every in-scope, internet-facing asset before a scan runs; on Azure, this means public IPs, App Service custom domains, API Management endpoints, load balancer front-ends, and anything with a path to the CDE.
Hosting on Azure does not reduce or exempt you from any of PCI DSS's twelve requirements, including quarterly external scanning, regardless of which cloud platform hosts your cardholder data environment.
Microsoft maintains PCI DSS certification at the infrastructure level, and Azure itself is assessed by qualified security assessors. That confirms the underlying physical and virtualization infrastructure meets PCI DSS requirements on Microsoft’s side of the boundary. It says nothing about your virtual machines, application tiers, APIs, or public-facing endpoints; those are yours to secure and validate independently.
Requirement 11.3.2 is specific: after an initial passing scan, organisations must run quarterly scans through an ASV and achieve a passing result, covering every system component in the CDE reachable from the internet. In a typical Azure deployment, that includes public IPs attached to virtual machines, Application Gateway endpoints, Azure Kubernetes Service ingress controllers, and any other externally reachable component tied to the CDE. Azure’s own certifications don’t satisfy this requirement on your behalf, a point worth confirming directly against the PCI SSC’s ASV Program Guide and your QSA rather than taking it on faith.
Share your Azure footprint: VMs, App Service, API Management, and get scoped, quarterly-ready pricing within one business day.
The Azure shared responsibility model assigns physical infrastructure and hypervisor security to Microsoft; everything above that, OS patching, application security, data protection, and network configuration, including all obligations tied to PCI ASV scanning on Azure, remains the customer's.
At the IaaS level (Azure Virtual Machines), Microsoft’s responsibility stops at the physical host, the hypervisor, and the underlying network fabric. You own the guest OS, patching, application software, identity configuration, and the network controls, including the NSG rules, that determine what traffic reaches those systems from the internet. At the PaaS level (App Service, Azure SQL Database), Microsoft takes on the runtime and underlying OS, but you still own the data you store, the application logic you deploy, and the security configuration of every public endpoint.
The practical consequence: your ASV scan scope and results are determined entirely by the configuration decisions you’ve made in Azure, not by anything Microsoft manages. If your NSG rules allow broad inbound access, that shows up in your scan. If an App Service listener is still running an outdated TLS version, that’s a finding, and Microsoft will not remediate it, because it exists on your side of the shared responsibility model. Understanding this distinction before your first scan cycle saves significant time during remediation.
Microsoft Defender for Cloud and similar native tools assess your Azure resources from the inside looking out; an Azure PCI DSS vulnerability scan under Requirement 11.3.2 has to come from an independent ASV, scanning from the outside looking in, and one cannot substitute for the other.
Defender for Cloud offers genuinely useful vulnerability assessments for VMs, container images, and other Azure resources, and it integrates with third-party scanners for continuous monitoring against security benchmarks. But it operates from within your subscription; with visibility into configuration, Azure grants it. An ASV scan has none of that privileged access; it simulates exactly what an external attacker sees: open ports, exposed services, outdated software detectable through banner grabbing, weak TLS cypher suites, and other conditions visible from the public internet. That external vantage point is the entire point of the requirement, and it’s a function Azure’s internal tooling structurally cannot replicate.
It’s also worth confirming vendor approval directly: not every scanner listed in Azure Marketplace holds current PCI SSC ASV certification, and only a scan from a vendor on the SSC’s approved list satisfies Requirement 11.3.2. Verifying your vendor’s status on the PCI SSC website before engaging them is a basic but essential step.
Dynamic public IPs, App Service custom domains, API Management gateways, and Load Balancer front-ends are the assets most commonly left out when scoping an ASV scan on an Azure VM or PaaS environment, and each one is a customer scoping responsibility that Azure will not flag for you.
Patterns that show up repeatedly in Azure environments:
Azure’s resource tagging and Azure Resource Graph are useful for building this inventory, but automated discovery should be a starting point, not a final answer; dynamic environments need scope revalidated after every network change, not at a single point in time. It’s also worth checking Azure’s current policies on notifying Microsoft before large-scale scanning activity; a scanning partner experienced in Azure environments will already know how to navigate this.
Moving from Azure VMs to PaaS services reduces your patching burden, but PCI DSS 11.3.2 on Azure still requires a quarterly scan of every internet-facing endpoint tied to the CDE; the requirement doesn't shrink just because Microsoft manages more of the stack.
It’s tempting to treat a PaaS migration as a compliance shortcut: Microsoft manages the OS, so the CDE must be “more compliant” by default. That’s only partly true. Microsoft patching the underlying App Service infrastructure does reduce certain OS-level vulnerability classes that an ASV would otherwise flag. But the scan obligation itself is unaffected: App Service, Azure SQL, and API Management endpoints are internet-facing and still need to be identified, scoped, and scanned quarterly, exactly like a VM. The responsibility shift changes what a scan is likely to find, not whether the scan is required.
Book a 20-minute call to map your Azure CDE scope before your next quarterly scan deadline.
Overly permissive NSG rules, outdated TLS configurations, unpatched application dependencies, and incomplete scan scope are the most frequent causes of Azure-side scan failures, all customer-owned, not Microsoft-owned.
Every one of these sits in the customer half of the shared responsibility model. Azure gives you the tools to prevent all of them: NSGs, Azure Policy, Front Door WAF, and Defender for Cloud, but none of those tools run themselves, and none substitute for the independent attestation. Requirement 11.3.2 calls for.
PCI compliance on Azure is a continuous state, not a quarterly event. Configuration drift between scans is one of the leading causes of unexpected findings on the next cycle.
Between scans, that means keeping NSG rules aligned with least privilege, monitoring Defender for Cloud recommendations as they surface, and making sure patch management covers every in-scope VM and service, not just the ones scanned last quarter. A working relationship with an ASV partner who understands Azure environments, combined with disciplined configuration management, is what turns quarterly scanning from a recurring scramble into a predictable, repeatable process.
Azure’s compliance certifications describe what Microsoft secures beneath your workload, not what you’ve built on top of it. The shared responsibility model draws a line at the platform; PCI DSS Requirement 11.3.2 draws a separate line at your CDE’s internet-facing perimeter, and that second line has to be scanned quarterly by an independent ASV no matter how much of the stack Azure manages.
PCI ASV scanning on Azure is not optional, not delegable to Microsoft, and not replaceable by native security tooling. Organisations that navigate this well treat it as part of ongoing Azure governance, accurate scoping, disciplined configuration, and a scanning partner who knows cloud environments, rather than a quarterly checkbox.
See plans built for cloud-hosted merchants running quarterly PCI ASV scans on Azure.
It's an external vulnerability scan performed by a PCI SSC-approved vendor to find internet-facing weaknesses. PCI DSS Requirement 11.3.2 requires it quarterly for any entity handling cardholder data; Azure-hosted environments aren't exempt.
No. Azure's PCI DSS attestation covers its own infrastructure. Only an independent, PCI SSC-certified ASV can perform and attest to the scan Requirement 11.3.2 requires.
No. Defender for Cloud assesses your resources from inside your subscription. An ASV scan has to come from outside your network, with no privileged access; that's what Requirement 11.3.2 specifically requires.
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.