ISO27001:2022 – A8.31 Separation of development, test and production environments

There are other ISO27001 Annex A controls that talk about the need for segregation in the network (A8.22) and segregation of duties (A5.3), so why do we need another one? 

ISO27001 doesn’t do things by chance, so it’s clearly important that we have segregation of your environments along with people and networks.  You could look at it as the ‘three musketeers’ of segregation; 

• People – Segregation of duties
• Traffic – Segregation of networks
• Environments – Segregation of development, test and production

 All three together form a powerful layered approach to security, you might even call it ‘People, Process, and Technology’!

What does the standard require?

The standard states that “Development, testing and production environments shall be separated and secured..” (A8.31 – Separation of development, test and production environments)

Note that this control doesn’t specific how they are separated, and this will be determined by your approach which should be detailed within your software development lifecycle.

Why is this required?

 The purpose of ISO 27001 – A8.31 is to protect the production environment and data from compromise by development and test activities. It’s not just about the risk of data breach caused by external threats.  If you are developing within your live environments it may lead to system failures or errors as production environments are compromised by systems which interrupt their normal operations.

By using a single environment or an environment which is not properly managed and segregated, it may lead to loss of confidentiality, integrity or availability. Outages and system errors will increase the risk of reputation damage and financial losses.

We worked with a client who suffered a major issue when a developer mistakenly transferred test data into the live environment, corrupting the entire customer database. The mistake could have been avoided if there had been segregation of duties and environments in place. As a result, several clients received incorrect invoices which caused them to call and complain. Reputational damage, loss of productivity and downtime were the impact caused by a simple, avoidable error.

What the auditor is looking for

For ISO 27001 – A8.31, the auditor will expect to see a variety of security measures that might include;

• Segregation of duties (A5.3 – Segregation of Duties)
• Segregation of networks (A8.22 – Segregation of networks)
• Access Control (A5.15 – Access Control)
• Privileged access rights (A5.18 – Access Rights and A8.2 – Privileged access rights)
• Control over the use of utilities (A8.18 – Use of privileged utility programs)
• Software development lifecycle (A8.27 – Secure system architecture and engineering principles)
• Network diagrams (showing the different environments in place and how they are separated)
• Management Review Team (MRT) meeting minutes.
• Risk Register. 

What do you need to do?

Keep in mind that the auditor wants to understand how you have approached this topic in an appropriate way. This means that your first step is to understand how development takes place, and what environments are used.  These will typically fall into the following categories;

• Development – Where code is created for the first time
• Test – Where the application is compiled and then tested for functionality and security
• Pre-prod – also known as the staging Think of it as a ‘dress rehearsal’, where the environment looks very similar to the production environment, and all aspects can be stress-tested.
• Production – also known as the ‘live’ environment, which the end user gets to see.

Segregation of these environments can be achieved in a number of ways, including;

Physical Separation:

This is when you use separate physical hardware for each environment. This is often called ‘air gaped’, indicating that there is physical space (air) between the systems. This is the strongest form of segregation as it is achieved by physically separating the environments, either in different racks, or locations.

Logical Separation

When physical separation isn’t workable or cost effective, you can consider logical separation, using Virtual Machines (VMs) or containers. This creates the ‘illusion’ of segregation, but without the additional overhead of buying additional servers.  The environment resides within a single physical server, but it is logically separated using software.

Network Segmentation

As with ISO27001 Annex A control A8.22 (Segregation of networks), you can separate networks for each environment with firewalls and access controls restricting communication between them.  

Once you understand what form of separation takes place, you need to ensure access controls are in place to ensure only those who need access can have it. For example, your Quality Assurance (QA) team might need access to your test environment, but it is unlikely that they need access to your development or production environment.

If this is not in place, or possible, then you must raise this as a risk on your risk register, and decide on a suitable risk treatment.

Difficulty rating

We rate this a 1.5 out of 5 difficulty rating. Look at the controls already in place for roles and responsibilities, access control and segregation of networks.  This is a control that will require focus and understanding of your business infrastructure. 

Q&A

Can we use the same server for development, test and production?

Yes, but this would need to be separated ‘virtually’ so that the environments sit on the same server, but they act independently of each other. This is cost effective and easily achieved, but you still need to identify the risks in doing this.  For example, what would happen if that server was to fail, or be damaged in some way. Is it backed up? Are ALL the environments backed up effectively.