A.8.31 Separation of development, test and production environments

What A.8.31 separation of development, test and production environments requires

A.8.31 asks the organization to keep its development, test and production environments separated and secured, so that activity in the first two cannot compromise the production environment or the data it holds. In practice, an auditor will expect to see clear boundaries between those environments, controlled routes for moving code and configuration from one to the next, and restrictions on who can reach production and what production data may appear elsewhere. The organization owns this control. An implementation partner can design the environments and prepare the evidence, but only an independent auditor or certification body reports on whether the control is met. The risk is usually built up through ordinary shortcuts rather than a single failure. Developers keep standing access to production databases because a release once needed it. A build pipeline uses the same service account in every environment, so a credential leaked from a test system opens production. A copy of the customer table is restored into staging to reproduce a bug and never deleted. The control is hard in practice because these shortcuts are convenient, the people who create them are often under delivery pressure, and no single tool enforces the boundary. Confirm with your engineering leads which environments exist today, which accounts and pipelines reach more than one of them, and where production data is currently copied. The 2013 edition covered this ground with two controls, A.12.1.4 on separation of development, testing and operational environments and A.14.2.6 on a secure development environment. The 2022 edition merges them into A.8.31, so an existing 2013-based program should map both old controls to the new one and check that nothing was dropped in the merge. A.8.31 is distinct from several neighbors that an assessor may test alongside it: A.8.22 covers network segregation, A.8.32 covers the change approval and rollback process, and A.8.33 covers the handling of test information. Evidence for A.8.31 should show the environment boundaries and promotion path itself, not only that those neighboring controls exist. The standard text is available from ISO/IEC 27001:2022 on ISO.

Which environments, data and third parties fall in scope for A.8.31

A.8.31 is only as strong as the boundary drawn around production. The decisions below determine which systems, data copies and external parties must meet the separation rules, and each one is easier to settle before the Statement of Applicability is written than during an audit.

Defining development, test, staging and production

Start with a written definition of each environment, based on what it holds and who can reach it. Staging is often the hardest call: if it uses production-like configuration, live integrations or real customer records, assessors will usually treat it as production for access and data purposes. Check each environment's network path, credentials and data sources against the definitions, and record any environment that sits in a gray area with a documented decision.

CI/CD runners and build systems

Build servers and deployment pipelines hold credentials that can reach production, so they belong in scope even though they are not an application environment. Confirm which runners can deploy, where secrets are stored, and whether a developer can change a pipeline definition and push it to production without review. Pipeline access should be reviewed as carefully as direct production access.

Shared cloud accounts and Kubernetes clusters

Separation by environment name alone does not separate anything if dev and production share an account, a VPC, a cluster or an identity provider. Document whether each environment has its own account or project, its own cluster or namespace with enforced network policies, and its own roles. Where separation is logical rather than physical, the design and its limits must be explained in writing, and the assessor will test whether a developer role can cross the boundary.

Production data in non-production use

Copies of production data in test or staging are the most common gap found in this area. Decide whether copies are allowed at all, who approves them, how personal or card data is masked or subset before it is loaded, and when the copy is deleted. Ask the team to produce a list of every non-production database and its data source, because the list usually reveals copies nobody remembered making.

Outsourced developers and SaaS test tenants

Contractors who write code, and vendors who host test tenants with copies of your data, extend the boundary outside your own infrastructure. Identify which external parties can reach non-production systems, what access they hold, and whether their contracts require the same separation and deletion rules. Also confirm which SaaS test or sandbox tenants are connected to real customer data, since those tenants fall within the scope of the control even though you do not operate them.

How an assessor tests environment separation

This table lists the steps an assessor typically takes to test A.8.31, what each step examines, the evidence requested and where organizations most often fail. Read it as a sequence: the architecture review sets the scope for the sampling that follows, and the common findings show where to look before the audit starts.

