Patch applications ML2: Essential Eight requirements

What Essential Eight patch applications ML2 asks for

To pass an assessment at Maturity Level Two for patch applications, you must show an assessor that every ML1 scanning cadence and deadline still holds and that two new ML2 controls are working. The ML1 requirements carry over unchanged into the ML2 baseline: asset discovery, daily and weekly scanning, the 48 hour and two week deadlines for online services, the two week deadline for common user applications, and removal of unsupported products. ML2 adds fortnightly vulnerability scanning of applications other than office suites, browsers and extensions, email clients, PDF applications and security products (ISM-1700), and patching those other applications within one month of release (ISM-1693). Confirm both control IDs and their wording against the ISM OSCAL catalog your assessor uses, since the ML2 profile is the reference point for what gets tested.

The risk behind these controls is familiar. Unpatched applications on internet-facing services and on user endpoints are a common route into an organization, and the ML2 additions widen the set of applications that must be patched on a fixed clock. Most of the difficulty is not the scanning itself. Asset inventories tend to have gaps, particularly for line-of-business tools, developer utilities and software installed outside central deployment, so an application that the scanner never sees is never patched on time. Patch ownership is split across application owners, desktop teams and business units, and a scan finding with no named owner and due date tends to age past the one month deadline without anyone noticing.

Start by reconciling your asset inventory against what your scanners actually report, then assign each non-exempt application an owner and a patch clock that starts at vendor release. Ask your scanning tool vendor, or check its documentation, which fields record installed version, first-seen date and remediation status, because those fields are the evidence an assessor will ask to see. Keep a dated record of scan runs to show the fortnightly cadence was met across the assessment period, and keep exception approvals with their expiry dates. Where you need outside help to build this evidence trail, the work is preparing systems and records for assessment, while the maturity conclusion itself comes from the assessor.

Which applications and systems fall under the one month deadline

At ML2, anything outside the named exemptions falls into the one month patch window, so scope decisions determine most of the workload. The cards below cover the questions that change the scan and patch volume most: what counts as an application, which hosts run it, and who patches what in managed or SaaS environments.

Defining the other category

The fortnightly scan and one month deadline apply to applications that are not office suites, browsers and extensions, email clients, PDF applications or security products. Start with a complete inventory of installed software, including runtimes, libraries with user-facing components, developer tools and vendor agents. Each item left in the other category adds to the scan scope and to the patch queue, so record the decision for every exemption category you rely on.

Hosts and servers in scope

The deadline covers applications on every endpoint and server in the assessed boundary, not only staff workstations. Build-server agents, jump hosts, and application servers that run line-of-business software usually carry the largest share of the other category. Confirm that your asset discovery reaches these hosts, because an unscanned server is also an unpatched server in an assessor's view.

Developer and engineering tools

Package managers, IDEs, container runtimes and command-line utilities often sit outside the named exemptions and change frequently. Their version drift can be high, so they generate recurring patch work. Decide whether these tools are managed centrally, pinned to approved versions, or left to individual engineers, and document the choice because the scan and deadline apply either way.

Third-party managed and SaaS applications

Where a provider operates the application, the organization still needs evidence that the provider patches within the one month window, usually through contract terms, service reports or provider attestations. Self-hosted components that the provider delivers to you remain your patch responsibility. Ask each provider how they notify customers of fixes and whether they publish release dates you can track.

Exempt products that still need checks

Browsers, PDF applications, email clients and security products are exempt from the other category, but they still appear in the ML1 scanning and deadline controls. Do not assume an exemption removes the product from your inventory. Confirm which deadline each exempt product falls under, and keep the mapping in your evidence set so an assessor can follow it.

Scan coverage and asset records

Fortnightly scanning only helps if the scanner sees the same applications your inventory lists. Compare scanner coverage with the asset register at each cycle, and record hosts that were offline, unauthenticated or excluded. Tools such as Wazuh, Fleet and Greenbone each depend on different collection methods, so confirm what software data each one can actually read in your environment.

How an assessor tests patch applications at ML2

