Most regulation applies to you and stops there. If your supplier is the problem, that is between you and your supplier, and the regulator’s interest is limited to whether you managed the relationship competently.
The EU’s Digital Operational Resilience Act does something else. It regulates financial entities in the ordinary way, and then it reaches past them and takes powers over their suppliers directly. In November 2025 the European supervisory authorities published the first list of providers designated as critical, and the three large cloud platforms are all on it.
That is an unusual piece of regulatory architecture, and it is widely misread in a specific and expensive way.
Table of contents
Open Table of contents
The shape of it
The regulation applies from 17 January 2025 and covers roughly twenty categories of financial entity. Banks, payment and electronic money institutions, investment firms, insurers and intermediaries, fund managers, trading venues, central counterparties, central securities depositories, credit rating agencies and crypto asset service providers among them. The breadth is deliberate: if it touches the financial system, it is probably in scope, and small entities get a simplified framework rather than an exemption.
It rests on five pillars, and the ordering is not accidental.
Governance and ICT risk management comes first, with explicit accountability sitting on the management body rather than being delegated into a technology function. Then incident management, classification and reporting. Then resilience testing, including intelligence driven red teaming for the larger entities. Then management of third party ICT risk, which is the largest and most demanding part in practice. Then arrangements for sharing threat intelligence, which is the only pillar that is genuinely voluntary.
Nothing in that list will surprise anybody who has read a modern security framework. What makes the regulation distinctive is the specificity of the deadlines and the fact that it goes after the supply chain with real powers.
Critical or important functions
Almost every obligation scales with a single classification: whether a function is critical or important. Get that wrong and everything downstream is wrong with it, because the classification determines which contracts need enhanced terms, which incidents need reporting, what has to be tested and what has to appear in your register.
If that pattern sounds familiar, it is because the same idea appears in the telecoms security framework under a different name, where the equivalent concept is the security critical function. Both regimes decided that the way to scope obligations is to ask what a thing does and how much of the service depends on it, rather than to enumerate systems. Both put the burden on you to justify the boundary you drew.
If you fall inside both regimes, and some infrastructure and payment businesses do, classify once against the stricter reading and map the output into both vocabularies. Running two independent classification exercises produces two registers that disagree, and the disagreement is the finding an examiner will pick up.
The four hour clock
Three deadlines apply to a major incident, and they are the part of the regulation most likely to embarrass an otherwise well run firm.
An initial notification is due within four hours of classifying the incident as major, and in any case no later than twenty four hours after you became aware of it. An intermediate report follows within seventy two hours of that notification, with a further update once normal operations resume. The final report is due within one month, when the root cause work is complete.
Read the first deadline carefully, because the clock starts at classification rather than at detection, and that creates an obvious hazard. A firm with a slow or ambiguous classification process is not thereby granted extra time; the twenty four hour backstop from awareness closes that gap. So the real requirement is that classification happens quickly and consistently, at any hour, by whoever is actually on duty.
That is an operational design problem rather than a legal one, and it is solved before the incident or not at all. It means the classification criteria must be written down in a form somebody can apply under pressure at three in the morning, the decision must not require a committee, and the person on call must know they hold that authority. The four hour window is not generous once you have spent ninety minutes trying to find out who is allowed to make the call.
Which is worth connecting to the incident tooling question. If your summarisation and correlation stack helps a human classify faster, it has become part of your regulatory reporting path, with all that implies about how much you trust it.
The Register of Information
On paper this is a reporting form. In practice it is the obligation that has caused the most work, and the first submissions made clear that supervisors are reading it closely.
You maintain a structured register of all your contractual arrangements for ICT services, and submit it in a defined machine readable format across fifteen templates. It covers who the providers are, what they do, which of your critical or important functions depend on them, where the services and the data sit, and, crucially, who the subcontractors are.
That last part is where the exercise stops being administrative. The register asks you to describe a supply chain to a depth most firms have never documented, including the parts of it you do not contract with directly. Assembling it honestly tends to surface three problems: providers nobody has a current owner for, dependencies on subcontractors nobody knew existed, and a concentration of critical functions on a small number of suppliers that is uncomfortable to see written down in one place.
It is a data quality problem wearing a compliance costume. The submission format is strict enough that inconsistent naming or missing identifiers become mechanical failures, which means the discipline your inventories never quite got is now enforced by a validator.
Third party risk, and the contracts
The regulation prescribes what has to be in a contract for a critical or important function, which is a departure from the usual practice of demanding an outcome and leaving the mechanism to you.
Audit and access rights have to be there, including for the regulator. Exit provisions have to be there. Conditions on subcontracting have to be there, along with visibility of who the subcontractors are. Service locations and data locations have to be specified. Assistance during incidents has to be committed.
Two of these deserve honest treatment rather than a nod.
Concentration risk is straightforward to identify and hard to do anything about. Once you have written the register, you can see how much depends on how few. The regulation expects you to assess this. It does not pretend there is an easy remedy, and neither should you.
Exit strategies are the uncomfortable one. You are required to have a documented, tested plan for leaving a provider of a critical function. Anybody who has genuinely attempted to move a substantial workload off a large cloud platform knows the distance between a plan that satisfies a document review and a plan that would survive being executed under time pressure. This is the requirement most likely to be met on paper and unmet in reality across the whole regulation, and it is worth being clear eyed about which of the two you have.
The oversight framework, and what people get wrong
Here is the novel part. The supervisory authorities can designate a provider as a critical ICT third party provider, and once designated it comes under direct oversight, with a lead overseer drawn from one of the three authorities according to the sector it mostly serves. Banking oriented providers to the banking authority, capital markets and post trade to the securities authority, insurance to the insurance authority.
The first designations were published in November 2025 and covered nineteen providers, including the three large cloud platforms alongside major enterprise software and telecommunications suppliers. Supervision began in earnest through 2026, with examination teams standing up and a supervisor cohort assembled for the purpose.
Now the misreading, which I have heard more than once. Designation of your provider does not reduce your obligations. Not a single one of them.
Your provider being supervised does not mean you may rely on that supervision in place of your own due diligence. It does not remove the contractual requirements, the register entry, the concentration assessment or the exit plan. It does not transfer accountability for a critical function from your management body to a European authority. The oversight regime exists because systemic dependence on a handful of providers is a risk to the financial system as a whole, and it addresses that systemic question. Your firm specific question is untouched.
There is a genuine practical benefit, which is worth stating so the point does not sound purely negative. A supervised provider is subject to recommendations from its overseer, and the existence of that channel changes the balance of a negotiation that has historically been entirely one sided. It is leverage. It is not a substitute.
Testing
Beyond routine testing, larger entities must carry out threat led penetration testing at least every three years, following the European framework for intelligence driven red teaming. Central bank implementation guidance for supervised institutions arrived in late 2025, and the first wave of notifications has been landing through 2026.
The timelines are what to internalise. A full cycle, from procuring a suitable provider through execution to attestation, runs somewhere between nine and fourteen months. Once notified, you have a matter of months to submit scope. Anybody expecting to complete a cycle by early 2028 should have procurement under way well before then.
Two failure modes are predictable. Firms treat it as a larger penetration test, when the whole point is that it targets the live production estate supporting critical functions, with realistic adversary emulation. And firms discover late that the scope has to be agreed with the authority, which removes the option of quietly narrowing it to something comfortable.
What to take from it if you are not in scope
The specific obligations belong to financial entities. Four of the ideas are worth borrowing by anybody.
The register is the useful artefact, not the form. A structured inventory of every ICT arrangement, mapped to the functions that depend on it, with subcontractors named, is valuable whether or not a regulator ever asks. Most organisations cannot produce it, and the attempt is instructive.
Classification speed is a design property. Any organisation with a reporting obligation, contractual or regulatory, should ask how quickly it can decide the severity of something at four in the morning, and who is permitted to decide.
Concentration is worth writing down even when there is nothing to do about it. Seeing it stated plainly changes conversations about architecture.
And an exit plan you have not tested is a hypothesis, which is the same observation that applies to backups and to every other control whose failure is invisible until the day it matters.