DORA’s two-year runway, measured in contract renewals

The week

Every bank, insurer and payment company today is, underneath, a technology operation. Customers see an app or a branch; behind it sit data centers, cloud services, software licensed from dozens of vendors and networks run by telecom carriers. When that machinery fails, through an outage, a cyberattack or a supplier going under, the financial firm fails its customers too. European lawmakers decided that this resilience could no longer be left to each firm’s judgment.

On January 16, 2023, the EU’s Digital Operational Resilience Act, Regulation (EU) 2022/2554, entered into force, with its requirements applying from January 17, 2025. Known as DORA, it covers a wide range of EU financial entities, including banks, investment firms, payment and e-money institutions, insurers and crypto-asset service providers.

The law had been more than two years in the making. The European Commission proposed it in September 2020 as part of a digital finance package that also included the regulation that became MiCA, the EU’s crypto-asset rulebook. Negotiators for the Parliament and the Council reached political agreement in May 2022. Both institutions adopted the text in November 2022, and it was published in the Official Journal on December 27, 2022. Entry into force followed twenty days later, which is why the formal start date fell in the week of January 16.

DORA is a regulation rather than a directive, and that choice mattered. A directive sets goals that each member state writes into its own law, which allows national variation. A regulation applies directly and identically across the EU. A companion directive, adopted alongside it, amended existing financial services directives so that they pointed to DORA. Member states had until January 2025 to transpose that companion text.

DORA speaks the language of ICT, short for information and communication technology: all the computers, software, networks and data services a firm depends on. It sets requirements in five areas:

• ICT risk management: knowing what technology the firm relies on and how it could fail.
• ICT incident classification and reporting: sorting technology incidents by severity and telling supervisors about the serious ones.
• Resilience testing, including threat-led penetration testing for significant firms. This is a controlled, authorized attack by specialists who imitate real criminals, to find weaknesses before real attackers do.
• Management of ICT third-party risk: the danger that comes from relying on outside technology providers.
• Information sharing about threats among firms.

Article 30 lists key provisions that contracts with ICT providers must contain, with more for services supporting critical or important functions, the activities whose failure would seriously harm the firm, its customers or the market.

DORA also created an EU framework for designating and directly overseeing critical ICT third-party providers. That means the largest technology suppliers to European finance, the ones whose failure could hurt many firms at once, would come under the direct eye of financial supervisors for the first time.

Much of the detail was left for later. DORA directed the three European Supervisory Authorities, the EU bodies for banking, securities and insurance, to draft regulatory and implementing technical standards. Those standards would specify the content of ICT risk policies, how to classify incidents, what templates to use for reporting, how to run threat-led tests and what the register of contracts must contain. The ESAs consulted on them during 2023 and delivered them in two batches, in January and July 2024. Firms therefore began the two-year window knowing the shape of the obligations but not their final detail.

The new law also built on existing expectations. The European Banking Authority’s 2019 guidelines on outsourcing had already required many contractual protections for critical outsourcing by banks and investment firms. The insurance and securities authorities had issued their own guidelines on cloud outsourcing. DORA went further in three ways. It covered all ICT services, including those never formally treated as outsourcing. It made the requirements binding law rather than supervisory guidance. And it applied a single standard across financial sectors that had previously followed different rules.

The NIS2 Directive on network and information security entered into force the same day, setting broader cybersecurity duties across many sectors of the economy. So did the Critical Entities Resilience Directive, which addresses the physical resilience of operators of essential services. Member states had until October 2024 to transpose NIS2. Where DORA and NIS2 overlap for financial entities, DORA takes precedence as the more specific law. For financial firms, though, DORA was the main event, and the two-year clock had started.

Take the general counsel of a mid-sized European bank in early 2023, looking at a spreadsheet of technology contracts. Some were signed last year. Some were signed a decade ago by people who have since left. Some renew automatically next month. All of them, from January 2025, would have to meet a new legal standard. And not one of them could be changed by the bank alone.

