The expectations gap: why DORA implementation fails before it starts
Every major regulatory implementation programme generates an expectations gap — the space between what the regulation requires, what different stakeholders believe it requires, and what the organisation actually delivers. For smaller regulations with contained scope, this gap is manageable. For DORA, it is structural and potentially dangerous.
DORA's scope is wide, its language is technical, and its interaction with existing Swiss regulatory requirements — particularly FINMA Circular 2023/1 — is complex. Different stakeholders read it differently. The board reads a high-level briefing and concludes that DORA is primarily an IT project. The CTO reads the ICT risk management requirements and concludes it is primarily a documentation exercise. The CCO reads the incident reporting obligations and concludes it is primarily a compliance workflow. The CFO reads the budget request and concludes it is primarily an expense. None of these readings is entirely wrong — and none of them is sufficient.
The organisations that implement DORA well are those that have first established a shared, accurate understanding of what the regulation actually requires across all relevant stakeholders — and then managed the implementation programme against that shared understanding. This is what expectations management means in the DORA context. It is an unglamorous but essential governance discipline, and it is where most implementation programmes that struggle have gone wrong.
The Digital Operational Resilience Act (Regulation EU 2022/2554) entered into force on 17 January 2025 and applies directly to financial entities operating in or regulated by EU member states — including EU subsidiaries of Swiss private banking groups. It establishes binding requirements across five domains: ICT risk management frameworks, ICT-related incident classification and reporting, digital operational resilience testing, management of third-party ICT providers, and information sharing arrangements. For Swiss private banking groups, DORA applies directly to EU-regulated entities and indirectly to Swiss parent institutions that provide services to or receive services from EU-regulated entities.
Critically, DORA is a regulation, not a directive — meaning it applies uniformly across all EU member states without national transposition, and there is no room for member state variation in its core requirements.
Who expects what: mapping the stakeholder landscape
Effective DORA expectations management requires a clear-eyed assessment of what each principal stakeholder group expects from implementation — and where those expectations diverge from regulatory reality. In most Swiss private banking groups, four stakeholder groups hold materially different assumptions about what DORA implementation means.
The three conversations every compliance leader must have
Managing DORA expectations is not a communications exercise — it is a substantive governance task that requires the compliance and risk leadership of a Swiss private banking group to hold three difficult conversations that most organisations have been avoiding.
Conversation 1: with the board, about permanence
The board needs to understand that DORA compliance is not a project with a completion date. It is a permanent governance obligation that will require ongoing board attention — through regular reporting on the institution's digital operational resilience posture, through oversight of the annual resilience testing programme, through timely escalation of material ICT incidents, and through periodic review of the institution's critical third-party ICT provider relationships.
This conversation is often resisted by management, who prefer to bring the board a compliance certificate rather than a standing agenda item. But it is the honest conversation — and regulators will eventually make it unavoidable. Better to have it proactively and design the board governance accordingly than to have it reactively after a supervisory finding.
The specific ask of the board: amend the risk committee's standing mandate to include digital operational resilience as a regular reporting item; establish a clear escalation protocol for material ICT incidents; and commission an annual board-level review of the institution's DORA compliance posture.
Conversation 2: with management, about substance over documentation
The temptation in any major regulatory implementation is to conflate producing documentation with achieving compliance. DORA creates particularly acute temptation in this direction because it requires a significant body of documentation — ICT risk management frameworks, asset registers, third-party provider registers, incident classification matrices, resilience testing plans. Producing this documentation is genuinely difficult and time-consuming. But it is not the same as embedding digital operational resilience into the institution's operations.
DORA compliance exists when the incident classification process is operational and staff know how to use it — not when the classification framework document has been approved. It exists when resilience tests have been conducted and the findings remediated — not when the testing plan has been written. It exists when third-party providers are actively managed against DORA obligations — not when the contract addenda have been signed.
"A DORA policy framework sitting in a SharePoint folder is not digital operational resilience. It is a record of the intention to achieve it."
Conversation 3: with technology providers, about mutual obligation
The third conversation is the one that most institutions have deferred longest and underestimated most severely. DORA's third-party requirements create genuine and significant obligations for ICT service providers — obligations that many providers, particularly smaller or non-EU-headquartered ones, have not fully engaged with.
Swiss private banks that rely on ICT providers for material functions need to have explicit, documented conversations with each material provider about four things: the provider's own DORA compliance status (for EU-regulated providers); the provider's contractual obligations under the institution's updated service agreements; the provider's incident notification procedures and timeline commitments; and the provider's capacity to support the institution's resilience testing requirements — including, for larger institutions, threat-led penetration testing that touches provider systems.
Providers that cannot or will not engage with these conversations represent a concentration of DORA compliance risk that the institution's board should be aware of — and that may, in extreme cases, require a provider transition.
Sequencing DORA implementation: a realistic programme architecture
Swiss private banking groups that have not yet completed their DORA implementation — or that have completed a first-phase documentation exercise but have not embedded operational practices — face the challenge of sequencing the remaining work against ongoing business operations and competing regulatory demands. The following phased architecture reflects realistic implementation timelines for a mid-sized private banking group.
The incident reporting obligation: where expectations cause most damage
Of DORA's five pillars, the incident classification and reporting obligation generates the most immediate and consequential expectations mismanagement. The reasons are structural: incident reporting is time-critical, involves multiple stakeholders with different information needs, and creates direct regulatory exposure if the classification or timing is wrong.
DORA requires financial entities to classify ICT-related incidents against defined criteria and to report major incidents to their competent authority within specified timeframes — an initial notification, a detailed intermediate report, and a final report. The clock on these timelines starts from the moment the institution becomes aware of the incident, not from the moment it is fully understood. In the chaos of an active incident response, meeting regulatory reporting timelines while simultaneously managing the incident itself is genuinely difficult — and institutions that have not rehearsed this process will struggle.
| Report type | Trigger | Timeline | Common failure |
|---|---|---|---|
| Initial notification | Awareness of potential major incident | 4 hours from classification as major | Delayed classification — incident managed as operational issue before regulatory dimension recognised |
| Intermediate report | Status update on ongoing incident | 72 hours from initial notification | Incomplete information handed to regulatory affairs team — technical and legal not coordinating |
| Final report | Incident contained and root cause identified | 1 month from intermediate report | Root cause analysis not completed — final report submitted without adequate lessons-learned content |
The most common failure in incident reporting is not wilful non-compliance — it is structural unpreparedness. The institution has not clearly designated who has authority to classify an incident as major, who is responsible for triggering the regulatory notification, and what information the notification must contain. These decisions, made under time pressure during an active incident, are too important to be made for the first time in the moment. They must be pre-decided, documented, and rehearsed.
DORA and Swiss institutions without direct EU exposure: the indirect obligations
A significant number of Swiss private banking institutions have concluded, after a superficial scope assessment, that DORA does not apply to them — because they are Swiss-regulated, serve predominantly non-EU clients, and have no EU-licensed entities. This conclusion is frequently incorrect, and the error has governance consequences.
The indirect channels through which DORA reaches Swiss private banks include: group-level obligations where a Swiss parent provides ICT services to an EU-regulated subsidiary; contractual obligations where EU-regulated counterparties require DORA-aligned practices from their Swiss service providers; and client-level expectations where EU institutional clients or EU-based private clients operate under DORA-governed environments. In addition, the Swiss Financial Market Infrastructure Act is evolving in a direction broadly consistent with DORA's principles — meaning that institutions that develop genuine DORA-aligned capabilities now are building towards future Swiss regulatory expectations, not merely satisfying current EU ones.
The appropriate response for Swiss private banking institutions without direct EU exposure is not to ignore DORA, but to conduct a documented scope assessment, conclude clearly on their position, and — where indirect obligations exist — address them proportionately. A documented, reasoned scope assessment that concludes DORA does not apply is a legitimate regulatory position. An institution that has never conducted a scope assessment has no position at all.
What good looks like: the expectations management standard
The benchmark for good DORA expectations management is not regulatory perfection — it is regulatory credibility. An institution that has managed its DORA expectations well can demonstrate, at any point in the implementation cycle, four things to any stakeholder who asks.
These four markers do not require perfection. They require honesty, structure and genuine governance engagement. An institution that can demonstrate all four — even if its implementation is not yet complete — is in a materially better regulatory position than one that has produced comprehensive documentation but cannot point to operational substance behind it.
DORA is, ultimately, a test of institutional character as much as regulatory compliance. The institutions that manage it well are those that treat it as a genuine governance standard — to be understood, embedded and owned — rather than a compliance exercise to be satisfied and filed. That distinction, which every experienced supervisor can detect within the first hour of an on-site review, is the difference that matters.