DORA for Board Directors: A Non-Technical Governance Primer

The Personal Liability Wake-Up Call

In December 2024, a month before DORA became applicable, a survey of 200 board directors at EU-regulated financial institutions revealed a striking gap: while 89% had heard of DORA, only 31% could name the specific obligations it places on the management body. Among non-executive directors from non-technology backgrounds — legal, finance, risk, commercial — that number dropped to 14%.

This is not a knowledge gap that will be tolerated. DORA Article 5(2) states that the management body shall "define, approve, oversee and be responsible for the implementation" of the ICT risk management framework. Article 5(4) requires members of the management body to "follow specific training" to understand and assess ICT risk. And penalties for individuals can reach EUR 1 million across multiple EU member states.

The regulation does not distinguish between executive and non-executive directors, between technology-literate and non-technical board members, or between those who delegated ICT oversight to a committee and those who retained it. The obligation is collective and personal.

This primer translates DORA's governance requirements into the language of board directors who may not have a technology background but who bear personal responsibility for their institution's digital operational resilience.

What DORA Actually Requires of the Board

Figure 1: DORA governance obligations on the management body. All six obligations are personal — failure to fulfill them exposes individual board members to penalties up to EUR 1 million.

DORA's governance obligations are concentrated in three articles. Understanding them does not require technical expertise — it requires understanding accountability.

Article 5: Governance and Framework Ownership

Article 5(2) is the foundational governance provision. The management body must:

• Define and approve the ICT risk management framework (Art. 5(2)(a)). This is not a rubber-stamp exercise. The board must understand what the framework covers, how it is structured, and what resources it requires.

• Approve the digital operational resilience strategy (Art. 5(2)(b)), including setting risk tolerance levels for ICT disruptions. This means the board decides how much disruption is acceptable — not the IT department.

• Approve and review business continuity and disaster recovery plans (Art. 5(2)(c)). When a critical system fails, the board owns the recovery strategy.

• Approve and review the ICT third-party risk management policy (Art. 5(2)(d)), including decisions on critical outsourcing arrangements.

Article 5(4) adds a personal obligation: management body members must "follow specific training, on a regular basis" to gain "sufficient knowledge and skills to understand and assess ICT risk and its impact on the operations of the financial entity."

Article 14: Annual Reporting to the Board

Article 14(1) requires financial entities to report at least annually to the management body on the "findings" of the ICT risk management framework review. This report must cover:

• Current ICT risk profile and material changes
• Incident history and lessons learned
• Testing programme results and coverage gaps
• Third-party risk profile and concentration exposure
• Progress on remediation of identified deficiencies

The board must not merely receive this report — it must review, challenge, and act on it. A board that receives an annual report and files it without discussion has not met its Art. 14 obligation.

Personal Penalties: The Individual Accountability Dimension

DORA Article 50-64 delegates penalty enforcement to national competent authorities (NCAs), and member states have implemented varying penalty ceilings. But the pattern is consistent: individuals face personal financial consequences.

The critical point for directors: these penalties can apply to individuals who failed to exercise adequate oversight, not only to those who actively caused a breach.

The 10 Questions Every Board Director Should Ask

Board directors do not need to understand cloud architecture or network topology. They need to ask the right questions and evaluate the answers. These ten questions map to specific DORA obligations and provide a structured governance framework.

1. Has the board formally approved the ICT risk management framework? (Art. 5(2)(a))

If the answer is no, this is a foundational gap. The framework must exist, be documented, and carry board approval. Ask to see the approval record.

2. What are our impact tolerance thresholds for critical functions? (Art. 5(2)(b))

The board must set — not merely acknowledge — the maximum tolerable disruption for each critical function. How many hours of core banking downtime is acceptable? How many customers can be affected before regulatory notification triggers?

3. How many of our critical functions depend on a single technology provider? (Art. 29)

Concentration risk is a board-level topic. If your core banking, payment processing, and customer authentication all depend on one cloud provider, a single outage can cascade across all critical functions simultaneously.

4. Have we tested our recovery plans in the last 12 months, and did they work? (Art. 24-27)

Testing plans on paper is not testing. Ask for actual recovery test results: Was the target recovery time achieved? Were critical functions restored in the correct priority order? What failed?

5. How many ICT incidents did we have last year, and what was the regulatory impact? (Art. 17-23)

The incident register is a health indicator. Zero incidents may indicate poor detection rather than good resilience. Ask for trend data, severity distribution, and root cause patterns.

6. Can we produce a complete evidence pack for an examiner in 48 hours? (Implicit across all pillars)

When regulators examine, they ask for evidence. If producing an evidence pack takes weeks rather than hours, the institution is not audit-ready. Sixty percent of supervisory findings relate to missing or incomplete evidence.

7. When did board members last complete ICT risk training? (Art. 5(4))