Most early DORA programs started with policies and gap assessments. Those were necessary, but the schedule broke elsewhere. DORA applied to every ICT contract from January 2025, including agreements signed years earlier, and a firm cannot rewrite a contract on its own.

The two-year window was really a negotiating window, and it raised three questions: what the contracts must say, which contracts are in scope, and when each one can actually be changed.

Why a resilience law cares about contracts

A generation ago, a bank ran most of its own technology in its own buildings. Today it rents much of it. Its core banking system, the central software that keeps track of every account, balance and transaction, may be licensed from a specialist vendor. Its servers may sit in a cloud provider’s data center, meaning the bank uses computing power owned and run by another company, much as a household uses electricity from the grid instead of running a generator. Its fraud screening, payments, customer messaging and market data may each come from a different supplier.

That arrangement brings real benefits: scale, expertise and lower cost. It also means the firm’s resilience depends on promises made by other companies. When something goes wrong, a regulator’s questions are practical: where the data is, whether the firm can get it back, whether the provider will help during an incident, whether the firm can inspect how the service is run, and whether it can leave and how long that would take.

The only place those answers are guaranteed is the contract. A provider may be helpful when asked, but helpfulness is not a right. DORA turns the answers into required clauses, so that a firm can show its supervisor enforceable commitments rather than trust in a provider.

Outsourcing a service does not outsource responsibility for it. Customers and regulators will hold the bank accountable whoever actually runs the servers.

What changed from the earlier guidelines

Banks that had worked through the EBA’s 2019 outsourcing guidelines started with an advantage. They already kept an outsourcing register, had classified critical outsourcing and had negotiated audit and exit clauses for their largest arrangements. What they had often not done was apply the same discipline to ICT services that fell outside the definition of outsourcing: software licenses, data feeds, security tools and network services. DORA swept those in. A bank with a mature outsourcing register might find that it covered only a fraction of its ICT contracts.

The register itself changed character. Under DORA, the register of information became a structured supervisory dataset with standard templates and legal entity identifiers for providers. It records the function supported, the type of service, data locations and how easily the provider could be replaced. Supervisors would collect it and aggregate it across firms. A register built as an internal spreadsheet needed to become a governed data asset.

How the burden differed by type of firm

The work looked different across the sectors DORA covers. Large banking groups had the most contracts but also the most experience and the largest negotiating teams. Insurers had followed EIOPA’s cloud guidelines but often had less experience with detailed ICT incident reporting. Payment and e-money institutions, many of them young and heavily dependent on a few technology providers, faced the full contractual requirements with small legal teams and limited bargaining power. Crypto-asset service providers, newly authorized under MiCA, met DORA as part of their first experience of EU financial regulation.

DORA did allow for proportionality. It sets a simplified ICT risk management framework for certain smaller and less interconnected entities, and microenterprises have lighter obligations in several areas. The contractual requirements in Article 30, though, apply to every in-scope firm’s ICT contracts. A small payment institution still needed its core processing contract to say where its data was held, how it could be recovered and how the firm could leave.

Groups headquartered outside the EU faced their own version of the problem. A US banking group with an EU subsidiary had to meet DORA for that subsidiary while operating under US supervisory expectations at the parent. Technology was often provided by the parent or by global contracts negotiated in the United States. Those global contracts and the intra-group arrangements behind them both had to support the subsidiary’s DORA obligations.

What the contracts must say

Article 30 sets minimum contents for every contractual arrangement for ICT services. They include a clear description of the services, the locations where services are provided and data processed, provisions on data availability, integrity and confidentiality, and the firm’s ability to recover and return its data if the provider fails or the contract ends.

They also require service level descriptions, provider assistance during ICT incidents at no cost or a cost set in advance, cooperation with the firm’s regulators, and defined termination rights.

Contracts for services supporting critical or important functions need more. They must carry precise quantitative and qualitative performance targets and notice and reporting duties. They need provider business contingency plans that are tested, participation in the firm’s threat-led penetration testing where relevant, unrestricted rights of access, inspection and audit, and exit strategies with a mandatory transition period.

