Skip to main content
FromNine
Menu

CloudArchitecture

DORA and ICT third-party providers: what EU financial entities expect from suppliers in India

When an Indian company runs applications, infrastructure or data services for a European bank or insurer, DORA governs that relationship. The regulation turns operational resilience into duties for the financial entity, and most of them reach the supplier through the contract. What DORA requires, what the designation of critical providers changed, how it compares with the rules Indian teams already know, and what to prepare.

By
FromNine editorial team
Published
Reading time
11 min read

Key takeaways

  1. Since 17 January 2025 DORA has applied directly in every Member State, and an EU financial entity stays fully accountable for its ICT risk however much it outsources, to India or anywhere else.
  2. Article 30 clauses belong in every ICT contract wherever the provider is based; for services behind critical or important functions they extend to audit rights, a role in resilience testing and a tested exit with a transition period.
  3. A major incident must reach the supervisor within 4 hours of being classified and no later than 24 hours after detection; Indian teams that already work to CERT-In’s six-hour rule know how little time that leaves.
Contents

DORA at the end of 2026

Regulation (EU) 2022/2554, the Digital Operational Resilience Act (opens external site), has been in application since 17 January 2025. No national transposition is needed: the regulation binds directly, and national laws mostly name the supervisors and set penalties. The working detail lives in Commission technical standards covering the ICT risk-management framework, how incidents are classified and reported, the register of information, contractual policies, subcontracting and threat-led penetration testing.

Within the EU financial sector, DORA displaces the NIS2 rules on ICT risk management, incident reporting and supervision. The three European Supervisory Authorities, EBA, EIOPA and ESMA, released (opens external site) their first list of critical ICT third-party providers under direct EU oversight on 18 November 2025.

Table 1DORA in five areas
AreaArticlesMain requirement
ICT risk management5 to 16A framework signed off by the board that identifies, protects, detects, responds and recovers, with backup policies, lessons learned and crisis communication.
ICT-related incidents17 to 23A way to manage incidents, grade them on shared criteria and report the major ones to the supervisor.
Resilience testing24 to 27A testing programme based on risk, annual tests of the systems behind critical or important functions, and threat-led penetration testing (TLPT) where the supervisor requires it.
ICT third-party risk28 to 44A strategy for supplier risk, a register covering every ICT contract, mandatory clauses, exit strategies, and EU oversight of critical providers.
Information sharing45Optional arrangements among financial entities to share intelligence on cyber threats.

Who is covered: financial entities and the firms that serve them

DORA names twenty kinds of financial entity. Banks, payment and e-money institutions, investment firms and fund managers are covered, and so are insurers and their intermediaries, crypto-asset service providers, trading venues, occupational pension schemes, crowdfunding platforms and credit rating agencies. Proportionality runs through the text: Article 4 adjusts the duties to an entity’s size, risk and complexity, and Article 16 offers a lighter regime to some smaller firms.

DORA reads “ICT third-party service provider” widely: any undertaking that supplies digital and data services through ICT systems, on a continuing basis, to one or more users inside or outside the organisation. Hosting, SaaS, managed services, data services and the upkeep and support of applications normally qualify, which describes much of the work Indian IT services companies carry out for European financial groups. A provider is not itself supervised unless it is designated critical, yet every customer writes DORA duties into its contract.

The board owns ICT risk

Article 5 puts final accountability for ICT risk on the management body. The board sets up the ICT risk-management framework and keeps watch over it, decides the resilience strategy and how much risk the entity will tolerate, signs off continuity, response and recovery plans, and periodically re-examines the policy that governs third-party ICT services. Board members have to keep their knowledge current, among other things through regular training.

Indian regulated entities have comparable rules at home, such as the 2025 directions of the Reserve Bank of India (RBI) on managing risks in outsourcing, which extend to IT services, and the Cybersecurity and Cyber Resilience Framework (CSCRF) of the Securities and Exchange Board of India (SEBI) for its regulated entities. A provider that already answers RBI or SEBI questions will find DORA questions familiar in kind, but the answers have to follow the EU texts.

Reporting a major incident in three stages

The financial entity grades each ICT-related incident against the Article 18 criteria, worked out in Delegated Regulation (EU) 2024/1772 (opens external site): the clients and transactions hit, how long services were down, geographical spread, lost data, how critical the affected services are and the economic impact. Major incidents go to the competent authority in three stages, on deadlines that Delegated Regulation (EU) 2025/301 (opens external site) fixes:

Table 2Deadlines for reporting a major ICT-related incident (DORA Article 19 and Delegated Regulation (EU) 2025/301)
StageDeadline
Initial notification4 hours after the incident is classified as major, and 24 hours at most after the entity learns of it.
Intermediate report72 hours after the initial notification; updated promptly afterwards and in any case once normal operations are back.
Final reportOne month at most after the latest updated intermediate report, when the root cause analysis is finished.

