What does PCI-DSS require for network segmentation in AWS?

PCI-DSS Requirement 1 (Network Security Controls) requires that the cardholder data environment (CDE) is isolated from all other network segments. Specifically, Requirement 1.3.1 mandates that inbound traffic to the CDE is restricted to only what is necessary, and Requirement 1.3.2 mandates the same for outbound. In AWS, this means controlling all VPC peering connections, Transit Gateway route tables, and security group rules that could allow traffic to or from CDE VPCs.

What is a CDE VPC in AWS?

A CDE VPC (Cardholder Data Environment VPC) is an AWS VPC that stores, processes, or transmits cardholder data — such as primary account numbers (PANs), CVVs, or magnetic stripe data. Any VPC that can reach the CDE VPC is considered 'in scope' for PCI-DSS, which is why isolating the CDE VPC from all other VPCs is critical to reducing audit scope.

How often must PCI-DSS network segmentation be tested?

PCI-DSS Requirement 11.4.5 requires that segmentation controls are tested at least every six months and after any changes to segmentation controls. The testing must verify that segmentation is operational and effective, and that all out-of-scope systems cannot reach in-scope CDE systems.

What evidence do QSAs accept for AWS network segmentation?

QSAs typically require point-in-time evidence that includes: a topology diagram showing which VPCs are in scope, route table exports showing no unauthorized paths to the CDE, security group rules for CDE-facing resources, and records of segmentation testing. Screenshots are generally accepted but must be timestamped; automated, signed reports are preferred because they are harder to manipulate and demonstrate repeatable process.

How to Audit AWS VPC Topology for PCI-DSS — What Your QSA Will Check

When a Qualified Security Assessor (QSA) arrives for a PCI-DSS assessment of your AWS environment, the first thing they want to understand is your network topology. Not your Security Hub score. Not your GuardDuty findings. The topology — specifically, which VPCs can reach the one that holds cardholder data, and how you can prove that list is complete and correct.

This post walks through the specific PCI-DSS requirements that govern network segmentation in AWS, what QSAs actually request as evidence, and the practical problem with the most common approach teams use to produce it.

Requirement 1: Network Security Controls

PCI-DSS v4.0 reorganized the old "firewall" requirements into a broader framework called Network Security Controls (NSCs). The goal is the same as it always was: the Cardholder Data Environment (CDE) must be isolated from everything else, and that isolation must be demonstrably enforced at the network layer.

Two sub-requirements are directly relevant to AWS VPC topology:

Requirement 1.3.1 — Inbound Traffic Restriction

Inbound traffic to the CDE is restricted to only that which is necessary. In AWS, this means every VPC peering connection, Transit Gateway attachment, and security group rule that allows traffic into a CDE VPC must be documented and justified.

Requirement 1.3.2 — Outbound Traffic Restriction

Outbound traffic from the CDE is likewise restricted to only what is necessary. Unrestricted egress from a CDE VPC — for example, a route to a Transit Gateway with no route table scoping — is a finding. QSAs will check both directions.

In a traditional data center, "firewall rules" are the primary evidence. In AWS, the equivalent evidence set is larger: VPC peering connections, Transit Gateway route tables, Network ACLs, security groups, and VPC endpoint policies all contribute to the effective network boundary of a CDE VPC. A QSA assessing an AWS environment will want to see all of them.

What Defines the CDE VPC Boundary

The CDE is not just the VPC that holds your payment database. Under PCI-DSS, any system that can communicate with a CDE system is considered in-scope, which means any VPC with a network path to the CDE VPC is drawn into scope. This is why the topology question matters so much: every peering connection or Transit Gateway route that can reach the CDE CIDR range expands your audit scope.

The practical definition of "CDE VPC boundary" for a QSA review is:

The CDE VPC itself (the VPC tagged or identified as holding cardholder data)
Any VPC with an active peering connection to the CDE VPC
Any VPC attached to a Transit Gateway that has a route to the CDE CIDR in its route tables
Any shared services VPC (e.g., a central logging or DNS VPC) that bridges the CDE and non-CDE environments

This is why "we don't peer the CDE VPC to anything" is not sufficient — shared Transit Gateways can create indirect paths that aren't visible from the CDE VPC's own peering list.

Pulling Evidence with the AWS CLI

Before your QSA visit, run these commands to enumerate what you'll need to explain. Replace vpc-0abc1234 with your actual CDE VPC ID.

List all VPC peering connections involving the CDE VPC:

aws ec2 describe-vpc-peering-connections \
  --filters \
    "Name=accepter-vpc-info.vpc-id,Values=vpc-0abc1234" \
    "Name=status-code,Values=active" \
  --query 'VpcPeeringConnections[*].{ID:VpcPeeringConnectionId,Requester:RequesterVpcInfo.VpcId,CIDR:RequesterVpcInfo.CidrBlock}' \
  --output table

