Ensure Software Changes Occur in Development Environments
Software changes should only be done in a development environment to prevent issues in production.
Plain language
When a company changes its software, it should only do so in a special area called a 'development environment' and not directly on the software that everyone uses every day. This is important because making changes on the live system can lead to unexpected problems or even outages, potentially costing money and reputation.
Framework
ASD Information Security Manual (ISM)
Control effect
Preventative
Classifications
NC, OS, P, S, TS
ISM last updated
Aug 2018
Control Stack last updated
19 Mar 2026
E8 maturity levels
N/A
Guideline
Guidelines for software developmentOfficial control statement
Development and modification of software only takes place in development environments.
Why it matters
Making software changes directly in production increases outage and data-loss risk and can bypass testing and approvals, causing service disruption and reputational damage.
Operational notes
Restrict code changes to development environments; require change records and CI/CD promotion to test/UAT before production, and monitor for unauthorised production edits.
Implementation tips
- The IT team should set up a development environment: Create a separate and safe place where software changes can be made and tested without affecting everyday business operations. This might involve using a separate server or cloud space that mimics the live system.
- Managers should ensure that their team only uses the development environment for making software changes: Regularly remind staff during team meetings and onboarding of the importance of this process for avoiding mistakes in the live system.
- The IT team should maintain a logbook of changes: Document each change made in the development environment, including who made the change and when. Use a simple spreadsheet or software that tracks changes automatically to make this task easier.
- System and software users should report issues immediately to the IT team: Encourage staff to speak up if they notice anything odd in the software, as early detection of problems can prevent bigger issues later.
- Procurement managers should involve the IT team in software purchasing decisions: Ensure new software is compatible with existing systems and allows for changes to be tested in a development environment.
Audit / evidence tips
- AskThe list of software systems and environments used: Request a document that outlines all software systems and their respective environments in use GoodShows clear separation and documentation of purpose for each environment
- AskRecent logs of software changes GoodRecord shows changes only in the development environment, with clear timestamps and responsible personnel
- AskTo see policies or staff training materials regarding development environments GoodIs having up-to-date materials that have been reviewed annually
- AskTo view a demonstration of the development process: Request to see how a typical software change is made and tested. Good practice shows a well-structured process with clear handovers from development to production, ensuring no direct changes are made to live systems
- AskReports detailing incidents or issues in the last year GoodSituation is where no issues have occurred due to changes being tested thoroughly in development first
Cross-framework mappings
How ISM-1419 relates to controls across ISO/IEC 27001, ISO/IEC 42001, Essential Eight, and ASD ISM.
ISO 27001
| Control | Notes | Details |
|---|---|---|
| layers Partially meets (2) expand_less | ||
| Annex A 8.25 | ISM-1419 requires that development and modification of software only occurs in development environments to avoid uncontrolled changes in ... | |
| Annex A 8.32 | ISM-1419 requires that software development and modification occur only in development environments, preventing ad-hoc production changes | |
| sync_alt Partially overlaps (1) expand_less | ||
| Annex A 8.19 | ISM-1419 requires that software changes are performed in development environments rather than on operational systems | |
| handshake Supports (3) expand_less | ||
| Annex A 8.4 | ISM-1419 requires software changes to occur only in development environments, reducing the likelihood of unauthorised or uncontrolled pro... | |
| Annex A 8.9 | ISM-1419 requires that development and modification of software only occurs in development environments, limiting configuration drift and... | |
| Annex A 8.29 | ISM-1419 requires software changes to be performed only in development environments rather than directly in production | |
| link Related (1) expand_less | ||
| Annex A 8.31 | ISM-1419 requires development and modification of software to occur only in development environments, to protect production integrity | |
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.