Which Essential Eight logging requirements apply at ML2 and ML3
From Maturity Level Two, the organization must centrally log application control, PowerShell, command line, privileged access and multi-factor authentication events, protect those event logs from unauthorized modification and deletion, and analyze event logs from internet-facing servers in a timely manner. Cyber security incidents must also be reported to the CISO and to ASD, and the incident response plan must be enacted. The ISM controls behind these requirements include ISM-1660 (allowed and blocked application control events), ISM-1623 and ISM-1889 (PowerShell and command line events), ISM-1509 and ISM-1650 (privileged access and account management events), ISM-1683 (successful and unsuccessful MFA events) and ISM-1815 (log protection). Confirm the exact control wording against the ISM OSCAL profiles on the ASD ISM OSCAL repository, because the logging scope is defined there rather than in this summary.
Maturity Level Three extends timely log analysis from internet-facing servers to all non-internet-facing servers and workstations (ISM-1907 and ISM-0109), and replaces the ML2 analysis requirements for internet-facing servers with stricter versions. The ML3 baseline also replaces three ML2 controls (ISM-1691, ISM-1695 and ISM-1873) with stricter versions. Which systems fall in scope depends on your asset inventory, your network architecture and the target level you have chosen. A logging design that covers only domain controllers and internet-facing servers will meet ML2 expectations but not ML3. Ask your assessor to confirm, before work starts, which systems and event sources they will sample and how they will verify that each source is forwarding to the central store.
The organization owns its logging controls, the retention decisions and the incident process. An independent assessor decides whether the implementation meets each requirement at the target level. DeployOpen can prepare the systems, log forwarding, protection settings and evidence packages, but it does not issue assessment outcomes or maturity ratings. Before you scope a project, list every event source in the ML2 and ML3 requirements, record which ones your platforms already forward centrally, and document the gaps. That list is the most useful input for a fixed-scope quote.
Which events must be centrally logged at ML2
At Maturity Level Two, the Essential Eight expects six families of security events to reach a central store that the organization protects and analyzes. The cards below cover what each family records, what an assessor will ask to see, and where teams most often find gaps during evidence collection.
Application control allowed and blocked events
ISM-1660 requires both allowed and blocked application control events to be sent to a central store. The allowed events show which executables ran on each endpoint, and the blocked events show what the policy stopped. An assessor will compare the blocked events against the approved application list to confirm the policy is enforced rather than only configured. Check that both event types arrive centrally, not only on the local machine where they are generated.
PowerShell module and script block events
ISM-1623 and ISM-1889 cover PowerShell module logging, script block logging and transcription events. These records capture what PowerShell commands and scripts did on a system, which matters because PowerShell is a common route for living-off-the-land activity. Confirm that logging is enabled through policy on all in-scope endpoints and that the resulting events are forwarded centrally. Assessors often sample a few hosts and ask for the events from a specific date range.
Command line process creation events
ISM-1889 also requires command line process creation events to be centrally logged. These events record the full command line used to start a process, so an analyst can see the arguments an attacker or administrator supplied, not just the name of the program. Confirm that command line capture is enabled alongside process creation auditing, because the process name alone rarely explains what ran. Check that the central store keeps these events long enough for investigations to be completed.
Privileged access and account management events
ISM-1509 and ISM-1650 require privileged access events, and privileged account and security group management events, to be centrally logged. These show when administrative rights were used, when accounts were created or changed, and when group membership was modified. An assessor will test whether a change to a privileged group produces a traceable record that someone reviewed. Confirm the log sources include domain controllers and the identity platform, since local logs on a single server will not show directory-wide changes.
Successful and unsuccessful MFA events
ISM-1683 requires both successful and unsuccessful multi-factor authentication events to be centrally logged. Successful events show who authenticated and from where, while failed attempts can reveal password spraying, MFA fatigue attempts or a user being targeted. Confirm that the identity provider forwards authentication events for all in-scope services, not only the primary sign-in path. Assessors commonly ask for a sample of failed attempts and the follow-up that was recorded.
Confirming coverage across the six families
Coverage is judged family by family, so a single working source does not satisfy the requirement. Build a simple matrix that lists each event family, the systems that generate it, the forwarding path to the central store, and the person who reviews it. Gaps usually appear where a platform was added after the logging baseline was set. Confirm each family against the current ISM Essential Eight ML2 profile before scoping the assessment, because control wording and numbering are the reference point an assessor uses.
How log protection and timely analysis are tested
An assessor testing this part of the Essential Eight logging requirements asks two questions: can anyone alter or delete the event logs without leaving a trace, and does the organization look at the logs quickly enough to matter? ISM-1815 covers the first question. It requires event logs to be protected from unauthorized modification and deletion. ISM-1906 and ISM-1228 cover the second. They require logs from internet-facing servers, and detected cyber security events, to be analyzed in a timely manner. At ML2 these apply to internet-facing servers. At ML3 the analysis requirement extends to all servers and workstations under ISM-1907 and ISM-0109.
For log protection, the assessor will usually ask who can read, write, and delete the central log store, and whether those rights are granted through named, reviewed roles. Expect requests for the access control list on the log workspace or SIEM, evidence that administrators cannot clear logs without a second party or an audited action, and the retention settings in effect. Ask your team to export these settings and a recent access review rather than describe them from memory. Retention periods are not stated here. Confirm the required period with the current ISM text and your own records policy, and make sure the retention you configure matches what you have written down.
For timely analysis, the assessor looks for proof that alerts and log events are reviewed on a defined cadence, not only that a platform collects them. Useful evidence includes triage tickets with timestamps, alert rules mapped to detected events, and records showing that internet-facing server logs were reviewed in the window your own policy sets. Response times are not stated here either. Confirm the acceptable analysis window with the ISM and your incident response plan before the assessment, because an assessor will measure your records against the figure you documented. Keep the review evidence as a routine output, so the proof exists before anyone asks for it.
What ML3 adds to timely log analysis
At ML2, timely analysis of event logs is required for internet-facing servers and detected cyber security events (ISM-1906, ISM-1228). ML3 extends that analysis to non-internet-facing servers and workstations (ISM-1907, ISM-0109). The change is mostly about reach: every server and every workstation that produces security-relevant events must feed a process that reviews them in a timely way, not only the hosts that sit on the internet edge. Before planning the uplift, confirm which hosts currently forward events to your central store and which do not, because the gap is usually workstations and internal servers that were never onboarded to the logging pipeline.
The ML3 baseline also replaces three ML2 controls with stricter versions: ISM-1691, ISM-1695 and ISM-1873. Read the current ISM OSCAL profiles for the exact wording of each replacement, since the stricter versions govern what your existing logging must do, not merely that it exists. Every ML2 control carries into ML3, so the central logging of application control, PowerShell, command line, privileged access and MFA events built for ML2 is the foundation rather than something to rebuild. Treat the ML2 logging design as the baseline and confirm each of the three replaced controls against it.
The practical question for an ML3 plan is analysis capacity. Ask who reviews alerts from workstation and internal server events, what queries or detections run against them, how quickly a finding is triaged, and whether the volume is manageable at the new scope. Pilot the onboarding on a representative group of workstations and internal servers, measure the event volume and the triage workload, and size the team and tooling from those results. Any cost or effort estimate for this step should come from your own pilot data or from a written proposal, not from a generic figure.
How Microsoft environments capture and analyze these logs
Microsoft publishes Essential Eight guidance for its own platforms, and one part of it pairs Microsoft Defender for Endpoint P2 with Windows event logs captured in Microsoft Sentinel and Microsoft Defender XDR. That combination is the reference Microsoft gives for central logging of allowed and blocked application control events and for timely analysis of server and workstation logs. Organizations on Windows and Microsoft 365 can start from that guidance rather than designing the pipeline from scratch.
- Application control events: Allowed and blocked application control events must be centrally logged at ML2. Microsoft's guidance maps this requirement to Defender for Endpoint and Sentinel, so the events land in a single queryable store.
- Licensing scope: Defender for Endpoint P2 is the licensing tier Microsoft's guidance names. Confirm which licenses your tenant holds before assuming coverage.
- Event capture: Windows event logs must be forwarded to Sentinel. Confirm which channels and event IDs your configuration collects against the control IDs in the Essential Eight profiles.
- Analysis scope: Timely analysis of internet-facing server logs is required at ML2. At ML3 the same analysis extends to non-internet-facing servers and workstations.
- Reference: Read the Microsoft Learn page on Essential Eight application control for the current configuration steps and prerequisites.
Before relying on this path, check the current Microsoft Learn documentation, because product names, licensing tiers and default event collection can change.
Organizations running Linux servers, third-party endpoint tools, network devices or open-source applications do not have a single vendor guide that covers the whole estate. They need a self-hosted central log store and a SIEM that collects the same event categories Microsoft's guidance covers: application control, PowerShell, command line process creation, privileged access, MFA and privileged account management. The architecture must be designed and proven within the organization's own infrastructure, so the evidence sits under its control.
- Event coverage: Map each ML2 and ML3 logging requirement to a source in your estate, including MFA events from the identity provider and privileged access events from directory and jump server systems.
- Central store: Run the log store and SIEM in your own cloud account, data center or air-gapped network, with access controls and retention set to your policy.
- Log protection: Logs must be protected from unauthorized modification and deletion. Design write-once storage or separate administrative rights for the log platform.
- Analysis rules: Build detections for internet-facing server logs at ML2, then extend them to all servers and workstations at ML3.
- Confirmation: Confirm each capability of every open-source component against its own documentation and test it in your environment before you rely on it.
Ask any implementation partner to show, for each control ID, which source feeds the SIEM and which query or alert produces the evidence.
Whichever path an organization takes, an assessor will test the outcome rather than the product choice. The evidence needs to show that the events are generated, collected centrally, protected and reviewed. A screenshot of a dashboard is rarely enough on its own. Assessors typically look for configuration records, sample events traced from source to store, and records of analysis and escalation.
- Configuration records: Keep exported policy and forwarding configurations that show which event sources are enabled.
- Sample traces: Select representative events, such as an application control block or a failed MFA attempt, and trace them from endpoint to central store.
- Protection evidence: Show access rules and immutability or integrity settings on the log store.
- Review records: Keep records of timely analysis, including alert triage and escalation to the CISO.
- Gap register: Document any source not yet forwarded, with an owner and a date.
Use the ASD assessment evidence material for enterprise IT as a checklist, and have an independent assessor confirm the results.
Logging spans several teams, and the split of work determines who owns the evidence. The organization owns the control and its outcome. Platform teams configure sources and the SIEM. Security teams write detections and run triage. An implementation partner can prepare systems and evidence, but it does not issue assessment reports or certifications. Independent assessors do that work.
- Organization: Owns the logging policy, the incident reporting process and the decision to accept any residual gap.
- Platform team: Configures endpoint policies, forwarders, retention and access to the log store.
- Security team: Owns detection content, analysis cadence and escalation to the CISO and ASD where incidents are reported.
- Implementation partner: Can design the pipeline, deploy it inside your infrastructure and prepare evidence, when scoped in writing.
- Independent assessor: Tests the implementation and reports on it.
Confirm these roles in the scope document before work starts, so no requirement is left without an owner.
How incident reporting fits the logging chain
This sequence shows how the logs that ML2 requires become a reported incident. Each step leaves a record that the next step relies on, so an assessor can trace a single event from detection through to the report sent to the CISO and to ASD.
Detect the cyber security event in central logs
The chain starts when a centrally logged event matches a detection rule. At ML2 these events include allowed and blocked application control events, PowerShell and command line events, privileged access events and MFA events. Detection depends on those sources reaching the central log platform intact. The output is an alert or detection record that identifies the event, its source and its timestamp. Confirm that every source named in the requirements is forwarding into the platform before you rely on it for detection.
Analyze the event in a timely manner
An analyst reviews the alert against the logs that surround it, such as logons, process creation and changes to privileged groups. At ML2 this analysis covers event logs from internet-facing servers. At ML3 it extends to non-internet-facing servers and workstations. The output is a triage record that states whether the event is benign, a false positive or a potential cyber security incident, with the reviewer's name and the time of review. Your policy should define what counts as timely for your organization, and you should confirm that expectation with your assessor.
Confirm the event as a cyber security incident
When triage shows that an event is a genuine security concern, the event is escalated and recorded as an incident. The incident record should link the triage record, the affected systems, the accounts involved and the log entries that show what happened. The output is an incident record with an assigned owner and a severity decision made under your own classification scheme. Keep the link to the original log entries intact, because the protection of event logs matters most when an incident is under review.
Enact the incident response plan
Once an incident is confirmed, the incident response plan is enacted (ISM-1819). The response team contains the affected systems, preserves evidence, and works through the steps the plan sets out. The output is a timeline of actions taken, with each action linked to the responsible person and to the evidence it produced. An assessor will look for proof that the plan was used in practice, not only that it exists, so the response timeline is the record you should be able to show.
Report the incident to the CISO
The incident is reported to the Chief Information Security Officer (ISM-0123). The report should summarize what was detected, what was affected, the current containment status and the open questions. The output is a dated internal report with a record of when the CISO received it. Confirm with your own policy which roles must be told and how quickly, since those expectations are set by the organization rather than by the Essential Eight alone.
Report the incident to ASD
The incident is also reported to the Australian Signals Directorate (ISM-0140). The external report should draw on the incident record and the timeline, and it should be sent through the channel and format that ASD currently specifies. The output is a copy of the submitted report and any reference or acknowledgment returned, filed with the incident record. The reporting obligations, the reporting channels and any applicable timeframes should be confirmed directly with ASD and checked against your organization's own policy before an incident occurs.
Close the loop with lessons learned
After containment, the team reviews the incident against the logging chain. The review asks whether the right events were captured, whether they were analyzed in time, and whether the incident record and report were complete. The output is a short post-incident review with specific changes, such as new detection rules, log source fixes or updates to the response plan. Recording these changes gives an assessor evidence that the logging chain is improved through use, and it feeds back into the detection step.
Questions buyers ask about Essential Eight logging
Can we build Essential Eight ML2 logging in-house?
Yes, if your team has the skills and capacity to build and run it, and many organizations do. ML2 asks you to centrally log events for application control, PowerShell, command line process creation, privileged access, and MFA, protect those logs from modification and deletion, and analyze logs from internet-facing servers in a timely manner. Your engineers can configure Windows event collection, forwarding and retention, then decide on a SIEM. The hard part is usually not the first build but keeping the rules, parsers and alert handling current. Before committing, check whether your team can own the work after go-live, because the ASD assessment looks at whether the logging operates over time, not only whether it was switched on.
What drives the effort of an Essential Eight logging uplift?
Scope drives effort more than any single technology choice. The main factors are the number of endpoints and servers that must forward events, the event volume each one generates, how much of your estate already sends logs somewhere, and whether you already run a SIEM that can take the new sources. Event volume matters because PowerShell script block logging and command line auditing can produce large amounts of data, which affects storage, licensing and tuning. Ask any provider to break its estimate down by source type, log retention period and alerting work, and to state which of these assumptions it has made about your existing tooling.
How long does an Essential Eight logging uplift take?
The duration depends on scope, so treat any single timeline with caution until you have a written scope. A uplift that covers one domain controller group and a few privileged accounts is very different from one that covers every workstation, every internet-facing server and several SIEM integrations. Time is also spent on decisions that are not technical, such as who reviews alerts and where logs are stored. Ask for a plan with separate phases for design, pilot, rollout to each source group, and a period where logs are reviewed before the assessor arrives. A plan that skips the review period is a warning sign.
What evidence does an assessor expect for Essential Eight logging?
An assessor usually expects to see that the required events are collected centrally, that the logs cannot be altered or deleted by ordinary administrators, and that someone analyzes them. In practice this means a list of log sources and the event types each one sends, configuration showing forwarding and retention, access controls on the log store, and records of alert review or incident handling. For ML2 you should also be able to show incident reporting to the CISO and to ASD, with the incident response plan in use. The exact tests are set by the ASD assessment guidance and by your assessor, so confirm the evidence list with them early.
Must all systems send logs to a central location at ML2?
At ML2 the central logging requirement covers specific event types, not every system and every log line. The required events include application control allow and block events, PowerShell and command line events, privileged access events, and MFA successes and failures. The stronger analysis requirement at ML2 applies to internet-facing servers, while ML3 extends timely analysis to non-internet-facing servers and workstations. Your scope should be written down as a list of systems and event types, and you should confirm the exact wording against the ISM Essential Eight baseline for your target level before you finalize it.
What does DeployOpen do for Essential Eight logging, and what stays with us?
DeployOpen plans, implements and documents self-hosted open-source logging platforms inside your own infrastructure, including collection, forwarding, storage protection, retention settings and the evidence pack that shows how they work. Your organization owns the controls, the risk decisions, the alert handling and the incident process. An independent assessor is the party that tests the controls and issues any assessment outcome. DeployOpen does not issue audit reports or certifications. Scope is agreed in writing before work starts, and ongoing support can be arranged as a retainer if you want help keeping rules and sources current.
Do we need a SIEM before we can meet the logging requirements?
Not necessarily, but you need a place to collect, protect and analyze the events. A SIEM is the most common choice because it combines collection, correlation and alerting, but an open-source log pipeline with a separate analysis tool can also meet the requirements if it protects the logs and supports timely review. Microsoft's guidance for application control logging uses Defender for Endpoint P2 with Windows event logs captured in Microsoft Sentinel and Microsoft Defender XDR, which is one reference point if you are a Microsoft shop. Confirm the features of any product against its own documentation, because capabilities vary by edition.
How to check logging is ready before an assessment
Logging evidence is only as good as the path it takes from a sensor to a report. The checks below test whether central logging, log protection, review, incident reporting and traceability actually work together before an assessor asks to see them. Each check produces a specific artifact you can hand over.
Each required event family is centrally stored
Start with the event families the ML2 baseline names: application control allow and block events, PowerShell module, script block and transcription events, command line process creation, privileged access and account management events, and successful and unsuccessful MFA events. For each family, pick a sample host, trigger a benign event, and confirm it appears in the central store with the original timestamp and host name. Keep the query and the result as evidence.
Log stores resist tampering
The ML2 baseline requires event logs to be protected from unauthorized modification and deletion. Check who holds write, delete and retention-change rights on the central store, confirm those rights sit with a small administrative group separate from the people whose activity is being logged, and confirm that changes to retention or access are themselves logged. Export the access control list and a sample of the change log for the assessor.
Alerting and review have a named owner
Logs that nobody reviews do not satisfy timely analysis. Confirm that internet-facing server logs and detected cyber security events have a documented triage owner, a review cadence and a route into the incident process. At ML3 the same expectation extends to non-internet-facing servers and workstations. Evidence includes the rule set, the on-call roster and tickets showing alerts were acted on or closed with a reason.
Incident response plan names the reporting path
The incident response plan should name the CISO as the internal recipient of incidents and set out how and when reports reach ASD. Check that the plan names the people and roles responsible, not just the functions, and that contact details are current. Run a tabletop exercise that starts from a logged event and follows it through to the reporting step, then keep the exercise notes and the updated plan version.
Trace one event end to end
Pick one event, such as a blocked application control event on a workstation, and follow it from the endpoint through collection, storage, alert or review, and into any ticket or incident record. The trace shows whether time sources match, whether host identifiers survive the pipeline, and whether the record is complete. Keep the trace as a single document an assessor can read in one sitting.
Who owns the logging controls and who judges them
The organization owns its logging controls, and the logs themselves are its records. The Essential Eight is a set of mitigation strategies, not a certification scheme, so there is no ASD certificate to buy and no certificate that a vendor or consultant can issue. Maturity is judged by assessing whether each strategy is implemented and effective against the maturity model. For logging, that means the organization must be able to show which events are forwarded to its central store, who can read and change that store, who reviews the alerts, and how incidents reach the CISO and ASD. Those decisions and accountabilities sit with the organization's own leadership and security team, whatever help it brings in.
An implementation partner such as DeployOpen can configure the collection path, set the forwarding policies, protect the log store, build the analysis rules and assemble the evidence. Typical evidence includes forwarding configuration for PowerShell module, script block and transcription events, command line process creation events, application control allow and block events, and MFA and privileged access events, along with samples of analyst review and incident records. The partner prepares that material and documents it, but it does not decide whether the organization meets ML2. Ask any provider to confirm in writing that its deliverables are systems, configurations and evidence packs, and that it will not state a maturity result.
Only an independent assessor or auditor reaches a conclusion on maturity. Before engaging one, confirm with the assessor how it will test log protection, timely analysis of internet-facing server logs, and incident reporting, and which sample of events and time periods it expects to see. Your internal audit or risk function may run a readiness review in advance, but that review is a planning check, not an assessment. Plan for the assessor's conclusion to be the only one that counts in a government or regulatory submission, and budget your engagements on that basis.
How DeployOpen scopes Essential Eight logging work
DeployOpen is a Chainscore Labs company that plans, implements and documents self-hosted open-source platforms inside your own infrastructure. For Essential Eight logging, we prepare the central logging, log protection and analysis systems and the evidence an assessor will ask to see, while your organization keeps ownership of its controls.
How we scope
- We confirm your target maturity level and which logging events each ISM baseline requires for it.
- We inventory log sources, including application control, PowerShell, command line, privileged access and MFA events.
- We agree a fixed-scope written proposal covering systems, deliverables, responsibilities and timelines before work starts.
How we build
- We deploy and configure a central logging platform inside your cloud account, data center or air-gapped network.
- We set log protection so event records cannot be modified or deleted by ordinary administrators.
- We configure timely analysis of internet-facing server logs and test that detected events reach the right people.
How we hand over
- We document configurations, log source coverage and the incident reporting path to the CISO and ASD.
- We test logging end to end and record the results so your team can reproduce them.
- We hand over evidence packs mapped to ISM control IDs for your independent assessor to review.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- We can review log source coverage when new servers or workstations are added to scope.
- Independent auditors and assessors issue any reports or conclusions; DeployOpen prepares the systems and evidence.
