A.8.31
Separation of development, test and production environments
Technological controlsCheckpoints 6Evidence 6Cases 6
Control objective
This control requires the organization to separate development, test, and production environments physically or logically, so that unverified code or configuration changes cannot reach production services outside a controlled process and production data cannot leak into lower environments with weaker protection. By making the boundaries between environments and the promotion procedures explicit, the organization protects the integrity and availability of production systems and minimizes the impact that mistakes or unauthorized changes during development/test can have on production. The same separation principle should be maintained consistently not only on premises but also in cloud/container/CI-CD and other automated deployment environments.
Key checkpoints
- Are development/test/production environments separated physically or logically (network/system/account)?
- Are procedures for promoting software and changes between environments (approval, linkage with change management, integrity verification, rollback) defined and enforced?
- Is development/test data sensitivity reduced, with essential use of real production data controlled through a lawful basis, separate approval, and safeguards?
- Are access privileges separated per environment, and is developers' direct access to production minimized/controlled?
- Are unnecessary development elements (compilers, development tools, source code) removed from production so that it is kept to a minimal configuration?
- Is environment separation, including separation of accounts and secrets, applied in cloud/container/IaC/CI-CD automated deployment environments as well?
Implementation guidance
- Separate development/test/production environments physically, or logically through distinct network segments/VPCs/subscriptions/projects/namespaces and accounts.
- Link promotion from lower environments to production with change management for approval and recording, and provide integrity verification of deployment artifacts (signing, artifact verification) and rollback procedures.
- Block developers' direct access to production by default, and where needed grant least-privilege/time-bound access controlled and logged through privileged access management (PAM).
- Prefer synthetic/transformed test data and assess re-identification risk. For necessary real-production-data exceptions, verify need, lawful basis, owner approval, minimum scope/duration, and adequate safeguards under A.8.33.
- Apply login banners/screen colors/host naming conventions so that environments are clearly identifiable, preventing mistaken operations between production and test.
- Remove unnecessary elements such as compilers, debugging tools, development accounts, and source code from production to minimize the attack surface.
- Separate privileges, network boundaries, secrets, and deployment authority across environments in cloud/IaC/CI-CD, and test enforcement. Even on shared platforms, prevent unauthorized production access by development identities and permit only approved deployment paths.
Evidence
- Development/test/production environment separation policy/procedures and network diagrams
- Per-environment access privilege lists and access privilege review records
- Cross-environment promotion/deployment approval records (linked to change management) and rollback procedure documents
- Test data masking/pseudonymization records and usage approval records
- Cloud/IaC environment separation configuration evidence (account/VPC/namespace/secret separation)
- Reviews of removal of unnecessary development elements and access protection for required runtime components
Nonconformity examples
- Development/test/production run on the same server or same network segment without separation.
- Standing developer access to production lacks business justification, least privilege, approval, and activity review, leaving unauthorized-change risk uncontrolled.
- Production data is copied into test without transformation or the lawful basis and safeguards required for an approved exception.
- Developers apply source code or configuration directly to production (hotfix) without change management approval.
- Unnecessary development tools/source/repository material remains in production, or required runtime files lack access protection.
- Insufficient privilege/network isolation or shared credentials in a cloud environment permit unauthorized access from development to production.