ASD ISM 0300 Apply system security patches with approval
What it says
Patches, updates or other vendor mitigations for vulnerabilities in high assurance IT equipment are applied only when approved by ASD, and in doing so, using methods and timeframes prescribed by ASD.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishSecurity patches for critical IT must be approved and applied as directed by ASD.
This control is about making sure that important security updates for IT systems are properly approved and applied. This matters because if critical systems don't get timely updates, they could be exposed to cyber attacks or data breaches, leading to significant business disruption and loss.
Free. Save your status, tasks and notes.
Why it matters
Applying patches to high assurance equipment without ASD approval or prescribed timeframes can cause outages, weaken assurance and leave critical vulnerabilities exploitable.
How to implement
System Owner should understand ASD's guidelines: Identify which of your systems are categorised as high assurance by leveraging the Australian Signals Directorate's recommendations.
Stay informed about the specific procedures ASD requires for any updates.
IT Team should prepare a patch management plan: Draft a clear plan that outlines how and when system patches will be reviewed, approved, and applied based on ASD's schedule.
Make sure this plan includes steps to follow up in case of any issues during updates.
Authorising Officer should approve updates: Ensure the person responsible for approving updates has all relevant information about the patches and understands the risks of delay.
They should sign off either via email or a form on each patch's application.
IT Team should schedule and apply patches: Once patches are approved, the IT team should ensure they are applied within the timeframe given by ASD.
Maintain a log of applied patches, including dates and any issues encountered for future reference.
Someone should monitor the outcomes: Designate someone within the IT team to verify that patches are applied successfully and systems function as expected post-update.
Use feedback mechanisms to quickly identify and rectify any problems.
Keep it running
Coordinate with ASD for patch/mitigation approval for high assurance equipment; implement changes only via ASD-prescribed methods and within mandated timeframes.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
The organisation's patch management policy: Look to see if it mentions ASD's approval requirements for high assurance IT systems.
Good evidence
Includes references to ASD guidelines and documentation showing understanding of required approval processes.
- Check 2 of 5What an auditor asks for
Look at
These records to ensure they have been approved by the authorising officer as per ASD guidelines.
Good evidence
Record should have clear approval notations and show dates patches were applied.
- Check 3 of 5What an auditor asks for
Ask for
Them to explain the steps they follow for applying patches approved by ASD.
Good evidence
Includes detail on how they adhere to ASD methods and timeframes for applying updates.
- Check 4 of 5What an auditor asks for
Look at
Reports or logs showing post-patch testing or monitoring to confirm systems function as expected.
Good evidence
Includes documented checks or test results after updates.
- Check 5 of 5What an auditor asks for
Ask for
Audit logs or systems reviewed for patches.
Look at
Consistency with documented patching schedules and ASD's prescribed timeframes.
Good evidence
Result is seeing regular entries marking when patches were reviewed and applied.
Mappings
Closest match in ISO/IEC 27001: A.8.8, Management of technical vulnerabilities, which this control partially meets.
ISO/IEC 27001: 2 mappings
This control partially meets A.8.8.
Annex A 8.8 requires the organisation to obtain vulnerability information, assess exposure and apply appropriate treatments, including patching and updates. ISM-0300 prescribes a specific patching governance approach for high assurance IT equipment, requiring ASD approval and prescribed methods/timeframes. ISM-0300 is a specialised patch-management treatment that fits within the wider Annex A 8.8 vulnerability management requirement.
This control partially overlaps A.8.32.
ISM-0300 requires an explicit approval mechanism (ASD) and prescribed processes/timeframes before implementing patches or mitigations on high assurance IT equipment. ISO/IEC 27001:2022 Annex A 8.32 requires changes to information systems to follow change management procedures, which would include controlled approval and implementation of patches. The overlap is in governing patching as a controlled change, but ISM-0300 is specifically about ASD approval for high assurance equipment, while Annex A 8.32 is a general organisational change control requirement.
ASD Essential Eight: 2 mappings
This control partially overlaps E8-PO-ML3.5.
ISM-0300 requires that patches, updates or vendor mitigations for vulnerabilities in high assurance IT equipment are only applied when approved by ASD and using ASD-prescribed methods and timeframes. E8-PO-ML3.5 also concerns applying patches (for drivers) and imposes a 48-hour timeframe for critical issues or where exploits exist, which can be relevant where drivers are part of high assurance equipment. However, ISM-0300 is defined by ASD approval and ASD-directed methods for a specific equipment class, while E8-PO-ML3.5 is a general operational timeliness requirement without an external approval gate.
- E8-PO-ML3.8Firmware vulnerabilities patched within one month if non-critical and no exploitsPartially overlaps
This control partially overlaps E8-PO-ML3.8.
ISM-0300 requires that vulnerabilities in high assurance IT equipment are remediated via patches/updates/mitigations only when approved by ASD and in ASD-directed timeframes. E8-PO-ML3.8 requires applying non-critical firmware patches within one month when no exploits exist, which can be part of maintaining high assurance equipment. They overlap on firmware patching activity, but ISM-0300 is driven by ASD approval and prescribed processes rather than the vendor's non-critical classification and a fixed one-month window.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.