AWS PCI DSS Compliance: What AWS Covers and What You Still Own

Short answer: AWS is validated as a PCI DSS Level 1 service provider for its in-scope services, but that covers only the infrastructure AWS runs. You still own your application, accounts, IAM, encryption choices, logging and network design. AWS PCI DSS compliance means using AWS's attestation for its share and proving your own controls for everything you build on top.

Related guides:

• Everything you need to know about PCI DSS scope
• PCI DSS compliance checklist: all 12 requirements
• A deep dive into SAQ types

Key takeaways

• AWS's PCI DSS Level 1 validation applies to specific services and to the layers AWS operates. It is evidence for your assessment, not a substitute for it.
• Download the PCI DSS Attestation of Compliance (AOC) and Responsibility Summary from AWS Artifact and keep it with your third-party service provider records.
• Put cardholder data in dedicated AWS accounts and VPCs so the rest of your environment stays out of scope, then prove the segmentation works.
• Native services such as IAM, KMS, CloudTrail, Config, GuardDuty, Security Hub, WAF and Inspector support most requirement areas, but only count once configured, monitored and documented.
• The simplest path for most SaaS and HealthTech companies is to never touch card numbers at all: tokenize through a payment provider and aim for a lighter SAQ.

---

Is AWS PCI DSS compliant, and does that make you compliant?

AWS is PCI DSS compliant for the services it lists as in scope, but your workloads are only compliant once you validate your own controls. AWS undergoes an annual assessment by a Qualified Security Assessor (QSA) and publishes a list of services covered by that assessment on its services in scope page.

That validation covers the data centers, hardware, hypervisor and managed service internals AWS operates. It says nothing about:

• Whether your security groups allow inbound traffic from the internet to a database holding primary account numbers (PANs).
• Whether developers share an IAM user with long-lived access keys.
• Whether your application logs card numbers in plain text to CloudWatch.

"We run on AWS" is a useful starting point for the conversation with your QSA, not the end of it.

Who is responsible for what under the AWS shared responsibility model?

AWS secures the cloud itself, and you secure what you put in it and how you configure it. The split shifts by service: with EC2 you manage the guest operating system, while with Lambda or a managed database AWS takes on more of the stack.

Area	AWS responsibility	Your responsibility
Physical security	Data center access, guards, media destruction	None for AWS-hosted systems, but offices and devices that touch card data remain yours
Network	Underlying network infrastructure and isolation between customers	VPC design, security groups, network ACLs, ingress and egress rules, segmentation of the CDE
Operating system	Host OS and hypervisor; guest OS for fully managed services	Guest OS hardening and patching on EC2 and containers you manage, secure base images
Identity and access (IAM)	Availability and security of the IAM service itself	Users, roles, policies, MFA, least privilege, access reviews, root account protection
Encryption	Providing KMS, CloudHSM and TLS endpoints	Choosing to encrypt, key policies, key rotation, rendering stored PAN unreadable
Logging and monitoring	Providing CloudTrail, CloudWatch and related services	Enabling logs in every account and region, protecting them, retaining them and reviewing them
Application security	None	Secure development, code review, dependency management, payment page script controls
Vulnerability management	Patching AWS-managed infrastructure	Scanning your instances, containers and code; external scans by an Approved Scanning Vendor (ASV)
Policies and people	AWS's own staff and procedures	Your security policies, training, incident response and vendor management

AWS's Responsibility Summary breaks this down per PCI DSS requirement. Use it, not a generic table, as the source of truth for your assessor.

How do you get the AWS PCI AOC from AWS Artifact?

You download it from AWS Artifact, a self-service portal in the AWS Management Console. PCI DSS Requirement 12 expects you to know which requirements each third-party service provider covers, and these documents are how you show that for AWS.

1. Sign in to the AWS console with a role that can use AWS Artifact, granted to your compliance owner rather than the root account.
2. Open AWS Artifact and go to Reports.
3. Search for PCI and select the PCI DSS Attestation of Compliance and Responsibility Summary package.
4. Accept the terms of the AWS Artifact agreement for that report, then download it.
5. Store it in your compliance evidence folder alongside your service provider inventory, and note the assessment date.
6. Repeat annually. AWS is reassessed every year, so refresh the document and confirm that the services you use are still in scope.

