GRCWatch
Sign inStart free trial

PCI DSS 6.5.4: Separate Roles Between Production and Pre-Production

PCI DSS 6.5.4 requires strict separation of roles between production and pre-production environments to prevent unreviewed changes from reaching live systems. This control ensures that only approved, tested modifications can be deployed to production, reducing the risk of introducing vulnerabilities or misconfigured payment systems. Proper role segregation is foundational to secure change management.

What this means

This control mandates that users and administrators have distinct roles with limited access across production and pre-production environments. Production environments—where customer payment data flows—must be protected from casual modifications, while pre-production serves as a testing ground for changes. Role separation prevents a single person from both making changes and deploying them without review, eliminating the risk of unauthorized or untested code reaching live systems.

How to comply

  1. 1.Define distinct roles for pre-production (development, testing) and production (deployment, support) environments
  2. 2.Implement access controls ensuring developers cannot directly modify production systems
  3. 3.Require change management approval workflows before any production deployment
  4. 4.Document all role assignments and enforce principle of least privilege
  5. 5.Conduct regular access reviews to ensure role separation is maintained
  6. 6.Use technical controls (separate credentials, network isolation) to enforce role boundaries
  7. 7.Train personnel on the requirement and consequences of role overlap

Evidence auditors look for

  • Role-based access control (RBAC) policies documenting production vs. pre-production responsibilities
  • Access control matrix showing which users can modify pre-production vs. deploy to production
  • Change management logs demonstrating separate requestor and approver roles
  • Network segmentation diagrams showing isolation between production and pre-production
  • Quarterly access reviews confirming no single user has both development and production deployment rights
  • Identity and access management (IAM) system configurations enforcing role boundaries
  • Audit logs showing that deployments required separate approval step

Frequently asked questions

When will FAQs be available?

The FAQ for this control is currently being prepared.

GRCWatch automates role separation enforcement by mapping user access across environments, flagging privilege overlaps in real-time, and generating audit reports proving role segregation—eliminating manual access reviews.

See how GRCWatch handles this control automatically

Start free trial

Related controls

PCI DSS 6.5.1 — Change ControlPCI DSS 6.5.2 — Review of Configuration ChangesPCI DSS 7.1 — Restrict Access to Cardholder DataPCI DSS 8.1 — User ID Assignment