PCI DSS Requirement 1 Guide: Network Security Controls, Rule Reviews and CDE Boundaries

PCI DSS Requirement 1 decides whether the cardholder data environment has a real boundary, and most findings against it come from rulesets nobody can explain rather than from missing firewalls. Version 4 replaced "firewalls and routers" with network security controls (NSCs), a term that covers cloud security groups, virtual firewalls and other policy enforcement points as well as appliances. This guide works through the 19 sub-requirements in Requirement 1 of PCI DSS v4.0.1, turns them into a ruleset standard, a six-monthly review, and the evidence an assessor will sample, and shows where NSC administration and service accounts pull in identity controls. It is for network and cloud engineers, PCI programme owners and internal assessors. Scoping and segmentation testing are covered separately in the PCI DSS Scoping and Network Segmentation Guide; this guide goes deeper on the controls themselves.

Source note: this page summarises the official text and the sources listed at the end. Confirm against the official text before relying on it.

Key takeaways

• NSC is a function, not a box. The PCI SSC glossary defines NSCs as firewalls and other network security technologies that act as network policy enforcement points, so cloud security groups, network ACLs and virtual firewalls that separate segments are in scope of Requirement 1.
• Every allowed port needs a reason. Requirement 1.2.5 requires all allowed services, protocols and ports to be identified, approved and to have a defined business need, which makes "any" rules and undocumented exceptions direct findings.
• Six months is the maximum, not the target. Requirement 1.2.7 requires NSC configurations to be reviewed at least once every six months to confirm they are relevant and effective.
• Outbound matters as much as inbound. Requirements 1.3.1 and 1.3.2 restrict both inbound and outbound CDE traffic to what is necessary; unrestricted egress is how stolen card data and credentials leave.
• Dual-connected devices are boundary crossings. Requirement 1.5.1 requires controls on any device, company or employee owned, that connects to both untrusted networks and the CDE, with settings users cannot change unless authorised case by case for a limited period.

How Requirement 1 is structured

Requirement 1, "Install and Maintain Network Security Controls", has five sections. PCI DSS v4.0.1 was published on 11 June 2024 as a limited revision that added and removed no requirements, and v4.0 retired on 31 December 2024, according to the PCI SSC. The requirement titles below follow v4.0.1.

1.2: building a ruleset standard that survives review

Requirement 1.2.1 asks for configuration standards for NSC rulesets that are defined, implemented and maintained. The standard is what makes the six-monthly review in 1.2.7 fast, because each rule can be tested against it.

• Default deny: every NSC ends with an explicit deny, and every permit is specific in source, destination and port. This is the NIST SP 800-53 SC-7(5) "deny by default, allow by exception" pattern.
• Rule metadata: each rule carries an owner, a business justification, a change ticket reference and a review or expiry date. This is how 1.2.5 (defined business need) is evidenced.
• Change control: 1.2.2 requires changes to network connections and NSC configurations to be approved and managed through the change control process at Requirement 6.5.1. Emergency changes still need a retrospective ticket.
• Diagrams: 1.2.3 requires an accurate network diagram showing all connections between the CDE and other networks, including wireless; 1.2.4 requires an accurate data-flow diagram. Generate them from configuration where possible so they do not drift.
• Insecure services: 1.2.6 requires security features to be defined and implemented for any services, protocols and ports in use that are considered insecure, so that the risk is mitigated. Typical candidates are cleartext management protocols such as Telnet, FTP and older SNMP versions; the best fix is replacement, the fallback is a compensating feature recorded against the rule.
• Configuration files: 1.2.8 requires NSC configuration files to be secured from unauthorised access and kept consistent with active configurations, so the running configuration and the stored or startup configuration must match, and stored copies need access control.

The rule review itself is covered step by step in the Firewall Rule Review Checklist, and day-to-day operations in the Firewall Management Guide.

1.3 and 1.4: CDE boundaries, inbound and outbound

Misconfigured boundary controls are a recurring breach cause. In the Capital One breach, a misconfigured web application firewall was abused to reach cloud role credentials, which shows why the review must cover what an NSC itself is allowed to reach, not only what it filters. Attack techniques worth testing these rules against include Exploit Public-Facing Application (MITRE ATT&CK T1190), External Remote Services (T1133) and Network Boundary Bridging (T1599).

1.5: devices that straddle the boundary

Requirement 1.5.1 applies to any computing device, company or employee owned, that connects to both untrusted networks, including the internet, and the CDE. It requires specific configuration settings defined to prevent threats being introduced into the entity's network, security controls actively running, and security controls not alterable by users unless specifically documented and authorised by management case by case for a limited period. Laptops of administrators who reach the CDE through a VPN or jump host are the usual population. Enforce host firewall and endpoint protection through central management with tamper protection, and record every time-limited exception. See the Host-Based Firewall Guide.

Where identity fits

NSCs are administered by people and by machines. Firewall management platforms, infrastructure as code pipelines and cloud automation hold API keys, service accounts and roles that can rewrite rulesets, so they can undo Requirement 1 in seconds. Treat them as privileged: individual named accounts for administrators under Requirement 8, least privilege under Requirement 7, multi-factor authentication for administrative access into the CDE, and vaulted, rotated credentials for automation. The NSC itself can also become a pivot if its own identity has broad cloud permissions, as the Capital One case showed. See the PCI DSS Requirements for Service Accounts and NHIs Guide (8.6) and the PCI DSS Requirement 7 Guide.

