NSC Change Control Process

PCI DSS Requirement 1.2.2 mandates that organizations handling payment card data apply rigorous change control to their network infrastructure. This requirement directly links to your existing change control process defined under Requirement 6.5.1, ensuring that network security controls receive the same scrutiny as application code changes.

Network security controls include firewalls, routers, switches, intrusion detection systems, and any device that enforces network segmentation or access control. Every modification to these systems — whether adding a firewall rule, updating router ACLs, or changing VLAN configurations — must follow your formal change control process.

The requirement exists because unauthorized or poorly planned network changes represent one of the most common paths to data breaches. A single misconfigured firewall rule can expose cardholder data environments to the internet. By enforcing change control at the network layer, you create accountability, maintain configuration integrity, and preserve your ability to investigate incidents.

Regulatory text

PCI DSS v4.0.1 Requirement 1.2.2 states: "All changes to network connections and to configurations of NSCs are approved and managed in accordance with the change control process defined at Requirement 6.5.1."

This requirement extends your existing change control framework to encompass all network infrastructure modifications. The linkage to Requirement 6.5.1 is deliberate — it ensures organizations don't create separate, potentially weaker processes for network changes versus application changes.

Who This Applies To

This requirement applies to all entities that store, process, or transmit cardholder data, including:

• Level 1-4 merchants
• Service providers of all sizes
• Payment processors and gateways
• Third-party service providers with network connectivity to CDE

The requirement covers any person or system making changes to:

• Firewall rules and policies
• Router and switch configurations
• Load balancer settings
• IDS/IPS rules
• Network segmentation controls
• VPN configurations
• Any device that controls network traffic flow

Step-by-Step Implementation

1. Inventory Your Network Security Controls

Document all devices that control network traffic in or around your cardholder data environment (CDE):

• Perimeter firewalls
• Internal segmentation firewalls
• Routers and layer 3 switches
• Web application firewalls
• Load balancers
• VPN concentrators
• Software-defined networking controllers

2. Extend Your 6.5.1 Process

Your existing Requirement 6.5.1 change control process must explicitly include network changes. Update your procedures to:

• Add network device types to the scope statement
• Include network engineers in the approval workflow
• Define network-specific testing requirements
• Establish network-specific rollback procedures

3. Define Change Categories

Not all network changes carry equal risk. Establish categories such as:

• Critical: Changes affecting CDE isolation (new firewall rules, VLAN modifications)
• Major: Changes to network topology or routing
• Minor: Updates to non-CDE network segments
• Emergency: Break-fix changes requiring expedited approval

4. Implement Pre-Change Requirements

Before any network change:

• Document the business justification
• Perform risk assessment for CDE impact
• Create detailed implementation steps
• Define success criteria and test cases
• Document rollback procedures
• Obtain required approvals per your change matrix

5. Testing and Validation

Network changes require specific testing approaches:

• Validate connectivity requirements are met
• Confirm no unintended access is granted
• Test from multiple source points
• Verify logging still functions
• Confirm monitoring alerts trigger appropriately
• Document all test results

6. Post-Implementation Tasks

After implementing network changes:

• Update network diagrams and data flow diagrams
• Update configuration baselines
• Verify backups capture new configurations
• Confirm change tickets are closed with evidence
• Schedule post-implementation review for major changes

Required Evidence and Artifacts

Maintain these records for each network change:

• Change request form with business justification
• Risk assessment documentation
• Approval records (emails, signatures, or system logs)
• Test plans and test results
• Implementation checklist with timestamps
• Configuration files (before and after)
• Updated network diagrams
• Rollback execution logs (if performed)
• Post-implementation review notes

Common Audit Questions and Hangups

Auditors typically focus on these areas:

"Show me your last five firewall rule changes" Have change tickets readily available with all supporting documentation. Auditors will trace from request through implementation.

"How do you ensure emergency changes follow the process?" Document your emergency change process, including retroactive approval requirements and compensating controls.

"What prevents unauthorized changes?" Demonstrate technical controls (change detection, configuration backups) and procedural controls (approval workflows, segregation of duties).

"How do you validate changes don't impact PCI compliance?" Show your risk assessment template specifically addresses CDE impact and segmentation validation.

Common audit failures include:

• Missing approval documentation
• Network diagrams not updated after changes
• Emergency changes lacking retroactive documentation
• Test evidence not retained
• Changes made directly in production without following process

Implementation Mistakes to Avoid

Mistake 1: Creating a Separate Network Change Process The requirement specifically mandates using your 6.5.1 process. Don't create a parallel process — extend your existing one.

Mistake 2: Informal Approvals "Bob said it was OK" doesn't count. Every approval needs documented evidence that meets your defined approval matrix.

Mistake 3: Skipping Documentation for "Minor" Changes Every change that could affect traffic flow to/from the CDE requires full documentation. That includes "trivial" firewall rule updates.

Mistake 4: Not Testing Rollback Procedures Having a rollback plan isn't enough. You must validate it works, especially for complex changes involving multiple devices.

Mistake 5: Treating Vendor Changes Differently When third parties manage your network devices, their changes must still follow your change control process. Include this in contracts.

Risk and Enforcement Context

While PCI DSS fines are contractual rather than regulatory, the payment brands can impose penalties ranging from a material amount to a material amount per month for non-compliance. Network security control failures often trigger the highest penalties because they directly enable breaches.

Beyond fines, inadequate network change control creates operational risks:

• Service outages from untested changes
• Security gaps from misconfigured rules
• Compliance gaps that compound during incident response
• Inability to determine root cause during investigations

30/60/90-Day Execution Plan

Immediate Actions (Days 1-30)

• Assess current state: Review your 6.5.1 process and identify gaps for network coverage
• Inventory all NSCs in and around your CDE
• Document any network changes made in the past a defined days retroactively
• Identify all personnel who can make network changes
• Implement configuration backups for all NSCs

Near-Term Improvements (Days 31-60)

• Update change control procedures to explicitly include network changes
• Create network-specific change request templates
• Define approval matrix based on change risk levels
• Establish network change testing protocols
• Train network team on updated procedures
• Implement change detection alerting on critical NSCs

Ongoing Maturity (Days 61-90)

• Perform mock audit of recent network changes
• Refine process based on findings
• Integrate network changes into your CAB (Change Advisory Board) meetings
• Establish monthly reporting on network change metrics
• Create dashboards showing change control compliance
• Schedule quarterly review of the process effectiveness

Frequently Asked Questions

Do simple firewall rule additions require the full change control process?

Yes. Any modification that could affect traffic flow to or from the CDE requires full change control documentation, regardless of perceived simplicity.

How do we handle emergency changes when systems are down?

Execute your emergency change procedures, which should include expedited approval and mandatory retroactive documentation within 24-a defined hours.

What if our firewall vendor makes changes during maintenance windows?

Vendor-initiated changes must still follow your change control process. Include these requirements in your vendor contracts and ensure they submit change requests in advance.

Do changes to non-production environments require the same rigor?

If the non-production environment contains live cardholder data or connects to the production CDE, yes. Otherwise, you may use a simplified process, but document the scope clearly.

How long must we retain network change documentation?

PCI DSS requires retention in accordance with Requirement 12.10.7, which typically means one year minimum. However, retain major network architecture changes indefinitely.

Can automated changes bypass the approval process?

Automated changes (like dynamic firewall rules) need pre-approval of the automation logic itself. The automation must log all changes for review.