Share the AOC with your QSA or reference it in your SAQ, but do not post it publicly. Whether you can pass an AWS report to anyone else depends on the terms printed on its first page, so check them before sharing it outside your company.

How do you reduce CDE scope on AWS?

Isolate cardholder data in dedicated AWS accounts and VPCs so that only a small set of systems is in scope. Under PCI DSS, every system that stores, processes or transmits cardholder data is in your cardholder data environment (CDE), along with anything that can connect to it or affect its security. A flat AWS account where everything can talk to everything puts your entire company in scope.

A practical segmentation pattern for SaaS teams:

• Separate AWS accounts. Use AWS Organizations to create a dedicated account (or a small set of accounts) for the CDE. Account boundaries are the strongest isolation AWS offers and make scope easy to explain.
• Service control policies (SCPs). Restrict which regions and services can be used in CDE accounts, and prevent anyone from disabling CloudTrail or other guardrails.
• Dedicated VPCs. Keep CDE workloads in their own VPC with private subnets. Avoid broad VPC peering or transit routes into non-CDE networks.
• Tight security groups. Allow only the specific ports and sources a component needs. Deny by default.
• Controlled admin access. Route administrative access through a hardened path such as AWS Systems Manager Session Manager instead of open SSH or RDP.
• Shared services, carefully. Identity providers, CI/CD pipelines and logging accounts that connect to the CDE are usually in scope as connected systems.

Segmentation only reduces scope if it works. If you rely on it, PCI DSS v4.0.1 Requirement 11.4.5 expects penetration testing of segmentation controls at least once every 12 months and after any change to them. Service providers have an extra requirement, 11.4.6, that raises the frequency to at least once every six months.

Which AWS services map to PCI DSS v4.0 requirements?

Most PCI DSS requirement areas have at least one AWS-native service that supports them, but the service is a tool, not the control. Your control is the configuration, the monitoring and the evidence that it runs. The mapping below is general; confirm specifics with your QSA.

PCI DSS requirement area	Supporting AWS services	What you still need to show
1: Network security controls	VPC, security groups, network ACLs, AWS Network Firewall, AWS WAF	Documented rules, business justification, periodic rule reviews
2: Secure configurations	AWS Config, Systems Manager, hardened AMIs	Configuration standards and drift detection
3: Protect stored account data	AWS KMS, CloudHSM, encryption for S3, EBS and RDS	Data retention limits, PAN rendered unreadable, key management procedures
4: Protect data in transit	AWS Certificate Manager, TLS on load balancers and API Gateway	Strong protocols only, certificate inventory
5: Malware protection	Endpoint anti-malware tooling you run on instances and user devices (GuardDuty Malware Protection scans EBS volumes and S3 objects, but is not a substitute)	Coverage of in-scope systems and devices, updates and alert handling
6: Secure systems and software	Amazon Inspector, AWS WAF, code scanning in CI/CD	Secure development process, patching timelines, payment page script management
7 and 8: Access control and authentication	IAM, IAM Identity Center, MFA, AWS Organizations	Least privilege, MFA for CDE access, access reviews, no shared accounts
10: Logging and monitoring	CloudTrail, CloudWatch, VPC Flow Logs, S3 Object Lock	Logs in every account and region, tamper protection, retention, daily review
11: Security testing	Amazon Inspector, GuardDuty	ASV external scans, internal scans, penetration tests, change detection
12: Policies and program	Security Hub (PCI DSS standard), AWS Artifact	Policies, risk analysis, incident response plan, vendor management

Two notes for smaller teams. Security Hub offers a PCI DSS standard that runs automated configuration checks. It is a useful early warning system, but passing every check does not mean you meet PCI DSS, because many requirements are about process and people. And Amazon Inspector is not an ASV. PCI DSS requires external vulnerability scans by an Approved Scanning Vendor, so budget for one separately. For broader hardening ideas, see our list of AWS cloud security strategies.

Can tokenization get you to a simpler SAQ?

