Graylog for Essential Eight event logging

Essential Eight event logging with Graylog: what it covers at ML2 and ML3

If your organization is working toward Essential Eight Maturity Level 2 or 3, you need central logs of privileged access, MFA, PowerShell and application control events, and those logs must be protected and reviewed on a timely basis. A self-hosted Graylog deployment covers collection, protection, retention and review of those logs, but it does not make you compliant on its own. The Essential Eight is a set of mitigations rather than a certification scheme, so there is no certificate to obtain, and maturity is judged by an independent assessor who examines how each strategy is implemented and whether it works. DeployOpen prepares the logging system, its configuration and the evidence an assessor will ask for. DeployOpen does not assess maturity and does not issue any assessment outcome.

At ML2, the ISM baseline asks for central logging of application control, PowerShell, command line, privileged access and MFA events, protection of event logs, timely analysis of internet-facing server logs, and incident reporting to the CISO and ASD. At ML3, timely analysis extends to non-internet-facing servers and workstations, and the stricter versions of several controls apply. The ISM OSCAL profiles list the control IDs for each level, so the first working step is to map each ID to a named event source, a Graylog input, a stream and an event definition or review task. Confirm the current profile version with ASD before you freeze the mapping, because the controls and their wording change between ISM releases.

Plan the Graylog side around three decisions. First, decide which hosts forward which events, since Windows event channels, PowerShell logging, MFA provider logs and privileged access tools each need their own collection path. Second, decide how logs are protected, which means restricting who can change inputs, streams and index retention, and keeping event logs out of reach of the administrators whose activity they record. Third, decide who reviews alerts and how review is recorded. Ask your assessor which evidence they expect for timely analysis and for the ML3 scope, and confirm the retention period your own policy and the assessor require before you size storage in Graylog.

Which Essential Eight logging controls Graylog helps with

This table maps the Essential Eight logging controls at Maturity Level 2 and 3 to the requirement each one asks for, and to the Graylog capability and configuration that supports it. Read each row as a starting point: Graylog collects, protects and reviews the events, while your team defines which events count and who reviews them. Confirm the exact control wording in the ISM OSCAL catalog before you map evidence to it.

Control and requirement	Graylog capability	Configuration to set up
ISM-1509 and ISM-1650: privileged access and privileged account or group management events logged centrally	Inputs (syslog, GELF, Beats), streams, processing pipelines	Forward domain controller, directory and privileged host logs to dedicated inputs, route them to a stream for privileged activity, and confirm each source sends account and group change events
ISM-1683: successful and unsuccessful MFA events logged centrally	Inputs, streams, event definitions	Collect identity provider and MFA service logs, create a stream for authentication events, and use event definitions to separate successes from failures
ISM-1660 and ISM-1623: PowerShell and command line events logged centrally	Inputs (Beats or syslog from endpoints), pipelines for field extraction	Enable script block and command line auditing on endpoints, then use pipeline rules to parse fields so searches can filter by host, user and command
ISM-1889: application control events logged centrally	Inputs, streams, dashboards	Forward application control block and allow events from endpoint tooling, and build a dashboard view that shows blocked executions by host
ISM-1815: event logs protected from unauthorised modification and deletion	Index retention settings, roles and permissions, index set configuration	Restrict who can change or delete index sets and streams, keep retention to deletion by policy, and confirm that the Graylog backend is not writable by ordinary users
ISM-1906 and ISM-1228: timely analysis of internet-facing server logs and detected cyber security events	Event definitions, notifications, dashboards	Create event definitions for internet-facing server sources, set notifications to the on-call channel, and confirm alert timing matches your review expectations
ISM-1907 and ISM-0109 (ML3): timely analysis extended to non-internet-facing servers and workstations	Event definitions, streams, notifications	Extend the same event definitions to internal server and workstation streams, and tag streams so reviewers can see which sources are covered
ISM-0123, ISM-0140 and ISM-1819: incident reporting to the CISO and ASD, and the incident response plan	Process item: Graylog supports it but does not perform it	Use event notifications and saved searches as evidence inputs to your incident process, while reporting, escalation and plan activation stay in your own procedures

