PCI DSS Security Maturity Model·AWS v1.1.0

Drag to explore · pinch to zoom
Home / Matrix / Requirement 7 / c7.2
Foundational Identity and Access ManagementSecurity domain from the AWS Cloud Adoption Framework (CAF) Security Perspective, used to organize the controls. 🤝 SharedAWS Shared Responsibility Model: who implements and operates this control. Customer = you own it; AWS = AWS operates it and you inherit it; Shared = both have obligations.

c7.2 Centralize access with IAM Identity Center and role-based permissions

Manage access through a centralized access control system that covers all system components, with default-deny unless explicitly authorized.

Quick Wins
Foundational
Efficient
Optimized
Effort: Medium Impact: High Applies to CDE: Yes

Requirement 7

Restrict Access to System Components and Cardholder Data by Business Need to Know

PCI sub-requirements coveredCoverage shown per PCI DSS v4.0.1 sub-control. “Covered” = addressed by this AWS recommendation. “Roadmap” = technical, planned. “Your responsibility” = organizational/process control. “Out of scope” = physical or third-party control not implemented in AWS.

7.2 Access to system components and data is appropriately defined and assigned
  • 7.2.1 Access control model defined for need-to-know/least-privilege Covered
  • 7.2.2 Access assigned based on job classification and least privilege Covered
  • 7.2.3 Required privileges approved by authorized personnel Your responsibility
  • 7.2.4 User accounts and access reviewed at least every 6 months Your responsibility
  • 7.2.5 Application/system accounts and access managed by least privilege Covered
  • 7.2.5.1 Access by app/system accounts reviewed periodically Your responsibility
  • 7.2.6 Query access to stored CHD restricted via roles/applications Covered
7.3 Access is managed via an access control system(s)
  • 7.3.1 Access control system(s) in place covering all components Covered
  • 7.3.2 Access control system configured to enforce least privilege Covered
  • 7.3.3 Access control system set to 'deny all' by default Covered

How to implement on AWS

Adopt AWS IAM Identity Center with permission sets by job function, federated with the corporate IdP. Enforce a default-deny model reinforced with SCPs in AWS Organizations. Define data perimeters to limit access to CDE resources.

Practical implementation

How this control is implemented in each reference architecture:

In a single account, build role-based, default-deny access with native IAM roles per job function (no standing users), and evolve to IAM Identity Center for federation as you grow.

  1. Define IAM roles by job function and have people assume them (via federation or short-lived sessions) instead of standing IAM users; grant only the specific actions/resources each function needs (deny-by-default).
    Account access IAM
  2. Apply data perimeters (resource policies / IAM conditions) so CDE resources are reachable only from trusted identities.
    Data tier (CDE) IAM
  3. Evolution: when you need centrally assigned, IdP-federated access with permission sets, adopt IAM Identity Center. Note that permission-set access to AWS accounts requires an organization instance, which adopts AWS Organizations (a standalone account instance only covers application access, not account permission sets).
    Account access (as you scale) IAM Identity Center

How to validate: Access is assigned through job-function IAM roles (no standing users with inline admin), least privilege is enforced, and a request for an action outside the granted role is denied by default.

Avoid: Handing people standing IAM users with broad inline policies. Define roles by job function, grant least privilege, and deny by default.

Single-account, 3-tier →

This is where multi-account shines: assign permission sets across all accounts from one place, enforce default-deny with SCPs, and lock CDE data to trusted identities/networks.

  1. Use IAM Identity Center to assign permission sets across all accounts from a single place, federated to the IdP.
    Identity / security account → PCI OU IAM Identity Center AWS Organizations
  2. Enforce default-deny guardrails with SCPs on the PCI OU so no account can exceed its allowed actions.
    PCI OU (guardrail) AWS Organizations
  3. Define data perimeters so CDE data is reachable only from trusted identities and networks (blocking untrusted principals/VPCs).
    Each CDE workload account IAM

How to validate: Identity Center covers all accounts, an SCP test blocks an out-of-scope action in a CDE account, and the data perimeter rejects an untrusted principal.

Avoid: Federating each account separately. Centralize in Identity Center so access, MFA, and default-deny are uniform across the org.

Multi-account with a dedicated PCI OU →

PCI validation

Testing methods: examineobserve

Testing procedures

  • Examine vendor documentation and system settings to verify the access control system manages access for each component based on need to know and covers all system components (7.3.1).
  • Verify the access control system enforces permissions by job classification and function (7.3.2).
  • Verify the access control system is set to 'deny all' by default (7.3.3).

Evidence in AWS

  • IAM Identity Center permission sets mapped to job functions.
  • Organizations SCPs that enforce default-deny.
  • Data perimeter configuration restricting access to the CDE.

Customized approach

Requires a targeted risk analysis (Req 12.3.2).

Customized Approach Objective

  • 7.2 — Access requirements are established according to job functions following least-privilege and need-to-know principles.
  • 7.3 — Access rights and privileges are managed via an access control system(s) that restricts access based on need to know and is set to deny by default.

AWS services

AWS IAM Identity Center AWS Organizations AWS IAM

Learning resources

References

  • AWS Security Maturity Model: Federated identity
  • PCI DSS v4.0.1 Requirement 7.3