DORA and ICT Incident Management – Is your process ready for when a real cyber-attack happens?

In this blog article Cyberfort security experts look at what happens when a financial services firms incident management framework is tested for real with an actual incident.  They also look at key actions to take when the regulatory clock starts ticking whether your process is ready or not.

Detecting an incident and reporting it on time are two different capabilities. DORA expects both and many financial services firms have invested far more heavily in one than the other.

DORA’s incident management requirements are not, at heart, a reporting exercise. They are a test of whether your organisation can recognise a genuine problem quickly enough, and describe it accurately enough, for a regulator’s clock to be met without guesswork.

That distinction matters because most financial services firms already have monitoring tools, a security operations function and an incident process of some kind. What DORA exposes is whether that process was ever designed to answer regulatory questions under time pressure; severity, impact, cross-border relevance, rather than just internal ones like ‘is this resolved yet’.

So, the practical question for a senior security leader when it comes to Incident Management and DORA is not ‘do we have incident management’. It is ‘can we classify an incident correctly within the first hour, and can we prove with a documented root-cause record that we did, for every major incident, not just the ones that made the board pack’.

Most regulated financial services firms are not starting from a blank canvas when it comes to incident management. Security information and event management platforms, endpoint detection tooling and around-the-clock monitoring are standard across the sector and have been for some time. Anomalous activity detection – the first of DORA’s obligations, is broadly in place, even if it varies in maturity from one firm to the next.

This is the comfortable part of the picture, and it is often where board-level confidence about DORA incident readiness comes from. If asked ‘can we detect an incident’, most CISOs would say yes, and reasonably so.

The comfort stops there, because detecting something and classifying it in DORA’s terms are not the same skill, and the sector’s investment has overwhelmingly gone into the former.

The regulatory clock is more specific than most incident plans assume

It is worth being precise about what that clock actually requires, because the specificity is the point. Once an incident is classified as major, DORA’s technical standards set out a three-stage reporting path: an initial notification within four hours of classification, and no later than twenty-four hours from when the incident was first detected; an intermediate report within seventy-two hours of that initial notification; and a final report within one month. There is no grace period built into any of those windows for a classification process that is still deliberating.

That is the detail an internal incident plan has to be built around, not the general principle that reporting should happen ‘without undue delay’. A four-hour clock that starts at classification, not at detection, makes the speed and consistency of your classification step the single biggest determinant of whether you report on time at all.

Classification and cross-border relevance are where the process breaks

DORA does not simply ask you to notice an incident. It asks you to classify it by severity, impact, and critically, and if it has cross-border relevance, using a standardised methodology that the European Central Bank and national competent authorities expect to see applied consistently, not improvised on the day.

This is where the Incident Management gap actually sits in many financial services firms when it comes to DORA compliance. Classification decisions are frequently made informally, by whoever is on the incident bridge at the time, using judgement rather than a documented methodology. That might produce a reasonable outcome, but it does not produce a defensible one, and it rarely produces a consistent one across incidents six months apart or across different response teams.

Cross-border relevance is a particular blind spot. Many financial services firms operate across more than one jurisdiction. Yet few have a documented, tested method for deciding when an incident in one entity’s systems has implications that another competent authority needs to know about. That decision, made badly or made late, is exactly the kind of gap DORA was written to close.

The four-hour reporting requirement compounds this. That clock does not wait for your classification process to catch up. It starts at the point of classification, and the twenty-four-hour detection ceiling applies regardless. An informal or slow classification step does not buy you time; it simply means you report late, working from judgement, not a stopwatch.

So what does this mean for financial services organisations?

If your organisation can detect incidents well but has never pressure-tested how quickly and consistently it can classify one against DORA’s specific criteria, you have a gap that will not show up until a real incident forces it into the open.

The practical answer is not more detection tooling. It is a documented, rehearsed classification methodology that turns judgement calls into a repeatable process, backed by a root-cause and remediation record that exists for every major incident as a matter of course, not assembled retrospectively when a regulator asks for it.

So where should financial services firms start with building this capability? At Cyberfort we believe there are four key steps organisations should undertake when it comes to building out the reporting capabilities to become DORA compliant. Each step should be built as a sequence, not a single project. Every step depends on the one before it and skipping ahead tends to produce a document that looks complete but has not actually been tested.

How do you know if your Incident Response process is working?

When working with Financial Services firms we often find the below measures and management approaches to incident management and reporting tell you whether the 4-step process outlined above is actually working, not just documented.

Time from detection to classification. This matters because DORA’s four-hour reporting clock only starts once you classify an incident as major, so a slow classification step erodes the time you have to report well. Aim to bring this down to well under an hour for anything touching a critical or important function, not days, and ideally not much more than the time it takes to convene the right people.

Consistency of classification outcomes. If two similar incidents, assessed months apart, produce different severity or cross-border judgements, your methodology is not standardised. It is a matter of who happened to be on the call. Track this by periodically re-testing past incident facts against the current methodology and checking the outcome matches. Aim for full consistency; any drift is a sign the documented method has stopped being the one actually used.

Root-cause analysis completion rate. This is the clearest proof that remediation is a genuine discipline rather than a box-ticking exercise once the pressure is off. Aim for a completed, reviewed root-cause record for every major incident, with none left open beyond the timeframe your own process sets for closing them out.

Reporting timeliness against the regulatory window. This is the most visible metric to a regulator and the hardest to fix retrospectively. Aim for full adherence to the four-hour, seventy-two-hour and one-month deadlines for every major incident and treat any near-miss on timing as a signal to fix the classification step upstream, not the reporting step itself.

Tabletop exercise frequency and findings closure. A methodology that is never rehearsed is a document, not a capability. Aim to run realistic incident classification exercises at least annually, with every material finding from each exercise closed out before the next one runs, otherwise you are simply re-discovering the same gap on a yearly cycle.

These figures are directional good-practice targets, not numeric thresholds DORA itself prescribes. Your own risk appetite, the criticality of the functions involved and the jurisdictions you operate in should all shape exactly where you set the bar. The point is to set it explicitly and measure against it, rather than to hit a specific number for its own sake.

Where you’ll likely need further support

Two areas tend to need outside input when it comes to DORA expectations around incident management and reporting, even in organisations with strong internal security teams.

The first is cross-border classification logic. Working out when an incident in one jurisdiction needs to be flagged to another competent authority is a legal and regulatory judgement as much as a technical one. Getting outside support here means arriving at a workable internal standard your team can apply consistently in the moment; built on expertise that has seen how different national authorities actually interpret the requirement in practice, rather than relying on a legal opinion sought for the first time in the middle of a live incident.

The second is independent rehearsal. An incident classification exercise designed and run by the same team that will use it in a real incident tends to test what that team already believes, rather than what a regulator or an external reviewer would actually probe. Bringing in an outside facilitator, unattached to the existing process, means the gap in your methodology is found before a real incident does with a specific, evidenced list of what to fix, rather than a rehearsal that quietly confirms the plan already in place.

Final thoughts

Detection was never the hard part of DORA’s incident requirements and treating it as though it is, is the most common reason organisations misjudge their own readiness. The hard part is classification, consistency and the discipline to produce a defensible record every time, not just when it is convenient. Start there, test it before a real incident does, and the reporting deadline stops being the thing you are afraid of.