Patch operating systems ML2: Essential Eight requirements

Why Essential Eight patch operating systems at ML2 looks like ML1 and what changes

If your organization is moving from Maturity Level One to Maturity Level Two and expects operating system patching to get harder, the ASD tags say otherwise. The ML2 operating system scanning, patching and replacement controls are the same set as ML1: ISM-1701, ISM-1702, ISM-1877, ISM-1694, ISM-1695, ISM-1501, ISM-1807 and ISM-1808. The step up comes from logging, log analysis and incident response, not from patching. Your existing patch program can usually carry forward unchanged, provided it already meets the ML1 cadence and deadlines. The reason patching stays central is simple: an unpatched operating system gives an adversary a known route in, and attackers often reuse public exploits against flaws that vendors have already fixed. The ML2 baseline still holds the one month operating system patch deadline for workstations, non-internet-facing servers and non-internet-facing network devices (ISM-1695 is tagged at ML1 and ML2). Confirm that your asset inventory covers every endpoint in that population, because the deadline is only as good as the list of systems it applies to.

The overall ML2 Essential Eight baseline holds 87 ISM controls across all eight strategies, against 46 at ML1, so most of the new work sits outside patching. Treat the move as a logging project. Decide where event logs from internet-facing servers will be collected, confirm that logs are protected from unauthorised modification and deletion (ISM-1815), and assign someone to analyse detected cyber security events in a timely manner (ISM-1906, ISM-1228). Then confirm that incidents are reported to the CISO and to ASD, and that the incident response plan is enacted (ISM-0123, ISM-0140, ISM-1819). For the patching tasks you keep, have your scanning tool produce evidence an assessor can read: scan dates, the software inventory per host, and remediation records against each deadline. Wazuh's vulnerability detection, for example, correlates each agent's software inventory with its vulnerability feed, so you can show what was found and when it was closed. Confirm with your assessor which evidence format they accept before you build the reporting.

Which systems and teams fall under Essential Eight patch operating systems at ML2

Patch operating systems at ML2 applies the same patching controls as ML1, so the scope question is less about new deadlines and more about which systems sit in which exposure group and which logs must reach central logging. Each card below is a decision the organization owns before it can show evidence to an assessor.

Internet-facing versus internal servers

Internet-facing servers and non-internet-facing servers are separated in the ISM Essential Eight tags, so the inventory must record exposure for each server before patch deadlines can be applied. Ask who maintains the exposure flag, how it is updated when a server gains a public address or load balancer rule, and whether the assessor will sample servers from both groups. A server that is internal today but reachable through a forgotten NAT rule is a common finding.

Workstations keep the one month deadline

Workstations keep the one month operating system patch deadline at ML2 under ISM-1695, which is also the deadline for non-internet-facing servers and non-internet-facing network devices. Teams often assume workstations need the faster cadence used for exposed systems, so this group is easy to mis-scope in either direction. Confirm which device classes your asset register labels as workstations, including laptops that roam outside the corporate network.

Non-internet-facing network devices

Switches, firewalls, routers and load balancers that do not face the internet still fall under the operating system patching controls and the same one month deadline. Network teams often run firmware and operating systems through vendor tooling outside the server patch process, so the scanner may never see them. Ask which team owns each device class, whether scanning covers management interfaces, and how the vulnerability list is reconciled with the change calendar.

Log sources for central logging

ML2 requires event logs to be protected and analysed, so the scope must name every endpoint, server, network device and cloud service that produces security-relevant events. Build the list from the asset inventory rather than from memory, and note which sources send logs natively and which need an agent or forwarder. Missing sources are a frequent gap because logging gets added after the patching scope is already agreed.

Third-party platforms holding logs

Some logs sit with SaaS providers, managed service providers or cloud platforms the organization does not operate. For each one, confirm whether the provider exports logs to the organization's store, how long the provider retains them, and whether the organization can demonstrate that those logs are protected from modification and deletion. Where the provider will not export, record the gap and the compensating process in the scope document before the assessment.

Owners for each system group

Each exposure group and log source needs a named owner who signs off on scope, patch status and log coverage. Infrastructure, network, endpoint and cloud teams often each hold part of the estate, so unclear ownership leaves systems unpatched or unlogged without anyone noticing. Ask for a responsibility matrix that maps every system group to one accountable team and to the person who reports incidents to the CISO.

How an assessor tests operating system patching and the ML2 logging controls

This table compares each control area an assessor reviews for operating system patching and the logging, analysis and incident response controls that ML2 adds. Read each row as a question the assessor asks, the records they request, and where organizations most often fall short. The main takeaway is that the patching tests look the same at ML1 and ML2, so most of the ML2 effort sits in logs and incident handling.

