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

Does Hosting on AWS Make You PCI Compliant?

No — and this is the misconception our QSAs correct in almost every first AWS engagement. Amazon Web Services is certified as a PCI DSS Level 1 Service Provider, and AWS makes its Attestation of Compliance available to customers through AWS Artifact. That certification covers the physical data centres, the hypervisor layer, and the managed services Amazon operates. It does not cover anything you build, configure, or deploy on top of them.

PCI DSS on AWS follows the shared responsibility model AWS describes as security of the cloud (Amazon) versus security in the cloud (you). Where the line sits depends on the service type:

AWS formalises this split in the PCI Responsibility Summary, downloadable from AWS Artifact alongside the AOC — see the AWS PCI DSS Level 1 FAQs. Your QSA will use it to decide which controls can be inherited from AWS's certification 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 AWS

Scoping determines cost and effort more than any other decision, and AWS environments have their own mechanics. Your cardholder data environment (CDE) is defined by accounts, VPCs, and identity boundaries rather than physical network segments. Three practices consistently produce clean, defensible scope:

Dedicated accounts for the CDE. AWS Organizations makes account-level isolation the natural PCI boundary — a dedicated CDE account (or organizational unit) creates a hard blast-radius limit, simplifies IAM policy review, and prevents scope creep from unrelated workloads sharing a VPC. This is the AWS-recommended pattern and the one our assessors see work best.

Segmentation with Security Groups, NACLs, and Network Firewall. The same PCI DSS rule applies in the cloud: systems that can reach the CDE are in scope. Default-allow security group rules, wide-open VPC peering, and Transit Gateway routes nobody documented are the cloud equivalent of a flat network — and segmentation must still be verified by penetration testing. (AWS's penetration testing policy permits testing of your own workloads on most services without prior approval.)

Identity as a scope boundary. In AWS, identity is the perimeter. Every IAM principal that can touch CDE resources — users, roles, instance profiles, cross-account trust relationships — is part of the assessment. Stale cross-account roles with broad permissions into the CDE account are a finding in most first-year AWS 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 AWS Services

The table below is the mapping our assessors use as a starting point in AWS engagements — which native AWS service typically satisfies each requirement family, and what evidence the QSA will ask for.

Two requirement families remain almost entirely yours regardless of AWS services: Requirement 9 (physical security) is inherited from Amazon'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 AWS Gaps Our QSAs Find Most Often

Across AWS-hosted PCI DSS assessments EIC has delivered in Asia-Pacific, the same findings recur — and almost none of them are platform problems:

1. Cardholder data in unprotected S3 buckets. Exports, application logs, backups, and analytics staging data containing live PANs, in buckets whose access policies nobody has reviewed since creation. S3 is the single most common location for shadow cardholder data we find in AWS environments — and every copy expands your scope.

2. Root account usage and missing MFA. The account root user used for routine administration, sometimes without MFA, and IAM users with console access outside any MFA enforcement policy. PCI DSS v4.0.1 requires MFA for all access into the CDE — including programmatic and emergency-access paths.

3. Incomplete CloudTrail coverage and short retention. Trails enabled in one region but not organisation-wide, data events not captured for in-scope S3 buckets, or logs expiring at 90 days. Requirement 10 expects twelve months of audit trail history with three months immediately available.

4. Over-broad IAM policies. Wildcard actions and resources ("Action": "*") granted during development and never tightened, plus stale cross-account trust relationships into the CDE account. Requirement 7 expects least privilege based on job function, with access reviews that actually happen.

5. Segmentation assumed but never tested. VPC peering, Transit Gateway attachments, and shared services (CI/CD runners, monitoring, directory services) frequently connect the CDE to networks nobody considers in scope. Segmentation controls must be penetration-tested in AWS just as they are on-premises.

None of these are exotic — they are the cloud translations of classic on-premises findings, and 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 Azure, GCP and Multi-Cloud Environments

The shared responsibility model is conceptually identical on Microsoft Azure 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 (Entra ID for IAM, Activity Logs for CloudTrail, Defender for Cloud for Security Hub), but the assessment approach does not. For the Azure-specific version of this guide — including the Entra ID, Defender for Cloud, and Azure Monitor mapping — see PCI DSS on Azure — 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. Multi-cloud CDEs are best assessed with a single consolidated scope document that maps every requirement to the specific control in each platform, with one evidence set spanning both clouds.

Automating AWS 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 IAM policies, CloudTrail settings, Security Hub findings, security group 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 AWS through read-only integrations — AWS IAM for access-control and authentication evidence, AWS CloudTrail for audit-logging evidence, AWS Security Hub for aggregated security findings, and AWS Config for resource-configuration evidence. The same read-only model covers Azure via Entra ID, Activity Logs, and Defender for Cloud, so a multi-cloud CDE produces one evidence set. 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 from EIC and through the Microsoft Marketplace.

Frequently Asked Questions

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