PCI DSS on Azure — The QSA's Guide to Cloud Compliance

Does Hosting on Azure Make You PCI Compliant?

No — and this is the single most common misconception our QSAs correct in cloud engagements. Microsoft Azure is certified as a PCI DSS Level 1 Service Provider, and Microsoft publishes its Attestation of Compliance (AOC) through the Service Trust Portal. That certification covers the physical data centres, the hypervisor layer, and the platform services Microsoft operates. It does not cover anything you build, configure, or deploy on top of them.

PCI DSS in the cloud follows a shared responsibility model. Microsoft is responsible for the security of the cloud; you are responsible for security in the cloud. Where the line sits depends on the service model:

Microsoft formalises this split in the Azure PCI DSS Shared Responsibility Matrix — a requirement-by-requirement mapping of who owns what, available from the Microsoft Azure PCI DSS compliance offering and the Service Trust Portal. Your QSA will use it to decide which controls can be inherited from Azure's AOC and which must be evidenced from your environment. If your assessor has never asked for it, that is a red flag.

Scoping Your Cardholder Data Environment in Azure

Scoping determines cost and effort more than any other decision, and cloud environments change the mechanics. In Azure, your cardholder data environment (CDE) is defined by subscriptions, virtual networks, and identity boundaries rather than physical network segments. Three practices consistently produce clean, defensible scope:

Dedicated subscriptions for the CDE. Placing cardholder data systems in their own subscription (or management group) creates a natural assessment boundary, simplifies role assignments, and prevents scope creep from unrelated workloads sharing the same virtual network.

Segmentation with NSGs and Azure Firewall. Network Security Groups, Azure Firewall, and private endpoints replace the physical firewalls of on-premises segmentation. The same PCI DSS rule applies in the cloud: systems that can reach the CDE are in scope. Overly permissive peering and default-allow NSG rules are the cloud equivalent of a flat network — and segmentation must still be verified by penetration testing.

Identity as a scope boundary. In cloud environments, identity is the perimeter. Every Entra ID principal with access to CDE resources — users, groups, service principals, managed identities — is part of the assessment. Unused service principals with Contributor rights over CDE subscriptions are a finding we encounter in most first-year Azure assessments.

The PCI Security Standards Council's cloud computing guidance covers these principles in provider-neutral terms — see the PCI SSC document library for the Cloud Computing Guidelines information supplement.

Mapping PCI DSS v4.0.1 Requirements to Azure Services

The table below is the mapping our assessors use as a starting point in Azure engagements — which native Azure service typically satisfies each requirement family, and what evidence the QSA will ask for. It is not exhaustive, but it covers where the bulk of assessment effort goes.

Two requirement families remain almost entirely yours regardless of Azure services: Requirement 9 (physical security) is inherited from Microsoft's AOC for the data centres but still applies to your own offices and media, and Requirement 12 (policies, risk assessments, training, incident response) has no cloud service that can do it for you.

The Azure Gaps Our QSAs Find Most Often

Across Azure-hosted PCI DSS assessments EIC has delivered in Asia-Pacific, the same findings recur — and almost none of them are platform problems. They are configuration and process gaps:

1. MFA enforced for users but not for all access into the CDE. Conditional Access policies often cover interactive sign-ins but miss service accounts, break-glass accounts, or direct management-plane access. PCI DSS v4.0.1 requires MFA for all access into the CDE — not just for the accounts that are convenient to enrol.

2. Diagnostic settings incomplete or retention too short. Activity Logs exist by default, but resource-level diagnostic logs must be explicitly routed to a Log Analytics workspace or storage account. Requirement 10 expects twelve months of audit trail history with three months immediately available — a default 90-day retention setting fails this quietly.

3. Over-privileged roles at subscription scope. Owner and Contributor assignments granted at subscription level during a migration and never revisited. Requirement 7 expects least privilege based on job function, and access reviews that actually happen.

4. Segmentation assumed but never tested. VNet peering, hybrid connectivity, and shared services (DNS, monitoring, CI/CD agents) frequently connect the CDE to networks nobody considers in scope. Segmentation controls in the cloud must be penetration-tested just as they are on-premises.

5. Shadow cardholder data in storage accounts. Exports, diagnostics, backups, and test data in blob storage routinely contain live PANs. Cloud storage makes copying data effortless — and every copy expands your scope.

None of these are exotic. They are the cloud translations of the classic on-premises findings, and they are all avoidable with a pre-assessment gap analysis — see our breakdown of what PCI DSS compliance actually costs for why finding them early matters.

PCI DSS in AWS, GCP and Multi-Cloud Environments

The shared responsibility model is conceptually identical on AWS and Google Cloud — both are PCI DSS Level 1 certified service providers, both publish responsibility matrices, and both leave configuration, identity, logging, and application security to you. The service names change (Security Groups for NSGs, IAM for Entra ID, CloudTrail for Activity Logs, Security Hub for Defender for Cloud), but the assessment approach does not. For the AWS-specific version of this guide — including the IAM, CloudTrail, and Security Hub mapping — see PCI DSS on AWS — The QSA's Guide to Cloud Compliance.

Multi-cloud environments deserve one specific warning: each provider's controls only cover its own platform. A tokenisation service in AWS does not descope a database in Azure, and centralised logging must actually centralise — a SIEM that ingests from one cloud but not the other leaves a Requirement 10 gap. In our experience, multi-cloud CDEs are best assessed with a single consolidated scope document that maps every requirement to the specific control in each platform, rather than treating each cloud as a separate assessment. Evidence collection should follow the same principle — which is why Complium's read-only integrations cover both Azure and AWS (IAM, CloudTrail, Security Hub, and Config), so a multi-cloud CDE produces one evidence set, not two.

Automating Azure Evidence Collection

The most labour-intensive part of a cloud PCI DSS assessment is not implementing controls — it is proving them. Traditional evidence collection means screenshots: portal pages for role assignments, diagnostic settings, Defender recommendations, NSG rules, captured one by one, dated, and filed against requirements. For a Level 1 environment this consumes weeks, and the evidence is stale the moment it is captured.

This is the problem EIC built Complium to solve. Complium connects to Azure through read-only integrations — Microsoft Entra ID for access-control and authentication evidence, Azure Activity Logs for audit-logging evidence, and Microsoft Defender for Cloud for configuration posture across the network, secure-configuration, data-protection, and vulnerability control families. The same read-only model extends to AWS through IAM, CloudTrail, Security Hub, and Config. Evidence is pulled from the environment itself, mapped to PCI DSS v4.0.1 requirements by AI, and reviewed by the QSA inside the same platform that produces the Report on Compliance.

Because Complium is built and operated by a QSA organisation, the platform and the assessor who signs your validation come from the same accountable provider. Complium is available directly and through the Microsoft Marketplace, where Azure customers can deploy it alongside the environment it monitors.

Frequently Asked Questions

If you are planning a PCI DSS assessment for an Azure-hosted environment, our PCI DSS compliance assessment service covers scoping, gap analysis, and the full ROC or SAQ engagement — and our complete PCI DSS guide covers the standard itself in depth.