ASD Essentials IT.PRO-06.3 Remediate or Mitigate Above-Threshold Vulnerabilities Within Defined Timeframes and Verify Effectiveness
What it says
Remediate or mitigate vulnerabilities exceeding defined risk thresholds within defined timeframes based on exploitation, exposure, criticality, impact and compensating controls, and verify treatment effectiveness.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishFixes security weaknesses rated above the organisation's risk limit, or adds safeguards, by risk-based deadlines, then checks the risk really dropped.
The organisation sets a risk limit for security weaknesses (vulnerabilities), and a deadline to deal with those above it. Each one is rated on whether attackers are using it, how exposed and critical the system is, the likely harm and the safeguards in place. To meet this, each weakness over the limit is fixed, or has approved extra safeguards, by its deadline. Then someone checks it worked, for example by scanning again.
Free. Save your status, tasks and notes.
Where this action applies
What's in each domain?ASD orders the work by domain: apply this action to each ticked domain, phase by phase.
- Phase 3
Why it matters
Weaknesses that are untracked, overdue or only informally covered give attackers known ways to break in, spread and take control. Without a check, a failed fix can leave the risk open while records show it closed.
How to implement
The security lead should draft a standard, for the risk owner to approve, setting risk limits and a deadline per rating.
Ratings weigh active attacks, exposure, system importance, likely harm and existing safeguards, and deadlines never exceed any mandatory timeframe.
The vulnerability management team should rate every confirmed weakness against the standard.
Log each one over a limit in one tracker, such as a ticket queue, with its affected systems, rating reason, owner and due date.
System owners should fix tracked weaknesses in rating order and on time, by patching, upgrading, changing settings or removing the flawed part.
Escalate to the risk owner before a due date is missed.
The system owner should document extra safeguards that block the attack, such as a firewall rule, when a fix cannot be made in time.
Add a review date and fix plan, and get risk owner approval before the deadline passes.
The vulnerability management team should check each fix or safeguard before closing it, by rescanning, checking versions or testing, and reopen failures.
Each period, report on-time fixes, overdue items and failed checks by ASD domain, and keep the history.
Keep it running
The vulnerability management team re-rates open items when attackers start using a weakness, a system becomes more exposed or a safeguard lapses. Roll the process out in ASD's priority order: internet-facing and sign-in systems first, then critical and admin systems, then business systems and staff devices. Deadlines can differ by ASD domain. Report every set period, so records show steady, checked progress rather than a one-off clean-up.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the approved standard with its risk limits, rating method and deadlines.
Look at
Whether limits exist, and ratings weigh active attacks, exposure, importance, harm and safeguards or only vendor severity.
Good evidence
Approved limits and deadlines exist, and ratings weigh active attacks, exposure, importance, harm and existing safeguards.
- Check 2 of 5What an auditor asks for
Ask for
Request the tracker and recent vulnerability scan results for sample systems in each ASD domain.
Look at
Whether scan findings over a limit are missing from the tracker, or lack an owner or due date.
Good evidence
Every weakness over a limit is tracked with its rating, owner and due date until closed.
- Check 3 of 5What an auditor asks for
Ask for
Ask for a sample of weaknesses over a limit that fell due, with their fix dates.
Look at
Whether fixes came after the deadline, due dates are often missed, or overdue items were not escalated.
Good evidence
Each sampled weakness was fixed, or covered by approved safeguards, within its deadline.
- Check 4 of 5What an auditor asks for
Ask for
Request the register of extra safeguards, with the approval record for each.
Look at
Whether safeguards exist only informally, lack risk owner approval, or are past their review date.
Good evidence
Each safeguard is documented and approved in time, and its weakness stays tracked until closed.
- Check 5 of 5What an auditor asks for
Ask for
Ask for the evidence behind sample closed items, and progress reports for recent periods.
Look at
Whether items were closed without a rescan, check or test, or reports cover only one period.
Good evidence
Each closure has a dated check, and several periods show steady, on-time treatment.
ASD indicators of good practice (7)
The indicators below are quoted as published from ASD's Assessment evidence guide for enterprise IT. These optional indicators help an assessor judge the action in each domain where it applies: if any not effective statement is true, the action is rated not effective; if every applicable fully effective statement is true and no other statement is, it is rated fully effective; otherwise it is rated partially effective. ASD says the indicators "do not replace expert judgement, nor are they intended to serve as a checklist".
Not effective(2)
- NE-1No risk thresholds are defined for vulnerability remediation.
- NE-2Vulnerabilities exceeding acceptable risk levels are not tracked or remediated.
Partially effective(2)
- PE-1Risk thresholds are defined but vulnerabilities exceeding them are not consistently remediated within defined timeframes.
- PE-2Compensating controls are applied in some cases but are not formally documented or approved.
Fully effective(3)
- FE-1Risk thresholds defined by the organisation exist, and vulnerabilities exceeding them are remediated or have approved compensating controls within organisationally defined timeframes.
- FE-2Remediation and mitigation actions are tracked to closure with verification that actions reduced the risk as intended.
- FE-3The process is sustained, with historical data demonstrating consistent performance across organisationally defined reporting periods.
Mappings
Closest match in ISO/IEC 27001: A.8.8, Management of Technical Vulnerabilities, which this control partially meets.
ISO/IEC 27001: 2 mappings
This control partially meets A.8.8.
IT.PRO-06.3 requires vulnerabilities exceeding defined risk thresholds to be remediated or mitigated within defined timeframes, prioritised by exploitation, exposure, criticality, impact and compensating controls, with treatment effectiveness verified. This is a specific, risk-based implementation of the exposure evaluation and appropriate measures required by Annex A 8.8. Annex A 8.8 also covers obtaining information about technical vulnerabilities, while IT.PRO-06.3 adds explicit treatment timeframes and verification of effectiveness.
This control depends on A.5.7.
IT.PRO-06.3 requires vulnerabilities exceeding defined risk thresholds to be remediated or mitigated within defined timeframes, with prioritisation that explicitly considers exploitation. Judging whether a vulnerability is being exploited relies on the threat intelligence that Annex A 5.7 requires the organisation to collect and analyse, so IT.PRO-06.3 depends on that capability as an input. Annex A 5.7 covers threat intelligence generally and does not itself require any vulnerability treatment.
ASD Essential Eight: 15 mappings
This control partially overlaps E8-PA-ML1.5.
IT.PRO-06.3 requires vulnerabilities above risk thresholds to be remediated or mitigated in set timeframes; E8-PA-ML1.5 sets 48 hours to apply patches or vendor mitigations for online services when vendors rate vulnerabilities critical or working exploits exist, one such timeframe.
This control partially overlaps E8-PA-ML1.6.
IT.PRO-06.3 requires vulnerabilities above risk thresholds to be remediated or mitigated in set timeframes; E8-PA-ML1.6 sets two weeks to apply patches or vendor mitigations for online services when vendors rate vulnerabilities non-critical and no working exploits exist, one such timeframe.
- E8-PA-ML1.7Patch office, browser, email, PDF and security software within two weeksPartially overlaps
This control partially overlaps E8-PA-ML1.7.
IT.PRO-06.3 requires vulnerabilities above risk thresholds to be remediated or mitigated in set timeframes; E8-PA-ML1.7 sets two weeks to patch office suites, browsers and extensions, email clients, PDF and security software, one such timeframe.
This control partially overlaps E8-PA-ML2.2.
IT.PRO-06.3 requires vulnerabilities above risk thresholds to be remediated or mitigated in set timeframes; E8-PA-ML2.2 sets one month to patch applications other than office suites, browsers and extensions, email clients, PDF and security software, one such timeframe.
This control partially overlaps E8-PA-ML3.1.
IT.PRO-06.3 requires vulnerabilities above risk thresholds to be remediated or mitigated in set timeframes; E8-PA-ML3.1 sets 48 hours to patch office suites, browsers and extensions, email clients, PDF and security software when vendors rate vulnerabilities critical or working exploits exist, one such timeframe.
This control partially overlaps E8-PA-ML3.2.
IT.PRO-06.3 requires vulnerabilities above risk thresholds to be remediated or mitigated in set timeframes; E8-PA-ML3.2 sets two weeks to patch office suites, browsers and extensions, email clients, PDF and security software when vendors rate vulnerabilities non-critical and no working exploits exist, one such timeframe.
This control partially overlaps E8-PO-ML1.5.
IT.PRO-06.3 requires vulnerabilities above risk thresholds to be remediated or mitigated in set timeframes; E8-PO-ML1.5 sets 48 hours to patch operating systems of internet-facing servers and network devices when vendors rate vulnerabilities critical or working exploits exist, one such timeframe.
- E8-PO-ML1.6Timely application of non-critical patches for internet-facing OS vulnerabilitiesPartially overlaps
This control partially overlaps E8-PO-ML1.6.
IT.PRO-06.3 requires vulnerabilities above risk thresholds to be remediated or mitigated in set timeframes; E8-PO-ML1.6 sets two weeks to patch operating systems of internet-facing servers and network devices when vendors rate vulnerabilities non-critical and no working exploits exist, one such timeframe.
- E8-PO-ML1.7One-month operating system patching for workstations, non-internet-facing servers and network devicesPartially overlaps
This control partially overlaps E8-PO-ML1.7.
IT.PRO-06.3 requires vulnerabilities above risk thresholds to be remediated or mitigated in set timeframes; E8-PO-ML1.7 sets one month to patch operating systems of workstations, non-internet-facing servers and non-internet-facing network devices, one such timeframe.
This control partially overlaps E8-PO-ML3.3.
IT.PRO-06.3 requires vulnerabilities above risk thresholds to be remediated or mitigated in set timeframes; E8-PO-ML3.3 sets 48 hours to patch operating systems of workstations and non-internet-facing servers and network devices when vendors rate vulnerabilities critical or working exploits exist, one such timeframe.
This control partially overlaps E8-PO-ML3.4.
IT.PRO-06.3 requires vulnerabilities above risk thresholds to be remediated or mitigated in set timeframes; E8-PO-ML3.4 sets one month to patch operating systems of workstations and non-internet-facing servers and network devices when vendors rate vulnerabilities non-critical and no working exploits exist, one such timeframe.
This control partially overlaps E8-PO-ML3.5.
IT.PRO-06.3 requires vulnerabilities above risk thresholds to be remediated or mitigated in set timeframes; E8-PO-ML3.5 sets 48 hours to patch drivers when vendors rate vulnerabilities critical or working exploits exist, a timeframe keyed to criticality and exploitation.
This control partially overlaps E8-PO-ML3.6.
IT.PRO-06.3 requires vulnerabilities above risk thresholds to be remediated or mitigated in set timeframes; E8-PO-ML3.6 sets one month to patch drivers when vendors rate vulnerabilities non-critical and no working exploits exist, a timeframe keyed to criticality and exploitation.
This control partially overlaps E8-PO-ML3.7.
IT.PRO-06.3 requires vulnerabilities above risk thresholds to be remediated or mitigated in set timeframes; E8-PO-ML3.7 sets 48 hours to patch firmware when vendors rate vulnerabilities critical or working exploits exist, a timeframe keyed to criticality and exploitation.
- E8-PO-ML3.8Firmware vulnerabilities patched within one month if non-critical and no exploitsPartially overlaps
This control partially overlaps E8-PO-ML3.8.
IT.PRO-06.3 requires vulnerabilities above risk thresholds to be remediated or mitigated in set timeframes; E8-PO-ML3.8 sets one month to patch firmware when vendors rate vulnerabilities non-critical and no working exploits exist, a timeframe keyed to criticality and exploitation.
ASD Information Security Manual: 2 mappings
- ISM-1809Compensating Controls for Unsupported Systems Pending Removal or ReplacementPartially overlaps
This control partially overlaps ISM-1809.
IT.PRO-06.3 requires vulnerabilities above risk thresholds to be remediated or mitigated, allowing for compensating controls; ISM-1809 requires such controls for unsupported applications, operating systems, network devices or networked IT equipment until they can be removed or replaced.
This control partially overlaps ISM-1921.
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.