Often, yes. If card data goes straight from the customer's browser to a PCI DSS compliant payment provider and your systems only ever see a token, your CDE can shrink dramatically. Which SAQ you file then depends on how the payment page is built, and the rules changed under PCI DSS v4.x:

• Embedded or redirected payment pages. Merchants who fully outsource payment to a provider's page or embed the provider's payment form, for example in an iframe, may qualify for SAQ A. The January 2025 revision of SAQ A, effective March 31, 2025, added an eligibility criterion: the merchant must confirm its site is not susceptible to attacks from scripts that could affect its e-commerce systems. PCI SSC FAQ 1588 clarifies that this applies to merchants that embed a provider's form, not to those using a redirect, and that you can meet it either with your own script protections or with written confirmation from your provider.
• Your own page collects card data. If your website controls the page elements that capture card data, even when the data posts directly to the provider, SAQ A usually does not fit and SAQ A-EP may apply instead, which brings your web servers into scope. Confirm the right SAQ with your acquirer or payment provider.
• You receive or store PANs on AWS. If card numbers touch your EC2 instances, Lambda functions, databases or logs, expect SAQ D or a full Report on Compliance, and the full AWS control set above applies.

Tokens issued by a payment provider are generally not cardholder data on their own, so storing them in your AWS database does not by itself bring that database into scope. Always check the current SAQ documents in the PCI SSC document library before you decide. For a full walkthrough of every SAQ type and its eligibility criteria, see what a PCI SAQ is and our guide to PCI DSS self-assessment questionnaires.

For most SaaS and HealthTech companies that bill by card, the right answer is to keep PAN out of AWS entirely.

What changed after March 31, 2025?

PCI DSS v4.0 introduced 51 future-dated requirements that were best practice until March 31, 2025 and now apply in every assessment. PCI DSS v4.0.1, a limited revision published in June 2024, kept that timeline. The future-dated items that tend to matter most for AWS-hosted environments include:

• MFA for all access into the CDE, not just remote or administrative access.
• Targeted risk analyses to justify the frequency of certain periodic activities.
• Automated review of audit logs rather than relying on manual review.
• Management of payment page scripts and detection of unauthorized changes to payment pages, for merchants whose sites host or embed payment forms.
• Stronger authentication rules, including longer minimum passwords and tighter controls over application and system accounts.
• Incident response procedures for when stored PAN is found somewhere it is not expected, such as logs or backups.

How SecureSlate helps

SecureSlate helps SMB, SaaS and HealthTech teams run PCI DSS alongside SOC 2, ISO 27001 and HIPAA from one place. It connects to your AWS accounts through a read-only IAM role and scans configurations against security best practices and compliance frameworks, flagging risky settings so you can fix them before your assessor finds them. Policy templates cover Requirement 12 documentation, vendor risk management tracks AWS and your payment provider, multi-framework mapping reuses your SOC 2 controls, and a trust center shares your security posture with customers. See how our AWS integration collects evidence from your accounts.

Start your free SecureSlate trial

FAQ

Is AWS validated as a PCI DSS Level 1 service provider?

Yes. AWS states that it is validated as a PCI DSS Level 1 service provider, the highest level, based on an annual assessment by a QSA. The validation applies only to the services AWS lists as in scope, and it covers AWS's responsibilities, not your configuration or application.

Where do I find the AWS PCI attestation of compliance?

In AWS Artifact, inside the AWS Management Console. Search the reports for PCI, accept the agreement and download the PCI DSS Attestation of Compliance and Responsibility Summary. Refresh it each year after AWS's annual assessment.

Do I need a separate AWS account for my cardholder data environment?

It is not strictly required, but it is the cleanest way to reduce scope. A dedicated account with its own VPC, SCP guardrails and limited connectivity makes segmentation easier to enforce, test and explain to your assessor.

Does storing payment tokens on AWS put my database in PCI scope?

Generally no, if the tokens come from a PCI-validated payment provider and cannot be used to recover the card number. Confirm with your provider and your QSA, since how you integrate the payment form still decides your SAQ type.

Disclaimer (legal note)

This article is for general information only and is not legal, regulatory or professional advice. Requirements vary by framework, industry and jurisdiction. Consult qualified advisors for your specific obligations.