Separation of development, test and production environments
Purpose
Separate and secure development, test and production environments to protect production systems and data.
How to meet this control
In short: Separate and secure dev, test and production environments.
- Step 01Run development, test and production in separate domains, whether virtual, physical or separate cloud subscriptions
- Step 02Define and enforce authorised promotion paths so code moves to production only through change control
- Step 03Keep compilers, editors and development tooling off production systems when not needed
- Step 04Label environments clearly and never copy unprotected sensitive production data into development or test
- Step 05Protect non-production environments with their own secure configuration, access control, monitoring and backups
- Step 06Prevent any one person from changing both development and production without independent review and approval
Tip: No production data in dev/test without masking; separate credentials.
What ISO 27002 says to cover
Reference points from the ISO/IEC 27002:2022 guidance for this control. Use them to check the steps above cover everything relevant to you.
- ›Determine and apply the level of separation needed to prevent production problems
- ›Run development and production in different domains, virtual or physical
- ›Define and enforce rules and authorisation for promoting software into production
- ›Test changes in a staging environment first and avoid testing in production
- ›Keep compilers, editors and development tools off production systems when not needed
- ›Display clear environment labels and avoid copying sensitive data into dev or test unprotected
- ›Protect dev and test with secure configuration, access control, monitoring and backups
- ›Prevent one person from changing both development and production without review and approval
Audit evidence to keep
- - Evidence of separate development, test and production environments
- - Promotion or release process requiring change control
- - Environment labelling and access control configuration
- - Evidence production data is masked or excluded from non-production
- - Segregation of duties record covering deployment approval
Common mistakes
- - Treating security review as optional when release pressure rises
- - Testing only happy paths and missing abuse cases
- - Not linking production changes to approvals and rollback plans
Owner, cadence, and proof
Assign one accountable owner for A.8.31. Review this control at least annually, after related incidents, and whenever the underlying process, supplier, system, office, or legal obligation changes. The control is audit-ready when the owner can show the policy or procedure, the latest operating evidence, the latest review, and any open exceptions with due dates.
Policy templates for this control
Use these starting documents to turn the control into evidence. Adapt each template to your scope, systems, legal obligations and actual operating process.