How to Meet DORA Security Training Obligations in 2026

Before designing any program, you need to understand which clauses create legal obligations. General compliance awareness is not enough. DORA identifies specific articles that govern staff training, and each one creates a distinct requirement.

Article 13(6): the core DORA security training clause every entity must satisfy

Article 13(6) is the primary requirement. Financial entities must develop ICT security awareness programs and digital operational resilience training as compulsory modules in their staff training schemes. Those programs apply to all employees and to senior management, and the level of complexity must be commensurate with each employee's function. A customer service representative and a senior ICT engineer cannot receive the same training content. Complexity must scale with the role.

The word "compulsory" carries significant regulatory weight. Training cannot be optional, self-directed without tracking, or available only on request. It must be embedded in mandatory staff training schemes with verifiable completion records. This is a legal obligation under the Digital Operational Resilience Act, not a best practice your organization can opt out of.

Articles 5(2)(g), 5(4), and 16(1)(h): governance and continuous updates

Article 5(2)(g) requires management bodies to allocate and periodically review an appropriate budget for ICT security awareness programs and digital operational resilience training for all staff. Board-level accountability for the training program's funding is written directly into DORA. If your training budget has not been formally reviewed and approved by leadership, you have a governance gap before you even look at the content.

Article 5(4) creates a separate obligation for senior management: members of the management body must actively keep up to date with sufficient ICT risk knowledge by following specific training on a regular basis, commensurate to the ICT risk being managed.

Article 16(1)(h) makes training a living control: when post-incident analysis or resilience testing reveals new lessons, the training program must be updated accordingly and re-delivered to affected employee groups. One annual refresh is a floor, not a ceiling. Article 19(b) of CDR 2024-1774 adds a specific content requirement alongside the broader Article 13(6) obligation, all staff must be informed about security documentation and reporting channels for anomalous behavior.

The most expensive misunderstanding in DORA training design is assuming this applies only to the IT department. It does not, and regulators check this specifically during inspections.

All employees and senior management: no exceptions

Article 13(6) covers all staff and senior management without carve-outs. In practice, "all employees" means frontline staff, operations, finance, compliance, HR, legal, and customer-facing teams, every person who touches ICT systems or handles information that could be compromised. Senior executives face an additional burden under Article 5(4): they must maintain current ICT risk knowledge through specific, regular training that enables informed governance decisions, not just an annual policy sign-off. For practical awareness and training design notes, see resources on DORA training awareness.

Third-party ICT providers and the Article 30 obligation

Article 30(2)(i) requires financial entities to include ICT third-party service providers in relevant training schemes where appropriate, with that participation documented in the contractual arrangements governing the relationship. This is a frequently missed requirement during program design. Your managed service provider, cloud infrastructure vendor, or SaaS partner may need to be part of your DORA staff awareness program, and the contract needs to say so explicitly. Check your vendor agreements now and confirm whether this clause has been addressed.

Role-based complexity: what it looks like in practice

DORA's "commensurate to the remit of their functions" language maps to three practical implementation tiers:

• Foundational awareness (all employees): phishing recognition, secure behavior basics, password hygiene, and how to report suspicious activity through the correct channels
• Intermediate content (business managers and compliance officers): incident escalation procedures, regulatory obligations relevant to their function, and how to identify third-party risk signals
• Advanced technical training (ICT teams): incident response procedures, threat detection protocols, penetration testing participation, resilience exercise protocols, and security documentation standards

The content must match each person's actual exposure to ICT risk, not just their seniority level. Treat this as a recommended implementation framework aligned with the regulation's commensurate-complexity principle, and cross-reference it against any supervisory guidance issued by your relevant national competent authority. For organizations that already run structured awareness programs, our Security Awareness Training: A Practical Guide | HookPhish explains how to map existing learning objectives to role-based outcomes.

Understanding the obligation is one thing. Executing a program that satisfies it is another. The following framework translates Article 13(6)'s requirements into an executable program structure.

Structuring content by function: what each role actually needs to learn

Start with learning objectives tied to each audience group, not with content assets you already have. ICT staff need to execute incident response procedures, recognize threat indicators, and operate within your organization's security documentation standards. Business managers need to understand escalation paths, recognize third-party risk signals, and know which regulatory obligations apply to their function. All employees need three core outcomes: recognize a phishing attempt, practice secure behavior consistently, and know exactly how to report something suspicious. Senior management needs enough ICT risk literacy to evaluate governance decisions, understand their Article 5(4) obligations, and engage meaningfully with risk reports from the security team. For cross-functional governance considerations that overlap with other regulatory frameworks, see our notes on NIS2 Security Awareness Training & Compliance | HookPhish.

Delivery formats and how often to train