This table sets out what an assessor samples, compares and asks for across the ML2 additions and the ML1 patch controls that remain in the baseline. Read each row as a test step paired with the evidence that passes it and the gap that usually causes a finding.

Test area	What the assessor checks	Evidence requested	Common finding
Scan schedule (ISM-1700)	Fortnightly vulnerability scanning covers applications other than office suites, browsers and extensions, email clients, PDF applications and security products	Scan task definitions, schedule history for a sample of scan windows, and reports for each cycle	Scans run monthly or ad hoc, or the scan profile omits in-scope application categories
Scan coverage against inventory	Every in-scope host appears in the scanner's target list and is matched to the asset register	Asset inventory export, scanner target list, and a reconciliation showing hosts with no scan result	Unmanaged or newly provisioned hosts are absent from scan scope with no exception raised
Patch deadline for other applications (ISM-1693)	Patches for other applications are applied within one month of release, sampled across recent vendor releases	Release dates, change or deployment records, and installed version evidence for the sampled applications	Patches land after one month with no documented exception, risk acceptance or compensating control
ML1 deadlines carried into ML2	Online service and common user application deadlines still meet the ML1 timeframes, unchanged in the ML2 baseline	Patch timelines for internet-facing services and common user applications, with dated deployment records	Deadlines are tracked informally, so missed patches are discovered only during the audit sample
Unsupported application removal	Unsupported applications are identified in the inventory and removed or formally tracked	Inventory list of unsupported products, removal records, and any approved exception with an owner and review date	Unsupported software remains in use with no exception record or review
Event log protection (ISM-1815)	Logs are protected from unauthorised modification and deletion	Log store access control lists, retention settings, and evidence of write-once or restricted deletion rights	Administrators can alter or delete logs with no alerting or review
Log analysis (ISM-1906, ISM-1228)	Logs from internet-facing servers and detected cyber security events are analysed in a timely manner	Alert rules, sample alert triage records, and dated analyst review notes	Logs are collected but no analysis or alerting is documented
Incident reporting (ISM-0123, ISM-0140, ISM-1819)	Incidents are reported to the CISO and to ASD, and the incident response plan is enacted	Incident register, reporting records, and the incident response plan version in use	Plan exists but sampled incidents show no reporting record or plan activation

Sequence to reach ML2 patch applications

This sequence moves an existing Maturity Level One patch applications practice to Maturity Level Two by widening scan scope, adding a one month deadline for other applications, and tying every finding to a tracked remediation record. Each step ends with an artifact an assessor can inspect.

