ISO 27001:2022 Annex A 8.31 (Separation of Development, Test and Production Environments) is a mandatory compliance control requiring organizations to physically or logically isolate development, testing, and live operational systems to prevent unauthorized access, data contamination, or production downtime.
In this guide, you will learn how to implement Annex A 8.31 correctly – establishing secure staging tiers, strict access boundaries, and clear infrastructure isolation – with guidance from Lead Auditor Stuart Barker, founder of High Table and author of the ISO 27001 Toolkit.
Table of contents
- Key Takeaways
- ISO 27001 Annex A 8.31 Purpose & Definition
- Separation of Development, Test and Production Environments Guidelines
- How to implement ISO 27001 Annex A 8.31 (Separation of Development, Test and Production Environments)
- ISO 27001 Annex A 8.31 Toolkit & Templates
- How to audit ISO 27001 Annex A 8.31
- Conclusion
- ISO 27002:2022 Control 8.31 (Separation of Development, Test and Production Environments)
- Related ISO 27001:2022 Annex A Controls
- ISO 27001 Annex A 8.31 FAQ
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.
ISO 27001 Annex A 8.31 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
The Consultant-Grade ISMS.
Stop building ISO 27001 from scratch. Steal our playbook. Download the exact, battle-tested documentation a Lead Auditor uses to certify clients. Fully white-labeled, guaranteed to pass, and ready to deploy today.
✓ The complete ISMS
✓ Proven to Pass Certification Audits
✓ 100% White-Label & Brandable
Separation of Development, Test and Production Environments Guidelines
There are seven essential elements of a comprehensive Separation of Development, Test and Production Environments as covered the control guidance in ISO 27002:2022 Control 8.31 (Separation of Development, Test and Production Environments):
- Having development, test and production in separate domains (physical or virtual)
- Having rules that are defined and documented for authorising and implementing the deployment from development to production
- Having a testing environment to test changes to production systems before they are put live
- Not testing in production environments other than via emergency change
- Utility programs and development tools are not accessbile from production
- Labels have identification labels in menus and system displays
- Not transferring sensitive information into development or test without adequate security controls
How to implement ISO 27001 Annex A 8.31 (Separation of Development, Test and Production Environments)
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.
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.
The High Table ISO 27001 Internal Audit.
ISO 27001 strictly requires impartiality – you cannot audit your own work. If you implemented the ISMS, you must use an independent expert before the certification body arrives. Book your ISO 27001 Internal Audit with High Table and let Lead Auditor Stuart Barker’s team guarantee your certification readiness.
✓ 100% Independent & Impartial
✓ Conducted by Certified Lead Auditors
✓ Fixed-Price, Zero-Friction Process
ISO 27001 Annex A 8.31 Toolkit & Templates
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.
Everything a business needs to do ISO 27001 and get ISO 27001 certified in the High Table ISO 27001 Toolkit: Business Edition.
How to audit ISO 27001 Annex A 8.31
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.
ISO 27002:2022 Control 8.31 (Separation of Development, Test and Production Environments)
ISO 27002:2022 Control 8.31 provides implementation guidance for the Separation of Development, Test and Production Environments.
Related ISO 27001:2022 Annex A Controls
The following controls relate directly to ISO 27001 Annex A 8.31:
- 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 a qualified ISO 27001 Lead Auditor and 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).
He is the founder of High Table and the Lead Consultant driving the world’s number 1 dedicated ISO 27001 Consultancy.