What changes between Maturity Level 2 and Level 3 for logging

Maturity Level 3 keeps every Level 2 logging requirement and adds one major extension: timely analysis of event logs moves from internet-facing servers to non-internet-facing servers and workstations. In the ISM Essential Eight profiles published with ISM v2026.09.4, the ML1 controls are all included in ML2, and all but three ML2 controls are also included in ML3. The three exceptions are ISM-1691, ISM-1695 and ISM-1873, which ML3 replaces with stricter versions. Confirm the replacement wording for each of these in the ISM catalog before you write them into your control matrix, because the Graylog configuration you build for Level 2 has to satisfy the stricter text, not the original.

The practical effect is scale. Once workstations and internal servers are in scope for timely analysis, Graylog receives more log sources, more daily volume and a larger alert workload. That changes three design decisions. Storage sizing has to be recalculated from the actual daily ingest of the wider source set, not the Level 2 estimate. Message journal sizing needs the same review, since a larger ingest rate leaves less room for a slow search backend. Event definitions also need a different shape: a rule that is manageable across a few internet-facing servers can produce noise across hundreds of workstations, so you will need grouping, thresholds and priorities that separate routine authentication failures from events that need a response.

Plan the Level 3 expansion as a scoped change rather than a switch. Ask your assessor which systems they will treat as internet-facing and which as non-internet-facing, then map each workstation group and internal server to a stream with a named review owner and a defined analysis cadence. Confirm the timeliness expectation for each group with the ISM text and your assessor, because the Essential Eight maturity model describes the outcome and the ISM sets the specific controls. Testing one workstation group end to end, including alert delivery and the triage record, before the full rollout will show whether the daily workload is achievable with the staff you have.

Evidence Graylog produces for an assessor and how to keep it

An assessor judges Essential Eight maturity from configuration and operating records, so the evidence below should show what Graylog is set to collect, keep and alert on, and that someone reviewed it. Export each item on a schedule and store it under change control so the record reflects the state at each point in time.

Input and collector configuration exports

Inputs define which sources reach Graylog, such as syslog, GELF and Beats listeners, and collectors on hosts define what Windows and Linux systems send. Export input definitions and collector configuration files on a schedule and compare them with the list of in-scope servers, workstations and identity systems. Check that privileged access, MFA, PowerShell and application control events are present in the exports, not only the sources you remember to onboard. Store the exports in version control so every change has an author and a reason.

Stream and pipeline definitions

Streams and processing pipelines decide which messages are routed where and how fields are parsed. Export both, along with the pipeline rule source, because a parsing change can silently drop the fields an event definition depends on. Confirm that the streams for MFA and privileged access events still match the events you are required to log. Review changes to pipeline rules before they are applied, and keep the approved version alongside the assessment evidence.

Index set retention settings

Index sets record how Graylog rotates and deletes log data. Export each index set's rotation and retention settings, including the retention strategy that removes the oldest indices, and tie them to the retention period your own policy sets. Ask the assessor's expectations for retention before choosing values, because the Essential Eight model does not set a retention number in the material supplied here. Record any change to retention with its approval, since a shorter period after an incident is a common finding.

Event definitions and notification records

Event definitions show which conditions raise alerts for timely analysis of internet-facing server logs and detected security events, and notification records show that someone was told. Export the event definition list with its conditions, priorities and notification targets, then keep a dated record of notifications sent and to whom. Test notifications periodically and record the result. Confirm that alerts cover logging failures as well as security events, so a silent collector is noticed.

Role and access configuration for log data

Protection of event logs depends on who can read, change or delete log data and its configuration. Export user roles, group mappings and stream or index permissions, and record the administrators who can change inputs, retention and event definitions. Review the list on a set schedule and remove access that is no longer needed. Single sign-on and MFA for Graylog administrators should be documented here, as they are part of the access picture an assessor will test.

Triage records kept outside Graylog

An assessor will ask what happened after an alert fired, and the answer should not depend on the logging platform being intact. Keep triage notes, incident tickets and reports to the CISO and the incident response plan in a system separate from Graylog, with timestamps and the analyst who acted. Link each record to the event definition and the log messages it relied on. Sample these records regularly to confirm analysis happened in a timely manner.

