ASD ISM 1754 Timely resolution of identified software vulnerabilities
What it says
Vulnerabilities identified in software are resolved in a timely manner.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishSoftware vulnerabilities should be fixed quickly to prevent potential security risks.
This control means that any weaknesses found in your software should be addressed quickly to keep your organisation safe. If you don't fix these vulnerabilities in a timely manner, hackers might exploit them to steal data, disrupt operations, or cause other harm.
Free. Save your status, tasks and notes.
Why it matters
Delaying vulnerability fixes can lead to exploits, with attackers gaining access to sensitive data or disrupting critical operations.
How to implement
IT team should establish a process for identifying software vulnerabilities: Regularly use automated tools to scan software for vulnerabilities.
Set up alerts for when new vulnerabilities are discovered.
System owner should prioritise vulnerabilities based on risk: Evaluate the potential impact of each vulnerability on operations and data security.
Prioritise fixes for the most critical vulnerabilities that could cause the most harm.
IT team should develop and apply patches or updates: Ensure that software updates are created or sourced, tested, and applied swiftly after vulnerabilities are identified.
This might involve coordinating with software vendors if third-party products are affected.
Manager should allocate resources and support for timely resolutions: Ensure that the IT team has sufficient time, budget, and personnel to address vulnerabilities quickly.
Regularly review resource allocation to maintain effectiveness.
System owner should document and communicate resolution plans: Clearly document each vulnerability, the resolution steps taken, and the timeline.
Share this information with relevant stakeholders to keep them informed and engaged in the process.
Keep it running
Run regular vulnerability scans and patch promptly; prioritise remediation by severity, exploitability and asset criticality to reduce the likelihood of compromise.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Vulnerability assessment reports: Request the latest scans and reports that identify software vulnerabilities.
Look at
Comprehensiveness and regular frequency.
Good evidence
Includes recent and detailed vulnerability findings.
- Check 2 of 5What an auditor asks for
Ask for
The prioritisation criteria document: Request the policy or criteria used to prioritise which software vulnerabilities to address first.
Look at
A clear rationale linking business impact to priority.
Good evidence
Shows a structured approach to prioritisation.
- Check 3 of 5What an auditor asks for
Ask for
The remediation action plan: Request documentation showing how identified vulnerabilities are fixed.
Look at
Specific actions, timelines, and responsible parties for each vulnerability.
Good evidence
Is a detailed plan that is actively followed.
- Check 4 of 5What an auditor asks for
Ask for
Evidence of applied patches: Request logs or records of updates applied to the software.
Look at
Dates, descriptions, and confirmation of successful application.
Good evidence
Is a complete and recent patch history.
- Check 5 of 5What an auditor asks for
Ask for
Resource allocation records: Request documentation showing allocated resources for vulnerability management.
Look at
Evidence of adequate personnel, budget, and time dedicated to this process.
Good evidence
Shows management support and resource alignment.
Mappings
Closest match in ASD Essential Eight: E8-PA-ML1.5, Apply critical online service patches within 48 hours, which this control covers in full and more.
ISO/IEC 27001: 1 mapping
This control partially meets A.8.8.
ISM-1754 requires vulnerabilities identified in software to be resolved in a timely manner. Annex A 8.8 addresses a broader vulnerability management lifecycle by requiring organisations to obtain information on technical vulnerabilities, evaluate exposure, and take appropriate measures. ISM-1754 aligns to the remediation portion of Annex A 8.8 but does not, by itself, cover the full acquisition and exposure evaluation activities.
ASD Essential Eight: 8 mappings
This control is broader than E8-PA-ML1.5.
ISM-1754 requires vulnerabilities identified in software to be resolved in a timely manner. E8-PA-ML1.5 specifies a concrete timeliness requirement for one subset of software vulnerability remediation: applying critical patches for online services within 48 hours. E8-PA-ML1.5 is therefore one prescriptive implementation path that fits within the broader outcome stated by ISM-1754.
This control is broader than E8-PA-ML1.7.
ISM-1754 requires vulnerabilities identified in software to be resolved in a timely manner, without naming particular software or a timeframe. E8-PA-ML1.7 is a specific case of this, requiring vendor patches or mitigations for office productivity suites, web browsers and their extensions, email clients, PDF software and security products to be applied within two weeks of release.
This control is broader than E8-PA-ML3.1.
ISM-1754 requires vulnerabilities identified in software to be resolved in a timely manner. E8-PA-ML3.1 specifies applying critical patches within 48 hours for common applications (e.g. browsers, email clients, PDF software and security products), which is a direct subset of timely vulnerability resolution under ISM-1754. The candidate is narrower because it defines a specific timeframe and a specific application set.
This control is broader than E8-PA-ML3.2.
E8-PA-ML3.2 mandates timely patching of non-critical vulnerabilities in specified user applications within two weeks when no exploits exist. ISM-1754 requires timely resolution of vulnerabilities in software, encompassing broader remediation options. E8-PA-ML3.2 is more specific and measurable.
- E8-PO-ML1.7One-month operating system patching for workstations, non-internet-facing servers and network devicesBroader than
This control is broader than E8-PO-ML1.7.
ISM-1754 requires vulnerabilities identified in software to be resolved in a timely manner, without fixing a timeframe or limiting the software or assets covered. E8-PO-ML1.7 is a specific case of that requirement: vendor patches or mitigations for operating system vulnerabilities on workstations, non-internet-facing servers and non-internet-facing network devices must be applied within one month of release.
This control is broader than E8-PO-ML3.5.
ISM-1754 requires vulnerabilities identified in software to be resolved in a timely manner. E8-PO-ML3.5 mandates applying critical driver patches within 48 hours, which is a specific category of software vulnerability remediation that contributes to meeting ISM-1754. The candidate is narrower because it is limited to drivers and a particular timeliness threshold.
This control partially overlaps E8-PO-ML3.7.
ISM-1754 requires vulnerabilities identified in software to be resolved in a timely manner. E8-PO-ML3.7 mandates applying critical firmware patches within 48 hours, which overlaps with ISM-1754 where firmware is treated as software within the organisation's remediation scope. E8-PO-ML3.7 is more specific (firmware and 48-hour SLA), while ISM-1754 is broader in intent but not limited to firmware.
This control depends on E8-PA-ML1.4.
ISM-1754 requires vulnerabilities identified in software to be resolved in a timely manner. E8-PA-ML1.4 supports ISM-1754 by operationalising the discovery of patch-related vulnerabilities via at least weekly scanning of common applications, enabling faster identification and prioritisation of fixes. E8-PA-ML1.4 focuses on detection of missing patches, whereas ISM-1754 focuses on timely remediation once vulnerabilities are identified.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.