Two further provisions shaped the negotiations. Article 28 requires firms to assess providers before contracting, to consider concentration risk, and to maintain documented exit strategies for services that support critical or important functions. Firms must also inform their supervisor in a timely manner about planned contracts for critical or important functions. Article 30 also encourages the use of standard contractual clauses developed by public authorities for particular services. Together these turned contract negotiation into one stage of a lifecycle that ran from selection through monitoring to exit.

What those clauses mean in practice

The legal wording sounds abstract. Several of the requirements translate into everyday questions.

• Locations of services and data. Where, physically and legally, is our information? This matters for privacy law, for a regulator’s ability to reach it and for the firm’s ability to retrieve it if a provider in another country runs into trouble.
• Availability, integrity and confidentiality. Will the data be there when we need it, will it be accurate, and will only the right people see it? These are the three basic promises of information security.
• Recovery and return of data. If the provider goes bankrupt on a Friday, can we get our records back on Monday, in a form we can actually use? A pile of files in a format only the provider’s software can read is not much of a return.
• Incident assistance at a cost set in advance. During a crisis, the provider helps, and the price is not negotiated while the firm is at its most desperate.
• Cooperation with regulators. If the firm’s supervisor wants to understand how a critical service runs, the provider will engage rather than refuse because the regulator is not its customer.
• Termination rights. The firm can end the contract when the provider’s failures or a regulator’s instruction require it, as well as at the end of the term.

Read that way, Article 30 is close to a checklist any prudent buyer of an important service would want. The difference is that DORA made it compulsory, and set a date by which every existing contract had to measure up.

Where legacy contracts fell short

Few legacy agreements met all of this. Older outsourcing contracts often had audit rights limited to pooled reports, the standardized summaries a provider shares with all customers rather than letting each one look for itself. Their incident clauses were written for availability, whether the service was up or down, rather than security, whether it had been compromised. Their exit terms said little about transition support.

Testing clauses were another common gap. Firms designated for threat-led penetration testing must run such tests regularly, generally every three years, following a methodology built on the European TIBER-EU framework. Where a critical function relies on an outside provider, the test may need to include that provider’s systems. Older contracts rarely allowed a customer to commission simulated attacks against a provider’s environment. DORA allows pooled testing, in which a provider serving many firms takes part in one test on their collective behalf. That eased the concern for large providers, but it still had to be provided for in the contract.

Standard cloud and software terms were frequently silent on cooperation with a customer’s regulator. Each gap had to be closed by amendment, addendum or replacement.

Audit rights that can actually be used

Unrestricted rights of access and audit sound simple and are not. A large cloud provider cannot admit every customer’s auditors to its data centers on demand without creating security risks of its own. Firms and providers worked toward practical arrangements. Firms relied partly on independent certifications and audit reports for routine assurance. They kept the contractual right to carry out their own audit when a specific concern arose. And some joined pooled audits, in which several customers jointly commission and share one audit of a provider.

What mattered was that the underlying right existed and could be exercised. A contract that offered only the provider’s standard reports, with no right to go further, left the firm unable to respond if a supervisor asked a question those reports did not answer.

Incident clauses that match reporting deadlines

DORA’s incident reporting regime set tight timelines. Under the final technical standards, a firm must send an initial notification of a major ICT-related incident within four hours of classifying it as major. That must happen no later than 24 hours after the firm becomes aware of it. An intermediate report follows within 72 hours, and a final report within a month.

A firm cannot meet those deadlines if its provider tells it about an incident days later. Contracts therefore needed notice obligations measured in hours for critical services, a named contact on each side, and a commitment to supply the information the firm needs for its own reports. Older contracts that required notice “without undue delay” left too much room for interpretation when the clock was running.

Why exit terms were hardest

Exit terms were often the hardest. A provider can accept an audit clause at little cost, but a commitment to support a transition to a competitor for a defined period, at defined rates, has a price.

Exit support works like a lease: a landlord will happily promise to fix the heating. A promise to keep the building open and staffed for months after you give notice, while you move to a rival’s property, is a different matter. Firms that asked for exit support only after deciding to leave found it was no longer available on reasonable terms. Exit support has to be negotiated when the contract is signed or renewed.

