Requirement 1: Install and Maintain Network Security Controls

The most significant evolution is the transition from the narrower 'Install and Maintain a Firewall Configuration to Protect Cardholder Data' in previous versions to the broader 'Install and Maintain Network Security Controls' in 4.0/4.0.1. This change acknowledges that modern security extends beyond traditional firewalls to include cloud security groups, software-defined networking, zero-trust architectures, and other contemporary approaches. The requirement now encompasses all network security controls that restrict unauthorized access regardless of implementation technology. PCI DSS 4.0.1 specifically clarifies the language and guidance around these controls while maintaining the same security objectives as 4.0, with improved consistency in terminology throughout the document. These changes reflect the reality of modern network architectures while ensuring the core security principles remain intact across diverse implementations.

Requirement 1 mandates comprehensive network documentation including current and detailed network diagrams showing all connections to and from the cardholder data environment (CDE). These diagrams must clearly identify all network segments (in-scope and out-of-scope), all ingress and egress points, and all security controls between segments. Documentation must include wireless networks, cloud environments (including provider boundaries), third-party connections, and data flows. Additionally, organizations must maintain a complete inventory of all security services, protocols, and ports allowed through security controls with documented business justification for each. Formal documentation of all firewall and router configurations, security group settings, and access control lists is required, along with change management records. In PCI DSS 4.0.1, the guidance clarifies that this documentation should use standardized terminology and clearly indicate the relationship between different components of the network architecture, providing assessors with a clear understanding of how cardholder data is protected throughout its lifecycle.

Yes, cloud environments absolutely require compliance with Requirement 1, with several specific considerations unique to cloud architectures. Organizations must implement appropriate network security controls for their cloud implementation, including cloud provider security groups, virtual network ACLs, web application firewalls, and API gateways. These controls must enforce the same security principles as traditional environments: default-deny posture, restriction of inbound/outbound traffic, and protection of the cardholder data environment. PCI DSS 4.0.1 clarifies that organizations must document cloud network boundaries, security control configurations, and clearly define the shared responsibility model with their cloud service provider, specifying which security controls are managed by which party. Multi-tenant cloud environments require special attention to ensure proper isolation from other tenants. Organizations must also understand that traditional network concepts may map differently in cloud environments—for instance, security groups functioning as stateful firewalls or subnet boundaries serving as network segmentation controls. Cloud-specific misconfigurations, such as overly permissive security groups or public-facing storage buckets, represent significant risks that must be addressed through specific cloud security processes and regular validation.

Network segmentation is not technically mandatory in PCI DSS 4.0.1, but it is strongly recommended as a best practice for reducing the scope of the PCI DSS assessment. Without proper segmentation, all connected systems would be considered in-scope for PCI DSS, significantly increasing compliance complexity and cost. Requirement 1.4 (introduced in v4.0 and maintained in 4.0.1) specifically addresses the implementation of network segmentation to isolate the cardholder data environment (CDE) from other networks. Organizations must define and document segmentation methods and implement security controls at all boundaries between in-scope and out-of-scope networks. The effectiveness of segmentation must be tested at least annually and after significant changes. PCI DSS 4.0.1 clarifies that segmentation can be implemented through various technologies including physical separation, VLANs with proper ACLs, internal firewalls, security groups in cloud environments, and micro-segmentation in software-defined networks. The guidance emphasizes that organizations should implement segmentation that aligns with their risk assessment and specific environment, with higher-risk environments potentially requiring more robust segmentation controls and more frequent validation.

PCI DSS Requirement 1 mandates that network security controls, including firewall and router rules, must be reviewed at least every six months to ensure they remain effective and aligned with business needs. Additionally, reviews must be conducted after any significant changes to the network architecture or cardholder data environment. These reviews must verify that all rules, particularly security group settings and access control lists, have documented business justification, that authorized services, protocols, and ports are still necessary, and that rules are properly ordered and configured. The review should include validation that default deny-all configurations remain in place and that both inbound and outbound traffic filtering is properly implemented. Organizations must maintain records of these reviews, including who performed them, findings, and any remediation actions. PCI DSS 4.0.1 clarifies that the review process should include a risk-based approach, with more critical rules or environments potentially requiring more frequent reviews. The standard also emphasizes that reviews should include not just traditional firewalls but all network security controls including cloud security groups, web application firewalls, and software-defined networking controls. These regular reviews help prevent control bloat, identify misconfigured or overly permissive rules, and ensure the continued security of the cardholder data environment.

