PCI DSS Security Maturity Model·AWS v1.1.0

Drag to explore · pinch to zoom
Home / Matrix / Requirement 9 / c9.1
Quick Wins Security GovernanceSecurity domain from the AWS Cloud Adoption Framework (CAF) Security Perspective, used to organize the controls. ☁ AWSAWS 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.

c9.1 Inherit AWS physical controls through the compliance reports

On AWS, the physical security of the data centers is AWS's responsibility under the shared responsibility model. The customer inherits these controls and evidences them with the AWS PCI DSS AOC obtained via AWS Artifact.

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

Requirement 9

Restrict Physical Access to Cardholder Data

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.

9.2 Physical access controls manage entry into facilities and systems
  • 9.2.1 Physical access controls at facility entries Out of scope
  • 9.2.1.1 Monitoring of physical access with cameras/mechanisms Out of scope
  • 9.2.2 Physical/logical controls restrict use of publicly accessible network jacks Covered
  • 9.2.3 Physical access to wireless access points/hardware restricted Out of scope
  • 9.2.4 Access to consoles in sensitive areas restricted via locking Out of scope
9.3 Physical access for personnel and visitors is authorized and managed
  • 9.3.1 Procedures to authorize/manage personnel physical access Out of scope
  • 9.3.1.1 Physical access to sensitive areas controlled and individually assigned Out of scope
  • 9.3.2 Procedures to authorize/manage visitor access Out of scope
  • 9.3.3 Visitor badges/identification distinguished and surrendered Out of scope
  • 9.3.4 Visitor log maintained Out of scope

How to implement on AWS

Download the AWS PCI DSS Attestation of Compliance (AOC) and the customer responsibilities from AWS Artifact. Document in the shared responsibility matrix which physical sub-requirements AWS covers. Keep these documents current as evidence for the assessor.

Practical implementation

How this control is implemented in each reference architecture:

Physical security of the AWS facilities is AWS's responsibility under the shared model. Your work is to inherit those controls and evidence them.

  1. Download the current AWS PCI DSS Attestation of Compliance (AOC) and the customer responsibility guide from AWS Artifact.
    AWS Artifact (this account) AWS Artifact
  2. Record in your shared-responsibility matrix that Requirements 9.2/9.3 (physical CDE access) are inherited from AWS.
    Shared responsibility matrix
  3. Keep the AOC current (re-download on renewal) so the assessor always sees valid evidence.
    Evidence store AWS Artifact

How to validate: A current AWS PCI DSS AOC is on file from Artifact, and the shared-responsibility matrix maps 9.2/9.3 to AWS.

Avoid: Trying to 'implement' data-center physical controls yourself on AWS. You cannot; inherit them and evidence via the AWS AOC instead.

Single-account, 3-tier →

The same inheritance applies to every CDE account; capture it once at the org level with a single matrix.

  1. Use AWS Artifact organization agreements to obtain the AOC once for the whole organization.
    Management/Artifact (org) AWS Artifact AWS Organizations
  2. Maintain one shared-responsibility matrix that covers all CDE accounts under the PCI OU.
    Org-level shared responsibility matrix
  3. Store the AOC and matrix centrally so every account references the same current evidence.
    Log archive / evidence store Amazon S3

How to validate: The org-level AOC and a single shared-responsibility matrix cover every PCI OU account, and both are current.

Avoid: Downloading and tracking the AOC separately per account. Capture it once at the org level so evidence stays consistent and current.

Multi-account with a dedicated PCI OU →

PCI validation

Testing methods: examine

Testing procedures

  • Observe entry controls and physical access controls to verify that access to systems in the CDE is restricted, and that entry/exit points of sensitive areas are monitored and the recordings retained (9.2.1, 9.2.1.1.a, 9.2.1.1.c).
  • Examine procedures for authorizing and managing physical access of personnel and visitors to the CDE (9.3.1.a, 9.3.2.a). On AWS, these controls are inherited from AWS under the shared responsibility model and evidenced via the AWS PCI DSS AOC.

Evidence in AWS

  • AWS PCI DSS AOC downloaded from AWS Artifact (current).
  • Shared responsibility matrix documenting the physical controls covered by AWS.
  • AWS customer responsibilities guide for PCI DSS.

Customized approach

Requires a targeted risk analysis (Req 12.3.2).

Customized Approach Objective

  • 9.2 — System components in the CDE cannot be physically accessed by unauthorized personnel.
  • 9.3 — Requirements for access to the physical CDE are defined and enforced to identify and authorize personnel.

AWS services

AWS Artifact

Learning resources

References

  • PCI DSS v4.0.1 Requirement 9.2, 9.3 (AWS responsibility)