DORA Board Responsibilities 2026

In this article ↓

Short answer
DORA board responsibilities at a glance
What “management body” oversight means
Board evidence pack
ICT risk appetite and tolerance
Incident oversight
Incident board report
Resilience testing oversight
Testing report for the board
ICT third-party risk oversight
Third-party dashboard
Training and competence
Board training evidence
90-day board governance upgrade
Days 1-30: Build the board view
Days 31-60: Formalise governance
Days 61-90: Test oversight
Management-body evidence checklist
Common mistakes
Mistake 1: Treating DORA as an IT-only matter
Mistake 2: Approving a policy without seeing risk data
Mistake 3: No record of challenge
Mistake 4: Missing third-party concentration
Mistake 5: No overdue remediation view
Related reading
Primary sources
Bottom line
FAQ
What is the board responsible for under DORA?
Does the board need to understand technical cybersecurity details?
What should a DORA board pack include?
How often should DORA be reported to the board?
What evidence shows board oversight?
Is DORA compliance only an IT responsibility?

Last reviewed: 29 April 2026

Key takeaways

DORA makes the management body accountable for ICT risk oversight, not only policy approval.
Boards need evidence of risk appetite, reporting, incidents, third-party risk and resilience testing.
Supervisors ask whether directors receive current, challengeable information and track remediation.
Fastest path: define the board pack -> assign owners -> review exceptions -> keep minutes and decisions audit-ready.

Short answer

Under DORA, the management body is responsible for the financial entity's ICT risk management framework and digital operational resilience oversight. In 2026, the board or management body needs evidence that ICT risk is governed, reviewed and acted on.

This does not mean board members run security operations. It means they must approve, challenge and monitor the operating model for ICT risk, incidents, resilience testing, third-party ICT risk and remediation.

The practical board question is:

Can the management body show that it understands the material ICT risks and has made recorded decisions about them?

For most EU financial entities, the answer depends on five evidence areas:

approved ICT risk management framework;
current ICT risk register and risk appetite;
incident and resilience testing reports;
ICT third-party risk and concentration reporting;
remediation tracker with overdue actions and accepted risks.

DORA board responsibilities at a glance

Responsibility	What the board / management body should see	Evidence
Approve ICT risk framework	Framework, roles, risk appetite and review cadence	Approval minutes, version history
Oversee ICT risk	Top risks, residual risk, changes since last review	ICT risk register, board pack
Oversee incidents	Major incidents, near misses, classification decisions	Incident report, after-action review
Oversee resilience testing	Test results, failed assumptions, remediation	Test reports, BCDR evidence
Oversee third-party risk	Critical providers, Register of Information status, contract gaps	Supplier dashboard, clause tracker
Ensure resources	Budget, staffing, tooling and external support needs	Decision log, budget approvals
Track remediation	Overdue actions, risk acceptances, closure evidence	Remediation tracker

This table is the practical board checklist. It turns DORA governance from a policy statement into a repeatable agenda.

What “management body” oversight means

DORA uses the concept of the management body. Depending on the entity and jurisdiction, this may mean the board, executive management body, management board or equivalent governance body.

Oversight means the management body should be able to:

understand the entity's ICT risk profile;
approve the ICT risk management framework;
review material ICT risks and risk appetite;
receive information about major incidents and testing outcomes;
challenge overdue remediation;
ensure resources are adequate;
document risk acceptances and key decisions.

It should not be reduced to one annual sign-off. DORA resilience oversight works best as a standing governance cadence.

Board evidence pack

A supervisory-ready board pack should be concise, but it must connect strategy, risk and evidence.

Pack section	What to include	Source
Executive summary	Current ICT risk posture and major changes	CISO / risk owner
Top ICT risks	Highest residual risks and trend	ICT risk register
Incidents	Major ICT-related incidents, near misses, lessons learned	Incident log
Third parties	Critical ICT providers, concentration, contract gaps	Register of Information
Resilience testing	Tests performed, failed assumptions, remediation	Test reports
BCDR	Recovery objectives, test results, open gaps	BCP/DR evidence
Decisions required	Risk acceptances, budget, ownership, policy approval	Management action log

The board pack should be understandable without technical translation, but detailed enough to support challenge.

ICT risk appetite and tolerance

The board should not approve generic statements such as “low risk appetite for cyber risk” and stop there. Risk appetite needs operating meaning.

Useful tolerance examples include:

Area	Example tolerance question
Service availability	What downtime is tolerable for a critical payment or customer function?
Data loss	What recovery point objective applies to regulated records?
Incident classification	Who can decide that an incident is major under DORA?
Supplier concentration	What dependency on a single cloud, processor or KYC provider is acceptable?
Remediation	How long can high-risk actions remain overdue?
Access control	What exceptions to privileged access rules require management approval?

The key is not the exact wording. The key is that risk appetite is connected to decisions, reporting and escalation.

Need a DORA board pack that is usable, not decorative?

A 15-minute call can identify the evidence directors actually need before the next review - no pitch, just gaps.

Book a free 15-min call →

Incident oversight

The management body does not need to approve every operational incident. It does need visibility into material incidents, reporting decisions and after-action remediation.

The board should see:

whether the incident was ICT-related;
whether it was classified as major;
when it was detected and classified;
whether the NCA was notified;
which services and customers were affected;
root cause and remediation;
lessons learned and control changes.

Incident board report

Incident field	Board relevance
Detection time	Shows response maturity
Classification decision	Shows DORA reporting governance
Impact	Shows business and customer consequence
NCA reporting status	Shows regulatory handling
Root cause	Shows whether the issue is understood
Remediation owner	Shows accountability
Due date	Shows control over closure

