DORA Executive Briefing for Boards and Directors

Under the Digital Operational Resilience Act, the management body of an EU financial entity does not just receive reports on ICT risk: it carries the ultimate legal responsibility for it. Regulation (EU) 2022/2554 (DORA) has applied since 17 January 2025 to banks, insurers, investment firms, payment and e-money institutions, crypto-asset service providers and many other financial entities. This briefing is for directors, chief executives, chief risk officers, general counsel and CISOs who need to know what DORA asks of the board itself, how to oversee ICT risk, testing and third-party dependence, and how to tell whether management's assurances would survive a supervisor's questions. It stays at board level. The pillar-by-pillar requirements and the Level 2 standards are covered in the DORA Guide.

The risk in one paragraph

Financial services now run on a small number of technology platforms, cloud providers and software suppliers, and an outage or compromise at any of them can stop payments, trading or claims within minutes. DORA responds by making digital operational resilience a matter of law rather than supervisory expectation: each financial entity must manage ICT risk through a documented framework, classify and report major ICT incidents on fixed clocks, test its resilience every year (and, for the most significant firms, through threat-led penetration testing), and control the ICT third parties it relies on through a register, mandatory contract terms and tested exit plans. The board's exposure is twofold. If a disruption happens, the firm must show it was managed under a framework the board defined and approved. If the supervisor finds gaps, national law can apply penalties and remedial measures not only to the firm but, where national law allows, to members of the management body.

Why this is a board-level issue now

The law names the board. Article 5(2) states that the management body "shall define, approve, oversee and be responsible for the implementation" of the ICT risk management framework, and point (a) says it must "bear the ultimate responsibility for managing the financial entity's ICT risk".
Directors must keep their own knowledge current. Article 5(4) requires members of the management body to "actively keep up to date with sufficient knowledge and skills" to understand and assess ICT risk and its impact on operations. Supervisors can test this in interviews.
Penalties can reach individuals. DORA does not fix an EU-wide fine level for financial entities. Article 50 requires Member States to give competent authorities powers including cease and desist orders, pecuniary measures and public notices, and Article 50(5) allows these to apply, subject to national law, to members of the management body and other individuals responsible for the breach.
Supervisors now see your supplier map. Each entity's register of information under Article 28(3) is reported to supervisors. On 18 November 2025 the European Supervisory Authorities (EBA, EIOPA and ESMA) published the first list of designated critical ICT third-party providers, built from data in those registers.
Incident clocks run in hours. A major ICT-related incident needs an initial notification within four hours of classification and no later than 24 hours after the entity became aware of it, an intermediate report within 72 hours and a final report within a month. See the DORA Major ICT Incident Reporting Guide.

What DORA asks of the management body

Article 5(2) turns board accountability into a list of specific duties. Directors should be able to point to the paper that discharges each one.

Article 5(2) duty	What the board should have seen and approved	Evidence a supervisor may ask for
(a) Ultimate responsibility for ICT risk	ICT risk on the board agenda with a named executive owner	Board and committee minutes showing challenge, not just noting
(b) Policies for data availability, authenticity, integrity and confidentiality	Information security and data policies at the right level	Approved policies with review dates
(c) Clear ICT roles and responsibilities	Three lines of defence for ICT risk, with an independent control function	Role descriptions and terms of reference
(d) Digital operational resilience strategy	A strategy linked to business strategy and risk appetite	Approved strategy and progress reports
(e) ICT business continuity policy	Continuity and response and recovery plans for critical or important functions	Test results and remediation tracking
(f) ICT internal audit plans	Audit coverage of ICT risk, testing and third parties	Approved audit plan and material findings
(g) Budget	Funding for resilience, including awareness and training under Article 13(6)	Budget decisions tied to identified gaps
(h) Policy on use of ICT third-party services	Third-party risk policy and risk appetite for concentration	Approved policy, register summary
(i) Reporting channels on third-party arrangements	Regular information on ICT contracts, planned material changes and impact on critical or important functions	Reports received and decisions taken

Article 5(3) adds that financial entities other than microenterprises must establish a role to monitor arrangements with ICT third-party service providers, or designate a senior manager to oversee that exposure. Boards should know who holds it.

ICT risk: what the board should oversee

DORA's ICT risk management chapter (Articles 5 to 16) and Delegated Regulation (EU) 2024/1774 follow a management system shape: identify, protect, detect, respond and recover, learn and communicate. The board does not run any of this, but it should expect clear answers in these areas:

Critical or important functions: the firm should have identified the business functions whose disruption would materially impair its performance, its regulatory compliance or its financial soundness, and mapped the ICT assets and providers each one depends on. Almost every other DORA obligation hangs off this list.
Access to the systems that matter: RTS 2024/1774 Articles 20 and 21 require unique identities for people and systems, need-to-use privileged access, strong authentication for remote and privileged access, and access reviews at least every six months for systems supporting critical or important functions. This explicitly covers machine and service identities as well as people. See the Board Briefing: NHI Risk.
Backup and recovery: the board should see tested recovery times for critical or important functions, not backup success rates. See the Business Impact Analysis Template.
Learning from incidents: post-incident reviews should lead to changes the board can track, and the framework should be reviewed at least yearly and after major incidents.

