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
Network diagrams
Showing the CDE boundary, all connections into and out of the CDE, and all systems in scope.
Data flow diagrams
Showing how cardholder data moves across the network — which systems touch it and over which paths.
Firewall and routing rule documentation
Showing that inbound and outbound rules restrict traffic to only what is necessary, with justification for each permitted flow.
Evidence of segmentation testing
Typically penetration test results or equivalent automated verification showing that paths from out-of-scope environments into the CDE do not exist at the routing plane.
Change log
Evidence that any changes to network controls were reviewed, approved, and logged — and that changes did not introduce new paths into the CDE.
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:
Policy documentation
"Our policy says staging cannot connect to production." Describes intent. Does not verify the network enforces it.
Routing-plane proof
A record showing that no route exists at the network layer from staging to the CDE — verified by traversing actual route tables.
Security group rules
Host-level controls that don't verify routing plane isolation. A peering with open routes bypasses security groups at the routing layer.
Continuous daily scan log
A timestamped, immutable record showing the isolation was verified on every scan day — with the full path traced on any day a breach was detected.
Annual pen test results
Point-in-time verification. Accurate at the time of testing. Does not tell your QSA what the network looks like today or what changed between tests.
Signed compliance report
HMAC-signed PDF covering a date range — network diagram, isolation verdicts, change log, and anomaly log — that your QSA can verify has not been modified.
How Netway Generates This Evidence
Netway's compliance module is built around exactly this requirement. On every scan:
Topology collection
Netway maps all VPCs, peerings, TGW attachments, route tables, and IGWs across your configured accounts and regions.
Environment group assignment
VPCs are tagged with environment groups — production, staging, development, cde — using your existing VPC tags.
Isolation rule evaluation
For each rule you define (e.g. "production must not connect to staging"), Netway performs a BFS traversal of the network graph to determine whether any routing-plane path exists between the two groups.
Immutable result log
Each evaluation produces a PASS or FAIL result, stored with a timestamp that cannot be altered after the fact. This is your continuous compliance history.
On-demand compliance report
A signed PDF covering any date range within your retention window — generated from the dashboard with one click and handed directly to your QSA.
What the Report Contains
The Netway compliance report is structured around the specific evidence requirements in PCI-DSS v4.0:
Control assessment
Every PCI-DSS and SOC2 control Netway covers, evaluated automatically against the scan results — with a clear verdict for each.
Network diagram
Auto-generated from the live topology snapshot — VPCs, TGW, peerings, IGWs — with environment group boundaries marked.
Data flow summary
Top traffic flows by volume from VPC flow log analysis, showing which systems are communicating and over which network paths.
Isolation verification
Per-rule isolation verdicts with daily PASS/FAIL history for the full report period. For any FAIL: the exact network path traced, with VPC IDs, peering or TGW attachment IDs, and timestamps.
Topology change log
All topology changes detected in the period — new VPCs, new peerings, route table changes — with flags for which changes triggered isolation rule re-evaluations.
Anomaly and alert log
All findings and alerts generated in the period, with timestamps and severity levels.
Scope boundary statement
An explicit list of PCI-DSS and SOC2 requirements that are not covered by Netway — so there is no ambiguity about what complementary tooling is needed.
Getting Started
Register at netway.basavytix.com
Run the CloudFormation deploy command shown in your dashboard
Run the scan
In the Compliance tab, assign your VPCs to environment groups and define your isolation rules
When you need the report, click Download from the Compliance tab — hand it directly to your QSA