Article 5 DORA governance: requirements and evidence

What DORA Article 5 asks of the management body

Article 5 makes the management body of a financial entity, meaning the board and the senior people who run the firm, personally answerable for ICT risk. The first thing a compliance lead should take from it is that this is not a delegation exercise. Article 5(1) asks the entity to run an internal governance and control framework that keeps ICT risk managed effectively and prudently. Article 5(2) then places the duty to define, approve, oversee and implement every arrangement in the ICT risk management framework on the management body, which carries ultimate responsibility. A technology or security function can run the work, but the board has to own the decisions and be able to show that it did.

Boards struggle here for a predictable reason: oversight is easy to claim and hard to evidence. Minutes that say a cyber update was noted do not show that a director understood the risk, challenged the position, or changed a decision. An assessor will look for the decisions the board actually took: approving the digital operational resilience strategy and ICT risk tolerance, approving and periodically reviewing the business continuity and response and recovery plans, approving the internal audit plan, and allocating budget for resilience and training. Each approval should have a dated paper, a named owner and a record of the review that followed. Confirm with your supervisor how often it expects those reviews to occur, because the Regulation sets the principle and the supervisory expectation sets the cadence.

Start by mapping each Article 5(2) duty to a board decision already in your calendar, and check whether the paper, the discussion and the follow-up action are recorded for the last cycle. Where a gap appears, the fix is usually a standing agenda item and a decision log, not a new policy. An implementation partner can help assemble that evidence trail from existing documents, but the approvals, the challenge and the accountability must come from the management body itself. Whether an independent body will test the arrangement is a matter for the competent authority, which supervises compliance under DORA.

Which entities and roles fall under Article 5 governance duties

Article 5 applies to the management body of every financial entity in scope, but the workload depends on the entity type, its size and how much ICT work it outsources. The cards below cover who is in scope, where the exemptions sit, and which scoping decisions change what the board must review.

Twenty entity types in Article 2(1)

Article 2(1) applies DORA to 20 types of financial entity, from credit institutions and payment institutions to insurers, crypto-asset service providers and securitisation repositories. Article 5 falls on the management body of each of them, so the first task is confirming which point of Article 2(1) describes your legal entity. Check this against your licence or authorisation, not against how the business describes itself. Entities that hold more than one licence may fall under more than one point.

Microenterprise exemption from monitoring

Article 5(3) requires most financial entities to set up a role that monitors arrangements with ICT third-party providers, or to name a senior manager who oversees that risk and its documentation. Microenterprises are excluded from that monitoring role. Confirm your microenterprise status against the definition that applies to you and record the decision, because the exemption covers only the monitoring role and not the wider governance duties in Article 5(2).

Simplified regime under Article 28

Entities under the simplified regime still have governance duties. Article 28 of Delegated Regulation (EU) 2024/1774 requires the management body to allocate and review, at least once a year, the budget needed for digital operational resilience. Ask whether your entity qualifies for the simplified regime under Article 16 and what the Delegated Regulation requires on top of the baseline, so the board knows which duties still apply in full.

Group entities and shared governance

Group structures change the governance workload. A subsidiary that relies on a parent for ICT services still needs its own management body to approve the resilience strategy, the third-party policy and the continuity arrangements. Document which decisions the board takes locally, which it adopts from group policy, and how group-level ICT providers and intra-group services are reported back to each regulated entity.

Outsourced ICT functions and accountability

Outsourcing an ICT function does not transfer the management body's responsibility under Article 5. The board still approves the third-party policy and receives reporting on arrangements, planned material changes and major incidents. Map each outsourced function to a named internal owner and confirm that the reporting lines reach the board, especially for providers that host or operate systems supporting critical or important functions.

Scoping decisions to record

Several scoping choices shape the governance file: entity type, microenterprise status, simplified regime eligibility, group reliance and the list of outsourced ICT services. Record each decision with its rationale, the date it was taken and the person who approved it. Assessors and supervisors usually ask for this scoping record before they test the board's duties, so keep it current when the business, the group or a provider changes.