What a workable exit plan contains

A clause promising transition support is only half of an exit. The other half is the firm’s own plan. A workable plan names the events that would trigger it, such as provider insolvency, a serious breach, a supervisory instruction or an unacceptable price rise. It identifies at least one realistic alternative, whether another provider or bringing the service back in-house. It specifies the data the firm would need to take with it, in what format, and how it would be migrated and checked. And it estimates how long the move would take, what it would cost, and how the firm would run during the transition.

Some services have no realistic substitute in the short term. A core banking platform may take years to replace. For those, the exit plan becomes partly a continuity plan. It sets out how the firm would keep serving customers if the provider stopped working tomorrow, and what minimum service it could offer during a longer migration. Supervisors did not expect every critical service to be swappable overnight. They did expect firms to have thought it through and written it down.

Testing an exit plan rarely means actually leaving. In a tabletop exercise, business, technology, legal and procurement staff walk through the plan against a realistic scenario. It usually exposes the weak points: data the firm cannot extract, a dependency nobody listed, or a transition period far shorter than the migration would need.

Which contracts are in scope

The basic requirements applied to all ICT services, which in a mid-sized bank can mean hundreds of agreements: software licenses, cloud subscriptions, data feeds, managed security services and network carriers.

Intra-group arrangements count too, so a US parent providing technology to its EU subsidiary needed compliant intra-group agreements. Many groups had never written formal contracts between their own entities, or had written them as accounting documents rather than service commitments. That made them some of the easiest agreements to fix, since both sides answer to the same board, and some of the most surprising to discover.

Writing those agreements properly meant treating the group technology company as a provider like any other. The agreement had to describe the services, set service levels, cover data location and return, and give the subsidiary and its supervisor the access and audit rights DORA requires. It also had to work if the group were restructured or the subsidiary sold, when a friendly internal relationship could quickly become a commercial one. Groups that had relied on informal cost allocations found that the contract was the easy part. Agreeing measurable service levels between teams that had never been held to them was harder.

Building the register from scratch

The register was where the scope question became concrete. Firms found that their contract data lived in several places: procurement systems, legal document stores, finance systems that tracked invoices, and business units that had bought software on corporate cards. Reconciling those sources took months. Invoices often revealed providers that procurement had never recorded, and contracts sometimes covered services that had long since stopped.

Each entry needed more than a name and a date. The firm had to link the contract to the functions it supported, record the provider’s legal entity identifier and describe the service type. It also had to note where data was stored and processed, and assess how hard the provider would be to replace. That last judgment, substitutability, required input from the business and the technology teams as well as procurement. Many firms discovered that their first answers were optimistic.

Boundary cases also took time. Firms had to decide how to treat services bought from other regulated financial firms, hardware purchases, and services bundled inside larger agreements. Supervisory questions and answers helped over time, but the firm had to make and document its own call in the meantime.

Classify first, negotiate second

The heavier requirements depended on whether a service supports a critical or important function. That classification had to come first, because it determined which contracts needed the full set of clauses and which could be handled with a standard addendum. Firms that classified late spent their negotiating capacity on the wrong agreements.

Classification also had to be defensible to supervisors, so the reasoning for each function needed to be written down along with the result. A note saying “payments: critical” is a conclusion. A note explaining which customers and obligations depend on the payments service, and what would happen if it stopped, is a justification a supervisor can test.

The most defensible classifications started from the business rather than the contract list. A firm identified the services it provides to customers and the market, judged which ones would cause serious harm if disrupted, and then traced the ICT services each one depended on. Working in that direction surfaced dependencies that a contract-by-contract review missed, such as a small data provider whose feed a critical pricing process could not run without. Working in the other direction, from contracts to functions, tended to rate services by their cost or their visibility, which are poor guides to criticality.

The chain behind the provider

Subcontracting widened the scope. A provider supporting a critical function may rely on a cloud platform, an offshore support center and embedded third-party components. The firm’s risk does not stop at the company it signed with; it runs down a chain of suppliers the firm may never have heard of.

