ISM-1606policyASD Information Security Manual (ISM)

Patch Isolation Mechanisms and Underlying Operating Systems Promptly

When 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.

Preventative NC OS PASD Information Security ManualGuidelines for system hardening Vulnerability management Hardening

record_voice_over

Plain language

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.

01 - Overview

Framework

ASD Information Security Manual (ISM)

Control effect

Preventative

Classifications

NC, OS, P, S, TS

ISM last updated

June 2026

Control Stack last updated

18 June 2026

E8 maturity levels

N/A

Guideline

Guidelines for system hardening

Section

Virtualisation Hardening

Topic

Functional Separation Between Operating Environments

Official control statement

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.

policyASD Information Security Manual (ISM)ISM-1606

priority_high

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.

settings

Operational notes

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.

02 - Implement

build

Implementation tips

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.

03 - Audit

fact_check

Audit / evidence tips

AskWhich software-based isolation mechanisms (hypervisors or container engines) do you run that share physical resources, and what operating system sits underneath each one?Look atAn inventory listing each isolation product, its version, and the host operating system and versionGoodA current inventory naming each product and host OS, with an owner assigned to keeping each one patched
AskHow quickly must patches, updates and vendor mitigations be applied, and does that timeframe cover both the isolation software and the underlying operating system?Look atA written policy stating maximum timeframes by severity that explicitly names both layersGoodA policy with defined timeframes (for example critical within 48 hours) that applies equally to the isolation mechanism and the host operating system
AskCan you show the patch history for the isolation mechanism AND for its underlying operating system over the last few months?Look atPatch or update logs for both layers with dates applied compared against vendor release datesGoodLogs showing both layers were updated within the policy timeframe after each vendor release
AskHow do you find out when a new patch, update or vendor mitigation is released?Look atEvidence of subscriptions to vendor security advisories or a vulnerability monitoring feed covering the isolation products and host operating systemsGoodActive subscriptions or alert feeds for every isolation product and host OS in the inventory
AskWhat did you do the last time a vulnerability was announced but no patch was available yet?Look atA record showing the vendor mitigation was applied as an interim step, then replaced by the full patch laterGoodA documented case where the vendor mitigation was applied promptly and the permanent patch followed within the policy timeframe

04 - Mappings

link

Cross-framework mappings

How ISM-1606 relates to controls across ISO/IEC 27001, ISO/IEC 42001, Essential Eight, and ASD ISM.

ISO 27001

Control	Notes	Details
layersPartially meets(1)expand_less
Annex A 8.8	ISM-1606 requires timely remediation of vulnerabilities by applying patches, updates or vendor mitigations to software-based isolation me...
handshakeSupports(2)expand_less
Annex A 8.19	ISM-1606 requires timely remediation of vulnerabilities affecting software-based isolation mechanisms and the underlying host operating s...
Annex A 8.32	ISM-1606 requires timely application of patches, updates or vendor mitigations to isolation mechanisms and their underlying host operatin...

E8

Control	Notes	Details
sync_altPartially overlaps(4)expand_less
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
E8-PO-ML1.6	ISM-1606 requires timely remediation of vulnerabilities by applying patches/updates/mitigations to the isolation mechanism and the underl...
E8-PA-ML2.2	E8-PA-ML2.2 requires patching of non-critical applications within one month of release
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 un...