PCI DSS Security Maturity Model·AWS v1.1.0

Drag to explore · pinch to zoom
Home / Matrix / Requirement 7 / c7.1
Quick Wins 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.1 Enforce least privilege with IAM policies

Assign access to system components and account data based on business need, granting the minimum privilege necessary through well-defined IAM policies and roles.

Quick Wins
Foundational
Efficient
Optimized
Effort: Low 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

Define IAM roles by job function with minimal permissions. Avoid long-lived IAM users in favor of roles and temporary credentials. Use IAM Access Analyzer to detect broad or external access. Remove policies with unnecessary wildcards (Action:*, Resource:*).

Practical implementation

How this control is implemented in each reference architecture:

Grant the minimum privilege by job function through IAM roles, avoid long-lived credentials, and detect any broad or external access.

  1. Define IAM roles per job function with least-privilege policies for the app/data tiers; scope Action and Resource, avoiding wildcards (Action:*, Resource:*).
    App tier (CDE) / Data tier (CDE) IAM
  2. Replace long-lived IAM users with roles and temporary credentials (instance roles, federation).
    Whole account IAM
  3. Run IAM Access Analyzer to detect policies that grant broad or external access and remediate them.
    Account-wide detection IAM

How to validate: IAM Access Analyzer shows no unjustified external/broad findings, and a role-vs-business-function matrix maps each role to a documented need.

Avoid: Attaching AdministratorAccess 'temporarily' to move fast. Broad grants become permanent; start from least privilege and widen only with justification.

Single-account, 3-tier →

Standardize least-privilege permission sets and detect broad/external access across every CDE account from the delegated administrator.

  1. Define standard least-privilege permission sets by job function and apply them consistently across accounts.
    Security tooling / identity account IAM Identity Center
  2. Run IAM Access Analyzer at the organization level (delegated admin) so external/broad access is detected across all CDE accounts in one place.
    Security tooling account → PCI OU IAM AWS Organizations
  3. Reinforce boundaries with SCPs and data perimeters so identities cannot reach CDE resources outside their scope.
    PCI OU (guardrail) AWS Organizations

How to validate: Org-level Access Analyzer shows no unjustified external access across accounts, and permission sets match the documented job-function model.

Avoid: Per-account, hand-crafted IAM that drifts. Standardize permission sets centrally and analyze access org-wide.

Multi-account with a dedicated PCI OU →

PCI validation

Testing methods: examineinterview

Testing procedures

  • Examine policies/procedures and the access-control model settings to verify access needs are defined per the requirement (7.2.1.a, 7.2.1.b).
  • Examine user access settings, including privileged users, and interview management to verify assigned privileges follow classification and job function (7.2.2.b, 7.2.2.c).
  • Compare assigned privileges to documented approvals by authorized personnel (7.2.3.b).

Evidence in AWS

  • IAM policies and roles evidencing least privilege by function.
  • IAM Access Analyzer findings with no unjustified external/broad access.
  • Documented role-vs-business-function matrix.

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 IAM Access Analyzer AWS IAM Identity Center

Learning resources

References

  • AWS Security Maturity Model: Least privilege