Separation of Pre-Production and Production

PCI DSS requires you to keep pre-production (dev/test/stage) environments separate from production and enforce that separation with access controls so that non-production users, tools, and data paths cannot reach production systems. Operationally, you must define environment boundaries, segment networks and identities, restrict pipelines, and retain evidence that separation is designed and working. (PCI DSS v4.0.1 Requirement 6.5.3)

Key takeaways:

• Separate networks, identities, and deployment paths between pre-production and production, then prove the separation works. (PCI DSS v4.0.1 Requirement 6.5.3)
• “Separation” is not a diagram; it’s enforced access control plus monitoring and change discipline across people, systems, and pipelines. (PCI DSS v4.0.1 Requirement 6.5.3)
• Your audit package should show boundaries, allowed access, denied access, and periodic validation of controls. (PCI DSS v4.0.1 Requirement 6.5.3)

“Separation of pre-production and production” is a deceptively short requirement that often fails in practice because teams treat it as a naming convention (“prod” vs “stage”) instead of a security boundary. PCI DSS 4.0.1 Requirement 6.5.3 expects a real partition between environments, with access controls that enforce who and what can cross that boundary. (PCI DSS v4.0.1 Requirement 6.5.3)

For a Compliance Officer, CCO, or GRC lead, the fastest route to operationalization is to translate the requirement into three control outcomes you can test: (1) production systems are unreachable from pre-production identities and networks unless explicitly authorized; (2) production changes can only be introduced through controlled mechanisms with production-only permissions; and (3) evidence exists to show the boundary is intentional, documented, and reviewed.

This page gives you requirement-level implementation guidance: scoping, control design options (network, IAM, CI/CD, secrets, and data), evidence to retain, and the audit questions that typically cause findings. Where helpful, it also flags operational tradeoffs and common mistakes that create “accidental bridges” between environments.

Regulatory text

PCI DSS 4.0.1 Requirement 6.5.3: “Pre-production environments are separated from production environments and the separation is enforced with access controls.” (PCI DSS v4.0.1 Requirement 6.5.3)

Operator meaning: you must (a) define what counts as pre-production and production in your environment, (b) implement technical controls that prevent pre-production users/systems from accessing production by default, and (c) be able to demonstrate that enforcement through configurations, access reviews, and testing evidence. (PCI DSS v4.0.1 Requirement 6.5.3)

Plain-English interpretation (what “separation” really means)

Separation means a compromise or mistake in pre-production should not provide a path into production. In practice, assessors look for strong boundaries across:

• Network reachability: pre-production subnets/VPCs cannot route to production subnets/VPCs except through tightly controlled, justified paths.
• Identity and permissions: pre-production accounts (human and machine) cannot authenticate to production; production roles are distinct and more restrictive.
• Secrets and keys: production secrets are not present in pre-production tooling, config stores, or logs.
• Deployment paths: promotion to production happens through a controlled release process, not by reusing pre-production credentials or “shared admin” access.

If you only separate by naming or by convention, you will struggle to show “enforced with access controls.” (PCI DSS v4.0.1 Requirement 6.5.3)

Who it applies to

This requirement applies to merchants, service providers, and payment processors in scope for PCI DSS. (PCI DSS v4.0.1 Requirement 6.5.3)

Operationally, it applies wherever you have:

• A production environment that stores, processes, or transmits cardholder data, or that is connected to the cardholder data environment (CDE).
• Any pre-production environment used to build, test, validate, or stage changes that could impact production systems (including CI/CD runners, test harnesses, staging clusters, UAT environments, and shared QA tooling).

Also include third parties that touch your SDLC or hosting stack (cloud providers, managed CI/CD, outsourced developers, MSPs). If a third party’s pre-production access can reach your production, your separation model is already broken.

What you actually need to do (step-by-step)

1) Inventory and label environments (scope clarity)

1. Define environment categories: production, pre-production (dev/test/stage/UAT), and shared services (artifact repos, logging, monitoring).
2. Map assets: cloud accounts/subscriptions, VPCs/VNETs, clusters, databases, CI/CD runners, identity tenants, and secrets stores.
3. Declare which components are in scope for PCI and which are adjacent but connected.

Deliverable: an environment boundary statement that names the technical boundaries (accounts, networks, IAM tenants) that enforce separation.

2) Implement network segmentation between pre-production and production