How a supervisor tests board-level ICT governance

This table compares each Article 5 governance duty against the test approach a supervisor typically takes, the evidence it asks for and the findings that recur. Read it as a checklist of what the management body must be able to show, not as a statement of what a competent authority will do in any specific case.

Duty under Article 5	Test approach and evidence requested	Common findings
Approve the digital operational resilience strategy and ICT risk tolerance	Review the signed strategy and risk tolerance statement, the board minute approving them, and the metrics the board receives against that tolerance.	Minutes record approval but no discussion of tolerance levels; the strategy was approved after the period it covers had already started.
Approve and periodically review continuity and response and recovery plans	Request the approved policy, plan versions, review dates and the minutes showing the board reviewed test results from the continuity testing cycle.	Plans approved once and never reviewed; test findings reported to management but not tabled at board level.
Approve internal audit plans	Check the approved audit plan, its scope against ICT risk, and the board or audit committee minutes that accepted it.	Audit plan approved without any ICT scope; findings from prior ICT audits not followed up at board level.
Allocate budget for resilience, awareness and training	Compare the approved budget lines with the resilience programme and the training records for the same year. Ask how the budget was set and reviewed.	Budget approved as a single line with no link to the programme; training budget spent on an unrelated area.
Approve the policy on ICT third-party services	Review the approved policy, its review date, the version history and minutes showing the board discussed the policy's scope and material changes.	Policy approved after contracts with material providers were already signed; no record of periodic review since approval.
Reporting channels on third-party arrangements, material changes and major incidents	Ask for the standing agenda, the reports sent to the board, and the minutes showing what questions were asked and what decisions followed.	Reports are received as information only; minutes record no challenge, no requested action and no follow-up on open items.
Monitoring role for ICT third-party arrangements (Article 5(3))	Confirm the named role or senior manager, the terms of reference, and the register or log of monitoring activity such as reviews and contract checks.	Role named on paper but no monitoring activity recorded; the designated person lacks the authority or time to act.
Board member ICT knowledge and training (Article 5(4))	Request the training plan for each board member, completion records, and evidence that the training relates to the ICT risk the entity manages.	Training is generic cyber awareness; some members have no record of completion; no update after a major change in the risk profile.

How to build board governance that passes review

This sequence turns the management body's Article 5 duties into a documented decision map, a reporting cadence, a named monitoring owner, an approval calendar and a training record that an assessor can trace from requirement to evidence.