Test step	What the assessor examines	Evidence requested	Common finding
Review the documented environment architecture	Whether development, test and production are defined as separate environments, with stated boundaries, network paths and data flows between them	Architecture diagrams, environment inventory, network and account structure, and the policy that defines each environment	Environments exist in practice but are not documented, or the diagram shows paths the policy never mentions
Sample access rights per environment	Who holds accounts in each environment, whether roles differ by environment, and whether the same person has rights in both development and production	Exported access lists per environment, role definitions, and the approval record for each sampled grant	Developers with standing production access, or one identity group granted rights across all environments
Test shared and service accounts	Whether accounts used by pipelines, scripts or applications can be traced to one owner and whether they are limited to their environment	Account register, credential rotation records and the owner assigned to each service account	Shared service accounts used by several teams, or the same credential working in test and production
Trace a sample of changes end to end	Whether a change moves from development to test to production through the agreed path, with approval and testing recorded at each stage	Sampled change records, pipeline run logs, test results and deployment approvals linked to one release	Changes reach production by a route that skips test, or approvals are recorded after deployment
Check how production data is handled in test	Whether production data is copied into non-production environments, under what approval, and whether it is masked or removed afterward	Data copy requests, masking or sanitization records, and deletion evidence after test cycles	Full production copies kept in test indefinitely, with no approval and no record of who accessed them
Review who may promote builds	Whether the people or automated gates that approve promotion are defined, separated from the people who write the code where practical, and recorded	Promotion rules, approver lists, pipeline configuration and a sample of promotion approvals	Promotion rights held by the developers who wrote the change, or manual copies that bypass the pipeline
Confirm undocumented promotion paths are absent	Whether any route to production exists outside the documented process, such as direct console changes, hotfix channels or local builds deployed by hand	Production change logs, administrator activity logs and a reconciliation of deployed versions against approved releases	Emergency fixes deployed directly to production with no later record in the change process
Verify that controls are monitored	Whether access and deployment events from each environment are logged and reviewed, so that cross-environment activity is noticed	Log sources per environment, review records and examples of follow-up on unexpected cross-environment events	Logs exist but nobody reviews them, or non-production logs are not collected at all

How separated environments and promotion paths work together

Separation only protects production if each environment has its own boundary. In practice that means development, test and production run in separate cloud accounts, projects or Kubernetes clusters, with distinct identity boundaries, so that a credential, role or network path valid in development cannot reach production. Each environment gets its own service accounts, secrets store and deployment credentials, and production deployment rights sit with a small group that developers do not belong to. Before go-live, confirm in writing which identity provider, administrators and break-glass accounts serve each environment, because shared administrators quietly collapse the separation the control asks for.

The second half of the design is the promotion path. Artifacts such as container images or packages are built once, stored in a registry the production environment can read but not write to from developer workstations, and then promoted forward through test and into production. Nobody edits production directly: configuration changes and hotfixes go through the same pipeline, so production state can be traced to a specific, reviewed artifact and commit. Confirm that the deploy job, not a person, is the only route to production, and that the pipeline can be shown to have refused a direct change in a test run.

Promotion gates are where A.8.31 meets A.8.32 change management. Automated tests, dependency and container image scans, and static analysis run before an artifact may move forward, and a named approver authorizes the production step against a recorded change request with an impact assessment and rollback plan. The gate results, approver identity and timestamps are the records an assessor will sample, so they should be retained centrally and linked to the change ticket. Decide in advance which failed scan or failed test blocks promotion outright and which requires a documented risk acceptance, since that decision is what an auditor will ask to see.

How to implement environment separation step by step

This sequence turns A.8.31 from a policy statement into a working boundary: each environment is mapped, isolated, given its own identities, fed through a controlled promotion path, and governed for data use, with the Statement of Applicability position recorded at the end.