Choose one primary pattern and document it:

• Strong pattern (preferred): separate cloud accounts/subscriptions (or separate data centers) for production vs pre-production, with routing blocked by default.
• Acceptable pattern: same account, different VPCs/VNETs with explicit deny rules, no transitive peering, and firewall policy that only permits approved flows.

Controls to implement:

• Deny east-west traffic from pre-production to production except explicitly approved ports and sources.
• Prohibit “convenience” bridges such as shared bastions that can reach both environments without step-up controls.
• Ensure management planes are segregated (admin endpoints and jump hosts are production-only).

Evidence tip: auditors will ask for the “enforced” part. Have screenshots/exports of route tables, firewall rules, security groups, and segmentation policies that show default-deny across environment boundaries. (PCI DSS v4.0.1 Requirement 6.5.3)

3) Separate identities and permissions (humans and machines)

1. Create distinct production roles vs pre-production roles in IAM/AD/SSO.
2. Enforce least privilege for production: no broad “admin” from developer groups.
3. Separate machine identities: CI/CD service accounts for pre-production must not have production deploy rights.
4. Add step-up controls for production access: MFA, privileged access workflows, or time-bound elevation.

Common audit focus: whether developers can access production “because it’s easier.” Your job is to make production access intentional, logged, and limited. (PCI DSS v4.0.1 Requirement 6.5.3)

4) Gate the CI/CD pipeline so pre-production cannot push directly to production

Design the release path so only production-approved identities can deploy:

• Separate pipeline stages with separate credentials.
• Production deploy jobs run on production-only runners/agents, or use controlled federated identity with strict conditions.
• Require approvals for production promotion in the pipeline tooling.
• Restrict who can change pipeline definitions for production.

Artifact discipline: build once, promote the artifact. Avoid rebuilding in production with different dependencies because it increases risk and complicates evidence.

5) Prevent production data and secrets from bleeding into pre-production

Even though 6.5.3 is about environment separation, production data exposure often becomes the real incident driver.

Minimum operational expectations:

• Production secrets live only in production secret managers and are not copied to pre-production.
• Mask or synthesize sensitive data used for testing.
• Ensure logs/telemetry do not forward production-only sensitive events into pre-production systems.

Practical check: search pre-production config repos and parameter stores for production URLs, tokens, or certificate material.

6) Document exceptions and compensating controls (and make them rare)

Some teams need limited connectivity (example: pre-production calling a shared artifact repository). Handle this with:

• A documented exception register.
• Explicitly approved flows, narrow allowlists, and continuous logging.
• Periodic revalidation that the exception still exists for a business reason.

7) Validate the separation (prove it works)

Add a control test that demonstrates:

• Pre-production identities cannot access production endpoints.
• Pre-production networks cannot route to production networks.
• Production deployment requires production permissions.

This can be performed via scripted checks, configuration compliance rules, or periodic access tests. Retain the results as evidence. (PCI DSS v4.0.1 Requirement 6.5.3)

Required evidence and artifacts to retain

Keep evidence that shows design + enforcement + ongoing control:

• Network diagrams showing environment boundaries and allowed flows.
• Firewall/security group/ACL exports demonstrating default-deny between pre-production and production.
• IAM role matrix listing production vs pre-production roles, who can assume them, and conditions (MFA, time bound).
• Access reviews for production roles (review records, tickets, approvals).
• CI/CD configuration evidence: production deploy permissions, approval gates, runner/agent segregation, and change control for pipeline definitions.
• Secrets management evidence: separate secret stores/paths for production vs pre-production and access policies.
• Exception register with approvals and compensating controls.
• Validation/test results that show blocked access attempts or compliance checks. (PCI DSS v4.0.1 Requirement 6.5.3)

If you want to operationalize evidence collection, Daydream can help you run a standing evidence request list (network segmentation proof, IAM exports, pipeline controls) and keep the artifacts current for PCI assessment cycles.

Common exam/audit questions and hangups

Expect questions like:

