PCI DSS Security Maturity Model·AWS v1.1.0

Drag to explore · pinch to zoom

Quick Wins Security GovernanceSecurity domain from the AWS Cloud Adoption Framework (CAF) Security Perspective, used to organize the controls. 👤 CustomerAWS 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.

c12.1 Define the CDE scope and maintain the inventory with AWS Config

Document and validate the PCI DSS scope by maintaining an accurate inventory of the system components in the CDE, updated as changes occur.

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

Requirement 12

Support Information Security with Organizational Policies and Programs

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.

12.5 PCI DSS scope is documented and validated
  • 12.5.1 Inventory of system components in scope maintained Covered
  • 12.5.2 PCI DSS scope documented and confirmed at least annually Your responsibility
  • 12.5.2.1 Scope confirmed every 6 months for service providers (SP only) Your responsibility
  • 12.5.3 Org structure changes trigger scope review (SP only) Your responsibility

How to implement on AWS

Enable AWS Config to inventory resources continuously. Tag CDE resources with a consistent tagging strategy and enforce it with Organizations tag policies. Generate the in-scope component inventory from Config. Review scope at least annually and after significant changes.

Practical implementation

How this control is implemented in each reference architecture:

Keep an accurate, always-current inventory of in-scope components so the PCI scope is known and defensible.

  1. Enable AWS Config to inventory resources continuously in the account.
    Account-wide detection AWS Config
  2. Tag CDE resources with a consistent tagging strategy and generate the in-scope inventory by filtering Config on those tags.
    All CDE resources AWS Config
  3. Review scope at least annually and after significant changes, recording the review date.
    Scope documentation

How to validate: Config produces a current CDE-tagged inventory, and the scope document shows a review within the last 12 months.

Avoid: A hand-maintained spreadsheet inventory. It drifts; derive the inventory from Config so it stays accurate automatically.

Single-account, 3-tier →

Derive the in-scope inventory org-wide from a Config aggregator, with tagging enforced by policy.

  1. Aggregate the resource inventory across the PCI OU with a Config aggregator in the security tooling account.
    Security tooling account → PCI OU AWS Config AWS Organizations
  2. Enforce the CDE tagging strategy with Organizations tag policies so tagging is consistent everywhere.
    PCI OU (guardrail) AWS Organizations
  3. Derive and review the in-scope inventory org-wide at least annually.
    Security tooling account AWS Config

How to validate: The Config aggregator lists CDE resources across all accounts, tag policies enforce the scheme, and the org-wide scope review is current.

Avoid: Inventorying each account separately. Aggregate with a Config aggregator so scope is complete and consistent.

Multi-account with a dedicated PCI OU →

PCI validation

Testing methods: examineinterview

Testing procedures

  • Examine the inventory to verify it includes all in-scope system components with a description of function/use, and interview personnel to confirm it is kept current (12.5.1.a, 12.5.1.b).
  • Examine documented scope-review results and interview personnel to verify scope is confirmed at least every 12 months and after significant changes (12.5.2.a, 12.5.2.b).

Evidence in AWS

  • AWS Config resource inventory filtered by CDE tags.
  • Organizations tag policies applied to the CDE.
  • PCI scope document with last-review date (<= 12 months).

Customized approach

Requires a targeted risk analysis (Req 12.3.2).

Customized Approach Objective

  • 12.5 — All system components in scope for PCI DSS are identified and known.

AWS services

AWS Config AWS Organizations AWS Resource Groups

Learning resources

References

  • AWS Security Maturity Model: Define scope, Inventory
  • PCI DSS v4.0.1 Requirement 12.5