For the operating timeline, see DORA Incident Reporting 2026.

Resilience testing oversight

DORA requires a digital operational resilience testing programme. The board should understand what has been tested, what failed and what is being remediated.

Testing reports should distinguish between:

vulnerability assessments;
scenario/tabletop exercises;
backup restore tests;
disaster recovery tests;
supplier failure simulations;
incident response exercises;
threat-led penetration testing where the entity is in scope.

Threat-led penetration testing under Article 26 is not universal. It applies at least every three years to financial entities identified by competent authorities. The board should confirm whether the entity is in scope rather than assume it is.

Testing report for the board

Question	Evidence
Which critical functions were tested?	Test scope
What scenario was used?	Scenario description
Did RTO/RPO expectations hold?	Test result
What failed?	Exceptions and findings
Who owns remediation?	Action tracker
What is overdue?	Remediation status

ICT third-party risk oversight

ICT third-party risk is a board-level topic because many financial entities depend heavily on cloud, payment processors, SaaS platforms, fraud tools, KYC vendors and managed service providers.

The board should see:

critical ICT third-party providers;
services supporting critical or important functions;
concentration risk;
material subcontracting;
contract remediation status;
exit strategy gaps;
supplier incidents or deteriorating assurance;
Register of Information status.

Third-party dashboard

Metric	Why it matters
Number of critical ICT providers	Shows dependency perimeter
Providers supporting critical or important functions	Shows DORA priority
Contracts missing Article 30 clauses	Shows legal remediation need
Single-provider concentration	Shows resilience exposure
Exit plans missing or untested	Shows continuity risk
Supplier incidents this period	Shows operational performance

For the underlying artefact, see DORA Register of Information: 2026 Guide for ICT Third-Party Risk.

Training and competence

DORA oversight requires the management body to understand the ICT risk matters it is approving and challenging. That does not require every board member to become a technical specialist.

Board training should cover:

DORA scope and management-body responsibilities;
ICT risk framework and risk appetite;
incident classification and reporting;
resilience testing and BCDR;
ICT third-party risk and concentration;
how to read the ICT risk register;
how to challenge remediation delays.

Board training evidence

Evidence	Why it matters
Training agenda	Shows topics covered
Attendance record	Shows who participated
Materials	Shows content quality
Q&A / decisions	Shows challenge and understanding
Refresher cadence	Shows ongoing competence

90-day board governance upgrade

If board oversight is weak, start with a practical 90-day upgrade.

Days 1-30: Build the board view

Prepare a concise ICT risk register extract.
Identify top 10 ICT risks.
Map risks to critical or important functions.
Summarise incident history and open remediation.
Identify critical ICT third-party providers.

Days 31-60: Formalise governance

Approve or update the ICT risk management framework.
Define ICT risk appetite and escalation thresholds.
Create a standard quarterly DORA board pack.
Assign owners for incidents, third-party risk, testing and remediation.
Schedule board training.

Days 61-90: Test oversight

Run one incident or BCDR tabletop with management reporting.
Present results to the board or management body.
Record decisions and challenge.
Update the remediation tracker.
Review overdue actions and accepted risks.

Management-body evidence checklist

Evidence item	Status question
ICT risk management framework	Has it been approved and reviewed in the last 12 months?
ICT risk register	Are top residual risks current and owned?
Risk appetite	Are tolerance levels defined and used?
Incident reporting workflow	Are DORA classification decisions recorded?
BCDR and testing reports	Are findings tracked to closure?
Register of Information	Are critical ICT providers visible?
Contract remediation tracker	Are Article 30 gaps tracked?
Board training record	Has the management body received current DORA training?
Board pack	Is there a recurring ICT risk reporting cadence?
Decision log	Are risk acceptances and approvals recorded?

This is the checklist I would use before a supervisory review, partner-bank request or internal audit.

Common mistakes

Mistake 1: Treating DORA as an IT-only matter

Technology teams operate controls. The management body owns oversight. If ICT risk never reaches the board, governance evidence is weak.

Mistake 2: Approving a policy without seeing risk data

The board should see the risk register, incidents, supplier dependencies and remediation, not only the framework document.

Mistake 3: No record of challenge

Minutes that only say “noted” are weak evidence. Record questions, decisions, requested follow-up and risk acceptances.

Mistake 4: Missing third-party concentration

Supplier dependence is often where board-level resilience risk lives. Cloud, payment processors and core SaaS dependencies should be visible.

Mistake 5: No overdue remediation view

If the board cannot see late actions, it cannot challenge accountability.

Primary sources

Bottom line

DORA board responsibility is about evidence of informed oversight.

The management body should be able to show what it approved, what it challenged, which risks it accepted, which remediation it funded and how ICT resilience is monitored over time.

That is the difference between a DORA policy sign-off and a defensible governance model.

FAQ

What is the board responsible for under DORA?

The management body is responsible for oversight of the ICT risk management framework, risk appetite, resilience strategy, incident and testing governance, ICT third-party risk and the resources needed to manage operational resilience.

Does the board need to understand technical cybersecurity details?

The board does not need to operate technical controls, but it should understand the material ICT risks, incident trends, supplier dependencies, recovery assumptions and remediation decisions it is approving or challenging.

What should a DORA board pack include?

A practical board pack should include top ICT risks, incidents and classification decisions, testing and BCDR results, critical third-party dependencies, overdue remediation, contract gaps, risk acceptances and decisions required from the management body.

DORA Board Responsibilities 2026: Management Body Evidence Checklist