# Also check as requester
aws ec2 describe-vpc-peering-connections \
  --filters \
    "Name=requester-vpc-info.vpc-id,Values=vpc-0abc1234" \
    "Name=status-code,Values=active" \
  --query 'VpcPeeringConnections[*].{ID:VpcPeeringConnectionId,Accepter:AccepterVpcInfo.VpcId,CIDR:AccepterVpcInfo.CidrBlock}' \
  --output table

Check Transit Gateway route tables for routes to the CDE CIDR (e.g., 10.10.0.0/16):

aws ec2 search-transit-gateway-routes \
  --transit-gateway-route-table-id tgw-rtb-0abc1234 \
  --filters "Name=route-search.exact-match,Values=10.10.0.0/16" \
  --query 'Routes[*].{Destination:DestinationCidrBlock,State:State,Attachment:TransitGatewayAttachments[0].ResourceId}' \
  --output table

Pull all route tables in the CDE VPC to check for unexpected outbound routes:

aws ec2 describe-route-tables \
  --filters "Name=vpc-id,Values=vpc-0abc1234" \
  --query 'RouteTables[*].{RTID:RouteTableId,Routes:Routes[*].{Dest:DestinationCidrBlock,Target:GatewayId}}' \
  --output json

Note: These commands give you a point-in-time snapshot. They don't tell you whether this state has been true continuously since your last assessment, or whether a peering connection was added and removed in between scans. QSAs are increasingly aware of this gap.

Requirement 11.4.5 — Segmentation Testing Every 6 Months

This is the requirement that catches teams off guard most often. It's not enough to have segmentation in place — you must test that it works at least every six months and document the results. The testing must cover all segmentation controls and confirm that out-of-scope systems cannot reach the CDE.

In practice, segmentation testing for an AWS environment means:

Verifying no active network path exists from non-CDE VPCs to CDE VPC subnets
Testing after any infrastructure change that could affect network paths
Producing evidence that the test was performed at a specific point in time
Retaining that evidence for QSA review

Many teams interpret this as "run a penetration test twice a year." That satisfies the requirement, but it's expensive and the gap between tests is long. An alternative approach is continuous topology monitoring with logged, signed segmentation test results on every scan.

The Static Documentation Problem

The most common response to QSA evidence requests is a folder of screenshots: the VPC peering list from the console, a route table export, a network diagram from the last architecture review. QSAs accept this — but with growing skepticism.

Screenshots have no chain of custody. A screenshot of a route table taken today does not prove that table was in that state six months ago, or that it hasn't changed in the past week. The AWS console does not timestamp screenshots. The file modification date on a PNG file is not evidence of when the underlying AWS state was captured.

The stale diagram problem: Architecture diagrams go out of date within weeks of an infrastructure change. QSAs know this. They will often ask when the diagram was last validated against the live environment — and the correct answer requires a process, not a document.

What QSAs increasingly want is evidence that is:

Timestamped at the moment of capture from the AWS API
Tamper-evident — ideally signed or checksummed so the content cannot be altered retroactively
Repeatable — produced by a documented, automated process, not manual effort
Linked to a specific topology state — not a generic export but a record of what was connected to what at a specific time

What Netway Provides for PCI-DSS Evidence

Netway runs as a Lambda in your own AWS account and builds a live graph of your VPC topology on every scan — VPCs, peering connections, Transit Gateway attachments, route tables, and the effective paths between them. For PCI-DSS teams, it generates a compliance report that includes:

Evidence Item	How Netway Provides It
Topology diagram	Auto-generated on every scan, exportable as SVG/PNG with scan timestamp embedded
Violation paths	BFS traversal of the topology graph; any path from a non-CDE VPC to the CDE VPC is reported with the exact hop sequence
Point-in-time evidence	Each scan is HMAC-signed with a scan ID and UTC timestamp; the signature covers the full topology snapshot
Change log	Diff between consecutive scans shows exactly which connections appeared or disappeared and when
Control assessment table	Maps each finding to the relevant PCI-DSS requirement (1.3.1, 1.3.2, 11.4.5) for direct inclusion in QSA evidence packages

The HMAC signature on each scan report means a QSA can verify that the report content has not been modified after the scan completed. Combined with the change log, you can demonstrate not just the current state of your CDE isolation but the state at any point in the scan history — which satisfies the 11.4.5 requirement for repeatable, documented segmentation testing.

If you're preparing for an upcoming PCI-DSS assessment and want to understand your current CDE isolation posture before the QSA does, Netway's first scan is free.

Netway maps your full VPC topology, detects isolation breaches, and generates compliance evidence — all from one Lambda in your own AWS account. First scan is free →