What the Board Owns Under DORA — and How to Evidence It

Boards are used to owning risk in the abstract. DORA is unusually specific about what the management body must do personally, and unusually unhelpful to firms whose evidence consists of a policy document with a signature page.

The Non-Delegable Duties

DORA states that the management body bears ultimate responsibility for managing the financial entity's ICT risk and assigns it a defined set of duties. The ones that generate evidence questions:

Approve, oversee and periodically review the ICT risk management framework. Approval is a point event. Oversight and periodic review are ongoing, and the review must also be triggered by major incidents and by supervisory or testing findings.

Set and approve the digital operational resilience strategy, including the risk tolerance level for ICT risk. The tolerance is a positive statement of how much disruption the entity accepts, per critical or important function — not a generic appetite paragraph.

Approve and review the policy on arrangements regarding the use of ICT services provided by third-party providers, and be informed about arrangements concluded for critical or important functions.

Allocate and periodically review the appropriate budget to fulfil digital operational resilience needs, including relevant training.

Approve and review the internal audit plan covering ICT risk, and the audit findings.

Maintain sufficient knowledge and skills to understand and assess ICT risk and its impact, including through regular specific training commensurate with the ICT risk being managed.

The Evidence Problem

Every one of those duties is discharged in a meeting and recorded — or not — in minutes. The recurring finding is not that boards fail to consider ICT risk. It is that the record does not show it.

Compare two minutes of the same discussion:

*"The Committee received the quarterly ICT risk report and noted its contents."*

*"The Committee reviewed the quarterly ICT risk report. It challenged the four-hour recovery time objective for the payments function on the basis that the most recent restore test achieved six hours, and asked the CIO either to remediate to the stated objective or to bring a revised objective with a rationale to the next meeting. The Committee also asked for the concentration position across the two cloud providers to be quantified."*

The second is not longer because more happened. It is longer because someone wrote down what happened. That difference is the single cheapest improvement available to most boards, and it is worth more than another policy revision.

Setting an ICT Risk Tolerance That Means Something

A tolerance statement is useful when it constrains a decision. "The Group has a low tolerance for ICT disruption" constrains nothing.

A usable tolerance is stated per critical or important function and quantified: maximum tolerable outage duration, maximum tolerable data loss, and the severe-but-plausible scenario set against which those are assessed. It then flows directly into recovery objectives, testing scope and third-party service levels. When a proposed architecture cannot meet the tolerance, the tolerance forces the decision to the board rather than letting it be absorbed silently in delivery.

The UK operational resilience concept of impact tolerance, discussed in the comparison article, is a good model to borrow here even for entities not subject to UK rules.

Board Training

The training obligation is explicit, cheap to satisfy and frequently missed. Annual ICT and cyber risk training for the management body, tailored to the entity's actual risk profile rather than a generic awareness module, with attendance recorded. Where directors have joined mid-year, record their induction coverage.

Training that works tends to be scenario-based: walk the board through a real incident from another institution, ask what decisions they would have faced and what information they would have needed. That surfaces reporting gaps far more effectively than a slide on the threat landscape.

Committee Structure and Information Flow

DORA does not prescribe a committee structure. What matters is that the information reaching the management body supports the specific duties above.

A board ICT risk pack that supports the duties contains: the position against each function's tolerance; open findings from resilience testing by severity and age; major incidents and classification decisions in the period, including non-major decisions of note; the third-party concentration position and any changes to critical or important arrangements; and the status of the framework review cycle.

That is five items. Most packs run to forty pages and contain none of them in a form the board can challenge.

Key Takeaways

• The management body's DORA duties are specific and non-delegable, and most are evidenced in minutes rather than in documents.

• Minutes must record challenge and the resulting action, not receipt of a report.

• ICT risk tolerance should be quantified per critical or important function so that it constrains real decisions.

• The board training obligation is explicit; scenario-based training also exposes information gaps.

• A five-item board pack aligned to the duties beats a forty-page pack aligned to nothing.

Frequently Asked Questions

Can ICT risk oversight be delegated to a risk committee? Committee delegation of the work is normal and appropriate. Ultimate responsibility remains with the management body, which means the board must receive enough from the committee to discharge its own duties — not merely be told the committee is satisfied.

What does "sufficient knowledge and skills" mean in practice? Enough to challenge substantively. Supervisors do not expect directors to be technologists; they expect a director to be able to ask why a recovery objective is achievable and to recognise an unsatisfactory answer. Where the board lacks that, the usual remedies are targeted training, a specialist non-executive, or standing independent advice.

How should the board handle a risk it cannot remediate? Document the acceptance explicitly: the risk, why remediation is not currently proportionate or feasible, the compensating controls, the review date and the accountable executive. An articulated acceptance is defensible; a silent one is not.

About the author

Jonas Mohamed Osman Abdelghafour is a risk and compliance expert advising banks, insurers, payment institutions and asset managers on operational resilience, ICT and third-party risk, financial crime and enterprise governance across EU and UK regimes. He works at the point where digital operational resilience obligations meet the evidence a board and a supervisor actually ask for. See qualifications and services, or get in touch to discuss an engagement.

*This article discusses regulatory frameworks in general terms and is not legal advice. Jurisdictional interpretation should be confirmed with qualified counsel.*