DORA Compliance Training for Non-Technical Employees
Why DORA training extends beyond IT: what non-technical employees need to know about incident reporting, vendor management, and resilience.
When financial services organisations begin planning for DORA compliance, the instinct is to start with the technology team. This makes sense on the surface — the Digital Operational Resilience Act is about ICT risk, and ICT is what technology teams manage.
But DORA is not a technology regulation. It is an operational resilience regulation that happens to focus on the ICT dimension. The distinction matters enormously when it comes to training, because operational resilience is not something the IT department delivers alone. It is something the entire organisation either has or does not have.
Article 13 of DORA makes this explicit. ICT security awareness programmes and digital operational resilience training are described as "compulsory modules" in staff training schemes, "applicable to all employees and to senior management staff." Not applicable to technical employees. All employees.
This article explains why, and what non-technical training under DORA should actually cover.
Why DORA's Training Mandate Extends Beyond IT
The logic of DORA's broad training scope becomes clear when you consider the scenarios the regulation is designed to address.
A critical ICT disruption at a bank does not stay within the technology function. When core banking systems go offline, branch staff cannot serve customers. Call centre teams face a surge of enquiries they cannot resolve. Operations teams cannot process payments or settlements. Finance cannot produce regulatory reports. Compliance needs to determine whether the incident meets reporting thresholds. HR must manage the workforce impact. Communications must handle external messaging.
Every one of those responses involves non-technical staff making decisions that affect the organisation's operational resilience. If those staff do not understand the ICT risk framework — if they do not know what constitutes a reportable incident, what the escalation pathway is, or what their role is in the business continuity plan — then the organisation's resilience is limited by their knowledge gap, regardless of how well-prepared the IT team is.
DORA recognises that a chain of operational resilience is only as strong as its least-informed link. The regulation's training requirements are designed to ensure that the entire organisation, not just the technical core, can function coherently when an ICT disruption occurs.
This is not about turning HR managers into cybersecurity specialists. It is about ensuring that every function understands its own role within the broader resilience framework. The depth of knowledge varies by role. The existence of knowledge does not.
What Non-Technical Employees Actually Need to Know
The training that non-technical staff require under DORA is not a diluted version of technical security training. It is a different kind of training altogether, focused on organisational behaviour during ICT disruption rather than on technical controls.
There are four domains that matter most for non-technical audiences.
Incident Recognition and Reporting
This is arguably the highest-value training for non-technical staff. DORA imposes strict incident reporting timelines — initial notification to the competent authority within four hours of classifying a major ICT-related incident, with intermediate and final reports to follow. The clock starts at classification, but the underlying events often begin with observations by non-technical staff.
A relationship manager notices that client data is displaying incorrectly. An operations analyst finds that a reconciliation process has produced anomalous results. A branch employee discovers that a system they use daily is behaving in an unfamiliar way. These are potential early indicators of an ICT incident — but they only become part of the incident response if the person who observes them knows what to do with the observation.
Non-technical staff do not need to classify incidents. They need to understand what looks abnormal, who to tell, and how quickly. The gap between "that is odd, I will mention it at the team meeting" and "that looks like it could be an ICT incident, I am escalating it now" can be the gap between meeting the four-hour reporting window and missing it.
Training for this domain should focus on recognition patterns — what does a potential ICT incident look like from a non-technical vantage point? — and on escalation mechanics. Not the technical details of what happened, but the organisational response: who do I contact, what information do I provide, and what happens next.
Third-Party ICT Risk
DORA places substantial weight on the management of ICT third-party service providers. Articles 28 through 30 establish requirements for risk assessment, contractual provisions, and ongoing monitoring of outsourced ICT services.
The employees who interact most frequently with third-party providers are often not in IT. Procurement teams negotiate contracts. Business teams define requirements and evaluate service quality. Operations teams depend on provider performance daily and are often the first to notice degradation.
These staff need to understand the basics of DORA's third-party framework: what the organisation is required to include in ICT service contracts, what performance and resilience standards providers must meet, and how to escalate concerns about a provider's reliability or security posture. They do not need to conduct technical due diligence. They need to know that due diligence requirements exist, what their role is in supporting them, and what red flags to watch for in their day-to-day interactions with providers.
A procurement manager who does not know that DORA requires specific contractual provisions for critical ICT services may negotiate a contract that is non-compliant from day one. That is not a failure of the procurement function — it is a failure of the training programme.
Business Continuity During ICT Disruption
Every function in a financial services organisation has some dependence on ICT systems. When those systems are disrupted, each function needs to know its own continuity procedures: what manual workarounds exist, what activities must be prioritised, what can be deferred, and how to communicate with other parts of the organisation during the disruption.
DORA's requirements for ICT business continuity management (Article 11) and ICT response and recovery plans (Article 12) create a framework that must be understood beyond the teams that wrote the plans. The plans only work if the people who must execute them know they exist, understand their own role, and have practised the relevant procedures.
Training in this domain is not about the technical recovery process. It is about operational behaviour: what does this team do in the first hour of a major ICT disruption? Who leads the response at the function level? What decisions can be made locally and what requires escalation? How do we maintain critical client services while systems are being restored?
Governance and Personal Responsibility
For staff in management or supervisory roles outside IT, there is an additional dimension. DORA establishes that the management body is responsible for the ICT risk management framework (Article 5), and that this responsibility includes understanding and assessing ICT risk. Senior managers in non-technical functions — heads of operations, CFOs, chief risk officers, HR directors — sit within or report to governance structures that have DORA obligations.
These individuals need to understand how ICT risk integrates with the broader risk framework they oversee. They need to be able to ask informed questions in governance forums, challenge assumptions about ICT resilience, and make resource allocation decisions that reflect DORA's expectations. This is not technical knowledge. It is governance literacy applied to the ICT domain.
Making ICT Resilience Relevant to Non-Technical Teams
The biggest obstacle to effective DORA training for non-technical staff is not complexity — it is relevance. If the training feels like a technology briefing that has been awkwardly extended to a non-technical audience, engagement will be low and retention will be lower.
The solution is to frame the training around the decisions and situations that non-technical staff actually face, rather than around the regulatory text or the technical framework.
Start with scenarios, not articles. A compliance officer does not need to read Article 13 to understand their DORA obligations. They need to work through a scenario where a vendor outage disrupts regulatory reporting and they must decide how to respond. The article is the legal basis; the scenario is the learning.
Use role-specific contexts. An operations team learning about incident escalation should encounter a scenario set in their operational context — a payment processing disruption, a reconciliation failure, a data integrity issue. Not a generic phishing simulation. The content is "what would you do if this happened to your team?" not "here is what a cyberattack looks like."
Focus on decisions, not information. The difference between effective and ineffective compliance training is usually the difference between "here is what you need to know" and "here is a situation — what would you do?" The first produces awareness. The second produces competence. DORA's training requirements, particularly for the management body, are set at the competence level.
Connect individual actions to organisational outcomes. Non-technical staff engage with resilience training when they understand that their behaviour during a disruption directly affects the organisation's ability to recover. The branch manager who escalates an anomaly quickly is not just following procedure — they are protecting the organisation's ability to meet its regulatory reporting obligations. Making that connection explicit transforms the training from a compliance exercise into something meaningful.
As we covered in detail in our analysis of DORA's staff training requirements, the organisations that build proportionate, role-specific training programmes produce better evidence and better resilience outcomes than those that deploy a single module across the entire organisation.
Scenario-Based Approaches vs. Technical Certification
There is a reasonable question about whether non-technical staff should pursue formal ICT or cybersecurity certification as part of their DORA compliance training. The short answer is no — not because certification is without value, but because it solves a different problem.
Technical certifications (CISSP, CISM, CompTIA Security+, and similar) are designed for practitioners who need to implement and manage security controls. They test deep technical knowledge against a broad domain. Requiring non-technical staff to pursue these certifications would be disproportionate under DORA's own terms, and the content would be largely irrelevant to their actual obligations.
What non-technical staff need is contextual competence — the ability to act appropriately within the DORA framework given their specific role. A finance director does not need to understand network segmentation. They need to understand how an ICT disruption affects financial reporting obligations and what governance decisions they may need to make during a major incident.
Scenario-based training is better suited to this requirement because it tests decisions in context rather than knowledge in the abstract. A well-designed scenario places a non-technical learner in a realistic situation relevant to their function and asks them to make choices: do you escalate this observation? To whom? What information do you include? What is your continuity procedure? The learning happens in the decision-making, and the assessment evidence comes from the decision trail.
This is also the kind of evidence that supervisory authorities find most compelling. A record showing that your head of operations correctly identified an incident trigger and made the appropriate escalation decision in a simulated scenario is more meaningful than a certificate showing they completed a 45-minute eLearning module on ICT risk fundamentals.
Building a Proportionate Programme
Proportionality is a core principle of DORA. The regulation recognises that a global systemically important bank and a small authorised payment institution face different ICT risk profiles and should not be held to identical standards. The same principle applies within organisations: different roles require different training depths.
A proportionate non-technical training programme might look like this:
All staff (awareness tier): Annual ICT security awareness training covering basic hygiene, incident recognition, and escalation procedures. Short, role-contextualised, with evidence of completion. This satisfies the baseline Article 13 obligation.
Operationally exposed staff (applied tier): Teams whose functions are directly affected by ICT disruption — operations, finance, compliance, customer-facing roles — receive scenario-based training that tests their ability to respond to realistic disruptions affecting their function. This produces competence evidence, not just completion records.
Non-technical management (governance tier): Senior managers outside IT who sit on or report to governance bodies receive training focused on DORA governance obligations, ICT risk oversight, and their role in the management body's Article 5 responsibilities. This should include applied assessment — not awareness slides, but scenarios that test governance decision-making.
Vendor-facing staff (third-party tier): Procurement, business owners of outsourced services, and relationship managers receive training on DORA's third-party framework, contractual requirements, and ongoing monitoring obligations.
The tiers are not mutually exclusive. A head of operations might need training at the applied, governance, and third-party tiers. The point is that each tier is designed for its audience, with content, depth, and assessment calibrated to the role's DORA-relevant responsibilities.
The Cost of Getting This Wrong
There is a tendency to view non-technical DORA training as a lower priority — something to address after the technology team's programme is in place. This sequencing is understandable but creates risk.
The most common DORA compliance failures will not be technical. They will be organisational. A delayed incident report because a non-technical employee did not recognise the trigger. A non-compliant vendor contract because procurement was not trained on Article 30 requirements. A governance gap because senior managers outside IT could not demonstrate ICT risk competence during a supervisory examination.
These are exactly the failures that DORA's broad training mandate is designed to prevent. Addressing them does not require complex or expensive training infrastructure. It requires deliberate, role-appropriate training that reaches every function in the organisation — and produces evidence that it did.
The DORA compliance training programme at Blend is built around this principle. It includes role-specific learning paths for both technical and non-technical audiences, using scenario-based approaches that test applied competence in realistic operational contexts. Each path produces decision-level evidence suitable for supervisory review.
If you are unsure where your current training arrangements stand against DORA's full scope of obligations — including the non-technical workforce — the compliance training diagnostic will give you a structured gap analysis in about two minutes. It is a practical starting point for understanding what proportionate coverage looks like for your organisation.