ASD ISM 1696 Apply critical patches within 48 hours
What it says
Patches, updates or other vendor mitigations for vulnerabilities in operating systems of workstations, non-internet-facing servers and non-internet-facing network devices are applied within 48 hours of release when vulnerabilities are assessed as critical by vendors or when working exploits exist.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishApply critical security patches to certain systems within 48 hours to prevent exploits.
This control is about making sure that important security updates, known as critical patches, are installed on certain computer systems within two days of their release. This is crucial because if you delay these updates, it can leave your systems vulnerable to hackers who can exploit these weaknesses and potentially cause damage or loss by accessing sensitive data.
Free. Save your status, tasks and notes.
Why it matters
Failure to apply critical OS patches within 48 hours can allow rapid exploitation, leading to compromise of workstations and internal servers, data loss, and downtime.
How to implement
The IT team should track new critical patches: Set up a system to receive notifications from software vendors about new critical patches.
Tools like email alerts or vendor-specific dashboards can be used to ensure that you're aware of patches as soon as they are released.
The IT manager should prioritise these patches: Organise and assess which systems need urgent updates based on vendor guidance and potential risks.
Use a checklist to identify systems that are the most crucial, such as servers critical to operations, and ensure they are patched first.
System administrators should apply patches directly: Once patches are identified, the system administrators should implement them on the intended systems.
Follow vendor instructions carefully to ensure correct patching, and make sure you're not disrupting business-essential operations during the process.
Office managers should coordinate with IT: Ensure that teams affected by potential downtime due to patching are informed.
Prepare a communication plan so everyone knows what to expect, and consider scheduling updates during off-peak hours to minimise impact.
The IT support team should verify patch installations: After patches are applied, use system reports to confirm that the update was successful.
Check system logs or vendor tools to verify that patches are not only deployed but also active and functioning as expected.
Keep it running
Track vendor advisories and exploit intel; prioritise critical OS patches for workstations and non-internet-facing servers/devices and enforce automated deployment to meet the 48-hour window.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
A list of all critical patches received in the past month: Request records that show notifications received for critical patches from vendors.
Look at
The dates and descriptions to see that these correspond with patches released by vendors.
Good evidence
A comprehensive log showing received patches with timestamps matching vendor releases.
- Check 2 of 5What an auditor asks for
Ask for
The patch prioritisation policy: Request the document or policy which outlines how critical patches are prioritised.
Look at
A clear methodology that explains decision criteria used by the IT team.
Good evidence
A policy document that clearly lists criteria like system criticality and potential risk.
- Check 3 of 5What an auditor asks for
Ask for
Patch implementation records: Request documentation showing when and on which systems the patches were applied.
Look at
Timestamps and system identification that confirms patches were installed within 48 hours.
Good evidence
A report detailing patch application times, affected systems, and responsible personnel.
- Check 4 of 5What an auditor asks for
Ask for
Confirmation communications sent to stakeholders: Request emails or messages sent to stakeholders about patching schedules.
Look at
The details of the communication to ensure they were sent before patch deployment.
Good evidence
Timely distributed communications that outline the expected implementation schedule.
- Check 5 of 5What an auditor asks for
Ask for
System verification logs: Request logs that verify successful patches applications.
Look at
According entries and confirmations in system logs or administrative dashboards.
Good evidence
Logs showing completed patching with no errors and confirmation of system functionality post-update.
Mappings
Closest match in ASD Essential Eight: E8-PO-ML3.3, Apply critical patches to non-internet-facing OS within 48 hours, which asks for the same thing.
ISO/IEC 27001: 2 mappings
This control partially meets A.8.8.
ISM-1696 requires a specific technical vulnerability treatment outcome: applying critical OS patches within 48 hours for defined non-internet-facing systems and workstations when rated critical or exploited. ISO/IEC 27001:2022 Annex A 8.8 requires organisations to obtain information about technical vulnerabilities, evaluate exposure, and take appropriate measures, which includes patching as one possible treatment. ISM-1696 is a prescriptive, time-bound implementation that fits within the broader vulnerability management expectation of Annex A 8.8.
This control depends on A.5.7.
ISM-1696 requires applying critical OS patches within 48 hours when vendors assess vulnerabilities as critical or when working exploits exist. ISO/IEC 27001:2022 Annex A 5.7 requires collecting and analysing threat information to produce threat intelligence, which can inform whether working exploits exist and drive prioritisation decisions for patching. Annex A 5.7 does not require patch application, but it strengthens the decision inputs and triggers that help organisations meet ISM-1696 timeframes.
ASD Essential Eight: 7 mappings
This control is equivalent to E8-PO-ML3.3.
ISM-1696 requires critical patches, updates or vendor mitigations for operating systems on workstations, non-internet-facing servers and non-internet-facing network devices to be applied within 48 hours when rated critical or when working exploits exist. E8-PO-ML3.3 states the same 48-hour requirement for the same system scope and the same triggering conditions (vendor-critical or working exploit). Implementing E8-PO-ML3.3 would largely satisfy ISM-1696 and vice versa.
This control partially overlaps E8-PO-ML1.5.
ISM-1696 requires applying critical OS patches within 48 hours for workstations, non-internet-facing servers and non-internet-facing network devices when vendors rate vulnerabilities critical or working exploits exist. E8-PO-ML1.5 also mandates a 48-hour patch window under the same critical/exploit conditions, but it applies to internet-facing servers and internet-facing network devices. They align on urgency and decision triggers, but differ materially on asset exposure scope (internet-facing versus non-internet-facing/workstations).
- E8-PO-ML1.7One-month operating system patching for workstations, non-internet-facing servers and network devicesPartially overlaps
This control partially overlaps E8-PO-ML1.7.
E8-PO-ML1.7 requires operating system patches for workstations, non-internet-facing servers and non-internet-facing network devices to be applied within one month of release, while ISM-1696 requires patches for the same systems within 48 hours where vendors assess vulnerabilities as critical or working exploits exist. They share the same assets and activity, but ISM-1696 imposes a much shorter deadline for that subset and E8-PO-ML1.7 also covers non-critical vulnerabilities.
This control partially overlaps E8-PO-ML3.4.
E8-PO-ML3.4 sets a one-month patching requirement for non-critical OS vulnerabilities on non-internet-facing workstations/servers/network devices when no working exploits exist. ISM-1696 covers the same OS and internal asset scope, but applies to the different condition of critical vendor ratings or the existence of working exploits, with a much shorter 48-hour timeframe. They intersect on the same patch management activity and assets, but address different severity/exploit scenarios and therefore are complementary rather than equivalent.
This control depends on E8-PO-ML1.1.
ISM-1696 requires critical OS patches to be applied within 48 hours for workstations and non-internet-facing servers and network devices when rated critical or exploited. E8-PO-ML1.1 requires automated asset discovery at least fortnightly to ensure assets are known for subsequent vulnerability scanning, which underpins the ability to identify where critical patches must be applied. Without asset discovery, organisations can miss unmanaged endpoints and fail to meet ISM-1696 timeframes for all in-scope systems.
This control depends on E8-PO-ML1.2.
ISM-1696 requires rapid application of critical OS patches within 48 hours for specified non-internet-facing systems and workstations based on vendor criticality or working exploits. E8-PO-ML1.2 requires using a vulnerability scanner with an up-to-date database, which is a prerequisite capability to accurately identify and prioritise missing critical patches and known exploited vulnerabilities. While ISM-1696 is about patch deployment, it is dependent on reliable, current vulnerability intelligence/tooling like E8-PO-ML1.2 to drive timely action and provide assurance coverage.
This control depends on E8-PO-ML1.4.
ISM-1696 requires organisations to apply critical operating system patches within 48 hours for workstations and non-internet-facing servers and network devices when vendors rate issues critical or working exploits exist. E8-PO-ML1.4 requires fortnightly vulnerability scanning to identify missing OS patches on the same asset classes, which provides an operational mechanism to detect patch gaps and validate patch compliance. While scanning does not itself meet the 48-hour patching requirement, ISM-1696 is practically dependent on discovery/verification activities like E8-PO-ML1.4 to reliably identify missing critical patches across the environment.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.