Control area	Test approach	Evidence requested	Common findings
Operating system scanning cadence and coverage	Compare the scan schedule and asset inventory against the requirement, then sample endpoints and servers to confirm they appear in scan results.	Scan schedules, scan job history, asset inventory export and scan reports dated across the review period.	Scanners configured for some subnets only, or inventories that omit workstations and internal servers.
Patch deadline compliance	Select a sample of operating system vulnerabilities, trace each to its patch date, and check the date against the deadline for that system type.	Vulnerability tickets, patch deployment logs, change records and exception approvals with dates.	Workstations and non-internet-facing servers patched later than one month with no approved exception.
Unsupported operating system replacement	Check the register of operating systems against vendor support status, then test whether unsupported systems are replaced or formally risk accepted.	Operating system register, vendor support end dates, replacement plans and signed risk acceptances.	Unsupported systems left in production with no owner, plan or documented acceptance.
Log protection from unauthorised modification and deletion (ISM-1815)	Attempt to trace whether event logs can be altered or removed by standard users and administrators, and review write, retention and access settings on the log store.	Log store access control lists, retention settings, integrity mechanisms, and records of who can change logging configuration.	Administrators able to clear logs without alerting, or log forwarding that is not verified at the central store.
Analysis of logs from internet-facing servers and detected cyber security events (ISM-1906, ISM-1228)	Select internet-facing servers and recent detected events, then trace whether logs were reviewed and whether the review occurred in a timely way.	Log source inventory, alert rules, analyst review records, ticket timestamps and examples of events handled.	Internet-facing servers absent from the log pipeline, or alerts generated but never triaged.
Incident reporting and incident response plan activation (ISM-0123, ISM-0140, ISM-1819)	Review the incident response plan, then walk through a past or simulated incident to confirm the CISO was informed, external reporting was considered and the plan was followed.	Current incident response plan, incident records, CISO notification records, reporting decisions and post-incident reviews.	Plan not updated after staff or system changes, or incidents closed without a documented reporting decision.

How to sequence the ML2 operating system patching and logging work

This sequence moves an organization from its current patch practice to a documented ML2 position, where operating system patching meets the same bar as ML1 and central logging, log analysis and incident response are in place. Each step closes with an artifact you can track.

Confirm the ML2 control list
Start by downloading the Essential Eight ML2 baseline profile from ASD's ISM OSCAL release and filtering it to the operating system patching controls and the logging, analysis and incident response controls. Your team, with your compliance lead, confirms which controls apply to each system class, such as workstations, internet-facing servers and non-internet-facing network devices. The output is a scoped control register that names each ISM control, its owner and the systems it covers. The step is done when the register has been reviewed and signed off by the control owners.
Baseline current patch scanning and deadlines
Measure where you stand before changing anything. Your platform or security team reviews how often vulnerability scans run on each system class, how patches are deployed, and how long fixes have taken in practice against the one month operating system deadline that ML2 keeps for workstations, non-internet-facing servers and non-internet-facing network devices. Open-source vulnerability tooling such as Wazuh or Fleet can produce the inventory and findings you need, but confirm each product's coverage in your environment before relying on it. The output is a baseline report listing overdue patches by system class. The step is done when the report has been reviewed against the register from the previous step.
Close the gap to the one month deadline
Work through the overdue items in the baseline, starting with internet-facing and privileged systems. Assign each gap to an owner, schedule the change through your normal change process, and remove any blockers such as unsupported operating system versions that need a replacement plan. Record exceptions with a documented reason, an approver and a review date. The output is a remediation tracker and a list of approved exceptions. The step is done when the scan results show no unexplained patches past the deadline for the in-scope systems, and the tracker is retained as evidence.
Stand up central log collection with protected storage
Configure logs from operating systems, internet-facing servers and the key applications to flow to a central collector. Set access controls so that engineers cannot modify or delete event logs, and separate who administers the logging platform from who administers the systems being logged. Where an application writes its own audit trail, such as Nextcloud's admin_audit app, confirm the log path and retention settings directly with the product documentation. The output is a log source inventory, a data flow diagram and the access settings for the log store. The step is done when a sample of events from each source appears in the central store and an administrator's attempted deletion is blocked or logged.
Define log analysis triage and alert handling
Decide which events count as cyber security events, how they are reviewed for internet-facing servers, and who triages them within working hours and outside them. Write triage steps that tell an analyst how to classify an alert, when to escalate, and how to record the outcome. Test the rules against known benign and known suspicious activity in a lab or cyber range before they go live. The output is a written analysis procedure, an alert severity matrix and a triage log. The step is done when the procedure has been walked through with the analysts on shift and a test event has been triaged end to end.
Exercise the incident response plan and reporting
Update the incident response plan so that it names the CISO as the internal reporting contact and sets out how incidents are reported to ASD, as the ISM ML2 controls require. Run a tabletop exercise based on a plausible scenario, such as a compromised internet-facing server, and time the handoffs between triage, the CISO and the reporting step. Record gaps and assign fixes. The output is an updated plan, an exercise report with action items and a reporting template. The step is done when the exercise action items are closed, or have approved dates, and the plan has been approved by the accountable executive.

