Requirement 1: Install and Maintain Network Security Controls

Requirement 1 is about controlling what can reach the cardholder data environment, and proving that the controls are configured deliberately rather than inherited from a default.

PCI DSS v4.0.1 breaks this requirement into 5 sections containing 19 individual controls.

What this requirement is actually asking

v4.0.1 talks about network security controls (NSCs), not "firewalls and routers". The wording changed because the control is now met by security groups, cloud firewalls, service meshes and host-based rules just as legitimately as by an appliance. If your environment is cloud-hosted, your NSCs are your security groups and network ACLs.

The heart of it is 1.3: traffic into and out of the CDE is restricted to what is necessary, and everything else is denied. Most of the remaining controls exist to prove that restriction is real, documented and reviewed, not simply asserted.

Does it apply to you?

Applies to every entity. If you have outsourced your entire CDE, you still need evidence that your provider meets it and that your own connections into their environment are controlled.

The controls

Requirement 1 contains 19 controls across 5 sections. Each links to its own page with the requirement in full and the testing procedures an assessor uses to verify it.

1.1: Governance: the policies and role assignments behind everything else in Requirement 1

Control	What it requires	Guidance
1.1.1	All security policies and operational procedures that are identified in Requirement 1…	Yes
1.1.2	Roles and responsibilities for performing activities in Requirement 1 are documented, assigned…	Yes

1.2: Configuration standards for NSCs, change control, and keeping the network diagram current

Control	What it requires	Guidance
1.2.1	Configuration standards for NSC rulesets…	Yes
1.2.2	All changes to network connections and to configurations of NSCs are approved and managed…	Yes
1.2.3	An accurate network diagram(s) is maintained that shows all connections between the CDE…	Yes
1.2.4	An accurate data-flow diagram(s) is maintained that meets…	Yes
1.2.5	All services, protocols, and ports allowed are identified, approved…	Yes
1.2.6	Security features are defined and implemented for all services, protocols…	Yes
1.2.7	Configurations of NSCs are reviewed at least once every six months to confirm they are relevant…	Yes
1.2.8	Configuration files for NSCs…	Yes

1.3: The core rule. Restricting inbound and outbound CDE traffic to what is necessary

Control	What it requires	Guidance
1.3.1	Inbound traffic to the CDE is restricted…	Yes
1.3.2	Outbound traffic from the CDE is restricted…	Yes
1.3.3	NSCs are installed between all wireless networks and the CDE…	Yes

1.4: Connections between trusted and untrusted networks, including anti-spoofing and DMZ placement

Control	What it requires	Guidance
1.4.1	NSCs are implemented between trusted and untrusted networks	Yes
1.4.2	Inbound traffic from untrusted networks to trusted networks is restricted…	Yes
1.4.3	Anti-spoofing measures are implemented to detect and block forged source IP addresses…	Yes
1.4.4	System components that store cardholder data are not directly accessible from untrusted networks	Yes
1.4.5	The disclosure of internal IP addresses and routing information is limited to only authorized…	Yes

1.5: Devices that touch both an untrusted network and the CDE, typically staff laptops

Control	What it requires	Guidance
1.5.1	Security controls are implemented on any computing devices…	Yes

Evidence your assessor will ask for

• A current network and data-flow diagram, dated within the last 12 months, showing every CDE ingress and egress
• NSC rule sets exported as configuration, with a business justification recorded per rule
• Change tickets for NSC rule changes, showing approval before the change
• Evidence that rule sets were reviewed at least every six months (1.2.7)

Where this commonly fails

• A network diagram that was accurate at the last assessment and has not been touched since. Assessors check it against live configuration
• "Allow any" egress rules from the CDE. Outbound is assessed as strictly as inbound and is the more common finding
• Cloud environments where security groups are managed in Terraform but the reviewed evidence is a console screenshot that no longer matches

Official source

This page is original commentary. It cites requirement identifiers and the official requirement title, and does not reproduce the text of the standard. For the authoritative wording, including each testing procedure and the customized approach objective, download PCI DSS v4.0.1 (June 2024) from the PCI Security Standards Council document library.

PCI DSS is a registered standard of the PCI Security Standards Council, LLC, which does not endorse this site.