DORA Staff Training Requirements: What Financial Services Firms Must Do
DORA staff training requirements explained: Articles 5, 13, and 30 obligations, who needs training, and how to build audit-ready evidence.
The Digital Operational Resilience Act has been enforceable since 17 January 2025. That date was not a starting gun — it was a deadline. Financial entities across the EU are now expected to have functioning ICT risk management frameworks in place, including training programmes that cover all relevant staff.
Yet a significant number of organisations are still treating DORA training as a future concern, or as something that applies only to their technology teams. Both assumptions create exposure. DORA's training requirements are broader than many compliance teams initially expected, and the enforcement machinery is already active.
This article sets out what the regulation actually requires, who it applies to, and what a defensible training programme looks like in practice.
The Three Articles That Create Training Obligations
DORA's training requirements do not sit in a single article. They are distributed across three interconnected provisions, each addressing a different layer of the organisation.
Article 5: ICT Risk Management Governance establishes that the management body — the board, executive committee, or equivalent — bears ultimate responsibility for the ICT risk management framework. This is not a delegation point. Article 5(4) specifically requires members of the management body to "actively keep up to date with sufficient knowledge and skills to understand and assess ICT risk." They are also required to "follow specific training commensurate with the ICT risks being managed."
This is a personal obligation. It attaches to individual directors and senior executives, not to the compliance function as an abstraction. If a supervisory authority examines your governance arrangements and finds that board members cannot demonstrate adequate understanding of ICT risk, the gap sits with those individuals and with the organisation's governance framework.
Article 13: Learning and Evolving addresses the broader workforce. It requires financial entities to establish ICT security awareness programmes and digital operational resilience training as "compulsory modules" in staff training schemes. The article specifies that these programmes must be "applicable to all employees and to senior management staff." It also requires that training be proportionate — calibrated to the role, the function, and the level of ICT risk exposure.
Article 13 is where the "all staff" obligation lives. This is not a recommendation. The directive uses the language of compulsion, and it explicitly extends beyond IT.
Article 30: Key Contractual Provisions deals with third-party ICT service providers. Among the requirements for contractual arrangements with critical providers, the regulation expects financial entities to ensure that relevant staff understand the risks associated with outsourced ICT services. This creates an indirect training obligation: your people need to understand the third-party risk framework well enough to manage vendor relationships in line with DORA's expectations.
Together, these three articles create a layered training architecture. The board must be trained on ICT risk governance. All staff must receive awareness and resilience training proportionate to their roles. And anyone involved in vendor management must understand the third-party risk framework.
Who Needs Training (and Why It Is Not Just IT)
The most common misunderstanding about DORA training is that it is a technology team obligation. It is not. The regulation is explicit on this point, and the logic is straightforward once you consider what digital operational resilience actually means.
A ransomware attack does not only affect the IT department. It affects operations teams who cannot process transactions, customer-facing staff who cannot access client records, compliance officers who must determine whether a regulatory notification is required, HR teams who must manage workforce disruption, and finance teams whose reporting systems are offline.
DORA recognises this reality. Digital operational resilience is an organisational capability, not a technical one. The training requirements reflect that.
In practical terms, the following groups are in scope:
The management body — board members, executive directors, and equivalent governance roles. Their obligation under Article 5 is individual and non-delegable.
IT and security teams — the most obvious audience, but the training they need under DORA is not generic cybersecurity certification. It is specific to the DORA framework: ICT risk management, incident classification and reporting, resilience testing, and third-party oversight.
Operations and business continuity staff — anyone involved in maintaining critical business functions during ICT disruption. DORA's emphasis on operational resilience means these teams need to understand the framework, not just their own continuity plans.
Compliance and risk functions — staff responsible for regulatory reporting, risk assessment, and supervisory engagement. They need to understand DORA's reporting timelines, classification criteria, and the interaction between ICT risk and broader operational risk.
Procurement and vendor management — anyone involved in selecting, contracting with, or overseeing ICT third-party providers. Article 30 obligations flow through these roles.
All remaining employees — the Article 13 awareness obligation applies to everyone. The depth and specificity will vary by role, but no function is exempt from the requirement to receive ICT security awareness and digital operational resilience training.
What "Digital Operational Resilience" Training Actually Looks Like
DORA does not prescribe a specific training format, curriculum, or delivery method. It sets outcome standards and leaves the methodology to the organisation. This is deliberate — the regulation applies to entities ranging from large universal banks to small payment institutions, and a one-size-fits-all programme would be inappropriate.
What the regulation does require is that training produces demonstrable competence relative to the individual's role and risk exposure. For practical purposes, that means a training programme should cover the following domains, adjusted for audience:
ICT risk management fundamentals. What the DORA framework requires, how it differs from existing operational risk frameworks, and what it means for the organisation's governance structure. This is relevant for all staff at varying depths — executives need governance-level understanding, operational staff need awareness of how ICT risk management affects their daily work.
Incident identification and reporting. DORA introduces specific incident classification criteria and reporting timelines (initial notification within four hours of classification, intermediate report within 72 hours, final report within one month). Staff across the organisation need to understand what constitutes a reportable incident and what their role is in the reporting chain. A delayed report because a non-technical employee did not recognise an incident as reportable is an organisational failure, not an individual one.
Third-party ICT risk. How the organisation manages vendor relationships, what the contractual requirements are, and how to escalate concerns about third-party performance or resilience. This applies well beyond procurement — any team that depends on an outsourced ICT service needs a working understanding of the risk framework.
Business continuity and resilience testing. What the organisation's resilience testing programme involves, what role each function plays in testing scenarios, and how test results feed back into the risk management framework.
Threat-led penetration testing (TLPT). For entities subject to advanced testing requirements, relevant staff need to understand the testing methodology, their role in supporting tests, and how findings translate into remediation actions.
The key principle is proportionality. A board member's training should focus on governance responsibilities, risk oversight, and supervisory engagement. A branch operations manager's training should focus on incident recognition, business continuity, and escalation procedures. Both are DORA training. Neither is reducible to a single awareness module.
Building Evidence for Regulatory Audits
Training that cannot be evidenced is, for regulatory purposes, training that did not happen. This is a practical reality that organisations routinely underestimate.
The European Central Bank, national competent authorities, and the European Supervisory Authorities (EBA, ESMA, EIOPA) all have supervisory mandates under DORA. When they examine an organisation's ICT risk management framework, training evidence will be part of the assessment. The question is not whether you ran a programme. It is whether you can demonstrate that the programme produced the required competence.
A defensible evidence base includes several elements:
Training records with role attribution. Not just a list of completions, but records that show which training was delivered to which roles, and how the content was calibrated to the individual's DORA-relevant responsibilities. A generic completion certificate that does not distinguish between a board member and a junior analyst is weak evidence.
Assessment data that tests application, not just recall. Multiple-choice quizzes measure whether someone read the material. Scenario-based assessments — where learners must make decisions in realistic situations — measure whether they can use it. Article 5's requirement that management bodies "understand and assess ICT risk" is an application standard, not a recall standard.
Regularity and currency. One-off training events, however thorough, do not satisfy an ongoing obligation. DORA requires that training programmes be maintained and updated. Evidence should show a recurring cadence — not annual refreshers of the same content, but evolving programmes that reflect the current threat landscape and regulatory developments.
Coverage documentation. Evidence that all in-scope staff received training proportionate to their role. Gaps in coverage — functions or seniority levels that were missed — are the most straightforward finding for a supervisor to identify and the hardest to defend.
Feedback loops. Records showing that training outcomes informed the ICT risk management framework. If scenario-based training revealed that staff consistently misjudged incident classification thresholds, that finding should appear in risk committee minutes and in subsequent training revisions. This demonstrates a learning organisation, not just a compliant one.
The difference between a compliance exercise and a genuine resilience programme often comes down to this evidence layer. Organisations that treat training as a checkbox produce certificates. Organisations that treat it as a governance function produce decision logs, competence assessments, and documented improvements. Supervisors can tell the difference.
DORA Is Already Enforceable — What That Means Now
There is no transition period remaining. DORA entered into force on 16 January 2023, with a two-year implementation period that ended on 17 January 2025. Financial entities are now expected to be compliant, and supervisory authorities have the power to examine and enforce.
In practical terms, this means:
Supervisory examinations are active. The ECB and national competent authorities are incorporating DORA into their supervisory review processes. ICT risk management, including training arrangements, is within scope of ongoing supervision.
Incident reporting obligations are live. If a major ICT incident occurs today and your staff cannot correctly classify and report it within the required timelines because they have not been trained, that is a compliance failure with immediate consequences.
Third-party register requirements are in effect. The register of ICT third-party arrangements (required under Article 28) is a live obligation. Staff involved in vendor management need to understand these requirements now, not at some future implementation date.
Proportionality works both ways. Supervisors will apply proportionality when assessing compliance — a small payment institution is not held to the same standard as a G-SIB. But proportionality does not mean exemption. Every in-scope entity needs a training programme that is proportionate to its size, risk profile, and the complexity of its ICT arrangements.
The organisations that will navigate this period most comfortably are those that started building their training programmes during the implementation period and can now demonstrate an established, documented, evolving programme. Those that are starting now are not in an impossible position, but they need to move with purpose.
Getting Started Without Overcomplicating It
Building a DORA training programme does not require reinventing your entire learning infrastructure. It requires being deliberate about four things: who needs what training, at what depth, on what cadence, and with what evidence.
Start by mapping your DORA-relevant roles against the training domains described above. Identify where your existing programmes already cover relevant content and where the gaps are. The gap analysis will likely show that your IT security training covers some technical ground but does not address DORA-specific governance, incident reporting, or third-party risk in sufficient depth — and that non-technical staff have received little or no relevant training.
For the management body, the priority is training that addresses the Article 5 governance obligation directly. This should be specific to DORA, focused on ICT risk oversight responsibilities, and delivered in a format that produces competence evidence, not just completion records. The NIS2 training comparison we published recently examines why format matters for board-level regulatory training — the same logic applies to DORA.
For all-staff training, the Article 13 obligation can be met through a proportionate programme that scales with role complexity. Awareness-level training for lower-risk roles, applied scenario training for roles with direct DORA responsibilities. The important thing is coverage and documentation.
The DORA compliance training programme we have built at Blend covers the full scope of these obligations — from board-level governance scenarios to operational staff awareness modules — using scenario-based approaches that produce the kind of decision-level evidence supervisors are looking for. It is designed to be deployed across the organisation with role-appropriate learning paths.
If you want to understand where your current training arrangements sit against DORA's requirements before committing to a specific programme, the compliance training diagnostic gives you a structured view of your gaps in about two minutes.
DORA's training requirements are broad, but they are not ambiguous. The regulation tells you who needs training, what competence standard it must reach, and that it must be proportionate and ongoing. The organisations that treat this as a governance priority rather than a procurement task will find the compliance burden lighter and the resilience benefit real.