Requirement 1.2.1: Establishing Secure Standards for Network Security Controls

Requirement 1.2.1 emphasizes the importance of standardization and consistency. The PCI DSS mandates that organizations establish documented configuration standards for network security control (NSC) rulesets and ensure these standards are implemented and maintained throughout the environment. This approach aims to prevent inconsistent configurations of network security devices, which may create security vulnerabilities and elevate the risk of unauthorized access to the Cardholder Data Environment (CDE).

To achieve compliance with this requirement, organizations must document the expected configurations for network security controls, specifying acceptable protocols, approved ports, traffic restrictions, and other relevant security parameters. These documented standards should guide the configuration of network security devices and be reviewed regularly to ensure continued effectiveness and alignment with organizational objectives.

During an assessment, organizations are expected to provide documented configuration standards and demonstrate that network security controls have been configured in accordance with these standards. 

Requirement Information

Parent Requirement 1.2

Network security controls (NSCs) are configured and maintained.

PCI DSS Requirement 1.2.1

Configuration standards for NSC rulesets are:

• Defined.
• Implemented.
• Maintained.

Priority: 2

Priority Meaning: Protect systems and networks and be prepared to respond to a system breach. This milestone targets controls for points of access to most compromises and the response processes.

Requirement 1.2.1 mandates that organizations establish, implement, and maintain configuration standards for network security control rulesets. These standards specify baseline security expectations for devices and services that manage network traffic.

Consistent configuration is essential for the effectiveness of network security controls. In the absence of documented standards, administrators may implement varying security practices, which can lead to unnecessary exposure, inconsistent controls, and heightened compliance risk.

Organizations must determine permitted and prohibited activities within their environment and configure network security controls to enforce these requirements. 

Why This Requirement Exists

Network security controls are fundamental mechanisms for safeguarding cardholder data. These controls regulate traffic between trusted and untrusted networks, manage communication between systems, and enforce segmentation of sensitive environments.

In the absence of established configuration standards, administrators may implement subjective configurations that introduce security vulnerabilities. Over time, network security rules may become excessively permissive, challenging to manage, and misaligned with organizational security objectives.

Requirement 1.2.1 ensures that security configurations are intentional, consistent, and aligned with management expectations. Defining configuration standards enables organizations to establish a repeatable framework for implementing and managing network security controls.

Applicability of the Self-Assessment Questionnaire (SAQ)

PCI DSS Requirement 1.2.1 is included in the following Self-Assessment Questionnaires (SAQs):

SAQ D (Merchant)

Applicable to: Merchants that do not qualify for any other SAQ type or have a more complex cardholder data environment requiring a full assessment.

Why this requirement appears: Organizations completing SAQ D are expected to establish and manage network security controls using documented security standards.

SAQ D (Service Provider)

Applicable to: Service providers that store, process, transmit, or could affect the security of cardholder data on behalf of other organizations.

Why this requirement appears: Service providers frequently manage complex network environments and are expected to maintain formal standards governing network security control configurations. 

Scope

Requirement 1.2.1 pertains to network security controls designed to protect the Cardholder Data Environment as well as systems that may affect the security of cardholder data.

PCI DSS requirements are applicable to the Cardholder Data Environment (CDE), which consists of the following:

• System components, personnel, and processes that store, process, or transmit cardholder data or sensitive authentication data; and
• System components that do not store, process, or transmit cardholder data or sensitive authentication data but have unrestricted connectivity to systems that perform these functions.

Additionally, PCI DSS requirements extend to:

• System components, personnel, and processes that may affect the security of cardholder data or sensitive authentication data.

Definition: Network Security Control (NSC)

A technology that manages, filters, inspects, or restricts network traffic based on configured rules.

Examples include firewalls, routers using access control lists (ACLs), cloud security groups, and cloud virtual networks.

Definition: Ruleset

A ruleset is a collection of rules, policies, and configuration settings employed by a network security control to permit, deny, inspect, or restrict network traffic.