Map the management body's decisions
Start by listing every decision Article 5 places with the management body: approving the digital operational resilience strategy and ICT risk tolerance, approving and reviewing the ICT business continuity policy, response and recovery plans, ICT internal audit plans and the third-party use policy, and allocating budget for resilience, awareness and training. Record each decision against the board or committee that holds it, the paper that supports it and the role that prepares it. The output is a decision register that names one owner per decision. You know it is done when every Article 5(2) duty appears once, with an accountable member of the management body and no orphaned items.
Set the reporting cadence
Agree which reports reach the management body, how often, and in what form. Article 5(2) expects reporting channels that cover third-party arrangements, planned material changes and at least major ICT-related incidents with their impact and response. Define a standing ICT risk pack, a third-party arrangements summary, and an incident summary with escalation triggers for major events. Write the cadence into the governance calendar and the terms of reference for the board or its committee. The output is an approved reporting schedule. You know it is done when each channel has a named preparer, a recipient, a frequency and a minute entry showing it was received.
Assign the third-party monitoring role
Article 5(3) asks financial entities other than microenterprises to establish a role that monitors arrangements with ICT third-party service providers, or to designate a senior manager who oversees the related risk exposure and documentation. Decide which option fits the entity's size and structure, then document the mandate, the authority to escalate, and the link to the register of information and exit planning. Confirm the appointee has the skills to read contracts and service reports. The output is a signed role description or senior manager designation, recorded in the governance framework. You know it is done when the appointment is minuted and the monitoring output feeds the reporting schedule from the previous step.
Build the annual approval calendar
Turn the decision register into a dated calendar that places each approval and periodic review at a fixed point in the governance year. Include the policy set, the resilience strategy and risk tolerance, the continuity and response plans, the internal audit plan, and the third-party policy. Align the calendar with the framework review and the budget cycle so that resilience funding is approved in the same governance period. The output is an approved calendar owned by the company secretary or governance lead. You know it is done when each item has an approval date, a reviewer, and a minute reference from the previous cycle, and no mandatory review is left without a slot.
Define the board training plan
Article 5(4) requires members of the management body to keep sufficient up-to-date knowledge and skills to understand and assess ICT risk, including regular specific training commensurate with the risk being managed. Assess each member's current knowledge against the entity's ICT risk profile, then set a training plan that covers threats, third-party concentration, incident handling and the resilience strategy. Decide whether training is delivered internally, by an external provider, or through a learning platform such as Moodle, and record how completion is measured. Ask any provider to confirm the content, the assessment method and the record it will produce. The output is an approved training plan with a named owner. You know it is done when each member has an individual learning record that the governance function can retrieve for review.
Record outputs in a controlled document set
Hold every governance output in one controlled repository with version history, so that an assessor can see what was approved, when, by whom and what changed. Store the approved policy set, the decision register, reporting packs, board minutes, the monitoring role mandate, the approval calendar and the training log. Wiki or document platforms with version control, such as XWiki, and permissions by role, such as BookStack, can hold these records, provided access and retention rules are set and tested. The output is an evidence index that maps each Article 5 duty to its document and minute reference. You know it is done when a reviewer can start from any Article 5 duty and reach the approved record in a few steps.
Test the sequence against an assessor's walkthrough
Before the first formal review, walk through the governance chain as a supervisor would: choose one Article 5 duty, trace it from the decision register to the calendar, the minute, the report and the training record, and check that each link holds. Note gaps such as a decision with no owner, a report with no minute, or a member with no training record, and close them through the governance committee. Confirm with your competent authority or auditor which evidence formats they expect. The output is a signed walkthrough record and a remediation log. You know it is done when the walkthrough completes without a broken trace and each remediation item has an owner and a closure date.

Which evidence proves each governance duty

Minutes are the primary proof that the management body exercised its ultimate responsibility for ICT risk under Article 5(2). They show that ICT risk, resilience strategy and third-party topics were deliberated, challenged and decided. Resolutions form the formal record of what was approved, by whom and on what date.

Agenda items tied to duties: Name ICT risk, resilience strategy, third-party arrangements and incident reporting as separate agenda items so they are visible in the record.
Decisions recorded clearly: State each decision, who proposed it, and the outcome of the vote or consensus.
Challenge and follow-up: Record the questions the board asked, the answers given and the actions assigned, with owners and due dates.
Signed and stored versions: Keep approved minutes in a controlled repository with the signed copy and a clear version history.

Before a review, check that every duty in Article 5(2) has at least one dated minute or resolution in the current cycle, and that sampled minutes record questions asked and answers given.

What meeting Article 5 costs in money and effort

This table breaks down the cost of Article 5 governance into its components, showing who is paid, whether each cost is one-time or recurring, and what drives it up or down. No price or duration is stated because none is set by the Regulation or supplied for this page, so use the table to frame questions for a written quote. The main takeaway is that most of the cost is management time and recurring reporting effort, not software.

