Open source SIEM for DORA detection and incident management: what the regulation asks
A financial entity in scope of DORA, which has applied since 17 January 2025, must be able to show its competent authority how it detects anomalies and how it records and classifies ICT-related incidents. A self-hosted SIEM supplies the detection, alerting and incident records that this evidence rests on. The classification decisions, reporting decisions and the ICT risk and incident policy remain the entity's own responsibility, and the SIEM does not make them. DORA sets no certification scheme, so no SIEM product or deployment is certified as compliant. Supervisors judge the entity's processes and records as a whole. The regulation's detection requirements sit in Article 10. Article 10(1) requires mechanisms to promptly detect anomalous activities, and Article 10(2) requires multiple layers of control, defined alert thresholds and automatic alerts to the staff who respond. Article 17 requires a defined incident management process that records all ICT-related incidents and significant cyber threats, and it requires root causes to be identified and documented. Delegated Regulation (EU) 2024/1774, Article 23, sets out the detection criteria that trigger incident detection and response. Read these together with your own risk assessment before you configure any rule.
The practical starting point is a mapping exercise. For each detection rule in the SIEM, record which critical service it protects, which threshold triggers an alert, who receives it, and where the resulting incident record is kept. Confirm with your competent authority and internal audit how they expect to sample these records. The incident record should carry the fields needed for classification under Article 17(3), including the priority, severity and criticality of affected services, so that a classification decision can be traced back to the alert that started it. Ask your implementation partner how alert and case fields are named and exported, because classification and reporting workflows downstream will depend on them.
Mapping DORA Articles 10 and 17 to SIEM functions and configuration
This table maps each DORA detection and incident management obligation to the SIEM function that supplies it and the configuration an assessor will expect to see. Read each row as a requirement, the function it needs, and the concrete settings to build and document. The main takeaway is that the SIEM supplies detection and records, while the classification and reporting decisions remain documented entity processes that the SIEM data must support.
| Requirement | What the function must do | How to configure it |
|---|---|---|
| Article 10(1) anomaly detection and testing under Article 25 | Promptly detect anomalous activity, including network performance issues and ICT-related incidents, and keep detection mechanisms tested | Enable network and host telemetry sources, baseline normal activity per critical service, add anomaly rules, and schedule periodic test cases that inject known events and record whether alerts fire |
| Article 10(2) layered controls and alert thresholds | Provide multiple control layers and defined criteria that trigger incident response, with automatic alerts to incident staff | Define correlation rules per layer (endpoint, network, identity, application), set documented thresholds per rule, and route alerts automatically to the on-call incident group with severity tags |
| Article 10(3) monitoring resources | Provide sufficient capacity to monitor user activity, ICT anomalies and cyber-attacks | Size ingest, storage and analyst queues against daily log volume and retention, and document who triages each alert queue and during which hours |
| Article 17(1) and (2) incident recording and root cause | Record all ICT-related incidents and significant cyber threats, and support identification of root causes | Create a case record for every alert that is escalated, link related alerts and log sources to the case, and keep closure notes that state the root cause and corrective action |
| Article 17(3)(a) to (c) early warning indicators and classification fields | Track, log, categorise and classify incidents by priority, severity and criticality of affected services | Add case fields for priority, severity, affected service, criticality rating and Article 18 category, and tag early warning indicators so they can be filtered and reported |
| Article 17(3)(e) and (f) senior management reporting | Report major incidents to senior management and the management body with impact, response and added controls | Schedule a saved report from case data showing open major incidents, impact fields, response timeline and added controls, and confirm who receives it and how often |
| Article 23 of Delegated Regulation (EU) 2024/1774 criteria | Specify anomaly detection and the criteria that trigger incident detection and response | Map each trigger criterion to a named rule or threshold, version the rule set under change control, and keep the mapping as evidence for supervisors |
Which open source platforms fit DORA detection and incident records
DORA asks for detection that works continuously and incident records that can be classified and reported. No single open-source tool covers both, so the practical choice is a small set of components with clear roles. The cards below cover the SIEM core, network detection, storage, and the threat context and triage tools that feed classification.
Wazuh as the agent-based detection core
Wazuh combines an indexer that stores alerts, a server that applies decoders and rules, a dashboard and agents on endpoints. It fits Article 10 detection on hosts and applications, and it can run as a cluster and manage agent configuration remotely. Check that its prebuilt compliance views do not include DORA, so you will need to map DORA Article 10 and 17 requirements to your own rules and dashboards. Confirm agent coverage for your core banking and payment hosts before you commit.
Graylog Open for log routing and alerts
Graylog Open ingests syslog, GELF and Beats inputs, routes events through streams and pipelines, and raises alerts from event definitions. Its index rotation and retention settings govern how long incident evidence stays searchable. Graylog Open is licensed under SSPL-1.0, which is not OSI-approved, so have counsel review it. Correlation and anomaly detection sit in the paid Enterprise and Security editions, so confirm which features your Article 10(2) thresholds need.
Security Onion for network detection
Security Onion bundles Suricata for intrusion detection, Zeek for network analysis, osquery for host telemetry and the Elastic stack for search. It supports the multi-layer detection Article 10(2) expects on network traffic and can surface network performance anomalies. Its Elastic License 2.0 terms and the Elastic stack dependency should be reviewed against your sourcing rules. Confirm sensor placement on critical service segments before you size the deployment.
OpenSearch as the storage layer
Graylog and Wazuh both rely on indexed search backends, and OpenSearch is the common storage layer in these designs. Storage sizing drives how many days of ICT incident records you can keep searchable for supervisors. Graylog's compatibility matrix limits which OpenSearch versions it supports, so confirm that range before you select a version. Plan for index lifecycle policies that keep incident evidence longer than routine logs.
MISP or OpenCTI for threat context
MISP and OpenCTI store threat indicators and campaign context that help analysts decide whether an anomaly is a significant cyber threat under Article 17. Both are open source, and OpenCTI's Enterprise Edition uses a separate license. Use them to enrich alerts with known indicators and to document significant cyber threats in your records. Confirm which sharing communities and data handling rules apply to your jurisdiction before you connect external feeds.
Shuffle for triage and escalation
Shuffle is an AGPL-3.0 automation platform that can enrich alerts, open tickets and route escalations to the staff in charge of incident response. It supports the Article 17(3) roles, responsibilities and internal escalation steps by making them repeatable. Playbooks must be written, tested and recorded as part of your incident process. Confirm the connectors you need for your ticketing and communication systems before you rely on automated notifications.
How alerts become DORA incident records
The incident record is the output of a chain, not a spreadsheet filled in after the fact. Logs from identity providers, endpoints, network sensors and business applications reach the SIEM, where decoders and rules (Wazuh) or streams, pipelines and event definitions (Graylog) turn raw events into alerts. Each alert needs to carry the fields the entity will later use to classify it: affected system or service, source and destination, user or account, time of first and last event, and the rule or threshold that fired. Article 10(2) asks for alert thresholds and criteria that trigger incident response, so the threshold is part of the record, not a footnote. Confirm with your SIEM team which fields are written into each alert and which exist only in the raw log.
Once an alert fires, routing decides whether the record exists at all. Article 10(2) requires automatic alerts to the staff in charge of incident response, so the SIEM notification path (Graylog event notifications to email, Slack or PagerDuty, or Wazuh integrations) must reach a named on-call rota, not a shared mailbox. Triage opens a case in your ticketing or case system, with a unique identifier that links back to the alert and the raw events. Classification then records priority, severity and the criticality of affected services under the Article 18(1) criteria, as Article 17(3)(c) requires. The root cause section is completed after recovery, and Article 17(2) expects it to be documented and tied to a corrective action. Ask your partner to show how a closed case cannot be shut without that field.
*Illustrative example:* a burst of failed logins for one service account from an unfamiliar address is detected by a threshold rule on the authentication logs. The alert reaches the on-call analyst, who confirms the account is in use by a legitimate job and sees a successful login from the same address minutes later. The case is classified as a major incident affecting a customer-facing service, the escalation to senior management is logged, and the root cause (a leaked credential in a build script) is recorded with the corrective action. Whether a given event meets the classification thresholds is a judgment your incident response procedure must set, and the criteria in Delegated Regulation (EU) 2024/1774 should be checked against your own documented process.
Evidence a competent authority asks for and which component produces it
This table maps the evidence a competent authority is likely to request on detection and incident management to the self-hosted component that produces it and what the entity must confirm. Read it as a starting inventory for an evidence pack, not as a list the authority has approved. The main takeaway is that the SIEM supplies raw records, while classification decisions, root cause analysis and Article 25 test results must come from the entity's own processes.
| Evidence item | Source component | What to confirm |
|---|---|---|
| Detection rule inventory and change history | Wazuh server rules and decoders in version control, or Graylog event definitions with audit history | Who approves rule changes, whether changes are versioned, and whether the history can be exported for an assessor |
| Alert threshold definitions | Wazuh rule levels and frequency settings, or Graylog event definition conditions and thresholds | Thresholds map to the criteria the entity defined under Article 10(2) and Delegated Regulation 2024/1774 Article 23 |
| Alert logs and acknowledgement timestamps | Wazuh indexer alert store, or Graylog event and notification history, joined with the ticketing or case tool | Acknowledgement is recorded by the case tool, not the SIEM alone, and clocks are synchronized across all sources |
| Detection test results under Article 25 | Test plans and results from the entity's own testing program, with SIEM alert records as supporting evidence | Which detections were tested, how often, by whom, and whether results are kept with the rule version tested |
| Incident records with classification and root cause | Case management or ticketing system linked to SIEM alert identifiers; SIEM supplies the underlying events | Classification by priority, severity and service criticality is a human decision and must be documented separately |
| Log retention and integrity controls | Graylog index rotation and retention settings, or Wazuh indexer retention and snapshot policies | Retention periods chosen by the entity, whether logs are protected from modification, and how deletion is recorded |
| Access records for the SIEM itself | Wazuh dashboard and API authentication logs, or Graylog user authentication and audit records | Who holds administrator rights, whether access is tied to the identity provider, and whether changes to the SIEM are logged |
What a SIEM alone does not satisfy under DORA
A self-hosted SIEM produces the detections, thresholds and incident records that DORA expects, but the Regulation also assigns decisions, notifications, provider oversight and governance to people and processes. The cards below cover what remains outside the tool and what a finance team should confirm before go-live.
Incident classification and major incident decisions
Article 17(3)(b) requires incidents to be classified by priority, severity and the criticality of affected services under the Article 18(1) criteria. A SIEM can tag an event with a severity, but deciding that an event is a major ICT-related incident is a judgment made by a named role, using documented criteria. Check who holds that decision, how it is recorded when the SIEM and the incident lead disagree, and whether the criteria match the entity's own service map.
Reporting to authorities and timing
Reporting of major incidents to competent authorities follows deadlines set in the delegated regulations and in the entity's own supervisory arrangements. The SIEM can supply timestamps, affected hosts and event counts, but it does not decide what is reportable or when the clock starts. Confirm the reporting deadlines and templates with the entity's legal and compliance team, and agree which SIEM fields feed each report section before an incident happens.
Third-party ICT provider oversight
Chapter V of DORA requires the entity to manage the risk of ICT third-party providers, including any managed SIEM, SOC or hosting provider. Self-hosting keeps log data in your infrastructure, but a partner that installs, tunes or supports the platform still falls under third-party risk management. Confirm contractual terms for access to logs, incident notification by the provider, and exit arrangements, and record each provider in the register of information.
Detection testing and threat-led penetration testing
Article 10 requires that all detection mechanisms are regularly tested under Article 25, and Article 26 governs threat-led penetration testing for in-scope entities. A SIEM with rules that have never been exercised gives no assurance. Plan recurring tests that inject known attack patterns, record which alerts fired and how long triage took, and confirm with your supervisor whether threat-led testing applies to your entity and how its results are documented.
Senior management governance
Article 17(3)(e) requires that at least major incidents are reported to senior management and the management body, including their impact, the response and any additional controls. The SIEM supplies the data, but the management body must approve the framework, understand the risk and receive regular reporting. Define the reporting pack, its frequency and the escalation path, and document which board members have reviewed the ICT risk framework.
Communication plans under Article 17(3)(d)
Article 17(3)(d) requires communication plans for staff, external stakeholders and the media, notification of affected clients, internal escalation including ICT-related customer complaints, and information to counterparts. Alert routing in the SIEM does not write these messages or decide who receives them. Maintain pre-approved templates, contact lists kept outside the affected environment, and a tested path from a SIEM alert to the communications owner.
Questions financial entities ask before hiring a partner
What drives the cost of a self-hosted SIEM for DORA detection?
Cost is driven mostly by the volume and variety of log sources, daily ingest, how long logs are kept, and the detection engineering needed to turn those logs into alerts an incident team can act on. Platform licenses are only one part. Graylog Open is free with no volume limits and community support, while the Graylog pricing page lists Graylog Enterprise from 15,000 US dollars per year and Graylog Security from 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. Wazuh is licensed under GPL version 2. Recurring costs include storage and compute that scale with retention, paid editions if you choose them, and the people who tune rules and review alerts. Ask any partner for a quote that separates one-time onboarding from recurring run costs, and that states the assumed ingest and retention.
How long does a DORA-aligned SIEM implementation take?
Duration depends on the number of log sources, how many systems need custom parsing, whether the platform runs in an air-gapped or segmented network, and how much detection content must be written and tested. No fixed timeline applies to every entity, so treat any single duration as a claim to verify. DeployOpen works on fixed-scope engagements, with scope, deliverables and timelines agreed in writing before work starts. Ask for a scoped plan that lists the log sources in order of priority, the detection use cases mapped to Article 10 alert thresholds, the testing approach for those detections, and the milestones at which the incident classification and reporting workflow is exercised.
What does the financial entity need to provide during a SIEM project?
The work depends on your people and documents as much as on the platform. Name an owner for the SIEM, one for incident response, and one for the ICT risk framework, because Article 17 expects defined roles and responsibilities for different incident types. Provide access to log sources, network diagrams, asset inventories and change windows. Supply the existing incident management, escalation and classification policies so detection thresholds and alert routing match them. Plan time for the staff who will test detections and run tabletop exercises, since Article 10 requires detection mechanisms to be regularly tested in accordance with Article 25. Confirm these commitments in the statement of work before kickoff.
Can our internal team run a Wazuh or OpenSearch SIEM without a partner?
Some entities can, provided they have engineers who understand log pipelines, Linux administration, index lifecycle management and detection engineering, and who can keep up with patching. Wazuh's four components (indexer, server, dashboard and agents) can be deployed through several documented options, but a production DORA setup also needs correct parsing, tested alert thresholds, retention policies and evidence that detections work. Consider a hybrid model in which a partner implements and hardens the platform and documents it, and your team runs it with a retainer for upgrades and testing. Ask any partner to show which runbooks and tests your team will own after go-live.
How are Wazuh and OpenSearch upgrades handled in a regulated SIEM?
Upgrades should follow a written, tested procedure, with a staging environment that mirrors production log sources and detection content. The Wazuh release line is currently 4.14, and Wazuh published 4.14 patch releases on 17 March, 23 April, 1 July, 29 July, 23 September and 14 October 2026, so patching is a recurring task. Graylog deployments need compatibility checks: the compatibility matrix lists which MongoDB and OpenSearch versions work with each Graylog release, and Graylog recommends Data Node over OpenSearch 1.x, which is deprecated since Graylog 7.0. Ask the partner for the upgrade calendar, rollback steps, how detection rules are retested after each upgrade, and who approves changes in the change record.
Does DORA certify a SIEM or the entity's detection setup?
No. DORA sets no certification scheme, and no authority issues a certificate that a SIEM or an entity is DORA compliant. Competent authorities supervise compliance using their powers under Article 50. The only authority-issued attestation the Regulation provides for is the attestation that a threat-led penetration test met the requirements under Article 26(7). A partner can prepare detection logic, incident records, classification workflows and testing evidence for your supervisory file, but independent assessors and your competent authority make the judgment. Be cautious with any vendor or consultant who promises a DORA certificate.
How a DORA-focused SIEM rollout is sequenced
The sequence turns DORA's detection and incident management duties into a working SIEM, with each step producing a record that a regulator-facing file can rely on. Scope comes first so that every later decision traces back to the entity type and services in play.
Scope the entity type and in-scope services
Start by confirming which DORA entity category applies to your organization and which services fall under its ICT risk and incident processes, with compliance and legal staff signing off the boundary. Your DeployOpen team, or your own architects, then map which business services depend on which ICT systems, since those dependencies drive the criticality ratings used later for incident classification. Done means a signed scope statement that names the entity type, the critical services and the systems supporting them, so that detection coverage can be measured against a defined perimeter.
Inventory log sources and critical services
Build an inventory of every log source that supports the in-scope services, including identity providers, network devices, endpoints, cloud control planes, core applications and third-party connections. For each source, record the owner, the log types it produces, whether an agent or syslog can collect it, and how its clock is synchronized. Also flag single points of failure, because Article 10 expects detection to cover them. Done means a reviewed source register that shows coverage gaps and the owner responsible for each gap.
Build and test detection thresholds
Write detection rules for anomalous activity across the critical services, then set the alert thresholds and criteria that will trigger incident response and automatic notification of the staff on call. Use the criteria in Delegated Regulation (EU) 2024/1774 as the reference for what must trigger detection and response, and document the reasoning for each threshold. Test every rule against replayed or simulated events and record the results, since DORA requires detection mechanisms to be regularly tested. Done means a rule catalogue with thresholds, owners, test records and a documented decision on each rule that did not pass.
Wire incident records and escalation
Connect alerts to an incident record workflow in which each ICT-related incident is logged, categorized and classified by priority, severity and the criticality of the affected services. Define who is responsible for each incident type, how major incidents are escalated to senior management and the management body, and how client notifications and communication plans are triggered. Where an orchestration tool such as Shuffle is used, test the handoffs so that alerts reach the right roles without manual relay. Done means a tabletop exercise in which a sample alert moves through detection, logging, classification and escalation, with every step timestamped and assigned.
Run a review cycle and capture evidence
Establish a recurring review in which the SOC examines alert volume, false positives, missed detections, rule test results and root cause findings from closed incidents, and updates thresholds or rules as the service landscape changes. Each review cycle should produce a dated record: the decisions taken, the rules changed, the incidents reviewed and the actions assigned to address recurrence. Keep these records and the SIEM audit logs in retained, access-controlled storage so that a supervisor can trace how detection evolved. Done means the first review minutes are signed off and filed, and the rule change history is reproducible from the SIEM configuration repository.
Scope limits and what to confirm with your regulator
DORA applies to a defined list of financial entities, not to every organization that holds customer money. Article 2(1) covers 20 types of financial entity, from credit institutions and payment institutions to insurers, crypto-asset service providers and securitisation repositories, and Article 2(1)(u) also reaches ICT third-party service providers. Before you scope the SIEM, confirm which of the 20 categories your legal entity falls under, because that decides whether the detection and incident management obligations in Articles 10 and 17 apply to you directly. A group with several licensed entities may need to map logs and incident records separately for each one.
NIS2 can apply alongside DORA, and the overlap changes what your SIEM must prove. Article 1(2) makes DORA a sector-specific Union legal act for the purposes of Article 4 of the NIS2 Directive for financial entities that are identified as essential or important entities under NIS2. Ask counsel whether your entity falls in that group and whether national transposition adds reporting or logging duties on top of DORA. Also check the Commission review due by 17 January 2028 under Article 58(1), which covers the criteria for designating critical ICT third-party providers and the voluntary nature of significant cyber threat notification. Those points could change obligations that your detection design depends on, so keep the SIEM's alert routing and reporting fields configurable.
Confirm the rules with your competent authority and counsel, not with this page. Supervision sits with the national competent authority for your entity type under Article 46, and the ECB supervises credit institutions classified as significant. Ask your authority which thresholds and classification criteria it applies, and confirm the current text of the relevant delegated regulation, including Commission Delegated Regulation (EU) 2024/1774 on detection and incident criteria, with counsel before you write those criteria into alert rules. DORA sets no certification scheme, so ask your auditor which evidence it will sample, and treat any reading of this page as general information rather than legal advice.
How DeployOpen scopes and delivers a DORA-aligned SIEM
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source SIEM platforms inside your own cloud accounts, data centers or air-gapped networks. For DORA detection and incident management, we turn Articles 10 and 17 into a written scope, a tested detection and incident record set, and evidence your compliance team can hand to assessors.
How we scope
- Map which ICT systems, critical services and log sources fall within the detection scope for Articles 10 and 17
- Agree alert thresholds, criteria and escalation roles in writing before any build work starts
- Confirm retention, storage location and incident record fields with your compliance and risk owners
How we build
- Deploy the chosen SIEM platform in your environment, with log inputs, decoders and correlation rules for in-scope sources
- Configure incident categorisation, priority and severity fields that match your classification procedure
- Test each detection mechanism against agreed scenarios and record the results for regular retesting
How we hand over
- Deliver architecture, runbooks, rule inventory, threshold register and incident record procedures as written documentation
- Train the staff who receive automatic alerts and maintain the incident log on the platform
- Provide a control mapping that shows which evidence supports each DORA requirement, for your auditors and supervisors to assess
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work begins
- Ongoing support, platform upgrades and continuous detection testing are available as a retainer
- Confirm with us during scoping how patches, rule updates and retesting will be handled after go-live
