Board Responsibility for ICT Risk

Under DORA, responsibility for ICT risk belongs to the management body, and it cannot be handed away by delegation, outsourcing or reassurance. Executives and specialists do the detailed work, and providers may run parts of the technology, but the management body remains answerable for the framework, for its review, and for the judgements made under it. That distinction is the whole point of this guide.

Responsibility in this sense is active. It means approving the framework, understanding the main ICT risks to the services the entity runs, reviewing whether controls and recovery arrangements work, and acting when evidence shows a gap. A board that receives regular reports but never questions an assumption, never revisits a decision, and never checks that actions were completed has information without responsibility. The record should show the difference.

Ultimate responsibility means that the management body is the final point of accountability for ICT risk decisions, even when the work itself is delegated. Delegation is normal and necessary: no board runs a security operation or a recovery exercise directly. What delegation cannot do is transfer the duty to judge. The board must still understand the risks in broad terms, approve the framework that addresses them, and satisfy itself that the framework is followed.

Approval covers the ICT risk management framework and the strategy that sits behind it. That includes how ICT risk is identified and assessed, how incidents are handled, how testing is planned, and how third party risk is managed. Approval is not a signature at the end of a long document. It implies that members have had the chance to understand the main choices, to ask why a particular approach was chosen, and to record any conditions or concerns.

Review is the continuing part. Frameworks age as services change, providers change, threats change and incidents reveal weaknesses. Review therefore looks for evidence that the framework still fits the entity as it is now, not as it was when first approved. Incident reports, test findings, audit results and changes in provider arrangements are all review material. A framework that is approved once and never revisited becomes a historical document, however sound it once was.

Delegation ends where judgement begins. Senior managers can propose, implement and report, but they cannot replace the management body as the approving and reviewing authority. That boundary should be visible in governance documents: who proposes, who decides, who implements, and who checks. Where those roles blur, accountability blurs with them, and a failure can be explained away as someone else's remit.

Providers present a similar boundary. A provider can be responsible for operating a system under contract, but the financial entity remains responsible for the service its customers use. Board responsibility therefore includes understanding provider dependencies at service level, not merely at contract level. If a provider outage would stop a customer service, the board needs to know that before the outage, and to have considered what the entity would do in response.

Evidence of responsibility is found in decisions, questions and completed actions. Minutes that record a challenge to a recovery assumption, a decision to increase testing of a fragile service, or a refusal to accept an untested provider assurance all show responsibility in action. By contrast, a thick pack of technical detail with no decision attached shows activity, not oversight. Quality matters more than volume, and a short, clear record of a hard question is worth more than pages of unexamined metrics.

Follow-up is the other half of the evidence. When the board asks for a remediation, a retest or a provider review, the action should be tracked until there is evidence that it happened. Open actions that roll forward from meeting to meeting without explanation suggest that responsibility is being noted rather than exercised. Closing an action should require evidence, not merely the passage of time or a verbal assurance that work is under way.

A common misunderstanding is that responsibility requires deep technical knowledge from every board member. DORA expects the management body collectively to understand ICT risk and to ensure it has the knowledge and training to oversee it, not that each member becomes a technologist. Members can and should rely on specialists, provided they test what they are told and do not accept conclusions they do not understand.

Another misunderstanding is that responsibility is satisfied by appointing a committee or a senior manager. Committees and managers help the board do its work, but they do not replace it. The management body should still receive the material it needs, make the framework decisions itself, and review outcomes. When a committee does useful detailed work, the board record should show what it adopted, what it questioned, and what it sent back, so that responsibility remains traceable to the body that holds it.