PCI-DSS Requirement 1.3: Network Segmentation Evidence That Actually Satisfies a QSA

Most engineering teams approaching a PCI-DSS audit understand that network segmentation is required. Fewer understand what a Qualified Security Assessor actually needs to see to sign off on it.

The gap between "we have segmentation controls in place" and "we can prove those controls are working continuously" is where audits get delayed, findings get issued, and remediation timelines get extended.

This post covers what PCI-DSS Requirement 1.3 specifically demands, what evidence actually satisfies a QSA, and how to generate that evidence automatically in AWS.

---

What Requirement 1.3 Actually Says

PCI-DSS v4.0 Requirement 1.3 governs network access controls to and from the cardholder data environment (CDE). The key sub-requirements engineering teams need to address:

Requirement	What it demands
1.3.1	Inbound traffic to the CDE is restricted to only that which is necessary. All other traffic is denied.
1.3.2	Outbound traffic from the CDE is restricted to only that which is necessary. All other traffic is denied.
1.4.1	Network security controls are implemented between trusted and untrusted networks.
11.4.5	If network segmentation is used to isolate the CDE, penetration testing is performed to verify that the segmentation methods are operational and effective.

The word "verify" in 11.4.5 is the one most teams underestimate. Configuring segmentation controls is not the same as verifying they are operational. Your QSA needs evidence that the isolation was tested — and in the case of a continuous compliance posture, that it is tested on an ongoing basis.

---

What QSAs Actually Ask For

---

The 6-Month Verification Requirement

PCI-DSS v4.0 Requirement 11.4.5 requires that segmentation testing is performed at least once every six months and after any significant change in the segmentation controls. In practice, "significant change" is interpreted broadly — any new VPC, peering connection, TGW attachment, or route table modification qualifies.

In a typical AWS environment with active development, changes happen weekly or more frequently. A six-month verification cadence means you either test constantly or accept coverage gaps between tests.

The practical implication: annual pen testing does not meet the six-month requirement. Teams that relied on annual penetration tests under PCI-DSS v3.2.1 will need to increase verification frequency or adopt automated continuous verification under v4.0.

---

How Segmentation Actually Breaks in AWS

The three most common ways PCI segmentation fails in AWS environments — none of which generate alerts from standard AWS tooling:

1. VPC Peering That Bypasses Transit Gateway

Your Transit Gateway route tables may correctly isolate the CDE VPC from staging and development. But if someone creates a direct VPC peering connection between a non-CDE VPC and the CDE VPC, that peering completely bypasses TGW routing. The isolation that TGW was supposed to enforce is irrelevant — the peering is a direct routing-plane path.

This is the most common isolation finding Netway detects. TGW route tables look correct. Security teams believe isolation is enforced. The peering is invisible unless you specifically scan for cross-environment peerings.

2. Shared Services VPC Scope Creep

Shared services VPCs — hosting internal tools, logging infrastructure, build systems — are typically connected to multiple environment VPCs including the CDE. If a non-CDE VPC gains connectivity to the shared services VPC through a new peering or TGW attachment, and the shared services VPC already has a path to the CDE, you now have an indirect path: non-CDE → shared-services → CDE.

This indirect path is harder to detect than a direct peering because neither connection looks suspicious individually.

3. Route Table Propagation Errors

TGW propagation automatically adds routes to TGW route tables based on VPC attachments. If a CDE attachment is associated with the wrong propagation group, routes to the CDE CIDR can appear in route tables that should never see them. Traffic may not flow immediately, but the routing-plane path exists and will be flagged by a thorough QSA review.

---

AWS-Specific Evidence: CLI Commands

Before investing in automation, teams often start by generating evidence manually with the AWS CLI. These commands produce output that can be included in evidence packages for your QSA:

Export all VPC peering connections (scan for cross-environment paths)

# List all active peering connections with requester/accepter VPC info
aws ec2 describe-vpc-peering-connections \
  --filters Name=status-code,Values=active \
  --query 'VpcPeeringConnections[*].{
    PeeringId:VpcPeeringConnectionId,
    RequesterVpc:RequesterVpcInfo.VpcId,
    RequesterCidr:RequesterVpcInfo.CidrBlock,
    AccepterVpc:AccepterVpcInfo.VpcId,
    AccepterCidr:AccepterVpcInfo.CidrBlock
  }' \
  --output table

Export route tables that include CDE CIDR ranges

# Find any route table with a route to your CDE CIDR
# Replace 10.1.0.0/16 with your CDE VPC CIDR
aws ec2 describe-route-tables \
  --query 'RouteTables[?Routes[?DestinationCidrBlock==`10.1.0.0/16`]].{
    RT:RouteTableId,
    VPC:VpcId,
    Routes:Routes[?DestinationCidrBlock==`10.1.0.0/16`]
  }' \
  --output json

