ISO 27001 Annex A 8.31 Separation of Development, Test and Production Environments is an ISO 27001 control that requires an organisation to have separate environments for each part of the development lifecycle and to be managing those environments.
In this guide you will learn how to implement ISO 27001 Annex A 8.31 Separation of Development, Test and Production Environments and pass your audit from ISO 27001 Lead Auditor Stuart Barker – author of the ultimate ISO 27001 Toolkit.
Table of contents
Key Takeaways
- ISO 27001 Annex A 8.31 mandates the logical (and often physical) separation of the environments where you build software (Development), check it (Test/Staging), and run it (Production).
- The goal is to prevent unstable code, unauthorised changes, or sensitive data leaks from crossing the boundary into the wrong place.
Purpose & Definition
ISO 27001 Annex A 8.31 is a preventive control to protect the production environment and data from compromise by development and test activities.
The ISO 27001 Standard defines ISO 27001 Annex A 8.31 as:
Development, testing and production environments should be separated and secured.
ISO/IEC 27001:2022 Annex A 8.31 Separation of Development, Test and Production Environments
DO IT YOURSELF ISO 27001
Stop Spanking £10,000’s on Consultants and Platforms
Implementation Guide
Separate Environments
You are going to make sure that for the in-scope developments that you have separate development, test and live environments with the appropriate management and controls in place around this. This will include the process of promoting through those environments and the authorisations and approvals and acceptance.
In the production environment you will remove development tools and utility programs such as compliers and editors.
Confidential, personal and sensitive data will not exist other than in the production environment.
Environment Management
Consideration for the management of the environments, the versions, the software, the patching, updating and access will be in place. Secure configurations will be documented and in place.
Monitoring and logging will apply, as appropriate – ISO 27001 Annex A 8.16 Monitoring Activities, ISO 27001 Annex A 7.4 Physical Security Monitoring.
Backups, backup process and evidence of backups will be implemented – ISO 27001 Annex A 8.13 Information Backup
Approval processes will be put in place and there will NOT be the ability for one person to change all environments without that approval. Segregation of duty will be deployed. Changes will be controlled.
You will define and document and implement rules for the authorisation and management through the different environments.
Secure Development Policy Template
The secure development policy includes the approach to separating environments.
Secure Development Policy Example
An example of the ISO 27001 secure development policy.
How to implement ISO 27001 Annex A 8.31
This is probably a no brainer requirement when it comes to your development lifecycle and you will adapt the requirement as needed by you based on the feedback and input of your specialist resources. The basic principle of segregation will hold whether we are talking a virtual or physical environment.
The key to this control is to document everything and be able to demonstrate evidence that the control is working.
- Isolate Network Environments: Build separate physical or virtual network boundaries for development, test, and production systems to prevent lateral movement and reduce operational risks.
- Enforce Role-Based Access Controls: Restrict production access using the principle of least privilege, multi-factor authentication, and temporary, time-bound approvals for emergency changes.
- Protect and Mask Test Data: Replace personal and sensitive data with synthetic or masked data before testing to avoid data leaks in non-production environments.
- Automate Secure Deployment Pipelines: Use automated deployment pipelines that require mandatory peer reviews, code quality checks, and security scans before code moves to production.
- Separate Operational Duties: Ensure distinct roles so developers cannot directly deploy unapproved changes to live production environments.
- Maintain Centralised Audit Logs: Collect and review access logs across all environments to detect unauthorised access, configuration drift, and policy breaches.
- Document Policies and Retain Evidence: Maintain formal environment management policies, access reviews, and change records to present as audit evidence.
DO IT YOURSELF ISO 27001
Stop Spanking £10,000’s on Consultants and Platforms
ISO 27001 Annex A 8.31 Audit Checklist
ISO 27001 Annex A 8.31 Separation of Development, Test and Production Environments Audit Checklist:
- 1. Are there distinct environments?
- 2. Is data isolation in place?
- 3. Is change managed?
- 4. What monitoring and logging is in place?
- 5. Are Authorisations Obtained?
Conclusion
Many if not all of the controls that apply to this control are covered elsewhere. Be it the experience, licensing, technical controls access controls but consider them in the context of this clause and be able to evidence them as they apply to separation of environments.
The best advice is to seek the help of your qualified and experienced technical teams that specialise in the management of environments.
Related ISO 27001 Controls
- ISO 27001 Annex A 8.33 Test Information
- ISO 27001 Annex A 8.34 Protection of Information Systems During Audit Testing
- ISO 27001 Annex A 8.28 Secure Coding
- ISO 27001 Annex A 8.25 Secure Development Life Cycle
ISO 27001 Annex A 8.31 FAQ
Direct write access for developers is strictly prohibited in a compliant environment, and read access should be restricted. To meet the standard, organisations typically enforce:
“No Write” Rule: Developers should never be able to modify live code or databases directly; changes must go through a controlled deployment pipeline.
Read-Only Access: If debugging is necessary, developers may be granted temporary, monitored “read-only” access.
Break-Glass Accounts: Emergency administrative access should only be available via a specific account that logs all activity for review.
ISO 27001 allows for both, but modern cloud infrastructure primarily relies on logical separation. Auditors accept different methods depending on your setup:
Physical Separation: Using completely different server racks or hardware for Dev and Prod (common in legacy on-premise setups).
Logical Separation (Cloud): Using separate AWS Accounts, Azure Subscriptions, or distinct Virtual Private Clouds (VPCs) with strict firewall rules preventing cross-talk.
Network Segregation: Ensuring that the Test network cannot route traffic to the Production database.
Live production data (PII) should never be used in development or test environments without rigorous anonymisation. Moving real data into a lower-security environment (like Dev) violates the principle of separation. Instead, you should:
Use Synthetic Data (fake data generated by scripts) for development.
Apply Data Masking or Anonymisation if production datasets must be used for staging tests.
Ensure “Dev” environments do not have the same data classification level as “Prod.”
Yes, the control is equally critical for cloud-native organisations, though the implementation differs. In a SaaS context, separation is demonstrated by:
Separate Deployment Pipelines (CI/CD) for Staging vs. Production.
Distinct URL endpoints (e.g., app-dev.com vs. app.com).
Role-Based Access Control (RBAC): Ensuring a user’s identity has different permissions when logged into the Test cloud account versus the Production cloud account.
Stuart Barker
Stuart Barker is qualified ISO 27001 Lead Auditor and a veteran practitioner with over 30 years of experience in systems security and risk management. Holding an MSc in Software and Systems Security, he combines academic rigour with extensive operational experience, including a decade leading Data Governance for General Electric (GE).
Now he is founder and Lead ISO 27001 Consultant at High Table, the worlds number 1 dedicated ISO 27001 Consultancy.