Which evidence shows ML2 operating system patching and logging are working

At Maturity Level Two the operating system patching controls match ML1, so assessors look for proof that scanning and patching run on schedule and that logging is protected and acted on. The six artifacts below connect those two halves and show who owns each one between assessments.

Vulnerability scan reports

Scan reports with timestamps and asset coverage show that operating systems are scanned at the cadence the ML2 baseline requires. Check that every workstation, non-internet-facing server and network device appears in the scan scope, and that the scan source is current. Wazuh and Fleet can both produce inventory-based results, but the vulnerability feed must be updated before each run. The security operations lead should review coverage monthly and sign off the scope list, since missing assets are the most common gap an assessor finds.

Patch records against the deadline

Patch records show when each operating system vulnerability was identified and when it was remediated, measured against the one month deadline that applies to workstations and non-internet-facing servers at ML2. Each exception needs a documented reason, a compensating measure, a named approver and an expiry date. Keep the records in your ticketing or configuration system and export a monthly summary. The IT operations manager signs off the exception register, and the CISO reviews any overdue item.

Unsupported system register

A register of operating systems that have reached end of support, with owner, business justification, isolation measures and a dated replacement plan, shows that unsupported systems are being retired rather than left running. Review the register at each change board meeting and remove entries only when the system is decommissioned or replaced. The asset owner signs each entry, and the CIO or equivalent approves any extension that carries risk into the next review cycle.

Log retention and protection settings

Configuration exports from the log store show that event logs are protected from unauthorised modification and deletion, which is the requirement behind ISM-1815. Capture the retention period, write-once or access-restricted storage settings, and the list of accounts that can alter or purge logs. For Nextcloud, the admin_audit app writes to audit.log in the data directory or to a path set with logfile_audit. For OpenBao, audit device output records every API request, so confirm that the audit device is enabled and its file is not writable by administrators' day-to-day accounts. Infrastructure engineering signs off quarterly.

Log analysis tickets and alerts

Tickets or alert records show that event logs from internet-facing servers and detected cyber security events were analysed in a timely manner, which the ML2 baseline requires under ISM-1906 and ISM-1228. Each alert should carry a timestamp, the analyst, the disposition (benign, false positive, or escalated) and the time taken to close. Sample a set of closed alerts each month to confirm dispositions are reasoned, not just closed. The security operations lead signs off the monthly sample and any alert rule change.

Incident records and reporting trail

Incident records show that cyber security incidents were reported to the CISO and to ASD, and that the incident response plan was enacted, covering ISM-0123, ISM-0140 and ISM-1819. Each record needs the detection time, the notification times, the response steps taken and the closure review. Test the plan at least annually with a tabletop exercise and keep the outputs. The CISO signs off every incident closure, and the legal or compliance lead confirms the external reporting steps were followed.

What meeting ML2 operating system patching and logging costs

This table breaks down the cost components of meeting ML2 operating system patching and the logging controls that ML2 adds, showing who is paid, whether each cost is one-time or recurring, and what moves it. Use it to scope a quote, because the logging work is where most of the step up from ML1 sits. No price figures are given here, so ask each provider for the basis of their estimate.