Clients whose financial interests suffer must hear about it promptly. The entity may hand the reporting to a third party but keeps full responsibility for it (Article 19(5)).

For the supplier, this is where DORA becomes concrete. Each ICT contract has to oblige the provider to help when an incident linked to its service occurs, either free of charge or at a price agreed beforehand (Article 30(2)(f)). The customer’s four-hour window works only if the provider’s monitoring, logs and escalation contacts are in place before anything goes wrong.

Indian teams start with an advantage. Since the CERT-In Directions of 28 April 2022, listed cyber incidents must be reported to the Indian Computer Emergency Response Team (CERT-In) within six hours of being noticed, and ICT logs must be retained with system clocks synchronised. A provider whose detection and escalation already meet that rule has much of what a DORA customer needs. What changes is the recipient, the classification criteria and the content of each report, so the two procedures should be documented side by side.

Resilience testing and TLPT

Under Article 24 the entity needs a testing programme driven by risk and carried out by independent testers, internal or external, with every ICT system and application behind a critical or important function tested at least once a year. Entities singled out by their supervisor must also run threat-led penetration tests on live production systems, once every three years at the latest, as set out in Delegated Regulation (EU) 2025/1190 (opens external site), which builds on the TIBER-EU framework.

When a TLPT covers services a provider delivers, the entity has to secure that provider’s participation (Article 26(3)), and the contract for a critical or important function must already oblige it (Article 30(3)(d)). If joining the test could hurt the provider’s other customers, DORA allows a pooled test, for which the provider engages one external tester to act for several financial entities together (Article 26(4)). For a provider in India this means agreeing test windows, tester access and a named coordinator in advance, not after the scoping letter arrives.

Supplier risk: strategy, register and exit

Article 28 folds ICT third-party risk into the wider risk-management framework, and outsourcing never transfers the entity’s responsibility for compliance. What the entity has to do:

  • Set a third-party risk strategy, including a policy for ICT services behind critical or important functions, which the board revisits at regular intervals.
  • Maintain a register of information that lists every ICT arrangement for the entity and the group and singles out those behind critical or important functions. The templates come from Implementing Regulation (EU) 2024/2956 (opens external site); the supervisor receives a report on the register every year at least, and the full register on request.
  • Do the homework before signature: which function the service supports and how critical it is, the risks involved, concentration among them, the provider’s fitness for the job and any conflict of interest. Providers should apply sound information security standards, and for critical or important functions the most up-to-date ones of the highest quality.
  • Keep the right to end the contract, for example after a serious breach by the provider, demonstrated gaps in how it manages ICT risk, or conditions that get in the way of supervision.
  • Prepare to leave. For each service behind a critical or important function, a written and tested exit strategy that lets the entity switch without stopping its business, losing compliance or hurting its clients.

Clauses every ICT contract needs

Article 30 lists the minimum content. The whole arrangement, service levels included, must be set down in one written document covering at least:

  • what the provider does, function by function and service by service, and whether it may subcontract and on what terms;
  • the places where services are delivered and data is processed and stored, India included where that applies, with advance notice of any move;
  • safeguards for the availability, authenticity, integrity and confidentiality of data, personal data among it;
  • how the entity gets its data back, in a usable and accessible format, if the provider becomes insolvent, stops trading or the contract ends;
  • the service levels described;
  • help during ICT incidents linked to the service, free of charge or at a price fixed beforehand;
  • cooperation in full with supervisors and resolution authorities;
  • when either side may terminate, and the minimum notice;
  • the provider’s involvement in the entity’s security awareness and digital resilience training.

Contracts for services behind critical or important functions carry more under Article 30(3): measurable performance targets, both quantitative and qualitative; duties to notify and report; contingency plans that the provider puts in place and tests; participation in TLPT; unrestricted access, inspection and audit rights for the entity and its supervisor; and an exit strategy with a mandatory transition period. Delegated Regulation (EU) 2025/532 (opens external site) adds what the entity has to evaluate before such services are subcontracted, which matters when an Indian provider relies on its own subcontractors or group companies.

Critical providers and the EU subsidiary rule

Article 31 lets the European Supervisory Authorities designate ICT providers as critical for the EU financial sector. They weigh systemic impact, how important the dependent financial entities are, the provider’s place in critical or important functions and how hard it would be to substitute. Each designated provider gets a Lead Overseer drawn from the three authorities, with powers to request information, investigate, inspect on site and issue recommendations.

The first list (opens external site), dated 18 November 2025, named 19 providers: cloud and data centre operators, telecoms companies, IT service firms, market data vendors and enterprise software houses. None of this relieves the financial entity, which must still hold a register entry, contract clauses and an exit strategy for every designated provider it uses.

One provision matters especially for large providers based outside the Union. Under Article 31(12), financial entities may use an ICT third-party provider established in a third country and designated as critical only if that provider has set up a subsidiary in the Union within the 12 months following its designation. Most Indian suppliers will never be designated, but a large provider that could be should plan its EU corporate structure before the question arises.

