DORA does not apply to your company. The regulation is aimed at banks, insurers and other financial entities in the EU, and if your business in Aarau maintains software, runs hosting or provides support, your name appears nowhere in the legal text. And yet DORA requirements are landing on the desks of Swiss suppliers right now. Not as a letter from an authority, but as a contract annex from a customer.
In our experience the pattern looks like this: a long-standing customer from the financial sector sends an annex of twenty or thirty pages. Audit rights, reporting deadlines, exit clauses, subcontractor lists. Along with the friendly request to sign it by the end of the quarter because "we need this for regulatory reasons". And now you sit there wondering which parts of it apply to you.
Why a regulation that does not apply to you still reaches you
DORA, spelled out the Digital Operational Resilience Act, has applied since 17 January 2025 (Regulation (EU) 2022/2554). It obliges financial entities in the EU to manage their digital resilience, and that explicitly includes the risk from purchased ICT services.
Two mechanisms make sure this obligation ends up with you.
First, the register of information: every financial entity must keep a register of all contracts with ICT service providers and present it to its supervisor on request. Translated, that means your customer must know who you are and what you do for them, and they must be able to report you to the supervisor. From now on you are on a list that a European supervisory authority can read.
Second, the mandatory contractual content: the regulation prescribes which points must be covered in a contract with an ICT service provider. If they are missing, your customer has a compliance problem. They cannot opt out of this, and they cannot limit it to EU suppliers either. So they send the annex to everyone, including Aarau.
It does not follow that an EU authority is now at your door. Direct supervision of ICT service providers only hits providers classified as "critical", in practice the large cloud and infrastructure groups. For a Swiss SME everything runs through the contract with the customer. That is the good news, because contracts can be read and negotiated.
The mechanism itself will probably feel familiar. The Swiss Information Security Act works in a similar way: a narrow circle is directly obliged, and everyone else receives the requirements passed down through customers and contracts. We described this in our post on the ISG and its ISMS obligation. DORA is the same logic, just with Brussels as the sender.
What the annex demands: the DORA requirements in plain language
The contract annexes look similar across financial customers because they all reflect the same rules. The most important points, translated into what they mean for your business:
Complete service description with locations. Your customer must know which service you provide where, and where data is stored and processed. Sounds trivial. In our experience most suppliers fail here, because nobody in the company can write down the full service for this one customer, including the question of which part of it sits with a subcontractor.
Disclosing subcontractors. If you pass on parts of the service, to a data centre, a hoster, a development partner, the customer wants to know and partly wants a say. Your supply chain becomes part of their risk assessment. You may already know this topic from the other direction: supply chain security is exactly this question, only until now you were the one asking.
Incident support and reporting deadlines. Your customer faces tight reporting deadlines for ICT incidents towards their supervisor. They can only meet those deadlines if you report quickly what happened on your side. That is why the annex typically contains a deadline in hours, not in days.
Audit and access rights. The customer, their auditor and, if in doubt, their supervisory authority may examine your service delivery. For many this is the most uncomfortable point. It is also the least negotiable one, because it comes straight from the regulation.
Termination and exit provisions. The customer must be able to get out of the contract without their operations coming to a halt: transition periods, cooperation during migration, return of data in a usable form.
If your service supports a critical or important function of the customer, another layer comes on top: measurable performance targets, participation in security testing up to threat-led penetration tests, worked-out exit strategies. That is considerably more effort, and exactly why the question of whether your service belongs in this category is worth asking.
What is fixed and what is negotiable
This part determines your effort and your margin. The annexes we see are almost always maximum templates. The customer's legal department has built a template for the heaviest case and sends it to all suppliers, from the data centre operator to the company maintaining the coffee machine software. For the customer this is efficient. For you it means that part of the annex is not relevant to your service.
The regulation itself makes a distinction: the full catalogue applies to services supporting critical or important functions. For everything else a considerably leaner one applies. Whether your maintenance service for an internal reporting tool supports a critical function of the bank is a classification question, and the customer makes that classification. Asking is allowed. In our experience that conversation is the most effective lever in the whole process: one hour with the customer's provider management to clarify the classification can spare you testing obligations and exit documentation that were never meant for you.
Modalities are also negotiable in our experience: deadlines in detail, the form of audits (reports and certificates instead of on-site visits, where the classification allows it), the handling of existing subcontractors.
How you respond makes a difference. The weakest move is to sign the annex without a word and hope nobody ever checks. The second weakest is to let it sit for months. What works well in our experience: a short, factual reply to the customer with three elements. First, the question back about the classification of your service, with your own assessment as a proposal. Second, the points you already meet today, with evidence. Third, the points you do not meet yet, with a date by when you will. Provider managers in the financial sector work under pressure and deadlines themselves. A supplier who responds like this makes their life easier, and that pays directly into the business relationship.
The core is not negotiable. That you can describe your service. That you detect incidents and report them within a committed deadline. That you know your subcontractors. That you cooperate in an exit. Anyone who tries to negotiate these points away signals one thing above all to the customer: that they cannot meet them.
That is the finding we take away from such mandates. The problem is rarely the annex. The problem is that the supplier does not have the answers. Nobody can produce the subcontractor list because it is not kept anywhere. Nobody can commit to reporting within hours because no process and no responsible person exists. The contract demands nothing exotic. It demands that you know your own shop, and it makes visible where that has not been the case so far.
One answer that works for all financial customers
If you have one financial customer, you probably have several, or you want to win them. And because all EU financial customers must reflect the same rules, you will receive the same annex in variations again and again. You can answer it individually every time, with a week of effort across management, IT and your lawyer. Or you build the answers once, in a structured way: a maintained register of your services and subcontractors, an incident process with responsibilities and realistic deadlines, a documented security baseline, a defined way of handling audits.
Soberly speaking, that is a small ISMS, cut to what your customers ask. It does not need to be certified. If ISO 27001 is on the table anyway because larger customers ask for it, a well-scoped ISMS covers the DORA annexes to a large extent. What that costs and where the cost drivers sit is something we wrote up separately. The order matters: first understand your customers' questions, then build the framework. Not the other way round, otherwise you end up with a programme that covers more than anyone ever asked for.
There is a second reason not to put this off. Procurement teams in the financial sector screen suppliers before the first conversation takes place. Whoever cannot sign the annex, or needs three months for an answer, drops out of tenders they never heard about. The reverse holds too: a supplier who answers the questions reliably within a week stands out from a field that fails at exactly that. For Swiss suppliers, DORA is less a compliance topic than a sales topic.
If such an annex is sitting on your desk right now and you are not sure which half of it applies to you: this is exactly the kind of assessment we do, including the uncomfortable question back to the customer about whether the classification is right. An initial conversation is non-binding.
One question interests us first in every case, and you can ask it yourself today: what have you already committed to in the supplier contracts of recent years, without anyone ever checking?