Cost component	One-time or recurring	What drives it up or down	What to request in a quote
Tooling or licenses	Recurring if commercial, one-time setup otherwise	Commercial scanners and SIEM products are priced by endpoint or data volume. Self-hosted open-source options such as Wazuh remove license spend but not the hosting and operations work.	Itemized license terms, the endpoint or data volume they assume, and any support tier needed for ML2 logging
Engineering time to build central logging	One-time	Number of operating systems, log sources and internet-facing servers in scope. Standard agent deployment across a consistent fleet keeps this down.	A named list of log sources, the collection method for each, and the acceptance test that shows logs arrive centrally
Log storage and retention	Recurring	Log volume, retention period set by the organization, and whether logs are protected from modification and deletion (ISM-1815). Write-once or separated storage adds design work.	Assumed daily volume, retention period, storage location, and how deletion is restricted for administrators
Analyst time for log review	Recurring	Volume of alerts, quality of detection rules, and whether internet-facing server logs are reviewed on a defined cadence (ISM-1906). Tuning reduces noise over time.	Who reviews logs, how often, what counts as a timely analysis, and how detected events are triaged and recorded
Incident response plan and reporting	One-time to draft, recurring to exercise	Number of teams involved, existing plan maturity, and reporting paths to the CISO and ASD (ISM-0123, ISM-0140, ISM-1819). Tabletop exercises add cost each cycle.	The plan owner, the reporting workflow, and what is included in an exercise and its written record
Evidence upkeep	Recurring	Number of systems and controls whose patch cadence, scan results and log configurations must be shown on request. Automated evidence export lowers effort.	Which evidence is exported automatically, which is manual, and how records are versioned and retained
External review or testing	Recurring, usually per engagement	Scope of the review, number of systems tested, and whether it covers logging configuration as well as patch status. Fixed scope agreed in writing keeps it predictable.	A written scope, deliverables, the systems covered, and whether logging and patch evidence are both tested
Auditor sampling	Recurring, per assessment	Number of samples the assessor selects and how quickly records can be produced. Clean, consistent records reduce follow-up requests.	Confirm with the assessor which samples they will request and in what format before the assessment starts

Which self-hosted open-source tools can produce ML2 patch and logging evidence

Four self-hosted open-source components can each generate part of the evidence an assessor will ask for at Maturity Level Two, covering vulnerability detection on endpoints and event logging for application and secrets access. None of them satisfies a control on its own, and each one's output depends on how the organization configures it and what its own applications emit.

Wazuh vulnerability detection

Wazuh correlates the software inventory each agent collects with its CTI vulnerability repository, or a locally hosted offline copy, to identify weaknesses in the operating system and installed applications of monitored endpoints. For ML2 patch operating systems, the export of these findings over time is the evidence of scanning cadence and remediation against the one month deadline for workstations and non-internet-facing servers. Confirm that agents cover every in-scope device class, and that an offline feed is refreshed on a schedule you can show.

Fleet software vulnerability matching

Fleet detects vulnerable software on enrolled hosts by matching installed software against the NVD, OVAL definitions, Microsoft security bulletins, Amazon Linux advisories and OSV. Its host query results give a second, independent view of OS patch state that you can compare with the Wazuh output. Confirm which of these sources apply to your operating systems, since a source that does not cover a platform leaves gaps an assessor will notice.

Nextcloud admin audit logging

The Nextcloud admin_audit app writes additional event information to audit.log in the data directory, or to a path you set with logfile_audit. For ML2 logging, this provides a record of administrative actions on the file platform that can be protected from modification and reviewed for timely analysis. Confirm which events the app captures in your version, where the file is stored, who can write or delete it, and whether it is forwarded to your central log store.

OpenBao audit device logs

OpenBao audit devices keep a detailed JSON log of every API request and response, including errors, with most sensitive values hashed using HMAC-SHA256. This gives a tamper-evident record of secrets and authentication activity that feeds incident response and log analysis at ML2. Confirm that the audit device is enabled before production use, that a failing audit device does not silently stop requests in your configuration, and that your analysts know which fields remain unhashed.

Who owns ML2 patching and logging, and what a partner can take on

The organization owns the decisions that the patching and logging controls depend on. Those decisions set the risk tolerance behind every deadline and every retention period, and they cannot be delegated to a vendor. Staff who run the environment day to day also carry the accountability for acting on what the tools report.

Patch deadlines: Leadership and system owners agree which deadlines apply to workstations, non-internet-facing servers and internet-facing systems, and who approves any exception.
Log retention: The organization decides how long event logs are kept and where they are stored, and it confirms that this matches its legal and contractual obligations.
Incident response: The organization defines who is notified, who reports to the CISO and how incidents are escalated to ASD when required, and it owns the incident response plan.
Asset ownership: Named owners confirm which systems are in scope, which are internet-facing and which are replaced when the operating system goes unsupported.

Before engaging anyone, confirm internally which person signs off on each decision and where those decisions are recorded.

Common questions about meeting Essential Eight ML2 patching and logging

Do Essential Eight ML2 patch deadlines differ from ML1 for operating systems?

No. For operating systems, the ML2 scanning, patching and replacement controls are the same set as ML1, so the patch deadlines do not change at ML2. In ASD's ISM v2026.09.4 Essential Eight tags, the ML2 operating system controls match ML1, and workstations, non-internet-facing servers and non-internet-facing network devices keep the one month operating system patch deadline. The step up at ML2 comes from logging, log analysis and incident response. Confirm the exact cadences and deadlines for your internet-facing and internal systems against the ASD maturity model before you write them into procedures.

