ASD Essentials IT.PRO-06.2 Apply Security Patches Within Risk-Based Timeframes and Automate Low-Impact Updates
What it says
Apply security patches or updates within defined risk-based timeframes or automatically where operational impact is low.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishApplies security patches and updates within set deadlines based on risk, or automatically where the impact on operations is low.
Software makers release patches to fix security flaws. The organisation installs them within set deadlines, and turns on automatic updates where they won't disrupt work. To meet this, deadlines reflect how severe the flaw is, how exposed the system is and whether attackers can already use it. They are met on every applicable system. For example, a flaw under attack on an internet-facing server goes first. Any patch held back gets approved extra safeguards.
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
Attackers often break in through unpatched internet-facing services and staff computers. They then use flaws in unpatched internal systems to spread and gain admin control. Missed or untracked patches leave these known flaws open long after a fix exists.
How to implement
The security lead should set patching deadlines for applications, operating systems, drivers and firmware in the patching process.
Base them on severity, exposure and whether attackers can use the flaw, stay within any mandatory deadline and get risk owner approval.
IT operations should push patches to every applicable system from a central patching tool and confirm each install.
Patch the flaws that are most severe, most exposed or already usable by attackers first, and install every patch within its deadline.
System owners should record which assets can patch automatically with little disruption, such as web browsers on staff laptops.
Turn automatic updates on centrally there so users cannot switch them off, and schedule the rest through change management.
The system owner should record why each patch is delayed, the extra safeguards used (such as restricted network access) and a planned date.
The risk owner should approve it, and the security team track it in a register until patched.
The patch management team should compare install records with the asset list, and report coverage and deadlines met by ASD domain.
List any excluded asset with its reason and formal risk acceptance.
Keep it running
IT operations run patching as a routine cycle: watch for new releases, rank them, install them centrally and confirm each one went on. Deadlines can differ between ASD domains. Work in ASD's priority order: internet-facing and sign-in systems first, then critical and admin systems, then business systems and staff devices. Check coverage reports regularly so appliances, firmware and systems outside the main patching tool are not missed.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the approved patching deadlines and the risk factors used to set them.
Look at
Whether some assets have no deadline, or one flat deadline applies whatever the risk.
Good evidence
Every applicable asset has an approved deadline based on severity, exposure and whether an attack exists.
- Check 2 of 5What an auditor asks for
Ask for
Request patch reports for several periods and a sample of high-severity patches from each ASD domain.
Look at
Whether deadlines are missed, patches go on irregularly with no record, or urgent ones wait behind routine ones.
Good evidence
Deadlines are met consistently, each sampled patch is confirmed installed, and the riskiest go first.
- Check 3 of 5What an auditor asks for
Ask for
Ask for the record of assets judged suitable for automatic patching, and their update settings.
Look at
Whether automatic updates are off or left to users on suitable assets, or failures go unreported.
Good evidence
Suitable assets update automatically, and their results, including failures, appear in patch reports.
- Check 4 of 5What an auditor asks for
Ask for
Ask for the register of delayed patches, with the extra safeguards and approval for each.
Look at
Whether overdue patches are missing from the register, or their safeguards are vague or unapproved.
Good evidence
Each delayed patch has a register entry with approved safeguards and a planned patch date.
- Check 5 of 5What an auditor asks for
Ask for
Request the coverage figures, the asset list behind them and the list of exclusions.
Look at
Whether figures show large unpatched gaps, leave out appliances or firmware, or list exclusions without risk acceptance.
Good evidence
Every applicable asset is either covered by patching or a formally risk-accepted exclusion.
ASD indicators of good practice (10)
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 defined patching timeframes exist for applicable assets.
- NE-2Patches are not applied or are applied on an ad hoc basis with no tracking.
Partially effective(3)
- PE-1Expected patching timeframes are defined by the organisation but are not consistently met.
- PE-2Patches are applied but compensating controls are not documented where operational constraints prevent timely patching.
- PE-3Patching coverage metrics exist but show significant gaps.
Fully effective(5)
- FE-1Risk-based patching timeframes defined by the organisation are in place and consistently met.
- FE-2Patching is prioritised based on vulnerability severity, exposure and exploit availability.
- FE-3Where operational constraints prevent timely patching, compensating controls are documented and approved.
- FE-4Patching coverage metrics account for all applicable assets, with any exclusions identified and formally risk accepted.
- FE-5Automatic patching of assets is applied where available and the organisation has determined operational impact is low.
Mappings
Closest match in ISO/IEC 27001: A.8.8, Management of Technical Vulnerabilities, which this control partially meets.
ISO/IEC 27001: 1 mapping
This control partially meets A.8.8.
IT.PRO-06.2 requires security patches or updates to be applied within defined risk-based timeframes, or automatically where operational impact is low. Patching is the principal treatment under Annex A 8.8, which requires appropriate measures to be taken once the organisation's exposure to technical vulnerabilities has been evaluated. Annex A 8.8 is broader, also covering how vulnerability information is obtained and exposure is assessed, and it allows treatments other than patching.
ASD Essential Eight: 15 mappings
This control partially overlaps E8-PA-ML1.5.
IT.PRO-06.2 requires security patches or updates to be applied within defined risk-based timeframes; E8-PA-ML1.5 sets a 48-hour deadline for patching online services when vendors assess vulnerabilities as critical or working exploits exist, one risk-based timeframe.
This control partially overlaps E8-PA-ML1.6.
IT.PRO-06.2 requires security patches or updates to be applied within defined risk-based timeframes; E8-PA-ML1.6 sets a two-week deadline for patching online services when vendors assess vulnerabilities as non-critical and no working exploits exist, one risk-based 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.2 requires security patches or updates to be applied within defined risk-based timeframes; E8-PA-ML1.7 sets a two-week deadline for patching office, browser, email, PDF and security software, one specific case of that.
This control partially overlaps E8-PA-ML2.2.
IT.PRO-06.2 requires security patches or updates to be applied within defined risk-based timeframes; E8-PA-ML2.2 sets a one-month deadline for patching applications other than office, browser, email, PDF and security software, one specific case of that.
This control partially overlaps E8-PA-ML3.1.
IT.PRO-06.2 requires security patches or updates to be applied within defined risk-based timeframes; E8-PA-ML3.1 is one case: a 48-hour deadline for office, browser, email, PDF and security software when vendors assess vulnerabilities as critical or working exploits exist.
This control partially overlaps E8-PA-ML3.2.
IT.PRO-06.2 requires security patches to be applied within risk-based 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 specific case.
This control partially overlaps E8-PO-ML1.5.
IT.PRO-06.2 requires security patches to be applied within risk-based 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 specific case of that.
- 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.2 requires security patches to be applied within risk-based 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 specific case of that.
- 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.2 requires security patches to be applied within risk-based 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 specific case of that.
This control partially overlaps E8-PO-ML3.3.
IT.PRO-06.2 requires security patches to be applied within risk-based 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 specific case of that.
This control partially overlaps E8-PO-ML3.4.
IT.PRO-06.2 requires security patches to be applied within risk-based 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 specific case.
This control partially overlaps E8-PO-ML3.5.
IT.PRO-06.2 requires security patches to be applied within risk-based timeframes; E8-PO-ML3.5 sets 48 hours to patch drivers when vendors rate vulnerabilities critical or working exploits exist, one specific case of that.
This control partially overlaps E8-PO-ML3.6.
IT.PRO-06.2 requires security patches to be applied within risk-based timeframes; E8-PO-ML3.6 sets one month to patch drivers when vendors rate vulnerabilities non-critical and no working exploits exist, one specific case of that.
This control partially overlaps E8-PO-ML3.7.
IT.PRO-06.2 requires security patches to be applied within risk-based timeframes; E8-PO-ML3.7 sets 48 hours to patch firmware when vendors rate vulnerabilities critical or working exploits exist, one specific case of that.
- 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.2 requires security patches to be applied within risk-based timeframes; E8-PO-ML3.8 sets one month to patch firmware when vendors rate vulnerabilities non-critical and no working exploits exist, one specific case of that.
ASD Information Security Manual: 2 mappings
This control partially overlaps ISM-0298.
IT.PRO-06.2 requires security patches or updates to be applied within defined risk-based timeframes; ISM-0298 supports it by requiring a centralised, managed patching approach that maintains patch integrity and confirms patches were applied successfully.
This control partially overlaps ISM-1143.
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.