Board Training on ICT Risk
Board training on ICT risk under DORA is about collective understanding, not technical mastery. This guide explains how training helps a management body ask better questions and judge answers.
The short answer
Under DORA, the management body needs sufficient knowledge and skills to understand ICT risk and to oversee the framework that manages it. Training is the means by which that collective understanding is built and maintained. It does not turn board members into technologists. It gives them enough understanding of services, dependencies, threats, testing and provider risk to ask informed questions, to recognise a weak answer, and to judge whether a proposal or a report is credible.
Training is therefore a governance control, not a courtesy. A board that lacks a shared vocabulary for ICT risk will struggle to challenge specialists, and challenge is central to oversight. When members understand what a recovery test can and cannot prove, or what provider assurance does and does not cover, they can focus on the points that matter. Without that understanding, oversight tends to accept reassurance at face value.
What does collective understanding mean?
Collective understanding means that the management body as a group can oversee ICT risk, even if individual members bring different backgrounds. Some members may have technology experience, others may bring risk, audit, business or customer perspectives. Training should build a common foundation across that mix, so that discussions do not depend on a single knowledgeable member while others remain silent.
That foundation includes the entity's own services and dependencies, the main types of ICT risk it faces, how incidents are handled, how testing works, and how provider risk is managed. It also includes the limits of each of those topics: what testing has not covered, what a provider contract cannot promise, and what an incident report cannot yet explain. A board that understands limits is less likely to mistake a partial test for full assurance.
What should training cover?
Useful training starts with the entity itself rather than with abstract technology. Members should understand which services matter most to customers, which providers and systems those services depend on, and where recovery would be hardest. From that service picture, training can introduce threat and incident patterns in plain terms: how a provider failure, a failed change, a cyber incident or a data problem could each disrupt a service, and what recovery would involve in each case.
Training should also cover governance mechanics: how the framework works, what reports mean, how to read test results, and how decisions and follow-up are recorded. A member who understands the framework can ask whether a report answers the framework's own questions. A member who only understands technology in general may admire a technical presentation without noticing that it never addressed the service at risk. Governance literacy is therefore as important as technology literacy.
How can incidents and tests become training?
Incidents and tests are powerful training material because they are concrete. A walkthrough of a recent incident, showing the timeline, the decisions taken, the recovery sequence and the lessons identified, teaches more about resilience than a generic presentation. Members can see where information was missing, where a decision was delayed, and where a dependency surprised the response team. Those details make abstract risks tangible.
Tests can be used in a similar way, provided the board sees realistic results rather than only successes. A test that exposed a recovery weakness, followed by a discussion of what changed, teaches the board how to read future test reports critically. Training that only presents successful outcomes teaches the opposite lesson: that testing confirms resilience rather than probing it. The most instructive training material often comes from the tests that did not go as planned.
How are new members brought up to speed, and how is knowledge kept current?
New members need induction that covers the entity's services, its ICT risk framework, its provider landscape and its recent incident and test history. Induction should happen early enough to matter, because a member who joins during a period of change needs that context to participate in decisions. A brief overview that omits recent failures and open findings gives a new member a misleading picture of the risk they are joining to oversee.
How can the value of training be judged?
The value of training shows in boardroom behaviour, not in attendance records. After effective training, members ask more specific questions, challenge assumptions about recovery and provider assurance, and follow up on actions rather than accepting verbal reassurance. Minutes and decision records should reflect that change, with questions and challenges visible rather than smoothed into general agreement.
Attendance alone is a weak measure, and it connects directly to the pitfall in this cluster. A record that shows members attended a training session, without any change in the questions asked or decisions made, proves presence rather than understanding. A stronger record shows training topics linked to subsequent oversight: a training discussion about provider concentration followed by a board decision to review a provider dependency, for example. That linkage is what turns training from an event into governance.
Primary sources on the record
- Regulation (EU) 2022/2554, EUR-Lex text.
- European Securities and Markets Authority, ESMA home page.
Legal status: Regulation (EU) 2022/2554 in force; applies from 17 January 2025, with technical standards applying on the dates stated in each standard. Application position for this topic: Applies from 17 January 2025. Technical standards apply on their own stated dates.