Cost component	Who bears or is paid	One-time or recurring	What drives it
Board time for strategy, risk tolerance and policy approval	Management body members (internal time)	Recurring	Number of board members, frequency of review cycles, and how much material each approval requires
Board training on ICT risk	Members of the management body, plus any external training provider	Recurring	Required regular refresher training under Article 5(4), the depth of prior knowledge, and whether training is internal or bought in
Reporting packs on ICT third-party arrangements and major incidents	Risk, security and platform engineering staff (internal effort)	Recurring	Number of ICT providers, incident volume, and how much data must come from manual sources versus automated systems
Building the reporting channels and templates	Engineering, risk and compliance staff, sometimes an implementation partner	One-time, then updated	Current state of inventories and records, the tooling chosen, and how many entities in a group report up
Governance tooling and licenses	Software vendors, or internal teams if self-hosted	Recurring for commercial licenses	Number of users, modules and frameworks required; open-source options can remove license spend but still need hosting and support effort
Designating the third-party monitoring role or senior manager	Staff time, or a hire if a new role is created	Recurring	Size of the ICT provider portfolio, and whether monitoring is carved out for microenterprises
External review of the governance framework	Independent reviewers or consultants paid per written scope	Periodic	Scope agreed in writing, group structure, and whether the review is also used for the annual framework review

Open-source tools that produce governance evidence

Article 5 places ICT risk governance with the management body, and the body must be able to show what it approved, when, and who was trained. The four tools below cover different parts of that record: framework mapping, policy approvals, access to governance documents, and board training completion. Each one needs confirmation against your own environment before you rely on it.

CISO Assistant for DORA assessments

CISO Assistant is an AGPL-3.0-only tool that ships more than 200 frameworks, including DORA, and runs audits and compliance assessments against them with automatic mapping between frameworks. For Article 5, it can hold the records that show management body oversight of ICT risk and the status of each DORA requirement. Confirm that the DORA framework version you load matches the regulatory text your competent authority uses, and check whether the mappings meet your assessor's expectations before you treat them as evidence.

XWiki for approved policy versions

XWiki is an LGPL-2.1-or-later wiki that keeps every change to a page under version control, recording what changed, when and by whom. Users can compare any two versions and roll back to an earlier one. For Article 5, this gives the ICT risk strategy, risk tolerance and business continuity policy a dated approval trail. Confirm that your approval workflow records the board decision separately from the editing history, because a version log alone does not show who had authority to approve.

BookStack for governance access control

BookStack is an MIT-licensed documentation platform where user abilities come from assigned roles, and permissions can be overridden per role at the shelf, book, chapter or page level. For Article 5, this lets you restrict who can edit board-approved governance documents while keeping them readable to the staff who must follow them. Confirm that the permission model separates approvers from editors, and test that an edit by a non-approver is blocked before an assessor asks for the access record.

Moodle for board training records

Moodle is a GPL-3.0-or-later learning platform. Its activity completion feature marks an activity complete for each learner when they view it, receive a grade, or tick it manually, depending on the conditions you set. Article 5(4) requires members of the management body to keep up-to-date knowledge of ICT risk, so this gives you a per-member completion record for the training you assign. Confirm that the completion condition matches the training's intent, since viewing a module does not prove understanding, and keep the training content and its version alongside the record.

Who owns the board duties and who prepares the evidence

The management body owns the decisions that Article 5 names. It approves the digital operational resilience strategy and ICT risk tolerance, approves and periodically reviews the ICT business continuity policy, response and recovery plans and ICT internal audit plans, and allocates budget for resilience, awareness and training. Board members cannot delegate that accountability to a vendor or to a single officer, even when others prepare the material they review.

Approval decisions: Minutes should show the board discussed and approved the strategy, risk tolerance, continuity policy and audit plan, not only received them.
Third-party policy: The board approves and periodically reviews the policy on using ICT third-party services.
Reporting lines: The board must receive reporting on third-party arrangements, planned material changes and at least major ICT-related incidents with their impact and response.
Training: Members must keep current knowledge to assess ICT risk, which the board should plan and record for each member.
Budget: Resilience funding is a board decision that should be visible in annual planning.

Check that board minutes, approval records and training logs name the individuals who made each decision.

Where boards usually fall short on Article 5