Configuring Graylog for ML2 event logging, in order

This sequence takes a Graylog deployment from sizing to a working review path, so that the event types Maturity Level 2 expects are collected, protected, retained and reviewed with a named escalation route.

Size storage and the message journal
Estimate log storage with the formula Graylog documents: daily ingest multiplied by retention days, then multiplied by 120 percent. Give the message journal 3 to 5 times daily ingest on SSDs, as the Graylog system architecture guidance advises. Your team or DeployOpen works through the event sources in scope and their volume, then records the result as a sizing worksheet. Confirm the retention period with your assessor and your own policy before you finish, since the Essential Eight does not set one in the supplied facts. Done means the sizing worksheet is approved and the storage and journal figures are written down.
Choose the deployment shape
Pick packages, Docker Compose or the multi-node layout. The multi-node guide recommends three Graylog nodes and three MongoDB nodes running as a replica set, three Data Nodes on their own cluster, and a load balancer in front, with the is_leader setting set to false on follower Graylog nodes. Confirm that the chosen OpenSearch or Data Node version matches the Graylog compatibility matrix, and that the Graylog version is not on a path that deprecates OpenSearch 1.x. Done means a written architecture diagram and a version table have been reviewed by the security owner.
Configure time synchronization and backups
Set every Graylog node, MongoDB node, Data Node and event source to one trusted time source, because event timestamps underpin the timely analysis ISM-1906 expects. Define backup schedules for MongoDB configuration and Data Node snapshots. The exact time source, backup frequency and retention must be confirmed in your environment with your infrastructure team. Done means a time-drift check passes on all hosts and a restore test of the configuration backup has been recorded.
Set inputs for each required event source
Create inputs for the sources that carry the Maturity Level 2 event types: privileged access and privileged account or security group changes, successful and unsuccessful MFA results, PowerShell and command line activity, application control blocks, and internet-facing server logs. Use Beats, syslog or GELF as your collectors support them, and check which inputs need an Enterprise license before you commit. Done means each source sends events and a sample search shows fields from every source.
Route events into protected streams with pipelines
Use streams to separate event categories, such as authentication, privileged access and endpoint execution, and processing pipelines to normalize fields. Restrict write and edit rights on these streams to the logging administrators so that log data stays protected from unauthorized change, as ISM-1815 requires. Done means each category lands in its own stream and a test event from a non-admin account cannot alter the stream rules.
Configure index rotation and retention
Create index set templates that rotate indices by message count, size or time, and set retention so that the oldest indices are deleted on the schedule you defined in the sizing step. Keep security-relevant streams on index sets that match your retention decision. Done means a test index set shows the rotation and retention settings you chose and the sizing worksheet matches the live configuration.
Build event definitions and set role-based access
Create event definitions for privileged access use, repeated MFA failures, and PowerShell or application control events that match your threat model, and route notifications to your on-call channel by email, Slack or PagerDuty. Assign roles so that analysts can search and review, while only administrators can change streams, pipelines and retention. Done means a test event triggers each definition, the notification arrives, and an analyst account is confirmed unable to change retention.
Document the review and escalation path
Write the review cadence, the named reviewers, and the steps for escalating a confirmed incident to the CISO and to ASD, with the incident response plan referenced. Record who reviews alerts, how triage is logged, and where the evidence is stored. Done means the document is approved by the CISO and a tabletop exercise has walked one alert through to the escalation step.

Which Graylog edition each logging capability needs

Graylog Open is the free edition, licensed under the Server Side Public License version 1 (SSPL-1.0), which is not an OSI-approved open source license. It covers the core log pipeline, so you can build much of the central logging evidence for the Essential Eight without a paid license. The pricing page describes it as free with no volume limits and community support.

Collection inputs: Syslog, GELF and Beats inputs receive events from Windows hosts, Linux servers and applications.
Routing and parsing: Streams and processing pipelines separate privileged access, MFA, PowerShell and application control events.
Search and dashboards: Teams can search and build dashboards for daily review of these event types.
Index retention: Index rotation and retention settings control how long events stay in storage.
Alerting: Event definitions can send notifications to PagerDuty, Slack and email.
Authentication: Active Directory, LDAP and trusted header authentication are available.

