ASD ISM 1921 Assess system compromise risks often
What it says
The likelihood of system compromise is frequently assessed when working exploits exist for unmitigated vulnerabilities.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishRegularly check how likely systems can be hacked due to known vulnerabilities.
This control is about regularly checking your system to see how vulnerable it might be to cyberattacks due to known weaknesses. It's important because if you don't, you risk being unexpectedly hacked, which could lead to stolen data, upset clients, and even losing money.
Free. Save your status, tasks and notes.
Why it matters
Unchecked vulnerabilities with known exploits can swiftly lead to system breaches, risking critical data loss and operational disruption.
How to implement
The IT team should regularly scan all computer systems for vulnerabilities.
They can use scanning tools that search for known weaknesses in the systems. Make sure this process happens every month and whenever new updates are available.
The manager should ensure that someone is responsible for reviewing scan results.
Assign this task to an experienced IT employee who can identify which vulnerabilities are critical and need immediate attention.
Business owners should prioritise addressing critical vulnerabilities.
After reviewing with the IT team, decide which risks are the highest priority and allocate resources to mitigate them as quickly as possible.
The IT team should keep software up to date to reduce vulnerabilities.
Set automatic updates wherever possible and keep a manual schedule for updating any systems that don't auto-update.
System owners should work with the IT team to establish a response plan for when vulnerabilities are found.
This plan should outline who takes what action and include steps to follow up after mitigation to ensure the vulnerabilities have been successfully addressed.
Keep it running
Integrate exploit monitoring into routine risk assessments; prioritise immediate mitigation when working exploits exist for unmitigated vulnerabilities.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
The most recent vulnerability scan report: Request a recent scan result document to review.
Look at
The date of the report and the vulnerabilities listed.
Good evidence
Sign includes up-to-date results with notes on action taken or planned for each listed vulnerability.
- Check 2 of 5What an auditor asks for
Ask for
Meeting notes where vulnerabilities were discussed: Request documentation of discussions or meetings on system vulnerabilities.
Look at
Who attended and the actions decided. Good documentation will record participant names, meeting dates, and action items with deadlines.
- Check 3 of 5What an auditor asks for
Ask for
About the update schedule for software: Request the schedule or records for software updates.
Look at
The frequency of updates and any exceptions.
Good evidence
Schedule will show regular update intervals, with few exceptions and reasons documented.
- Check 4 of 5What an auditor asks for
Ask for
Records of patched vulnerabilities: Request a list of patched vulnerabilities. Check which ones were patched promptly and if any remain open. Good records will show dated entries for each patch and minimal outstanding critical vulnerabilities.
- Check 5 of 5What an auditor asks for
Ask for
The response plan document: Request to see the document outlining the steps to take when vulnerabilities are found.
Look at
The clarity of responsibilities and timelines in the plan. A well-prepared plan will clearly assign tasks and deadlines for when actions should be completed.
Mappings
Closest match in ASD Essentials for enterprise IT: IT.IDE-04.1, Feed continuously reviewed threat intelligence and weaknesses into risk assessments, which partially overlaps with this control.
ASD Essential Eight: 5 mappings
This control supports E8-PA-ML1.5.
ISM-1921 requires organisations to frequently reassess the likelihood of system compromise when working exploits exist for unmitigated vulnerabilities. E8-PA-ML1.5 supports ISM-1921 by providing a high-priority treatment trigger (critical or exploited online service vulnerabilities) that should drive urgent re-evaluation of compromise likelihood and residual risk while remediation is pending. E8-PA-ML1.5 is primarily a remediation timeframe for one asset class, whereas ISM-1921 is an assessment-cadence requirement that also applies when mitigations are not immediately possible.
This control supports E8-PO-ML1.5.
ISM-1921 requires organisations to frequently reassess the likelihood of compromise when working exploits exist for unmitigated vulnerabilities. E8-PO-ML1.5 supports ISM-1921 by prioritising remediation for exploited/critical vulnerabilities on internet-facing operating systems and network devices, which are high-likelihood compromise scenarios that warrant frequent reassessment and escalation decisions. E8-PO-ML1.5 is a remediation SLA for a specific asset exposure category, whereas ISM-1921 is the ongoing reassessment requirement regardless of whether patching is immediately achievable.
This control supports E8-PO-ML3.3.
ISM-1921 requires organisations to frequently reassess compromise likelihood when working exploits exist for unmitigated vulnerabilities. E8-PO-ML3.3 supports ISM-1921 by defining an urgent patching expectation for exploited or critical OS/device vulnerabilities in non-internet-facing environments, which should still trigger reassessment of lateral movement risk, privilege boundaries and compensating controls. E8-PO-ML3.3 is treatment-focused, while ISM-1921 is the reassessment cadence and prioritisation logic that governs what to do while vulnerabilities remain unmitigated.
This control depends on E8-PA-ML3.1.
ISM-1921 requires organisations to frequently assess the likelihood of system compromise when working exploits exist for unmitigated vulnerabilities. E8-PA-ML3.1 supports ISM-1921 by setting an urgent patch/mitigation expectation for exploited or vendor-critical application vulnerabilities, which should trigger repeated compromise-likelihood reassessment for affected endpoints and services until mitigated. E8-PA-ML3.1 prescribes treatment timeframes for a defined application set, while ISM-1921 is broader and focuses on the assessment cadence and decision-making driven by exploitability.
This control depends on E8-PO-ML3.5.
ISM-1921 requires organisations to frequently reassess compromise likelihood when working exploits exist for unmitigated vulnerabilities. E8-PO-ML3.5 supports ISM-1921 by defining an urgent response expectation for exploited/critical driver vulnerabilities, which should prompt repeated compromise-likelihood reassessment (e.g., exposure, affected fleets, compensating controls) until patched. E8-PO-ML3.5 is a patching SLA, while ISM-1921 governs the reassessment process that prioritises and validates that urgency based on exploit conditions.
ASD Essentials for enterprise IT: 2 mappings
- IT.IDE-04.1Feed continuously reviewed threat intelligence and weaknesses into risk assessmentsPartially overlaps
This control partially overlaps IT.IDE-04.1.
IT.IDE-04.1 requires risk assessments to consider relevant weaknesses, malicious actor techniques and threat behaviours, reviewed continuously; ISM-1921 is a narrower case, frequently assessing the likelihood of compromise where working exploits exist for unmitigated vulnerabilities.
- IT.PRO-06.3Remediate or mitigate above-threshold vulnerabilities within defined timeframes and verify effectivenessPartially overlaps
This control partially overlaps IT.PRO-06.3.
IT.PRO-06.3 requires vulnerabilities above risk thresholds to be remediated or mitigated in timeframes that weigh exploitation; ISM-1921 requires frequent assessment of the likelihood of system compromise when working exploits exist for unmitigated vulnerabilities, informing those timeframes.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.