How much extra effort does the ML2 logging step add?

The effort depends mostly on how many systems generate logs today and whether those logs leave the host. ML2 requires event logs to be protected from unauthorised modification and deletion, logs from internet-facing servers and detected cyber security events to be analysed in a timely manner, and incidents to be reported and handled under a tested plan. Teams that already forward logs to a central store with restricted write access usually have less to add. Teams that rely on local logs will need collection, retention, access control and alert triage work. Ask any partner to size the work from your asset inventory and log sources, not from a generic estimate.

Can our team meet ML2 patching and logging in-house?

Often yes, if the team has time, clear ownership and someone who can run the logging platform. Patching is largely a matter of consistent scanning, deadline tracking and change control, which many IT teams already perform. Logging and incident response add new work: designing log protection, writing alert rules, triaging events and rehearsing reporting to the CISO and, where required, ASD. The organization still owns its controls. An implementation partner can prepare systems and evidence, but the decisions about risk, reporting and sign-off stay with your own staff.

What skills and staff time does ML2 need from our team?

The work needs three roles: someone who owns the patch process and its evidence, an engineer who runs the log pipeline and alerting, and an incident owner who can run the response plan and make reporting decisions. Smaller organizations often combine these roles. Staff need working knowledge of your operating systems, your log sources and your change process. Time demands are highest during the initial build and the first incident exercise, then fall to recurring reviews of scanning results, alert quality and access to logs. Ask who will do each task and how much of their week it takes before you agree a plan.

How long does ML2 patching and logging work usually take?

Duration depends on the number of endpoints and servers in scope, how current your patch tooling is, how many log sources need onboarding, and how mature your incident response plan already is. Patch scanning and deadline tracking can often be established on existing infrastructure, while central logging, log protection and an exercised incident plan take longer because they touch more systems and people. Request a written timeline from any provider that is tied to a defined scope, listed deliverables and named dependencies, and check that it covers testing and evidence collection as well as installation.

Are open-source tools enough to meet the ML2 patching and logging controls?

Open-source tools can cover much of the evidence trail, but they do not decide whether a control is met. Vulnerability detection tools such as Wazuh correlate each agent's software inventory with a vulnerability repository, which can include a locally hosted offline copy, and Fleet matches installed software against sources including the NVD and OSV. Wazuh and similar platforms can also collect and analyse logs. Protection of logs, alert design, retention and incident procedures still need your own configuration and documentation. Confirm each capability in your environment during a proof of concept before relying on it for evidence.

Will an auditor test our logs or only our patch records?

An assessor will usually test both, because ML2 includes logging and incident response controls alongside the patching controls. For patching, expect requests for scan results, deadline records and evidence that replacement of unsupported systems is tracked. For logging, expect evidence that logs are protected from unauthorised change and deletion, that events from internet-facing servers are reviewed, and that detected events lead to documented incident handling and reporting. Sampling is common, so keep records consistent and retrievable. Note that the Essential Eight is a set of mitigations rather than a certification, so the assessor's report, not a certificate, documents the outcome.

How DeployOpen prepares ML2 patching and logging evidence

DeployOpen plans, implements and documents the self-hosted tooling that produces ML2 patching and logging evidence inside your own infrastructure. Your organization owns its controls, and an independent assessor reviews the evidence and issues any conclusion about maturity.

How we scope

Engagements are fixed-scope, with systems, deliverables and timelines agreed in writing before work starts.
The written scope lists which operating system patch cadences, scanning tools and log sources are in scope for ML2 review.
Scope confirms where log retention, protection and incident reporting responsibilities sit between your teams and DeployOpen.

How we build

We deploy vulnerability detection that matches installed operating system software against vulnerability sources on a defined cadence.
We configure central event logging so logs from internet-facing servers are protected from unauthorised modification and deletion.
We test that alerts for detected cyber security events reach the people named in your incident response plan.

How we hand over

You receive configuration records, scan schedules, patch deadline reports and log protection settings mapped to the ML2 operating system controls.
Runbooks explain how to review scan results, raise patch exceptions and export evidence for an assessor.
Documentation states which evidence is produced by tooling and which must still be recorded by your staff.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
A retainer can cover updates to scan sources, log pipelines and patch reporting as your estate changes.
Confirm with your assessor which evidence formats and review periods they expect before the engagement begins.

Patch operating systems maturity level 2