ISO 27001 Annex A 8.31: environment separation that passes audit

The enterprise security questionnaire asks a question no policy document can answer: can your developers touch production? If the honest reply is "some of them, all the time", the deal stalls while procurement waits for remediation.

This guide covers ISO 27001 Annex A 8.31 for engineering leads and CISOs at 25–250 person firms. It explains what ISO 27001 Annex A separation of development, test and production requires. It then shows how to build it into cloud accounts and pipelines, and what auditors sample. The aim is separation your engineers barely notice and an auditor can verify in minutes.

What does ISO 27001 Annex A 8.31 require for separation of development, test and production?

ISO 27001 Annex A 8.31 requires separate domains for building, testing and running software, with authorised, deliberate promotion between them. Changes are proven in staging before reaching live systems, deployment follows documented rules, and no single person can push their own code unreviewed. Non-production environments must be secured in their own right.

Enterprise buyers probe this control early because the failure stories are mundane and expensive. A debugging session pointed at the wrong database. A Friday hotfix straight onto the live server. A developer laptop holding an unmasked production dump when it is stolen.

For regulated firms the stakes sharpen. A compromised test box that can reach production turns a nuisance into a reportable breach. Missing segregation of duties around deployment is the kind of gap that external auditors and regulators write up as an absent management control.

The control is preventive, and it protects all three security properties. Confidentiality holds because production data and credentials stay out of weaker environments. Integrity holds because nothing changes live systems without review, and availability holds because untested code cannot take the service down.

Two neighbouring controls own the related questions. Annex A 8.32 governs what moves across the boundary, and Annex A 8.33 governs the data allowed on the non-production side.

Done well, this control is mostly invisible plumbing that your CI/CD pipeline already wants to build.

What changed in ISO 27001:2022 Annex A 8.31 separation of development, test and production environments?

ISO 27001:2022 Annex A 8.31 separation of development test and production environments carries forward the 2013 control A.12.1.4 into the Technological theme. The 2022 guidance is pragmatic about edge cases. Canary rollouts to pilot users, blue-green production pairs and deliberate testing in development are allowed when the blurring is defined and approved.

The intent carries over from 2013. Domains for building, testing and running software stay apart, and crossing between them stays a deliberate act. The edge cases are named in the supporting guidance, ISO/IEC 27002:2022 control 8.31 separation of development, test and production environments. A team running canary releases is therefore not non-compliant by default.

Each deliberate exception needs two things on paper: the circumstances and the approver. Typical entries in the secure development policy look like this:

• Canary or pilot-user rollouts: which user cohort receives the release, and what triggers rollback.
• Blue-green switchovers: confirmation that both production stacks sit under production controls, and who authorises the cut-over.
• Testing against a production copy: why the copy is needed, what data it holds and how long it exists.

The standard allows the pattern. It does not allow the pattern being undefined. An auditor who finds a canary release with an approval record sees a controlled exception. The same release with no record looks like accidental blurring.

How do you meet ISO 27001 separation of development, test and production environments across AWS, Azure and GCP?

Separate at the cloud account or subscription boundary, not at folders or shared VPCs. Use distinct accounts for development, staging and production, with no network route from non-production into production. Code then flows one way through the pipeline, never sideways, and environments are labelled loudly so nobody runs a destructive command in the wrong one.

The NCSC technically enforced separation guidance supports this approach. It treats separation in cloud architectures as a defence against lateral movement, with development and test environments kept apart from production workspaces. A folder is an organisational label. An account boundary is an enforcement point.

The boundary has a different name on each major cloud:

• AWS: one account each for development, staging and production, grouped under an organisation with policy guardrails above them.
• Azure: separate subscriptions, with management-group policy applied above the subscriptions.
• GCP: separate projects, with organisation policy inherited from above.

On every platform, deny peering, shared credentials and shared secrets stores between non-production and production by default. A forgotten route is how a weak environment becomes a path into a strong one.

A manual edit on a live server is not a shortcut. It is an incident that has not been timestamped yet.

Label environments loudly with console banners, distinct prompt colours, separate URLs and account names that cannot be mistaken for each other. The label matters most late at night, when a tired engineer is about to run something destructive.

Cloud-native firms get separation as strong as physical isolation for the cost of an org-structure decision. Formalising the boundaries, pipeline gates and break-glass route is typically one to two weeks of engineering plus a short policy section. Re-platforming a legacy shared environment is a larger project, and your risk assessment should size it.

How do you separate duties in the CI/CD pipeline without a change advisory board?

Split the duties inside the pipeline rather than the org chart. Branch protection plus a required peer reviewer means the author of a change cannot also approve and release it. At 50 people that delivers the assurance enterprises buy change advisory boards for, without deployment windows or ceremony slowing the release cadence.

Four settings deliver the split on any mainstream Git platform:

1. Protect the production branch. No direct pushes and no force pushes, for anyone, administrators included.
2. Require an independent approval. At least one reviewer who is not the author, with self-approval blocked.
3. Require passing checks. Tests and security scans must pass before a merge is possible.
4. Make the pipeline the only deployer. Production deploy credentials belong to the pipeline, so a merged and approved change is the only route to release.

Every merged pull request then records who wrote the change, who approved it and what shipped. That record is the trace an auditor asks for.

Two pitfalls sit at opposite ends. The first is segregation on paper: one engineer who writes, approves and deploys, with the review step self-certified. The second is imported ceremony: a 30-person team adopting change advisory boards and deployment windows. A required reviewer gives the same assurance without the drag.

