By Tanguy Duthion
·
May 23, 2026
If I had to sum up this article in one idea: for DORA, training SaaS teams is not enough; you also need to prove who was trained, on what, when, and after which incidents.
I would keep five simple points in mind:
One fact stands out clearly: 63% of the security incidents cited in the article stem from SaaS configuration errors. So if I provide training without addressing access, permissions, integrations, and off-process usage, I miss the risk.
Here is the simplest starting point:
| Topic | What I need to do |
|---|---|
| Scope | Map SaaS applications, including Shadow IT |
| Audiences | Separate content according to roles |
| Frequency | At onboarding, every year, then after an incident |
| Measurement | Track completion, scores, simulations, and effects on controls |
| Evidence | Archive registers, results, versions, reviews, and exceptions |
In practical terms, this article shows how to turn DORA text into a short, targeted, and traceable awareness programme.
DORA does not only require rules on paper. The text imposes behaviours, decisions, and evidence. In the field, the right question is therefore not “what does the regulation say?” but rather: who trains whom, on which topic, and with what record? The idea is simple: convert these obligations into training modules linked to each role.
The first level of training is aimed at decision-makers. That makes sense: when governance fails, everything else follows.
DORA Article 5 places digital resilience under the direct responsibility of the management body. In plain terms, leaders must approve the ICT risk management framework. They must also take responsibility for supervising and approving that ICT risk framework.
At this level, training covers Shadow IT mapping, the identification of critical functions, and dependencies on SaaS providers. And simply having “raised awareness” is not enough. You need to keep concrete evidence: attestations, approved policies, and management meeting minutes.
Awareness training must remain very practical. The goal is not to run through generic material once a year. People need to learn how to recognise phishing, spot Shadow IT, know when to escalate an incident, and then reuse every incident in the next session. In other words, training must evolve with what happens in the field.
It must also turn the requirements of Article 13(6) into clear instructions for users and providers.
In a SaaS environment, the third-party perimeter is often underestimated. It is a classic blind spot. Yet DORA requires critical SaaS providers to be included in the awareness process, especially regarding DORA contractual clauses and cooperation requirements in the event of an incident.
To move from an obligation to a programme, the simplest approach is to link each DORA pillar to a training objective and retained evidence:
| DORA pillar | Training objective | Expected evidence / artefact |
|---|---|---|
| ICT risk management | Asset-mapping workshops and decision-making scenarios | Updated asset register |
| Incident reporting and resilience testing | Incident triage and classification; scenario-based simulations | Incident logs, test reports, and remediation plans |
| Third-party risk | DORA clauses and third-party cooperation | DORA contract addenda |
| Information sharing | Use of the TLP protocol for threat intelligence | Participation in sharing networks (ISACs) |
This foundation can then be adjusted to each audience.
DORA requires role-based training with documented and traceable elements. Once the DORA obligations have been set out, they must be converted into separate content for each audience. The idea is simple: each group should receive the training that matches its tasks, and the organisation must be able to prove it. If the programme is reviewed, it must show that everyone received what they needed to fulfil their control responsibilities.
Leaders must be able to justify accepted SaaS risks, budget choices, and remediation decisions. This is not vague. The expected evidence is very concrete: agendas for dedicated sessions, signed policies, and committee minutes.
For IT, security, and compliance teams, the technical depth needs to go further. They must master incident qualification, classification, and notification within DORA deadlines - 4 hours and then 72 hours - as well as logging, log retention, and third-party provider monitoring. Theory is not enough. Use scenarios close to the field: a shared administrator account bypassing MFA, logs kept for only seven days, or a provider outage affecting a critical business service.
Business users need clear, simple, actionable instructions. Which tools are authorised? How should sensitive data be handled? How can phishing be identified? When should an issue be escalated? For example, as soon as a tool processes regulated data, lacks clear identity controls, or was purchased outside the approved process.
Application owners, for their part, need to understand their role as custodians. They must keep an up-to-date inventory of the SaaS in use, assess business criticality, validate data flows, and declare every new integration. In practice, they are often the first people to see a dependency emerging.
Procurement teams need training on DORA contractual control points: security obligations, incident notification, subcontracting, data location, audit rights, and service continuity. This training must be embedded in the process, not handled separately. In other words: what to check before buying, connecting, sharing, or approving.
The table below summarises the required training level, risks, and expected evidence for each audience.
| Audience | Main risks | Required depth | Delivery format | Evidence to retain |
|---|---|---|---|---|
| Leaders (board, C-level) | Personal accountability, regulatory sanctions, service interruption | Strategic: risk appetite, governance, priority approval | Short briefings, governance simulations | Agendas, signed policies, committee minutes |
| IT, security, compliance | Detection failure, poor evidence management, missed reporting deadlines | Technical: incident triage, logging, third-party monitoring, evidence management | Workshops, tabletop exercises, guided incident reviews | Incident reports, test results, log configurations |
| Business users | Shadow IT, data leakage, phishing, poor access management | Operational: authorised tools, data handling, escalation paths | Microlearning, phishing simulations, contextual nudges | Completion rates, assessment results |
| Application owners | Unmapped dependencies, failure to meet RTO/RPO, undeclared integrations | Functional: SaaS inventory, business criticality, data flows | One-to-one workshops, inventory reviews | Updated asset register, criticality classification |
| Procurement | Contractual gaps, concentration risk, lack of audit rights | Legal/commercial: key contractual clauses, exit plans, subcontracting | Process training, contract reviews | DORA-compliant contracts, supplier risk assessments |
The next step is to set the timetable, tracking indicators, and evidence to archive.
Once the content has been defined for each audience, you need to decide when it is delivered and how you will retain evidence of it.
At onboarding, every employee whose role involves a SaaS tool should complete their training before accessing production systems. In practice, this means completion during the first month, with a role-appropriate module - business user, application owner, or IT team - and a timestamped record in the learning management system. This is a prerequisite, not a box-ticking exercise.
Refresher training is annual for everyone, with a more frequent cadence for IT, security, compliance, SaaS governance, and procurement.
After an incident or failed control, DORA requires lessons learned to be incorporated into awareness programmes.[1][2][3][4] In practice, plan a targeted session for the teams concerned within 4 to 6 weeks of the post-incident review. Then update the modules and require the relevant roles to complete them again.[1][2][3]
Leaders must also be trained. Schedule an annual briefing on DORA obligations, SaaS risks, and significant incidents around governance cycles, such as approval of the ICT risk management framework or review of the risk appetite. Agendas, materials, and attendance lists then serve as expected evidence.
Track three families of metrics: coverage, performance, and control improvement.
Coverage answers a simple question: who completed the training, and on time? You should therefore measure the completion rate by role, department, and status - employee or contractor - along with the average completion time at onboarding and the completion rate within the defined deadlines.
Performance goes a step further. It looks at average assessment scores by audience, the initial failure rate, and the associated remediation actions. It also includes phishing simulation results: click rate, reporting rate, and year-on-year change. In other words, it is not enough for people to have seen the module. You need to check what they retained and how they respond.
Control improvement connects training to what happens in the field. Track the number of actions from post-incident reviews incorporated into updated modules, the reduction in recurring SaaS incidents linked to human error, and governance decisions influenced by training results. These metrics should show a clear reduction in Shadow IT, human errors, and third-party-related incidents. Otherwise, you have just added another dashboard.
Indicators are useless if they are not archived properly.
For an audit, retain six artefacts.[6][7][8][9]
A centralised, exportable repository saves a great deal of time during a review. When an auditor asks for evidence, it is better to retrieve it within minutes than to hunt through files.
Avanoo can cross-reference these metrics with the SaaS inventory to connect training, incidents, and application criticality.
Use the table below to connect training to DORA requirements.
| DORA obligation | Expected training outcome | Evidence artefact (audit) |
|---|---|---|
| Art. 5 - Governance and management accountability | Leaders understand their non-delegable obligations and approve the ICT framework | Signed committee minutes, approved ICT policy, briefing attendance register |
| Art. 6 - ICT risk management framework | Employees identify and report Shadow IT and SaaS concentration risks | Automated discovery logs, SaaS tool risk assessment reports, completion attestations |
| Art. 13 - Awareness and continuous learning | Modules incorporate lessons from incidents | Content version history, post-incident reports, retraining evidence |
| Arts. 17-20 - Incident notification | Teams classify major incidents and meet the 4-hour / 72-hour deadlines[1][5] | Simulation reports, timestamped incident register, post-incident review minutes |
| Arts. 24-27 - Operational resilience testing | Technical teams execute recovery plans (RTO/RPO) | Annual exercise results, remediation plans with deadlines, TLPT reports |
| Arts. 28-30 - Third-party risk | Procurement and IT identify critical SaaS providers and verify contractual clauses | Updated Register of Information (RoI), DORA-compliant contract addenda, supplier risk assessments |
Once the roles, content, and evidence are in place, one final connection remains: training and SaaS governance. DORA awareness is of little use if it does not start from your actual SaaS portfolio.
Every SaaS application should appear in a clear inventory, with:
This link - inventory → owner → targeted training → evidence - turns the inventory into the centre of governance. Without this foundation, training is partly blind. This is where Shadow IT becomes a real problem. Its detection must therefore be part of the awareness programme, not something handled on the side.
This visibility into the field then helps track training completions and identify gaps. Avanoo can cross-reference application discovery, owner assignment, risk classification, and completion tracking by application and team.
The minimum viable programme consists of five simple actions.
A well-run minimum programme can be enough. Targeted modules, annual refreshers, post-incident updates, and strong traceability already make it possible to demonstrate credible compliance. The goal is not to be perfect on day one. It is to move forward consistently, with documentation directly connected to your organisation's SaaS risks.
::: faq
Without visibility, meeting DORA requirements for mapping and risk management quickly becomes difficult. The right starting point is a gap analysis. It shows what is missing, what is escaping the teams' attention, and where the risk areas are.
Then move to automated discovery to catalogue the whole estate. The idea is simple: obtain a clear view of everything in use, including Shadow IT and Shadow AI. Without this, part of the environment remains off the radar.
Avanoo can help build this inventory by cross-referencing several data sources, such as SSO, financial data, proxies, and browser extensions. Combining these sources provides a much more accurate picture of actual usage than relying on any one source in isolation.
Once the assets have been identified, classify them along three dimensions:
This sorting makes it possible to decide where to act first instead of moving forward blindly. :::
::: faq
Keep documentation clear, organised, and up to date to demonstrate DORA compliance. This includes a register of ICT providers classified by criticality, risk assessments for SaaS and AI providers, security policies, incident reports, and test evidence.
Also archive contracts containing the mandatory clauses. Keep a clear record of governance actions, changes made, results achieved, recommendations issued, and remediation plans.
In short, your file should make it possible to show, without ambiguity, who does what, which risks were assessed, what was decided, and what was corrected. :::
::: faq
After a major incident, review the ICT risk management framework to incorporate the lessons learned and take new threats into account.
Also update the training with simulations based on incidents that have actually occurred. Use usage data from your governance platform to adapt awareness training to the field and reinforce the right reflexes, so that an incident of the same type does not happen again. :::
Co-fondateur & CEO
Tanguy Duthion is co-founder and CEO of Avanoo. Previously at Google and Asana, he founded Avanoo to help organizations regain control over their SaaS and AI usage.
See how Avanoo can map your SaaS and AI landscape, reduce risk, and optimize costs. A reliable platform with dedicated human support.
