Imagine a chef trying to invent a new spicy soup recipe in the same pot that is currently serving customers in the dining room. One wrong move with the chilli powder, and the dinner service is ruined. In the world of information security, this is exactly what ISO 27001:2022 Annex A 8.31 tries to prevent.
This control is about setting boundaries. It ensures that the creative chaos of development doesn’t accidentally crash your stable, revenue-generating production systems. It is one of the most fundamental controls for any business developing its own software or managing complex IT infrastructure.
Table of contents
What is the Core Objective?
The goal of Annex A 8.31 is relatively simple: stop your testing activities from breaking your live environment and stop your live data from leaking into your testing environment. It mandates that development, testing, and production environments should be separated to reduce the risks of unauthorized access or changes to the operational system.
If a developer makes a mistake in the code, you want that error to happen in a safe, isolated sandbox—not on the server that processes your client’s payments.
Step-by-Step Implementation Guide
Implementing this doesn’t require you to build three separate physical data centres. In the age of cloud computing, logical separation is often enough, provided it is robust. Here is how to get it done.
1. Establish Clear Boundaries
You need to define what “Development,” “Test,” and “Production” actually mean for your organization and ensure they are isolated from one another. In a cloud environment like AWS or Azure, this usually means using separate accounts or distinct virtual private clouds (VPCs) with strict firewall rules preventing traffic between them.
As the experts at Hightable.io suggest, while physical separation was the gold standard in the past, logical separation is now the norm. The key is ensuring that a compromise in your development environment cannot be used as a stepping stone to jump laterally into your production network.
2. Lock Down Production Access
One of the hardest habits to break in smaller teams is allowing developers to have “admin” access to production servers “just in case” they need to fix a bug quickly. This is a major security risk.
Under Annex A 8.31, developers should rarely, if ever, have write access to the live environment. Access should be restricted to system administrators or automated deployment tools. If a developer needs to investigate a production issue, they should be granted temporary, monitored access—often referred to as “break-glass” access.
3. Quarantine Your Tools
Your production environment should be lean. It exists to run the application, not to build it. This means you should remove any tools that aren’t strictly necessary for the application to run.
Compilers, code editors, and debuggers are essential in development but dangerous in production. If a hacker gains access to a server that has a compiler installed, they can easily build and run malicious exploits. Hightable.io highlights this as a critical “non-negotiable” rule: quarantine your tools. Keep the builders in the workshop and the finished product in the showroom.
4. Protect Production Data
This is where many companies fail their audit. It is very tempting to copy your live database into your test environment because it gives you “real” data to work with. However, this often violates data protection laws (like GDPR) and spreads sensitive information into environments that are generally less secure.
Instead of copying live data, use anonymised or synthetic data for testing. If you absolutely must use production data for a specific test, it must be sanitized (stripped of sensitive identifiers) before it leaves the production environment, and it should be deleted immediately after testing is complete.
DO IT YOURSELF
STOP SPANKING £10,000s on CONSULTANTS and ISMS ONLINE PLATFORMS
Common Pitfalls to Avoid
Even with good intentions, implementation can go wrong. Watch out for these common mistakes:
- The “Staging” Trap: Treating a staging environment as a “quasi-production” environment where security rules are relaxed. Staging should mirror production security exactly.
- Shared Credentials: Using the same API keys or passwords for databases in both Dev and Prod. If a developer accidentally commits a key to GitHub, you don’t want it to unlock your live customer database.
- Lack of Documentation: You can have perfect separation, but if you can’t prove it to an auditor, you will fail. Maintain network diagrams and user access lists that clearly show the separation.
A Quick Checklist for Annex A 8.31
Before your external audit, run through this list to ensure you are ready:
- Are development, test, and production environments logically or physically segregated?
- Have you removed compilers and development tools from production servers?
- Is there a documented process for moving code from Dev to Test to Prod?
- Are developers restricted from making unauthorized changes to production?
- Is production data protected from being copied into lower environments without sanitization?
- Do you have unique login credentials for each environment?
By following these steps, you not only satisfy the ISO 27001 auditor but also build a more resilient and professional engineering culture. Separation of duties isn’t just compliance; it’s just good engineering.
About the author
Stuart Barker is a veteran practitioner with over 30 years of experience in systems security and risk management.
Holding an MSc in Software and Systems Security, Stuart combines academic rigor with extensive operational experience. His background includes over a decade leading Data Governance for General Electric (GE) across Europe, as well as founding and exiting a successful cyber security consultancy.
As a qualified ISO 27001 Lead Auditor and Lead Implementer, Stuart possesses distinct insight into the specific evidence standards required by certification bodies. He has successfully guided hundreds of organizations – from high-growth technology startups to enterprise financial institutions – through the audit lifecycle.
His toolkits represents the distillation of that field experience into a standardised framework. They move beyond theoretical compliance, providing a pragmatic, auditor-verified methodology designed to satisfy ISO/IEC 27001:2022 while minimising operational friction.