The chain also concentrates risk in ways a single firm cannot see. Many providers that look independent may run on the same small number of cloud platforms. A firm that diversified its software vendors could still find that most of them depended on one hyperscaler’s region. Recording the material subcontractors behind each critical service in the register was the first step toward seeing that concentration. Supervisors, aggregating registers across firms, would be able to see it across the whole sector.

DORA required firms to address material subcontracting, and the detailed technical standards were still being written in 2023. Contracts negotiated early needed language flexible enough to absorb standards not yet final, for example by committing both parties to update the agreement once those standards were settled.

The subcontracting question was also the one providers resisted most. Firms wanted notice of material subcontracting changes and the right to object or terminate. Providers, especially those built on layered cloud services, worried about giving every customer a veto over their own supply chains. Typical compromises gave the firm advance notice of material changes, a description of the risk assessment the provider had done, and a right to terminate if the change was unacceptable, without an outright veto.

When the contracts can be changed

This was the binding constraint. A firm’s contract portfolio has its own calendar. Some agreements renew within the window and can be renegotiated in the normal course. Others run past January 2025 and need an amendment the provider must agree to mid-term. Some auto-renew with notice periods that pass unnoticed if nobody is tracking them, locking the firm into old terms for another cycle.

Tracking those dates sounds like clerical work and often was not done well. Contract data sat in document stores where renewal terms were buried in clauses rather than recorded as fields. Firms that used the program to move contracts into a contract management system, with renewal dates, notice periods and key clauses captured as structured data, gained a lasting tool. The extraction effort was considerable, because someone had to read each agreement or check what software had pulled from it. The alternative was rediscovering the same facts at every renewal.

Bargaining power

Bargaining power varied sharply. A large bank negotiating with a niche vendor could insist on its own clauses. A small payment institution facing a hyperscale cloud provider, one of the handful of giant companies that run cloud computing at global scale, or a dominant core banking vendor usually could not.

Large providers responded by publishing standard DORA addenda, which saved time but meant accepting the provider’s interpretation. An addendum is a short add-on document that amends an existing contract without rewriting it. Firms had to decide where a standard addendum was good enough and where to spend scarce negotiating time.

What providers wanted from the process

Providers had their own constraints. A global software company serving thousands of customers across sectors cannot maintain thousands of bespoke contracts. It needs uniform terms, predictable audit arrangements and limits on liability. Mid-sized software vendors with few financial clients were often meeting these requirements for the first time and needed time to understand them. Some priced the new commitments into renewals.

Firms that understood those constraints negotiated better. Asking a provider for a clause it had already agreed with other financial clients was faster than drafting a new one. Industry groups and law firms circulated model clauses that providers grew used to seeing. A firm that came with a clear, short list of genuinely necessary changes usually got further than one that sent a long redline of its preferred positions.

The remediation plan

The practical tool was a contract remediation plan built from the portfolio itself. Each agreement got a criticality rating, a gap score against Article 30, a renewal or amendment date and a negotiation owner.

Critical services whose contracts did not renew before January 2025 went to the top, because they required providers’ cooperation outside the normal cycle. Procurement, legal, the business owner and the risk function had to work from the same list. In many firms that was the first time those teams had shared a single view of the vendor base.

Sequencing the work in waves

Most firms organized remediation in waves. The first wave covered critical-function contracts that would not renew before January 2025, because they required providers to agree to mid-term amendments. The second wave covered contracts that renewed within the window and could be fixed at renewal. The third wave was the long tail of lower-risk agreements, handled through a standard addendum sent in bulk and tracked to signature.

Each wave had its own measures. For the first wave, the useful metric was the number of critical contracts with all required clauses agreed. For the second, it was the share of renewals completed on compliant terms, with no auto-renewal on old ones. For the third, it was the proportion of signed addenda and the list of providers that had not responded. Reporting those numbers monthly let the management body see where the program stood.

One firm’s list

Suppose a payment institution’s remediation list shows a core processing contract supporting a critical function that runs well past January 2025, with weak exit terms. Its cloud provider offers a standard DORA addendum. A dozen smaller software tools renew within the window.

