What PCI DSS on AWS requires from you and what AWS already covers
A customer, acquirer or contract now requires PCI DSS, and you plan to host cardholder data on AWS. AWS is assessed as a PCI DSS Level 1 service provider by Coalfire, an independent QSA, and you obtain its Attestation of Compliance and Responsibility Summary through AWS Artifact in the AWS Management Console. Using PCI DSS compliant AWS services does not make your organization compliant. AWS states that you must manage your own PCI DSS compliance and testing, so the AWS documents describe what AWS covers, not what you have achieved.
Your organization owns its controls and its compliance decision. An implementation partner can prepare accounts, network designs, logging, access configuration and evidence, but it does not assess your environment or sign anything. Only your QSA issues the Report on Compliance and the Attestation of Compliance for your entity. Your QSA can rely on the AWS AOC for the part of the cardholder data environment deployed on AWS without further testing, which makes the Responsibility Summary the working document for deciding who handles each requirement.
Before the QSA review starts, confirm three things with AWS and your own team. First, check the Services in Scope by Compliance Program list to confirm that every service in your data flow is covered, because a provider's compliance does not prove that each service it offers was assessed. Second, map each requirement in the Responsibility Summary to an owner in your environment, including configuration of security groups, IAM policies, encryption keys, CloudTrail logging and the operating systems and applications you run on EC2 or containers. Third, record the AWS services your environment uses in your own network and data-flow diagrams so the QSA can see where your scope begins and ends.
Which AWS documents to get and what each one proves
The AWS PCI DSS Attestation of Compliance (AOC) is the document that states AWS has been assessed as a PCI DSS Level 1 service provider by Coalfire, an independent Qualified Security Assessor. You obtain it through AWS Artifact in the AWS Management Console. Executives and procurement teams use it as the headline proof that the AWS environment was validated, and a QSA uses it as the starting point for the part of your cardholder data environment (CDE) that runs on AWS.
- What it shows: that AWS's service provider assessment was completed and attested by an independent assessor for the stated period.
- Who uses it: executives and procurement for vendor due diligence, and the QSA when deciding what can be relied on.
- What it does not prove: that your accounts, VPCs, IAM policies or encryption settings are configured to meet PCI DSS.
- What it does not cover: services outside the assessed scope, which the Services in Scope list defines.
- Recurring use: the AOC is tied to an assessment period, so confirm you hold the current one at each validation.
Check that the AOC you download is the current version and that its assessment period overlaps your own assessment period without a gap.
The Responsibility Summary explains which PCI DSS requirements AWS meets as the service provider and which ones remain with the customer. It is the working document for the compliance lead, who uses it to build a responsibility matrix for the CDE and to assign each requirement to an owner. AWS states that customers must manage their own PCI DSS compliance and testing, so this summary is the map of where your responsibility starts.
- What it shows: the division of responsibilities between AWS and the customer across the requirements.
- Who uses it: the compliance lead and platform team, who turn it into a matrix with named owners.
- What it does not prove: that any requirement you own is already met. Using compliant AWS services does not by itself make you compliant.
- What to watch for: entries marked as shared, where AWS handles the platform and you handle configuration, logging or access.
- Practical use: keep it with your data-flow diagrams so the QSA can trace each responsibility to evidence.
Before relying on it, confirm that the version you hold matches the AOC period, and document which entries you have accepted and which you have assigned to your own controls.
The Services in Scope by Compliance Program list tells you which AWS services were included in the PCI DSS assessment. The QSA uses it to decide whether a service in your architecture is covered by AWS's validation or must be tested as part of your own assessment. This is the document that determines your scope, so it matters more than its length suggests to the architecture team.
- What it shows: the named AWS services included in the PCI DSS assessment.
- Who uses it: the architect and the QSA, who check each service in the CDE against the list.
- What it does not prove: that a listed service is correctly configured for your workload.
- What it does not prove about unlisted services: that they are safe to use in the CDE. A service missing from the list falls back to your own testing.
- Scope decisions: a provider's compliance does not show that every service it offers was assessed, so ask which ones are covered before you design around them.
Review the list at each architecture change and whenever AWS publishes a new assessment, because a service added to a workload after the review may fall outside the validated scope.
The three AWS documents establish what AWS has validated. They do not establish that your environment is compliant. Assessors test your configurations, access paths, logging, key management and the controls around your application, and none of those are covered by AWS's attestation. Treating the AOC as a finished control is one of the most common scoping errors, and it is the point where many teams need outside help to split the work correctly.
- Configuration: a service listed in the scope may still be deployed with public access, weak encryption settings or permissive security groups.
- Identity and access: AWS does not manage your users, roles or multi-factor authentication decisions.
- Logging and monitoring: your retention, review and alerting of logs remain your responsibility.
- Application and data: the software you deploy, its vulnerability management and its handling of cardholder data are yours to prove.
- Evidence: the QSA needs your own records, such as configuration exports and access reviews, to test your side.
Ask your QSA early which of your controls they will sample, and prepare evidence for each one before the on-site work begins.
What your QSA can rely on without retesting AWS
Your QSA can rely on AWS's Attestation of Compliance for the part of your cardholder data environment that runs on AWS, and test that part without further testing of AWS's own controls. The PCI SSC does not require a QSA to go onsite to a validated third-party service provider and retest requirements already covered by that provider's current assessment. That reliance is the reason to obtain the current AOC and Responsibility Summary from AWS Artifact before fieldwork starts, not after. AWS's assessment covers the services AWS names in scope, so the reliance is only as wide as that list.
The reliance has firm edges. It covers the AWS-assessed scope and nothing you build on top of it. Your QSA still tests your own configurations, such as security groups, network ACLs, S3 bucket policies, IAM roles and policies, encryption settings and logging, along with your applications, your identities and the data flows you define. AWS's Responsibility Summary marks which controls sit with you, and those are the ones your QSA will sample. Confirm that the AOC's service list matches every service in your cardholder data flow, including managed databases, queues, logging and key management. A service that is absent from the list is not covered by the reliance.
A provider's compliance does not show that each service it offers was assessed. Before you rely on the AOC, ask your QSA to map each service in your flow against the AWS in-scope list and record the result in your scoping evidence. Where a service is missing or the AOC date does not match the assessment period your QSA is testing, raise it early with your QSA and with AWS. Your own AOC will reference AWS as a third-party service provider, so the reliance must be documented in your scope and responsibility records to hold up at assessment.
How to confirm which AWS services are in scope for your CDE
AWS's AOC covers the services AWS assessed, not everything in its catalog, so your scope depends on matching each service in your design to that assessment. The cards below run the checks in order, from the in-scope list to the scope statement your QSA will read.
Start from the in-scope services list
Open AWS's Services in Scope by Compliance Program list and filter for PCI DSS. This list states which services fall within AWS's PCI DSS assessment, and it is the first reference your QSA will compare against. Treat the list as the authority for AWS's assessed services, and save a dated copy with your assessment evidence. Note that AWS does not directly store, transmit or process your cardholder data, so the list tells you what AWS assessed, not how your workloads handle card data.
Match every CDE service to the list
Build an inventory of each AWS service that stores, processes, transmits or could affect the security of card data in your design, including supporting services such as logging, key management, identity and networking. Compare each name against the in-scope list one by one. A service that appears on the list is covered by AWS's assessment only for the scope AWS describes, so your QSA will still test how you configure it.
Flag services outside the list
Mark any service in your CDE that does not appear on the in-scope list, including newly launched features or services used through a marketplace product. AWS's AOC cannot be relied on for a service it did not assess, so these services fall to your own assessment and may need a separate evidence trail. Ask your QSA how they want those services tested before you add them to a production CDE, since a late discovery can delay your validation.
Record service versions and regions
For each in-scope service, record the regions and any version, engine or configuration tier in use. A service can be on the list while a specific region, deployment model or feature set is not covered by the scope AWS describes, so confirm this in AWS's documentation and with your QSA. Capture the same details in your network and data-flow diagrams so the assessor can trace card data across every region it touches.
Confirm the AOC covers your period
Download the current AWS PCI DSS Attestation of Compliance from AWS Artifact and check its validity dates against the period your own assessment covers. Your QSA needs an AOC that spans the assessment window or an explanation for any gap. Ask AWS or your QSA how any period between AWS's attestation and your assessment will be handled, because an AOC is a point-in-time document that does not extend your own validation.
Document service-level decisions
Write a scope statement that lists each AWS service, its region, whether AWS's AOC covers it, and which of your controls apply to it. Record why any service was excluded from the CDE and how you isolated it. Keep this document under version control, because your QSA will test the scope statement against your network diagrams and asset inventory, and changes to either should trigger a scope review.
What remains your responsibility on AWS
Using AWS does not make your environment compliant. AWS states that customers must manage their own PCI DSS compliance and testing, and that a PCI DSS compliant AWS service does not by itself make a customer compliant. The AWS Attestation of Compliance covers AWS's own infrastructure and services, not your account design, your configurations or your processes. Every requirement that touches your cardholder data environment still needs evidence from your side, and your QSA will test that part directly. The areas most often left to the customer include account and identity design (how AWS accounts are separated, who holds administrative roles, and how multi-factor authentication is enforced), network segmentation through VPCs, subnets, security groups and network ACLs, and encryption and key management choices, including whether you use AWS-managed or customer-managed keys and who can use them. Logging and log review, vulnerability scanning, penetration testing, change control, personnel training and your written policies also sit with you. Any third party you add, such as a managed security provider or a payment software vendor, needs its own responsibility split and its own evidence. AWS states that it does not directly store, transmit or process customer cardholder data and that it is not a shared hosting provider under PCI DSS, so requirement A1.4 does not apply to it. That statement tells you which parts of the cardholder data flow are yours to protect. Before scoping, confirm each area against the Responsibility Summary you download from AWS Artifact, and document who owns each control in your own responsibility matrix.
Should your team scope AWS alone or bring in a partner
This table compares three ways to handle the AWS part of your cardholder data environment: internal scoping with a QSA, an implementation partner preparing evidence before the assessment, or a managed provider whose own PCI DSS assessment covers part of the CDE. Read each row for the fit, who is paid for what, and where independence ends. The main takeaway is that no option transfers your own compliance responsibility to AWS or to a partner.
| Option | When it fits | Who is paid for what | Independence boundary |
|---|---|---|---|
| Internal team with a QSA | Your engineers already know AWS well, the account structure is simple, and you can dedicate staff to collecting evidence and answering assessor questions. | Your organization pays its own staff time and the QSA for the assessment. Cloud subscriptions are paid to AWS. | The QSA assesses your environment independently. Your team prepares and owns all controls and evidence. |
| Implementation partner before the QSA | Your environment spans many accounts, the team lacks PCI DSS experience, or the assessment date is fixed and configuration work is still open. | Your organization pays the partner under a written scope to prepare configurations, documentation and evidence, and pays the QSA separately for the assessment. | The partner prepares systems and evidence but does not issue reports or validate compliance. The QSA must remain independent of the partner's preparation work. |
| Managed provider covering part of the CDE | You outsource operation of a payment component to a provider that holds its own current PCI DSS validation and can show which services that validation covers. | Your organization pays the provider for the service and still pays its own QSA for the parts of the CDE you own. | The provider's AOC covers only the services it assessed. Your QSA can rely on it for that scope, but your own compliance responsibility remains with you. |
| What to confirm before choosing | Use this row to check any option against the AWS AOC, the Responsibility Summary and your data flows. | Ask each party for a written scope, deliverables, and what is excluded from its work. | Confirm with your QSA in advance which evidence and reliance they will accept from each party. |
How to scope an AWS cardholder data environment step by step
This sequence turns AWS's published PCI DSS evidence into a scope decision your QSA can test, separating what AWS has assessed from what your own team must still prove.
Download the AWS AOC and Responsibility Summary
Sign in to the AWS Management Console and open AWS Artifact to obtain the AWS PCI DSS Attestation of Compliance and the Responsibility Summary. AWS states it is assessed as a PCI DSS Level 1 Service Provider by Coalfire, an independent QSA, so these documents are the starting evidence for the AWS side of the environment. Store them with the date you retrieved them, and confirm with your QSA which version they will accept. The step is done when both documents are filed in your assessment evidence folder.
Map cardholder data flows and in-scope accounts
Your team, with the payment and engineering owners, traces how primary account numbers enter, move through, and leave the environment, including every AWS account, region, VPC, and service that touches them. Record the connections to on-premises systems, third-party payment providers, and administrative access paths. Output: a data-flow diagram and an account inventory that name each system component. Confirm that no cardholder data reaches a system you have left off the diagram, because this is what your QSA will test first.
Match each service to the AWS compliance list
Compare every AWS service in your data flows against AWS's Services in Scope by Compliance Program list for PCI DSS. A service listed there was included in AWS's assessment, but a service being in the list does not make your use of it compliant. Mark any service that is absent, out of scope, or only partly covered, and note the scope limits that AWS documents. Output: a service table with three columns, in scope with AWS assessment, not listed, and not applicable, which you will attach to the responsibility matrix.
Build the customer responsibility matrix
Using the Responsibility Summary as the baseline, assign each PCI DSS requirement to AWS, to you, or to a shared owner for each service in your table. AWS states that customers must manage their own PCI DSS compliance and testing, so most application, identity, logging, and configuration controls will remain with your team. Record which AWS-side evidence covers each shared item. Output: a signed matrix that names an owner and an evidence location for every requirement in scope.
Validate the AWS-side boundary with cloud scoping
Review your scope against the principles in PCI SSC's guidance on properly scoping cloud environments. Confirm that a cloud provider's own service provider assessment does not show that each service was assessed, so you must verify coverage for the services you use. Check segmentation between cardholder data and non-payment accounts, and document any shared services such as central logging or identity accounts that may affect security of the CDE. Output: a scope statement that lists in-scope accounts, services, and interconnections, with the rationale for each exclusion.
Prepare your own evidence package
Collect the evidence for every requirement you own: configuration baselines, access reviews, log retention settings, vulnerability scan reports, change records, and policy documents. Include the AWS AOC and Responsibility Summary as inputs, but do not present them as proof of your controls. Organize the package by requirement and by account so the QSA can trace each claim to a source. Output: an indexed evidence repository where every control has a named owner, a date, and a file location.
Hand the package to your QSA
Send the scope statement, data-flow diagrams, service table, responsibility matrix, and evidence index to your QSA before fieldwork begins. The QSA decides what they can rely on from the AWS AOC for the portion of the CDE deployed on AWS, and that determination belongs to the assessor, not to AWS or to your implementation partner. Ask the QSA to confirm the reliance position in writing. The step is complete when the QSA has accepted the scope in writing and has listed any further evidence requests.
Where AWS scope projects go wrong and how to avoid it
Most AWS PCI DSS scoping problems come from one mistaken belief: that AWS's compliance covers what you build on top of it. The cards below cover the decisions where that belief breaks down, and the check that catches each one before your QSA does.
Treating the AOC as covering your account
AWS's Attestation of Compliance covers the part of the cardholder data environment deployed on AWS's services. It does not cover your configurations, your applications, your identity setup or your operating procedures. AWS states that using PCI DSS compliant services does not by itself make a customer compliant, and that customers must manage their own compliance and testing. Map every component in the CDE to one of three owners (AWS, you, or a third party) and write that map down before the assessment starts.
Using services missing from the in-scope list
AWS publishes a Services in Scope by Compliance Program list, and only services on it are covered by the AWS assessment for PCI DSS. A service that is new, in preview, or simply absent from that list still needs its own evidence, and a provider's general PCI DSS status does not show that each service was assessed. Before a service enters the payment flow, check the current list for the PCI DSS program and record the date you checked it. If the service is not listed, plan for your QSA to test it directly or move the function to a covered service.
Stray cardholder data in logs and storage
AWS says it does not directly store, transmit or process customer cardholder data, which means the data you let into logs, backups, snapshots, debug output or object storage is your responsibility. Application logs, load balancer access logs, serverless traces and copied database dumps are common places where primary account numbers appear unmasked. Run discovery scans across S3 buckets, log groups, EBS snapshots and RDS backups, and confirm that stored data falls within your retention and masking rules before you rely on the AOC for those components.
Shared accounts pulling workloads into scope
When payment systems and non-payment workloads share an AWS account, VPC or identity store, the assessor may treat every connected system as in scope, since a compromise there could reach the CDE. The PCI SSC's guidance on properly scoping cloud environments makes this point directly. Separate the CDE into its own accounts or organizational units, control routing with security groups and network firewalls, and document the connections that remain. Ask your QSA to confirm the boundary early, because a late change can expand the assessment considerably.
Relying on an outdated AOC or Responsibility Summary
AWS publishes a new AOC and Responsibility Summary as its assessment cycle completes, and an older copy may list different services or a different validation period. A QSA will check that the AOC in your file is current and matches the services you use. Download both documents from AWS Artifact in the AWS Management Console, record the download date and the period they cover, and set a calendar reminder to refresh the file before your own assessment window opens and whenever you adopt a new service.
Assuming identity and access remain with AWS
AWS operates the underlying infrastructure, but IAM users, roles, policies, MFA settings and access reviews inside your account are yours to configure and evidence. Overly broad administrator roles, long-lived access keys and unreviewed cross-account trust are frequent findings when teams assume the cloud provider handles access. Export your IAM credential report, review who holds administrative rights to the CDE accounts, and keep a dated record of each access review so the assessor can test it.
Questions buyers ask about AWS and PCI DSS scope
Does using AWS, a Level 1 service provider, make us PCI DSS compliant?
No. AWS's validation covers AWS's own environment as a service provider, and AWS states that using PCI DSS compliant AWS services does not by itself make a customer compliant. Your organization still owns its PCI DSS compliance and testing. Your assessment must show how your configurations, applications, identities, logging and policies meet each applicable requirement inside the cardholder data environment you build on AWS. The AWS assessment reduces what you have to prove about the infrastructure layer, not what you have to prove about your own controls.
Where do we get the AWS PCI DSS Attestation of Compliance?
You download the AWS PCI DSS Attestation of Compliance and the Responsibility Summary from AWS Artifact in the AWS Management Console. AWS states it is assessed as a PCI DSS Level 1 Service Provider by Coalfire, an independent QSA. Check that the document you download is the current one and that it names the AWS services your environment uses. Your QSA will want to see the document itself, so keep a dated copy in your evidence repository and record the date you retrieved it.
Can our QSA rely on AWS evidence instead of retesting AWS infrastructure?
Generally yes, for the part of the cardholder data environment deployed on AWS. AWS states that a customer's QSA can rely on the AWS AOC for that part of the CDE without further testing. Reliance is limited to the services that the AOC covers and to controls that AWS is responsible for. Your QSA still assesses everything you configure and operate. Ask your QSA early which AWS evidence they will accept and how they want the responsibility split documented, because the way that evidence is presented shapes how much testing remains.
Which AWS services are covered by the PCI DSS assessment?
Start with AWS's Services in Scope by Compliance Program list, which identifies the services included in its PCI DSS assessment. A cloud provider's compliance does not prove that each service it offers was assessed, so confirm coverage service by service against your own architecture diagram. Services outside that list, third-party marketplace products and services you run on EC2 instances are your responsibility to assess. Record each service in your scope document with its data flows, because scope decisions drive the size of your assessment more than any other factor.
What do we still have to test and document ourselves on AWS?
Everything you configure, operate or change. In practice this includes the following:
- Account structure, identity and access management policies, and multi-factor authentication for your users
- Network controls such as security groups, network ACLs and routing around the CDE
- Encryption, key management and handling of cardholder data stored in your own services
- Logging, log review, time synchronization and retention in your accounts
- Vulnerability scanning, penetration testing and change detection for your workloads and applications
- Policies, roles, training and incident response for your staff and third parties
AWS's responsibility summary tells you which of these controls AWS handles, so use it as the starting point for your responsibility matrix.
Can our internal team handle the AWS PCI DSS work without outside help?
Some organizations can, if they have staff who understand PCI DSS requirements, AWS security services and the assessment process. The work is ongoing, not a one-time project, and the Report on Compliance or Self-Assessment Questionnaire must be prepared on official PCI SSC templates. A QSA independently assesses your environment and issues the ROC if your situation requires one. Consultants and implementation partners can prepare systems, controls and evidence, but they do not issue validation. Decide early which parts your team owns and which parts an outside party will support, and write that split into the engagement.
What does the engagement need from our side to get started?
Expect to supply an accurate architecture diagram, an inventory of AWS accounts, services and data flows, a list of systems that store, process or transmit cardholder data, and named owners for each control area. You also need access to the AWS Management Console for evidence collection, and a decision on which PCI DSS approach you will use for each requirement. The effort scales with the number of accounts, services and third parties involved. Ask for a written scope before work starts, so the deliverables, the evidence you must produce and your own responsibilities are agreed in advance.
How DeployOpen prepares AWS evidence for your QSA
DeployOpen plans, implements and documents self-hosted open-source platforms inside your own AWS accounts, and prepares the systems, controls and evidence that your QSA will examine. DeployOpen does not issue reports, attestations or certifications. Your QSA reaches its conclusions, and your organization owns its controls. The starting point is a written scope that names every account, VPC, service and component that stores, processes or transmits cardholder data, plus the systems that could affect the security of that environment. Most engagements are fixed-scope, so the scope, deliverables and timelines are agreed in writing before work begins.
Once the scope is set, the evidence work starts with the parts of the environment that remain your responsibility after you take the AWS AOC and Responsibility Summary from AWS Artifact. Typical deliverables include network and data-flow diagrams, a service inventory that maps each in-scope AWS service to the AWS assessment it relies on, configuration baselines for the open-source platforms, and records showing that logging, access reviews and change control operate as described. Confirm with your QSA which AWS services they will accept under the AOC, because the AOC covers only the services AWS lists as assessed. Ask your QSA early whether they expect to see the Responsibility Summary mapped to your own configurations.
Before your QSA arrives, ask DeployOpen for a written deliverables list that states exactly which evidence items it will produce, which items your team must sign off, and which items your QSA must review directly. Confirm how the platforms will be documented, backed up and upgraded after handover, and whether ongoing support is needed through a separate retainer. Any cost or timeline figures belong in the written quote that follows from this scope, not in general estimates. Keep the scope document, the inventory and the Responsibility Summary together so that your QSA can trace each customer-side control to its owner and its evidence.
How DeployOpen scopes, implements and hands over AWS evidence
DeployOpen plans, implements and documents self-hosted open-source platforms inside your own AWS accounts, so the parts of your cardholder data environment you control are built and evidenced in a way your QSA can review. DeployOpen prepares systems, controls and evidence. Only your QSA issues the Report on Compliance and Attestation of Compliance.
How we scope
- Map which AWS services carry, process or could affect cardholder data, checked against AWS's own in-scope services list.
- Confirm with your QSA which parts of the CDE rely on the AWS AOC and which remain your own responsibility.
- Agree the scope, deliverables and timelines in writing before any work starts, since most engagements are fixed-scope.
How we build
- Configure and harden self-hosted open-source platforms in your own AWS accounts against your network and data-flow diagrams.
- Implement logging, access control, encryption and file integrity monitoring for the components you own under your responsibility matrix.
- Test each control against the requirement it supports, then record the results in a form your QSA can trace.
How we hand over
- Deliver the AWS AOC and Responsibility Summary alongside your own control matrix, so the split of duties is documented in one place.
- Provide configuration records, screenshots, logs and change history that show each control operating as designed.
- Walk your internal team and QSA through the evidence, and document the systems and controls we handed over.
How we support
- Keep your evidence current after handover as AWS services, configurations and your own workloads change.
- Upgrade and patch the open-source platforms we deployed, with changes recorded for your next assessment.
- Offer ongoing support, upgrades and continuous testing as a retainer, agreed separately from the initial scope.
