In this guide, I will show you exactly how to implement ISO 27001 Annex A 8.31 and ensure you pass your audit. You will get a complete walkthrough of the control, practical implementation examples, and access to the ISO 27001 templates and toolkit that make compliance easy.
I am Stuart Barker, an ISO 27001 Lead Auditor with over 30 years of experience conducting hundreds of audits. I will cut through the jargon to show you exactly what changed in the 2022 update and provide you with plain-English advice to get you certified.
Key Takeaways: ISO 27001 Annex A 8.31 Separation of Development, Test and Production Environments
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.
Core requirements for compliance include:
- 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”:
- 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).
- The “Oops” Test: They will ask, “If a developer accidentally deletes the database in Dev, does it affect Production?” (The answer must be No).
- 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.
Environment Roles & Access Rules:
| Environment | Purpose | Access Level (Developer) | Data Type | ISO 27001:2022 Control |
|---|---|---|---|---|
| Development | Building & experimenting. | Admin / Full | Synthetic / Fake. | A.8.31 (Separation of dev, test and prod) |
| Test / Staging | QA & Security testing (Pre-prod). | Read-Only (Deployment via Pipeline). | Anonymized / Masked. | A.8.33 (Test data) |
| Production | Live business operations. | None (or Read-Only via “Break Glass” procedure). | Real / Live PII. | A.5.18 (Access rights) |
Table of contents
- Key Takeaways: ISO 27001 Annex A 8.31 Separation of Development, Test and Production Environments
- What is ISO 27001 Annex A 8.31?
- ISO 27001 Annex A 8.31 Explainer Video
- ISO 27001 Annex A 8.31 Podcast
- How to implement ISO 27001 Annex A 8.31
- ISO 27001 Annex A 8.31 Implementation Checklist
- ISO 27001 Annex A 8.31 Audit Checklist
- Applicability of ISO 27001 Annex A 8.31 across different business models.
- Fast Track ISO 27001 Annex A 8.31 Compliance with the ISO 27001 Toolkit
- Conclusion
- ISO 27001 Annex A 8.31 FAQ
- Related ISO 27001 Controls
- Further Reading
- ISO 27001 Annex A 8.31 Strategic Briefing Slides
What is ISO 27001 Annex A 8.31?
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.
ISO 27001 Annex A 8.31 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.
ISO 27001 Annex A 8.31 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
ISO 27001 Annex A 8.31 Explainer Video
In this strategic implementation briefing, Lead Auditor Stuart Barker and team do a deep dive into ISO 27001:2022 Annex A 8.31 Separation of Development, Test and Production Environments.
ISO 27001 Annex A 8.31 Podcast
In this episode: Lead Auditor Stuart Barker and team do a deep dive into the ISO 27001:2022 Annex A 8.31 Separation of Development, Test and Production Environments. The podcast explores what it is, why it is important and the path to compliance.
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.
Implementing ISO 27001 Annex A 8.31 requires a rigorous technical framework to ensure that development, testing, and production activities are logically or physically isolated. This separation mitigates the risk of unauthorized changes, operational interference, and the exposure of sensitive live data to unhardened environments.
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.
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
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 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.
Applicability of ISO 27001 Annex A 8.31 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. |
| 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. |
| 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. |
Fast Track ISO 27001 Annex A 8.31 Compliance with the ISO 27001 Toolkit
For ISO 27001 Annex A 8.31 (Separation of development, test, and production environments), auditors require evidence of segregation rules, not necessarily complex software. The High Table Toolkit provides a permanent, flexible governance framework that avoids the “asset taxes” and rigid schemas of SaaS platforms.
| Compliance Factor | SaaS Platform Risk | High Table Toolkit Advantage |
|---|---|---|
| Ownership | Rented Proof. Environment diagrams and separation policies are often locked in proprietary viewers. Leaving the platform means losing your “proof” of secure architecture. | Permanent Asset. You receive the Secure Development Policy and Environment Separation Guidelines in Word/Excel. You own the evidence of your network security forever. |
| Simplicity | Rule Complication. Requires complex dashboard configurations to define simple rules (e.g., “Developers cannot push to Prod”), adding unnecessary friction. | Focus on Rules. Uses clear, auditor-approved templates. You simply adopt the policy (e.g., requiring Pull Request approvals) and let your team use the tools they already know. |
| Cost | The “Asset Tax”. Costs often spiral based on the number of environments or integrations tracked, punishing you for having a robust, multi-stage infrastructure. | One-Off Fee. A single payment covers the documentation suite regardless of complexity. You save budget for actual infrastructure tools rather than paying to list them. |
| Freedom | Rigid Schemas. SaaS tools often mandate specific tagging or organization methods. If your architecture (e.g., air-gapping, specific VLANs) doesn’t fit, you fight the tool. | Full Flexibility. You describe your separation exactly as it exists. The Statement of Applicability and policies are fully editable to reflect your unique stack (AWS, Azure, or on-prem). |
Summary: For Annex A 8.31, the auditor needs to verify that you have a policy for separation and that you follow it. The High Table ISO 27001 Toolkit gives you that policy instantly. It bridges the gap between your technical team’s actions and the auditor’s checklist, providing a permanent, cost-effective solution without the bloat of an ongoing subscription.
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.
ISO 27001 Annex A 8.31 FAQ
What is the primary requirement of ISO 27001 Annex A 8.31?
ISO 27001 Annex A 8.31 requires that development, testing, and production environments are strictly separated to reduce the risk of unauthorized changes or operational errors. The primary goal is to ensure that “work in progress” code or testing activities never negatively impact the availability or security of live business systems.
Can developers have access to the production environment?
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.
What is the difference between Logical and Physical separation?
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.
How does this control relate to real production data?
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.”
What will an ISO 27001 auditor ask regarding Control 8.31?
Auditors frequently use the “Oops Test” and check your access lists to verify separation. Expect questions such as:
- “If a developer accidentally deletes a database in the Test environment, is it physically possible for that command to affect Production?” (Must be No).
- “Show me the list of users with Admin access to your Production environment.” (Should not include daily developers).
- “Show me the evidence that development tools (compilers, debuggers) are removed from your production servers.”
Does Annex A 8.31 apply to SaaS or Cloud-native companies?
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.
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 Strategic Briefing Slides