What a provider in India should have ready

Very few suppliers to financial entities will ever be designated critical, yet each of them meets DORA through contracts, due diligence and audits. A provider that can hand over the following up front speeds up procurement and gives its customer an easier conversation with the supervisor:

  • Register information. Everything the customer’s register asks for: the legal entity and its identifiers, each service and the function behind it, where delivery happens and data sits, any location in India included, and every subcontractor in the chain.
  • A DORA addendum. One standard set of clauses covering both Article 30 lists, so each contract does not begin from a blank page.
  • Incident evidence. Monitoring, reliably timestamped logs and an alerting routine that allows the customer to grade and report an incident within hours; teams already working to CERT-In’s six-hour rule can extend that routine to the customer’s channel.
  • Continuity that has been tested. Contingency plans plus restore tests, each with its date and result.
  • Security on paper and in practice. Security standards, access control, secure development and vulnerability handling, with independent evidence wherever it exists.
  • Readiness for audits and testing. A workable process for receiving auditors and inspectors from the EU, and for joining TLPT, pooled tests included where suitable.
  • An exit plan. Data handed back in formats the customer can use, documentation, and help with the transition for an agreed period.

FromNine works on these terms as an ICT supplier to EU financial entities. We agree the clauses DORA requires, report incidents through the channel set in the contract, keep exit plans documented, take part in resilience tests and give customers what their register needs. The trust and compliance page sets out our approach, including our ISO/IEC 27001 certified information security management system.

A joint plan for the entity and its supplier

  1. Finish the register. Link each ICT contract to the functions it serves and flag the critical or important ones.
  2. Close contract gaps. Test each contract against Article 30 and agree an addendum where clauses are missing.
  3. Rehearse incidents together. With each critical supplier, settle what data feeds the classification, who calls whom and how fast, and then practise it.
  4. Plan tests with suppliers. Bring them into the testing programme and, where relevant, into the scoping of a TLPT.
  5. Write and rehearse exit strategies. For each critical or important function: alternatives, data return and the transition period.
  6. Track concentration. Several critical functions depending on one provider is a concentration risk that Article 29 asks you to document and manage.

Supervisors in the EU, and the rules at home

Every Member State applies the same DORA text, yet supervision of most financial entities is national. Depending on the type of entity, that means the central bank, the prudential regulator or the securities regulator, and for significant banks the ECB. National authorities choose the format and channel for registers and incident reports and decide who runs TLPT. Your customer’s supervisor therefore shapes what it will ask of you.

An Indian provider that also serves Indian banks, NBFCs or market intermediaries works under RBI and SEBI requirements at the same time. Keep the two sets of obligations visible side by side, because the reporting clocks, recipients and formats differ.

Developments to follow

  • Supervisory priorities and review findings on registers of information and incident reports.
  • Lead Overseer activity towards critical providers, and any recommendation that touches services you deliver or rely on.
  • The Digital Omnibus proposal (opens external site) of the Commission, COM(2025) 837, which would send DORA major incident reports to one entry point run by ENISA. In October 2026 the European Parliament was still considering it; until it is adopted and applies, today’s channels and deadlines stand.

Outside finance, comparable supply-chain duties come from NIS2; see our article on NIS2 and software suppliers. The European Supervisory Authorities maintain a summary of the technical standards and of the oversight arrangements on their DORA pages (opens external site).

Sources

  1. EUR-Lex. Regulation (EU) 2022/2554 (Digital Operational Resilience Act) (accessed )
  2. EUR-Lex. Commission Delegated Regulation (EU) 2024/1772 (classification of ICT-related incidents) (accessed )
  3. EUR-Lex. Commission Delegated Regulation (EU) 2025/301 (content and time limits of incident reports) (accessed )
  4. EUR-Lex. Commission Implementing Regulation (EU) 2024/2956 (register of information templates) (accessed )
  5. EUR-Lex. Commission Delegated Regulation (EU) 2025/532 (subcontracting of ICT services) (accessed )
  6. EUR-Lex. Commission Delegated Regulation (EU) 2025/1190 (threat-led penetration testing) (accessed )
  7. ESMA. European Supervisory Authorities designate critical ICT third-party providers (accessed )
  8. ESMA, on behalf of the Joint Committee of the ESAs. List of designated critical ICT third-party service providers (accessed )
  9. EUR-Lex. Proposal for a Regulation on the simplification of the digital legislative framework (Digital Omnibus), COM(2025) 837 (accessed )
  10. ESMA. Digital Operational Resilience Act (DORA) (accessed )

Supplying ICT services to an EU bank or insurer?

Whether you are an EU financial entity or an ICT provider delivering to one, we can help with the practical side of DORA: register data, incident evidence, recovery that has been tested, support during resilience tests, and exit plans. Your counsel makes the legal assessment.