Choosing a SIEM Under DORA Logging Duties

Under DORA, logging stops being purely a security concern and becomes a supervisory one. The regulation expects financial entities to detect, log and reconstruct ICT incidents, which means the SIEM — the system that collects and correlates logs — moves from a tool the security team likes to have to a control a regulator will inspect. That shift changes how the selection should be run, and it exposes a licensing trap that has caught out plenty of firms mid-implementation.

What DORA actually expects of your logging

DORA’s ICT risk management and incident-reporting requirements assume you can answer specific questions after an incident: what happened, when, which systems were affected, and in time to meet tight reporting windows. That implies comprehensive logging of the systems that matter, retention long enough to reconstruct an incident, and the ability to correlate across sources fast enough to classify and report within DORA’s deadlines. A SIEM that ingests only the easy sources, or retains logs too briefly, or cannot correlate quickly, leaves a gap that is a security weakness and now also a compliance one.

The licensing trap

Here is where selections go wrong. The major SIEM platforms — Splunk, Microsoft Sentinel, Elastic and others — price largely on data volume, and DORA’s logging expectations push volume up. Firms select on the proof-of-concept’s cost, then discover that ingesting everything DORA implies multiplies the bill, and respond by logging less — which quietly recreates the compliance gap they bought the tool to close. The trap is a pricing model that penalises exactly the comprehensive logging the regulation wants. The way through is to model the real data volume DORA implies for your estate before choosing, and to evaluate the pricing model at that volume, not at the pilot’s.

Choosing for evidence and cost together

• Model the compliant data volume first. What must you log to satisfy DORA for your critical systems, and what does each platform cost at that volume? This is the number that decides the outcome, not the sticker price.
• Check retention against reconstruction. Can you hold logs long enough, at a cost you can sustain, to reconstruct an incident a supervisor asks about months later?
• Test correlation against the reporting clock. Detection and classification have to be fast enough to meet DORA’s windows; a SIEM that surfaces the incident too slowly fails the real test.
• Weigh ecosystem fit. Sentinel suits Microsoft-centric estates; Splunk and Elastic have their own strengths and cost profiles. Fit with your stack affects both cost and how much you actually get logged.

The SIEM decision under DORA is a compliance-and-cost decision wearing a security badge. Run it on the data volume the regulation actually requires, with someone who can read both the DORA obligation and the pricing model, and the platform choice follows. Run it on the demo, and the licensing bill or the compliance gap catches up with you later.

Who this is for

This reading is for:

• CTOs and security leads selecting or replacing a SIEM under DORA
• Firms whose logging was built for security, not supervisory evidence
• Compliance leads who own the DORA obligation but not the tooling
• Boards facing an unexpectedly large SIEM licensing bill

Sixteen Pillars runs the SIEM selection on the data volume DORA actually requires, not the pilot’s, so you avoid both the compliance gap and the licensing shock. Pricing is published at /pricing/. If this is live for your organisation and you would like an independent reading, the place to start is a conversation.

Sixteen Pillars is a technology governance consultancy based in Cyprus. Engagements run remote across the EU, UK, and Middle East, with on-site time where the engagement requires it.