Management Body Strategy and Oversight
Strategy and oversight under DORA link board direction to everyday ICT risk work. This guide explains how a management body sets direction, monitors it, and revises it when evidence changes.
The short answer
Strategy under DORA is the management body's statement of direction for ICT risk: what the entity aims to protect, how it will manage risk across its services, and how it will judge whether its arrangements are working. Oversight is the continuing work of checking that direction against reality. Together they form a loop. Strategy without oversight drifts, because no one checks whether practice follows intent. Oversight without strategy wanders, because there is no direction against which to judge reports.
The management body therefore does more than approve a document. It sets priorities among competing demands, such as resilience investment, provider choices and testing effort, and it revisits those priorities when services, threats or incidents change the picture. A strategy that never changes may look stable, but stability can also mean that new evidence has not been allowed to alter old choices.
How does strategy become a working framework?
Strategy becomes operational through the ICT risk management framework, which translates direction into processes for identifying risk, protecting services, detecting problems, responding to incidents and recovering. The framework should make the strategy visible in daily work: risk assessments that reflect the services the board prioritised, testing that focuses on the scenarios the board considers most serious, and incident handling that protects the customers the board identified as most affected by disruption.
Consider an insurer whose claims service depends on a document platform and a payment provider. A strategy that prioritises continuity of claims handling during a major weather event implies specific framework choices: tested manual workarounds, provider contingency arrangements, and communication routes for claimants. If the framework instead treats all systems equally, the strategy has not travelled from the boardroom into operations. Oversight spots that gap by asking whether framework activity matches strategic priorities, not merely whether activity happened.
What does oversight look like over time?
Oversight is a rhythm rather than a single event. It involves receiving information, questioning it, deciding, and then checking that decisions were carried out. Reports should arrive in a form that supports that rhythm: concise, linked to services, and honest about gaps. A report that only celebrates progress makes oversight difficult, because the board cannot judge risk it cannot see. Reports that surface open findings, overdue actions and uncertain recovery assumptions give the board something real to oversee.
The rhythm also needs time for reflection. A board that only reviews resilience during a crisis is overseeing under pressure, when choices are narrow. Regular review in calmer periods allows harder questions: whether a service has become more fragile as it grew, whether a provider concentration has increased, or whether a testing programme has become routine and lost its edge. Oversight in quiet periods is what makes oversight in a crisis possible.
How does the management body prioritise when everything claims urgency?
Prioritisation is one of the most consequential parts of strategy. Every technology team can present a genuine risk, and every provider can argue for attention, but resources and management attention are finite. The management body prioritises by reference to services and customers: which disruptions would harm customers most, which services have the weakest recovery evidence, and which dependencies create the widest exposure if they fail.
That service lens prevents a common distortion, where the loudest technical risk wins regardless of customer impact. A back office reporting tool and a customer payment channel may both carry risks, but their disruption consequences differ sharply. Strategy should make that difference explicit, so that testing, investment and management attention follow customer impact rather than internal familiarity. When priorities are explicit, later decisions can be checked against them, and changes of priority can be explained.
When should strategy change?
Strategy should change when the underlying picture changes. A new service, a new provider dependency, a serious incident, a testing programme that repeatedly finds the same weakness, or a shift in the threat landscape can all justify revisiting direction. Change does not imply that the earlier strategy was wrong. It implies that the entity has learned something, and that learning should be reflected in direction rather than filed as a lesson.
The governance risk is inertia. A strategy approved in calmer conditions can survive long after its assumptions have been overtaken, especially if reports continue to use its language. Oversight counters inertia by asking, at each review, what has changed since the strategy was set and whether the strategy still answers the most serious risks now facing the services. If the answer requires a change of direction, the change should be decided and recorded, not left as an informal understanding.
Does strategy shape behaviour beyond documents?
Strategy shapes behaviour because it signals what the management body values. If the board consistently asks about recovery evidence and open findings, managers learn that those topics matter and prepare accordingly. If the board only asks about delivery dates and cost, resilience becomes an afterthought, however strong the written strategy appears. The questions asked in the boardroom are therefore part of the strategy, not separate from it.
Primary sources on the record
- Regulation (EU) 2022/2554, EUR-Lex text.
- European Insurance and Occupational Pensions Authority, EIOPA home page.
- 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.