One of the most common ways small businesses accidentally break their own systems is by making changes directly to the live environment. ISO 27001 Annex A 8.31 (Separation of development, test and production environments) is the safety barrier that stops a small coding error from becoming a business disaster.
For a small business, this control is not about buying expensive separate servers. It is about establishing a clear workflow that protects your live customer data from your experimental work.
What is ISO 27001 Annex A 8.31?
Annex A 8.31 requires an organisation to separate its information processing facilities into distinct environments. The goal is to reduce the risk of unauthorised access or changes to the operational (live) system.
Simply put: Do not build or test software in the same place where your customers are transacting.
The Three Environments You Need
To comply with this standard, even a small startup should aim for a three-tier structure. In the age of Cloud computing (AWS, Azure, Google Cloud), this can be done virtually and cheaply.
1. Development Environment (Dev)
This is the “sandpit”. It is where your developers write code and build new features. It is messy and constantly breaking. Rule: No real customer data should ever exist here.
2. Test / Staging Environment
This is a mirror of your live site. It looks and behaves exactly like production but is not accessible to the public. This is where you test updates to ensure they do not crash the system. Rule: Use anonymised or synthetic data here.
3. Production Environment (Live)
This is your “shop front”. It is the live system your customers use. Rule: This environment is locked down. Developers should not have write-access here; changes should only be deployed via a controlled release process.
Why Small Businesses Ignore This (And Why They Shouldn’t)
Small businesses often practice “Cowboy Coding”—editing code directly on the live server to fix issues quickly. While fast, this violates Annex A 8.31 and introduces massive risks:
- The “Oops” Factor: A typo in the code takes your entire website offline.
- Data Leakage: Developers might accidentally expose live customer databases while debugging.
- Performance Hits: Running heavy tests on the live server slows down the website for real customers.
How to Implement Separation on a Budget
You do not need three physical server racks. Here is how small businesses achieve separation effectively:
- Cloud Segmentation: Use different VPCs (Virtual Private Clouds) or separate accounts within your cloud provider to isolate Dev from Prod.
- Access Control: Ensure that the developers who build the code cannot simply “push” it to production without approval. Restrict administrative access to the live environment.
- Visual Cues: Make the environments look different. For example, give the Test environment a red banner or a different background colour so a developer knows instantly they are not in Production.
DO IT YOURSELF
STOP SPANKING £10,000s on CONSULTANTS and ISMS ONLINE PLATFORMS
What the Auditor Will Look For
When auditing a small business for ISO 27001, the auditor will verify that you cannot accidentally break the live system. They will check:
- Segregation: Can a developer log into the live database and delete a table? (The answer should be no).
- The Path to Live: Is there a defined process for moving code from Dev → Test → Prod?
- Data Protection: Is live PII (Personally Identifiable Information) present in the development environment? (This is a major non-conformity).
Summary Checklist for SMEs
- Stop editing live websites or software directly.
- Create a staging site that mimics your live site.
- Restrict access to the live production environment.
- Ensure test environments use dummy data, not live customer data.
- Document the separation in your Secure Development Policy.
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.
