ASD ISM 1900 Fortnightly system vulnerability scanning
What it says
A vulnerability scanner is used at least fortnightly to identify missing patches or updates for vulnerabilities in firmware.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishScan systems every two weeks to find and fix unpatched security flaws.
This control means that every two weeks, your business should scan its computer systems to look for software that needs updating. This is important because unpatched software can have security holes that hackers can exploit to steal data or disrupt operations.
Free. Save your status, tasks and notes.
Why it matters
If firmware isn't scanned at least fortnightly, missing patches can persist and be exploited, causing service disruption or data compromise.
How to implement
The IT team should schedule regular vulnerability scans: Decide on specific days every two weeks to perform these scans.
Use reliable software tools designed for scanning and ensure they cover all devices and systems used in the organisation.
The system owner should review scan results: After each scan, check the report to see which software lacks necessary updates.
Prioritise fixes for the most critical vulnerabilities first, based on the risk to the organisation.
The manager should communicate the importance: Explain to the team why these checks are essential for keeping both the company and customer data secure, thereby encouraging their cooperation in timely patching.
The IT team should document findings and actions: Keep a detailed record of all vulnerabilities found and how they were fixed.
This document should include dates, actions taken, and confirmation that updates were applied.
The manager should ensure backup support: Arrange for a secondary person in case the primary IT contact is unavailable.
Make sure this person is trained to run scans and apply updates as needed.
Keep it running
Run an authenticated vulnerability scan at least fortnightly and track firmware patch gaps; prioritise and remediate high/critical findings quickly.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
The vulnerability scan schedule: Request to see a calendar or schedule showing planned scan dates.
Look at
Whether these dates are set consistently every two weeks.
Good evidence
A schedule with clearly marked biweekly scans.
- Check 2 of 5What an auditor asks for
Ask for
Recent scan reports: Obtain the latest scan reports that list any vulnerabilities found.
Look at
Whether they include details on all systems and critical vulnerabilities.
Good evidence
Comprehensive reports showing vulnerability details for each system.
- Check 3 of 5What an auditor asks for
Ask for
The vulnerability action log: Request a log of actions taken following each scan.
Look at
Whether it aligns with the scan report and includes dates and descriptions of fixes.
Good evidence
A detailed log with precise actions linked to each vulnerability found.
- Check 4 of 5What an auditor asks for
Ask for
About follow-up communication: See if there have been communications sent to staff or relevant team members following scans.
Look at
Whether these explain the need for updates and compliance checks.
Good evidence
Clear communications advising on scanning outcomes and required actions.
- Check 5 of 5What an auditor asks for
Ask for
Backup personnel records: Confirm who is designated as backup support for the scanning process.
Look at
Training records for this person.
Good evidence
A named backup with completed training records on vulnerability scanning.
Mappings
Closest match in ASD Essential Eight: E8-PO-ML3.2, At least fortnightly use of a vulnerability scanner for firmware, which asks for the same thing.
ISO/IEC 27001: 1 mapping
This control partially meets A.8.8.
ISM-1900 requires a specific operational practice: using a vulnerability scanner at least fortnightly to identify missing firmware patches or updates. ISO/IEC 27001:2022 Annex A 8.8 requires organisations to obtain information about technical vulnerabilities, evaluate exposure, and take appropriate measures, covering the full vulnerability management lifecycle. ISM-1900 is a concrete, firmware-focused detection activity that fits within the broader expectations of Annex A 8.8.
ASD Essential Eight: 4 mappings
This control is equivalent to E8-PO-ML3.2.
E8-PO-ML3.2 requires a vulnerability scanner to be used at least fortnightly to identify missing patches or updates for vulnerabilities in firmware. ISM-1900 states the same requirement with the same frequency and the same firmware-specific scope. Implementing ISM-1900 would largely satisfy E8-PO-ML3.2 and vice versa.
This control partially overlaps E8-PO-ML1.3.
E8-PO-ML1.3 requires daily vulnerability scanning to identify missing operating system patches/updates on internet-facing servers and network devices. ISM-1900 requires at least fortnightly vulnerability scanning to identify missing patches/updates, but for firmware rather than operating systems. They overlap in the vulnerability-scanning mechanism and missing-update objective, but differ in target component (OS vs firmware) and required frequency.
This control supports E8-PO-ML1.2.
ISM-1900 requires using a vulnerability scanner at least fortnightly to identify missing firmware patches or updates. E8-PO-ML1.2 requires that the vulnerability scanner used has an up-to-date vulnerability database, which is necessary for accurate identification of missing patches and known firmware vulnerabilities. In practice, ISM-1900 depends on E8-PO-ML1.2 to ensure scanning results are current and trustworthy.
- E8-PO-ML3.8Firmware vulnerabilities patched within one month if non-critical and no exploitsSupports
This control supports E8-PO-ML3.8.
E8-PO-ML3.8 requires organisations to remediate non-critical firmware vulnerabilities within one month when no working exploits exist. ISM-1900 supports this by requiring at least fortnightly vulnerability scanning to identify missing firmware patches/updates, helping organisations detect what needs to be applied to meet the one-month deadline. ISM-1900 is about identification and verification of missing firmware patches rather than the remediation timeframe itself.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.