ASD ISM 1697 Apply non-critical patches within one month
What it says
Patches, updates or other vendor mitigations for vulnerabilities in drivers are applied within one month of release when vulnerabilities are assessed as non-critical by vendors and no working exploits exist.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishApply updates for driver vulnerabilities within a month if they are non-critical and have no known exploits.
Applying patches within a month for non-critical issues in your computer drivers is like fixing a small leak in a roof before it rains heavily. While these updates may not seem urgent, ignoring them can lead to bigger problems like system slowdowns or even data loss if vulnerabilities are exploited later.
Free. Save your status, tasks and notes.
Why it matters
If non-critical driver patches (no known working exploits) aren't applied within 1 month, exposure to privilege escalation or device compromise increases.
How to implement
The IT team should regularly check for driver updates.
This can be done by scheduling a monthly check using reliable software update tools that notify them when new patches are available.
System owners should create a priority list of drivers based on their importance to business operations.
This helps in deciding which updates need to be attended to first, ensuring critical drivers are never missed.
Office managers should ensure staff are aware of the patching schedule.
Communicating the plan in advance prevents downtime surprises and allows staff time to save work and power down systems as needed.
IT support should test updates in a controlled environment before full deployment.
Create a small testing group to apply updates first, ensuring no adverse effects before rolling them out to the entire organisation.
Assign a team member to document all updates applied and any issues encountered.
This log should include update dates, driver names, and systems affected for accountability and easy reference in case of future issues.
Keep it running
Track vendor driver advisories; when rated non-critical and no working exploit exists, test then deploy within 1 month and record evidence of completion.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
The driver update schedule: Request the documented plan that shows how and when driver updates are checked.
Look at
Whether the schedule reflects a monthly check.
Good evidence
Includes a structured and clear timeline that includes update checks every month.
- Check 2 of 5What an auditor asks for
Look at
Details on which updates were tested, when, and any issues found during testing.
Good evidence
Includes a log of test results with steps taken to address any problems before full implementation.
- Check 3 of 5What an auditor asks for
Ask for
Staff communication records: Request emails or notices sent to staff about scheduled updates.
Look at
The timing of these communications and their content.
Good evidence
Demonstrates proactive communication that gave staff adequate warning before updates occurred.
- Check 4 of 5What an auditor asks for
Ask for
To see the priority list for driver updates.
Look at
Evidence of thought given to business criticality in driver prioritisation.
Good evidence
Includes an assessment of drivers based on their role in business operations and risk level.
- Check 5 of 5What an auditor asks for
Ask for
The update log documentation: Request the record showing all updates applied and any encountered issues.
Look at
The completeness of records, including dates and driver details.
Good evidence
Provides comprehensive logs that track each update and any action taken.
Mappings
Closest match in ASD Essential Eight: E8-PO-ML3.6, Apply non-critical driver patches within one month, which asks for the same thing.
ISO/IEC 27001: 1 mapping
This control partially meets A.8.8.
ISM-1697 requires applying vendor-provided mitigations for non-critical driver vulnerabilities within one month where no working exploits exist. ISO/IEC 27001:2022 Annex A 8.8 requires organisations to obtain information about technical vulnerabilities, assess exposure, and take appropriate measures across information systems generally. ISM-1697 is a specific, time-bound patching requirement within the broader vulnerability management expectations of Annex A 8.8.
ASD Essential Eight: 10 mappings
This control is equivalent to E8-PO-ML3.6.
ISM-1697 requires organisations to apply patches, updates or other vendor mitigations for non-critical driver vulnerabilities within one month where no working exploits exist. E8-PO-ML3.6 states the same patching requirement with the same scope (drivers), timing (one month), and conditions (non-critical, no working exploits). Implementing E8-PO-ML3.6 would therefore largely satisfy ISM-1697.
This control partially overlaps E8-PA-ML1.6.
ISM-1697 requires organisations to patch non-critical driver vulnerabilities within one month where no working exploits exist. E8-PA-ML1.6 similarly requires patching of non-critical vulnerabilities with no working exploits, but for online services and within two weeks. They overlap on vulnerability-driven patching, but have different technology scope and mandated timeframes.
This control partially overlaps E8-PO-ML3.4.
ISM-1697 requires applying non-critical patches for driver vulnerabilities within one month when no working exploits exist. E8-PO-ML3.4 sets the same one-month/non-critical/no-exploit requirement, but for operating systems on workstations and non-internet-facing servers/devices rather than drivers. They overlap on patch timeliness for non-critical vulnerabilities, but differ in the asset category being patched.
This control partially overlaps E8-PO-ML3.5.
ISM-1697 requires organisations to apply vendor mitigations for driver vulnerabilities within one month when they are assessed as non-critical and no working exploits exist. E8-PO-ML3.5 addresses the same technology scope (drivers) but applies to critical vulnerabilities or those with working exploits and requires patching within 48 hours. The controls overlap on driver patching governance, but they target different risk conditions and impose different timeframes.
This control partially overlaps E8-PO-ML3.7.
ISM-1697 requires applying non-critical driver patches within one month when no working exploits exist. E8-PO-ML3.7 requires patching firmware vulnerabilities within 48 hours when they are critical or when working exploits exist. The overlap is limited to the general patch/mitigation concept, with key differences in both asset type (firmware vs drivers) and urgency/risk trigger (critical/exploited vs non-critical/non-exploited).
- E8-PO-ML3.8Firmware vulnerabilities patched within one month if non-critical and no exploitsPartially overlaps
This control partially overlaps E8-PO-ML3.8.
ISM-1697 requires organisations to apply non-critical patches for driver vulnerabilities within one month when no working exploits exist. E8-PO-ML3.8 applies the same timing and exploit/criticality conditions, but for firmware rather than drivers. They overlap on the general patch-timeliness principle, but differ materially in asset class and technical scope.
This control supports E8-AC-ML3.3.
ISM-1697 requires patching non-critical driver vulnerabilities within one month when no working exploits exist. E8-AC-ML3.3 supports ISM-1697 by reducing exposure to known vulnerable drivers through Microsoft's vulnerable driver blocklist, acting as an additional vendor mitigation when patching is pending or unavailable. The blocklist is a different control mechanism than patching and does not replace the one-month remediation requirement in ISM-1697.
This control supports E8-PO-ML1.1.
ISM-1697 requires applying non-critical driver patches within one month when no working exploits exist. E8-PO-ML1.1 supports ISM-1697 by requiring automated asset discovery to feed vulnerability scanning, helping ensure devices with vulnerable drivers are in scope for patch tracking and remediation. The candidate control is foundational for coverage, but it does not itself require patch deployment within a defined window.
This control depends on E8-PO-ML1.2.
ISM-1697 requires organisations to apply non-critical driver patches within one month where no working exploits exist. E8-PO-ML1.2 supports ISM-1697 by requiring vulnerability scanning with an up-to-date database, which helps identify missing patches/updates and validate remediation status for components such as drivers. The scanning requirement is complementary but does not define the driver patching timeframe or conditions itself.
This control depends on E8-PO-ML3.1.
ISM-1697 requires organisations to apply non-critical driver patches within one month where no working exploits exist. E8-PO-ML3.1 supports ISM-1697 by requiring fortnightly vulnerability scanning to identify missing driver patches, which helps detect non-compliance with the one-month patch window. Scanning improves visibility and assurance, but it does not itself mandate the patch application timeframe or decision conditions.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.