Zum Hauptinhalt springen
CENEDRIL WIKI
DE
Annex A · Technological Control

A.8.31 — Separation of Development, Test and Production Environments

Updated on 4 min Reviewed by: Cenedril Editorial
A.8.31 ISO 27001ISO 27002BSI CON.8

A developer runs a database migration script against what they believe is the test database. It is actually the production database. The script deletes a key table. Customer-facing services go down for four hours while the team restores from backup. A.8.31 prevents this by requiring strict separation of development, test and production environments — different infrastructure, different access controls, different credentials.

Environment separation protects production data and availability from the inherent risks of development and testing activities: untested code, experimental configurations, destructive test scripts and broader access.

What does the standard require?

  • Operate environments in separate domains. Development, test and production run on separate infrastructure (or separate accounts/subscriptions in the cloud).
  • Define promotion rules. Software moves from development to test to production through a controlled, documented process.
  • Restrict cross-environment access. Developers do not have routine access to production. Production data is protected in non-production environments.
  • Separate credentials. Each environment uses independent credentials and secrets.
  • Protect sensitive data. If production data must appear in non-production environments, apply masking or anonymization.

In practice

Use separate infrastructure. Run development, staging and production on different servers, different network segments or different cloud accounts. Shared infrastructure with environment-level tagging is insufficient — a misconfigured IAM policy can grant cross-environment access.

Implement controlled promotion. Code moves from development to test to production through a defined pipeline. Each promotion requires automated tests to pass and, for production, a documented approval.

Restrict production access. Remove standing developer access to production. Use just-in-time access for troubleshooting — time-limited, logged and approved. Break-glass procedures cover genuine emergencies.

Mask production data. When test environments need realistic data, use data masking (A.8.11) or synthetic data generation. Copying unmasked production data to test environments is the most common finding in this control area.

Typical audit evidence

Auditors typically expect the following evidence for A.8.31:

  • Environment architecture — documentation showing separation of environments (see Secure Software Development Policy in the Starter Kit)
  • Access control lists — evidence that production access is restricted
  • Deployment pipeline configuration — controlled promotion process
  • Data masking evidence — proof that production data in test environments is masked
  • Credential separation — evidence that environments use independent secrets

KPI

Percentage of projects with fully separated development, test and production environments

Measured as a percentage: how many of your development projects operate on fully separated environments with controlled promotion? Target: 100%.

Supplementary KPIs:

  • Number of developers with standing production access (target: zero)
  • Number of test environments using unmasked production data (target: zero)
  • Number of incidents caused by environment confusion

BSI IT-Grundschutz

A.8.31 maps to BSI modules for development and test management:

  • CON.8 (Software Development) — requires separation of development, test and production environments.
  • OPS.1.1.6 (Software Testing and Approval) — requirements for test environment security and controlled promotion to production.

Sources

Frequently asked questions

Can developers have access to the production environment?

ISO 27002 recommends restricting production access. Developers should not have routine access to production. When production access is necessary for troubleshooting, it should be time-limited, logged and approved through a formal process.

Can we use production data in test environments?

Only with appropriate protection measures. Data masking (A.8.11) or synthetic data generation is strongly recommended. If real production data must be used, apply the same access controls as in production and obtain formal approval.

Does this apply to cloud environments?

Yes. Use separate cloud accounts or subscriptions for development, test and production. Shared accounts with environment-level tagging alone do not provide sufficient separation.