PCI DSS Security Maturity Model for AWS

The vertical axis is the 12 PCI DSS requirements (grouped into 6 control objectives). The horizontal axis is 4 maturity phases prioritized by ease/cost versus impact: Quick Wins, Foundational, Efficient, and Optimized. Each cell contains one or more AWS control recommendations. The phases are a roadmap, not a maturity score: start with Quick Wins (high impact, low effort) and progress toward Optimized (continuous, automated compliance). The recommendations are aligned to PCI DSS v4.0.1; see the Changelog for the model version and future updates.

Every recommendation states what the control is and why it matters (summary), how to implement it on AWS (implementation guidance and AWS services), how it would be validated (PCI testing methods and testing procedures) and what evidence you can present in AWS. Each recommendation is also tagged with its maturity phase, its AWS security domain, the PCI sub-requirements it covers, effort/impact, whether it applies to the CDE, and its shared-responsibility classification.

The model provides two reference architecture paths for hosting a cardholder data environment (CDE) on AWS: a single-account, three-tier design for smaller or early-stage environments, and a multi-account design with a dedicated PCI organizational unit (OU) for scale, separation of duties, and scope reduction.

These are not just background diagrams. On each recommendation's detail page, a Practical implementation section shows how that specific control is applied in each architecture, so you can see the difference between, for example, isolating the CDE with subnets in one account versus isolating it in a dedicated account under a PCI OU. Start on the Reference architectures page to understand the two paths, then use the matrix and each control's practical guidance to plan your build.

On AWS, PCI DSS compliance is a shared responsibility. Each recommendation is classified as 'customer' (you implement and evidence it), 'aws' (AWS operates the control; you inherit it and evidence it with the AWS PCI DSS Attestation of Compliance from AWS Artifact), or 'shared' (both parties have obligations). This classification is derived from the AWS PCI DSS OSCAL System Security Plan. Physical security (Requirement 9.2, 9.3) is a typical 'aws' example; policies and risk management (Requirement 12) are typically 'customer'.

PCI DSS v4.0.1 allows two ways to meet most requirements.

• Defined Approach: you implement the requirement exactly as written and it is validated against the standard's defined testing procedures. This is what the 'testing procedures' and 'AWS evidence' fields in each recommendation describe, and it is the path most organizations take.

• Customized Approach: instead of following the prescribed method, you design your own controls that meet the Customized Approach Objective of the requirement. This path is for mature organizations with a robust risk-management function. It requires a documented targeted risk analysis (Requirement 12.3.2), and the assessor derives bespoke testing procedures to confirm your controls meet the objective.

Because of this, each eligible recommendation includes the Customized Approach Objective for the sub-requirement(s) it covers, so a team choosing the customized path knows the outcome their custom controls must achieve. Not every control is eligible: a few are defined-approach only (for example, not storing sensitive authentication data under Requirement 3.3). Customized approaches typically appear in the Optimized phase, where organizations optimize how they meet objectives rather than how the requirement is written.

Because each recommendation carries structured tags, the same content can be viewed by PCI requirement (the default matrix), by maturity phase (a roadmap), by AWS security domain (a cross-cutting view), or by shared responsibility (customer vs inherited from AWS). You can also filter by whether a control applies to the CDE and by effort/impact.

The model is available in English (the source language), Spanish, and Portuguese. Requirement text and testing procedures are aligned with the official PCI DSS v4.0.1 standard; the shared-responsibility classification and control catalog draw on the AWS PCI DSS OSCAL package; and the AWS guidance draws on the PCI DSS on AWS guide, the AWS Security Reference Architecture, and the AWS Security Maturity Model.