We maintain comprehensive and current network diagrams that clearly identify all connections to and from the cardholder data environment as required by PCI DSS 4.0.1. Our diagrams include detailed representations of network boundaries, all ingress and egress points, DMZ implementations, and connections to wireless networks, cloud environments, and third-party service providers. Each diagram is color-coded to distinguish between in-scope and out-of-scope network segments with clear identification of where network security controls are implemented. We specifically document all security control points, including firewalls, routers with ACLs, cloud security groups, and other filtering mechanisms. The diagrams show data flows with specific annotation for cardholder data transmission paths. For our cloud environments, we clearly delineate provider boundaries and document the shared responsibility model for security controls. We update these diagrams whenever there's a significant change to our network architecture and formally review them at least quarterly to ensure accuracy. All diagrams are version-controlled with change history and accessible to relevant security personnel, with previous versions archived for audit purposes. We can demonstrate how our diagrams align with our asset inventory and data flow documentation to provide complete visibility into our cardholder data environment.

We implement a comprehensive defense-in-depth approach to block unauthorized traffic to and from our cardholder data environment. Our primary controls include stateful inspection firewalls deployed at all network boundaries with a default-deny configuration that explicitly blocks all traffic not specifically permitted by our security policy. All firewall rules require documented business justification, management approval, and are subject to regular review. We implement inbound traffic filtering to restrict connections based on source IP addresses, ports, and protocols, only allowing authorized entities to initiate connections to systems in the CDE. For outbound traffic, we maintain equally strict controls that limit connections to only authorized destinations, preventing data exfiltration and command-and-control activities. For more granular control, we deploy next-generation firewalls with application-level filtering capabilities at critical boundaries, allowing us to enforce policies based on application identity rather than just port and protocol. In our cloud environments, we implement similar protections using security groups, NACLs, and web application firewalls, ensuring consistent security across our hybrid infrastructure. We maintain formal rule management procedures including change control, periodic reviews, and rule lifecycle management to prevent firewall rule bloat. All traffic to and from the CDE is logged and monitored in real-time through our SIEM solution, with automated alerts for suspicious activity and potential policy violations. We conduct regular ruleset reviews every six months and after significant changes, perform vulnerability scans quarterly, and conduct penetration testing annually to validate the effectiveness of our controls. We can demonstrate the results of our most recent reviews and tests to validate our controls are functioning as intended.

Our segmentation validation process follows a comprehensive, multi-layered approach to ensure our cardholder data environment remains properly isolated from other networks. We conduct formal penetration tests specifically focused on segmentation controls at least annually and after any significant changes to segmentation methods or technologies. These tests are performed by qualified internal personnel and supplemented by independent external testers to provide diverse perspectives on segmentation effectiveness. Our testing methodology simulates attacks from multiple vectors, including from outside the CDE, from adjacent network segments, and from different security zones, to verify that segmentation prevents unauthorized access in all scenarios. We maintain specific test cases for each segmentation boundary and technology in use, including physical separation, VLANs, firewalls, security groups, and micro-segmentation controls. Our testing includes both authenticated and unauthenticated attempts to bypass segmentation controls. We supplement these annual tests with quarterly internal vulnerability scans and network traffic analysis to identify any potential segmentation issues or unauthorized communication paths. Our continuous monitoring tools provide real-time visibility into traffic patterns and alert us to any unexpected communication attempts across segment boundaries. We maintain a detailed segmentation control matrix documenting all segmentation technologies in use, their configurations, expected traffic patterns, and validation results. All test results are thoroughly documented with screenshots and technical evidence, with any findings immediately remediated according to their risk level and retested to confirm resolution. The entire process is governed by formal procedures subject to regular review and improvement. We can provide documentation of our most recent segmentation validation results, including the methodology used, findings identified, remediation performed, and confirmation of successful retesting.