The CISO's DORA Dashboard: 12 KPIs That Matter

The Reporting Gap That Supervisors See

DORA Article 5(2) makes the management body personally accountable for the institution's ICT risk management framework. Article 14 requires that this body receive regular reporting on ICT risk — at minimum annually, but in practice at every meeting where ICT risk is on the agenda. The ECB's 2024 cyber resilience stress test across 109 banks revealed that while incident response frameworks generally exist, the quality of board-level reporting on operational resilience varies dramatically.

The problem is not a lack of metrics. Most CISOs track dozens: vulnerability counts, patch latency, phishing click rates, SOC alert volumes. The problem is that these metrics do not map to what DORA requires the management body to understand, decide upon, and be held accountable for.

A CISO presenting 40 operational security metrics to a board is delivering noise. A CISO presenting 12 metrics that map to DORA's five pillars is delivering governance.

The 12 KPIs: Organized by Pillar

Pillar I — ICT Risk Management Framework (Art. 5-16)

KPI 1: ICT Asset Register Coverage (%)

This is the foundation metric. If your asset register is incomplete, everything built on it — BIA, risk assessments, testing programmes, third-party mapping — is unreliable. Art. 8(1) requires that the register be "updated on a regular basis and at least once a year." The calculation must include shadow IT discovery: assets found through cloud console scans or network discovery that do not appear in the register count as gaps.

KPI 2: Risk Assessment Currency (Days Since Last Update)

Art. 6(5) requires "continuous" identification of all sources of ICT risk. While "continuous" does not mean "daily," a risk assessment that has not been updated in over a year is indefensible. The metric should track the last substantive update — not cosmetic edits, but material changes to risk scoring, new risk entries, or reassessments triggered by incidents or environmental changes.

KPI 3: Critical Control Effectiveness Rate (%)

A control that exists on paper but has not been tested is not a control — it is an assumption. This KPI measures the percentage of critical controls (those protecting critical and important functions per Art. 3(22)) that have been tested within the last assessment period and confirmed effective. The EBA's guidelines on ICT risk management emphasize that control effectiveness must be measured, not assumed.

Pillar II — Incident Management (Art. 17-23)

KPI 4: Mean Time to Detect (MTTD) — ICT Incidents

The 4-hour threshold is not arbitrary. Art. 19(4)(a) requires initial notification to the competent authority "without undue delay, but no later than the end of the business day or, where the major ICT-related incident occurred later than 2 hours before the end of the business day, not later than 4 hours from the beginning of the next business day." If detection takes more than 4 hours, the institution cannot meet the initial notification deadline. MTTD directly determines whether you can comply with Art. 19.

KPI 5: Incident Classification Accuracy (%)

Art. 18 establishes specific materiality thresholds for incident classification: number of clients affected, transaction volume, duration, geographic spread, data losses, and economic impact. Misclassification has two failure modes: under-classification (a reportable incident is not reported, triggering regulatory consequences) and over-classification (resources are mobilized unnecessarily, eroding response capacity). Track accuracy through post-incident reviews that compare initial classification against final determination.

KPI 6: Regulatory Reporting Compliance Rate (%)

This is a binary compliance metric with no room for ambiguity. Art. 19 specifies three reporting phases: initial (within timeframes per Art. 19(4)(a)), intermediate (within 72 hours), and final (within 1 month). A missed deadline is a regulatory breach. Green is 100% — there is no acceptable failure rate for regulatory reporting compliance. Amber acknowledges that near-misses on intermediate or final reports may occur during the learning period; red signals a systemic process failure.

Pillar III — Resilience Testing (Art. 24-27)

KPI 7: Testing Programme Completion Rate (%)

Art. 24(1) requires a testing programme "as an integral part of the ICT risk management framework." This KPI measures execution against plan. A programme that is 50% complete at year-end indicates either insufficient resourcing, poor planning, or deprioritization — all of which are examination findings. Include all test types: vulnerability assessments (Art. 25(1)), scenario-based tests, recovery tests, and TLPT if applicable.

KPI 8: Recovery Objective Achievement Rate (%)

