PCI DSS Security Maturity Model·AWS v1.1.0

Drag to explore · pinch to zoom
Home / Matrix / Requirement 1 / c1.3
Foundational Infrastructure ProtectionSecurity 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.

c1.3 Network segmentation with VPCs and multi-account architecture

Isolate the CDE from the rest of the infrastructure through network segmentation. Effective segmentation reduces the scope of the PCI DSS assessment.

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

Requirement 1

Install and Maintain Network Security Controls

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.

1.2 NSCs are configured and maintained
  • 1.2.1 NSC config standards defined and applied Covered
  • 1.2.2 Changes to network connections and NSCs are approved and managed Your responsibility
  • 1.2.3 Accurate network diagram(s) maintained Your responsibility
  • 1.2.4 Accurate data-flow diagram(s) maintained Your responsibility
  • 1.2.5 All services, protocols, and ports allowed are identified and justified Covered
  • 1.2.6 Security features for insecure services/protocols are defined Covered
  • 1.2.7 NSC configurations reviewed at least every 6 months Your responsibility
  • 1.2.8 NSC configuration files are secured and consistent with active settings Covered
1.3 Network access to and from the CDE is restricted
  • 1.3.1 Inbound traffic to the CDE is restricted to what is necessary Covered
  • 1.3.2 Outbound traffic from the CDE is restricted to what is necessary Covered
  • 1.3.3 NSCs installed between all wireless networks and the CDE Covered

How to implement on AWS

Separate the CDE into its own dedicated VPC or AWS account using AWS Organizations. Use separate accounts for production, non-production, and the CDE. Control connectivity between VPCs with Transit Gateway or VPC Peering using restrictive route tables. Validate segmentation with periodic testing.

Practical implementation

How this control is implemented in each reference architecture:

Segment inside one account with subnet tiers and security groups. This reduces in-account scope but does not isolate the CDE from other workloads in the same account, its main limitation.

  1. Place the CDE in isolated private subnets and expose only the load-balancer subnet to the internet; everything else is private.
    Public subnet vs. App/Data tiers (CDE) Amazon VPC Elastic Load Balancing
  2. Use per-tier security groups with cross-references (not IP ranges) so the app tier only talks to the data tier on the database port, and nothing else can.
    App tier (CDE) → Data tier (CDE) Amazon VPC
  3. Document the segmentation in the network and data-flow diagrams that PCI requires, and plan to graduate to the multi-account design when scope reduction becomes a priority.
    Whole account (in-scope) Amazon VPC

How to validate: Network diagram matches the deployed subnets/security groups, and the CDE data tier has no route to the internet gateway.

Avoid: Treating a single account as 'segmented' from other workloads. Everything in one account shares a trust and blast-radius boundary; for real isolation, separate accounts.

Single-account, 3-tier →

This is the design's core strength for scope reduction: the CDE runs in dedicated workload accounts under the PCI OU, fully separated from non-PCI accounts, and segmentation is proven by testing.

  1. Run the CDE in its own workload account(s) under the PCI OU, with no shared VPC or account with non-PCI workloads.
    PCI OU (CDE workload accounts) AWS Organizations Amazon VPC
  2. Use Transit Gateway route tables that connect the CDE accounts only to the shared network/inspection path, never directly to out-of-scope accounts.
    Network/inspection account Transit Gateway
  3. Validate the segmentation with the annual segmentation penetration test (PCI DSS 11.4.5) and keep the results as scope-reduction evidence.
    PCI OU boundary

How to validate: AWS Organizations shows the CDE in a dedicated OU/accounts, Transit Gateway route tables prove isolation, and the segmentation pen-test confirms the CDE is unreachable from out-of-scope networks.

Avoid: Sharing a Transit Gateway route table between CDE and non-CDE accounts. Use separate route tables/domains so out-of-scope networks cannot reach the CDE.

Multi-account with a dedicated PCI OU →

PCI validation

Testing methods: examinetest

Testing procedures

  • Examine configuration standards and network diagrams to verify that NSCs are defined and in place between trusted and untrusted networks (1.4.1.a, 1.4.1.b).
  • Examine the network and data-flow diagrams to verify that system components storing cardholder data are not directly accessible from untrusted networks (1.4.4.a, 1.4.4.b).
  • When segmentation is used to reduce scope, confirm isolation through segmentation testing (see 11.4.5).

Evidence in AWS

  • AWS Organizations structure showing the account/OU dedicated to the CDE.
  • Transit Gateway route tables and VPC configurations evidencing isolation.
  • Segmentation penetration-test results confirming that the CDE is unreachable from out-of-scope networks.

Customized approach

Requires a targeted risk analysis (Req 12.3.2).

Customized Approach Objective

  • 1.2 — The way that NSCs are configured and operate is defined and consistently applied.
  • 1.3 — Unauthorized traffic cannot enter the CDE.

AWS services

Amazon VPC AWS Organizations AWS Transit Gateway AWS RAM

Learning resources

References

  • AWS Security Maturity Model: Network segmentation (VPCs), Multi-account management