DORA Board Reporting: Metrics, Evidence and a Dashboard

1. Start with the decisions the board needs to make

A board pack can contain every security metric the organisation collects and still fail to answer its most important question: can the business continue serving customers when something goes wrong? A report earns its place in the meeting when it exposes a material uncertainty, explains a trade-off or supports a decision about resources, priorities or risk.

Ask: what changed since the previous meeting? Which customer-facing service could now fail in a way the organisation cannot accept? What decision is required today? Put the answers before the supporting charts. A director should not have to infer an urgent funding decision from a red cell on page thirty.

Under the general ICT risk framework, Article 5 covers management-body responsibility and regular training; Article 6 addresses the risk framework and its review; Article 13(5) requires at least annual reporting by senior ICT staff on specified findings and recommendations. See DORA, Articles 5, 6 and 13.

Those provisions do not prescribe one approved dashboard or a universal monthly board-pack format. Choose a reporting cadence proportionate to exposure and your governance arrangements, with escalation between meetings for urgent matters. Keep statutory reporting, supervisory requests and internal management reporting clearly distinguished. This guide offers a practical design, not a replacement for the entity-specific assessment of applicable obligations. For the wider division of responsibility, read our guide to DORA board responsibilities.

2. Organise the report around services and business impact

Begin with a short list of business services that directors recognise: making a payment, accessing an investment account, settling a transaction or receiving an insurance claim. Map these to the entity’s assessment of critical or important functions. Do not silently substitute a list of applications for the business view. One service may require several applications, staff teams, facilities and external providers.

For each service, identify a business owner and describe the consequence of disruption. Include affected customers or transactions, time-sensitive deadlines, manual workarounds and the point at which backlogs become difficult to clear. Distinguish measured impact from estimates. If customer counts are incomplete, state the uncertainty rather than presenting a precise-looking total.

A useful service row combines exposure and evidence: the main failure scenario, the recovery objective, the most recent relevant test and the remaining weakness. A successful database restoration may offer little assurance about the payment service if identity access, reconciliation and outbound connectivity were excluded from the exercise.

Make changes visible. A new provider, acquisition, product launch or migration may invalidate yesterday’s service map. Mark an assessment as awaiting refresh when a material dependency changes. Otherwise, the pack can remain visually green while its supporting evidence describes an operating model that no longer exists.

Keep detailed technical inventories available through controlled links. The board page should explain consequences and decisions; the evidence layer should let reviewers trace those claims back to the responsible teams.

3. Define each metric before assigning it a colour

A percentage without a denominator is an invitation to misunderstanding. “Recovery tests complete: 90%” could mean nine of ten scheduled exercises, nine of ten business services or nine of ten applications. Those statements describe different things. Write the numerator and denominator next to the metric, and make excluded items visible.

• Purpose: the decision or risk question the metric helps answer.
• Population: the services, systems, providers or people included, plus exclusions.
• Calculation: the exact numerator, denominator, unit and treatment of missing data.
• Accountability: the business owner, data producer and reviewer.
• Timing: observation period, extraction date, review date and next refresh.
• Evidence: the controlled record supporting the result and its version.
• Escalation: the internally agreed threshold and the action a breach triggers.

Separate “not tested”, “test failed” and “evidence unavailable”. Combining them into a single green or amber status hides the work required. Show absolute numbers beside percentages so a small population cannot create false confidence. A change from one overdue action to two is a doubling, but its significance depends on the affected service and severity.

Preserve comparability. If the denominator expands after an acquisition, show both the new population and the reason for the discontinuity. Do not interpret a lower completion percentage as worsening execution without checking the scope.

4. Separate recovery objectives from demonstrated performance

The recovery time objective, or RTO, describes the target time to restore a service or capability after disruption. The recovery point objective, or RPO, describes the acceptable data-loss window expressed in time. Neither is proof of actual recovery. Report the target and the observed result separately, with the scenario, scope and measurement boundaries.

A four-hour RTO does not mean a restore command must finish within four hours while reconciliation happens later. Define when the clock starts and what business acceptance ends it. For the RPO, record the latest usable recovery point and whether transaction reconciliation confirmed completeness. A system can restart promptly with data that is too old or unreliable.

Within the full framework, Article 11(6) covers annual continuity/recovery-plan tests across all functions and substantive-change triggers. Article 24(6) requires annual appropriate testing of all ICT systems and applications supporting critical or important functions, excluding microenterprises. See DORA’s testing provisions. Confirm entity-specific scope before turning these requirements into a calendar.

Delegated Regulation 2024/1774, Article 25, links continuity testing to business-impact and risk assessments and requires deficiencies to be analysed, addressed and reported to the management body. In your pack, connect each failed objective to an accountable remediation item and a retest plan.

Keep threat-led penetration testing, or TLPT, separate. It applies to identified entities, not universally; selection criteria and testing requirements are detailed in Delegated Regulation 2025/1190, alongside DORA Articles 26–27. A tabletop, vulnerability scan or ordinary penetration test should not be labelled TLPT. Report the type of evidence each exercise actually provides.

5. Show supplier concentration through service dependencies

A provider count does not reveal concentration. Three suppliers can rely on the same cloud region, identity platform or telecommunications route. For each important service, ask which dependencies could fail together and whether the proposed alternative is operationally independent. Distinguish contractual alternatives from alternatives that have been configured, staffed and exercised.

