DORA Article 5: what the management body actually signs up for¶
DORA gets treated like an IT project. Article 5 says otherwise. It is the first substantive article of the regulation, it is about governance, and it puts the board on the hook before a single firewall rule is mentioned. Today I want to walk through what Article 5 requires, what the defined terms actually mean, and what this looks like in practice.
Start with the definition, not the vibe¶
The regulation says "management body", and it is tempting to read that as "senior management" or "the CISO's boss". That reading is wrong, and the definition matters.
Article 3(30) does not define the term from scratch. It points to the sectoral rulebooks: Article 4(1)(36) of MiFID II, Article 3(1)(7) of CRD for credit institutions, the UCITS Directive, CSDR, the Benchmarks Regulation and MiCA, "or the equivalent persons who effectively run the entity or have key functions". For a bank this means the board, in both its management function and its supervisory function. Not a delegate. Not a committee that reports upwards. The body itself.
That is the first practical takeaway: when Article 5 says the management body shall do something, the evidence has to show the board doing it. A working group that prepared a paper is fine. A board that never discussed the paper is not.
What Article 5 actually requires¶
Article 5(1) sets the frame: financial entities need an internal governance and control framework that ensures effective and prudent management of ICT risk. So far, so generic. The teeth are in Article 5(2).
Article 5(2) says the management body shall "define, approve, oversee and be responsible for the implementation" of the ICT risk management framework, and then lists what that means, from (a) to (i). Grouped in plain language:
Own the risk. Point (a) is blunt: the management body bears the ultimate responsibility for managing the entity's ICT risk. You can delegate work. You cannot delegate this.
Set the direction. Points (b), (c) and (d): policies for availability, authenticity, integrity and confidentiality of data, clear roles for all ICT-related functions, and approval of the digital operational resilience strategy, including the risk tolerance level for ICT risk. More on that term below.
Review the machinery. Points (e) and (f): the ICT business continuity policy, response and recovery plans, and the ICT internal audit plans all need board approval and periodic review. "Periodically" is doing a lot of work here. If your board last saw the ICT audit plan two years ago, you have a finding waiting to be written.
Pay for it. Point (g) is my favourite, because it is the one boards feel: allocate and periodically review the budget for digital operational resilience, including security awareness programmes and training and ICT skills for all staff. A resilience strategy without a budget line is a wish.
Watch the vendors. Points (h) and (i): approve the policy on ICT third-party services, and set up reporting channels so the board is actually informed about third-party arrangements, planned material changes and their risk impact on critical or important functions, and major ICT incidents. On top of that, Article 5(3) requires a dedicated role, or a designated member of senior management, to monitor third-party arrangements.
Stay competent. Article 5(4) requires board members to actively keep their knowledge and skills up to date, including regular training commensurate to the ICT risk being managed. This is not a courtesy paragraph. Supervisors check it, and I will come back to that.
The risk tolerance detail most summaries miss¶
Article 5(2)(d) makes the board responsible for "the determination of the appropriate risk tolerance level of ICT risk". Here is the detail I find interesting: risk tolerance is not a defined term. I went through all 65 definitions in Article 3. It is not there.
The substance sits in Article 6(8)(b) instead. The digital operational resilience strategy must establish "the risk tolerance level for ICT risk, in accordance with the risk appetite of the financial entity, and analysing the impact tolerance for ICT disruptions". So the regulation quietly assumes a three-layer model: risk appetite at the top, an ICT risk tolerance level consistent with it, and impact tolerances for disruptions underneath.
My opinion on how to do this: write it as one page, not thirty. Appetite as a sentence the board can defend. Tolerance as a small set of thresholds (availability of critical functions, data loss, recovery time) with numbers in them. Impact tolerance as the point where a disruption becomes intolerable per critical or important function. If the board cannot explain the page, the page is too long. And because point (d) makes the board responsible for determining the level, the number cannot come from the risk function with the board waving it through. The minutes should show a discussion.
What the supervisors say¶
This is not theoretical. The supervisory community has been explicit about Article 5 themes.
The ECB expects the board to own this personally. Patrick Montagner of the ECB's Supervisory Board said in July 2025 that "governance and accountability must underpin every technological investment", and that boards themselves, not just risk or audit committees, are expected to own the resilience strategy, define the risk appetite for IT disruptions, and demand quantifiable metrics on availability and data accuracy (speech, 2 July 2025).
The ECB also checks Article 5(4) style competence. Anneli Tuominen said in October 2025 that there is "still room for improvement in the collective expertise" of boards on ICT and security risk, pointing to the ECB's dedicated supervisory expectations on board ICT expertise, which feed into fit-and-proper assessments (speech, 27 October 2025). Board training logs are not paperwork. They are supervisory evidence.
BaFin is watching the reporting channels fill up. Since reporting started in January 2025, BaFin received 733 major ICT incident reports in 2025, and roughly half of the incidents originated at third-party providers (BaFin incident statistics). Read that against Article 5(2)(i): if half the major incidents start at vendors, the board-level reporting channel on third-party arrangements is not a formality.
The framework beneath Article 5 is already concrete. The RTS on ICT risk management (Delegated Regulation (EU) 2024/1774) turns Articles 5 to 15 into detailed requirements, and the EBA narrowed its older ICT and security risk management guidelines in February 2025 so they now only cover entities and topics outside DORA's scope. For entities in scope, DORA is the rulebook.
The artefact: an evidence checklist¶
How I would assess Article 5 readiness: forget maturity models for a moment and ask, for each duty, "what single document proves this happened?". Here is the mapping I use.
| Duty | Evidence that proves it |
|---|---|
| 5(2)(a) ultimate responsibility | Board terms of reference naming ICT risk; minutes showing ICT risk as a board agenda item |
| 5(2)(b) data policies | Approved information security policy covering availability, authenticity, integrity, confidentiality |
| 5(2)(c) roles and responsibilities | RACI or equivalent for ICT functions, approved and dated |
| 5(2)(d) strategy and risk tolerance | Board-approved digital operational resilience strategy with an explicit tolerance statement |
| 5(2)(e) continuity and recovery | Approval and review records for the ICT business continuity policy and response and recovery plans |
| 5(2)(f) ICT audit | Approved ICT audit plan, review cadence, record of material modifications |
| 5(2)(g) budget | A budget line for resilience, awareness and training, reviewed at defined intervals |
| 5(2)(h) third-party policy | Approved policy on use of ICT third-party services |
| 5(2)(i) reporting channels | Standing board reporting on third-party arrangements, material changes and major incidents |
| 5(3) third-party oversight role | Role description or named senior manager with documented responsibility |
| 5(4) board competence | Training plan and attendance log for board members, proportionate to the ICT risk |
Eleven rows. If you can fill the right column with real documents and real dates, Article 5 stops being scary. If you cannot, you now have your gap assessment for this article, for free.
More DORA sources live in the DORA branch of the resource library. Next in this series: Article 6 and what an ICT risk management framework has to contain.