Article 5 places ultimate responsibility for ICT risk on the management body, so most gaps trace back to a board that approves documents without the information or authority to oversee them. The cards below cover the gaps assessors and supervisors most often find, each paired with a closing check the board can act on.

Generic training that misses the entity's risk

Article 5(4) asks board members to keep enough current knowledge to understand and assess ICT risk, and the training should be commensurate with the risk the entity actually runs. Off-the-shelf cyber awareness modules often cover phishing and passwords but say nothing about the entity's cloud concentration, its critical providers or its incident history. Check whether the curriculum is built from the entity's own risk register, whether attendance is recorded per director, and whether the training is refreshed when the risk profile changes.

Third-party reporting that never reaches the board

Article 5(2)(i) expects reporting channels that cover third-party arrangements, planned material changes and at least major ICT-related incidents with their impact and response. In many entities, provider risk sits in procurement or IT operations and the board sees only an annual summary. Check that a standing board report lists material ICT providers, open findings, planned changes to critical arrangements and major incidents, and that the minutes show the board discussing them.

Budget approved once and never reviewed

Article 5(2) requires the management body to allocate budget for digital operational resilience, awareness and training. Boards often approve a figure during the annual planning cycle and then have no mechanism to test whether the money was spent on the priorities they accepted. For entities under the simplified regime, Article 28 of Delegated Regulation (EU) 2024/1774 makes an annual budget review explicit. Check that the board receives spend against resilience priorities during the year and records any reallocation.

Monitoring role without documented authority

Article 5(3) requires a role to monitor ICT third-party arrangements, or a senior manager to oversee the related risk and documentation. Entities frequently name a person in an org chart without written terms of reference, access to the register of information, or a right to escalate to the board. The role then cannot show how it monitors anything. Check that the mandate, reporting line, decision rights and required records are written down, approved by the board and tied to the register of information.

Strategy and tolerance approved without metrics

Article 5(2) makes the management body responsible for approving the digital operational resilience strategy and the ICT risk tolerance. Approvals often happen as a single resolution with no measurable indicators attached, so the board cannot later tell whether the tolerance is being respected. Check that each tolerance statement has a metric, a threshold, an owner and a reporting frequency, and that the board sees breaches when they occur rather than at the next annual review.

Continuity and response plans never tested at board level

Article 5(2) requires the management body to approve and periodically review the ICT business continuity policy, response and recovery plans and ICT internal audit plans. Boards often sign these documents but never see them exercised or see audit findings against them. Check that the board receives test results from continuity exercises, knows which internal audit findings remain open, and has a record of the decisions it took after each review.

Questions buyers ask about Article 5 governance

What must the board of directors personally do under DORA Article 5?

The management body carries ultimate responsibility for ICT risk, and that accountability stays with the board even when staff do the work. Under Article 5(2), members must define, approve, oversee and implement the arrangements of the ICT risk management framework. In practice, that means approving the digital operational resilience strategy and ICT risk tolerance, approving and periodically reviewing the ICT business continuity policy, ICT response and recovery plans and ICT internal audit plans, and approving the policy on ICT third-party services. The board must also allocate budget for resilience, awareness programmes and training, and it must receive reporting on third-party arrangements and major ICT-related incidents.

How much effort does Article 5 governance take for a board?

The effort is mostly recurring decision and review time rather than a one-time build. The supplied material gives no hours figure, so ask any adviser for an estimate tied to your own scope. The work includes reading and approving policies and plans, reviewing reports on ICT third-party arrangements and incidents, and completing training under Article 5(4). The main drivers are the number of ICT third-party arrangements, how complex your ICT estate is, how mature your existing reporting is and whether you fall under the simplified regime. When requesting a quote, ask for a list of board decisions and reports expected each year and for the names of the people who prepare the board papers.

Can a small financial firm meet Article 5 without outside help?

