ISO 27001 Annex A 8.31 Separation of Development, Test and Production Environments Explained

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.

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

Requirement

• The “One-Way Street” Rule: Code should flow in one direction: Dev to Test to Production. You should never “hotfix” directly on the production server.
• Segregation of Duties: ideally, the person who writes the code should not be the same person who pushes the button to deploy it to Production. This prevents malicious code (or honest mistakes) from slipping through unchecked.
• Data Isolation: Production data (real customer PII) should never exist in the Development environment. Developers should work with “dummy” or synthetic data to avoid accidental leaks.
• Access Control: Developers should have “Admin” rights in Dev, but “Read-Only” (or no access) in Production. Only authorized System Admins or automated CI/CD pipelines should have write access to live servers.

Audit Focus

Auditors will look for “The Developer’s Keys”:

1. Access Rights: They will ask to see the user list for your Production AWS/Azure account. If they see “John (Developer)” has full Admin access, it is a non-conformity (unless heavily justified).
2. The “Oops” Test: They will ask, “If a developer accidentally deletes the database in Dev, does it affect Production?” (The answer must be No).
3. Pipeline Evidence: They want to see that deployments happen via a controlled tool (like Jenkins, GitHub Actions, or GitLab) rather than a developer manually dragging files via FTP.

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.

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.

1. Provision Isolated Environment Architecture

• Action: Define and deploy logically distinct network segments or cloud VPCs for development, staging (test), and production.
• Result: Establishes a “boundary-first” security posture that prevents lateral movement and resource contention between SDLC phases.
• Use Virtual Private Clouds (VPCs), Subnets, and Security Groups to enforce strict traffic isolation.

2. Enforce Granular IAM Roles and RBAC

• Action: Implement Role-Based Access Control (RBAC) and Multi-Factor Authentication (MFA) to restrict developer access to production systems.
• Result: Ensures the Principle of Least Privilege (PoLP) and prevents unauthorized code execution or configuration changes in the live environment.
• Provision “Read-Only” access for developers in staging and “No Access” in production, utilizing Just-In-Time (JIT) elevation for emergency patches.

3. Sanitize and Mask Production Data for Testing

• Action: Deploy automated data masking or synthetic data generation tools to replace PII/PHI before moving data to test environments.
• Result: Eliminates the risk of data breaches within development environments while maintaining the referential integrity needed for accurate testing.
• Formalize a Data Handling Policy that strictly prohibits the use of unencrypted “live” production databases in non-production zones.

4. Formalize Automated CI/CD Change Management

• Action: Configure CI/CD pipelines to require mandatory peer code reviews and automated security scanning (SAST/DAST) before deployment.
• Result: Creates an immutable audit trail and ensures that only verified, authorized code can transition from development to production.
• Integrate “Gatekeeper” approvals within tools like GitHub Actions or GitLab CI to enforce the separation of duties.

5. Implement Continuous Monitoring and Audit Logging

• Action: Enable centralized logging (SIEM) across all environments to track cross-environment data flows and access attempts.
• Result: Provides the technical evidence required for ISO 27001 audits and enables rapid detection of policy violations or configuration drift.
• Monitor for “Shadow IT” or unauthorized environment bridges that could bypass the separation controls.

Implementation Checklist

ISO 27001 Annex A 8.31 Separation of Development, Test and Production Environments Implementation Checklist:

1. Distinct Environments

Establish clearly defined and separate environments for development, testing, and production.

Each environment should have distinct hardware, software, and network configurations.

Implement strong access controls to each environment, with least privilege principles applied.

Challenges

Cost: Maintaining separate environments can be expensive due to hardware, software licenses, and ongoing maintenance.

Complexity: Managing multiple environments can increase operational complexity and require specialised tools and expertise.

Solutions

Virtualisation and Cloud Computing: Utilise virtualisation technologies (e.g., VMware, VirtualBox) or cloud platforms (e.g., AWS, Azure, GCP) to create cost-effective and scalable environments.

Automation: Automate the provisioning and configuration of environments using tools like Ansible, Puppet, or Chef to reduce manual effort and improve consistency.

Shared Resources: Explore options for sharing certain resources (e.g., network infrastructure, storage) across environments where feasible to optimise costs.

2. Data Isolation

Implement strict data isolation mechanisms to prevent unauthorised access or modification of sensitive data in non-production environments.

Utilise techniques like data masking, tokenisation, and encryption to protect sensitive data in test and development environments.

Ensure that only necessary data is copied or moved between environments.

Challenges

Data Masking Complexity: Implementing effective data masking rules can be complex and time-consuming, especially for complex data structures.

Performance Impact: Data masking and other isolation techniques can sometimes impact the performance of applications in test and development environments.

Solutions

Data Masking Tools: Utilise specialised data masking tools to automate the process and ensure consistent application of masking rules.

Performance Testing: Conduct thorough performance testing in masked environments to identify and mitigate any performance bottlenecks.

Data Subsets: Use smaller subsets of production data in test and development environments to reduce the volume of data that needs to be masked and improve performance.

3. Change Management:

Establish a robust change management process to control the movement of code and configurations between environments.

Implement strict controls on deployments to production, including thorough testing, code reviews, and approvals.

Utilise version control systems (e.g., Git) to track all changes to code and configurations.

Challenges

Slow Deployment Cycles: A rigid change management process can sometimes slow down the deployment of new features and updates.

Manual Processes: Manual steps in the deployment process can introduce errors and increase the risk of human error.

Solutions

Continuous Integration/Continuous Delivery (CI/CD): Implement CI/CD pipelines to automate the build, test, and deployment process, enabling faster and more frequent releases.

Automated Testing: Implement comprehensive automated testing suites to accelerate the testing process and reduce the reliance on manual testing.

Regular Reviews and Improvements: Regularly review and improve the change management process to identify and address any bottlenecks or inefficiencies.

4. Monitoring and Logging

Implement robust monitoring and logging capabilities in all environments to detect and respond to security incidents and performance issues.

Collect and analyse logs from all environments to identify and investigate security threats and system vulnerabilities.

Implement intrusion detection and prevention systems (IDPS) to monitor network traffic for malicious activity.

Challenges

Log Management Complexity: Managing and analysing large volumes of logs from multiple environments can be complex and time-consuming.

Alert Fatigue: An excessive number of security alerts can lead to alert fatigue and make it difficult to identify and respond to genuine threats.

Solutions

Security Information and Event Management (SIEM) Systems: Utilise SIEM systems to collect, correlate, and analyse security logs from multiple sources.

Alert Filtering and Prioritisation: Implement rules to filter and prioritise security alerts based on severity and risk level.

Regular Log Reviews: Conduct regular reviews of security logs to identify and investigate suspicious activity.

ISO 27001 Templates

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.

Secure Development Policy Example

An example of the ISO 27001 secure development policy.

Reference Resources and FAQs

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

ISO 27001 Annex A 8.31 Strategic Briefing Slides

About the author