Incident reporting: decisions that cannot wait for a board meeting

Classification of a major incident follows the criteria and thresholds in Delegated Regulation (EU) 2024/1772, and the reporting content and time limits are set by Delegated Regulation (EU) 2025/301. Four hours is less time than it takes to convene a committee, so the board's role is to delegate clearly in advance.

Stage	Deadline	Board's preparatory role
Classification as major	As soon as the criteria are met	Approve who may classify, and the escalation route to executives
Initial notification	Within 4 hours of classification, and no later than 24 hours after awareness	Confirm a named executive can sign off out of hours
Intermediate report	Within 72 hours of the initial notification	Expect a briefing to the chair and the relevant committee
Final report	Within one month of the latest intermediate report	Review root cause and remediation at the next board or committee

Financial entities may outsource the reporting task under Article 19(5) but remain fully responsible for it. Where the same incident triggers NIS2, GDPR or other notification duties, legal should hold one map of all the clocks. See the EU Incident Reporting Clocks comparison.

Resilience testing and TLPT

Article 24 requires a risk-based digital operational resilience testing programme, with appropriate tests at least yearly on all ICT systems and applications that support critical or important functions (Article 24(6)). Article 25 lists the test types, from vulnerability scans and source code reviews to scenario-based, end-to-end and penetration tests.

Threat-led penetration testing: entities identified by their competent authority must carry out TLPT at least every three years under Article 26(1), on live production systems supporting critical or important functions, with ICT providers in scope required to participate. Criteria and method are set by Delegated Regulation (EU) 2025/1190 and follow the TIBER-EU approach.
Tester independence: firms using internal testers must contract external testers every three tests (Article 26(8)).
The board's interest: TLPT findings show how a capable attacker would reach the firm's most important services. The board should see the summary, the remediation plan and progress against it, not just confirmation that a test took place. See the Penetration Testing Guide for how testing programmes are scoped.

ICT third-party risk and concentration

Article 28(1) is blunt: financial entities "remain fully responsible" for compliance with DORA when they use ICT third-party services. Outsourcing does not move accountability. For the board, this pillar is where the largest unpriced exposure usually sits.

DORA requirement	Board-level question	Weak answer
Register of information (Art. 28(3))	Does the register reconcile with finance and procurement records, including subcontractors that underpin critical or important functions?	"Procurement keeps a contract list"
Pre-contract assessment (Art. 28(4))	Do we assess concentration risk before signing, not after?	Concentration considered only at renewal
Contract terms (Art. 30)	Do contracts for critical or important functions include audit and access rights, incident assistance, TLPT participation and exit with a transition period?	Terms negotiated case by case with no gap tracker
Exit strategies (Art. 28(8))	Have we tested leaving a critical provider, and how long would it take?	Exit plan written but never exercised
CTPP oversight (Art. 31 to 44)	Which of our providers are designated CTPPs, and how do Lead Overseer findings feed our own risk view?	"The regulators supervise them, so we do not need to"

Lead Overseers can impose periodic penalty payments on a designated provider of up to 1% of its average daily worldwide turnover per day, for up to six months (Article 35(6) to (8)). That pressure on providers does not replace the financial entity's own due diligence, contracts and testing. See the DORA ICT Third-Party Risk and Register of Information Guide, the DORA Critical ICT Third-Party Provider Oversight Guide and the Cloud Concentration Risk and Exit Strategy Guide.

Five questions for the board to ask

Which of our functions are critical or important, and what would one day without each cost us? A credible answer names the functions, the ICT services and providers behind each, and a tested recovery time.
If a major incident started at 2am on a Saturday, who would classify it and who would sign the four-hour notification? Expect named people with deputies, an out-of-hours route and evidence of a rehearsal.
Which providers could stop more than one critical function at once, and could we leave any of them? Look for a concentration view from the register and at least one tested exit for a critical provider.
What did our last resilience tests find, and what has been fixed? The answer should include the yearly test programme, any TLPT summary and a remediation plan with dates and owners.
How would we show a supervisor that this board discharged its Article 5 duties? Management should be able to produce approvals, minutes, training records for directors and the reports the board received.

Red flags in management answers

"DORA is a compliance project": a project ends; DORA obligations run every year, with annual testing, yearly reporting of the register and continuous incident duties.
"We were already compliant with the EBA outsourcing guidelines": DORA's register covers all ICT contractual arrangements, not only outsourcing, and adds specific contract terms.
"Our cloud provider is a CTPP, so it is covered": designation brings EU oversight of the provider, but the financial entity remains fully responsible for its own risk.
"The register is done": ask when it last reconciled with invoices and whether subcontractors underpinning critical or important functions are recorded.
"We test every year": ask whether the tests covered every system supporting critical or important functions, or only the perimeter.
Board training as a one-off session: Article 5(4) asks directors to keep knowledge current, which suggests a recurring programme with records.