For example, a firewall configuration may allow HTTPS traffic to a payment application while blocking all other inbound traffic. 

Understanding the Requirement

Requirement 1.2.1 encompasses three primary expectations.

Configuration Standards Must Be Defined

Organizations are required to establish documented standards that specify the configuration of network security controls. These standards typically specify the following:

• Approved protocols
• Approved ports
• Permitted services
• Traffic filtering requirements
• Inbound and outbound restrictions
• Logging requirements
• Rule documentation expectations

The standards must clearly differentiate between acceptable and prohibited configurations.

Configuration Standards Must Be Implemented

Documented standards must be actively enforced rather than existing only as written policies.

Organizations are expected to verify that network security controls are configured in accordance with the documented standards.

Assessors typically compare documented standards with actual device configurations to determine whether implementation aligns with established expectations.

Configuration Standards Must Be Maintained

Standards must evolve in response to changes in technology, business requirements, and emerging threats.

Organizations are required to periodically review the following:

• Approved services
• Network architectures
• Traffic requirements
• Security technologies
• Business processes

Ongoing maintenance of standards ensures continued alignment with operational requirements and security objectives. 

Additional Technical Details

Configuration standards typically specify baseline requirements across multiple categories of network security controls. Representative examples include the following:

Traditional Firewalls

Relevant standards may specify the following:

• Default-deny requirements
• Rule review requirements
• Logging requirements
• Change approval requirements

Router Access Control Lists (ACLs)

Applicable standards may specify the following:

• Allowed traffic types
• Protocol restrictions
• Documentation requirements

Cloud-Based Network Security Controls

Relevant standards may specify the following:

• Security group requirements
• Network segmentation requirements
• Management access restrictions
• Public exposure limitations

Ways to Meet Requirement 1.2.1

Requirement 1.2.1 may be satisfied through several distinct approaches.

Option 1: Develop Formal Configuration Standards

Create documented standards describing:

• Authorized ports
• Approved protocols
• Default security settings
• Logging requirements
• Network segmentation expectations

This method represents the most widely adopted approach.

Option 2: Incorporate Standards into Existing Security Documentation

Organizations may include network security control standards within:

• Security standards documents
• Firewall standards
• Network security standards
• Infrastructure standards

This approach reduces documentation redundancy while ensuring continued compliance.

Option 3: Use Standardized Configuration Templates

Approved configuration templates may be established to reflect documented standards.

Examples include:

• Firewall baseline templates
• Cloud security group templates
• Router ACL templates

This practice improves consistency across operational environments.

Option 4: Periodic Configuration Reviews

Periodic comparison of actual configurations against documented standards is recommended.This helps identify:

• Configuration drift
• Unauthorized changes
• Legacy rules
• Unnecessary access

Definition: Configuration Drift

Configuration drift refers to the gradual deviation of system configurations from approved standards over time. For example, a firewall rule added during a specific project may remain active after project completion, even though it no longer aligns with organizational standards. 

Compensating Controls and Customized Approaches

Customized Approach ObjectivePCI DSS defines the customized approach objective as:

The way that NSCs are configured and operate are defined and consistently applied.

Organizations implementing a customized approach are required to demonstrate that network security control configurations remain consistent, controlled, and aligned with organizational requirements.

Practical Customized Approach Examples

Potential approaches include the following:

• Automated network security orchestration platforms
• Infrastructure-as-code deployment standards
• Cloud-native policy enforcement platforms
• Automated compliance monitoring systems

Regardless of the chosen implementation method, organizations must demonstrate consistent enforcement of configuration standards.

Compensating Controls

Compensating controls are infrequently used for Requirement 1.2.1, as documented standards are generally attainable for most organizations.

Any compensating control would need to provide equivalent assurance that network security controls are configured consistently and securely.

SMB Considerations

Small and mid-sized organizations can typically satisfy this requirement through straightforward documentation and regular configuration reviews.