The firm puts the processing contract first and opens talks early, because it needs the vendor’s goodwill outside the renewal cycle. It reviews the cloud addendum against Article 30, judges it acceptable with one clarification, and signs. It folds the smaller tools into routine renewals using a standard clause set, and in doing so notices that three of them do much the same job, so it keeps one. By the deadline, its negotiating effort has gone where the risk is, and its vendor list is shorter than when it started.

The economics of remediation

The economics deserved attention. Remediation consumed legal and procurement capacity for two years. Providers sometimes priced new audit or exit commitments into renewals.

Firms that consolidated overlapping vendors during remediation reduced both the negotiating load and the ongoing oversight burden. Firms that patched every contract separately paid for the same clauses many times.

Where the cost landed

The direct costs were mainly people: lawyers, procurement specialists and risk analysts, plus external counsel for the hardest negotiations. The register and classification work drew in business owners and technology staff who had other jobs to do. Indirect costs came through providers’ prices, as new audit, incident and exit commitments were built into fees.

Some of that cost bought real value. A firm with a working exit plan and enforceable data return rights is better placed in a provider failure or a pricing dispute. Some of it was friction, especially where firms duplicated effort that a group-wide template or an industry clause set could have saved. The firms that kept costs down treated the program as a portfolio exercise, not hundreds of separate negotiations.

The strongest objections

Skeptics raised three serious objections to putting contracts at the center. The first was that contracts do not prevent outages. A clause promising assistance will not stop a faulty software update from crashing systems; only engineering, testing and redundancy do that. The second was that small firms gain little from negotiating with giant providers that dictate terms anyway, so the exercise mostly produced paperwork. The third was that direct oversight of critical providers would make firm-level contract terms less important.

Each objection has some truth. Contracts are a floor, not a resilience strategy. But a contract is what gives a firm the right to the information, testing and exit support that its engineers need to build resilience around a provider. Without it, the firm depends on goodwill at the worst possible time. Small firms may have little bargaining power, but the standard addenda that large providers published were themselves a product of the regulation, and they moved baseline terms for everyone. Direct oversight addresses risks across the system; it does not give an individual firm its own data back or an orderly way out.

For a board, the useful framing is that DORA compliance, besides being a cost to minimize, was a rare forced review of every technology relationship the firm had. Used well, it produced a cleaner vendor base, clearer accountability and stronger exit options, all of which have value long after the regulator’s deadline. Used poorly, it produced a pile of addenda and the same sprawl as before.

Ownership at the top is explicit. DORA places responsibility for ICT risk with the firm’s management body, its board and senior executives, rather than leaving it with the technology department. In practice that means directors should expect to see the remediation plan, understand where the critical contracts stand and challenge decisions to accept a provider’s standard terms on important services. A board that only hears “we are on track” is not exercising that responsibility.

DORA backs that responsibility with specific duties. The management body must define and approve the ICT risk management framework, approve the policy on the use of ICT third-party services, and keep its own knowledge of ICT risk up to date. Directors who had treated technology contracts as an operational matter were now expected to understand, at least in outline, which providers the firm could not do without. They also needed to know how it would cope if one failed.

There is also a reputational dimension. When a technology provider fails, customers do not distinguish between the bank and its supplier. A firm that can show it had enforceable rights to its data, to incident help and to an orderly exit is in a far better position, with customers and with supervisors, than one that relied on goodwill.

Habits of the firms that finished well

The firms that came through in good order kept a single list of every ICT agreement, owned jointly by procurement, legal, the business and risk, with renewal dates tracked automatically; a notice period that passes unnoticed can lock in old terms for years. They wrote down a defensible classification of critical or important functions before negotiations began, rather than spending effort on full clauses for minor contracts. They had a clear policy on when a provider’s standard addendum was acceptable, and read each one, since even a fine addendum is still the provider’s interpretation of the firm’s obligation. Their exit plans for critical services had been worked through in detail as well as referenced in the contract, and their intra-group arrangements were documented as real service agreements. They also priced exit support before they needed it, asked what their key providers relied on in turn, and used the reopening of contracts to stop paying several vendors for overlapping services.

