One Model, Four Vocabularies: Shared Responsibility
AWS, Microsoft Azure and Google Cloud are each validated as PCI DSS Level 1 Service Providers, and Alibaba Cloud publishes its own PCI DSS attestation through its Trust Center. In every case the validation covers the physical data centres, the hypervisor and the platform services the provider operates. It does not cover anything you build, configure or deploy on top of them. The provider is responsible for security of the cloud; you are responsible for security in the cloud.
This is the single misconception our QSAs correct most often in cloud engagements, and it is worth stating plainly: a provider's Attestation of Compliance is an input to your assessment, not a substitute for it. Where the line sits depends on the service model you consume, and the split is the same on every provider:
| Service model | Provider handles | You handle |
|---|---|---|
| IaaS (VMs, virtual networks) | Physical hosts, storage, hypervisor | OS hardening and patching, segmentation, access control, encryption, logging, applications |
| PaaS (managed databases, app platforms, Kubernetes control planes) | OS patching, runtime, platform controls | Encryption choices, identity and access, network exposure, application code, logging configuration, workloads |
| SaaS | Application, platform, infrastructure | User access management, data governance, configuration options |
Each provider formalises the split in a requirement-by-requirement responsibility matrix. AWS publishes its Responsibility Summary through AWS Artifact, Microsoft publishes the Shared Responsibility Matrix through the Service Trust Portal, Google Cloud publishes its matrix through Compliance Reports Manager, and Alibaba Cloud provides compliance reports through its Trust Center. Your QSA should ask for the relevant document at the start of the engagement and use it to decide which controls are inherited and which must be evidenced from your environment. For a requirement-by-requirement walkthrough of how to read one, see the shared responsibility matrix, explained.
Two requirement families never move to the provider.Requirement 9 (physical security) is inherited for the data centres but still applies to your offices, devices and media. Requirement 12 (policies, risk assessment, training, incident response) has no cloud service that can do it for you.
AWS, Azure, Google Cloud and Alibaba Cloud Side by Side
The assessment approach does not change between providers. What changes is the name of the service that satisfies each requirement family and the place you obtain the provider's attestation. The table below is the starting map our assessors use; each provider guide expands it into a full requirement-to-service mapping with the evidence a QSA will ask for.
| Control area | AWS | Azure | GCP | Alibaba Cloud |
|---|---|---|---|---|
| Provider validation | PCI DSS Level 1 Service Provider | PCI DSS Level 1 Service Provider | PCI DSS Level 1 Service Provider | PCI DSS validated (check current AOC for in-scope products and regions) |
| Where to get the AOC and responsibility matrix | AWS Artifact (AOC + Responsibility Summary) | Service Trust Portal (AOC + Shared Responsibility Matrix) | Compliance Reports Manager (AOC + Responsibility Matrix) | Alibaba Cloud Trust Center (compliance reports on request) |
| Identity and access (Req 7, 8) | IAM, IAM Identity Center | Microsoft Entra ID, Conditional Access | Cloud IAM, Cloud Identity, Context-Aware Access | RAM users and roles, STS |
| Network security and segmentation (Req 1) | Security Groups, NACLs, Network Firewall, VPC | NSGs, Azure Firewall, Private Endpoints | VPC firewall policies, Cloud Armor, VPC Service Controls | Security Groups, Cloud Firewall, CEN |
| Audit logging (Req 10) | CloudTrail, CloudWatch, VPC Flow Logs | Activity Logs, Azure Monitor, Log Analytics | Cloud Audit Logs, Cloud Logging | ActionTrail, Simple Log Service (SLS) |
| Key management and encryption (Req 3, 4) | KMS, ACM, CloudHSM | Key Vault, Managed HSM | Cloud KMS, Cloud HSM, Secret Manager | KMS, Encryption Service (HSM) |
| Secure configuration and vulnerability visibility (Req 2, 6, 11) | Security Hub, Config, GuardDuty, Inspector | Defender for Cloud, Azure Policy | Security Command Center, Organization Policy | Security Center, Cloud Config |
| Full guide | PCI DSS on AWS → | PCI DSS on Azure → | PCI DSS on GCP → | PCI DSS on Alibaba Cloud → |
One practical difference is worth calling out. AWS, Azure and Google Cloud maintain broadly global validation scope across their commercial regions. Alibaba Cloud's attestation should be read carefully for the specific products and regions in scope, and customers processing card data in its China regions should also consider data-residency and cross-border transfer obligations alongside PCI DSS itself. The Alibaba Cloud guide covers this in detail.
Scoping a Cloud Cardholder Data Environment
Scoping determines the cost and effort of an assessment more than any other decision, and cloud environments change the mechanics. A cardholder data environment (CDE) in the cloud is defined by account boundaries, virtual networks and identity, not by physical network segments. Five decisions produce clean, defensible scope on every provider:
A dedicated account boundary for the CDE
An AWS account, an Azure subscription, a Google Cloud project or an Alibaba Cloud Resource Directory member account reserved for cardholder data systems creates a natural assessment boundary and stops unrelated workloads sharing the same network.
Segmentation you can prove
Security groups, firewall policies, private endpoints and peering rules replace physical firewalls. The PCI DSS rule is unchanged: any system that can reach the CDE is in scope. Default-allow rules and untested peering are the cloud equivalent of a flat network.
Identity as the perimeter
Every principal with access to CDE resources is part of the assessment: users, groups, roles, service principals, service accounts and managed identities. Unused automation identities with administrative rights are a first-year finding on every platform.
Know where the data can go
Object storage, snapshots, backups, log exports, analytics datasets and test environments are where cardholder data spreads. Every copy expands scope. Tokenisation and provider-managed payment services reduce it.
Shared services are in scope too
DNS, monitoring, CI/CD runners, jump hosts, directory services and SIEM collectors that connect to the CDE are connected-to systems and must be assessed, whichever account they live in. Kubernetes clusters follow the same rule: see PCI DSS on Kubernetes for cluster-level scoping.
The PCI Security Standards Council's Cloud Computing Guidelines information supplement covers these principles in provider-neutral terms; it is available from the PCI SSC document library. Our complete PCI DSS guide covers scoping methodology for on-premises and hybrid environments.
The Gaps Every Cloud Assessment Finds
Across the cloud-hosted assessments our QSAs deliver, the same six findings recur, and almost none of them are platform problems. They are configuration and process gaps, and they translate directly between providers:
| Finding | Requirement | What it looks like on each cloud |
|---|---|---|
| MFA enforced for interactive users but not for all access into the CDE | 8.4.2 | Service accounts, break-glass accounts, API keys and management-plane access without MFA or equivalent controls |
| Audit logs incomplete or retained for less than 12 months | 10.2, 10.5 | CloudTrail in one region only; Azure diagnostic settings not routed; GCP Data Access logs disabled; ActionTrail not delivered to storage |
| Administrative roles granted at the account or subscription scope and never reviewed | 7.2 | AdministratorAccess, Owner, Editor or AdministratorAccess-equivalent RAM policies attached during migration |
| Segmentation assumed but never tested | 11.4.5 | Peering, transit gateways, hub-and-spoke networks and CEN instances connecting the CDE to networks nobody scoped |
| Cardholder data in object storage and exports | 3.2, 3.3 | PANs in S3, Blob Storage, Cloud Storage or OSS buckets from backups, diagnostics, analytics pipelines and test data |
| Vulnerability findings visible in the console but not remediated in time | 6.3, 11.3 | Security Hub, Defender for Cloud, Security Command Center or Security Center findings ageing past the required windows |
None of these are exotic. They are the cloud translations of the classic on-premises findings, and all of them are avoidable with a pre-assessment gap analysis. Finding them early is also cheaper: see what PCI DSS compliance actually costs for why remediation timing matters.
SAQ or ROC When You Host in the Cloud
Cloud hosting does not change which validation route applies to you. That is determined by your merchant level, set by your acquirer and the card brands, and by how you accept and process card data. Three situations cover most cloud-hosted organisations:
Level 1 merchants and service providers
A Qualified Security Assessor must perform the assessment and produce a Report on Compliance (ROC) and Attestation of Compliance, regardless of where the environment runs. The provider's AOC is used to mark inherited controls; everything else is evidenced from your accounts.
Lower-level merchants operating their own payment application in the cloud
Because you operate systems that store, process or transmit cardholder data, you will normally complete SAQ D. Outsourcing the infrastructure does not qualify you for a shorter SAQ; outsourcing the payment function itself, for example through a validated hosted payment page or tokenisation service, can.
Multi-tenant service providers
If you host cardholder data on behalf of customers, PCI DSS v4.0.1 requires you to support your customers' external penetration testing (Requirement 11.4.7) and to provide them with the information they need for their own assessments, in the same way the hyperscale providers do for you.
Whichever route applies, the scope document, the network diagram and the data-flow diagram must reflect the cloud architecture as built: accounts, regions, virtual networks, managed services and the identities that connect them. Which SAQ fits which cloud-hosted payment architecture is covered in SAQ or ROC? PCI DSS validation when you host in the cloud. Our PCI DSS assessment service covers scoping, gap analysis and the full ROC or SAQ engagement for cloud, hybrid and on-premises environments.
Penetration and Segmentation Testing in the Cloud
Requirement 11.4 applies to cloud cardholder data environments in full. Internal and external penetration tests are required at least once every 12 months and after significant changes; segmentation controls must be tested at least every 12 months, and every six months for service providers. Two things change in the cloud.
What "internal" means. An internal test of a cloud CDE is an assumed-breach test: the tester starts with a low-privilege identity or a foothold inside the virtual network and attempts to reach cardholder data through identity privilege escalation, misconfigured services and trust relationships between accounts. Exploiting an unpatched CVE is rarely the path; abusing a permission usually is.
Whose rules apply. Each provider publishes conditions for customer penetration testing. AWS permits testing of most services without prior approval but prohibits denial-of-service and certain activities; Microsoft publishes Rules of Engagement for Azure; Google Cloud requires compliance with its acceptable use policy. Your tester must know these rules and scope the engagement to stay inside them. The full requirement, 11.4.1 to 11.4.7, is explained in PCI DSS Requirement 11.4, explained; Kubernetes-hosted CDEs are covered in PCI DSS on Kubernetes.
Cloud Penetration Testing
CREST Accredited testing of AWS, Azure, Google Cloud and Alibaba Cloud environments: identity attack paths, exposure, privilege escalation and Kubernetes.
PCI DSS Penetration Testing
Requirement 11.4 testing and segmentation validation, reported so that any QSA can accept it, with a 30-day retest window.
Evidence: From Screenshots to Read-Only Integrations
The most labour-intensive part of a cloud assessment is not implementing controls; it is proving them. Traditional evidence collection means screenshots of console pages for role assignments, logging configuration, firewall rules and posture findings, 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.
Complium, EIC's compliance management platform, replaces that process with read-only integrations. On Azure it connects to Microsoft Entra ID, Azure Activity Logs and Microsoft Defender for Cloud; on AWS to IAM, CloudTrail, Security Hub and Config. Evidence is pulled directly from the environment, mapped to PCI DSS v4.0.1 requirements, and reviewed by the QSA inside the same platform that produces the Report on Compliance. The integrations request zero write permissions and can be revoked at any time.
For Google Cloud and Alibaba Cloud environments, Complium works today from exported Cloud Audit Logs, IAM policy exports and Security Command Center findings, or ActionTrail, RAM policy and Security Center exports, uploaded as evidence and mapped by the same engine. Native read-only connectors for those platforms are on the roadmap; we describe integrations as they exist, not as planned.
Comparing PCI DSS compliance automation tools for Azure or AWS?
See how Complium's QSA-built evidence collection and one-click ROC generation compare with generalist GRC platforms.
PCI DSS compliance automation for Azure and AWS →Frequently Asked Questions
Does using a PCI DSS compliant cloud provider make my organisation PCI compliant?
No. AWS, Azure, Google Cloud and Alibaba Cloud are each validated for the infrastructure and platform services they operate. That validation covers their side of the shared responsibility model only. Your configuration of those services, your identity and access design, your logging, your application code, and all of your policies and processes must still be assessed and validated separately, either through a Report on Compliance (ROC) or a Self-Assessment Questionnaire (SAQ).
Which cloud provider is easiest for PCI DSS compliance?
In our assessment experience the differences between AWS, Azure and Google Cloud are small; each offers native services that satisfy every requirement family a customer is responsible for, and each publishes a responsibility matrix. What determines effort is how the environment is designed: dedicated accounts or subscriptions for the cardholder data environment, tested segmentation, least-privilege identity, and complete log retention. Alibaba Cloud offers equivalent services, but customers should confirm which products and regions are covered by its current Attestation of Compliance before relying on inherited controls.
Can I complete an SAQ if my cardholder data environment is hosted in the cloud?
Cloud hosting does not change SAQ eligibility. Eligibility is determined by your merchant level, set by your acquirer and card brands, and by how you accept and process card data. A Level 1 merchant or a service provider needs a QSA-led ROC regardless of where the environment runs. Lower-level merchants hosting their own payment application in the cloud typically fall into SAQ D, because they operate systems that store, process or transmit cardholder data, even though the underlying infrastructure is outsourced.
How do I use the cloud provider's Attestation of Compliance in my assessment?
Obtain the provider's current AOC and its PCI DSS responsibility matrix, confirm that the specific services and regions you use are listed in scope, and give both documents to your QSA at the start of the engagement. The QSA marks each requirement the provider fully covers as inherited, and evidences the rest from your environment. An AOC that does not list a service you rely on means that service cannot be treated as inherited.
Do cloud-hosted environments need penetration testing and segmentation testing?
Yes. PCI DSS Requirement 11.4 applies to cloud cardholder data environments in full: internal and external penetration testing at least once every 12 months and after significant changes, and segmentation testing at least every 12 months (every six months for service providers). In the cloud, segmentation is implemented with security groups, firewall policies, VPC or VNet peering and private endpoints, and those controls must be tested, not assumed. Each provider publishes rules for customer penetration testing that your tester must follow.
What does a multi-cloud cardholder data environment change?
Each provider's controls and AOC cover only that provider's platform. A multi-cloud CDE needs one consolidated scope document that maps every PCI DSS requirement to the specific control in each cloud, centralised logging that genuinely ingests from every platform, and segmentation testing across the connections between clouds. Treating each cloud as a separate assessment usually leaves gaps at the seams.