PCI DSS 6.5.4: Roles and functions are separated between production and pre-production environments to provide
PCI DSS v4.0.1 control 6.5.4: 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
Roles and functions are separated between production and pre-production environments to provide accountability such that only reviewed and approved changes are deployed.
Summary
The people who build a change are not the people who put it into production, so only reviewed and approved changes get deployed.
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.4.a | Examine policies and procedures to verify that processes are defined for separating roles and functions to provide accountability such that only reviewed and approved changes are deployed. |
| 6.5.4.b | Observe processes and interview personnel to verify implemented controls separate roles and functions and provide accountability such that only reviewed and approved changes are deployed. |
The counterpart to 6.5.3, and the distinction between them is exactly the point: 6.5.3 separates the environments, 6.5.4 separates the people. A developer who can deploy their own code to production defeats this control however cleanly the environments are divided. The stated purpose is accountability, "such that only reviewed and approved changes are deployed", so the separation exists to make the review in 6.2.3 and the approval in 6.5.1 meaningful rather than optional. It is also the control that 6.1.2's responsibility matrix has to demonstrate, which is unusual: most matrices only describe, and this one has to prove a split.
What to prepare
- The documented separation of roles and functions.
- Who can deploy to production, and whether they can also author changes.
- Evidence that deployments carry an approval from someone other than the author.
- The pipeline permissions, if deployment is automated.
How to implement it
1. Let the pipeline deploy, and let nobody else. Automation is the practical way to separate the function without separating the people into two teams, because the pipeline deploys only what was approved.
2. Remove standing production deploy rights from authors. Break-glass access with approval and logging is a different thing from routine capability.
3. Make the approval visible in the deployment record. Accountability is the stated purpose, so tracing a production change back to its approval is what evidences it.
4. Handle emergency changes deliberately. They are where the separation is bypassed, and an undocumented bypass is the finding.
Where this commonly fails
- Developers with production deploy rights, which is the case the control names.
- Environments separated and roles identical, meeting 6.5.3 and failing this.
- A pipeline that anyone can trigger with arbitrary content, which automates the bypass.
- Emergency deployments with no retrospective approval record.
Related controls
Others in section 6.5:
| Control | What it requires |
|---|---|
| 6.5.1 | Changes to all system components in the production environment are made according… |
| 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.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.5.3 · All controls · 6.5.5 →
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.