Confirm the ML1 baseline is operating
The engineering lead and compliance lead review the existing ML1 patch applications controls before changing anything. They confirm asset discovery runs on the stated cadence, that daily and weekly scans complete, and that the 48 hour and two week deadlines for online services and the two week deadline for common user applications are being met. The output is a short baseline record listing each ML1 control, its current evidence, and any gaps to close first. Because ML2 keeps the ML1 controls unchanged, a gap here will carry into ML2 unless it is fixed now.
Build the asset and application inventory
The engineer confirms which software inventory source feeds scanning, such as agents on endpoints or a discovery tool on the network, and lists every application that falls outside the excluded categories. Excluded categories are office suites, browsers and extensions, email clients, PDF applications and security products, which ML2 handles through the ML1 deadlines. The output is an application inventory with an owner and a scan-scope tag for each entry. Ask the auditor which inventory evidence they expect to sample before finalizing the format.
Document the fortnightly scan schedule and scope
The engineer configures a scan task that runs fortnightly against the other applications identified in the inventory, separate from the existing daily and weekly scans. The compliance lead records the scope in a scope record that names the target groups, the tool, and the schedule. The step is done when the first scheduled run has completed and its report is stored. Scanning tools such as Greenbone Community Edition, which schedules scan tasks and stores results in PostgreSQL, can produce this history if they are configured for the scope.
Set the one month patch deadline policy
The compliance lead writes a deadline policy requiring applications outside the excluded categories to be patched within one month of release. The policy names the owners responsible for each application group, the approval route for the patch, and how release dates are recorded. The step closes when the policy is approved by the accountable executive and published to the teams that run the applications. Confirm with your assessor how they expect the release date to be evidenced for vendor patches.
Define the exception process
The compliance lead defines how a team requests more time when a patch cannot be deployed within one month, such as a vendor compatibility issue or a change freeze. Each exception needs a documented reason, a named risk owner, a compensating action, and an expiry date set by the accountable executive. The output is an exception register and a written procedure. Exceptions that never expire, or that lack a risk owner, are a common reason an assessor will question the control, so the register should be reviewed on a regular cycle.
Wire scan findings into ticketing
The engineer connects scan output to the ticketing system so each finding creates or updates a remediation ticket with the affected application, severity, owner, and deadline from the policy. Tools such as DefectDojo can import scan reports, deduplicate findings, and track them over time, which reduces duplicate tickets. The step is done when a test finding flows from scan to ticket to closure with the timestamps preserved. The output is a ticket trail that links each finding to its patch, exception, or verification record.
Test the sequence and collect the evidence pack
The compliance lead runs a walkthrough in which the team selects a sample of applications and traces each from inventory through scan, deadline, patch or exception, and closure. Gaps found in the walkthrough are logged and fixed before the evidence pack is assembled. The pack contains the baseline record, inventory, scan schedule and scope record, deadline policy, exception register, and ticket samples. The independent assessor, not the implementation partner, decides whether the evidence meets ML2.

Why ML2 also brings log protection and incident reporting into scope

At Maturity Level Two, the patch controls are not the only ones an assessor tests. The same ML2 baseline also requires that event logs be protected from unauthorised modification and deletion (ISM-1815), that event logs from internet-facing servers and detected cyber security events be analysed in a timely manner (ISM-1906 and ISM-1228), and that incidents be reported to the CISO and to ASD, with the incident response plan enacted (ISM-0123, ISM-0140 and ISM-1819). These controls sit in the same Essential Eight baseline profile as the fortnightly scanning and one month deadline, so a patch program that works on paper but has no protected logs or tested incident path will not satisfy ML2.

Practically, the logging question is about where the evidence lives. Scanner output, patch records and alerts from a vulnerability tool should be forwarded to a central store that administrators of the source systems cannot quietly edit or purge. Confirm with your own team who can write to, rotate and delete that store, whether retention is set in policy, and whether an assessor can see the access settings as well as the logs. Those answers determine whether ISM-1815 is met in practice, and they are easier to settle before the first assessment than during it.

Patch findings also feed the incident process more often than teams expect. A critical vulnerability with signs of exploitation on an internet-facing application may need to move from the patch queue into the incident response plan, with a defined owner, a severity threshold and a record of who was told. Decide in advance which scanner findings trigger incident handling, who makes that call, and how the outcome is recorded. An assessor will usually ask for an example of that path working, so a documented, rehearsed route is worth more than a policy that has never been used.

Evidence that satisfies patch applications at ML2

An assessor testing patch applications at ML2 looks for records that prove the cadence ran, the inventory was complete, the deadlines were met and the exceptions were approved. The cards below cover the artifacts that carry that proof and how to keep them current between assessments.

Scan schedules and completed reports

Show the scan task definitions and a run history proving that applications other than office suites, browsers and extensions, email clients, PDF applications and security products were scanned every two weeks. Keep the schedule export alongside the report set, so an assessor can see both the configured cadence and the runs that actually happened. Gaps in the run history are the most common finding, so check for missed or failed runs each cycle. Greenbone Community Edition can schedule tasks and store results in PostgreSQL, and Wazuh vulnerability detection can supply endpoint findings. Confirm that either tool covers your application set before relying on it.

Asset inventory coverage records

A scan report only proves coverage for assets the scanner knows about. Keep an inventory export that lists each endpoint and server, the software installed on it and the date the inventory was last refreshed, then reconcile it against the scan targets. Wazuh builds its software inventory from agents, and Fleet matches installed software on enrolled hosts, so either can supply the inventory. Ask the assessor which asset sources they will accept, and document any asset class that a tool cannot see.

