DORA for SaaS vendors based in Singapore

Who this is relevant to

Singapore is a regional hub for banking, payments and insurance technology, and a good share of that business has an EU leg: a European branch, an EU-regulated subsidiary of an Asian group, or a European bank's regional processing arrangement. If any part of the entity you are contracting with sits inside the EU's financial regulatory perimeter, this reaches you.

• —SaaS and infrastructure vendors selling into banks, insurers, payment institutions, asset managers or trading venues with an EU footprint
• —Vendors already inside a European bank's approved supplier list, now being re-papered against new contract terms
• —Fintech and regtech companies whose product touches core banking, payments, clearing or trading functions
• —Vendors who have received a DORA-branded due diligence questionnaire from an existing customer for the first time

How DORA reaches a vendor that is not a European financial firm

DORA is addressed to EU financial entities: banks, insurers, investment firms, payment institutions, trading venues and a long list of similar regulated bodies. It sets out how they must manage ICT risk, including the risk that sits with their suppliers.

A Singapore SaaS vendor is not itself a financial entity, and DORA does not address it directly unless it falls under the critical ICT third-party provider designation described below. What changes is your customer's obligation, and your customer passes it to you through the contract, because their regulator holds them accountable for their supply chain, not just their own systems.

There is a second, narrower route: the European Supervisory Authorities can designate certain ICT third-party providers as “critical”, which brings that provider under direct EU oversight. This applies to a small number of very large infrastructure and cloud providers. If you have not been formally notified of such a designation, assume you have not received it. It is not a status you can infer from the size of your customer base.

Direct application vs customer flow-down

Where DORA reaches a Singapore SaaS vendor, it does so as a flow-down obligation rather than a direct one, unless that vendor is one of the small number formally designated as critical ICT third-party providers. That distinction changes what “compliance” even means for you: there is no DORA certificate to obtain and no filing to make. What exists is a set of contract terms your EU financial customer must include, and a register entry describing your service that your customer maintains, not you.

Your job is to be able to agree to those terms, evidence the operational resilience behind them, and answer the questions your customer needs answered to complete their own register and risk assessment.

• —Direct: applies to a handful of designated critical ICT third-party providers, formally notified by an EU authority
• —Flow-down: applies to you through mandatory contract clauses your EU financial customer must include (the normal case)
• —Your customer classifies you, not the reverse (see below)

What an EU financial customer will ask you to produce

The questionnaire usually arrives looking like a standard vendor security review with a handful of DORA-specific additions layered on top.

• —Confirmation you accept the mandatory ICT third-party contract terms: exit rights, audit and access rights, service level detail, subcontracting notification
• —A description of your service precise enough for your customer to record it correctly in their register of information
• —Your position on subcontracting: who you rely on, where, and how you notify changes
• —Business continuity and disaster recovery evidence, including test results, not just a plan
• —Incident detection and notification timelines you can commit to contractually
• —Confirmation of audit and access rights the customer's regulator expects them to hold over material suppliers
• —An exit and termination plan describing how the customer's data and workloads leave your service without unacceptable disruption
• —Where relevant, evidence that any subcontractor you rely on for a material part of the service accepts equivalent terms

Common misconceptions

“DORA does not apply to us because we are not a financial institution.”

Correct as a matter of direct legal application for almost everyone reading this. But your EU financial customer's obligation to manage you as an ICT risk is real, contractual, and enforced through the contract regardless of your own regulatory status.

“We can decide for ourselves whether we support a critical or important function.”

That classification is made by the financial entity, based on their own operations and regulatory exposure, not by you. If a customer has not told you the classification, the honest answer is that you do not know it. Do not guess in a security questionnaire.

“One customer's DORA terms will do for all our EU financial customers.”

Contract terms vary by customer and by how critical the function is judged to be. Treat each EU financial relationship as its own review, even where the paperwork looks similar.

“Being a large or well-known vendor means we are a critical ICT third-party provider.”

Designation is a formal EU regulatory act, not a reputational judgement. Very few providers hold it. Assume you do not unless you have been formally told otherwise.

“Our SOC 2 report already covers this.”

A SOC 2 report is useful evidence but does not itself satisfy the specific contractual terms DORA requires: audit rights, exit planning, subcontracting notification and register data are additional, not substitutable.

Practical checklist

1. 01Identify which of your customers are EU financial entities, including EU branches or subsidiaries of Asian groups
2. 02Ask directly whether your service has been classified as supporting a critical or important function. Do not assume either answer
3. 03Review your standard contract for exit rights, audit and access rights, and subcontracting notification, and be ready to accept stronger versions for EU financial customers
4. 04Maintain a current subcontracting map for the service you provide to each EU financial customer
5. 05Test your business continuity and disaster recovery plan, and keep the test evidence, not just the document
6. 06Define incident detection and notification timelines you can actually meet before you commit to them contractually
7. 07Prepare a written exit and data-portability plan for the service, not just a data export feature
8. 08Nominate someone who can answer a customer's register-of-information questions about your service without a lengthy internal chase
9. 09Confirm your key subcontractors are willing to accept flow-down terms if a customer asks for that assurance

Singapore context

Singapore's own financial regulator has for some years pushed banks and insurers towards more rigorous outsourcing and technology risk oversight of vendors, so many Singapore ICT suppliers to MAS-regulated firms already operate under a comparable discipline domestically. DORA does not replace that; it adds a distinct, EU-specific contractual layer that applies only where the counterparty is itself inside the EU financial perimeter.

Because Singapore is a regional processing and data-hub location for Asian and European banking groups, it is common for the EU dimension to appear indirectly (a Singapore team supporting a European branch's systems, for instance) rather than through a direct EU banking relationship. Establishing which of your customer relationships actually carries an EU financial-entity counterparty is the first practical step, not an afterthought.

Official EU sources

Every conclusion on this page traces back to the primary legal text. We link only to official EU sources.

• Regulation (EU) 2022/2554 — Digital Operational Resilience Act · Read on EUR-Lex (CELEX 32022R2554)Verified 2026-08-17