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

Does Hosting on Alibaba Cloud Make You PCI Compliant?

No — and on Alibaba Cloud the question has a second layer that AWS and Azure customers rarely face: which Alibaba Cloud you are on. Alibaba Cloud holds a PCI DSS Attestation of Compliance as a service provider. The current document we have reviewed is a PCI DSS v4.0 service-provider AOC issued to Alibaba Cloud (Singapore) Private Limited and assessed by an independent QSA company, with an assessment end date in August 2024. It covers Alibaba Cloud's Public Cloud International Services — the platform you reach through alibabacloud.com — and lists a long set of in-scope products from ECS, VPC and OSS through RAM, ActionTrail, KMS, Cloud Firewall, Security Center and Bastionhost.

Two lines in that AOC matter more than the product list. First, it states that other Alibaba Cloud environments, including Public Cloud China Services and Fincloud, are not covered by the assessment. Second, it states that the cardholder data environments of Alibaba Cloud's customers and their system components are not covered. In other words: the attestation covers the security of the cloud; you are responsible for security in the cloud, and only on the platform the attestation actually names.

The split follows the same service-model logic as every other provider:

Alibaba Cloud formalises the split in its PCI DSS Responsibility Management Matrix, which it publishes alongside the AOC through its Trust Center PCI DSS page and compliance resources. Your QSA will use the matrix to decide which controls can be inherited from Alibaba Cloud's AOC and which must be evidenced from your environment. Obtain the current AOC, the in-scope service list and the matrix from the Trust Center at the start of the engagement — the public pages and the AOC have not always described the same version and region list, so the document you hold is the one that counts.

Scoping Your Cardholder Data Environment on Alibaba Cloud

Scoping determines cost and effort more than any other decision. On Alibaba Cloud, the cardholder data environment (CDE) is defined by accounts, VPCs and RAM identity boundaries rather than physical network segments. Four practices consistently produce clean, defensible scope:

Decide the platform and regions first. Alibaba Cloud's International site and China site are separate platforms with separate accounts that cannot be linked. If any part of your CDE sits on the China site, or in a region that is not in the scope list of the AOC you hold, your assessor cannot inherit Alibaba Cloud's attestation for those components. Cross-border card-data flows between regions also need to be mapped for your acquirer's and local regulators' data-residency expectations. Settle this before designing anything else.

Dedicated accounts for the CDE, governed through Resource Directory. Placing cardholder data systems in their own Alibaba Cloud account (or resource group at minimum) inside a Resource Directory creates a natural assessment boundary. Control policies attached to the Resource Directory act as guardrails on the maximum permissions any RAM identity in the CDE account can hold, which is exactly the kind of preventive control a QSA can point to for Requirement 7.

Segmentation with security groups, Cloud Firewall and CEN. VPCs, security groups, Cloud Firewall (including its VPC-border firewall) and Cloud Enterprise Network replace the physical firewalls of on-premises segmentation. The rule is unchanged in the cloud: systems that can reach the CDE are in scope. Default-allow security groups, CEN transit routers that connect every VPC to every other VPC, and Express Connect links back to on-premises networks are the cloud equivalents 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 RAM user, RAM role, STS session source and Alibaba Cloud account with access to CDE resources is part of the assessment. Long-lived AccessKeys on RAM users with AdministratorAccess, created for a migration and never rotated, are the finding to expect in a first-year assessment.

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. Alibaba Cloud's own PCI DSS Practices Manual is written mainly for e-commerce merchants and is a useful reference for the provider's intended deployment patterns.

Mapping PCI DSS v4.0.1 Requirements to Alibaba Cloud Services

The table below is the mapping our assessors use as a starting point when an environment is hosted on Alibaba Cloud — which native 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 Alibaba Cloud services: Requirement 9 (physical security) is inherited from Alibaba Cloud'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.

One practical note on Cloud Config: its PCI DSS compliance package is built on the PCI DSS v4.0 baseline and checks items such as RAM MFA, AccessKey rotation, OSS anonymous access, ActionTrail coverage, security-group high-risk ports, RDS public access and SQL audit retention. It is a useful continuous-monitoring control and a good evidence source, but a passing compliance package is not a PCI DSS assessment — it does not know your scope, your compensating controls or your processes.

The Alibaba Cloud Gaps a QSA Will Look For First