Patch records against the one-month deadline

For each vulnerability in a non-excluded application, record the release date, the date the finding was raised, the patch date and the verification scan that confirmed the fix. The one-month deadline applies to patching those other applications within one month of release, so the release date is the figure an assessor will check first. DefectDojo can import findings from many scanner formats and deduplicate them with per-tool hashcode fields, which keeps one finding tied to one remediation record. Confirm the release date source you use for each vendor.

Exception approvals with expiry dates

Where an application cannot be patched within the deadline, the organization needs a documented, approved exception with a named owner, a compensating control, a review date and an end date. Assessors test whether exceptions are rare, justified and actually closed. Store approvals in the same tracker as the findings so the link between finding, exception and final fix can be shown without manual reconstruction. The organization owns the approval decision, not the implementation partner or the tool.

Protected log configuration

ML2 requires event logs to be protected from unauthorized modification and deletion. Evidence is the configuration showing where logs are forwarded, who can read or write them, and how deletion is blocked or alerted. Export the access control list for the log store and a sample of integrity or tamper checks. Wazuh and similar agents can forward logs to a central store, but the organization must verify that the storage permissions and retention settings meet the control, since the tool default may not.

Incident reports and analysis records

ML2 expects logs from internet-facing servers and detected cyber security events to be analyzed in a timely manner, and incidents to be reported to the CISO and to ASD with the incident response plan enacted. Keep dated analysis notes for alerts from vulnerability and log tooling, plus incident reports showing escalation, notification and response steps. Assessors look for the timing between detection and escalation, so record both timestamps. Confirm the reporting route to ASD with your own incident response team, since the tools do not handle that step.

What meeting patch applications ML2 costs

This table breaks down the cost components of meeting the ML2 application patching baseline, marking each as one-time or recurring and naming what pushes it up or down. Use it to structure a written quote, since no price figures are published for this work and the costs depend on your estate. The main takeaway is that open-source scanning can remove license spend, but staff time for deadline tracking, exceptions and evidence stays.

Cost component	Who is paid or who spends time	One-time or recurring	What drives it up or down
Tooling and licenses	Software vendor for commercial scanners; your team for self-hosted open-source platforms	Recurring if commercial; open-source removes license spend but not hosting	Up: number of endpoints and applications in scope. Down: self-hosted options with no per-seat license
Engineering time to extend scanning	Internal platform team or implementation partner	One-time, plus upkeep when scanning scope changes	Up: number of application types outside office suites, browsers and email clients. Down: a standard inventory source and reusable scan configuration
Deadline tracking build	Internal engineers or implementation partner	One-time build, recurring maintenance	Up: several ticketing or patch systems. Down: one tracker that records release dates against the one month deadline
Exception handling	Application owners and security staff	Recurring	Up: number of applications that cannot be patched within one month. Down: documented compensating controls and a short exception register
Evidence upkeep	Internal compliance or security staff	Recurring	Up: manual exports and screenshots. Down: scan and ticket records kept automatically with timestamps
Log protection and analysis	Internal security operations or managed provider	One-time setup, recurring operations	Up: log volume and number of internet-facing servers. Down: central logging with protected storage and defined alert rules
External testing or review	Independent testers or assessors	Recurring, usually per engagement	Up: scope of testing and number of systems. Down: a written scope limited to the patching evidence you need
Independent assessment sampling	Independent assessor, paid by you	Recurring per assessment cycle	Up: number of applications and deadline exceptions sampled. Down: clean, complete records for each sampled patch

Who does what: your team, a partner and the auditor

Your organization owns the controls. Your team decides what is in the application inventory, makes the patch decisions, approves exceptions and accepts the residual risk. An assessor will ask who made each decision, when, and on what basis, so these decisions must be recorded where someone outside the team can read them.

