ISM-1143 ASD Information Security Manual (ISM)

Develop and Maintain Patch Management Procedures

Ensure patches for systems are regularly updated and processes are in place to manage this.

Proactive Non-classified OFFICIAL: Sensitive PROTECTED SECRET TOP SECRET ASD Information Security ManualGuidelines for system management vulnerability management

🏛️ Framework

ASD Information Security Manual (ISM)

🧭 Control effect

Proactive

🔐 Classifications

NC, OS, P, S, TS

🗓️ ISM last updated

Nov 2022

✏️ Control Stack last updated

19 Mar 2026

🎯 E8 maturity levels

N/A

Guideline

Guidelines for system management

Section

System patching

Topic

Patch Management Processes and Procedures

Official control statement

Patch management processes, and supporting patch management procedures, are developed, implemented and maintained.

Source: ASD Information Security Manual (ISM)

Plain language

Patch management is about keeping all your software and systems up-to-date with the latest fixes or updates provided by the software maker. This matters because outdated software can have security weaknesses, which hackers can exploit to steal information or disrupt your business operations.

Why it matters

Without structured patch management, known vulnerabilities remain exploitable, risking unauthorised access and potential data breaches.

Operational notes

Document patch procedures: roles, asset scope, SLAs by severity, testing/rollback and exceptions. Track patch status and audit compliance; use vendor advisories to prioritise.

Implementation tips

IT team should create a patch schedule: The IT team needs to develop a regular timetable for checking and applying new patches. This can be done by setting up reminders or using software tools to automatically alert when updates are available.
Business manager should allocate resources: To ensure effective patching, the business manager needs to allocate time and budget for the IT team to implement patches without delay. This can involve understanding the patch schedule and planning for any downtime needed.
IT team should document patching procedures: The IT team should clearly outline each step of the patching process and who is responsible for each step. Writing down these procedures helps ensure everyone knows what to do and when to do it.
System owners should review critical systems for patches: Each system owner must keep track of their systems and regularly check if there are vital updates or patches available. They can use manufacturer's websites or patch alerts as useful resources.
Managers should ensure training and accountability: Managers should ensure that everyone involved in the patch management process is trained to understand its importance and has clear responsibilities. This can be done through regular training sessions and assigning clear patch management roles.

Audit / evidence tips

Ask: the patch management schedule: Request to see the documented schedule that outlines when and how patches are applied

Good: includes specific dates and names of responsible individuals
Ask: the patching procedure document: Request the documented procedures that describe how patching is carried out
Ask: to see recent patch implementation records: Request recent records showing what patches were applied when, and by whom
Ask: evidence of training sessions: Request documentation of training sessions conducted for patch management

Good: includes regular training sessions with all relevant personnel attending
Ask: a list of non-compliant systems: Request a list of any systems that are pending patches or updates

Good: list will have explanations and plans to address the delay

Cross-framework mappings

How ISM-1143 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.19	Annex A 8.19 requires procedures and measures to securely manage software installation on operational systems
Supports (2)
Annex A 8.8	ISM-1143 requires organisations to develop and maintain patch management processes and procedures to ensure patches are applied in a cont...
Annex A 8.32	Annex A 8.32 establishes the need for change management for system changes

E8

Control	Notes	Details
Partially meets (1)

E8-PA-ML1.4	E8-PA-ML1.4 requires organisations to conduct weekly vulnerability scanning specifically to identify missing patches/updates in key softw...
Supports (5)

E8-AC-ML3.3	E8-AC-ML3.3 requires implementing Microsoft’s vulnerable driver blocklist as a preventative control against vulnerable drivers

E8-PA-ML1.3	E8-PA-ML1.3 requires daily vulnerability scanning to identify missing patches or updates for vulnerabilities in online services
E8-PA-ML3.1	E8-PA-ML3.1 requires a 48-hour remediation outcome for critical or exploited vulnerabilities in a defined set of high-risk applications

E8-PO-ML3.1	E8-PO-ML3.1 requires fortnightly vulnerability scanning to identify missing driver patches or updates
E8-PO-ML3.8	E8-PO-ML3.8 requires organisations to apply non-critical firmware vulnerability patches within one month when no working exploits exist
Depends on (9)

E8-PA-ML1.6	E8-PA-ML1.6 requires organisations to apply non-critical online service patches within two weeks based on vendor criticality and exploit ...
E8-PA-ML2.2	E8-PA-ML2.2 requires timely application of patches/mitigations for non-critical applications within one month

E8-PO-ML1.5	E8-PO-ML1.5 requires critical vendor patches or mitigations to be applied within 48 hours to internet-facing operating systems on servers...
E8-PO-ML1.6	E8-PO-ML1.6 requires a defined patching outcome for a specific scope: non-critical internet-facing OS vulnerabilities must be remediated ...
E8-PO-ML3.3	E8-PO-ML3.3 mandates a time-bound outcome: critical OS vulnerabilities on internal systems are remediated via patches/updates/mitigations...
E8-PO-ML3.4	E8-PO-ML3.4 requires a defined operational outcome: non-critical, non-exploited OS vulnerabilities on internal devices are patched within...
E8-PO-ML3.5	E8-PO-ML3.5 requires organisations to patch critical driver vulnerabilities within 48 hours under defined trigger conditions
E8-PO-ML3.6	E8-PO-ML3.6 requires organisations to deploy non-critical driver patches within one month when no working exploits exist
E8-PO-ML3.7	E8-PO-ML3.7 requires organisations to apply critical firmware patches or mitigations within 48 hours when vendor criticality or working e...