Requirement 1 Is Where Every PCI Assessment Begins -- and Where Many Go Wrong
Requirement 1 is the foundation of PCI DSS. It has been part of the standard since the original version, but v4.0 introduced a significant philosophical shift: the rename from "Install and Maintain a Firewall Configuration to Protect Cardholder Data" to "Install and Maintain Network Security Controls."
This is not just a semantic change. It reflects the reality that network security in modern environments extends far beyond traditional firewalls. Cloud security groups, micro-segmentation platforms, software-defined networking, container network policies, and zero-trust architectures all fall under the Network Security Controls (NSC) umbrella. Your QSA is now evaluating all of these technologies against Requirement 1, not just your firewall rules.
We test Requirement 1 controls in every PCI DSS penetration testing engagement, and the findings follow consistent patterns. Overly permissive rules, stale configurations, undocumented changes, and cloud environments with security group sprawl are the issues that surface repeatedly.
The v4.0 shift in thinking: PCI DSS v4.0 no longer asks "do you have firewalls?" It asks "do you have controls that govern network traffic between all segments relevant to your CDE?" This broader question catches organizations that have solid perimeter firewalls but weak internal controls, undocumented cloud security groups, or container environments with no network policies.
What Changed from v3.2.1 to v4.0
Understanding the specific changes helps you identify where your existing compliance posture may have gaps under the new standard.
| Aspect | v3.2.1 | v4.0 |
|---|---|---|
| Terminology | Firewalls and routers | Network Security Controls (NSCs) -- encompasses all network traffic control technologies |
| Scope | Focused on perimeter firewalls and internal segmentation | Includes cloud security groups, micro-segmentation, SDN, WAFs when used as NSCs, and container network policies |
| Rule review | Review firewall and router rule sets at least every six months (1.1.7) | Review NSC configurations at least every six months (1.2.7) with explicit requirement to confirm rules are still relevant |
| Documentation | Network diagram and cardholder data flow diagram required | Same diagrams required, plus explicit documentation of all NSCs including their role and business justification for allowed traffic |
| Inbound traffic | Restrict inbound traffic to that which is necessary | Same principle, plus explicit requirement for anti-spoofing measures and more granular control documentation |
| Outbound traffic | Restrict outbound traffic from the CDE | Outbound traffic restrictions explicitly required with documented business justification for each allowed flow |
| Wireless | Separate requirement for wireless security | Wireless integrated into NSC requirements; wireless traffic treated the same as any other network traffic |
Key takeaway: If your Requirement 1 compliance was built around traditional firewall management, you likely have gaps under v4.0. Cloud environments, container platforms, and software-defined networks introduce NSCs that were not explicitly covered in v3.2.1. Your assessor will evaluate all of these under Requirement 1.
Requirement 1 Sub-Requirements: What Assessors Actually Check
1.1 -- Processes and Mechanisms for NSCs Are Defined and Understood
This is the governance layer. You must have documented policies and procedures that describe how NSCs are managed across your environment. The documentation must cover NSC configuration standards, change management procedures for NSC rules, roles and responsibilities for NSC management, and review schedules.
Your QSA will ask to see these documents and will verify that personnel responsible for NSC management are aware of and follow them. A policy document that exists but is not followed is worse than no policy document, because it demonstrates a control failure rather than a control gap.
1.2 -- NSCs Are Configured and Maintained
This is where the technical controls live. Requirement 1.2 covers the actual configuration of your NSCs, including both inbound and outbound traffic restrictions.
1.2.1 -- NSC Rulesets: All inbound and outbound traffic must be restricted to that which is necessary for the cardholder data environment. Every rule in your NSC configuration must have a documented business justification. "Allow all" rules between network segments are a finding. Rules that permit traffic to or from the CDE must specify source, destination, port, and protocol with the minimum scope necessary.
1.2.5 -- Permitted Services, Protocols, and Ports: All services, protocols, and ports allowed through NSCs must be identified, approved, and documented. Each allowed flow must have a defined business need. Insecure services and protocols must be identified with additional security features documented.
| Protocol/Service | Risk Level | PCI Requirement |
|---|---|---|
| FTP (port 21) | High -- cleartext credentials and data | Must be replaced with SFTP/FTPS or have documented compensating controls |
| Telnet (port 23) | Critical -- cleartext authentication | Must be replaced with SSH. No compensating control is acceptable |
| HTTP (port 80) | High for CDE traffic | Must redirect to HTTPS for any traffic involving cardholder data |
| RDP (port 3389) | High -- frequent attack vector | Must not be exposed to the internet. Internal use requires NLA, MFA, and documented justification |
| SMB (port 445) | High -- lateral movement vector | Must be restricted to necessary systems only. Cross-segment SMB traffic is a finding |
| DNS (port 53) | Medium -- potential exfiltration channel | Outbound DNS from CDE should be restricted to internal DNS servers only |
1.2.7 -- Six-Month Rule Review
NSC configurations must be reviewed at least every six months. This review must confirm that rules are still relevant, that no unauthorized rules have been added, that rules are correctly ordered (for firewalls where order matters), and that the documentation matches the actual configuration.
The six-month review is one of the most frequently failed requirements. Organizations set calendar reminders, conduct the first review, and then miss subsequent reviews due to operational priorities. Your QSA will ask for evidence of the last two reviews at minimum, and gaps indicate a process failure.
1.2.8 -- Configuration File Security
NSC configuration files must be secured from unauthorized access and kept consistent with the active running configuration. A firewall whose running configuration differs from its saved configuration indicates either unauthorized changes or a configuration management failure. Both are findings.
Traffic Restrictions: Inbound, Outbound, and Between Zones
1.3.1 -- Inbound Traffic Restriction
Inbound traffic to the CDE must be restricted to only that which is necessary. NSCs must be configured to deny all inbound traffic by default and allow only explicitly authorized connections. This is the default-deny principle applied at the network level.
1.3.2 -- Outbound Traffic Restriction
Outbound traffic from the CDE must also be restricted to only that which is necessary. This is where many organizations fail because they focus on inbound restrictions but leave outbound traffic unrestricted. An attacker who compromises a CDE system and can freely communicate outbound has no difficulty exfiltrating cardholder data.
Assessment reality: Your QSA will review both inbound and outbound rules and ask for business justification for every allowed flow. "We need outbound HTTPS" is not sufficient. "Outbound HTTPS to payment processor API endpoints at 203.0.113.0/24 for transaction authorization" is the level of specificity expected. Overly broad outbound rules are one of the top five Requirement 1 findings.
1.3.3 -- Anti-Spoofing
NSCs must implement anti-spoofing measures to detect and block forged source IP addresses. This typically means enabling BCP38/BCP84 ingress filtering, configuring reverse path forwarding checks, or implementing equivalent controls at the NSC level.
1.4 -- Trusted and Untrusted Network Boundaries
NSCs must be implemented between all trusted and untrusted networks. The CDE is a trusted network. The internet is an untrusted network. Your corporate network, depending on your architecture, may be trusted or untrusted relative to the CDE. Every boundary between trust zones must have NSC controls.
Inbound traffic from untrusted networks to the CDE must pass through a DMZ or equivalent buffered zone. Direct internet-to-CDE connectivity is not permitted. Your public-facing web servers should be in a DMZ, with the CDE sitting behind a second NSC layer.
1.5 -- Dual-Homed Devices
Systems that connect to both the CDE and untrusted networks -- such as laptops used by administrators who work remotely -- must have personal firewalls or equivalent endpoint NSCs that are active and cannot be disabled by the user. Your QSA will check that these controls are enforced, not just deployed.
Network Segmentation and Requirement 1
Network segmentation is not required by PCI DSS, but it is so strongly recommended that nearly every organization implements it. Without segmentation, every system on every network connected to any system that handles cardholder data is in scope. With proper segmentation, only the systems in the CDE and those directly connected to it are in scope. For a detailed guide on segmentation strategies, see our PCI DSS scope reduction guide.
Segmentation is implemented through NSCs, which makes Requirement 1 the foundation for scope reduction. If your segmentation controls fail, your scope expands to include every system on your network.
Segmentation Validation
Segmentation penetration testing must be performed at least annually for merchants and at least every six months for service providers. This testing validates that the NSC rules enforcing segmentation are effective and cannot be bypassed. Testing must verify that systems outside the CDE cannot access systems inside the CDE through any path, including through connected systems.
Common Segmentation Failures
- Flat VLANs with no inter-VLAN filtering. Systems are on different VLANs but the VLANs can communicate freely. VLANs alone are not segmentation without NSC rules restricting traffic between them.
- Management network bypass. The CDE is segmented from the corporate network, but the management network has unrestricted access to both. An attacker who compromises a management workstation can reach the CDE.
- Shared services in multiple zones. A DNS server, SIEM, or monitoring system sits in one zone but serves both the CDE and non-CDE systems. This shared service creates a connected-systems path between zones.
- Cloud VPC misconfiguration. Security groups are configured correctly, but VPC peering or transit gateway routes allow traffic flows that bypass the security groups.
- Jump server with excessive access. A bastion host used for CDE access also has connectivity to non-CDE systems, creating a bridge between segments.
Cloud NSC Considerations
Cloud environments introduce NSC types that do not exist in traditional data centers. PCI DSS v4.0's technology-agnostic approach to NSCs means all of these are evaluated under Requirement 1.
| Cloud NSC Type | Function | PCI Considerations |
|---|---|---|
| Security Groups | Instance-level stateful firewall (AWS, Azure NSG, GCP firewall rules) | Must follow least privilege, documented business justification for each rule, reviewed every six months. Default "allow all outbound" must be restricted. |
| Network ACLs | Subnet-level stateless firewall (AWS NACLs) | Provides defense in depth alongside security groups. Must be documented and reviewed. Stateless nature requires explicit inbound and outbound rules. |
| VPC/VNet Firewalls | Cloud-native firewall services (AWS Network Firewall, Azure Firewall, GCP Cloud NGFW) | Full NSC capabilities including stateful inspection, IPS, and logging. Must be configured with documented rule sets and reviewed every six months. |
| Container Network Policies | Kubernetes NetworkPolicy, service mesh policies | Controls traffic between pods/services. Must enforce CDE segmentation at the container level. Default deny with explicit allow rules. |
| VPC Peering/Transit Gateway | Inter-VPC connectivity | Creates network paths between environments. Must be documented, justified, and filtered by security groups or firewalls at each end. |
Cloud-Specific Challenges
- Security group sprawl. Cloud environments accumulate security groups over time. Rules are added for troubleshooting and never removed. Port ranges are broadened to fix connectivity issues and never narrowed. The six-month review must audit all security groups, not just the ones your team remembers creating.
- Infrastructure as Code drift. Your Terraform or CloudFormation templates define the intended NSC configuration, but manual changes through the console create drift. Your actual configuration may not match your documented configuration, which is a Requirement 1.2.8 finding.
- Shared responsibility model. The cloud provider manages the underlying network infrastructure, but you are responsible for configuring security groups, NACLs, and firewall rules correctly. Your QSA will evaluate what you control, not what the provider manages.
- Ephemeral resources. Auto-scaling groups, serverless functions, and container orchestration create and destroy resources dynamically. Your NSC controls must account for these ephemeral resources and ensure they inherit the correct security group and network policy configurations automatically.
Documentation Requirements That Assessors Verify
Requirement 1 has some of the most extensive documentation requirements in the entire standard. Missing or inaccurate documentation is a finding even if your technical controls are correctly configured.
Network Diagram
Your network diagram must show all connections between the CDE and other networks, all system components within the CDE, all NSCs including firewalls, routers, security groups, and any other network traffic control devices, and all wireless access points. The diagram must be current and accurate. QSAs will compare the diagram against actual network configurations and flag discrepancies.
Cardholder Data Flow Diagram
Separate from the network diagram, the data flow diagram must show how cardholder data enters your environment, where it is processed, where it is stored, and how it exits your environment. This diagram is the foundation for accurate scoping and directly informs which NSC rules are necessary. If you have implemented tokenization, the data flow diagram should clearly show where PAN is replaced by tokens.
NSC Rule Documentation
Every rule in every NSC must be documented with the business justification for the rule, the source and destination (by IP range, subnet, or security group), the ports and protocols allowed, the person who approved the rule, and the date it was last reviewed. This documentation must be updated whenever rules change and reviewed every six months.
Common Requirement 1 Assessment Failures
Based on our penetration testing and compliance support engagements, these are the Requirement 1 findings that appear most frequently.
- Overly permissive rules. "Allow any-any" rules between network segments, typically left from initial deployment or troubleshooting sessions. Every rule must restrict traffic to the minimum necessary.
- Missing outbound restrictions. Inbound traffic is restricted but outbound traffic from the CDE is unrestricted. Outbound rules must limit traffic to authorized destinations and ports.
- Stale rules. Rules for decommissioned systems, former employees' VPN access, or temporary exceptions that became permanent. The six-month review should identify and remove these.
- Documentation gaps. NSC rules exist but have no documented business justification. The network diagram does not reflect the current environment. Data flow diagrams are missing or outdated.
- No six-month review evidence. The organization cannot provide evidence that NSC configurations were reviewed in the past six months. This is a process failure that results in a finding regardless of technical configuration quality.
- Default credentials on NSC devices. Firewall management interfaces accessible with default or weak credentials. Administrative access to NSCs must use unique credentials with strong authentication.
- Insecure management protocols. NSC management interfaces accessible via HTTP or Telnet instead of HTTPS or SSH. Management traffic must be encrypted.
- Missing anti-spoofing controls. No ingress filtering or reverse path forwarding checks configured on perimeter NSCs.
The Six-Month Rule Review Process That Passes Assessment
The six-month rule review is a defined process, not a casual review. Here is the approach that consistently satisfies QSAs.
Step 1: Export Current Configurations
Pull the running configuration from every NSC in scope. For cloud environments, export security group rules, NACL rules, and firewall policies. For physical appliances, export the running configuration. Compare these against the previously documented configurations to identify any changes since the last review.
Step 2: Validate Each Rule
For every rule in every NSC, verify that the rule is still needed (the business justification is still valid), the source and destination are correct and as narrow as possible, the ports and protocols are the minimum necessary, and the rule owner is still with the organization and in the relevant role.
Step 3: Identify and Remediate Issues
Remove rules that are no longer needed. Tighten rules that are overly permissive. Update documentation for rules that have changed. Flag rules that need further investigation and assign owners with deadlines.
Step 4: Document the Review
Create a review record that includes the date, the reviewer, the NSCs reviewed, the findings identified, the remediation actions taken, and sign-off from the responsible manager. This record is the evidence your QSA will ask for.
- All NSC configurations exported and compared against documentation
- Every rule validated for continued business necessity
- Unused or stale rules removed with documentation
- Overly permissive rules tightened to least-privilege
- Network diagram updated to reflect current state
- Data flow diagram verified against actual traffic patterns
- Review record created with findings, actions, and sign-off
- Next review date scheduled (no more than six months from this review)
Integrating Requirement 1 with Other PCI DSS Requirements
Requirement 1 does not exist in isolation. NSC management is closely tied to several other requirements, and assessors evaluate these connections.
- Requirement 7 (Access Control) -- Administrative access to NSCs must follow the principle of least privilege. Only personnel with a documented business need should have the ability to modify NSC configurations.
- Requirement 8 (Authentication) -- All access to NSC management interfaces must use unique credentials with strong authentication, including MFA for remote access.
- Requirement 10 (Logging and Monitoring) -- Changes to NSC configurations must be logged, and those logs must be monitored for unauthorized changes. Your monitoring program should include alerts for NSC rule modifications.
- Requirement 11 (Testing) -- NSC effectiveness must be validated through vulnerability scanning and penetration testing. Segmentation testing specifically validates that NSC rules properly isolate the CDE.
- Requirement 12 (Policies) -- Your information security policy must cover NSC management procedures, and personnel must be aware of their responsibilities.
Organizations that treat Requirement 1 as a standalone firewall management exercise miss these integration points. Your evidence collection should capture artifacts that demonstrate compliance across these connected requirements.
Lorikeet Security's ASM platform ($29.99/mo - $299/mo) provides continuous attack surface monitoring that identifies exposed services, open ports, and misconfigurations that would result in Requirement 1 findings -- before your assessor finds them.
Need Help with PCI DSS Requirement 1 Compliance?
Lorikeet Security's Offensive Security Bundle ($37,500/yr) includes PCI DSS penetration testing and segmentation testing that validates your NSC controls. Our Compliance Package ($42,500/yr) covers full PCI DSS readiness and documentation support.