Confirm with Graylog that each input and notification type you need is included in Open before you rely on it. Check your license terms against your own distribution and hosting model.

What Graylog does not cover for Essential Eight

Graylog stores and searches the events, but several Essential Eight logging requirements depend on endpoints, identity systems, tooling and processes outside the log platform. Treat each card below as a separate workstream with its own owner, and confirm each one before you claim coverage.

Endpoint logging configuration

Graylog only receives what Windows hosts emit. PowerShell script block and module logging, command line process auditing and application control event logs are switched on in the endpoint configuration, usually through Group Policy or another management tool, and the events must then be forwarded to Graylog by an agent or collector. Check that every server and workstation in scope produces these events, that the collector ships them, and that a test command shows up as a searchable message. Also confirm which event IDs your build produces, since default settings often omit them.

Identity provider MFA logging

Successful and unsuccessful MFA events are generated by the identity provider or VPN and remote access gateway, not by Graylog. Before the logs reach Graylog, confirm that each system that prompts for MFA writes both outcomes, that the timestamp and user fields are present, and that failed attempts are not suppressed by default. A Graylog input does not create missing MFA events, so this check belongs at the source.

The application control tool itself

Graylog can collect application control events, but it does not enforce application control or define its rules. The application control product, its policy mode and its rule set are separate decisions, and the events Graylog receives depend on how that product logs blocked and allowed executions. Confirm which tool your organization uses, that its policy is in enforcement mode for the scope being assessed, and that its event output is forwarded and parsed in Graylog.

Tamper protection beyond access roles

Graylog roles limit who can change searches, streams and retention settings, but they do not on their own make stored events immutable. Protection against unauthorized modification and deletion at ML2 and ML3 may need write-once or immutable storage for the index backend, copies sent to a separate system, and restricted administrator rights on the Graylog servers, MongoDB and Data Node. Ask your vendor and your assessor which of these your deployment can provide and document how each one is verified.

Incident reporting and the response plan

Graylog can alert on events, but reporting incidents to the CISO and to ASD, and enacting the incident response plan, are organizational processes. Define who receives Graylog notifications, how an alert becomes a recorded incident, the timing expected by your own plan, and how the report is made to ASD. Test this path with a tabletop exercise so the alert, the escalation and the record can be shown together.

Backups and the other six strategies

Essential Eight has eight mitigation strategies, and Graylog covers only the logging part of two of them in this topic. Patching applications and operating systems, restricting Microsoft Office macros, hardening user applications, restricting administrative privileges and regular backups need their own evidence. Backups of Graylog configuration, MongoDB and index data are a related but separate control that you should plan and test.

What buyers ask about Essential Eight logging with Graylog

What drives the cost of Essential Eight logging with Graylog?

The main drivers are the number of log sources, daily ingest volume, how long logs must be kept and searchable, the Graylog edition you license, and the endpoint work needed to forward events. Graylog Open is free to download and run, but a production cluster still costs money for infrastructure, MongoDB, the search backend and staff time. Graylog Enterprise starts at 15,000 US dollars per year and Graylog Security at 18,000 US dollars per year, each with a minimum of 10 GB per day or 100 Graylog Compute Units, according to Graylog's pricing page. Licensing is based on processed data, not users or devices. At ML3, the number of workstations in scope often becomes the largest effort driver. Ask any quote to list sources, daily volume, retention, edition and endpoint work separately, so you can see what is one-time and what recurs.

Can our own team implement Essential Eight logging on Graylog without a partner?

Yes, a team with Linux administration, MongoDB and log operations skills can build it alone, provided it plans capacity and high availability before deployment. Graylog's architecture guidance advises sizing storage as daily ingest times retention days times 120 percent, and giving the message journal 3 to 5 times daily ingest on SSDs. For medium to large deployments, Graylog's multi-node guide recommends three Graylog and MongoDB nodes, a MongoDB replica set, three Data Nodes on their own cluster, and a load balancer. Your team also needs to configure endpoint forwarding, event definitions and access restrictions on the logs themselves. Most of the difficulty is in source coverage and change control rather than in the Graylog software.