DORA does not prescribe fixed intervals, but EBA and ECB supervisory guidance has established annual training as the minimum floor for all employee groups. High-risk roles, specifically finance, operations, and ICT staff, should train at least quarterly given their elevated exposure to ICT threats. This reflects common supervisory practice and industry guidance rather than an explicit legal interval, so verify the current position of your relevant competent authority. Post-incident and post-test training updates are mandatory under Article 16(1)(h), which means your program needs a formal review trigger built into the incident management process, not just an annual calendar reminder. For example, many vendors and training providers outline practical staff training cadences in their DORA compliance staff training materials and checklists.

Accepted delivery formats include LMS-delivered prerecorded modules, live instructor-led sessions (in-person or online), and interactive scenario-based exercises such as phishing simulations and tabletop drills. New hires should complete role-based training before gaining production access. The sequence matters: access should follow completion, not precede it.

This is where most organizations expose themselves during inspections. Supervisors do not accept attendance screenshots, email confirmations, or aggregate completion percentages. They want individual-level, verifiable documentation proving each employee actually completed the required training.

The five documentation types auditors expect

Regulators conducting on-site inspections under Article 50 look for five categories of evidence:

• Training curriculum and materials that document the content covered and its explicit alignment with DORA requirements, including complexity level by role
• Per-employee attendance records with timestamps showing when each person completed each module
• Assessment results and quiz scores demonstrating knowledge retention, not just participation
• Competency certifications or signed acknowledgments confirming the employee understood and accepted the material
• Effectiveness metrics such as phishing simulation failure rates before and after training, showing measurable behavior change over time

Each of these must be retained, accessible, and ready for review at any point, not assembled on short notice before a supervisory visit. Retention duration should align with your national framework's requirements; confirm the applicable period with your legal and compliance teams.

Why timestamp-level records matter more than aggregate reports

A training completion percentage at the department level does not satisfy DORA's evidence standard. Regulators expect individual-level records showing when each employee completed each module, what version of the content they consumed, and what their assessment score was. Content version history matters equally: if you updated a phishing recognition module after a major incident or regulatory change, that update log must be retained and re-delivery to affected employees must be documented.

Platforms that generate exportable, per-employee training records remove significant audit friction at this stage. HookPhish produces timestamped completion records, role-based training documentation, and exportable compliance reports aligned with DORA's evidence requirements. When a supervisor walks in with a document request, the evidence is already organized rather than something your team has to reconstruct under pressure. For additional industry perspectives on implementing DORA-aligned evidence collection and program metrics, see specialist guides such as the DORA compliance staff training overview and practical vendor checklists.

DORA treats training as a continuous control, not a one-time checkbox. The regulation's emphasis on post-incident updates and regular repetition means your program must be actively maintained between formal audits.

Updating content after incidents and resilience tests

Article 16(1)(h) creates a direct operational obligation: when post-incident analysis or resilience testing reveals new lessons, the training program must be updated and re-delivered to relevant employee groups. Build a documented review process into your incident management workflow. After each major incident or resilience exercise, a designated owner reviews the training content, identifies modules that need updating, revises them with version control, and logs the re-delivery to affected groups. That update log becomes part of your audit trail, demonstrating that training is a living control rather than a static document. For a practical compliance-focused explanation of DORA's requirements and implementation steps, consult a detailed DORA compliance guide.

Metrics that prove the program is working

Supervisors expect effectiveness evidence alongside delivery evidence. Phishing simulation click-rate trends over time demonstrate actual behavior change rather than passive content consumption. Assessment score progression across cohorts, incident reporting rates from employees, and third-party training participation rates all contribute to a picture of a functioning program. Document these metrics on a regular cadence and tie them to employee risk profiles. A program showing measurable behavior improvement over 12 months is far more defensible during a supervisory review than one that can only confirm training was scheduled. If you need a pragmatic DORA compliance guide to structure these metrics, see the DORA compliance guide for further reading.

Four things you can act on immediately: identify which DORA articles create binding training obligations for your organization; design a role-based program with the right complexity for each employee group; choose delivery formats and frequencies that align with supervisory expectations; and build an evidence trail that holds up during an on-site inspection.

DORA's core intent is resilience, not paperwork. A well-documented training program is evidence of a workforce that can recognize ICT threats, report them correctly, and respond effectively when it matters. The documentation is how you prove to a regulator that the resilience is real. For concise procedural steps and recommended controls to maintain compliance, see external summaries of key DORA implementation steps.

If your organization needs to close the evidence gap, HookPhish provides role-based training modules, AI-driven phishing simulations, and exportable compliance records for financial entities operating under DORA. Per-employee completion records and phishing behavior metrics are generated automatically as your program runs. Implementing a structured DORA security training program and maintaining an exportable audit trail is how you pass supervisory reviews, and how you demonstrate that your workforce is genuinely prepared, not just trained on paper. See how HookPhish supports DORA compliance and start building an evidence trail that holds up under scrutiny.