Which DORA logging requirements Graylog helps meet
A financial entity in scope of DORA has to log specified events, protect those logs, detect logging failures and alert on them. Delegated Regulation (EU) 2024/1774 sets those duties, and DORA has applied since 17 January 2025, so the question is no longer whether to comply but which tooling carries the evidence. Graylog covers the technical layer: collection through inputs such as syslog, GELF and Beats, routing through streams and processing pipelines, search and dashboards, event definitions for alerting, and index rotation and retention that deletes the oldest indices.
Graylog does not decide the compliance position. Under Article 12(2), the entity defines which events are logged, how long logs are kept and how they are protected, in line with its ICT risk assessment. The entity also owns the alerting scope for ICT assets supporting critical or important functions, the retention periods, the access model for log data and the evidence a supervisor will ask for. Confirm early whether your inputs and alerting features need an Enterprise or Security license, since Graylog Open is licensed under SSPL-1.0 and is not an OSI-approved license.
DeployOpen plans and implements the Graylog side of this work and prepares the systems, configuration records and evidence that support an assessment. DeployOpen does not issue audit reports, attestations or certifications, and no certification scheme exists for DORA itself. Independent assessors and the national competent authority judge the outcome. Treat the first step as a written scope: list the critical or important functions, the ICT assets behind them and the event categories your risk assessment requires, then check that each can be produced in Graylog before the build starts.
Mapping Article 12 and Article 23 requirements to Graylog capabilities
This table maps each DORA logging and alerting requirement in Delegated Regulation 2024/1774 to the Graylog input, stream, pipeline, index set, event definition or configuration that supports it. Read each row as a design question: the Graylog component shows where the control lives, and the last column shows what your organization must still decide or supply. Rows marked as entity decisions cannot be closed by configuration alone.
| Requirement | Graylog component that supports it | Where the entity must supply the rule |
|---|---|---|
| Article 12(1) event categories: access control and identity management | Inputs from directory, SSO, VPN and privileged access sources routed to a dedicated stream with its own index set | Confirm which identity and access systems are in scope and which event types each must emit |
| Article 12(1) event categories: capacity management, change management and ICT operations | Syslog or Beats inputs from servers, hypervisors and change tooling, separated into streams by source and tagged with pipeline rules | Define the change and capacity events relevant to your ICT assets and the fields each must carry |
| Article 12(1) event categories: network traffic | Syslog or GELF inputs from firewalls, load balancers and network devices into a network stream | Decide which traffic events are logged and at what volume, based on your ICT risk assessment |
| Article 12(2) entity-defined scope and retention | Index set retention set by rotation and deletion settings, with separate index sets for categories that need different periods | Set event scope and retention periods in your ICT risk assessment; Graylog enforces only what you configure |
| Article 12 tamper and deletion protection | Restricted roles on streams and index sets, with retention deletion limited to approved administrators; backend access controls on MongoDB and the Data Node or OpenSearch cluster | Define who may change retention, delete indices or edit pipelines, and record approvals outside Graylog; confirm whether Graylog Open supports the controls you need |
| Article 12 detection of logging failures and Article 23 rule-based alerts on collection gaps | Event definitions that alert when expected sources stop sending, based on message counts or absence conditions in a stream | List each critical or important asset, its expected log volume and the silence window that should trigger an alert; confirm event definition options for your edition |
| Article 12 clock synchronisation | Timestamp handling in inputs and pipelines; monitoring of host time sources through a separate stream or dashboard | Document the reliable time source and the synchronisation check you run on each log-producing system |
| Article 23 prioritised alerts during and outside working hours | Event definition priorities mapped to notification targets such as email, Slack or PagerDuty, as listed on the Graylog Open product page | Set working-hours calendars, on-call routing and escalation paths; Graylog delivers alerts but does not define your rota |
| Article 23 anomaly records with date, time and type | Event records created by event definitions, with timestamp, source and category fields recorded in the event index | Define the anomaly types you track and the fields that record time of occurrence and detection |
| Article 23 protection of anomaly records against tampering and unauthorised access | Restricted access to event and alert streams, with a separate archive destination for closed records | Decide where event records are copied, who can read them and how changes are logged |
| Article 22 secure incident evidence retention | Archived or snapshotted indices stored outside the active cluster, with retention matched to the criticality of affected functions | Set retention and deletion periods against legal retention rules and confirm secure storage with your legal and records teams |
How Graylog inputs, streams and event definitions build the DORA trail
The DORA trail in Graylog starts at the input. Graylog Open ingests logs over inputs such as syslog, GELF and Beats, and each input is a point where you decide which sources are accepted and how they are identified. For the event categories Article 12 of Delegated Regulation (EU) 2024/1774 expects, such as access control and identity management, change management, ICT operations and network traffic, plan one input or collector path per source family and record which systems feed each one. Streams then route messages by rule, so access control events from identity systems can be separated from network traffic and kept in index sets with their own retention. Processing pipelines normalize fields before storage, which matters because the DORA records must show the date and time an anomaly occurred and was detected, and the anomaly type.
Storage is where the retention decision becomes concrete. Graylog stores messages in index sets, and rotation by message count, size or time, together with retention that deletes the oldest indices, sets how long each category stays searchable. Article 12(2) leaves the retention period to your ICT risk assessment, so confirm the period per index set with the risk owner before tuning rotation. Graylog runs as server nodes with MongoDB for configuration and metadata and Graylog Data Node or self-managed OpenSearch for log storage, and the storage backend should be sized for the retention you set. Plan the backend so that tampering with stored records is controlled through roles and access restrictions, since Article 23 requires protection of anomaly records against unauthorised access.
Alerting uses event definitions, which run searches in real time or against historical data and send notifications to PagerDuty, Slack or email. Graylog Open supports this path, but correlation and anomaly detection are not part of it. The Enterprise edition adds a correlation engine and 24/7 support, and the Security edition adds anomaly detection, risk scoring and investigations. Article 23 asks for automated rule-based alerts on gaps in log collection and integrity, prioritised inside and outside working hours, so confirm with your Graylog licence holder which alerting features your chosen edition provides and test a silent-source alert before relying on it. The pricing page lists Enterprise from 15,000 US dollars per year and Security from 18,000 US dollars per year, both subject to a minimum volume, which should be checked against your data volume in the written quote.
Evidence DORA reviews can sample from a Graylog deployment
Article 12(2) of Delegated Regulation (EU) 2024/1774 leaves the entity to define which events are logged, how long logs are kept and how they are protected, so the evidence is the record of those choices. The artifacts below show a reviewer what was decided, how it was configured and whether alerts on the logging pipeline and on anomalies actually fired.
Documented event catalogue
A written list of the event categories the ICT risk assessment selected, mapped to the sources that produce them: access control and identity management, capacity, change management, ICT operations and network traffic. Keep it in version control with the date of each change and the approver. Check that every category named in Article 12 has an owner, a source input and a stream that receives it. Reviewers often sample one category and trace it from the catalogue to a live stream.
Input and stream configuration exports
Exports of inputs, streams and their routing rules, taken on a schedule and stored with the catalogue. They show which sources reach Graylog and which stream each one lands in. Compare the latest export with the previous one so that a removed input or a rerouted stream is visible and attributable to a change request. Store exports outside the Graylog cluster so they survive a rebuild.
Index set retention settings
Exports of index set rotation and retention values, which record how long each category of log is kept. Article 12(2) ties retention to the ICT risk assessment, so each value should trace back to a line in that assessment. Retention deletes the oldest indices, so a changed setting can remove evidence early. Keep a dated history of every change and confirm that retention on the archive or tier matches the stated period.
Event definition and notification records
Exports of event definitions, their conditions and their notification targets, with the change history for each. For Article 23, these records show that rule-based alerts exist for gaps in log collection and data completeness, and that alerts are routed differently during and outside working hours. Each definition should name the owner who receives the alert and the priority assigned to it.
Access control records for log data
Role assignments, stream sharing and permission exports showing who can search, change or delete log data and event definitions. Article 12 requires logs to be protected against tampering and deletion, so reviewers will check that administrators cannot silently alter retention or disable alerts. Record each grant with a requester and approver, and review the list on a fixed cycle. Confirm the identity source used for these accounts, such as LDAP or Active Directory on Graylog Open or OpenID Connect and SAML on Graylog Enterprise.
Time synchronisation documentation
A written statement of the reliable time source used by Graylog servers, Data Nodes and every log-producing host, with the configuration showing how each system is pointed at it. Article 12 requires clock synchronisation, and anomaly records must carry the date and time an event occurred and was detected. Record the drift check results and the alert that fires when a source falls out of sync. Confirm the time source with your own infrastructure team before writing it down.
Configuring Graylog for DORA logging and alert coverage
This sequence turns the ICT risk assessment into a working Graylog setup that collects the required event categories, keeps them protected and retained as defined, and raises alerts when collection or integrity fails. Each step ends with a check you can record as evidence.
Confirm logging scope from the ICT risk assessment
Start by listing the ICT assets that support critical or important functions, using your existing ICT risk assessment. For each asset, record the event categories Article 12 of Delegated Regulation (EU) 2024/1774 names (access control and identity management, capacity, change management, ICT operations and network traffic), the retention period, and who may read the logs. Article 12(2) leaves these choices to you, so the decisions and their rationale should be signed off by the owner of the risk assessment. The output is a scope register that every later step references.
Deploy the multi-node Graylog architecture
Build the production cluster the Graylog multi-node guide describes: three Graylog and MongoDB nodes with MongoDB as a replica set, three Data Nodes on their own cluster, and a load balancer in front of the Graylog nodes. Set is_leader to false on follower Graylog nodes. Use Graylog 7.x and Data Node as the search backend, since OpenSearch 1.x is deprecated. The check is a healthy cluster view in the web interface and a successful test message sent through the load balancer.
Configure inputs and pipelines for each event category
Create one input or input group per source type, such as syslog, GELF or Beats, and route each category into its own stream. Use processing pipelines to normalize fields so that identity, change, capacity, operations and network events can be searched consistently. Confirm that clock synchronization is in place on every source and that the source timestamps reach Graylog as expected. Some inputs need an Enterprise license, so confirm this before design is final. The check is a sample event from each category appearing in its stream with the expected fields.
Set index retention and archive rules
Create index sets for each stream with a rotation strategy and a retention strategy that matches the periods recorded in step one. Graylog's retention deletes the oldest indices, so confirm that the period you set does not drop logs before the risk assessment requires them. Size storage with daily ingest multiplied by retention days and by 120 percent, and give the message journal 3 to 5 times daily ingest on SSDs, as the system architecture guidance advises. Archive or export of longer-term evidence needs its own confirmation of edition and capacity. The check is a written retention table matched to index set settings.
Lock down access to log data
Restrict who can read, search and change log data by assigning roles to a small group of named users. Connect directory accounts through Active Directory or LDAP, or through SSO if your edition supports it, and remove shared local accounts. Restrict administrative actions on inputs, index sets and event definitions to a separate role. Protect the backends, meaning MongoDB and the Data Nodes, so that no one outside the logging team can write to or delete indices directly. The check is an access review export showing each role and its members, reviewed by someone outside the logging team.
Build event definitions for gaps and integrity failures
Create event definitions that alert when a required source stops sending, when message volume falls below the expected baseline, when the journal or buffers approach their limits, and when a stream stops receiving expected event categories. Article 23 expects automated, rule-based alerts for gaps in data sources and log collection. Define two priority levels: one for working hours and one for outside working hours, and route them to different notification channels. Attach each definition to the procedure owner who responds. The check is a list of definitions with their conditions, priorities and recipients.
Test alert paths and record the results
Simulate each failure you configured: stop a test source, send a burst of events beyond the threshold, and trigger a notification to each channel for both priority levels. Confirm that the alert reaches the correct person within the time your procedure states, and that the notification and the event record keep the date and time the event occurred and was detected, as well as its type. Keep the test evidence in protected storage. The check is a test log that shows each alert firing and being acknowledged.
Document the logging and alerting procedure
Write a procedure that covers the scope register, the architecture, input and stream mapping, retention settings, access roles, event definitions, priorities, escalation contacts and the test results. Include how changes to any of these are reviewed and approved, and how logging failures are recorded. Store the procedure under version control and schedule a review tied to the ICT risk assessment cycle. Confirm with your compliance or legal team how the procedure maps to the DORA obligations that apply to your entity type. The check is an approved document with a version history and named owners.
Questions financial entities ask before scoping a DORA logging build
What does a Graylog DORA logging build cost, and what drives it?
The software is not the main cost driver. Graylog Open is free with no volume limits and community support, according to the Graylog pricing page, but DORA alerting on critical functions usually needs features that sit in paid editions, such as the correlation engine, data tiering and prebuilt detection content. 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, licensed on processed data with no per-user or per-device fees. Your quote should separate the licence, the infrastructure you pay your cloud or data center provider for, the professional services and the recurring support. Ask for each line to be shown as one-time or recurring.
How much log storage does a DORA retention period need?
Storage follows your daily ingest, your retention period and your own risk assessment, because Article 12(2) of Delegated Regulation (EU) 2024/1774 leaves the retention period to you. The Graylog system architecture guidance advises sizing as daily ingest times retention days times 120 percent, and giving the message journal 3 to 5 times daily ingest on SSDs. Start by measuring real daily volume from your critical sources for two to four weeks, then multiply by the retention your risk assessment sets. Ask the supplier to show the sizing calculation and the index rotation settings used to enforce retention.
How many log sources affect the cost and timeline?
Every source you onboard adds parsing, testing and alert work, so the source count is one of the biggest effort drivers. Sources include identity systems, core banking applications, cloud control planes, network devices and endpoints. Each needs an input, a stream, a processing pipeline and an agreed event category mapping to the events Article 12 requires. Ask for a source inventory with a priority tier for each source, because critical or important functions come first under Article 23.
How long does a DORA logging implementation take?
Duration depends on the number of sources, the size of the Graylog cluster, the number of event definitions and how quickly your approvers sign off. Single-node proofs of concept are quicker than production builds with three Graylog and MongoDB nodes and three Data Nodes, as the Graylog multi-node guide recommends for medium to large deployments. Procurement, network access, security review and change approvals often take longer than the build itself. Ask the supplier for a milestone plan with named dependencies, and treat any duration that arrives without a written scope as an estimate, not a commitment.
What must our team supply before a DORA logging build starts?
You supply the inputs that a logging design cannot invent. These are the ICT risk assessment that defines which events are logged, how long logs are kept and how they are protected, an event catalogue for access control, change management, ICT operations and network traffic, the list of ICT assets that support critical or important functions, and named approvers for alert priorities during and outside working hours. You also provide access to source systems, network paths, hosting capacity and a documented reliable time source for clock synchronisation. Without these, the scope cannot be fixed in writing.
Can our internal team build and run Graylog for DORA alone?
A capable platform or security team can build and run Graylog internally, provided it has the skills and time. The work spans Linux and container operations, MongoDB and OpenSearch or Data Node administration, log parsing, event definitions, access control and evidence collection. Ask yourself whether you can staff on-call coverage for alerts raised outside working hours, and whether you can keep the deployment patched and upgraded. Many entities split the work, keeping ownership of the risk assessment and alert decisions while a partner handles the build and handover.
Does Graylog alone make us DORA compliant?
No. Graylog is a tool that can help you collect, protect and alert on logs, but DORA compliance depends on your governance, risk management, incident processes, third-party contracts and testing as a whole. DORA sets no certification scheme, and competent authorities supervise compliance, so no tool or service provider can certify you. DeployOpen plans, implements, hardens and documents the logging setup and prepares evidence for compliance assessments, but it does not issue audit reports or attestations. Your independent auditor and supervisor decide what is sufficient.
Choosing between Graylog Open, Enterprise and Security for DORA
Graylog Open is the starting point for most DORA logging designs. It ingests logs over inputs such as syslog, GELF and Beats, routes them through streams and processing pipelines, and provides search and dashboards. Its index model supports rotation by message count, size or time, with retention that deletes the oldest indices. Alerting uses event definitions, which cover the rule-based alerts Article 23 expects for log collection gaps when built carefully. Graylog Open is free with no volume limits and community support, and it is licensed under SSPL-1.0, which is not an OSI-approved open source license.
- Core collection: Inputs, streams and pipelines can capture the event categories your ICT risk assessment defines.
- Retention control: Index rotation and retention cover the storage periods you set, within the capacity you provision.
- Event definitions: Real-time and historical monitoring can drive alerts on silence or missing sources.
- Support model: Support is community based, so response obligations must be covered by your own team or a partner.
Confirm with Graylog and your counsel whether SSPL-1.0 terms fit your procurement and whether community support meets your incident response expectations.
Graylog Enterprise is priced from 15,000 US dollars per year, with a minimum of 10 GB per day or 100 Graylog Compute Units, according to the Graylog pricing page. It is licensed on processed data with no per-user or per-device fees. Enterprise adds a data lake with archive restore, data tiering, a correlation engine and 24/7 support. These features matter when DORA retention periods are long, when logs must move between hot and cold storage, or when alerts depend on correlating events across sources.
- Data tiering: Moves older log data to lower-cost storage while keeping it restorable.
- Archive restore: Brings archived logs back for an incident or examination without rebuilding indices.
- Correlation engine: Links related events across sources for alerts that a single search cannot express.
- 24/7 support: Provides vendor coverage for outages affecting log collection.
For the cost side, the subscription recurs annually and scales with data volume, while your infrastructure and implementation work are separate line items. Ask Graylog how the minimum and compute units map to your daily ingest.
Graylog Security is priced from 18,000 US dollars per year on the same processed data basis, with the same minimum of 10 GB per day or 100 Graylog Compute Units, according to the Graylog pricing page. It is aimed at security operations. It adds SIEM features such as risk scoring, anomaly detection, investigations, compliance packs and prebuilt threat detection content. Anomaly detection is relevant to the Article 23 duty to alert on anomalous activity and to record each anomaly with its type and timing.
- Anomaly detection: Surfaces unusual activity patterns that rule-based event definitions may miss.
- Investigations: Gives analysts a structured workflow to record triage and link evidence.
- Compliance packs: Provides prebuilt content that may reduce rule-writing effort, though it is not a DORA mapping.
- Risk scoring: Helps prioritize alerts during and outside working hours.
Before relying on these features, confirm with Graylog which content packs exist for your version and whether Security requires OpenSearch 2.0 or later in your architecture.
How DeployOpen scopes and delivers DORA logging configuration
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including Graylog. For DORA logging and anomaly alerting, we start from the event categories and retention periods your ICT risk assessment defines, then configure Graylog to collect, protect and alert on them, with a written scope agreed before work begins.
How we scope
- Review your ICT risk assessment and the ICT assets that support critical or important functions, so the logging scope follows your own classification.
- Map required event categories to log sources, including access control, change management, ICT operations and network traffic, and record the gaps.
- Agree in writing the sources, retention periods, alert rules, edition requirements and deliverables, with fixed scope and timelines confirmed before build starts.
How we build
- Deploy Graylog server nodes, MongoDB and Data Node or self-managed OpenSearch in your infrastructure, with index retention and rotation set to your documented periods.
- Configure inputs, streams and processing pipelines, then test that each event category arrives with a correct timestamp from your documented time source.
- Build event definitions for alerts on log collection gaps, integrity gaps and anomalous activity, with priorities for working hours and outside them, then test each alert path.
How we hand over
- Document the event catalog, retention settings, access restrictions on log data and the protection applied to stored and archived records.
- Provide runbooks for triage of logging failures and anomaly alerts, including how each detected event is recorded with its type, occurrence time and detection time.
- Deliver test evidence and configuration exports so your team and auditors can review how the controls operate, without DeployOpen issuing any assessment.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, covering Graylog version changes and updates to event definitions.
- Plan upgrades ahead of changes to the Graylog release line, including the move away from OpenSearch 1.x, so logging keeps working through each change.
- Review alert volumes and retention against your ICT risk assessment at agreed intervals, and update the configuration when your risk assessment changes.