Export TGW route tables for all attachments

# List all TGW route tables and their routes
TGW_ID=tgw-0abc123
for RT_ID in $(aws ec2 describe-transit-gateway-route-tables \
    --filters Name=transit-gateway-id,Values=$TGW_ID \
    --query 'TransitGatewayRouteTables[*].TransitGatewayRouteTableId' \
    --output text); do
  echo "=== $RT_ID ==="
  aws ec2 search-transit-gateway-routes \
    --transit-gateway-route-table-id $RT_ID \
    --filters Name=state,Values=active \
    --query 'Routes[*].{Dest:DestinationCidrBlock,Target:TransitGatewayAttachments[0].ResourceId}'
done

Confirm no path exists via Network Reachability Analyzer

# Create a path analysis from staging to CDE (should return NOT-REACHABLE)
aws ec2 create-network-insights-path \
  --source eni-staging-instance \
  --destination eni-cde-instance \
  --protocol TCP

# Run the analysis and capture for evidence
aws ec2 start-network-insights-analysis \
  --network-insights-path-id nip-0abc123

# Retrieve the result (NetworkPathFound should be false)
aws ec2 describe-network-insights-analyses \
  --network-insights-analysis-ids nia-0abc123 \
  --query 'NetworkInsightsAnalyses[*].[NetworkInsightsAnalysisId,Status,NetworkPathFound]'

These CLI outputs can be saved as JSON files, timestamped, and included in your evidence package. For a QSA, the timestamp and the source (AWS API) make these more credible than manually drawn diagrams.

---

Defining CDE Scope in AWS

Before you can demonstrate segmentation, you need a clear definition of which VPCs and subnets are in CDE scope. In AWS, this is more complex than in on-prem environments because scope can expand unexpectedly:

• VPCs that touch the CDE: Any VPC with a direct routing path to a CDE VPC is potentially in scope as a "connected-to CDE" system — even if it doesn't process cardholder data itself.
• Shared services VPCs: If your shared services VPC has access to the CDE, the entire shared services VPC is a candidate for scope expansion. This is often the largest source of audit scope creep.
• Bastion hosts and jump boxes: Any EC2 instance that can SSH into CDE-scoped systems is a connected-to-CDE system, even if it sits in a non-CDE subnet.
• AWS services used by CDE workloads: S3 buckets storing cardholder data, RDS instances with customer records, KMS keys used for CHD encryption — all of these expand scope and the routing paths to them matter.

A common mistake is scoping the CDE as "the production VPC" and leaving everything else out of scope. A QSA will map traffic flows from the network diagrams and identify connected systems that belong in scope. Getting the scope definition right before the audit is critical.

---

Security Groups vs NACLs vs Route Tables: What Counts as Segmentation?

PCI-DSS is not prescriptive about which AWS mechanism you use for segmentation, but the quality of your evidence depends on which layer you're operating at:

Mechanism	Level	Provides segmentation?	Evidence strength
Route tables	Network / Layer 3	Yes — no route = no path	Strong. Routing-plane proof.
NACLs	Subnet / Layer 3-4	Yes — stateless deny rules	Moderate. Rules can be overridden by routing.
Security groups	Host / Layer 4	Partial — host-level only	Weak as standalone isolation evidence. A route still exists even if SG denies it.
TGW route tables	Network / Layer 3	Yes — controls TGW routing	Strong, but only if peering connections are also scanned.
VPC peering absence	Network / Layer 3	Implicit isolation	Strong — proving no peering exists is routing-plane proof.

The strongest segmentation posture relies on routing-plane controls (route tables and TGW) as the primary mechanism, with security groups as defense-in-depth. Evidence should prove isolation at the routing plane — not just at the host level.

---

The Static Documentation Problem

AWS networks change continuously. New VPCs get created. Peering connections get added. Transit Gateway attachments change. Route tables get modified.

A network diagram produced six months ago and a pen test performed three months ago may both have been accurate at the time. Neither tells your QSA what the network looks like today.

PCI-DSS v4.0 introduced more explicit requirements around continuous monitoring precisely because the static-documentation approach was failing in dynamic cloud environments. A QSA who understands cloud environments will probe whether your segmentation evidence is current. If your answer is "the diagram is updated annually" or "we run pen tests once a year," you are describing a compliance posture with gaps of up to twelve months.

---

Policy vs Routing-Plane Evidence

The strongest segmentation evidence is routing-plane proof — a record showing that at the network routing layer, no path exists from out-of-scope environments to CDE-scoped resources. This is distinct from weaker forms of evidence that describe intent rather than reality:

---

How Netway Generates This Evidence

Netway's compliance module is built around exactly this requirement. On every scan:

---

What the Report Contains

The Netway compliance report is structured around the specific evidence requirements in PCI-DSS v4.0:

---

Getting Started