Application inventory: Maintain the list of applications in scope and mark which ones fall under the ML2 fortnightly scanning requirement (ISM-1700) and which are covered by other requirements.
Patch decisions: Decide which patches ship within the one month deadline for other applications (ISM-1693), and document the change window and the reason for any delay.
Exception approvals: Name who approves each exception, the compensating control, and the date it will be reviewed. Exceptions without a named owner tend to become permanent.
Log and incident ownership: Decide who reviews event logs from internet-facing servers and who is notified when a cyber security event is detected, so the incident reporting requirements (ISM-0123, ISM-0140) have a clear path.

Before any assessment, check that every decision above has a named owner and a dated record that an assessor can follow without a walkthrough.

Where organizations fall short on ML2 patch cadence

Most organizations that aim for Maturity Level Two already run some scanning and patching, so the shortfall is rarely effort. The gaps cluster around what gets scanned, how deadlines are tracked, and whether the evidence can be trusted. Each card names one gap and the step that closes it.

Incomplete application inventory

Fortnightly scanning of applications only covers what the scanner knows exists. Organizations often discover that departmental tools, developer utilities and vendor-installed software were never enrolled. Before the ML2 cadence can be proven, run asset discovery across endpoints and servers and reconcile the results against a software list owned by a named person. Check the gap by picking ten machines at random and comparing their installed applications with the scanner's inventory.

Blind spots for SaaS and unmanaged apps

Scanners that rely on installed agents cannot see browser-based services, unmanaged laptops or applications that users installed outside IT. ISM-1700 covers applications other than office suites, browsers, email clients, PDF applications and security products, so the scope question matters. Document which applications fall into each group, record the owner of each hosted service, and confirm with the vendor how each product reports its version and patch status.

Patch deadlines tracked in spreadsheets

A one month deadline for applications other than the common categories is only defensible if each missed date has a recorded reason. Spreadsheets rarely hold that trail. Move findings into a tracker that stores the due date, the owner, the change record and any approved exception with its expiry and approver. An assessor will ask for the exception history, not just the current list of open items.

Duplicate findings across scanners

Two scanners often report the same vulnerability under different identifiers, which inflates backlogs and hides real overdue items. Deduplication must happen before deadlines are measured. DefectDojo deduplicates findings using per-tool hashcode fields, so confirm how each imported report is keyed and that re-imports update existing findings instead of creating new ones.

Logs that administrators can alter

ML2 requires event logs to be protected from unauthorised modification and deletion, and the scan records that prove patching are logs too. If the same administrators who patch systems can clear the scanner database or the central log store, the evidence is weak. Forward logs to a store with separate administrative accounts, restrict deletion rights and test that a sample deletion attempt is refused and recorded.

Incident reporting disconnected from scan findings

ISM-0123, ISM-0140 and ISM-1819 expect incidents to be reported to the CISO and to ASD, and the incident response plan to be enacted. When a scan shows an exploited internet-facing application, that finding should open an incident path rather than sit in a backlog. Agree the trigger criteria with the incident team, link the scanner's critical findings to the response queue, and rehearse one case end to end.

Questions buyers ask about ML2 patch applications

How much more effort does ML2 patch applications add over ML1?

ML2 adds two new requirements to the ML1 patch applications baseline, and the ML1 requirements stay in place unchanged. The new work is fortnightly vulnerability scanning of applications other than office suites, browsers and extensions, email clients, PDF applications and security products (ISM-1700), and patching those other applications within one month of release (ISM-1693). The effort depends on how many applications sit in that category, how much of your estate already reports into a scanner, and whether your change process can absorb a monthly patch deadline without exceptions piling up. Confirm the exact control wording against the ISM OSCAL catalog and the ASD maturity model before you scope the work, because your assessor will test against those documents, not against a summary.

How long does the ML2 patch applications work take?

No fixed duration applies because the answer depends on your estate. The main drivers are the size and diversity of your application inventory, whether asset discovery and scanning already run, the number of applications that fall outside the excluded categories, and how many change windows you can use for a one month deadline. Teams with mature asset inventories usually spend most of the time on tuning scans and clearing a backlog. Teams without one spend most of it building the inventory first. Ask any partner for a written plan that lists each dependency, and ask your assessor which evidence period they expect to see before they accept a control as operating.