The EBA’s register-of-information guidance explains the register of ICT contractual arrangements and provides reporting resources. Use the register as an input to the board view. A complete register is valuable, but the board still needs an interpretation of what those relationships mean for service continuity.

A concise dependency panel can show the services supported by a provider, the latest assurance evidence, unresolved limitations, the estimated time to exit and the next decision point. Label an exit estimate as an estimate until it has credible supporting work. Include data extraction, migration, skills, contractual restrictions and customer transition rather than only infrastructure replacement.

Ask a decision-focused question: if this provider became unavailable or unsuitable, which service would force us to act first, and what would prevent an orderly transition? Escalate missing information and unresolved dependency ownership explicitly. Our DORA ICT third-party risk guide develops the supplier and contract questions in more detail.

6. Explain incident trends and the age of unresolved exposure

Incident counts need context. A rise may reflect better detection rather than deteriorating resilience. A fall may reflect an incomplete feed. Report the definition used, the observation period, material service impact and whether collection methods changed. Keep internal severity labels separate from regulatory incident classification; a board chart must not silently redefine the reporting process.

Useful views include disruption minutes by service, repeat causes, unsuccessful changes, recovery performance and the age of important corrective actions. For detection or response-time metrics, record consistent start and end events. Averages can hide a single prolonged disruption: show the range or the most material exception where it changes the decision.

Track actions from incidents, tests, audits and supplier reviews in a common decision view while retaining their source. Each item needs an owner, original due date, current due date, affected service, evidence of completion and a reviewer. A ticket marked “done” should not automatically mean the underlying weakness has been removed.

Show extensions and reopened actions. Moving the due date can make an overdue chart improve without changing exposure. Record who authorised the extension, the reason, interim protection and the next review. Prioritise the consequences of the remaining weakness rather than rewarding teams for closing many low-impact tickets.

Finish the panel with a short explanation of the recurring pattern and the proposed intervention. If several incidents expose the same ownership gap, a new dashboard may be less useful than a clear operating decision.

7. Connect learning records to demonstrated judgment

Training completion is useful evidence of participation, but it does not show whether directors can challenge an optimistic recovery claim or make a difficult service-prioritisation decision. Pair learning records with a small number of applied exercises. Ask participants to identify missing evidence, select escalation points and explain the trade-offs in a fictional service disruption.

Report the learning population, assigned content and version, completion dates, assessment approach and follow-up needs. Record changes in role and newly appointed members so the denominator stays accurate. Where someone has relevant prior experience, document how that was considered and which organisation-specific knowledge still needs attention.

A useful learning discussion might identify that participants understand ransomware terminology but cannot explain who can authorise emergency expenditure. The action is then precise: clarify the authority, update the plan and rehearse its use. Avoid presenting an average quiz score as a measure of overall organisational resilience.

For programme design, use our DORA board training requirements guide. For rehearsal, the executive incident-response tabletop guide shows how to turn an interruption into decisions and recorded learning. Keep individual learning records appropriately restricted; the board pack usually needs coverage, gaps and resulting actions rather than every participant’s detailed answers.

8. A fictional board dashboard with actionable exceptions

The following example is entirely fictional. The figures are illustrative and are not industry benchmarks, legal thresholds or findings about any real organisation. Assume a financial entity has identified four services for this reporting view. The September pack uses a 30 September cut-off and identifies evidence owners for follow-up.

In this example, the data-loss target was met but the recovery-time target was missed. Combining both into a single “recovery passed” label would hide the service delay. The coverage row measures services, not the complete system-level testing population; the underlying testing register must retain that separate scope.

The table also avoids claiming that an unknown result is a failed test. Directors can see which uncertainty requires investigation and which demonstrated weakness needs a funded response. Link each row to its controlled evidence and carry the decision into the next pack until its outcome is verified.

9. Turn the report into a repeatable decision process

Use a short decision record beside every material exception. Describe the service affected, the scenario, available evidence and remaining uncertainty. Set out realistic options, their cost or resource implications, management’s recommendation and the consequence of delaying. Identify the authorised decision-maker and the date by which a decision is needed.

Illustrative decision wording: Approve the proposed recovery improvement for the payment service, with the operations director accountable for delivery. Require a retest against the stated objectives by the agreed date. Record the interim measures, remaining exposure and escalation triggers. Return the outcome and evidence to the next relevant committee.

If a risk is accepted temporarily, record the rationale, authority, conditions and expiry of that acceptance. Acceptance is a governance decision; it does not make an unmet legal obligation disappear. A generic minute saying that the board “noted the report” provides little detail about the challenge, alternatives or follow-up.

1. Agree the service population and map it to applicable requirements and internal responsibilities.
2. Select a small starting set of metrics and write their definitions before automating collection.
3. Assign data owners and reviewers, with a cut-off and an explicit treatment of missing evidence.
4. Reconcile one sample metric to its source, then check that the narrative matches the underlying result.
5. Run a rehearsal with a fictional exception and test whether the pack enables a clear decision.
6. Record the decision, communicate the action and verify its effect in subsequent reporting.

Start with a reliable pack that people can challenge. Automate stable definitions later. For a common foundation in executive oversight, DORA Board & Executive Training provides the academy’s eight-module board programme, approximately three hours of guided study. Use it within a broader programme of organisation-specific discussion, practice and follow-up; completion alone does not establish regulatory compliance.