Inventory environments and data flows
The control owner, usually the head of platform engineering with input from development leads, lists every development, test, staging, and production environment, including cloud accounts, clusters, namespaces, and shared tooling such as build servers and artifact registries. For each one, record what data it holds, who can reach it, and which systems feed or read from it. The output is a current environment register and a data flow diagram that an assessor can compare against what the systems actually do. Confirm the inventory against cloud account lists and network configuration, not only against what teams remember.
Define the separation model and trust boundaries
Decide how each environment is separated: separate cloud accounts or subscriptions, separate clusters or namespaces, or separate networks, and where the trust boundary sits between each pair. Production should be the most restricted zone, and development should not have a network path into production by default. Where separation depends on network segregation, cross-reference the design with A.8.22 Segregation of networks. The output is a written separation model, approved by the control owner, that names each boundary and the controls that enforce it.
Separate identities and credentials per environment
Create distinct identity groups, service accounts, and secrets stores for each environment, so that a credential issued for development cannot authenticate to production. Remove shared accounts that span environments and review standing administrative rights in production, linking this work to A.8.2 Privileged access rights. The output is an identity map showing which principals can act in which environment, plus evidence of the access review performed on it. Ask your identity provider team to confirm that cross-environment role assignments are blocked, not merely discouraged.
Build the controlled promotion pipeline
Define the single route by which code and configuration move from development to test to production, and build it so that each promotion is performed by the pipeline, not by hand. Each stage should require an approval record, and production deployments should reference the change request and the tested artifact, which connects this step to A.8.32 Change management and A.8.29 Security testing in development and acceptance. The output is a pipeline definition, a sample promotion record for each stage, and a rule that no environment is changed outside the pipeline except under a logged emergency procedure.
Set rules for production data in test
Write a rule that production personal or confidential data may enter a test environment only under documented authorization, and that most testing should use synthetic or masked data. Where production data is needed, define the approval, the transfer method, the protection applied in the test environment, and the deletion date after testing, which ties to A.8.33 Test information and A.8.11 Data masking. The output is a test data standard, a log of each approved copy, and evidence that copies were deleted after use. Ask the data owner to confirm which datasets are classified as sensitive before the standard is finalized.
Monitor and log cross-environment activity
Enable logging of authentication, deployment, and configuration changes in every environment, and send alerts when a principal from a non-production environment attempts to reach production resources. Runtime detection tools can help here. For example, Falco (Apache-2.0) evaluates Linux syscalls against YAML rules and can flag unexpected network connections or privilege escalation on hosts, though its rules must be written and tuned for your own environments. The output is a log source list per environment, alert rules for cross-boundary access, and a sample alert with its investigation record.
Document the Statement of Applicability position
Record the decision for A.8.31 in the Statement of Applicability, stating whether the control applies, how it is implemented, and which documents and systems provide the evidence. Name the separation model, the pipeline, the test data standard, and the review cadence the control owner has set. Note the two 2013 controls that A.8.31 merges, A.12.1.4 and A.14.2.6, so the assessor can trace the history. The output is a completed SoA entry with linked evidence. Ask the independent certification body how it expects the SoA justification to be presented, because wording expectations vary by auditor.

Using self-hosted tooling to enforce environment boundaries

Network separation is usually the first enforcement point an assessor asks about. A firewall between development, test and production segments turns the intent of the control into rules that either pass or block traffic. OPNsense is a stateful packet filter, and its rules pass, block or reject traffic by source, destination, port and protocol. Aliases let the team group address ranges for each environment, so a rule reads as a statement about environments rather than a list of individual hosts.

Environment aliases: Define one alias per environment, such as the address ranges for development, test and production, and write rules against those aliases instead of individual hosts.
Default deny between zones: Block development-to-production traffic by default, then allow only the named flows that a documented change has approved, such as a deployment pipeline reaching a production target.
Logged rule matches: Enable logging on the rules that block or permit cross-environment traffic so that each match is recorded and can be reviewed in the live log view.
Rule change history: Keep firewall configuration under version control so that every change to a boundary rule has an author, a reason and a review trail.
Licensing: OPNsense is licensed under BSD-2-Clause, which permits use, modification and redistribution with the license notice retained.

