PCI DSS 6.5.1: Every change to production follows a written procedure that records why, assesses the security impact, is approved by someone authorised, is tested, and has a way back if it fails.
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.
PCIComplianceHubLast updated Last reviewed against PCI DSS v4.0.1
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, is tested, and has a way back if it fails.
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. Six named elements: reason and description, documentation of security impact, documented approval by authorised parties, testing for adverse security impact, testing of bespoke and custom software updates against 6.2.4, and procedures to address failures and return to a secure state. A change record with a reason and an approval but no impact assessment does not meet the requirement. 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 six elements, including how a failed change is returned to a secure state.
- 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 changes. The guidance asks for approvers with the authority and knowledge to understand the impact; someone other than the person who made the change is good practice.
- For bespoke and custom software, evidence each update was tested for compliance with 6.2.4 before it was deployed.
How to implement it
1. Put the elements in the template. Reason, security impact, approver, test result and the back-out procedure. 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 6.5.1.b samples recent changes, which can include emergency ones.
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 by someone the procedure does not authorise, such as a deployer approving their own change.
- 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… |
Terms
Glossary entries that name this control, each with its own example, limits and sources:
← 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.