ASD ISM 1606 Patch isolation mechanisms and underlying operating systems promptly
What it says
When using a software-based isolation mechanism that consumes shared physical computing resources, patches, updates or vendor mitigations for vulnerabilities are applied to the isolation mechanism and underlying operating system in a timely manner.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishWhen you run a software-based isolation mechanism that shares the same physical computing resources (for example, a hypervisor that runs several virtual machines on one physical server, or a container engine that runs many containers on one host), you must keep both the isolation mechanism and the operating system it runs on up to date. As soon as the vendor releases a patch, an update, or a vendor mitigation for a known vulnerability, you apply it in a timely manner. This applies to both layers: the isolation software itself AND the underlying operating system beneath it.
A software-based isolation mechanism is software that keeps separate workloads apart even though they share the same physical hardware. Common examples are a hypervisor (the software that lets one physical server run many virtual machines side by side) and a container engine (software like Docker that runs many small isolated applications on one host). Because all of those workloads share the same processor, memory, and disk, a single flaw in the isolation software or in the operating system underneath it can let an attacker break out of one workload and reach the others. This control says: whenever the vendor releases something to fix a known security weakness, you apply it quickly. There are three kinds of fixes to watch for. A patch is a small piece of software that corrects a specific flaw. An update is a newer version that may bundle several fixes together. A vendor mitigation is an official instruction from the vendor (such as a configuration change or a setting to disable a feature) used when no patch exists yet. You must apply these fixes to both the isolation mechanism (the hypervisor or container engine) AND the underlying operating system it runs on. Doing only one of the two leaves a gap. "Timely" means acting within the timeframe your organisation has set for the severity of the flaw, not whenever it happens to be convenient.
Free. Save your status, tasks and notes.
Why it matters
Unpatched flaws in an isolation mechanism or its host OS can let an attacker break out of one virtual machine or container and reach all others on the shared hardware.
How to implement
The platform or virtualisation team subscribes to the security advisory feeds for every isolation product in use (for example VMware ESXi, Microsoft Hyper-V, KVM, or Docker) and for the host operating system, so new patches, updates and vendor mitigations are seen as soon as they are released.
The system owner sets a written maximum timeframe to apply fixes based on severity (for example critical flaws within 48 hours, others within two weeks) and applies that same timeframe to BOTH the isolation mechanism and the underlying operating system, not just one of them.
The IT team patches the host operating system underneath the hypervisor or container engine on the same schedule as the isolation software itself, because a flaw in either layer can let an attacker break out of an isolated workload.
When the vendor publishes a mitigation but no patch yet exists, the IT team applies that vendor mitigation (such as disabling an affected feature or changing a configuration setting) straight away and records the change, then applies the full patch when it is released.
The platform team uses live migration or rolling reboots to move running virtual machines or containers off a host before patching it, so the isolation mechanism and operating system can be updated promptly without waiting for a long maintenance window.
Keep it running
Patch both layers on the same schedule. A current hypervisor on an outdated host OS, or the reverse, still leaves an exploitable gap in the shared hardware.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Which software-based isolation mechanisms (hypervisors or container engines) do you run that share physical resources, and what operating system sits underneath each one?
Look at
An inventory listing each isolation product, its version, and the host operating system and version.
Good evidence
A current inventory naming each product and host OS, with an owner assigned to keeping each one patched.
- Check 2 of 5What an auditor asks for
Ask for
How quickly must patches, updates and vendor mitigations be applied, and does that timeframe cover both the isolation software and the underlying operating system?
Look at
A written policy stating maximum timeframes by severity that explicitly names both layers.
Good evidence
A policy with defined timeframes (for example critical within 48 hours) that applies equally to the isolation mechanism and the host operating system.
- Check 3 of 5What an auditor asks for
Ask for
Can you show the patch history for the isolation mechanism AND for its underlying operating system over the last few months?
Look at
Patch or update logs for both layers with dates applied compared against vendor release dates.
Good evidence
Logs showing both layers were updated within the policy timeframe after each vendor release.
- Check 4 of 5What an auditor asks for
Ask for
How do you find out when a new patch, update or vendor mitigation is released?
Look at
Evidence of subscriptions to vendor security advisories or a vulnerability monitoring feed covering the isolation products and host operating systems.
Good evidence
Active subscriptions or alert feeds for every isolation product and host OS in the inventory.
- Check 5 of 5What an auditor asks for
Ask for
What did you do the last time a vulnerability was announced but no patch was available yet?
Look at
A record showing the vendor mitigation was applied as an interim step, then replaced by the full patch later.
Good evidence
A documented case where the vendor mitigation was applied promptly and the permanent patch followed within the policy timeframe.
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.
ISM-1606 requires timely remediation of vulnerabilities by applying patches, updates or vendor mitigations to software-based isolation mechanisms and the underlying host operating system on shared physical servers. Annex A 8.8 is broader, requiring organisations to obtain information about technical vulnerabilities, evaluate exposure, and take appropriate measures across information systems in use. ISM-1606 is a specific, operationally focused instance of Annex A 8.8 applied to virtualisation/isolation platforms and their host OS patching/mitigation actions.
This control depends on A.8.19.
ISM-1606 requires timely remediation of vulnerabilities affecting software-based isolation mechanisms and the underlying host operating system on shared servers. Annex A 8.19 supports ISM-1606 by requiring secure procedures for software installation on operational systems, which underpins controlled installation of hypervisor updates, host OS patches and vendor mitigations without introducing integrity risks. Annex A 8.19 does not itself set expectations about vulnerability urgency or isolation-specific scope, which are central to ISM-1606.
ASD Essential Eight: 4 mappings
This control partially overlaps E8-PA-ML2.2.
E8-PA-ML2.2 requires patching of non-critical applications within one month of release. ISM-1606 overlaps by requiring timely patching/mitigation of vulnerabilities for isolation mechanisms and underlying operating systems in virtualised environments, which is also a form of timely vulnerability remediation. ISM-1606 is scoped to virtualisation components and does not specify the same one-month SLA or the same application category focus as E8-PA-ML2.2.
This control partially overlaps E8-PO-ML1.5.
ISM-1606 requires patches, updates or vendor mitigations to be applied in a timely manner to software-based isolation mechanisms (e.g. hypervisors) and their underlying host operating systems when sharing physical server hardware. E8-PO-ML1.5 overlaps by mandating rapid remediation (within 48 hours) for critical/exploited operating system vulnerabilities on internet-facing servers and network devices, which can include exposed hypervisor hosts. The overlap is limited to the host operating system patching outcome; ISM-1606 also explicitly includes the isolation mechanism itself and is not limited to internet-facing assets or to 'critical' classifications.
- E8-PO-ML1.6Timely application of non-critical patches for internet-facing OS vulnerabilitiesPartially overlaps
This control partially overlaps E8-PO-ML1.6.
ISM-1606 requires timely remediation of vulnerabilities by applying patches/updates/mitigations to the isolation mechanism and the underlying host operating system on shared physical servers. E8-PO-ML1.6 overlaps where the underlying host operating system is on an internet-facing server/device, requiring non-critical OS vulnerabilities to be addressed within two weeks. ISM-1606 remains distinct because it targets the isolation layer as well as the host OS and is framed around maintaining safe multi-tenancy rather than exposure-based patch SLAs.
This control partially overlaps E8-PO-ML3.3.
ISM-1606 requires patches/updates/vendor mitigations to be applied in a timely manner to both the software isolation mechanism and the underlying host operating system for shared physical servers. E8-PO-ML3.3 overlaps by imposing a 48-hour timeframe for critical/exploited operating system vulnerabilities on workstations and non-internet-facing servers/devices, which includes typical hypervisor host OSs that are not internet-facing. The shared requirement is timely host OS remediation, but ISM-1606 also explicitly covers the isolation mechanism itself and does not constrain triggering conditions to vendor criticality or exploit availability.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.