ISO 27001:2022 Annex A 8.31 Separation of development, test and production environments for SMEs

In this guide, I will show you exactly how small businesses and SMEs can implement ISO 27001:2022 Annex A 8.31 Separation of development, test and production environments without the enterprise-level complexity. You will get a complete walkthrough of the control tailored for organizations with limited resources, along with practical examples and access to ISO 27001 templates that make compliance easy.

I am Stuart Barker, an ISO 27001 Lead Auditor with over 30 years of experience auditing businesses of all sizes. I will cut through the jargon to show you exactly what changed in the 2022 update and provide the plain-English advice you need to get your small business certified.

Key Takeaways: ISO 27001 Annex A 8.31 Separation of Development, Test, and Production Environments (SME Edition)

For Small and Medium-sized Enterprises (SMEs), ISO 27001 Annex A 8.31 addresses the risk of accidental disaster. Small businesses often make changes directly to live systems (“Cowboy Coding”) to fix issues quickly, but this is the fastest way to accidentally delete customer data or take your website offline. This control mandates a strict separation between where you build code (Dev), where you test it (Test), and where your customers actually use it (Production).

Core requirements for compliance include:

• Virtual Separation: You do not need expensive physical servers. Using separate cloud accounts (e.g. distinct AWS accounts) or Virtual Private Clouds (VPCs) is sufficient to isolate environments.
• The “No Live Data” Rule: Developers should never use real customer data (PII) in the development or test environments. Use anonymised or dummy data to prevent GDPR breaches during testing.
• Restricted Access: Developers should not have “write” access to the live Production environment. Changes should be deployed via a controlled release process, not by a developer logging in and typing commands.
• Visual Cues: Make environments look different (e.g. give the Test site a red banner). This prevents the “Oops” factor where a developer thinks they are deleting test data but is actually wiping the live database.
• The Path to Live: Establish a one-way workflow. Code moves from Dev -> Test -> Production. It never goes backwards, and you never edit Production directly.

Audit Focus: Auditors will look for “The Safety Barrier”:

1. The Segregation Check: “Can your junior developer log into the live database right now and delete a table?” (The answer must be no).
2. The Data Check: “Show me the data in your Test environment. Is that a real customer’s name and address?” (If yes, it is a non-conformity).
3. The Deploy Process: “Show me the record of your last software release. Who approved it moving from Test to Live?”

SME Environment Matrix (Audit Prep):

Environment	Purpose	Access Rule	Data Rule
Development	Building new features (“The Sandpit”).	Open to Developers.	Dummy Data Only.
Test / Staging	Verifying updates before release.	Open to Testers/Devs.	Anonymised Data.
Production	Live customer transactions (“The Shop”).	Locked Down (Admins only).	Real Live Data.

What is ISO 27001 Annex A 8.31 for SMEs?

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.

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.

Fast Track ISO 27001 Annex A 8.31 Compliance for SMEs with the ISO 27001 Toolkit

For Small Businesses and SMEs, 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. One of the most common ways small firms break their own systems is by making changes directly to the live environment. This control ensures you do not build or test software in the same place where your customers are transacting.

While SaaS compliance platforms often try to sell you “automated environment monitoring” or complex “CI/CD integration dashboards”, they cannot actually define the workflow that protects your live data or ensure your developers do not have “cowboy coding” access to production. Those are human governance and operational tasks. The High Table ISO 27001 Toolkit is the logical choice for SMEs because it provides the separation framework you need without a recurring subscription fee.

1. Ownership: You Own Your Environment Governance Forever

SaaS platforms act as a middleman for your compliance evidence. If you define your environment segregation rules and store your deployment logs inside their proprietary system, you are essentially renting your own operational safety.

• The Toolkit Advantage: You receive the Secure Development Policy and Deployment Checklists in fully editable Word formats. These files are yours forever. You maintain permanent ownership of your standards, such as specific rules for cloud segmentation, ensuring you are always ready for an audit without an ongoing “rental” fee.

2. Simplicity: Governance for Real-World Segregation

Annex A 8.31 is about establishing a clear path from Dev to Prod. You do not need a complex new software interface to manage what a well-structured cloud configuration and a formal release process already do perfectly.

• The Toolkit Advantage: SMEs need to achieve separation on a budget. What they need is the governance layer to prove to an auditor that live PII is not present in development. The Toolkit provides pre-written “Environment Checklists” and “Visual Cue Guidelines” that formalise your existing virtualised setup into an auditor-ready framework, without forcing your team to learn a new software platform just to log a deployment.

3. Cost: A One-Off Fee vs. The “Environment” Tax

Many compliance SaaS platforms charge more based on the number of “environments”, “virtual private clouds”, or “repositories” you monitor. For a small startup using Cloud computing, these monthly costs can scale aggressively for very little added value.

• The Toolkit Advantage: You pay a single, one-off fee for the entire toolkit. Whether you have 3 environments or 30, the cost of your Separation Documentation remains the same. You save your budget for actual cloud resources rather than an expensive compliance dashboard.

4. Freedom: No Vendor Lock-In for Your Deployment Strategy

SaaS tools often mandate specific ways to report on and monitor “environment segregation”. If their system does not match your unique cloud provider (AWS, Azure, Google Cloud) or specialised release cycle, the tool becomes a bottleneck to efficiency.

• The Toolkit Advantage: The High Table Toolkit is 100% technology-agnostic. You can tailor the Separation Procedures to match exactly how you operate, whether you use separate cloud accounts or simple VPC segmentation. You maintain total freedom to evolve your deployment strategy without being constrained by the technical limitations of a rented SaaS platform.

Summary: For SMEs, the auditor wants to see proof that developers cannot log into the live database to delete tables and that there is a defined process for moving code through distinct environments. The High Table ISO 27001 Toolkit provides the governance framework to satisfy this requirement immediately. It is the most direct, cost-effective way to achieve compliance using permanent documentation that you own and control.