DORA for Malaysian IT providers serving EU banks and insurers

01Where DORA stands in late 2026

The Digital Operational Resilience Act (opens external site) has applied since 17 January 2025. As a regulation it needs no transposition; national legislation mostly names the supervisors and fixes the penalties. The working detail sits in Commission technical standards covering the risk-management framework, the classification and reporting of incidents, the register of information, contract policy, subcontracting and TLPT, the threat-led form of penetration testing.

For financial firms, DORA takes over from NIS2 on ICT risk, incident reports and supervision. In November 2025, EBA, EIOPA and ESMA, the EU’s three financial supervisory authorities, named the first critical ICT providers (opens external site), which they now oversee directly.

02Financial entities and their ICT providers

Twenty kinds of financial entity are covered. Banks, payment and e-money firms, investment firms, insurers and their intermediaries are the obvious ones; crypto-asset firms, trading venues, fund managers, pension funds, rating agencies and crowdfunding platforms are covered too. The rules scale with size, risk and complexity (Article 4), and smaller entities can use a lighter framework (Article 16).

Any undertaking that supplies ICT services counts as an ICT third-party service provider, and ICT services are defined widely as digital and data services delivered through ICT systems on a continuing basis. Hosting, managed services, SaaS, data services and the upkeep and support of applications usually qualify. No DORA supervisor oversees a provider in Malaysia unless it has been designated critical. Its EU clients, though, remain fully responsible and carry the requirements into every contract (Articles 28 and 30).

03ICT risk sits with the board

Under Article 5, final responsibility for ICT risk rests with the management body. It sets and approves the risk-management framework, the resilience strategy and the appetite for risk; signs off the continuity policy and the plans for response and recovery; and approves, then reviews, how third-party ICT services may be used. Its members keep their own knowledge current, including through regular training.

04Reporting a major incident: three deadlines

Article 18 lists the criteria for classifying ICT incidents, and Delegated Regulation (EU) 2024/1772 (opens external site) works them out: how many clients and transactions are hit, how long the outage lasts, how widely it spreads, what data is lost, how critical the affected services are and what it costs. Reporting a major incident to the authority happens in three steps, timed by Delegated Regulation (EU) 2025/301 (opens external site):

Clients whose financial interests suffer must be told without undue delay. Reporting may be delegated to someone else, yet the entity remains responsible for it (Article 19(5)).

For a provider this becomes concrete. Each ICT contract must oblige the provider to help when an incident linked to its service occurs, free of charge or at a price agreed beforehand (Article 30(2)(f)). The client’s four hours are only achievable if the provider’s monitoring, logs and escalation contacts already exist.

05Testing, from annual checks to TLPT

Article 24 calls for a testing programme driven by risk and run by independent testers, internal or external, with suitable tests at least once a year on every system and application behind a critical or important function. Entities singled out by their authority must also commission TLPT against live production systems at intervals of no more than three years, under Delegated Regulation (EU) 2025/1190 (opens external site), which builds on the TIBER-EU framework.

When a TLPT covers a provider’s services, the entity must secure that provider’s participation (Article 26(3)), and the contract behind a critical or important function has to require it (Article 30(3)(d)). Where joining one client’s test could put the provider’s other clients at risk, DORA allows a pooled test, with the provider engaging an external tester for several financial entities at once (Article 26(4)).

06Managing providers: strategy, register, exit

Article 28 folds third-party ICT risk into the entity’s risk-management framework, and the entity stays answerable for compliance however much it outsources. In practice:

• A third-party strategy, including a policy on services that underpin critical or important functions, which the board revisits at regular intervals.
• A register of information covering each ICT contract, kept per entity and per group, marking those that support critical or important functions. Implementing Regulation (EU) 2024/2956 (opens external site) prescribes the templates. Entities report on the register to their authority every year and hand over the whole register when asked.
• Checks before signing: whether a critical or important function is involved, the risks including concentration on a few providers, the provider’s suitability and possible conflicts of interest. Providers are expected to apply suitable security standards, and the newest and strongest ones when they support critical or important functions.
• Rights to terminate, for example after a serious breach by the provider, shown shortcomings in how it manages ICT risk, or conditions that stop effective supervision.
• Exit strategies for services behind critical or important functions, written down and tested, so that a change of provider leaves the business, its compliance and its clients unharmed.

Minimum contract content

Article 30 fixes the minimum content. The contract is written, held in a single document together with the service levels, and covers at least:

• a full description of the services, and whether and how subcontracting is allowed;
• the places where the service runs and where data is kept or handled, with notice before either changes;
• how the availability, authenticity, integrity and confidentiality of data, including personal data, are protected;
• access to data, its recovery and its return in an accessible format if the provider becomes insolvent, stops the service or the contract ends;
• descriptions of the service levels;
• help with incidents connected to the service, without charge or at a pre-agreed price;
• full cooperation with supervisory and resolution authorities;
• when and how either side may end the contract, with minimum notice;
• the provider’s attendance at the entity’s security awareness and resilience training.