This is the metric that the ECB's 2024 stress test specifically targeted. Recovery capabilities that cannot meet stated RTO/RPO targets are not capabilities — they are aspirations. The calculation requires actual measured recovery times from test executions compared against the RTO targets derived from the BIA (Art. 11(1)). A rate below 60% means the institution's continuity plans are materially unreliable and require urgent remediation.

Pillar IV — Third-Party Risk (Art. 28-44)

KPI 9: Third-Party Register Completeness (%)

The Register of Information is the single most auditable DORA artifact. ESMA's guidelines specify the data fields required for each entry. Completeness means every field populated — not just contract value and renewal date, but criticality classification, data processing location, sub-outsourcing status, exit strategy reference, and Art. 30 contractual provision compliance. An incomplete register is the fastest route to an examination finding.

KPI 10: Concentration Risk Index (HHI)

Art. 29 requires assessment of concentration risk from ICT third-party dependencies. The Herfindahl-Hirschman Index (HHI), borrowed from antitrust economics, provides a quantitative measure. Calculate each provider's share of your critical and important ICT services, square each share, and sum. An institution where 70% of critical services depend on a single provider has an HHI of at least 4,900 — extreme concentration. The SecurityScorecard report finding that 15 companies represent 62% of the global tech surface area underscores why this metric matters.

Weight by criticality: a provider hosting 15% of your services but supporting 60% of critical functions represents far greater concentration risk than raw service counts suggest. See our concentration risk analysis for detailed methodology.

Pillar V and Cross-Cutting

KPI 11: Evidence Completeness Score (%)

This is the meta-KPI that predicts examination outcomes. It measures not whether you are compliant, but whether you can demonstrate compliance under examination conditions. Every applicable DORA requirement should have linked evidence: a document, a test record, a log entry, an approval record, or a process artifact. Evidence must be current (within the assessment period) and accessible (retrievable within minutes, not days). See our analysis of evidence management for audit readiness.

KPI 12: Open Remediation Items (Count by Severity)

DORA Art. 13 requires that financial entities "learn and evolve" from ICT incidents and resilience testing. Open remediation items are the tangible measure of this obligation. An institution with 30 open high-severity findings from last year's testing programme and no documented remediation progress has a governance failure, not a technical gap. The metric must show trajectory: is the count increasing (deteriorating) or decreasing (improving)?

The Dashboard Layout

For board presentation, organize the 12 KPIs into a single-page dashboard with four quadrants:

Each KPI should display: current value, trend (3-month directional arrow), RAG status, and the DORA article it maps to. The management body does not need to understand the calculation methodology. They need to understand: what is the status, is it improving or deteriorating, and what action is required if red.

From Dashboard to Decision

A dashboard that informs without driving action is wallpaper. Each red or amber KPI must trigger a documented management body decision:

• Accept the risk (with formal rationale and expiry date — no eternal waivers)
• Allocate resources to remediate (with timeline and accountability)
• Escalate to a risk committee or competent authority (for systemic issues)

Art. 5(2) requires that the management body "approve and oversee" the ICT risk management framework. Approval is not passive receipt of a green dashboard. It is active governance: challenging amber metrics, demanding remediation plans for red metrics, and holding accountable the individuals responsible for improvement.

The 12 KPIs create the data layer. The management body's documented decisions create the governance layer. Together, they demonstrate to supervisors that operational resilience is not a technical backwater but a board-level discipline.

Key Takeaways

• Art. 14 requires annual ICT risk reporting to the management body. Twelve KPIs, mapped to DORA's five pillars, provide the minimum viable dashboard.
• Three KPIs per quadrant answer the four questions boards actually ask: risk posture, incident readiness, resilience confidence, and ecosystem governance.
• RAG thresholds are calibrated to supervisory expectations, not internal comfort. Green means examination-ready; red means examination-vulnerable.
• KPI 6 (Regulatory Reporting Compliance) has zero tolerance — 100% is the only green threshold. Missed reporting deadlines are regulatory breaches.
• KPI 10 (Concentration HHI) quantifies what Art. 29 mandates qualitatively: measure concentration, do not guess it.
• KPI 11 (Evidence Completeness) is the meta-metric that predicts examination outcomes. If you can prove it, you pass. If you cannot, you fail.
• Every red KPI must trigger a documented board decision — accept, remediate, or escalate. Passive acknowledgment is not governance.