How to implement ISO 27001 Annex A 8.31 – A certification bodies guide

Implementing ISO 27001 Annex A 8.31: Separation of Development, Test, and Production Environments

Welcome to the specific control that keeps your IT operations from descending into chaos. If you are new to the standard, ISO 27001 Annex A 8.31 might sound like just another technical hurdle. However, it is actually one of the most practical safeguards you can put in place. At ISO27001.com, we see this control as the bedrock of secure engineering and change management.

Simply put, this control requires you to keep your development, testing, and production environments separate. You need to ensure that the place where you write code is not the same place where you store live customer data. This guide will walk you through how to build this separation and what we, as certification experts, expect to see during an audit.

Why This Separation Matters

Imagine a chef trying to invent a new spicy soup recipe in the same pot that is about to be served to a customer. If the chef adds too much salt during the experiment, the customer’s dinner is ruined. In the world of information security, working on live systems is just as risky.

The goal of Annex A 8.31 is to reduce the risk of unauthorized changes or mistakes hitting your live systems. It protects your production environment from untested code and prevents your sensitive live data from leaking into less secure testing areas.

Step 1: Define Your Environments

You cannot separate what you have not defined. To satisfy this control, you must clearly distinguish between three distinct areas.

First is the Development environment. This is the sandbox. It is where your developers write code, break things, and experiment. It is volatile and changes constantly.

Second is the Test environment. This is often called staging or QA. It should look and feel exactly like your production environment. This is where you verify that the new code works correctly before it goes live.

Third is the Production environment. This is the live system. It is sacred ground. Only fully tested and approved changes should enter here. Availability and integrity are the top priorities in this space.

Step 2: Isolate the Networks and Systems

Once you have defined these roles, you need to enforce them technically. We expect to see logical or physical separation. You should not run your test database on the same server as your live database.

Using cloud services makes this easier. You can use different virtual private clouds or completely different accounts for production and development. This ensures that if a developer accidentally deletes a server in the dev environment, the live website stays online. The separation must be robust enough that an error in one area cannot cascade into another.

Step 3: Control Access and Separation of Duties

This is a critical part that beginners often miss. It is not enough to just have different servers. You must also control who can touch them. In a perfect world, the person who writes the code should not be the same person who deploys it to production.

Developers should have full admin rights in the development environment. However, they should have read-only access (or no access at all) to the production environment. If a developer can change live code on the fly without going through a formal process, you have failed this control.

We understand that in very small startups, strict separation of duties is hard. If everyone has admin access because there are only two of you, you must implement compensating controls. This might include robust logging and a strict “four eyes” policy where one person reviews the other’s work before deployment.

Step 4: Managing Test Data

One of the biggest red flags during an audit involves data privacy. You must not use live personally identifiable information (PII) in your test or development environments. Real customer data belongs in production only.

If you copy your live database to your test environment to troubleshoot a bug, you are creating a massive risk. Test environments usually have weaker security controls. If that data is stolen, you have a breach. You need to use anonymized data, dummy data, or synthetic data for testing. If you absolutely must use production data for a specific test, you need a documented authorization process and you must scrub the data immediately after.

What the Auditor Will Look For

When an auditor from a body like those we work with at ISO27001.com visits you, they will ask for evidence. Being prepared is half the battle.

They will ask to see your network diagrams. These diagrams should clearly show the boundaries between dev, test, and prod. They will verify that these networks are segregated.

They will review your access lists. They will check to see if your developers have write access to production. If they do, be ready to explain why and show the logs that track their activity.

They will also look at your change management tickets. They want to see the story of a software update. They will trace it from development, through a successful test in the staging environment, and finally to its approval for production deployment.

Common Mistakes to Avoid

We often see companies fail because they get lazy with “hotfixes.” This happens when a bug is found in production and a developer logs in directly to fix it, bypassing the test environment. While this solves the immediate problem, it breaks the process and the control. Always follow the path: Dev to Test to Prod.

Another mistake is relying on trust rather than configuration. Do not just tell your staff not to touch production. Remove their access so they cannot touch it even if they try.

Summary

Implementing Annex A 8.31 is about discipline. It builds a wall between your experiments and your business value. By strictly separating your environments, managing access, and sanitizing your test data, you protect the integrity of your systems.

Take the time to configure this correctly now. It will save you from data leaks and system crashes in the future. Plus, it makes your ISO 27001 audit much smoother.