Confirm with your network team which rules are logged by default in your build, how long logs are retained, and where they are forwarded for review.

Evidence that passes an A.8.31 assessment

An assessor testing A.8.31 wants proof that development, test and production are separated in practice, not only in the design document. The six artifacts below connect architecture, access, promotion and data handling, and each one needs a routine so it stays accurate between audits.

Environment architecture diagrams

Diagrams showing each environment, its network boundaries, its data stores, its identity sources and the paths between them. An assessor uses them to check that development and test cannot reach production databases or management interfaces directly. Confirm that the diagrams match the live configuration, and that each change to an environment updates the diagram in the same change record. Stale diagrams are one of the most common gaps found in reviews.

Access matrices with review records

A matrix listing, for each environment, which roles and named accounts hold read, write, deploy or administrative rights. The matrix is only evidence if reviewers signed off on it at a set interval and removed access that was no longer needed. Keep the signed review records with dated decisions, and check that developers do not hold standing production administrator rights.

Pipeline configuration and approval logs

Exports of CI/CD pipeline definitions showing the stages for each environment, the required approvers for production deployments, and the logs of who approved each run. Assessors look for production deployments that bypass approval, shared deployment credentials and pipeline changes made without review. Export the configuration on a schedule and store it alongside the change records it governs.

Promotion tickets traced end to end

Sample promotion records that follow one change from request through development, test and approval to production, with the test results and rollback plan attached. A useful trace links the ticket, the commit, the build, the test evidence and the deployment log. Pick examples across the audit period, including any emergency promotions, and confirm that each one shows who authorized it and when.

Production data handling rules and masking records

Written rules stating whether production data may enter test environments, under what approval, and which fields must be masked or replaced first. Keep the masking job logs, the approval for each copy, and proof that copies were deleted after testing. This evidence connects A.8.31 to A.8.33 Test information, so review it together with the test data controls.

Firewall logs showing blocked cross-environment traffic

Rule sets and log extracts showing that traffic from development and test segments to production is denied by default, with the blocked attempts recorded. OPNsense can log each rule match for review in the live log view, so export those logs on a schedule and review denied cross-environment entries. Confirm that the rule set in the export matches the rule set in force during the audit period.

What meeting A.8.31 costs in money and effort

This table breaks down the cost components of keeping development, test and production separated, who is paid for each, whether it is one-time or recurring, and what moves it up or down. Use it to shape a quote request: each row names what to ask an implementation partner or auditor to price separately. No fees are stated because none are supplied for this topic.

Cost component	One-time or recurring	What drives it up or down	Where self-hosted open source changes the spend
Separate environments and accounts	Recurring	Number of isolated environments, cloud accounts or clusters, and whether production data copies are allowed elsewhere. Ask for the infrastructure assumptions behind each environment.	Platform components can run in the client's own accounts or data center, so licence fees for the platform itself are avoided. Compute and storage still recur.
Pipeline and promotion engineering	One-time, with later changes	Number of pipelines, approval gates and automated checks between environments. Changes to release processes add rework.	Open-source CI/CD and infrastructure-as-code tools carry no licence fee, but build and maintenance effort remains.
Identity and access tooling	One-time setup, then recurring	Number of roles, environments and privileged accounts that must differ by environment. Federation with existing directories reduces custom work.	Open-source identity governance such as midPoint can run access certification campaigns without a per-user licence, though integration effort is still needed.
Access reviews and evidence upkeep	Recurring	How often reviews run, how many access items each reviewer decides, and how well logs are retained. Automated evidence cuts manual collection.	Self-hosted review and log tooling keeps evidence in the client's environment, but staff time to run and sample reviews is ongoing.
Network and firewall controls between environments	One-time build, recurring tuning	Number of segregated zones, rule changes and log review volume. Ask how rules are documented and reviewed.	Open-source firewalls such as OPNsense and web application firewalls such as Coraza avoid licence spend; hardening and rule upkeep remain.
External security testing of environments	Recurring per test cycle	Scope of environments tested, whether production-like test data is used, and how often retests follow changes. Ask for the scope in writing.	Testing is a service cost regardless of tooling. Ask whether findings on non-production environments are included in scope.
Auditor sampling and assessment	Recurring per audit cycle	Number of environments, promotion records and sampled changes an auditor selects. Clear records lower sampling effort.	The auditor's fee is set by the certification body, not by the platform. Ask the auditor how many samples they expect.

