Originally published in Financial IT
Digital Operational Resilience Act (DORA) conversations rarely start with a regulation PDF.
They start in the middle of the night, when a CISO or Head of ICT Risk scrolls through one more email asking, “Can we just double‑check what really happened in that incident six months ago?” They are not worried about whether they tried to be resilient. They are worried about when regulators, boards, and auditors start asking hard questions.
What makes DORA different
Most large financial institutions already have what looks like the right stack on paper: multiple SIEMs and XDR platforms, observability tooling and data lakes, and a reasonably mature incident management process. On a good day, that is enough to keep the lights on and the regulator mostly satisfied.
DORA quietly changes the question. It pushes you from “Do you have controls, processes, and contracts?” to “Can you prove, quickly and consistently, how your organisation withstands, responds to, recovers from, and learns from disruption across your entire ICT estate and third‑party chain?” That is a very different bar, especially when you already feel close to the limit in terms of people, budget, and political capital.
The major incident with five conflicting stories
Imagine a pan‑European bank that relies on a shared payments platform across several entities. One morning, that platform starts failing in strange ways: timeouts, partial retries, odd latency spikes, and a handful of alerts that hint at malicious activity. Customers notice. So do overseers. This clearly qualifies as a major ICT incident under DORA.
Inside the bank, the story fragments almost immediately. The SOC and cyber defence teams pull SIEM data, endpoint logs, and threat intelligence. IT operations and SRE teams turn to infrastructure metrics, application logs, and cloud dashboards. Operational resilience teams dig into crisis notes, BC/DR plans, and war‑room minutes.
Each group is working hard and each one holds a piece of the truth. What they do not have is a shared story. Instead there are five partial timelines, stitched together in spreadsheets and slides, always at risk of being contradicted by a “new” log file someone finds in cold storage at the worst possible moment.
Structured reporting on top of messy SOC data
On the page, DORA's playbook seems tidy: detect incidents fast, classify them consistently, and report major ICT incidents on time. That fits neatly into policy documents. It breaks in the real world when the evidence lives in half a dozen tools that do not agree on time, context, or identifiers. In a live incident, teams scramble to assemble one defensible timeline while everyone is already reading from partial versions. Tight DORA deadlines for initial alerts and follow ups turn every telemetry gap into a governance problem.
Third‑party risk: accountable for what you cannot fully see
DORA's ICT third party focus strikes where many leaders already feel vulnerable. On paper you have outsourcing frameworks, contract registers, and SLA reports. In practice, you can name your key providers but not always show, with data (namely network flows, logs, metrics, etc.), which critical functions and customer journeys depend on which service and sub-service; or conversely, you won’t be able to use data to update the contract registers. When a provider degrades, supervisors will not stop at the contract. They will ask how the failure propagated through your estate and how your own controls behaved while a supplier you barely see was in trouble.
“Store everything everywhere” meets DORA and flat budgets
For years, the default response to new regulation has been simple: log more and keep it longer. Under DORA, that instinct collides with tight budgets, growing telemetry, and a wider ICT estate. Not all data is equal in a DORA investigation; an authoritative payments log in a critical function is worth more than noisy debugging from a dev cluster. Yet cost pressure drives teams to throttle “non critical” logs, shrink hot windows, and push data into cheap, cold tiers that are painful to search when an incident lands and a supervisor expects a clear, defensible story.
AI expectations on top of brittle telemetry
At the same time, boards and supervisors want to hear how you are using AI in detection, investigation, and reporting, and what data underpins those outputs. In many institutions, the answer is that pilots run on the same fragmented, short lived telemetry that makes manual investigations hard. Coverage across entities and providers is patchy, normalisation uneven, and access to history beyond SIEM hot windows slow and expensive. In that world, AI becomes a confident storyteller built on unreliable sources that you still have to defend.
Why this feels personal for security and risk leaders
On a slide, DORA is another programme, another workstream, another set of deliverables. In real life, it lands much closer to identity and reputation.
DORA makes resilience measurable and reviewable. Your ability to reconstruct incidents, tests, and third‑party failures becomes a board‑visible KPI rather than a technical nice‑to‑have. It surfaces unknown unknowns in hybrid estates where legacy platforms and historical shortcuts are still lurking. It exposes organisational maturity gaps when tests or incidents reveal slow evidence gathering, unclear ownership, or brittle recovery processes. It raises the stakes for every telemetry decision; each dropped dataset, untagged feed, or undocumented dependency is a bet that nobody will ask for that evidence at the worst possible moment.
The fear is rarely “we do not care about resilience.” The fear is, “In the next crisis, policy audit, or supervisory review, will we have the evidence to back the story we are about to tell?”
This is not a “you” problem. It is a telemetry problem.
If any of this feels uncomfortably familiar, you are not alone. Across Europe, CISOs, SOC leads, DORA programme heads, ICT risk owners, observability leaders, and data teams are staring at the same ingredients: fragmented telemetry, fractured stories, rising SIEM and observability costs, third‑party exposure that runs deeper than the contracts imply, and AI expectations sitting on top of brittle, inconsistent data.
You can keep fighting those battles incident by incident and audit by audit. Or you can change the ground you are fighting on by treating telemetry as your evidence layer for DORA, not just “logs for the SIEM.” That shift is about architecture and operating model, not just about buying another tool.
If you want to see what that future looks like, and how to get there without rebuilding your entire stack, our DORA telemetry guide goes much deeper into architectures, scenarios, and practical roadmaps you can use to move from fragmented logs to evidence‑grade resilience.
