## 8.31 Separation of development, test and production environments

| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains |
| --- | --- | --- | --- | --- |
| #Preventive | #Confidentiality #Integrity #Availability | #Protect | #Application_security #System_and_network_security | #Protection |

**Control**
Development, testing and production environments should be separated and secured.

**Purpose**
To protect the production environment and data from compromise by development and test activities. 

**Guidance**
The level of separation between production, testing and development environments that is necessary to prevent production problems should be identified and implemented.

  

The following items should be considered:

  

a\) adequately separating development and production systems and operating them in different domains (e.g. in separate virtual or physical environments);

  

b\) defining, documenting and implementing rules and authorization for the deployment of software from development to production status;

  

c\) testing changes to production systems and applications in a testing or staging environment prior to being applied to production systems (see [8.29](a-8.29-Security-testing-in-development-and-acceptance.md));

  

d\) not testing in production environments except in circumstances that have been defined and approved;

  

e\) compilers, editors and other development tools or utility programs not being accessible from production systems when not required;

  

f\) displaying appropriate environment identification labels in menus to reduce the risk of error;

  

g\) not copying sensitive information into the development and testing system environments unless equivalent controls are provided for the development and testing systems.

  

In all cases, development and testing environments should be protected considering:

  

a\) patching and updating of all the development, integration and testing tools (including builders, integrators, compilers, configuration systems and libraries);

  

b\) secure configuration of systems and software;

  

c\) control of access to the environments;

  

d\) monitoring of change to the environment and code stored therein;

  

e\) secure monitoring of the environments;

  

f\) taking backups of the environments.

  

A single person should not have the ability to make changes to both development and production without prior review and approval. This can be achieved for example through segregation of access rights or through rules that are monitored. In exceptional situations, additional measures such as detailed logging and real-time monitoring should be implemented in order to detect and act on unauthorized changes.

  

**Other information**

Without adequate measures and procedures, developers and testers having access to production systems can introduce significant risks (e.g. unwanted modification of files or system environment, system failure, running unauthorized and untested code in product ion systems, disclosure of confidential data, data integrity and availability issues). There is a need to maintain a known and stable environment in which to perform meaningful testing and to prevent inappropriate developer access to the production environment.

  

Measures and procedures include carefully designed roles in conjunction with implementing segregation of duty requirements and having adequate monitoring processes in place.

  

Development and testing personnel also pose a threat to the confidentiality of production information. Development and testing activities can cause unintended changes to software or information if they share the same computing environment. Separating development, testing and production environments is therefore desirable to reduce the risk of accidental change or unauthorized access to production software and business data (see >8.33for the protection of test information).

  

In some cases, the distinction between development, test and production environments can be deliberately blurred and testing can be carried out in a development environment or through controlled rollouts to live users or servers (e.g. small population of pilot users). In some cases, product testing can occur through live use of the product inside the organization. Furthermore, to reduce downtime of live deployments, two identical production environments can be supported where only one is live at any one time.

  

Supporting processes for the use of production data in development and testing environments (>8.33>) are necessary.

  

Organizations can also consider the guidance provided in this section for training environments when conducting end user training.