A concise network security standard, combined with periodic reviews of firewall and cloud configurations, is generally sufficient to meet the requirement without the need for specialized governance tools. 

Demonstrating Compliance

Organizations must be able to demonstrate that configuration standards are clearly defined, consistently implemented, and regularly maintained.

Baseline Evidence Requirements

Examples include:

• Network security standards
• Firewall standards
• Router configuration standards
• Cloud security standards
• Approved configuration templates
• Configuration review procedures

Enhanced Evidence for Maturity

Organizations with higher maturity levels typically maintain the following:

• Automated configuration compliance reports
• Periodic baseline reviews
• Configuration drift monitoring
• Exception tracking
• Security architecture reviews
• Network security governance records

Frequently Missing Evidence

Assessors frequently identify the following deficiencies:

• Undocumented configuration standards
• Standards that do not match actual configurations
• Outdated requirements
• Inconsistent configurations across devices
• Insufficient documentation of approved protocols and ports
• Missing review evidence

Testing Procedures

PCI DSS Testing Procedure 1.2.1.a

Examine the configuration standards for NSC rulesets to verify the standards are in accordance with all elements specified in this requirement.

Application of the Testing Procedure by Internal Teams

Internal Audit, Compliance, Information Security, and Network Administration teams should review documented standards to determine whether they adequately define the configuration of network security controls.

Key assessment questions include:

• Are configuration standards formally documented?
• Do standards identify approved protocols and ports?
• Do standards specify prohibited or restricted configurations?
• Do standards establish baseline security expectations?
• Have the standards been reviewed and updated as the environment has changed?

This review facilitates the identification of documentation gaps prior to their emergence as audit findings.

Commonly Reviewed Evidence

Relevant examples include:

• Firewall configuration standards
• Network security standards
• Router ACL standards
• Cloud security standards
• Security architecture standards
• Approved configuration templates
• Standards review records

Frequently Identified Issues

Typical findings include:

• Missing configuration standards
• Standards that are overly vague
• Standards that do not define permitted services
• Outdated standards referencing retired technologies
• Incomplete documentation of security requirements

PCI DSS Testing Procedure 1.2.1.b

Examine configuration settings for NSC rulesets to verify that rulesets are implemented according to the configuration standards.

Application of the Testing Procedure by Internal Teams

Internal teams are expected to compare actual configurations with the organization's documented standards.Key assessment questions include:

• Do firewall rules align with documented standards?
• Are only approved ports and protocols enabled?
• Are prohibited services disabled?
• Have exceptions been documented and approved?
• Have configurations drifted from approved baselines?

This review ensures that standards are not only documented but also actively enforced throughout the environment.

Commonly Reviewed Evidence

Relevant examples include:

• Firewall configurations
• Firewall rule reviews
• Router ACL configurations
• Cloud security group configurations
• Network diagrams
• Approved exception records
• Configuration review reports
• Change management records

Frequently Identified Issues

Typical findings include:

• Configurations that differ from documented standards
• Unapproved ports or protocols
• Legacy rules remaining active
• Temporary exceptions becoming permanent
• Inadequate documentation supporting configuration decisions

Common Mistakes

Misidentifying Configurations as Standards

Some organizations incorrectly assume that device configurations constitute the standard. However, PCI DSS requires documented requirements that specify how configurations must be established.

Permitting Configuration Drift

Over time, unvalidated changes may gradually undermine security controls if configurations are not regularly compared to approved standards.

Developing Excessively Broad Standards

Standards that only instruct to "follow security best practices" typically lack the specificity required for consistent and effective implementation.

Omitting Specification of Approved Ports and Protocols

Assessors typically expect standards to explicitly define permitted network traffic and the conditions under which it is allowed.

Neglecting Periodic Review of Existing Rules

Many organizations prioritize new configurations but fail to conduct periodic reviews of existing firewall rules, access control lists (ACLs), or cloud security groups to ensure ongoing necessity and compliance.