Who is accountable for PCI DSS compliance in AWS shared responsibility models?

Why This Matters for Security Teams

PCI DSS responsibility in AWS is often misunderstood because cloud hosting changes the control boundary, not the compliance obligation. AWS secures the infrastructure layer, but the customer still owns the configuration, identities, data handling, logging, and business processes that determine whether cardholder data is protected. That distinction matters because PCI DSS expects evidence, not assumptions, and auditors will test the controls that sit inside the customer’s environment.

For teams operating payment workloads, the practical question is not whether AWS is “PCI compliant” in the abstract. It is whether the organisation has mapped each PCI DSS requirement to the correct party, then implemented compensating controls where the shared responsibility model leaves gaps. A useful baseline is the PCI DSS v4.0 — PCI Security Standards Council guidance, paired with control mapping from NIST Cybersecurity Framework 2.0 and supporting control depth from NIST SP 800-53 Rev 5 Security and Privacy Controls. In practice, many security teams encounter PCI failures only after an audit, a breach, or an overbroad cloud rollout has already exposed cardholder data.

How It Works in Practice

The shared responsibility model divides obligations by layer. AWS is responsible for the security of the cloud, including data centre facilities, physical hardware, managed platform foundations, and certain service-level controls. The customer is responsible for security in the cloud, which includes IAM design, network segmentation, workload hardening, encryption choices, patching of guest systems, application security, and monitoring. For PCI DSS, that means the customer usually owns the controls that matter most to scope reduction and evidence collection.

Operationally, this should be translated into a clear responsibility matrix for each PCI requirement. A strong matrix names the control owner, the system owner, the evidence source, and the review cadence. It should also distinguish between native AWS services and customer-managed components, because the line shifts depending on whether the workload uses EC2, EKS, serverless services, or fully managed data services. The cloud provider may support compliance, but it does not automatically extend compliance to a customer deployment.

• Define where cardholder data enters, moves, stores, and leaves the AWS environment.
• Assign ownership for IAM, logging, encryption, vulnerability management, and segmentation.
• Collect evidence from CloudTrail, Config, security groups, KMS, and workload-level records.
• Validate that service selection matches the PCI scope assumptions, especially for shared and managed services.

For governance alignment, many organisations map PCI obligations to the control families in ISO/IEC 27001:2022 Information Security Management and ISO/IEC 27002:2022 Information Security Controls, then use those mappings to support policy, risk treatment, and audit evidence. This is especially useful when the PCI programme spans security engineering, cloud operations, and third-party assurance. These controls tend to break down when ownership is split across platform, application, and compliance teams without a single system of record for evidence.

Common Variations and Edge Cases

Tighter cloud governance often increases operational overhead, requiring organisations to balance audit assurance against deployment speed. That tradeoff becomes more visible in AWS because some services reduce infrastructure burden while increasing the need for disciplined configuration and monitoring.

One common edge case is the use of fully managed AWS services. Best practice is evolving, but the current guidance suggests that managed services can reduce some PCI obligations while leaving the customer responsible for data classification, access control, retention, and transaction integrity. Another edge case is multi-account architecture: central security tooling can improve consistency, yet each account may still need separate scoping, logging, and access review evidence if cardholder data is present.

There is also a practical identity intersection. If cardholder data access depends on weak IAM design, shared admin roles, or unmanaged secrets, PCI compliance becomes fragile even when the underlying AWS services are configured correctly. The same is true for third-party integrators and payment applications that extend the scope of the environment. Organisations subject to AML or identity verification obligations may also need to align transaction controls with FATF Recommendations — AML and KYC Framework, but that is a related governance layer, not a substitute for PCI accountability. The cleanest answer is still this: AWS provides platform assurance, while the customer remains accountable for PCI design, operation, and evidence.

Related resources from NHI Mgmt Group

• Why do shared responsibility models create compliance risk in cloud environments?
• How should security teams govern non-human identities for compliance?
• How should security teams govern non-human identities for SOC 2 compliance?
• Why do non-human identities create compliance risk even when policies exist?