This is a personal obligation. Training must be documented, regular, and substantive. A 30-minute compliance video does not constitute "sufficient knowledge and skills" to assess ICT risk.

8. What is our third-party concentration exposure, and do we have credible exit strategies? (Art. 28-29)

Ask for the Herfindahl-Hirschman Index or equivalent concentration metric. Ask whether exit strategies have been tested — not merely documented.

9. How does our incident response timeline compare to DORA's reporting requirements? (Art. 19)

DORA requires initial incident notification within 4 hours. If the institution's detection and escalation process typically takes longer than that, there is a structural gap.

10. What is management's assessment of our overall DORA compliance posture, and what are the top three gaps? (Art. 5-6)

No institution is 100% compliant. The honest answer reveals whether management understands the gaps and has a prioritized remediation plan.

The Quarterly Board Briefing Framework

Annual reporting is the regulatory minimum. Effective governance requires quarterly visibility. The following template provides a structured briefing that can be delivered in 30 minutes.

This briefing should be a standing agenda item, not an ad-hoc addition when a crisis occurs.

What "Sufficient Knowledge and Skills" Means in Practice

Article 5(4) does not define what "sufficient knowledge and skills" means. But supervisory expectations are emerging. The training obligation is not a one-time exercise — it must be "on a regular basis" and must enable board members to:

• Understand the institution's ICT risk profile and how it relates to business strategy
• Evaluate whether the ICT risk management framework is adequate and properly resourced
• Challenge management on testing results, incident trends, and remediation progress
• Make informed decisions on critical outsourcing arrangements and concentration risk
• Assess the credibility of business continuity and recovery plans

Practical approaches that meet supervisory expectations include: dedicated board training sessions (half-day minimum, annually), participation in tabletop resilience exercises, structured briefings from the CISO or CTO before board decisions on ICT matters, and external training programmes accredited for financial sector governance.

What does not meet the obligation: forwarding an industry article by email, a 15-minute presentation once a year, or delegation to a board committee without whole-board engagement.

The Governance Model That Works

Figure 2: The three-tier DORA governance model. Delegation does not eliminate accountability — the full board remains responsible under Article 5(2) regardless of committee structures.

Institutions that manage DORA governance effectively typically adopt a three-tier model:

Tier 1: Full Board. Retains authority over framework approval, risk tolerance setting, and annual review. Receives quarterly briefings. Completes annual training. This is the Art. 5(2) accountability layer.

Tier 2: Board Risk Committee (or equivalent). Provides deeper oversight between board meetings. Reviews incident reports, testing results, and third-party risk assessments in detail. Recommends actions to the full board. Meets monthly.

Tier 3: Management-level ICT Risk Function. Executes the framework, manages the testing programme, maintains the third-party register, and prepares board reporting. Escalates material issues through Tier 2 to Tier 1.

The critical principle is that delegation does not eliminate accountability. The full board remains responsible under Article 5(2) regardless of committee structures.

The Cost of Getting This Wrong

Board governance failures under DORA carry three categories of consequence:

Regulatory. NCAs can impose administrative penalties on individuals. The amounts vary by jurisdiction, but EUR 1 million in personal liability concentrates the mind. Supervisory findings related to governance deficiencies can trigger remediation orders, increased scrutiny, and public disclosure.

Operational. A board that does not understand its institution's ICT risk profile cannot make informed strategic decisions about technology investment, outsourcing, and risk tolerance. The result is either under-investment (leading to incidents) or uninformed over-spending (wasting shareholder value).

Reputational. In the post-DORA environment, a major ICT incident followed by evidence that the board had not fulfilled its governance obligations will generate regulatory, media, and shareholder scrutiny simultaneously. The 2024 CrowdStrike incident demonstrated that operational resilience failures become front-page news within hours.

Actionable Takeaways

1. Schedule a dedicated DORA governance session. If the board has not formally approved the ICT risk management framework under Art. 5(2), this is the single highest priority. Schedule a half-day session, not a 30-minute agenda item.

1. Complete documented ICT risk training. Art. 5(4) training must be substantive and documented. Arrange training that covers DORA's structure, your institution's specific risk profile, and practical governance scenarios.

1. Establish quarterly reporting. Do not wait for the annual Art. 14 report. Implement the quarterly briefing template above and make it a standing agenda item.

1. Use the 10-question framework. At every relevant board meeting, ensure at least three of the ten questions are formally addressed. Over a year, the full governance landscape is covered.

1. Document everything. Board minutes should explicitly record DORA-related discussions, decisions, and challenges. When the examiner asks "How does the board oversee ICT risk?", the answer must be in the minutes — not in memory.

---

This guide reflects DORA Regulation (EU) 2022/2554 governance provisions as applicable from January 17, 2025. National penalty frameworks vary by member state. Institutions should seek jurisdiction-specific legal advice on individual liability exposure.

---