• “Show me how pre-production is separated from production. Is it separate accounts, networks, or both?” (PCI DSS v4.0.1 Requirement 6.5.3)
• “Can a developer in the dev group access production logs, databases, or admin consoles?” (PCI DSS v4.0.1 Requirement 6.5.3)
• “Which service accounts can deploy to production, and how are the credentials protected?” (PCI DSS v4.0.1 Requirement 6.5.3)
• “Do CI/CD runners for test jobs have any path to production?” (PCI DSS v4.0.1 Requirement 6.5.3)
• “Do you ever copy production data into test? If yes, what prevents that test environment from reaching production?” (PCI DSS v4.0.1 Requirement 6.5.3)

Hangups that trigger findings:

• Shared admin jump boxes for both environments.
• Flat networks with “temporary” firewall rules that became permanent.
• One IAM tenant with broad groups that apply to both prod and non-prod.
• Same secrets in both environments.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: “Separate” VPCs but shared routing/peering creates a backdoor.
   Avoid by adopting default-deny routing and explicitly documenting each allowed flow, with periodic review.

2. Mistake: CI/CD pre-prod credentials can deploy to production.
   Avoid by isolating production deploy permissions to production-only service accounts and requiring approvals for production stages.

3. Mistake: Shared observability or admin tooling becomes an environment bridge.
   Avoid by controlling admin tooling access and segmenting management planes; treat shared services as high-risk integration points.

4. Mistake: Production secrets appear in pre-production logs or configs.
   Avoid by segregating secret stores and scanning repos/config for production identifiers.

5. Mistake: No proof.
   Avoid by scheduling periodic validation checks and retaining exports/screenshots/tickets as evidence. (PCI DSS v4.0.1 Requirement 6.5.3)

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so do not treat this page as a predictor of regulator actions. The practical risk is straightforward: if pre-production is less controlled than production (common), it becomes a low-friction entry point that can lead to unauthorized access to production systems, cardholder data exposure, and integrity issues in production releases. (PCI DSS v4.0.1 Requirement 6.5.3)

Practical execution plan (30/60/90-day)

First 30 days (stabilize and define boundaries)

• Publish your environment definitions and boundary statement.
• Complete inventory of networks, accounts, clusters, and CI/CD runners.
• Identify and freeze obvious bridges (shared bastions, shared admin roles, shared deploy keys) with temporary compensating controls and logging.

By 60 days (enforce separation in the control plane)

• Implement network default-deny between pre-production and production; document allowed flows.
• Split IAM roles and groups; require MFA/step-up for production admin actions.
• Separate secrets storage and rotate any credentials found shared across environments.

By 90 days (prove and sustain)

• Put CI/CD gating in place with production-only deploy identities and approvals.
• Establish a recurring validation test and evidence collection routine.
• Formalize the exception register and route exception approvals through change management.

(Phases are guidance for sequencing; adjust to your delivery model and assessor expectations.) (PCI DSS v4.0.1 Requirement 6.5.3)

Frequently Asked Questions

Does PCI DSS require physically separate infrastructure for pre-production and production?

PCI DSS 6.5.3 requires separation enforced by access controls, not a specific architecture. Separate accounts/subscriptions are a common way to make enforcement easier to prove. (PCI DSS v4.0.1 Requirement 6.5.3)

Can developers have production access if it’s read-only?

Possibly, but it must be explicitly authorized, restricted, and auditable. Most teams pass assessments more cleanly by limiting production access to a smaller set of operational roles with step-up controls. (PCI DSS v4.0.1 Requirement 6.5.3)

Is a separate VLAN/VPC enough to meet “separation”?

Only if routing and firewall policy truly block pre-production from reaching production by default and you can show evidence of enforcement. A separate network name without enforced deny controls will not hold up. (PCI DSS v4.0.1 Requirement 6.5.3)

What about shared tools like ticketing, source control, or artifact repositories?

Shared tools are common, but treat them as high-risk connectors. Ensure production credentials are not stored in shared systems accessible from pre-production identities, and restrict network paths and permissions appropriately. (PCI DSS v4.0.1 Requirement 6.5.3)

How do we handle third parties who support both pre-production and production?

Require distinct accounts/roles for production vs pre-production, time-bound access for production, and a documented approval trail. Your separation controls must apply to third-party access paths the same way they apply to employees. (PCI DSS v4.0.1 Requirement 6.5.3)

What evidence is most persuasive to an assessor?

Configuration evidence that shows blocked paths (network denies, IAM denies), plus records that production access and production deployments require separate permissions and approvals. Pair design docs with exports and validation results. (PCI DSS v4.0.1 Requirement 6.5.3)