What DORA Means for Your Board: The Obligations That Cannot Be Delegated

Most financial services firms have been implementing DORA since before it came into force in January 2025. Implementation teams have been mapping requirements, updating third-party contracts, designing resilience testing programmes, and producing registers of ICT assets and dependencies. This work is necessary and, in most firms, it has been done by technology and operations functions, below board level.

That is precisely the problem DORA was designed to prevent.

DORA is not an IT regulation that happens to apply to financial services. It is a governance regulation that places specific, enforceable accountability at the management body, the board. The implementation work is genuinely important. But if a board believes that delegating DORA implementation to the technology function constitutes compliance, it has misread the regulation in the way regulators are most likely to find interesting.

DORA's explicit board-level obligations

Article 5 of DORA places the management body at the centre of ICT risk governance. The obligations are specific and are worth reading in terms of what they require from a board, not from the technology function.

1. Approve and own the ICT risk management framework. The board must formally approve the ICT risk management framework, not simply receive a presentation about it. This is a governance decision, not an information briefing. A board that approves a framework it does not understand has not discharged this obligation in any meaningful sense.

2. Ensure adequate budget and resources. DORA requires the management body to ensure that adequate financial resources and staffing are allocated to ICT risk management. This means the board must be able to connect security investment decisions to specific risk exposures, not simply approve a budget line. A board that cannot explain why it is spending what it spends on ICT resilience cannot demonstrate this obligation has been met.

3. Maintain oversight of third-party ICT risk. DORA's third-party risk requirements are among its most operationally complex provisions. The board is required to maintain oversight of the firm's critical ICT third-party dependencies, understand the concentration risks they create, and ensure appropriate contractual and monitoring frameworks are in place. This is not a management function that the board delegates and forgets.

4. Govern the incident management framework. The management body must approve the incident classification and response framework, ensure that material incidents are escalated to board level in a timely manner, and take active decisions, not just receive briefings, when significant incidents occur. Boards that have only ever received retrospective updates are not meeting this standard.

5. Maintain individual accountability. DORA, unlike many earlier regulations, is explicit that individual members of the management body carry personal accountability for ICT risk governance failures. This is not a collective corporate responsibility that diffuses across a structure. Each director should be clear about their specific accountability under the governance framework the board has adopted.

The implementation trap

The typical DORA implementation pattern, technology-led, below board, focused on documentation and controls, is not wrong. It is incomplete. The controls are necessary. But DORA requires those controls to be embedded in a governance structure that the board owns, understands, and can defend to a regulator.

The implementation trap is believing that completing the compliance programme satisfies the regulation. It does not. A firm can have comprehensive ICT risk policies, extensive third-party registers, and a full TLPT programme, and still have a board that cannot articulate its role in governing any of it. That is a DORA governance failure, even if the implementation is complete.

Regulators conducting DORA supervisory reviews will ask boards questions directly. The answers will reveal whether the board governs ICT risk or simply delegates it. These are different things, and experienced supervisors know how to distinguish them.

Three questions every board should be able to answer

The following three questions are not exhaustive, but they are diagnostic. A board that cannot answer them fluently has governance work to do before a regulatory conversation.

What is our current ICT risk appetite, and when did we last review it? The answer should be specific, not "low tolerance for significant incidents" but a defined threshold for acceptable disruption, acceptable recovery time, and acceptable third-party dependency, connected to actual business impact tolerances.

What are our three most significant ICT third-party dependencies, and what would we do if each failed? The answer should demonstrate that the board has visibility of concentration risk, that scenario planning has been done at governance level, and that the board has made active decisions about acceptable dependency rather than simply inheriting it.

If a major ICT incident occurred tomorrow, what decision would require board involvement within the first 24 hours? The answer should reflect a governance framework the board has actually adopted and tested, not a theoretical escalation path that lives in a policy document.

Ali Zeb is an Executive Cyber Security Advisor and former advisory member at the FCA ISCCG and NCSC. He provides DORA board advisory and ICT risk governance support to financial services boards and regulated organisations.