A small firm can do this in-house if it has board members with the knowledge and time to make the decisions. Article 5(3) requires a monitoring role for third-party arrangements, but it does not apply to microenterprises. Entities under the simplified regime, which Article 16 describes for small and non-interconnected investment firms and certain exempted payment, e-money and small pension fund entities, face lighter requirements. Even then, Article 28 of Delegated Regulation (EU) 2024/1774 requires the management body to allocate and review, at least once a year, the budget needed for digital operational resilience. Outside help can prepare papers and training material, but the board still makes and records the decisions.

What does an implementation partner do, and what stays with the board?

The organization owns its controls and its decisions. An implementation partner such as DeployOpen can prepare systems, documentation, reporting templates and evidence for board review, and can set up self-hosted tools that keep the records. For example, XWiki keeps version history of policy pages, showing what changed, when and by whom, while BookStack lets you set permissions by role. The board still approves the resilience strategy, risk tolerance, policies and budget, and it reviews the reports. DORA sets no certification scheme. Only an independent auditor or the competent authority assesses compliance, and no implementation partner issues attestations or reports.

How often must the board review ICT risk arrangements under DORA?

Article 5 requires the board to review certain arrangements periodically, but the supplied facts do not set a fixed interval for each one. The board must periodically review the ICT business continuity policy, the ICT response and recovery plans, the ICT internal audit plans and the policy on ICT third-party services. Entities under the simplified regime must review their resilience budget at least once a year under Article 28 of Delegated Regulation (EU) 2024/1774. Set review dates in your own governance calendar and confirm the expected intervals with your competent authority and the technical standards that apply to your entity type.

What will a supervisor ask first about board governance?

Supervisors usually start with evidence that the board owns the framework. Prepare minutes showing approval of the resilience strategy and ICT risk tolerance, the current policy on ICT third-party services with its review date, and the reporting lines covering third-party arrangements, planned material changes and at least major ICT-related incidents with their impact and response. Expect questions about the named role or senior manager who oversees third-party risk and about board training records. Supervision is carried out by the national competent authority for each entity type under Article 46, and by the ECB for significant credit institutions. Confirm the expected format with your authority.

Is board training under DORA mandatory, and how often must it happen?

Yes. Article 5(4) requires each member of the management body to keep sufficient, up-to-date knowledge and skills to understand and assess ICT risk, including by following specific training regularly. The training must be commensurate with the ICT risk the entity manages. The supplied facts do not set a number of hours or a fixed frequency, so ask your advisers and your competent authority what they expect. A practical training plan records who attended, what was covered, when it happened and how it links to the risks the board is deciding on. Self-hosted learning platforms such as Moodle can track completion for each learner if you want that record in your own infrastructure.

How DeployOpen prepares governance evidence

DeployOpen works on Article 5 Governance and organisation as an implementation partner. We help the management body's governance records, reporting lines and board training exist in working systems inside your own infrastructure, while your organisation keeps ownership of every decision and sign-off. Only an independent assessor or the competent authority can judge whether the arrangements meet DORA.

How we scope

Agree a written scope covering the governance documents, reporting lines and board training records in your entity
Confirm which self-hosted platforms will hold approvals, risk reports and training evidence before work starts
Record who inside your organisation owns each approval, review and sign-off in the scope document

How we build

Configure wiki and document workflows so management body approvals and periodic reviews leave a dated record
Set up role-based access so only authorised board and governance staff can approve or edit controlled documents
Connect the ICT third-party monitoring role to a register and reporting view the management body can review

How we hand over

Deliver the governance documentation set with version history, owners and review dates for your compliance team
Provide a written record of configuration, access roles and training tracking so your auditor can trace each element
Train designated staff to run the reporting cycle and keep evidence current after the engagement closes

How we support

Offer ongoing support and upgrades for the governance platforms through a retainer, if your organisation wants continued help
Review governance evidence on a schedule agreed with you so gaps surface before a supervisory request
Confirm with your independent auditor or supervisor which evidence formats they accept before final handover