Governance Board Oversight and Accountability

Under DORA, governance of digital operational resilience rests with the management body. That body defines the ICT risk strategy, approves the ICT risk management framework, and keeps it under review. Receiving a report is only the start of that work. Oversight becomes real when a meeting produces a decision, when challenge from members is recorded rather than smoothed away, and when every agreed action has a named owner and is followed until it is finished.

The test is practical. After a serious disruption, an outsider should be able to look at the governance record and see what the board knew, what it decided, what it questioned, and what changed as a result. If the record shows only that resilience was discussed, accountability has no anchor. This guide explains how strategy, reporting, roles, testing and third party oversight fit together as one governance story.

Board oversight under DORA covers the whole resilience picture, not a single system or a single project. It includes the ICT risk management framework, the approach to incident handling, the resilience testing programme, the management of ICT third party risk, and the way information is shared and learned from. Strategy sits at the centre: the management body sets the direction, and the framework is the means by which that direction is put into operation across the entity.

A discussion explores a topic. A decision changes something: it approves a framework, accepts or rejects a risk, allocates resource, sets a direction for a provider relationship, or requires a test to be repeated. Good governance records make that difference visible. Minutes and action logs should show the option considered, the reasoning, any dissent or challenge, and the outcome, in language that still makes sense long after the meeting has ended.

Challenge deserves particular attention. A board that only notes reassurance has not overseen anything. Challenge can be a question about whether a test was realistic, whether a provider assurance was evidenced, or whether a recovery assumption depended on a single person or a single site. Recorded challenge protects the entity as well as the board, because it shows that alternatives were weighed. Silence in the record, by contrast, reads later as if no one thought to ask.

Reporting gives the management body the material it needs to oversee, and roles give it people to hold to account. Reports should connect resilience information to services and customers: which services were affected, how recovery progressed, which findings remain open, and where third party risk has changed. A report that lists activities without linking them to services leaves the board informed in general and blind in particular.

Roles turn that information into responsibility. The management body remains ultimately responsible, while senior managers, risk functions, technology teams and assurance functions each carry defined parts of the work. The distinction matters when something fails. If every role is described as shared, no one can be asked what they owned. Clear roles, with named individuals for key decisions during an incident, let the board trace a failure to a decision point instead of to a vague collective.

Testing is how the board learns whether its framework works when conditions are difficult. Results should reach the management body in a form that supports judgement: what was tested, how severe the scenario was, where recovery fell short, and what will change before the next test. A finding that is noted and then left without an owner or a completion check is not closed. It is merely filed, and filing is not governance.

Third party risk belongs in the same conversation, because many critical services run partly outside the entity. Governance here means understanding which providers support which services, what happens if a provider fails or degrades, and how the entity would respond. Contracts and assurances matter, but the board question is broader: does the entity retain enough understanding and control to act independently if a provider cannot? Oversight that stops at the contract boundary stops short of the service.

When a service fails, accountability is tested by the record and by the response. The management body should be able to show that it had approved a framework, that it had reviewed testing and incident information, and that it acted on findings before the failure. After the event, the same discipline applies: decisions about recovery priorities, customer communication, provider engagement and remediation should be recorded, owned and tracked.