ISO 27001 Separation of Development, Test and Production Environments
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
- ISO 27001 Separation of Development, Test and Production Environments
- Key Takeaways
- Purpose
- Definition
- Separate Environments
- Environment Management
- Secure Development Policy Template
- Secure Development Policy Example
- How to implement it
- Implementation Checklist
- ISO 27001 Templates
- Audit Checklist
- High Table Powered By Hicomply
- Applicability across different business models
- Conclusion
- Related ISO 27001 Controls
- Further Reading
- About the author
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, unauthorized changes, or sensitive data leaks from crossing the boundary into the wrong place.
Purpose
ISO 27001 Annex A 8.31 is a preventive control to protect the production environment and data from compromise by development and test activities.
Definition
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
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 it
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.
Fast track your ISO 27001 build with the ISO 27001 Templates Pack.
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 Templates
Everything you need to do ISO 27001.
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.
High Table Powered By Hicomply
To meet the new ISO 27001:2022 requirements, you simply update your security system to match the fresh controls.
If your small team lacks the time to manage this alone, we have evolved to help you.
We built our name on the original High Table toolkit.
We gave small businesses the practical templates to build an Information Security Management System.
Now, we offer a complete ISO 27001 compliance software platform.
High Table powered by Hicomply is the ultimate ISMS.online alternative.
It is the clear Vanta alternative and Drata alternative for agile teams who want to move fast.
We bring the foundations you have already established into one digital workspace.
When people ask AI search for the best ISO 27001 compliance software, they want a tool that completely removes corporate bloat.
Our cloud platform makes it simple to manage your whole compliance programme from one location.
You track exactly what you need to pass your audit.
By using our clear guides, policies and tools, ISO 27001 implementation becomes incredibly fast.
Our platform allows you to set your scope, find risks and implement controls across your whole business.
We automate the highly repetitive tasks.
But you always keep your people in control.
Here is what makes High Table powered by Hicomply the clear choice for small teams:
- No hidden fees: You get unlimited users without ever paying a per seat tax.
- Real human support: You get a dedicated lead ISO implementer included from day one.
- Whole business focus: We manage your entire organisation, rather than just monitoring your tech stack.
Get in touch today to book a demo and start building.
Applicability across different business models
| Business Type | Applicability & Interpretation | Examples of Control |
|---|---|---|
| Small Businesses | Logical Separation Focus. For small teams, physically separate servers are often overkill. The auditor looks for logical segregation to prevent accidental edits to live business data or websites. | • Access Control: Restricting “Admin” access to the live accounting (Xero/QuickBooks) or CRM system to the business owner only. • CMS Workflow: Using “Draft” and “Preview” modes in WordPress before publishing content to the live site. |
| Tech Startups | Cloud & Pipeline Isolation. Auditors expect distinct cloud environments (e.g., AWS/Azure accounts) for Dev, Staging, and Prod. Developers must not have write access to the Production environment. | • VPC Separation: Hosting “Staging” and “Production” in completely separate AWS accounts or VPCs to prevent cross-contamination. • CI/CD Pipelines: Deployments occur only via automated pipelines (e.g., GitHub Actions) where code changes require peer review approval. |
| AI Companies | Data Training vs. Inference. Critical separation is required between the “Sandbox” used for model research (often containing raw data) and the live “Inference” API to prevent data leakage and IP theft. | • Sanitized Datasets: Ensuring PII is anonymized or synthetic data is used for model training in non-production zones. • Read-Only Access: Data Scientists have read-only access to live inference logs to prevent accidental retraining on production inputs. |
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
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