Who owns A.8.31 and what is worth outsourcing

The organization owns A.8.31 in full. Leadership and the security function must decide how many environments exist, what each one is for, which networks and identities separate them, and what data may appear outside production. These are risk decisions that the ISMS must record and that an auditor will trace back to named owners. Accountability does not transfer to a partner when the build is outsourced.

Environment design: Decide which environments exist, their purpose, and which boundaries (accounts, networks, clusters) separate them.
Access decisions: Approve who may hold rights in production and whether any developer may hold standing access to it.
Production data rules: Set whether production data may be copied into test, under what masking or approval, and who signs off.
Promotion criteria: Define what a change must pass before it moves from development to test and from test to production.
Review: Own periodic access reviews and the Statement of Applicability entry for A.8.31.

Before engaging anyone, confirm that these decisions are written down, assigned to named roles, and linked to the change and access processes your ISMS already runs.

Common gaps that fail A.8.31 and how to close them

Most A.8.31 findings trace back to the same few habits: shared accounts, standing access, copied production data, informal releases and reviews that never happen. Each gap below is a place where an assessor can see development and production blurring, and each fix leaves a record the organization can show.

Shared credentials across environments

When the same service account, database password or API key works in development, test and production, a compromise in the least protected environment reaches production. Give each environment its own identities and secrets, stored in a secrets manager with separate vaults per environment. Check that a credential issued for test is rejected when presented against production endpoints, and keep the inventory that shows which identity belongs to which environment.

Developers with standing production access

Engineers who hold permanent production administrator rights can change live systems without a change record, which undermines the separation A.8.31 expects. Replace standing rights with role-based access that is granted on request, time-limited and logged. Break-glass access should be rare, approved by a second person and reviewed afterward. Ask for the list of people with production rights and the reason each one holds them.

Production data copied into test without controls

Test databases refreshed from production with no masking, no access limits and no deletion date move personal and confidential data into the least controlled environment. Define which datasets may leave production, mask or synthesize personal fields before the copy, and record who requested each refresh. Set a deletion date for every copy and keep evidence that it ran. A.8.33 covers the test data rules in more detail.

Undocumented promotion paths

If code reaches production through ad hoc uploads, manual file copies or a pipeline that different teams configure differently, nobody can show which environments a release passed through. Document one promotion path from development through test to production, with the approvals and automated checks at each gate. Build it into the pipeline itself so the gates run the same way every time, and keep the pipeline run records as evidence.

No evidence of access reviews

Environment separation decays as people change roles and keep access they no longer need. Without a periodic review, an assessor has no proof that developer and production rights were checked against current duties. Run a recurring access certification in which named reviewers keep, change or revoke each item within a set timeframe, and retain the signed results. Access certification tooling such as midPoint can produce these campaign records.

A.8.31 questions buyers and practitioners ask

How much effort does A.8.31 take to implement?

Effort depends mainly on how many environments exist today, how much they share, and how far production data already flows into development and test. A team that already runs distinct accounts, clusters and credentials for each environment has a smaller gap than one where developers connect to the production database from their laptops. The work usually falls into three parts: mapping the current environments and data flows, separating access and network paths, and writing down the promotion rules. Ask any partner for a written scope that lists which environments and systems are in it before comparing estimates, since the same control can be a short configuration exercise or a multi-month rebuild.

Can a small team implement A.8.31 in-house?