A policy that describes a pipeline the team routinely bypasses isn't a control.

Annex A 8.32 owns the change ticket lifecycle, from request to review. Land the two controls together, because they share the promotion machinery.

How should developers access production under Annex A 8.31?

Scope developer access by environment: broad rights in development, read-only or nothing in production. Emergencies go through just-in-time elevation that is logged, time-boxed and reviewed afterwards. Define the break-glass route before you need it, because the hotfix improvised on a Friday is the one that bypasses the pipeline.

Standing production admin access for developers, justified as faster troubleshooting, is one of the most common findings on this control. The replacement is not blindness: read-only access to logs, metrics and traces lets engineers debug live behaviour without the ability to change it.

Write the break-glass route as a short procedure with five parts:

• Trigger: what counts as an emergency, such as a customer-facing outage or a live security incident.
• Approver: who can grant elevation, ideally someone other than the requester.
• Duration: a fixed expiry measured in hours, enforced automatically.
• Record: an incident or ticket reference plus session logging.
• Review: a look-back after use, with any fix replayed through the pipeline.

Break-glass access that never expires isn't break-glass. It's standing access with a better name.

The Friday hotfix is the pressure test. Give urgent fixes an expedited review lane inside the pipeline, and engineers will use it. A route that exists only as a policy paragraph will lose to a root shell every time.

Done this way, an urgent fix leaves a ticket, a time-boxed session and a merged pull request. The auditor gets a clean record, and the engineer gets a route faster than improvising.

How do you stop non-production environments becoming a route into production?

Treat non-production as a real security domain: patched tooling and dependencies, hardened baselines, access control, monitoring and backups. Keep compilers and debuggers off production, and keep live personal data out of development and test. Copying an unmasked production database into staging puts you at odds with UK GDPR Article 5(1)(f).

The ICO data protection principles guidance sets out the security principle behind that article. Personal data must be processed securely, including protection against unauthorised processing and against accidental loss, destruction or damage. A staging database holding live customer records behind a looser access list than production is hard to defend against that wording.

A dev environment that can reach production is production with weaker locks.

Non-production fails in three predictable ways:

• Treated as disposable: unpatched tooling and dependencies, open access, no monitoring or backups.
• Bridged by accident: a peering rule or shared credential left over from a migration, linking the soft environment to the hard one.
• Fed with real data: an unmasked production restore in staging, one act that breaks this control and Annex A 8.33 together.

Production needs the opposite discipline. Compilers, debuggers and utility programs have no business on live systems, and their absence removes a class of attacker convenience. Attackers compromise the weak environment and walk to the strong one, so every tier needs its own baseline and production should carry the smallest toolset.

For data, default to synthetic or masked sets in development and test. Annex A 8.33 carries the detail on masking and test-data handling.

What will an auditor ask for and sample under Annex A 8.31?

Auditors pull the production access list and compare it with your developer roster. They trace last week's release from commit through review and approval to deployment, and test your architecture diagram against live cloud configuration. Standing developer write access to production with no compensating review grades as a major nonconformity.

Expect these questions in the room:

• "Draw me your environments. Where does the boundary between test and production sit?"
• "Which of your developers can write to production right now?"
• "Take last week's release. Who wrote it, who approved it, and how did it reach production?"
• "When did someone last need emergency production access, and where is the record?"
• "What data does staging run on, and how did it get there?"

The access list is pulled, not the policy read. Auditors also examine any hotfix in the change log to see whether it followed the defined emergency route.

The artefacts that answer those questions:

• The secure development policy section on separation, promotion rules and approved exceptions.
• Architecture and network diagrams that match what the cloud console shows.
• IAM or RBAC definitions and access lists showing different developer rights per environment.
• Pipeline configuration and deployment logs showing required reviews, approvals and rollback capability.
• Change tickets and code review records for a sample of recent production releases.
• Masking or synthetic-data tooling records showing what non-production runs on.
• Audit trails for cross-environment access, including break-glass elevations with their approvals.

In certification-body practice, grading follows the gap. Developers with standing write access to production and no compensating review grade major. So does a shared development and production environment with nothing between them: both are the absence-of-separation case. A single release that skipped its gate, unlabelled environments or an undocumented break-glass event grades minor. Minor findings add up to a major where repetition shows the gates are decorative.

How do you automate environment separation as code?

Define the boundaries in infrastructure as code and cloud-organisation policy. Enforce duty separation through branch protection and pipeline-only deploy credentials, issue production access on a timer through the identity provider, and alert on cross-environment drift. Each mechanism enforces the control and generates its own evidence, so audit preparation becomes a query rather than a project.

This control automates more completely than almost any other in Annex A, because every enforcement point is configuration. Boundaries defined in Terraform and cloud-organisation policy mean drift from the documented architecture raises a finding automatically, instead of waiting for an auditor's diagram check.

Continuous monitoring then watches for the boundary eroding. Useful alerts include:

• Production credentials appearing in non-production.
• New network paths between environments.
• Changes to live infrastructure made outside the pipeline.

Just-in-time elevation through the identity provider, with automatic expiry, turns break-glass from a policy paragraph into a logged, self-revoking workflow. GRCMANA's cloud security architecture and GRC engineering work builds this version, from account structures and IAM design to the drift monitors.

Frequently asked questions