DORA management body responsibilities and ICT risk training

Under DORA, board training is not optional housekeeping. 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, and it expects this to be maintained through specific training followed regularly, scaled to the ICT risk the entity actually runs. For a board that approves the resilience strategy, risk tolerance and budget, this means a documented plan, not a single induction session. The training should cover the entity's own ICT architecture, its critical or important functions, the major incident and reporting obligations it faces, and its exposure to key ICT third-party providers, including any self-hosted open-source platforms it depends on. Each member should be able to explain, in plain terms, what the board is approving when it signs off a plan.

Article 13(6) adds a second layer. ICT security awareness programmes and digital operational resilience training must be compulsory modules for all employees and senior management, and ICT third-party service providers are included where appropriate under Article 30(2)(i). Senior management and the board overlap heavily here, so the board's module should be a separate, deeper track rather than the same slide deck given to staff. Decide which third-party personnel (for example, implementation partners with administrative access) must complete the modules, and write that decision into the contract. Ask your competent authority what training frequency, format and minimum content it expects, because DORA sets the principle and supervisors apply it in practice. Confirm the expectation in writing before you design the programme.

Record evidence for every session: the date, the agenda or module content, the attendees, the trainer, and the outcome, such as a short assessment or a documented board discussion of the risks raised. Supervisors will ask whether members can assess ICT risk, and attendance records alone rarely answer that question. Keep the training plan under the same approval cycle as the rest of the ICT governance documents, so the board reviews its own development needs at least as often as it reviews the framework. Budget for this work as a recurring cost: content updates when systems or regulations change, trainer fees or internal time, and assessment administration. Ask any external training provider for a written scope listing the modules, delivery format, assessment method and how content is refreshed.

The management body owns every DORA decision in this area, and it must be able to show that it made them. Under Article 5(2) of Regulation (EU) 2022/2554, the board defines, approves, oversees and implements the ICT risk management arrangements, and it carries ultimate responsibility for ICT risk. In practice that means the minutes or written resolutions must record approval of the resilience strategy, the ICT risk tolerance, the business continuity and response and recovery plans, the internal audit plan, the third-party use policy and the budget for resilience, awareness and training. Before the meeting, confirm which director holds each item, what paper the board received and whether the resolution names the approval date that the ICT security policies must state under Article 2 of Delegated Regulation (EU) 2024/1774.

Internal staff carry the preparation work. The CISO or head of ICT risk typically drafts the papers, the compliance function tracks the action log, and the company secretary or governance team keeps the record of decisions and training completion. Board members also need their own documented knowledge under Article 5(4), so training records should show each director's attendance and the topics covered. An implementation partner such as DeployOpen can help prepare system documentation, reporting packs for the board, and training materials that reflect the organization's own platforms and third-party arrangements. Those outputs are inputs to the board's work, not substitutes for it. Hiring DeployOpen does not transfer board accountability, and DeployOpen does not issue reports, attestations or certifications.

Supervision and assurance sit with others. Only the competent authority supervises compliance, using the powers in Article 50, and penalties can reach individual members of the management body under national law as set out in Article 50(5). Where an outside view is needed, an independent auditor or assessor produces the report, and the scope of that work should be agreed in writing before it starts. Confirm with your competent authority which evidence it expects the board to hold, and ask any prospective adviser to name exactly which deliverables they will hand over and which they will not.

Start by asking any consultant or training provider to map each board duty to the article that creates it. Under Article 5(2), the management body must approve and periodically review the digital operational resilience strategy, the ICT business continuity policy, the response and recovery plans and the ICT internal audit plans, and it must allocate budget for resilience and training. A credible provider will show you where each of those duties appears in your own governance documents, which board paper or minute evidences it, and who on your side owns the decision. If the answer is a generic slide deck covering all of DORA, the provider has not done the mapping. Ask for the mapping in writing before any work starts, and ask them to flag where your entity's obligations differ because of its type or size.

The second check is whether the board ends up owning its own decisions. Risk tolerance, the choice of ICT third-party arrangements and the acceptance of residual risk are judgments the management body must make and minute. A provider can prepare options, draft the papers and explain the trade-offs, but the board should be able to show it understood and chose. Ask who writes the first draft of each board paper, who presents it, and whether the board receives a decision record it can later hand to a supervisor. For the training required under Article 5(4) and Article 13(6), ask for course content tied to your own risk profile, plus a way to test whether members can apply it. Training that ends with a certificate of attendance alone does not show that members can assess ICT risk.

Third, ask how the provider keeps independence from audit work. The internal audit of the ICT risk management framework is a separate activity that should be performed by people independent of the function they review. If the same firm designs your board training, writes your framework and then audits it, you lose the separation your supervisor will expect. Ask whether the provider will commit in the written scope not to act as your internal auditor or your independent assessor, and which party is responsible for each deliverable. Fixed-scope engagements, with scope, deliverables and timelines agreed in writing before work starts, are the usual basis for this kind of work and make these boundaries easier to enforce. Finally, confirm what you receive at the end: editable board papers, the mapping, training materials, the decision records and a handover session, so that the knowledge stays with your organization when the engagement closes.