What does the work need from our internal team?

The work needs an owner for the application inventory, an operator for the scanner, an approver for exceptions, and a change team that can deploy updates within one month. Security engineers usually configure scanning and tune findings, while application owners decide on upgrades and document any accepted risk. ML2 also brings the log protection, analysis and incident reporting requirements (ISM-1815, ISM-1906, ISM-1228, ISM-0123, ISM-0140 and ISM-1819), so the people who run your SIEM or log platform and your incident response plan need to be involved. Confirm role assignments in writing, because an assessor will ask who approved each exception and who checked the results.

Can we implement ML2 patch applications ourselves?

Yes, if your team has the skills and capacity to run the scanner, maintain the inventory, and produce the evidence an assessor expects. The ASD documents describe outcomes rather than tools, so an internal team can meet them with any suitable scanner. Outside help is most useful when the inventory is incomplete, when the scanner needs to be deployed in an air-gapped or segmented network, or when the team lacks capacity to run the process every fortnight. DeployOpen plans, implements and hardens self-hosted open-source platforms inside your own infrastructure and prepares evidence for assessment, but it does not issue audit reports or maturity determinations. Scope and deliverables are fixed in writing before work starts.

What will an assessor request as evidence for ML2 patching?

An assessor will typically ask for evidence that the control operates, not just that it exists. Expect requests for the application inventory and how it was built, scan configuration and schedules, scan reports from the fortnightly cadence, records of remediation against the one month deadline for other applications, documented exceptions with approvals, and the log protection and incident reporting records that ML2 adds. Assessors also check whether the evidence covers the stated period. Confirm the required evidence period, sampling approach and format with your independent assessor, and check the ASD Essential Eight maturity model and the ISM OSCAL profiles for the control definitions they will test against.

Can a partner produce the ML2 patch evidence for us?

A partner can prepare the systems, scanner configuration, reports and evidence records that feed an assessment, but only an independent assessor can judge whether your organization meets the maturity level. Ownership of the controls stays with your organization. A useful partner setup produces evidence automatically where possible, such as scan results stored with timestamps, remediation tickets linked to findings, and exception records with approvals. Ask the partner to show how each piece of evidence maps to a control ID, where it is stored, who can alter it, and how long it is retained. The ASD maturity model is not a certification scheme, so there is no ASD certificate to request.

How DeployOpen prepares patch applications ML2 evidence

DeployOpen plans, implements and documents self-hosted open-source scanning and reporting inside your own infrastructure so that the Patch applications ML2 controls can be shown to an assessor. The organization keeps ownership of its controls, and an independent assessor reaches its own conclusions.

How we scope

Engagements are fixed-scope, with the ML2 application scanning and patch deadline controls agreed in writing before work starts.
The written scope lists which applications fall under the fortnightly scan and the one month patch deadline, and which are excluded.
Scope records the asset sources, scanning tools and evidence owners that the ML2 patch applications controls depend on.

How we build

We deploy a vulnerability detection tool such as Wazuh, Fleet or Greenbone inside your environment, configured for a fortnightly scan cadence.
We configure a findings platform such as DefectDojo to track application findings and their patch dates against the one month deadline.
We test the scan and tracking pipeline on sample assets so that the scan records and deadline reports produced are accurate before handover.

How we hand over

You receive configuration documentation, the scan schedule, and a mapping of each ML2 patch applications control to the evidence it produces.
Runbooks explain how to review overdue findings, record exceptions, and export scan and patch records for an assessor.
Handover includes a walkthrough with your security and operations staff so that the evidence process runs without us.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer, which can keep the scan cadence and deadline reporting current.
Retainer work can cover tool upgrades, changes to scanned asset populations, and periodic checks that evidence remains complete.
Confirm with your auditor or assessor which evidence formats and retention periods they require before the scope is finalized.