Preparing the evidence pack

Assessors test Requirement 1 by examining documents, sampling configurations and interviewing staff. Preparing the pack in advance shortens fieldwork and exposes gaps while there is still time to fix them. The list below is NHI Mgmt Group's suggested structure, not a PCI SSC template.

• Policy and roles (1.1.1, 1.1.2): the network security policy and operating procedures with version and approval dates, plus a responsibility matrix naming who builds, approves, reviews and monitors NSCs. Staff should be able to describe their part without reading it.
• NSC inventory: every enforcement point with location, owner, management method (console, manager, code) and whether it sits on a CDE boundary. Include cloud accounts and subscriptions by name.
• Configuration samples: current exports of a sample of rulesets, ready to compare with the standard and the services and ports register. Keep the export date and the tool used, so the assessor can see the export reflects the running configuration.
• Change records (1.2.2): a sample of change tickets matched to configuration differences in the period, including at least one emergency change with its retrospective approval.
• Review records (1.2.7): the last two reviews per NSC, each with the rules examined, findings, decisions and closure dates. A review with no findings in a large ruleset invites a closer look.
• Traffic evidence (1.3, 1.4): flow log or scan results that show denied traffic is in fact denied, external scan results for 1.4.4 and 1.4.5, and the anti-spoofing configuration for 1.4.3.
• Dual-connected devices (1.5.1): the endpoint baseline, proof that tamper protection is enforced centrally, and the exception register with approver and expiry.

Service providers should also be ready to show which NSCs they manage on behalf of customers and how that split is recorded. See the PCI DSS for Service Providers and Responsibility Matrix Guide.

Decision guidance

Large estates should automate the 1.2.7 review with a policy analysis tool that flags shadowed, unused and overly permissive rules; small estates can export rules quarterly and review them manually against the standard. Either way the reviewer should not be the person who wrote the rules.

Implementing Requirement 1 in phases

1. Map: confirm scope, then build or regenerate the network diagram (1.2.3) and data-flow diagram (1.2.4) from configuration and flow logs.
2. Standardise: write the ruleset standard (1.2.1), the approved services and ports register (1.2.5) and the insecure services list with mitigations (1.2.6).
3. Baseline: export every NSC ruleset, tag each rule with owner and justification, and list rules that have none.
4. Tighten in audit mode: where the platform supports it, log rather than block on candidate deny rules for two to four weeks, check flow logs for legitimate traffic, then enforce.
5. Enforce and test: apply changes through change control (1.2.2), keeping the previous configuration as a rollback point; verify with internal and external scans and the segmentation tests in Requirement 11.
6. Operate: run the review at least every six months (1.2.7), compare running and stored configurations (1.2.8), and record 1.5.1 exceptions with expiry dates.

Detection and measurement

Log NSC configuration changes, administrative logins and denied traffic to and from the CDE, and alert on changes outside approved windows. Requirement 10 sets the logging rules; see the PCI DSS Requirement 10 Guide.

• Justified rules: percentage of permit rules with an owner, business need and current review date (target 100 percent).
• Review timeliness: days since last completed review per NSC (must stay at or below six months).
• Permissive rules: count of rules with "any" in source, destination or service touching the CDE.
• Unauthorised changes: NSC changes without a matching change ticket (target zero).
• Configuration drift: NSCs whose running and stored configurations differ.
• Egress exceptions: outbound destinations allowed from the CDE, trended over time.

Framework mapping

Common failure patterns

• Rules without owners: legacy permits nobody will remove because nobody knows what breaks, failing 1.2.5.
• Review as a signature: a six-monthly sign-off with no rule-level findings, which an assessor will test by sampling rules.
• Cloud left out: security groups managed by application teams and never included in the NSC inventory or review.
• Open egress: strict inbound rules with unrestricted outbound access, ignoring 1.3.2.
• Diagram drift: diagrams drawn once for the assessment that no longer match the running network.
• Over-privileged automation: pipeline or tool credentials that can change any rule, outside change control.

Practitioner checklist

• Inventory every NSC, including cloud security groups, network ACLs and virtual firewalls touching the CDE.
• Publish a ruleset standard with default deny and required rule metadata.
• Maintain the approved services and ports register with business need and owner.
• Replace or mitigate insecure protocols and record the mitigation.
• Restrict outbound CDE traffic to named destinations.
• Place NSCs between every wireless network and the CDE.
• Review every NSC at least every six months, with rule-level findings tracked to closure.
• Compare running and stored configurations and restrict access to configuration files.
• Enforce tamper-protected controls on dual-connected devices and time-limit exceptions.
• Put NSC administration and automation identities under Requirements 7 and 8.

Standards and references

• PCI SSC: Document Library (PCI DSS v4.0.1)
• PCI SSC: Glossary, Network Security Controls
• PCI SSC: Just Published, PCI DSS v4.0.1
• PCI SSC: FAQ, What is meant by adequate network segmentation
• NIST: SP 800-53 Rev. 5
• NIST: Cybersecurity Framework 2.0
• MITRE ATT&CK: Network Boundary Bridging

Related NHI Mgmt Group resources: PCI DSS 4.0 Guide · PCI DSS Scoping and Network Segmentation Guide · Firewall Rule Review Checklist · Cloud Network Security Guide. This guide summarises Requirement 1 of PCI DSS v4.0.1 and is not legal advice.