Annex A 8.31: Separation Of Development Test Production Environments

Compliance leaders usually meet Annex A 8.31 during uncomfortable moments: a developer has production access “temporarily,” test data looks suspiciously like customer data, or a CI/CD pipeline can deploy straight to prod from a feature branch. ISO/IEC 27001:2022 expects you to prevent those conditions by separating development, test, and production environments so that errors, malicious actions, and uncontrolled changes don’t impact live services or real information.

This requirement is operational by nature. Auditors will look for clear boundaries (network, identity, and tooling), tight production access controls, and disciplined release pathways. They also look for evidence that these controls run all year, not just before the audit. If you rely on informal practices (“engineers know not to touch prod”), you will struggle to prove conformity.

This page gives requirement-level implementation guidance you can hand to Engineering, IT, and Security Operations. It focuses on decisions you must make, controls you must implement, and artifacts you must retain to demonstrate that separation is real, enforced, and monitored. Sources: ISO/IEC 27001 overview; ISMS.online Annex A control index.

Regulatory text

Control statement (provided excerpt): “ISO/IEC 27001:2022 Annex A control 8.31 implementation expectation (Separation Of Development Test Production Environments).” ¹

Operator interpretation: You must design and operate technical and procedural controls so that:

• Development and testing do not occur in production.
• Production access is restricted, monitored, and granted only when justified.
• Movement of code/configuration/data into production happens through controlled, auditable paths.
• Non-production does not become an uncontrolled copy of production data and privileges.

The assessment expectation is not “three AWS accounts exist.” It is “the organization can show enforced barriers that reduce the likelihood and impact of unauthorized changes and data exposure across environments.” ¹

Plain-English interpretation of the requirement

You need clear boundaries between environments (dev, test/staging, prod) so that:

• People who build and test cannot casually change what customers use.
• Bugs and experiments do not take down production.
• Sensitive production data does not show up in lower environments without controls.
• Tools used for development (debuggers, broad admin permissions, ad hoc scripts) do not become production backdoors.

In practice, separation is a combination of architecture, identity and access management, change/release controls, and data handling rules.

Who it applies to

Entity types: Service organizations pursuing or maintaining ISO/IEC 27001 certification or alignment. ²

Operational contexts where 8.31 is “in scope”:

• SaaS and hosted services with CI/CD pipelines and infrastructure-as-code.
• Internal enterprise apps where IT runs distinct environments.
• Regulated data processing where production contains personal, financial, or confidential client data.
• Third-party supported production (MSPs, contractors, platform providers) where remote access and shared tooling can blur boundaries.

If you outsource development or operations, 8.31 still applies. You must ensure separation through contracts, access control design, and oversight because third parties can create the same cross-environment risks as employees.

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

1) Define your environment model (and write it down)

Create an “Environment Separation Standard” that answers:

• What environments exist (at minimum: dev, test/stage, prod).
• What each environment is allowed to contain (data classes, secrets, integrations).
• What “production” means (customer-facing, processes real transactions, stores authoritative records).
• What constitutes an exception (break-glass access, production debugging).

Output: a 1–3 page standard plus a system/environment inventory mapping each system to its environments.

2) Enforce hard separation at the platform boundary

Pick the strongest feasible isolation for your stack:

• Cloud: separate accounts/subscriptions/projects per environment; separate VPC/VNet; separate KMS keys; separate secret stores.
• On-prem: separate VLANs/segments; separate clusters; separate admin domains where possible.
• Kubernetes: separate clusters for prod vs non-prod; if namespaces are used, document compensating controls and why cluster separation isn’t feasible.

Minimum bar auditors expect: production should not share the same administrative plane as dev/test unless you can prove equivalent isolation through controls and monitoring.

Evidence tip: screenshots/exports showing separate account IDs, network boundaries, and key/secret separation.

3) Separate identity, roles, and privileges across environments

Implement IAM so production access is meaningfully different:

• Unique production roles/groups (no “all engineers are admins everywhere”).
• MFA required for production console access.
• No shared accounts; no long-lived credentials for production administration.
• JIT access or time-bound access for production changes.
• Separate service accounts/managed identities for prod vs non-prod.

Then set up approval workflows for adding someone to production roles, with ticket references and manager/system owner approval.

Control objective: development convenience must not drive production privilege.

4) Control promotion paths into production (code, config, infrastructure)

Define and enforce how changes reach production:

• Code merges require review and pass automated checks.
• CI/CD pipeline has distinct deploy stages with gated approvals for production.
• Only the pipeline (or a limited release role) can deploy to production.
• Infrastructure-as-code follows the same promotion path; no manual prod edits except break-glass with post-event review.

Auditor-friendly pattern: “Engineers can deploy to dev; a restricted release role deploys to prod via pipeline with approvals and logs.”

5) Prevent production data leakage into lower environments

Write clear rules for data:

• No direct copies of production databases to dev laptops.
• If production data is needed for testing, require a formal request, approval, and defined safeguards (masking, tokenization, minimization, restricted access, expiration).
• Keep production secrets (API keys, private keys) out of non-prod; separate vaults and rotation schedules.

Common reality: teams copy prod “for debugging.” Your job is to channel that into a controlled path with explicit accountability and technical guardrails.

6) Monitor and detect cross-environment access and change

Separation without detection degrades fast. Implement:

• Central logging for production admin actions and deployments.
• Alerts for direct production changes outside the pipeline (where feasible).
• Detection for unusual data movement from prod to non-prod stores.
• Periodic review of production role membership and pipeline permissions.

7) Define exceptions and “break-glass” operations

You will need emergency access. Make it safe and auditable:

• Document when break-glass is allowed and who can approve/trigger it.
• Require ticket creation (even after the fact if truly urgent).
• Record session logs where feasible.
• Mandatory post-incident review to remove access and capture lessons learned.

