PCI DSS 1.2.2: All changes to network connections and to configurations of NSCs are approved and managed
PCI DSS v4.0.1 control 1.2.2: the requirement in full, the 3 testing procedures an assessor uses to verify it, and the related controls in section 1.2.
Requirement 1: Install and Maintain Network Security Controls › Section 1.2
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.
Summary
Changes to network connections and to the configuration of your network security controls go through the same change control process as everything else.
What the assessor will examine
These are the testing procedures the standard defines for this control. They tell you what evidence to have ready.
| Procedure | |
|---|---|
| 1.2.2.a | Examine documented procedures to verify that changes to network connections and configurations of NSCs are included in the formal change control process in accordance with Requirement 6.5.1. |
| 1.2.2.b | Examine network configuration settings to identify changes made to network connections. Interview responsible personnel and examine change control records to verify that identified changes to network connections were approved and managed in accordance with Requirement 6.5.1. |
| 1.2.2.c | Examine network configuration settings to identify changes made to configurations of NSCs. Interview responsible personnel and examine change control records to verify that identified changes to configurations of NSCs were approved and managed in accordance with Requirement 6.5.1. |
Requirement 1 borrowing Requirement 6's process: the control points directly at 6.5.1, so a network change needs the reason, the security impact assessment, the authorised approval and the testing that 6.5.1 requires. What makes this control harder than it reads is the direction the assessor works in. Procedures 1.2.2.b and 1.2.2.c say to examine the network configuration to identify changes made, then go and find the change record for them. They pick the change; you produce the paperwork. A tidy sample of approved tickets proves nothing if the device shows a rule nobody can account for.
What to prepare
- The change control procedure, showing network connections and NSC configuration explicitly in scope.
- Change records for the period, findable by device and by date rather than only by ticket number.
- Current configurations for the NSCs, and the previous version to compare against.
- The emergency change path, and the records it produced.
How to implement it
1. Make the configuration diffable. The assessor identifies changes from the configuration itself, so being able to show what changed and when is what turns this from an argument into a lookup. Version-controlled configuration or a configuration-management tool gives you that for free.
2. Bring the cloud security groups in. Security groups, network ACLs and firewall rules in a cloud console are NSC configuration changes. If they are made through infrastructure as code, say in the procedure that the merged pull request is the change record, so the evidence you already generate counts.
3. Give emergency changes a retrospective record with a deadline. Firewall rules opened during an incident are the changes most likely to have no ticket, and they are also the ones most likely to be left in place.
4. Do not run a separate network change process. The control names 6.5.1. A network team process that is good but parallel fails 1.2.2.a on the wording.
Where this commonly fails
- Rules on the device that nobody can tie to a change record, which is exactly what 1.2.2.b looks for.
- Emergency changes made verbally during an incident and never documented afterwards.
- Cloud network changes treated as configuration rather than as change, so they bypass the process entirely.
- A change process that records the approval and not the security impact assessment, which is a 6.5.1 element this control inherits.
Related controls
This control refers to 6.5.1.
Others in section 1.2:
| Control | What it requires |
|---|---|
| 1.2.1 | Configuration standards for NSC rulesets… |
| 1.2.3 | An accurate network diagram(s) is maintained that shows all connections between the CDE… |
| 1.2.4 | An accurate data-flow diagram(s) is maintained that meets… |
| 1.2.5 | All services, protocols, and ports allowed are identified, approved… |
| 1.2.6 | Security features are defined and implemented for all services, protocols… |
| 1.2.7 | Configurations of NSCs are reviewed at least once every six months to confirm they are relevant… |
| 1.2.8 | Configuration files for NSCs… |
← 1.2.1 · All controls · 1.2.3 →
Source
The requirement text and testing procedures above are reproduced from PCI DSS v4.0.1 (June 2024), ©2006-2024 PCI Security Standards Council, LLC. All rights reserved. The commentary is our own.
The official standard is authoritative and also contains the Customized Approach Objective, applicability notes and guidance for this control. Download it from the PCI Security Standards Council document library. PCI DSS is a registered standard of the PCI Security Standards Council, LLC, which does not endorse this site. Nothing here is a substitute for advice from a Qualified Security Assessor.