ASD ISM 1816 Prevent unauthorised changes to software sources
What it says
Unauthorised modification of the authoritative source for software is prevented.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishEnsure software source is protected against unauthorised changes to maintain integrity.
This control is about making sure that only the right people can change or update the source of the software your business uses. If just anyone can tamper with it, you might end up with untrustworthy software that could affect everything your business does, leading to financial loss or damaging your reputation.
Free. Save your status, tasks and notes.
Why it matters
If the authoritative software source can be modified, attackers can inject code into builds, compromising released software and systems that deploy it.
How to implement
System owners should ensure that access permissions to the software source are tightly controlled.
This can be done by regularly reviewing who has access and removing anyone who no longer needs it. Use a simple list or tool to track this access.
The IT team should implement version control systems to manage software updates.
This involves clearly tracking changes made to the software, who made them, and ensuring only authorised individuals can apply updates.
Managers should establish a clear policy on software changes.
This means writing down rules that say only approved changes can be made, and that these changes must be documented and reviewed.
Procurement officers should ensure third-party software sources are verified and trustworthy before any purchase.
Check that vendors provide evidence of integrity and security practices, such as certifications or audits.
The IT team should implement automated alerts for any unauthorised attempts to change the software source.
Use tools that notify the team in real-time if unapproved actions are attempted or if there are unusual activities.
Keep it running
Restrict write access to authoritative repos; enforce signed commits/tags and protected branches; require peer review and verify changes before merge.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
A list of individuals with access to software source code: Request documentation of all current access permissions.
Look at
Whether each individual listed is current and authorised.
Good evidence
Shows a dated, regularly reviewed list with justifiable access roles.
- Check 2 of 5What an auditor asks for
Ask for
To see the change management policy: Request a copy of the policy that governs software updates and changes.
Look at
Explicit approval processes and documentation requirements.
Good evidence
Is a clear policy document that's dated and used in practice.
- Check 3 of 5What an auditor asks for
Ask for
Logs from the version control system: Request logs that show who's made changes and when.
Look at
Whether only authorised personnel have modified the software.
Good evidence
Has timestamps, user identification, and shows regular review.
- Check 4 of 5What an auditor asks for
Ask for
Documentation on any third-party software audits: Request proof of vendor security certifications or audit results.
Look at
Recognised standards and recent dates.
Good evidence
Includes current and thorough certification records.
- Check 5 of 5What an auditor asks for
Ask for
Reports on unauthorised access attempts: Request the IT team's reports on any alerts triggered by attempted tampering.
Look at
Evidence of quick detection and response.
Good evidence
Shows resolved alerts with explanations and timestamps.
Mappings
Closest match in ISO/IEC 27001: A.5.15, Access control policies and procedures, which this control partially meets.
ISO/IEC 27001: 3 mappings
This control partially meets A.5.15.
ISM-1816 requires controls to prevent unauthorised changes to the authoritative source for software. Annex A 5.15 complements this by requiring documented access control policies and procedures, essential for managing roles and approvals for who can change software sources. While Annex A 5.15 applies broadly, ISM-1816 specifically targets software source integrity.
This control partially meets A.8.3.
ISM-1816 requires that the authoritative software source, such as source code repositories and release artefacts, is protected to prevent unauthorised modifications. Annex A 8.3 supports this by mandating access restrictions to information and associated assets, which is essential for preventing unauthorised write access to software sources. While Annex A 8.3 is more general, ISM-1816 specifically concerns the integrity of software sources.
This control supports A.8.32.
ISM-1816 is concerned with preventing unauthorised changes to the authoritative software source to maintain integrity. Annex A 8.32 supports this by requiring formal change management for information systems, ensuring that changes to software sources are authorised and traceable. Annex A 8.32 addresses general process governance, whereas ISM-1816 focuses specifically on software source integrity.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.