PCI DSS 6.5.1: Changes to all system components in the production environment are made according
PCI DSS v4.0.1 control 6.5.1: the requirement in full, the 2 testing procedures an assessor uses to verify it, and the related controls in section 6.5.
Requirement 6: Develop and Maintain Secure Systems and Software › Section 6.5
Changes to all system components in the production environment are made according to established procedures that include:
- Reason for, and description of, the change.
- Documentation of security impact.
- Documented change approval by authorized parties.
- Testing to verify that the change does not adversely impact system security.
- For bespoke and custom software changes, all updates are tested for compliance with Requirement 6.2.4 before being deployed into production.
- Procedures to address failures and return to a secure state.
Summary
Every change to production follows a written procedure that records why, assesses the security impact, is approved by someone authorised, and is tested.
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 | |
|---|---|
| 6.5.1.a | Examine documented change control procedures to verify procedures are defined for changes to all system components in the production environment to include all elements specified in this requirement. |
| 6.5.1.b | Examine recent changes to system components and trace those changes back to related change control documentation. For each change examined, verify the change is implemented in accordance with all elements specified in this requirement. |
The control most other controls quietly depend on: script inventories, configuration standards, network rules and scope all drift through changes that skipped a process. Five named elements, and documentation of security impact is the one entities most often lack: a change record with a reason and an approval but no impact assessment meets four of five and fails. 6.5.1.a examines the procedures, 6.5.1.b examines recent changes against them, so this is tested on real change records rather than on the policy.
What to prepare
- The change control procedure covering all five elements.
- Recent change records, which is what 6.5.1.b samples, each showing reason, impact, approval and testing.
- Evidence of who is authorised to approve, and that they are not the person who made the change.
- For bespoke and custom software, evidence changes were tested against the Requirement 6 controls.
How to implement it
1. Put the four fields in the template. Reason, security impact, approver, test result. A form that cannot be submitted without them produces the evidence as a by-product, which is far more reliable than asking people to remember.
2. Make "security impact" a question, not a checkbox. "Does this change what is exposed, who can reach it, or what data it touches?" answered in a sentence is enough, and it is what an assessor reads.
3. Cover emergency changes. They are still changes; the process may be retrospective but the record cannot be absent, and this is where sampling under 6.5.1.b usually finds the gap.
4. Include infrastructure and configuration. A firewall rule and a deployment pipeline setting are changes to system components in production, and they are frequently outside whatever tracks application releases.
Where this commonly fails
- Application deploys under change control while infrastructure changes are made directly.
- Approval recorded as the deployer themselves, so nobody independent approved anything.
- The security impact field present but filled with "none" by default.
- Emergency changes with no retrospective record, which sampling finds first.
Related controls
This control refers to 6.2.4.
Others in section 6.5:
| Control | What it requires |
|---|---|
| 6.5.2 | Upon completion of a significant change, all applicable PCI DSS requirements are confirmed… |
| 6.5.3 | Pre-production environments are separated from production environments and the separation… |
| 6.5.4 | Roles and functions are separated between production and pre-production environments to provide… |
| 6.5.5 | Live PANs are not used in pre-production environments… |
| 6.5.6 | Test data and test accounts are removed from system components before the system goes into… |
← 6.4.3 · All controls · 6.5.2 →
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.