Segregation of Environments in Software Development
Development areas are kept separate to enhance security and efficiency in software projects.
Plain language
In software projects, you need to keep different work areas separate, like development, testing, and live use. This is important because mixing them up can cause mistakes that lead to data being lost, functions not working properly, or sensitive information leaking out.
Framework
ASD Information Security Manual (ISM)
Control effect
Preventative
Classifications
NC, OS, P, S, TS
ISM last updated
Feb 2025
Control Stack last updated
19 Mar 2026
E8 maturity levels
N/A
Guideline
Guidelines for software developmentOfficial control statement
Development, testing, staging and production environments are segregated.
Why it matters
Mixing development, test, staging and production can cause unsafe changes, data loss, and breaches, disrupting operations.
Operational notes
Audit access and network paths regularly, and enforce separate accounts, data sets and CI/CD pipelines for each environment.
Implementation tips
- The IT team should create separate spaces for development, testing, and live use. They can do this by setting up different servers or virtual environments for each stage of software work.
- System managers should enforce rules that prevent software changes from being made directly to the live environment without testing. They can establish a process that requires each change to be tested and approved before going live.
- The development team should use version control systems to manage changes independently in different environments. This means setting up tools like Git to ensure that changes can be tested in isolation without affecting the live system.
- Project managers should regularly check that no one is using the wrong environment for a task. They can do this by reviewing logs and access records to ensure team members are working in the correct spaces.
- Business owners should have an overview session where the IT team explains how separating environments helps prevent accidental data loss or errors. They should also highlight any business impacts such as improved reliability and reduced downtime.
Audit / evidence tips
-
Aska network diagram showing separate environments: Request the IT department provide a diagram that illustrates how their development, testing, staging, and production environments are segregated
GoodA detailed diagram with annotations explaining which parts of the system belong to development, testing, staging, and production
-
GoodA document that specifies the need for testing and manager approval before changes can go live, with dates of reviews
-
Asklogging and monitoring reports from each environment: Request reports that show who has accessed each environment and what changes were made
GoodDetailed logs showing regular access reviews and documented responses to any suspicious activity
-
Askto see records of training conducted for staff on how to use these separate environments properly
GoodSigned attendance sheets and detailed training content that explains the importance of environment segregation
-
Aska list of approved software tools used in each environment: This ensures that only necessary and authorised tools are in use in each environment
GoodAn updated list signed off by management with clear distinctions on which tools can be used where
Cross-framework mappings
How ISM-0400 relates to controls across ISO/IEC 27001, Essential Eight, and ASD ISM.
ISO 27001
| Control | Notes | Details |
|---|---|---|
| sync_alt Partially overlaps (1) expand_less | ||
| Annex A 8.31 | ISM-0400 requires organisations to segregate development, testing, staging and production environments | |
| handshake Supports (1) expand_less | ||
| Annex A 8.29 | Annex A 8.29 requirements for embedding security testing in development life cycles are supported by ISM-0400, which prescribes environme... | |
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.