What good looks like

Area	Good practice
Governance	Approved resilience strategy, ICT risk appetite including concentration, named executive owner, Article 5(3) monitoring role assigned
Board capability	Recurring director training on ICT risk, with records, and access to independent expertise
ICT risk	Critical or important functions mapped to assets, identities and providers; six-monthly access reviews for systems supporting them
Incidents	Pre-approved classification authority, out-of-hours sign-off, rehearsed four-hour notification
Testing	Yearly risk-based programme covering all systems supporting critical or important functions; TLPT findings tracked to closure
Third parties	Reconciled register, Article 30 gap tracker, tested exit for at least the most concentrated provider
Assurance	Internal audit coverage of each pillar, findings reported to the audit committee

The DORA Readiness Checklist turns these areas into line items for management.

Where to invest first

The critical or important function map: without it, testing scope, contract remediation, access reviews and the register cannot be prioritised.
Incident classification and reporting readiness: the four-hour clock is the obligation most likely to be missed in practice, and missing it is visible to the supervisor immediately.
Contracts and exit for critical providers: repaper contracts for critical or important functions with Article 30 terms first, then test one exit end to end.
Identity and access to critical systems: strong authentication on privileged and remote access and an inventory of service accounts and API credentials that reach critical systems. See the DORA Guide for the RTS 2024/1774 detail.
Testing that produces fixes: a yearly programme with remediation tracking, ready for TLPT if the authority selects the firm.

Metrics to track

Percentage of critical or important functions with a tested recovery time within the approved tolerance.
Time from incident detection to classification, and to initial notification, in incidents and exercises.
Percentage of contracts supporting critical or important functions that include all Article 30 terms.
Number of critical or important functions dependent on a single provider with no tested exit.
Open resilience testing and TLPT findings past their due date.
Completion of six-monthly access reviews for systems supporting critical or important functions, including non-human accounts.

A 90-day plan

Days 1 to 30: confirm the executive owner and the Article 5(3) role; ask management for the current critical or important function list and the register summary; check that the board has formally approved the resilience strategy, continuity policy, third-party policy and ICT audit plan; schedule director training.
Days 31 to 60: review the incident classification and four-hour notification process and the out-of-hours sign-off; receive a concentration view of providers from the register; ask for the Article 30 contract gap tracker with dates.
Days 61 to 90: run an executive exercise of a major incident at a critical provider, including a regulator notification; review the yearly testing programme and open findings; agree a 12-month remediation plan and the quarterly metrics above.

Common failure patterns

Accountability without information: boards approve a framework once and then receive only traffic-light dashboards, which leaves them unable to show the challenge Article 5 implies.
A function list that is too long or too short: labelling everything critical makes testing and contracts unaffordable; labelling too little leaves real dependencies outside scope.
Registers built for submission, not management: a register compiled once a year for the supervisor does not help the board see concentration or change.
Exit plans as paperwork: exit strategies that have never been exercised rarely meet Article 28(8), especially for cloud providers with proprietary services. The July 2024 global outage linked to a faulty security software update showed how one provider can stop many firms at once: see the Third-Party Concentration Risk Guide.
Machine identities left out: access reviews cover staff but not the service accounts, API keys and automation that reach critical systems, although RTS 2024/1774 requires identities for systems as well as people.

Practitioner checklist

Record board approval of each Article 5(2) item, with review dates, in one evidence pack.
Keep a director training plan and attendance records that show knowledge kept current under Article 5(4).
Maintain an approved list of critical or important functions mapped to ICT assets, identities and providers.
Pre-approve incident classification authority and out-of-hours sign-off for the four-hour notification.
Report the register of information to the board as a concentration view at least yearly.
Track Article 30 contract gaps for critical or important functions to closure.
Test at least one exit from a critical provider and report the result.
Report the six metrics above to the risk or audit committee each quarter.

Standards and references

How NHI Mgmt Group can help

We provide independent identity and non-human identity risk assessments and board briefings, with a focus on the privileged, service and machine accounts that reach critical or important functions and that DORA's access control standard brings into scope. Our NHI Foundation Level Training Course helps security and IAM teams govern service accounts, API keys and secrets. Contact us to arrange a briefing.

Related NHI Mgmt Group resources: DORA Guide · DORA and NIS2 Overlap Mapping Guide · Board and Director Cyber Liability Guide · Board Cyber Risk Reporting Guide. This guide summarises Regulation (EU) 2022/2554 for board members and is not legal advice.

DORA Executive Briefing: What Boards Must Own, Ask and Evidence