{"id":57048,"date":"2025-12-10T15:02:14","date_gmt":"2025-12-10T14:02:14","guid":{"rendered":"https:\/\/setterwalls.se\/?post_type=articles&p=57048"},"modified":"2025-12-10T15:02:14","modified_gmt":"2025-12-10T14:02:14","slug":"back-to-school-from-classroom-to-boardroom-a-practical-guide-to-digital-operational-resilience-training-under-dora","status":"publish","type":"articles","link":"https:\/\/setterwalls.se\/en\/article\/back-to-school-from-classroom-to-boardroom-a-practical-guide-to-digital-operational-resilience-training-under-dora\/","title":{"rendered":"Back to School – From Classroom to Boardroom, a Practical Guide to Digital Operational Resilience Training under DORA"},"content":{"rendered":"
\n
\n
\n
\n
\n

Introduction<\/strong><\/p>\n

As part of the EU\u00b4s Digital Decade strategy, the EU adopted the Digital Operational Resilience Act (\u201cDORA<\/strong>\u201d) on the 17th<\/sup> of January 2025. DORA aims to strengthen cybersecurity within the financial sector and turned \u201cdigital resilience\u201d from a boardroom buzzword, into everyday practice for financial entities within the EU.<\/em><\/p>\n

The need for DORA is rooted in the rapid digitalization of our society and the growing number risks and threats connected to the use of Information and Communication Technology (\u201cICT<\/strong>\u201d). DORA aims to combat these threats and risks with inter alia mandatory hands-on operational resilience training. As such, it is time for all staff, management, and, where appropriate, ICT third-party service providers of DORA-entities to go back to (cybersecurity-)school and learn a thing or two about operational resilience. <\/em><\/p>\n

If you are a DORA entity struggling to understand what this all means, this article is for you. <\/em><\/p>\n

No One-Size fits all <\/strong><\/p>\n

DORA Article 13(6) requires financial entities to embed digital operational resilience training as compulsory modules (no opt-outs) within staff training programmes across all levels of the organisation. The content should be tailored to the role and responsibilities of each audience. While certain core topics will be relevant to everyone with access to ICT systems, the depth and specificity of training must reflect the functions and risk exposure of different staff groups\u2014because jobs differ and so should training<\/strong>.<\/p>\n

In practice, personnel with elevated privileges\u2014such as IT administrators and senior management with privileged system access\u2014should receive more advanced instruction, for example on the fun (and sensitive) stuff: secure authentication mechanisms and privileged access management. By contrast, staff with limited data access should receive foundational training that covers password hygiene, multi-factor authentication, phishing awareness, and general security practices\u2014the basics we all know and occasionally forget. The objective is to align training intensity with potential impact on the organisation\u2019s ICT environment.<\/p>\n

Training must also be proportionate and risk-based\u2014no need for heroics for low-risk, no half-measures for high-risk. Entities facing higher inherent or residual risk are expected to design and deliver more sophisticated and frequent training, whereas entities with lower exposure may reasonably implement a lighter programme. Traceability is critical: document the rationale, design decisions, delivery, attendance, assessment results, and continuous improvement measures to demonstrate how the training architecture aligns with your entity\u2019s risk profile and evolving threat landscape. If it isn\u2019t documented, it didn\u2019t happen<\/strong>.<\/p>\n

There is no one-size-fits-all training blueprint\u2014and that\u2019s a feature, not a bug. Each entity should calibrate its curriculum to its organisational structure, technology stack, risk appetite, and regulatory obligations. The following steps is one way to operationalise this in practice, accompanied by practical considerations to support implementation and ongoing compliance. Your mileage may vary.<\/p>\n

Step One \u2013 Who\u2019s on the hook? Map your people before you train them<\/em><\/strong><\/p>\n

Once you\u2019ve acknowledged your status as a DORA-regulated entity with a duty to implement training, start by charting the landscape of your staff and ICT third-party service providers across your organisation.<\/p>\n

The goal is simple: identify exactly who must be in scope for training<\/strong>. In a compact organisation, this may be refreshingly straightforward. In a sprawling group with multiple business lines and a thicket of outsourcing arrangements, it can be more of a treasure hunt\u2014so be systematic, thorough, and a little ruthless about who needs to be included.<\/p>\n

Step Two \u2013 Map your people to your cyber risks<\/em><\/strong><\/p>\n

In step two, line up your mapped staff populations against the ICT risks you\u2019ve actually identified\u2014no guesswork, just evidence.<\/p>\n

Start with the obvious cross\u2011cutting scenarios: credential theft, phishing, and business email compromise. If someone has an email account tied to internal systems, they\u2019re a phishing target. If they\u2019ve got remote access or privileged rights, they\u2019re a higher\u2011risk target. And if they help run a critical or important function, they need scenario\u2011based training that tracks to continuity and recovery expectations\u2014because when things wobble, they\u2019ll be holding the steering wheel.<\/p>\n

Keep it simple at first. Set a baseline curriculum for everyone<\/strong> that covers cyber hygiene fundamentals, secure data handling, and internal reporting and comms protocols. Then layer<\/strong> on role\u2011specific modules for the higher\u2011risk cohorts\u2014privileged users, remote workers, and operators of critical processes. The result is training that\u2019s right\u2011sized, risk\u2011aligned, and frankly more effective than death\u2011by\u2011slides.<\/p>\n

Step Three \u2013 Train your ICT third\u2011party service provider, and perhaps re<\/em><\/strong>\u2011<\/em><\/strong>write the fine print<\/em><\/strong><\/p>\n

Where it makes sense, bring your ICT third\u2011party service provider into the school room\u2014and make sure your contracts say that they will have to show-up and take notes.<\/p>\n

In line with step two, map ICT risk to each ICT third\u2011party service provider by zeroing in on services that underpin critical or important functions, involve privileged access, or are delivered on\u2011premises. If the current agreements don\u2019t oblige ICT third\u2011party service provider to receive the right training for the risks they introduce, then it\u2019s time to sharpen your pencil and renegotiate. Better training, better resilience, fewer surprises.<\/p>\n

Step Four \u2013 It doesn\u2019t have to be boring<\/em><\/strong><\/p>\n

DORA doesn\u2019t prescribe the format or delivery of training, which is both a blessing and a trap. You can stick to slide decks if you must, but relying solely on PowerPoint is a quick way to lose the room. A smarter approach and a better success (from what we have seen from our work with clients) is to treat the slides as the spine\u2014not the whole body\u2014and layer in activities that get people thinking, clicking, and actually doing.<\/p>\n

Start with short, sharp decks to set the scene and reinforce the \u201cwhy,\u201d then blend in practical, real-world exercises that mirror your risk profile and operating model. Aim for sessions that feel like they matter on Monday morning, not just on compliance reporting day. For example, you might weave in the following to bring the material to life and build muscle memory across the business and the management body:<\/p>\n

    \n
  • Phishing simulations delivered via email campaigns that escalate in sophistication over time, with tailored feedback for individuals and teams.<\/li>\n
  • Hands\u2011on incident response exercises aligned to your established playbooks, so the incident response team practices roles, decision points, and communications under time pressure.<\/li>\n
  • Structured walkthroughs of ICT response and recovery plans that surface dependencies, RTO\/RPO assumptions, and who does what when the lights flicker.<\/li>\n
  • Mandatory knowledge checks for management bodies focusing squarely on governance duties, escalation thresholds, and accountability under DORA.<\/li>\n<\/ul>\n

    The result is a programme that doesn\u2019t just tick the regulatory box\u2014it strengthens operational resilience, sharpens decision\u2011making, and nudges behaviours in the right direction. If attendees leave with a few hard lessons, a couple of good questions, and a clear sense of ownership, you\u2019ve done it right.<\/p>\n

    Step Five \u2013 Close the loop<\/em><\/strong><\/p>\n

    Now it is time to close the loop. Document your training programme comprehensively and define clear indicators to measure its effectiveness. Integrate lessons learned from actual incidents and insights from testing into the curriculum to ensure continuous improvement. By regularly updating and evolving the training, you will remain aligned with the latest cybersecurity practices.<\/p>\n

    DORA compliance is not a one\u2011off exercise: training must be delivered on a recurring basis to keep knowledge current and capabilities sharp at all times.<\/p>\n

    Ending Comment<\/strong><\/p>\n

    An effective training programme is proportionate, risk\u2011based, role\u2011specific, and continuously refined in response to incidents, testing outcomes, and technological change.<\/p>\n

    By mapping people to the risks they face, developing engaging, relevant content, and incorporating ICT third\u2011party service provider where appropriate, you lay the groundwork for a robust, bespoke training framework. Done well, this approach drives meaningful behavioural change where it matters most.<\/p>\n <\/div>\n <\/div>\n <\/div>\n <\/div>\n <\/section>\n","protected":false},"excerpt":{"rendered":"","protected":false},"author":14,"featured_media":50290,"template":"","meta":{"_acf_changed":true,"_seopress_robots_primary_cat":"","_seopress_titles_title":"","_seopress_titles_desc":"","_seopress_robots_index":""},"article_category":[1056],"class_list":["post-57048","articles","type-articles","status-publish","has-post-thumbnail","hentry","article_category-fintech-en"],"acf":[],"_links":{"self":[{"href":"https:\/\/setterwalls.se\/en\/wp-json\/wp\/v2\/articles\/57048","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/setterwalls.se\/en\/wp-json\/wp\/v2\/articles"}],"about":[{"href":"https:\/\/setterwalls.se\/en\/wp-json\/wp\/v2\/types\/articles"}],"author":[{"embeddable":true,"href":"https:\/\/setterwalls.se\/en\/wp-json\/wp\/v2\/users\/14"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/setterwalls.se\/en\/wp-json\/wp\/v2\/media\/50290"}],"wp:attachment":[{"href":"https:\/\/setterwalls.se\/en\/wp-json\/wp\/v2\/media?parent=57048"}],"wp:term":[{"taxonomy":"article_category","embeddable":true,"href":"https:\/\/setterwalls.se\/en\/wp-json\/wp\/v2\/article_category?post=57048"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}