Network Security Control (NSC)
PCIComplianceHubLast updated
The PCI DSS v4.x term for any technology that enforces network policy between segments, replacing the v3.2.1 wording "firewalls and routers". It covers traditional firewalls but also cloud security groups, virtual network appliances and container network policy, which is the point of the change: Requirement 1 applies to whatever enforces the policy, not only to a physical appliance.
Applies to. Requirement 1 is written around NSCs. 1.4.1 puts them between trusted and untrusted networks, 1.3.1 and 1.3.2 use them to restrict traffic into and out of the CDE, and 1.3.3 requires one between any wireless network and the CDE. The device or service that does the filtering then carries the housekeeping duties too: a documented ruleset standard (1.2.1), change control on configuration changes (1.2.2), a review of the configuration at least every six months (1.2.7) and protected configuration files that match what is actually running (1.2.8).
Example. A merchant runs its card-processing servers in a cloud subnet with no firewall appliance at all. What decides which traffic gets in is the subnet's security group plus a network policy on the container cluster. Both are NSCs: each allowed port needs a recorded business need under 1.2.5, the rules need a written standard under 1.2.1, and someone has to review them at least every six months under 1.2.7 and remove whatever is no longer justified.
Limits. An NSC is defined by what it does, not what it is called. A switch or router that forwards everything is not an NSC; the same router with access lists that deny traffic is. The term does not cover intrusion detection or prevention, which 11.5.1 handles separately as monitoring of traffic rather than enforcement of policy. Nor does an NSC prove segmentation by its presence: a firewall between the CDE and the office network only segments if its rules actually deny the traffic, which is what 1.3.1 and 1.3.2 test.