Change Control

PCIComplianceHubLast updated

The procedures by which a change to a system or to software is reviewed, tested and approved for its effect before it is made. PCI DSS asks for it on two fronts: changes to network connections and to network security control configurations, and changes to any production system component.

Applies to. Every in-scope system component and every network security control. Both the process (6.5.1, 1.2.2) and the check afterwards (6.5.2) are required.
Example. A firewall rule is opened for a new payment gateway. Under 1.2.2 the change is approved before it is made; under 6.5.1 the record shows the reason, the security impact assessment, the approval, the test, and how to back it out.
Limits. 6.5.1 lists what a change record must contain: reason and description, documented security impact, documented approval by authorised parties, testing that the change does not harm security, and a back-out procedure. A ticket that says 'opened port 443 for vendor' meets none of the five. After a significant change, 6.5.2 requires confirming every applicable requirement still holds on the changed systems, which is where scope creep is meant to be caught.
In PCI DSS v4.0.1. 1.2.2, 6.5.1, 6.5.2