How long does Essential Eight logging on Graylog take to deliver?

Duration depends on the scope of sources, how many systems need agent or policy changes, and the change windows your organization allows in production. ML2 work concentrates on privileged access, MFA, PowerShell, application control and internet-facing server logs, while ML3 extends timely analysis to non-internet-facing servers and workstations, which usually adds a larger rollout. DeployOpen does not publish timelines. A duration should appear only in a written scope agreed before work starts, with the source list, environments and client dependencies stated. If a proposal gives a duration without listing these items, ask for them before comparing.

What does our organization need to provide during the engagement?

You need to name owners for identity, endpoints, change approval and access to the environment. The identity owner supplies MFA and privileged account event sources, while the endpoint owner approves log forwarding policy for servers, PowerShell and application control on workstations. A change approver must schedule production windows, since enabling audit policy and forwarding can affect performance and operations. Your team also provides access to the cloud accounts, data centers or restricted networks where Graylog runs, and a record of current logging gaps. Without these owners, source onboarding usually stalls, so agree on them in the scope before work begins.

Does Graylog or DeployOpen certify that we meet Essential Eight?

No. The Essential Eight is a set of mitigation strategies, not a certification scheme, and the Australian Signals Directorate does not issue an ASD certificate. Maturity is evidenced through assessment of each strategy's implementation and effectiveness against the Essential Eight Maturity Model. Graylog is software, and DeployOpen configures, documents and hardens the logging platform and prepares evidence such as event sources, retention settings and review records. Independent assessment decides the maturity level. Ask any provider that claims certification to show who issued it.

What should a quote for Graylog Essential Eight logging include?

A quote should follow from a written scope that lists each element separately. Include the log source inventory by type and count, the expected daily ingest volume, the retention and searchable retention periods, the Graylog edition and any licensing minimum, and the Graylog architecture to be built, such as packages or Docker Compose and the Data Node layout. Add the deliverables, such as configured inputs, pipelines, dashboards, event definitions, access restrictions, runbooks and evidence records. State which client dependencies apply, which items are one-time and which are recurring support, and what happens if source counts change. DeployOpen's engagements are fixed-scope, so the agreed scope should define the boundary of the quote.

Which Graylog edition do we need for Essential Eight event logging?

Graylog Open can collect, search and alert on the events the Essential Eight requires, using syslog, GELF and Beats inputs, streams, pipelines, dashboards and event definitions. Some inputs and features need an Enterprise or Security license, so confirm the input types for each source before choosing an edition. Graylog Security adds SIEM features such as investigations, risk scoring and compliance packs, which may help review work at higher maturity levels. Graylog Open is licensed under SSPL-1.0, which is not an OSI-approved open source license, so have your legal team review that license against your procurement policy.

How DeployOpen scopes, builds and documents Essential Eight logging

DeployOpen plans, implements, hardens, documents and supports self-hosted Graylog inside your own infrastructure for Essential Eight event logging. We map each logging requirement to a written scope before any build starts, then hand over the configuration, runbooks and evidence your team needs to run it.

How we scope

Agree in writing which log sources, event types and mitigation strategies the Graylog build covers.
Confirm the target Essential Eight maturity level and the ISM controls mapped to each log source.
Size storage, the message journal and node layout from your daily ingest and retention targets.

How we build

Deploy Graylog server nodes, MongoDB and the search backend in your cloud accounts, data centers or restricted networks.
Configure inputs, streams and processing pipelines for MFA, privileged access, PowerShell and application control events.
Test that event definitions fire on sample privileged and MFA activity, and that log tampering is detectable.

How we hand over

Document the log source inventory, retention settings, index rotation and access restrictions in a form your auditors can sample.
Provide runbooks for event definitions, notifications and incident escalation to your CISO and response plan.
Walk your operations team through monitoring, backups and routine review so the workflow runs without us.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after handover.
Keep the Graylog version, backend compatibility and planned upgrades under documented change control.
Re-verify logging coverage when new log sources, mitigation strategies or maturity targets are added to scope.