PCI DSS Requirement 1: network security controls
By Sam Rivera, Founder, SentinelPanda · August 6, 2026 · 3 min read · PCI DSS
v4.0 stopped saying "firewall" and started saying "network security control" — a deliberate change that finally lets cloud security groups count as what they always were.
Why the name changed
PCI DSS v3.2.1 talked about firewalls and routers, which made assessments awkward for anyone running in a public cloud where the enforcement point is a security group, a network ACL, or a service mesh policy rather than an appliance. v4.0 replaced the language with "network security controls" — a technology-neutral term covering any mechanism that controls network traffic between segments.
The substance did not change: you still control what reaches the cardholder data environment. But the vocabulary shift means you no longer have to argue that your VPC security groups are morally equivalent to a firewall. They are an NSC, and the requirement addresses them directly.
The documentation assessors ask for first
- A current network diagram showing all connections into and out of the CDE (1.2.3).
- A cardholder data flow diagram showing how account data moves through and between systems (1.2.4). This is the one most often missing or years out of date.
- Documented business justification for every service, protocol, and port allowed (1.2.5).
- Evidence that NSC rulesets are reviewed at least once every six months (1.2.7).
Restriction and default-deny
Requirement 1.3 restricts inbound and outbound traffic to and from the CDE to only what is necessary — everything else is denied. Outbound is the half teams forget. It is common to find a tightly controlled inbound ruleset alongside an entirely open egress policy, which is exactly the path data exfiltration takes.
Requirement 1.4 governs connections between trusted and untrusted networks, including the rule that system components storing cardholder data must not be directly reachable from untrusted networks. Anti-spoofing measures (1.4.3) block forged source IP addresses from entering the network.
Segmentation is optional — and almost always worth it
Nothing in Requirement 1 forces you to segment. You may run a flat network and put your entire estate in scope. Nobody does this deliberately twice.
Segmentation is the single most effective lever on assessment cost, because it determines how much of your infrastructure the other eleven requirements apply to. If you segment, you must prove it works: segmentation penetration testing at least annually for merchants, and every six months for service providers.
Common findings
- Data flow diagrams that describe an architecture two migrations out of date.
- Six-monthly ruleset reviews performed but never evidenced — no record of who reviewed, when, or what changed.
- Overly broad rules ("allow 10.0.0.0/8") with a business justification written as "internal traffic".
- Unrestricted outbound access from CDE systems to the internet.
- Cloud security groups managed in Terraform with no review process, on the assumption that infrastructure-as-code is self-documenting. It is not — the review is a separate control.