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.
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.
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.
ISO27001:2022 Annex A 8.31 Separation of Development, Test and Production Environments
White Label
ISO 27001 for Consultants
Custom-brandable ISO 27001 documentation for consultants. Easily rebrand, reduce project time, and deliver professional, high-value security systems. Focus on delivery, not drafting.
ISO 27001 Annex A 8.31 Requirements and Guidance
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.
Check Your Work?
You built it yourself. Maybe with AI. But will it pass the audit?
Don’t gamble – let an ISO 27001 Lead Auditor check your work.
ISO 27001 Annex A 8.31 Implementation Checklist
ISO 27001 Annex A 8.31 Separation of Development, Test and Production Environments Implementation Checklist:
1. Distinct Environments
- Build separate environments for development, test, and production systems.
- Apply unique system, network, and security settings to each stage.
- Restrict user access using least privilege and multi-factor authentication.
- Prevent direct connections between non-production tools and live databases.
Challenges
- Infrastructure Cost: Running duplicate setups increases equipment, licence, and running costs.
- System Complexity: Managing several different stages adds extra operational tasks for small teams.
Solutions
- Logical Cloud Isolation: Use virtual networks to separate environments without buying extra hardware.
- Automated Deployment: Use code templates to build and configure consistent environments quickly.
- Controlled Resource Sharing: Safely share basic network layers to cut overhead while keeping data separate.
2. Data Isolation
- Block live, sensitive personal data from entering development and test spaces.
- Use data masking, anonymisation, or tokenisation to secure non-production datasets.
- Transfer only the minimum required data between systems under strict approval.
- Generate artificial mock data for testing to remove privacy risks completely.
Challenges
- Masking Rules: Scrubbing complex datasets requires careful setup and ongoing maintenance.
- Testing Performance: Heavy masking routines can slow down application speed during testing.
Solutions
- Automated Data Masking: Use automated tools to scrub sensitive records before export.
- Subset Testing: Extract small data samples to speed up testing runs and cut storage needs.
- Performance Checks: Test application response times regularly within masked test zones.
3. Change Management
- Record all source code and system configuration updates in a version control system.
- Require mandatory peer reviews and security approvals before code reaches live systems.
- Enforce segregation of duties so developers cannot deploy unapproved changes directly to production.
- Maintain a clear, time-stamped audit trail for every release to support compliance audits.
Challenges
- Deployment Delays: Formal review gates can slow down fast software release cycles.
- Human Error: Manual deployment steps increase the risk of live system mistakes.
Solutions
- Automated Pipelines: Automate build, test, and release steps to deploy code fast and safely.
- Automated Test Suites: Run automated security and feature tests to cut down manual verification.
- Process Audits: Review deployment workflows regularly to remove release blockers.
4. Monitoring and Logging
- Enable event and access logging across development, test, and production stages.
- Track cross-environment connections to spot unauthorised data transfers quickly.
- Deploy network intrusion detection tools to spot malicious activity in real time.
- Store system audit logs securely to prove compliance during ISO 27001 assessments.
Challenges
- Log Volume: Reviewing huge numbers of daily events can overwhelm internal teams.
- Alert Fatigue: Too many low-level notifications make real security incidents hard to spot.
Solutions
- Centralised Log Management: Collect and analyse event data in a single central console.
- Risk-Based Alert Rules: Prioritise alerts by threat level so engineers act on high-risk events first.
- Routine Log Audits: Review access logs regularly to detect policy breaches and suspicious actions early.
ISO 27001 Toolkit
Everything a business needs to do ISO 27001 and get ISO 27001 certified in the ISO 27001 Toolkit: Business Edition
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?
- Has the guidance in ISO 27001 Annex A 5.3 Segregation of duties been followed
- Are separate environments for development, testing, and production documented and operating as documented?
- Is there evidence that each environment has distinct hardware, software, and network configurations.
- Assess if strong access controls to each environment, with least privilege principles applied has been implemented and can be evidenced.
- Has automation been used and if so do a walkthrough to ensure it is as documented.
- Check virtualisation as relevant and walkthrough and assess the implementation.
2. Is data isolation in place?
- Have data isolation mechanisms been put in place to prevent unauthorised access or modification of sensitive data in non-production environments.
- Assess data protection of sensitive data in test and development environments by techniques like data masking, tokenisation, and encryption. Review the techniques for adequacy.
- Review the process and controls that ensure only necessary data is copied or moved between environments.
3. Is change managed?
- Has guidance in ISO 27001 Annex A 8.32 Change Management been followed
- Review the change management process to control the movement of code and configurations between environments taking a sample and walking through evidence.
- Audit the controls on deployments to production, including thorough testing, code reviews, and approvals.
- Assess the version control systems that track all changes to code and configurations.
- If Automated Testing is used then walkthrough the process.
- Check for regular reviews and improvements to the processes and controls.
- Sample changes and conduct thorough review of testing of changes.
- Assess if it includes unit testing, integration testing, security testing.
- Gain evidence of back out and roll back planning.
4. What monitoring and logging is in place?
- Has guidance in ISO 27001 Annex A 8.16 Monitoring Activities been followed
- Assess the monitoring and logging capabilities in all environments to detect and respond to security incidents and performance issues.
- Collect evidence of logging and if there is analysis of logs from all environments to identify and investigate security threats and system vulnerabilities.
- If relevant audit the intrusion detection and prevention systems (IDPS) for monitoring of network traffic for malicious activity.
- Walkthrough the log management process.
- Gain evidence of alerts and responses.
- Seek evidence of log reviews.
5. Are Authorisations Obtained?
- Walkthrough approval workflows for access to environments and the movement of data between them.
- Review if delegation is at appropriate authority levels.
- Assess what approval system is used and walkthrough it to evidence authorisation.
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 Test Information: Annex A 8.33
- ISO 27001 Protection of Information Systems During Audit Testing: Annex A 8.34
- ISO 27001 Secure Coding: Annex A 8.28
- ISO 27001 Secure Development Life Cycle: Annex A 8.25
Further Reading
ISO 27001 Secure Development Policy Template
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, organizations 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 anonymization. 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 Anonymization 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 organizations, 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.
About the author
