DORA Board Reporting: Your ICT Risk Dashboard Guide

DORA Article 5 establishes the management body's direct responsibility for ICT risk management. Article 5(2) requires the management body to define, approve, oversee, and take accountability for the implementation of the ICT risk management framework. Article 5(4) goes further: management body members must actively maintain sufficient knowledge and skills to understand and assess ICT risk and its impact on the organisation.

Article 5(2)(i) requires the management body to put in place reporting channels enabling it to be duly informed of major ICT-related incidents and their impact, response, recovery and corrective measures, as well as ICT third-party arrangements and material planned changes. This obligation implies structured, recurring reporting rather than ad hoc briefings; the management body must engage with the information substantively rather than merely acknowledge it.

The practical implication is that ICT risk reporting to boards must be designed for governance decision-making. Boards need to be able to answer: Is our ICT risk within appetite? Are we meeting our resilience obligations under DORA?

Are our critical ICT third parties performing to contractual and regulatory standards? A dashboard built around those questions is what Article 5(2) compliance looks like in practice.

A DORA-compliant board-level ICT risk dashboard is a governance instrument. It translates operational ICT risk data into risk-framed indicators that allow the management body to assess whether the organisation's ICT risk posture sits within the board-approved risk appetite and whether corrective action is required.

The dashboard should be structured around DORA's five ICT risk pillars (governance, protection, detection, response and recovery, and learning and evolving) with a summary risk status for each, supported by a concise set of KRIs. Supporting detail should be available but held back from the default view: boards respond to dashboards, not documents.

Recommended Dashboard Structure

The following KRIs give management bodies the information they need to meet Article 5(2)'s active oversight obligation. Each is risk-framed: it tells the board whether ICT risk is within appetite, rather than telling the IT function what to fix.

Effective board incident reporting focuses on governance accountability rather than technical detail. What the management body needs is risk framing: governance information that allows it to assess resilience posture, regulatory compliance, and risk appetite status.

For each incident included in board reporting, four questions need answers.

1. Classification: Was this a major ICT-related incident under DORA's criteria? If so, what was the client impact, service disruption duration, and affected critical functions?
2. Regulatory status: Were notifications submitted to the competent authority within required timelines? Is the incident under ongoing regulatory scrutiny?
3. Risk appetite: Did this incident push the organisation's ICT risk profile outside its stated appetite threshold, and if so, what remediation is in progress?
4. Systemic implication: Does this indicate a control weakness requiring a board-level response (additional investment, a policy change, or a third-party review)?

Incidents falling below DORA's major classification threshold should still appear in board reporting as an aggregate count. The volume and trend of all ICT incidents is a governance indicator in its own right, even when individual incidents don't reach the reporting threshold.

A DORA-compliant board reporting framework requires a formally approved ICT risk appetite statement; that document is the baseline every KRI is measured against, and its formal approval by the management body constitutes evidence of Article 5(2) compliance.

The ICT risk appetite statement should be approved by the management body (that approval documented as evidence of Article 5 compliance) and should set explicit thresholds for each dashboard indicator. For example:

1. Major ICT incidents: Appetite threshold of no more than [X] major incidents per quarter before escalation to exceptional governance review.
2. MTTR for critical functions: Appetite threshold of recovery within [X] hours, aligned to RTO commitments documented in the ICT Business Continuity Plan.
3. Third-party concentration: Appetite threshold of no more than [X]% of critical function capability dependent on a single ICT provider.

Each KRI in the dashboard should display its current value, its trend, and its position relative to the appetite threshold. Where a KRI is outside appetite, the dashboard should surface the escalation item and link it directly to the required board response.

DORA sets no fixed reporting schedule in Article 5. The following schedule reflects recommended governance practice aligned to Article 5(2) obligations; DORA prescribes no specific reporting frequencies and competent authorities have not published standard cadence expectations. Ad hoc or incident-triggered briefings alone don't satisfy the Article 5(2) oversight obligation.

1. Monthly: ICT risk dashboard to the risk committee or equivalent board subcommittee. Full incident register and KRI trends.
2. Quarterly: Summarised ICT risk dashboard to the full management body, including any risk appetite breaches, regulatory notifications issued, and resilience testing outcomes.
3. Incident-triggered: Immediate escalation to the management body for any major ICT incident under DORA classification, or for any third-party event with material impact on critical functions.
4. Annually: Full ICT risk framework review, updated risk appetite statement approval, and confirmation of management body competency development per Article 5(4).

This schedule reflects minimum governance practice. In active risk committee programmes, monthly engagement tends to surface material issues before the quarterly full-board cycle, improving the quality of board-level discussion when it matters most.