DORA has been live for over a year, the question for most boards has shifted from “are we ready?” to “can we prove it?” This is the second article in our DORA series, looking at what DORA actually requires, pillar by pillar, and where financial services firms most often find the gap between activity and evidence. In this blog article Cyberfort security experts look at the ICT Risk Management pillar in detail, identifying where many financial services firms have knowledge gaps and provide practical advice on key focus areas to ensure compliance.
Introduction
Most financial services firms believe they have ICT risk under control. They have a security operations centre, a patching cadence, an incident response plan and a long list of technical controls. What many do not have is a documented, board-owned ICT risk management framework that would satisfy a DORA supervisor asking a simple question – ‘show me how the board decided how much ICT risk this organisation is willing to carry, and how you know whether you are within that limit today’.
Under DORA, ICT risk management is not a technology function that reports upwards occasionally, it is a governance obligation that the board owns directly, with the same rigour as credit risk or liquidity risk. If your framework cannot answer that question clearly and with evidence, you have found your starting point, and it is worth understanding exactly why so many otherwise well-run security functions land in the same position.
Operations without governance maturity
Across financial services, the operational side of ICT risk is usually in reasonable shape. Firms run vulnerability management programmes, maintain asset inventories, operate detection and response capability, and can produce evidence of controls when asked. Security teams are not the weak link here.
The weak link is what sits above the operational layer. DORA’s ICT risk management pillar (set out primarily in Articles 5 to 16 of the regulation) asks for something most firms have never had to formalise in this way. A documented risk appetite and tolerance framework, integrated into the wider enterprise risk management system, reviewed annually, and independently validated. Not just referenced in a policy pack but actively used to make and defend decisions.
Why ‘we manage risk well’ is not the same as ‘we can evidence governance’
This is where the ‘so what?’ question usually surfaces. If the operational controls are working, why does the governance layer matter so much?
Because DORA does not ask supervisors, or boards, to take competence on trust. It asks for a defensible chain of evidence:
- A stated risk appetite
- A classification method applied consistently
- Named owners against every material risk
- Deadlines that are tracked rather than aspirational
- Reporting lines that reach the board risk committee in a form the committee can actually act on.
Most firms have fragments of this. Few have it end to end.
From our experience at Cyberfort we know the practical consequence shows up in three recurring patterns.
First, risk appetite exists informally, as a shared understanding among the security leadership team, rather than as a document the board has approved and can be tested against.
Second, ownership of ICT risks is diffused across IT, security and business units, so when an audit or supervisory review asks who owns a specific residual risk, the answer takes too long to arrive or arrives inconsistently depending on who is asked.
Third, independent validation, someone outside the team that built the framework, checking that it actually works, is thin or non-existent, which means the first real test of the framework is a live incident or a supervisory request, rather than a planned review.
None of this means the underlying security work is bad. It means the governance structure has not caught up with the operational maturity sitting underneath it. DORA is the first regulation to test that gap directly, at board level, with consequences attached.
A practical sequence, not a rewrite
The fix is not a wholesale replacement of what already exists. It is a sequence of four moves that turn existing operational capability into something the board can own and a supervisor can test.
If your organisation is unsure of where to start with the risk management pillar of DORA, the key starting point is with a board-approved risk appetite and tolerance statement. This is the single most valuable document you may not yet have in a defensible form. It should state, in terms the board can genuinely debate and sign off on how much ICT disruption, data loss or service degradation the organisation is prepared to tolerate before it becomes unacceptable, and where those thresholds differ by system criticality. Without this, every subsequent step in the framework has nothing to be measured against.
The second step is to formalise the identification, classification and assessment cycle. Most firms already do this informally and continuously through their security operations. The task is to make the cycle explicit, scheduled and consistently applied, so that every material ICT risk is scored against the same criteria and lands in the same register, rather than being assessed differently depending on which team found it.
Third, assign named owners and real deadlines to every risk mitigation action, and track them the same way you would track a regulatory finding. A mitigation with no owner and no date is not a plan, it is an intention, and intentions are exactly what supervisors’ probe first.
The final step is to build the reporting mechanism that carries all of this to the board risk committee on a fixed cadence, and commission an annual independent review of the framework itself. Not the individual controls, but whether the framework as a whole still reflects how the organisation actually operates. This is the step most often skipped, usually because it requires bringing in a perspective from outside the team that built the framework in the first place.
Taken in that order, this sequence does not require a new team or a new toolset. It requires the board to take formal ownership of decisions that, in most firms today, are still being made informally by security leadership on the board’s behalf.
The KPI’s that matter, and why
It should be noted that DORA itself does not prescribe numeric thresholds for any of the measures below. There is no rule stating a specific closure percentage or a specific number of days. The figures given are directional good-practice targets, reflecting what a mature framework should be capable of, not figures lifted from a named regulatory standard. Set your own thresholds against your risk appetite and the criticality of the function in question.
With that caveat in place, a framework is only as strong as the metrics that prove it is working. Under DORA, the board risk committee needs indicators that speak to governance performance, not just technical performance. From our DORA consultancy work we recommend all financial services organisations track these five KPIs, included in the board reporting pack on a monthly basis.
1. Time to detect and classify a material ICT risk
This matters because DORA’s incident reporting timelines only work if a risk is recognised and classified quickly enough to trigger them. A framework that takes days to classify something that happened in minutes cannot support the reporting obligations built on top of it. Good practice is a classification cycle measured in hours for anything touching a critical or important function, not days, and the board should know what your current cycle is, rather than assuming it is fast.
2. Mitigation closure rate against agreed deadlines
This is the clearest signal of whether ownership and deadlines are real or aspirational. A framework with named owners but a low closure rate tells the board that accountability exists on paper but not in practice. Firms with mature frameworks typically track this above nine in ten mitigations closed on or before their agreed deadline, with any slippage escalated automatically rather than quietly rolled over.
3. Risk register coverage against the critical function inventory
DORA expects risk assessment to extend to every ICT system supporting a critical or important function, not just the systems that are easiest to assess. This metric tells the board whether the register is comprehensive or has blind spots. The benchmark to aim for is full coverage including every system in the critical function inventory represented in the risk register with a current assessment date, and any gap treated as a finding in its own right.
4. Outstanding findings from independent validation
This is the metric that proves the framework has actually been tested by someone other than the people who built it. A high or ageing number of open findings suggests the framework looks sound on paper but has not been stress-tested. Good practice is a validation cycle that closes the substantial majority of findings within the same reporting year they were raised, with any finding still open after two review cycles escalated directly to the board.
5. Reporting cadence adherence to the board risk committee
This is the simplest metric and the easiest to let slip. It measures whether ICT risk reporting to the board is happening on the schedule the framework promises, in the form the committee agreed to receive it. The benchmark is straightforward. One hundred per cent adherence to the agreed cadence, because a framework that reports late or inconsistently cannot claim to give the board real-time oversight of risk.
A firm running lower-criticality systems may reasonably set a longer classification window than a firm running payment infrastructure; what matters to a supervisor is that the threshold was a considered board decision, not a default nobody examined.
Where you are likely to need further support
Two areas consistently take longer than firms expect, and both are worth planning for early rather than discovering under deadline pressure.
The first is drafting a genuine risk appetite statement. This sounds straightforward until a board actually sits down to agree numerical or descriptive thresholds for ICT disruption. The conversation is likely to surface disagreements about risk tolerance that have never been made explicit before, and it takes skilled facilitation to turn that into a document the board will actually stand behind. Done well, the outcome is a statement the board genuinely understands and owns, not one it has merely signed.
The second is independent validation. It has to be genuinely independent, not the same team marking its own homework with a different report template, and it has to be done by people who understand both the regulatory expectation and the operational reality well enough to give the board a credible answer, rather than a checklist exercise. Done well, the outcome is a validation the board can rely on when a supervisor asks how it knows the framework works, backed by evidence rather than assurance alone.
If either of those is where your own programme is stalling, this is where bringing in outside perspective tends to move things fastest; because both tasks benefit from someone who has run the exercise before and can shortcut the false starts.
If you take one thing into your next board risk committee meeting, make it this. Ask to see the current ICT risk appetite statement, in writing, with the board’s sign-off date attached. If it does not exist in that form, that is your starting point, and everything else in this article follows from getting that one document right.
Next in the DORA series
A board-approved risk appetite is where governance starts, but it means little if the organisation cannot detect, classify and report an incident against it fast enough to meet the regulator’s clock. That is where we turn next, in Blog 3: DORA and ICT Incident Management.
If you are unsure of where to start, need support to ensure your organisation is compliant with DORA, or for more information about Cyberfort DORA compliance services contact us at [email protected] and speak to one of our compliance experts.