The gaps our QSAs see most often in cloud assessments translate directly to Alibaba Cloud's service model — and almost none of them are platform problems. They are configuration and process gaps:

1. RAM users with AdministratorAccess and no MFA, or long-lived AccessKeys. RAM supports enforcing MFA for console sign-in and STS temporary credentials for programmatic access, but neither is applied by default to every identity that can reach the CDE. PCI DSS v4.0.1 requires MFA for all access into the CDE — service identities, break-glass accounts and the Alibaba Cloud root account included. AccessKeys that have not been rotated in years are the programmatic equivalent of a shared password.

2. ActionTrail left at its 90-day default. ActionTrail records management events for every account by default, but only for 90 days. Requirement 10 expects twelve months of audit-trail history with three months immediately available. That requires a trail delivering events to Simple Log Service or OSS with retention set deliberately — and the trail must cover every region and every account in scope, not just the one where it was first switched on.

3. OSS buckets with public-read access, or exports holding live PANs. Backups, database exports, diagnostics and test data in Object Storage routinely contain cardholder data. Cloud storage makes copying effortless — every copy expands your scope, and a public-read bucket ACL turns a scoping problem into a breach.

4. Security groups open to 0.0.0.0/0 on management ports. SSH and RDP exposed to the internet on ECS instances "temporarily" during a migration, and never closed. Bastionhost and Cloud Firewall exist precisely so that administrative access into the CDE is brokered, logged and restricted to known sources.

5. Segmentation assumed but never tested. CEN transit routers, VPC peering and shared services (DNS, monitoring, CI/CD runners, Bastionhost itself) frequently connect the CDE to networks nobody considered in scope. Segmentation controls on Alibaba Cloud must be penetration-tested just as they are on-premises, and a Security Center baseline check that is enabled but whose findings are never remediated is not a control — it is a record of what the assessor is about to find.

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, and our CREST Accredited penetration testing service for the segmentation and cloud testing Requirement 11 expects.

PCI DSS on AWS, Azure, GCP and in Multi-Cloud Environments

The shared responsibility model is conceptually identical on AWS, Azure and Google Cloud — each is a validated PCI DSS service provider, each publishes a responsibility matrix, and each leaves configuration, identity, logging and application security to you. The service names change (security groups and Cloud Firewall become Security Groups and Network Firewall on AWS, NSGs and Azure Firewall on Azure, VPC firewall rules on GCP; RAM becomes IAM or Entra ID; ActionTrail becomes CloudTrail, Activity Logs or Cloud Audit Logs), but the assessment approach does not. For the provider-specific guides, see PCI DSS on AWS, PCI DSS on Azure and PCI DSS on Google Cloud, or the side-by-side comparison in our PCI DSS in the Cloud guide.

Multi-cloud environments deserve one specific warning: each provider's controls only cover its own platform. A tokenisation service on AWS does not descope a database on Alibaba Cloud, and centralised logging must actually centralise — a SIEM that ingests CloudTrail but not ActionTrail leaves a Requirement 10 gap. Alibaba Cloud is frequently the second or third platform in a multi-cloud estate, added for a specific market, which makes it the one most likely to be missed in scope documents. 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.

Automating Alibaba Cloud 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: console pages for RAM policies, ActionTrail trail settings, security-group rules and Security Center 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.

This is the problem EIC built Complium to solve. Complium's native read-only integrations today cover Microsoft Azure (Entra ID, Activity Logs, Defender for Cloud) and AWS (IAM, CloudTrail, Security Hub, Config). Complium does not currently have a native Alibaba Cloud connector. For Alibaba Cloud environments, the workflow uses the platform's own machine-readable outputs instead of screenshots: ActionTrail events delivered to Simple Log Service or OSS and exported, RAM user, role and policy exports, Cloud Config PCI DSS compliance-package results, and Security Center baseline and vulnerability reports. These are uploaded as evidence, mapped to PCI DSS v4.0.1 requirements by the same engine that handles Azure and AWS evidence, and reviewed by the QSA inside the platform that produces the Report on Compliance. Native connectors for further cloud platforms are on the roadmap; we will say so here when one ships, not before.

Because Complium is built and operated by a PCI 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.

Frequently Asked Questions

If you are planning a PCI DSS assessment for an Alibaba Cloud-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.