Often yes, if the team has someone who can run infrastructure as code, manage identity and write clear procedures. A small team usually needs to separate environments in its cloud or hosting account, restrict who can reach production, keep copies of production data out of test systems, and record how code moves from development to production. The harder part is sustaining it: reviews of access, checks that test data stays masked, and evidence collected each audit period. Teams without that capacity often bring in an implementation partner for the initial build and keep the ongoing review in-house. Either way, the organization owns the control and its evidence.

What does A.8.31 need from the engineering team?

Engineering owns most of the technical substance of this control. Teams need to define each environment as code, keep credentials and network paths separate, and build a deployment pipeline that promotes tested artifacts rather than rebuilding them by hand in production. Developers need read access to production only where a documented need exists, and emergency access needs a logged path. Engineers also need to agree which data may enter test systems and how it is masked or synthesized. Expect the controls to touch CI/CD configuration, cluster and account design, and database access patterns, so engineering leads should review the written scope before work starts.

How long does A.8.31 implementation take?

The duration depends on scope: the number of environments, the number of systems and teams involved, and how much existing infrastructure has to be separated or rebuilt. No general timeline applies. Ask any implementation partner for a fixed-scope plan with deliverables and dates agreed in writing before work starts, and confirm which environments, data flows and evidence the plan includes.

Are separate cloud accounts required for A.8.31?

The standard asks for environments to be separated and secured, not for a specific account structure. Separate cloud accounts or subscriptions are one common way to achieve strong separation because they isolate identities, networks and billing boundaries, but a well-designed separate cluster, namespace and network policy can also satisfy the intent if access is restricted and documented. Confirm with your auditor how they will assess the chosen separation, and record the reasoning in the Statement of Applicability and the architecture documents.

How does A.8.31 relate to A.8.33 and A.8.32?

A.8.31 covers the environments themselves and the rules for moving changes between them. A.8.33 covers the test information used within those environments, including limits on copying production or personal data into test and deleting it after use. A.8.32 covers the change management process that authorizes, tests and records changes before they reach production. In practice an auditor will often sample a promotion from test to production and ask for the change record, the test results and the access logs together, so the three controls should share one evidence trail.

What will an auditor ask for to test A.8.31?

Auditors usually ask to see a diagram or description of the environments, evidence that they are separated in practice, and the rules governing promotion and access. Typical evidence includes account or cluster inventories, access reviews for production and non-production systems, pipeline configuration showing who can deploy, samples of change records linking tests to releases, and documentation of how test data is controlled. Ask your certification body which evidence it expects, because the sampling approach and the depth of testing vary between auditors. The organization owns these records; an auditor, not the implementation partner, decides whether they are sufficient.

How DeployOpen prepares environment separation evidence

DeployOpen plans, implements and documents separated development, test and production environments and the promotion paths between them, inside the client's own cloud accounts, data centers or air-gapped networks. Work starts from a fixed written scope that names the environments, the network boundaries, the identity and deployment tooling, the promotion gates and the systems in each tier. The client keeps ownership of the control itself: it decides who may approve a promotion, which production data (if any) may appear in a test environment, and how exceptions are handled. DeployOpen configures the mechanisms that enforce those decisions, such as separate accounts or projects, segregated networks, distinct credentials per environment, and pipeline stages that require approval before code reaches production. It then documents the design so an assessor can trace each promotion path to a named owner.

Evidence is prepared alongside the build. Typical artifacts include the environment inventory, network and access diagrams, role assignments showing which people hold production rights, the approval records for promotions, and configuration exports that show production data is masked or excluded from test systems. Where a review of access is needed, DeployOpen can set up the review workflow so that the client's reviewers, not the implementer, decide whether access is kept, changed or revoked. Before engaging, ask whether the scope covers each environment you run today and how exceptions will be logged. Only an independent auditor or certification body issues an assessment report or certificate. DeployOpen prepares systems and evidence for that assessment but does not certify, attest or sign off on the control.