PCI DSS 6.5.3: Pre-production environments are separated from production environments and the separation
PCI DSS v4.0.1 control 6.5.3: the requirement in full, the 3 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
Pre-production environments are separated from production environments and the separation is enforced with access controls.
Summary
Pre-production and production are separate environments, and access controls enforce the separation.
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.3.a | Examine policies and procedures to verify that processes are defined for separating the pre-production environment from the production environment via access controls that enforce the separation. |
| 6.5.3.b | Examine network documentation and configurations of network security controls to verify that the pre-production environment is separate from the production environment(s). |
| 6.5.3.c | Examine access control settings to verify that access controls are in place to enforce separation between the pre-production and production environment(s). |
Two things, tested by three procedures: the separation must exist in the network (6.5.3.b examines network documentation and NSC configurations) and be enforced with access controls (6.5.3.c examines access control settings). Both halves are needed, and the second is where cloud environments most often fall short: separate accounts or subscriptions give clean network separation while a single identity provider grants the same people the same rights in both, so the environments are separate and the access is not. Note the direction of risk that makes this matter. Pre-production is built to be permissive, and it usually contains a copy of something production has, which is also why 6.5.5 exists.
What to prepare
- Network documentation showing the separation.
- NSC configuration enforcing it.
- Access control settings for both environments, showing they differ.
- The documented policy behind it, which 6.5.3.a examines.
How to implement it
1. Separate the identity, not just the network. Distinct roles and distinct grants per environment are what 6.5.3.c examines, and they are the half a cloud account split does not give you.
2. Check the connections between them. Deployment pipelines and shared services cross the boundary by design, and they are where separation quietly becomes a permitted path.
3. Treat shared tooling carefully. A monitoring or CI system with access to both is a bridge, and it needs to be a deliberate one.
4. Write the policy down. The first procedure examines it separately from the implementation.
Where this commonly fails
- Separate networks with identical access rights in both.
- A pipeline with standing production credentials, crossing the boundary continuously.
- Shared services that reach both environments without anyone deciding they should.
- Separation implemented and never documented, which fails 6.5.3.a.
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.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.5.2 · All controls · 6.5.4 →
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.