ASD ISM 1693 Timely application of patches to mitigate vulnerabilities
What it says
Patches, updates or other vendor mitigations for vulnerabilities in applications other than office productivity suites, web browsers and their extensions, email clients, PDF applications, and security products are applied within one month of release.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishApply updates to non-generic software within a month to keep systems secure.
Keeping your software up-to-date is like locking your doors at night. This control ensures that less common software is updated within a month of a security fix being released. If you don't apply these updates, attackers might exploit weaknesses in your software, which could lead to data breaches or disruptions to your business operations.
Free. Save your status, tasks and notes.
Why it matters
Delaying patches for non-core applications beyond one month leaves known vulnerabilities exploitable, increasing breach and outage risk.
How to implement
The IT team should create a list of all installed applications on the organisation's systems that aren't part of common suites like Microsoft Office or web browsers.
They can do this by running an inventory check using automated tools or manual inspections.
System administrators should sign up for security notifications from software vendors.
These alerts will inform them when updates or patches are released, ensuring they can act quickly within the one-month timeframe.
Managers should meet with the IT team monthly to review the status of software updates.
They should ensure that all necessary patches have been applied and document any exceptions with a plan to resolve them.
The finance team should ensure there is budget allocated for software maintenance and updates.
They can do this as part of the annual budgeting process, factoring in potential costs associated with software updates.
The organisational leadership should endorse a policy mandating timely application of updates.
This can be done by drafting a formal policy document that outlines the procedure and consequences for not adhering to the patching timeline.
Keep it running
Track vendor releases for non-core applications and apply patches, updates or mitigations within one month, with exceptions risk-assessed.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
The software inventory list: Request the IT-maintained list of non-generic software that runs on the organisation's systems.
Look at
Details such as software name, version, and date of last update.
Good evidence
A current list that matches the latest system inventory check.
- Check 2 of 5What an auditor asks for
Ask for
The patch management log: Review the document tracking when patches were applied to each piece of software.
Look at
Entries to ensure that no software updates are pending beyond a month after release.
Good evidence
A log showing updates completed within 30 days of release.
- Check 3 of 5What an auditor asks for
Ask for
Security alert subscriptions: Verify that the IT team receives notifications from software vendors.
Look at
Evidence of email notifications or access to vendor portals.
Good evidence
Active subscriptions confirmed by vendor alerts or recent patch releases.
- Check 4 of 5What an auditor asks for
Ask for
To see the monthly IT review notes: Review the recorded outcomes of monthly update reviews between managers and the IT team.
Look at
Any identified issues and action plans to resolve them.
Good evidence
Topics discussed, issues resolved, and captured follow-up actions.
- Check 5 of 5What an auditor asks for
Ask for
The organisation's software update policy: Check that there is a formal document outlining the update procedures and responsibilities.
Look at
Clarity in responsibilities, update timelines, and steps for handling exceptions.
Good evidence
A signed and dated policy with annexed roles and procedures.
Mappings
Closest match in ASD Essential Eight: E8-PA-ML2.2, Timely patching of non-critical application vulnerabilities, which asks for the same thing.
ISO/IEC 27001: 1 mapping
This control partially meets A.8.8.
ISM-1693 requires a specific remediation action: applying patches/updates/vendor mitigations for certain applications within one month of release. ISO/IEC 27001:2022 Annex A 8.8 is broader, requiring organizations to obtain information about technical vulnerabilities, evaluate exposure, and take appropriate measures (which can include patching, configuration changes, compensating controls, or decommissioning). ISM-1693 is therefore a prescriptive subset implementation of the broader vulnerability management expectation in Annex A 8.8.
ASD Essential Eight: 5 mappings
This control is equivalent to E8-PA-ML2.2.
E8-PA-ML2.2 requires patches, updates or vendor mitigations for vulnerabilities in non-critical applications (excluding productivity suites, browsers, email clients, PDF software and security products) to be applied within one month of release. ISM-1693 states the same patching requirement for the same application scope and the same one-month timeframe. The two controls are effectively the same obligation expressed in different frameworks.
This control partially overlaps E8-PA-ML1.4.
E8-PA-ML1.4 requires weekly scanning to identify missing patches or updates, but only for office suites, browsers/extensions, email clients, PDF software, and security products. ISM-1693 requires patching within one month for applications outside those key categories. They overlap in the general patch/vulnerability management intent, but E8-PA-ML1.4 focuses on detection for a specific application set while ISM-1693 focuses on remediation timelines for other applications.
This control partially overlaps E8-PA-ML2.1.
E8-PA-ML2.1 requires fortnightly vulnerability scanning to identify missing patches for non-core applications. ISM-1693 focuses on applying patches/updates for those same non-core applications within one month of release. They overlap because scanning output is a key input to timely patching, but E8-PA-ML2.1 is about detection cadence while ISM-1693 is about remediation timeframe.
This control partially overlaps E8-PA-ML3.2.
E8-PA-ML3.2 requires patching within two weeks for non-critical vulnerabilities (with no working exploits) in a specific set of user-facing and security applications. ISM-1693 requires patching within one month for vulnerabilities in other applications outside that specified set. They both address timely patching, but apply to different software scopes and use different timeframes, so the alignment is only partial.
This control depends on E8-PA-ML1.2.
ISM-1693 requires patches and vendor mitigations for non-core applications to be applied within one month of release. E8-PA-ML1.2 supports ISM-1693 by requiring the use of a vulnerability scanner with an up-to-date vulnerability database, improving an organisation's ability to identify missing patches and prioritise remediation to meet the one-month deadline. E8-PA-ML1.2 does not itself mandate patch timeframes, so it strengthens but does not replace ISM-1693.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.