Segregation of Environments in Software Development
Development areas are kept separate to enhance security and efficiency in software projects.
🏛️ Framework
ASD Information Security Manual (ISM)
🧭 Control effect
Preventative
🔐 Classifications
NC, OS, P, S, TS
🗓️ ISM last updated
Feb 2025
✏️ Control Stack last updated
22 Feb 2026
🎯 E8 maturity levels
N/A
Development, testing, staging and production environments are segregated.
Source: ASD Information Security Manual (ISM)
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.
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
-
Ask: a network diagram showing separate environments: Request the IT department provide a diagram that illustrates how their development, testing, staging, and production environments are segregated
Good: A detailed diagram with annotations explaining which parts of the system belong to development, testing, staging, and production
-
Good: A document that specifies the need for testing and manager approval before changes can go live, with dates of reviews
-
Ask: logging and monitoring reports from each environment: Request reports that show who has accessed each environment and what changes were made
Good: Detailed logs showing regular access reviews and documented responses to any suspicious activity
-
Ask: to see records of training conducted for staff on how to use these separate environments properly
Good: Signed attendance sheets and detailed training content that explains the importance of environment segregation
-
Ask: a list of approved software tools used in each environment: This ensures that only necessary and authorised tools are in use in each environment
Good: An 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.
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.
ISO 27001
| Control | Notes | Details |
|---|---|---|
| Partially overlaps (1) | ||
| Annex A 8.31 | ISM-0400 requires organisations to segregate development, testing, staging and production environments | |
| Supports (1) | ||
| 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... | |