For critical or important functions, Article 30(3) goes further: measurable service targets, duties to notify and report, contingency plans the provider implements and tests, a role in TLPT, full rights of access, inspection and audit for the entity and its supervisor, and an exit plan with a mandatory transition period. Subcontracting of such services brings further checks under Delegated Regulation (EU) 2025/532 (opens external site).

07Critical ICT third-party providers

Article 31 has the European Supervisory Authorities designate the ICT providers that are critical to the financial sector. They look at systemic impact, how important the dependent entities are, the role the provider plays in critical or important functions and how hard it would be to replace. Each designated provider gets one of the three authorities as Lead Overseer, with powers to request information, investigate, inspect and issue recommendations.

The first list (opens external site), dated 18 November 2025, named 19 providers, among them cloud and data centre operators, telecoms and IT service companies, and suppliers of market data and business software. None of this lightens the financial entity’s load: for every designated provider it still needs register entries, compliant terms and an exit plan.

Location matters once a provider is designated. A critical provider established outside the EU, in Malaysia for example, has twelve months after designation to set up a subsidiary in the Union (Article 31(12)); EU financial entities can only keep using its services on that basis.

08At home: RMiT and the SC guidelines

A Malaysian IT provider serving EU financial entities often serves Malaysian ones as well, and at home the rules come from Malaysian regulators, not from DORA. Bank Negara Malaysia (BNM) sets its expectations for financial institutions in the policy document Risk Management in Technology (RMiT) (opens external site); the revised version has been in effect since 28 November 2025. For the capital market, Securities Commission Malaysia (SC) issued its Guidelines on Technology Risk Management (opens external site), revised and in effect since 19 August 2024.

The texts are separate, and meeting one does not mean meeting another. The evidence behind them overlaps a great deal, though: what you provide and from where, contract terms, incident procedures, tested recovery and exit plans. A provider that keeps one current set of records, mapped to each text, can answer a Malaysian bank’s RMiT questions and an EU bank’s DORA questions without starting twice.

09What a provider in Malaysia should have ready

Few suppliers will ever be designated critical. Every supplier, though, feels DORA through contracts, due diligence and audits, and those with the following ready move faster through procurement and make their client’s exchanges with its supervisor easier:

• Data for the register. Which legal entity contracts, under which identifiers, what it provides for which functions, from where, and through which subcontractors.
• Article 30 terms on the shelf. One prepared DORA addendum covering the general and the enhanced terms spares both sides a clause-by-clause negotiation.
• Evidence for incidents. Monitoring, logs with trustworthy time stamps and a notification routine fast enough for the client to classify the incident and file its report in time.
• Continuity that has been tested. Contingency plans and restore tests, each with a date and a result.
• Security that can be shown. Recognised security standards, controlled access, secure development and a vulnerability process, independently evidenced where possible.
• Readiness for audits and tests. A practical way to receive auditors and inspectors and to join a TLPT, pooled where that suits.
• A worked-out exit. Data handed back in formats the client can use, documentation, and help through an agreed handover period.

That is our own practice when we supply financial institutions: DORA provisions agreed in the contract, incidents reported on the channel we agreed, exit plans on paper, participation in resilience tests and the data your register asks for. The trust and compliance page describes it, with our ISO/IEC 27001 certified information security management system.

10Next steps for entity and provider

1. 01Finish the register. Link every ICT contract to the functions behind it and mark those that are critical or important.
2. 02Close contract gaps. Compare every contract with Article 30 and agree an addendum for what is missing.
3. 03Line up incident handling. Settle with every critical provider what data feeds classification, who calls whom and how fast, then test it.
4. 04Plan tests with providers. Bring them into the testing programme and, where it applies, into the scope of a TLPT.
5. 05Write and rehearse exits. Per critical or important function: the fallback option, how data comes back and how long the transition lasts.
6. 06Watch concentration. Too many critical functions on one provider is a concentration risk to record and control (Article 29).

11The authorities on each side

DORA is one text across the EU, yet most financial entities answer to a national supervisor: depending on its type, that is a central bank, a prudential or a markets supervisor, and significant banks deal with the ECB. Formats and channels for registers and incident reports, and responsibility for TLPT, are decided nationally. In Malaysia, BNM regulates banks, insurers and takaful operators and the SC regulates the capital market; their requirements apply alongside whatever an EU client passes on, never in its place.

12What to watch in the coming months

• What supervisors prioritise and find when they review registers and incident reports.
• Oversight of designated critical providers by their Lead Overseers, and recommendations that touch services you rely on or deliver.
• The Digital Omnibus proposal (opens external site), COM(2025) 837, under which major DORA incident reports would go through a single ENISA entry point. It was still with the European Parliament in October 2026, and current channels and time limits hold until it applies.
• Further revisions of RMiT by BNM and of the SC guidelines, where you also serve Malaysian institutions.

Outside the financial sector, NIS2 sets comparable supply-chain duties; our article on NIS2 for Malaysian providers covers them. The European Supervisory Authorities collect the technical standards and the oversight framework on their DORA pages (opens external site).