8) Make it assessable: map to control operation and recurring evidence

Operationalize evidence capture as a routine, not a scramble. A simple way:

• Identify “control owners” (IAM owner, DevOps owner, system owner).
• Define evidence cadence ².
• Store evidence in a single audit-ready location.

Daydream can help here by turning the requirement into a recurring evidence checklist (pipeline gates, access reviews, environment inventory) and tracking reminders and assessor-ready exports without building a custom spreadsheet process. ¹

Required evidence and artifacts to retain

Keep artifacts that prove design and operation:

Governance / documentation

• Environment Separation Standard (approved, versioned).
• Environment inventory per system (dev/test/prod mapping).
• Data handling rules for non-production (masking/approval requirements).

Access control

• RBAC/IAM role definitions for prod vs non-prod.
• Joiner/mover/leaver records for production groups (tickets + approvals).
• Periodic production access review results and sign-offs.
• Break-glass procedure and records of use (tickets, session logs, post-review).

Change and release

• CI/CD configuration showing gated production deploy steps.
• Change records for production releases (ticket links, approvals, deployment logs).
• Evidence of code review requirements (branch protection settings).

Technical separation

• Architecture diagrams showing account/subscription boundaries and network segmentation.
• Exports/screenshots of environment-specific secret stores and KMS key separation.
• Logging configuration for production admin activity.

Common exam/audit questions and hangups

Auditors and internal assessors often press on these:

1. “Show me that dev/test cannot access production data.”
   They want IAM proofs, not statements.

2. “Who can deploy to production, and how do you know?”
   Expect to demonstrate pipeline permissions and production role membership.

3. “Do you ever test in production?”
   If you do (feature flags, canaries), explain controls: limited scope, approvals, monitoring, and rollback.

4. “How do you handle break-glass?”
   They will look for records and post-event reviews.

5. “How do you prevent production secrets from being reused in non-prod?”
   They’ll expect separate vaults, keys, and documented rules.

Frequent implementation mistakes (and how to avoid them)

• Mistake: “Separate” environments share the same admin group.
  Fix: separate prod roles; require explicit approval and time-bound membership.

• Mistake: non-prod contains real customer data copied for convenience.
  Fix: formalize sanitized datasets; require approvals and expiry; restrict access.

• Mistake: manual hotfixes in production become normal.
  Fix: restrict direct changes; require pipeline-based promotion; track break-glass and conduct post-change review.

• Mistake: separation exists in cloud accounts, but CI/CD tokens can deploy everywhere.
  Fix: scope pipeline credentials per environment; separate deploy roles; rotate and monitor tokens.

• Mistake: no recurring evidence.
  Fix: schedule access reviews and automated exports; store artifacts continuously.

Enforcement context and risk implications

No public enforcement cases were provided for this requirement in the source catalog, so treat this as an ISO conformity and risk-management control rather than a control tied here to specific penalties. ²

Risk-wise, weak separation increases likelihood of:

• Unauthorized production changes (malicious or accidental)
• Data exposure into lower-trust environments
• Incident response complexity (unclear “who did what where”)
• Audit findings that expand into adjacent controls (access control, change management, logging)

Practical 30/60/90-day execution plan

First 30 days (stabilize and define)

• Publish the Environment Separation Standard and environment inventory.
• Identify all current paths into production (console, SSH, pipeline, third-party tools).
• Tighten production IAM: distinct groups, MFA, remove shared accounts.
• Implement or formalize break-glass with ticketing and post-event review.

Day 31–60 (enforce)

• Add pipeline gates for production deploys (approvals, restricted deploy role).
• Separate secret stores and keys between prod and non-prod.
• Block or restrict direct production changes outside approved mechanisms where feasible.
• Define and roll out non-production data rules, including approved masking/sanitization process.

Day 61–90 (prove and monitor)

• Turn on/confirm centralized logging for production admin activity and deployments.
• Run the first production access review; remediate findings.
• Collect an “audit packet” for one representative system (diagrams, IAM exports, pipeline settings, sample change records).
• Set recurring evidence capture tasks (access reviews, pipeline permission review, environment inventory review).

Frequently Asked Questions

Do we need physically separate hardware for dev, test, and production to meet Annex A 8.31?

ISO 27001 does not prescribe specific architecture in the provided excerpt; it expects effective separation. If you share infrastructure, document compensating controls that prevent cross-environment access and unauthorized production change. ²

Can engineers have production access if we log everything?

Logging helps, but auditors still expect restriction and justification for production privileges. Use role separation, approvals, and time-bound access so production access is the exception, not the default.

We do “testing in production” with feature flags. Is that automatically noncompliant?

Not automatically. Document how feature flags are controlled, who can enable them in production, how you monitor impact, and how you roll back. Tie the process to controlled change and restricted production permissions.

What’s the minimum evidence an auditor will ask for?

Expect to show (1) environment separation documentation, (2) production vs non-prod IAM/RBAC configuration, and (3) proof of controlled promotion into production through change records and deployment logs. ³

How do we handle third parties (MSPs/contractors) who need production access?

Put third parties into the same production access model: named accounts, MFA, least privilege, approval workflow, and monitoring. Require contractual support for your access and logging requirements as part of third-party due diligence.

Our staging environment connects to production integrations (payment, email). Does that violate separation?

It can. Treat production integrations as production-grade dependencies and control access carefully (separate keys, rate limits, test endpoints where possible). Document exceptions and show compensating controls that reduce risk of real-world impact.

Footnotes

1. ISO/IEC 27001 overview; ISMS.online Annex A control index

2. ISO/IEC 27001 overview

3. ISMS.online Annex A control index