ASD ISM 1143 Develop and maintain patch management procedures
What it says
Patch management processes, and supporting patch management procedures, are developed, implemented and maintained.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishEnsure patches for systems are regularly updated and processes are in place to manage this.
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.
Free. Save your status, tasks and notes.
Why it matters
Without structured patch management, known vulnerabilities remain exploitable, risking unauthorised access and potential data breaches.
How to implement
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.
Keep it running
Document patch procedures: roles, asset scope, SLAs by severity, testing/rollback and exceptions. Track patch status and audit compliance; use vendor advisories to prioritise.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
The patch management schedule: Request to see the documented schedule that outlines when and how patches are applied.
Look at
Regular intervals and responsible parties identified.
Good evidence
Includes specific dates and names of responsible individuals.
- Check 2 of 5What an auditor asks for
Ask for
The patching procedure document: Request the documented procedures that describe how patching is carried out.
Look at
The steps outlined to see if they are clear and comprehensive. Good documentation will have step-by-step guidance and assigned roles.
- Check 3 of 5What an auditor asks for
Ask for
To see recent patch implementation records: Request recent records showing what patches were applied when, and by whom.
Look at
Dates, times, and responsible persons for each patch activity. Good records are detailed and cover all systems or applications affected.
- Check 4 of 5What an auditor asks for
Ask for
Evidence of training sessions: Request documentation of training sessions conducted for patch management.
Look at
Attendance records and training content.
Good evidence
Includes regular training sessions with all relevant personnel attending.
- Check 5 of 5What an auditor asks for
Ask for
A list of non-compliant systems: Request a list of any systems that are pending patches or updates.
Look at
Reasons why they have not been patched.
Good evidence
List will have explanations and plans to address the delay.
Mappings
Closest match in ASD Essential Eight: E8-PA-ML1.4, Weekly scanning for missing patches or updates in key software, which this control covers in full and more.
ISO/IEC 27001: 3 mappings
This control partially meets A.8.8.
ISM-1143 requires organisations to develop and maintain patch management processes and procedures to ensure patches are applied in a controlled way. ISO/IEC 27001:2022 Annex A 8.8 supports this by requiring the organisation to obtain information about technical vulnerabilities, assess exposure, and take appropriate measures-patching being a primary measure. Annex A 8.8 is broader vulnerability management, while ISM-1143 is specifically about the procedural and operational mechanics of patching.
This control partially overlaps A.8.19.
Annex A 8.19 requires procedures and measures to securely manage software installation on operational systems. ISM-1143 overlaps by requiring patch management processes and procedures, which are a major category of software installation activity (installing updates/patches) requiring secure handling. ISM-1143 is focused specifically on patching governance, while Annex A 8.19 covers the wider installation of software (new installs, upgrades, components) beyond patches.
This control depends on A.8.32.
Annex A 8.32 establishes the need for change management for system changes. ISM-1143 provides support by focusing on patch management, a key aspect of system changes that adheres to Annex A 8.32's procedural requirements.
ASD Essential Eight: 16 mappings
This control is broader than E8-PA-ML1.4.
E8-PA-ML1.4 requires organisations to conduct weekly vulnerability scanning specifically to identify missing patches/updates in key software categories. ISM-1143 requires establishing and maintaining patch management processes and procedures, which would typically include how scanning identifies patch gaps and triggers remediation. E8-PA-ML1.4 is one specific operational activity within the broader patch management governance required by ISM-1143.
This control is broader than 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. ISM-1143 requires patch management processes and procedures to be developed, implemented and maintained, which supports the operational capability (intake, triage, testing, deployment, and exception handling) needed to consistently meet and evidence the 48-hour application patching SLA. ISM-1143 is procedural/governance-focused and does not specify the application categories or the 48-hour critical/exploited trigger set by E8-PA-ML3.1.
This control is broader than E8-PO-ML3.1.
E8-PO-ML3.1 requires fortnightly vulnerability scanning to identify missing driver patches or updates. ISM-1143 requires patch management processes and procedures to be developed, implemented and maintained. E8-PO-ML3.1 supports ISM-1143 by providing an operational mechanism for detecting driver patch gaps that patch procedures should address. However, it does not itself define the broader procedural governance ISM-1143 expects.
- E8-PO-ML3.8Firmware vulnerabilities patched within one month if non-critical and no exploitsBroader than
This control is broader than 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. ISM-1143 supports this by requiring documented and maintained patch management processes and procedures, which underpin consistent execution and tracking of the one-month firmware patch window. ISM-1143 is procedural and governance-focused, whereas E8-PO-ML3.8 is a specific operational requirement for firmware vulnerabilities.
This control supports 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 availability. ISM-1143 requires patch management processes and supporting procedures to be developed, implemented and maintained, which are necessary to operationalise consistent two-week patch deployment for online services. E8-PA-ML1.6 is a specific performance expectation, while ISM-1143 is the governance/process prerequisite to achieve it at scale.
This control supports E8-PA-ML1.7.
ISM-1143 requires patch management processes and supporting procedures to be developed, implemented and maintained, while E8-PA-ML1.7 requires patches for office productivity suites, web browsers and their extensions, email clients, PDF software and security products to be applied within two weeks of release. E8-PA-ML1.7 depends on the patch management process from ISM-1143 to deliver patches within its timeframe, although ISM-1143 does not itself set any timeframe.
This control supports E8-PA-ML2.2.
E8-PA-ML2.2 requires timely application of patches/mitigations for non-critical applications within one month. ISM-1143 is a prerequisite by requiring patch management processes and procedures to be developed, implemented and maintained to drive consistent patch identification, testing, scheduling and deployment. ISM-1143 is broader (governance and process), while E8-PA-ML2.2 sets a specific patching outcome and timeframe.
This control supports 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 and network devices when critical or exploited. ISM-1143 requires patch management processes and supporting procedures to be developed, implemented and maintained. Those defined processes (e.g., prioritisation, emergency change, testing exceptions, and verification) are generally necessary to reliably achieve the specific 48-hour requirement in E8-PO-ML1.5.
- E8-PO-ML1.6Timely application of non-critical patches for internet-facing OS vulnerabilitiesSupports
This control supports 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 within two weeks when no working exploits exist. ISM-1143 requires that patch management processes and procedures are developed, implemented and maintained. Effective compliance with E8-PO-ML1.6 is dependent on having the patch governance, workflow, and supporting procedures required by ISM-1143 to consistently meet the two-week SLA.
- E8-PO-ML1.7One-month operating system patching for workstations, non-internet-facing servers and network devicesSupports
This control supports E8-PO-ML1.7.
ISM-1143 requires patch management processes and supporting procedures to be developed, implemented and maintained, while E8-PO-ML1.7 requires operating system patches on workstations, non-internet-facing servers and non-internet-facing network devices to be applied within one month of release. Consistently meeting the one-month deadline relies on the patch management process that ISM-1143 establishes, although ISM-1143 itself sets no timeframe.
This control supports 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 within 48 hours. ISM-1143 requires an organisation to establish and maintain patch management processes and procedures, which are a prerequisite to reliably triage criticality, schedule changes, and drive patch deployment within that timeframe. ISM-1143 is broader and more procedural, while E8-PO-ML3.3 is a specific operational performance requirement focused on OS and a 48-hour window.
This control supports 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 one month. ISM-1143 requires organisations to develop, implement and maintain patch management processes and procedures that govern how patching decisions and actions occur. In practice, consistently meeting E8-PO-ML3.4 at scale depends on ISM-1143-style procedures (intake, assessment, scheduling, approvals and verification), even though ISM-1143 does not mandate the specific one-month SLA.
This control supports E8-PO-ML3.5.
E8-PO-ML3.5 requires organisations to patch critical driver vulnerabilities within 48 hours under defined trigger conditions. ISM-1143 requires patch management processes and procedures to be developed, implemented and maintained. Those procedures (triage, testing, deployment, exception handling) are a prerequisite to reliably meeting the 48-hour driver patching requirement in E8-PO-ML3.5, but ISM-1143 is broader and not driver/timeframe-specific.
This control supports E8-PO-ML3.6.
E8-PO-ML3.6 requires organisations to deploy non-critical driver patches within one month when no working exploits exist. ISM-1143 underpins this by requiring patch management processes and supporting procedures to be developed, implemented and maintained (e.g. triage, scheduling, exceptions, and compliance tracking). E8-PO-ML3.6 is a specific timing/condition requirement, while ISM-1143 is the governance/process prerequisite that makes consistent execution and auditability possible.
This control supports 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 exploits exist. ISM-1143 requires patch management processes and procedures to be developed, implemented and maintained, which underpin how the organisation identifies firmware patches, assesses urgency, schedules deployment and verifies completion within mandated timeframes. E8-PO-ML3.7 is the specific performance outcome, while ISM-1143 provides the governance and repeatability needed to meet it consistently.
This control depends on E8-PA-ML1.3.
E8-PA-ML1.3 requires daily vulnerability scanning to identify missing patches or updates for vulnerabilities in online services. ISM-1143 requires organisations to develop, implement and maintain patch management processes and procedures, which provides the governance and workflow to action the missing patches identified by E8-PA-ML1.3. The primary is detection-focused, while ISM-1143 is process-focused on managing patching end-to-end.
ASD Essentials for enterprise IT: 1 mapping
- IT.PRO-06.2Apply security patches within risk-based timeframes and automate low-impact updatesPartially overlaps
This control partially overlaps IT.PRO-06.2.
IT.PRO-06.2 requires security patches or updates to be applied within defined risk-based timeframes; ISM-1143 requires patch management processes and supporting procedures to be developed, implemented and maintained, the process framework within which that patching happens.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.