The firms that struggled usually started with policy and left contracts for later. Policies can be written in weeks; contracts depend on someone else’s calendar. Many also treated the deadline as the finish line, though new contracts, renewals and changing standards mean the work never fully stops.

What contract owners should be able to show about critical providers

1. Do we have one list of every technology contract we hold, including agreements with our own group companies?
2. Which of those services support critical or important functions, and where is our written reasoning for each?
3. For each critical service, where does the contract say we can get our data back, inspect how the provider runs the service and leave in an orderly way?
4. Which critical contracts run past the next renewal point, and which renew automatically without anyone watching the notice period?
5. Where have we accepted a provider’s standard addendum, and who decided it was good enough?

A firm that can answer these crisply has done more than comply. It knows what it depends on and what it can do when a dependency fails.

With hindsight

DORA applied on schedule on January 17, 2025, and contract work did not end there. Deadlines in regulation tend to mark the start of supervision rather than the end of effort, and this one was no exception.

Six months before that date, the risk DORA addressed had become very visible. On July 19, 2024, a faulty content update from the security vendor CrowdStrike crashed millions of Windows computers worldwide. Banks, insurers, payment firms and exchanges were among the organizations affected. The outage was caused by a single provider’s routine change, and recovery depended on firms’ own ability to restore systems and on how quickly the provider supplied guidance. Contracts did not prevent it. They did determine what information firms could demand afterward and how they would account for the incident to supervisors.

The subcontracting standards took a detour. On January 21, 2025, the European Commission told the European Supervisory Authorities, the three EU-level bodies that coordinate supervision of banking, securities and insurance, that it was rejecting their draft because parts of it went beyond the mandate DORA gave them, and proposed amendments. The authorities accepted the narrower text in March 2025. This is where flexible drafting mattered: a contract that committed both parties to update it once the standard was final could absorb a rule that landed after the law already applied, while a contract without such language would need to be reopened.

The register, too, became a recurring obligation rather than a one-time filing. DORA requires firms to report to their supervisor at least yearly on new ICT arrangements, and supervisors can request the full register at any time. A register assembled in a rush for the first submission, with gaps filled by estimate, will be compared with later versions. Errors that were tolerable in a first collection become harder to explain once supervisors are using the data to map dependencies across the sector and to judge which providers are critical.

Competent authorities, the national supervisors, had to pass the first registers of information to the ESAs by April 30, 2025. The register of information is the structured list of every ICT arrangement a firm holds. The ESAs’ roadmap used those registers to classify providers that summer and then designate critical ICT third-party providers for direct oversight.

Other parts of the picture moved more slowly. Most member states missed the October 2024 deadline to transpose NIS2, and the Commission opened infringement proceedings against many of them in late 2024. For financial firms, DORA’s direct effect avoided that kind of delay, which was one argument for choosing a regulation in the first place.

Regulators outside the EU pursued parallel goals by different routes. In June 2023 the US federal banking agencies issued final interagency guidance on third-party risk management. It sets out expectations across the lifecycle of a relationship, from planning and due diligence to contract negotiation, monitoring and termination, without DORA’s prescriptive list of clauses. The United Kingdom created its own critical third parties regime through the Financial Services and Markets Act 2023, giving its regulators powers over designated providers to the financial sector. A group operating in several jurisdictions now faces overlapping regimes that ask similar questions in different forms.

That oversight does not relieve firms of their own contractual duties. A small firm’s own contract matters just as much when supervisors are watching its cloud provider directly. Direct oversight addresses risk across the whole system, while each firm remains answerable for its own arrangements, its own data and its own exit plans.

The lasting value of the work lies in the tool firms built along the way. A single remediation plan built in 2023 and 2024 can be kept as a living contract register, updated at every renewal and new purchase. The same register serves US third-party risk expectations, so groups operating on both sides of the Atlantic need not maintain two separate views of the same vendors. Whether the firm met the deadline matters less now than whether the list it built is still current.