DORA for SaaS vendors based in Australia

Who this is relevant to

Australian software vendors are increasingly landing contracts with European banking, insurance and payments groups directly, or through the European arm of a global financial institution that also operates locally. The test is where the entity signing the contract sits in the EU's regulatory perimeter, not where your own company is based.

• —Vendors selling core platform, infrastructure or SaaS tooling into EU-regulated banks, insurers, payment institutions, asset managers or trading venues
• —Vendors already on a European bank's supplier panel, now being asked to re-sign under updated contract terms
• —Fintech and regtech companies whose product sits inside payments, clearing, trading or core banking workflows
• —Anyone who has just received a due diligence pack with “DORA” printed on the cover for the first time

How a law written for banks ends up on a vendor's desk

DORA addresses financial entities directly: banks, insurers, investment firms, payment institutions, trading venues, and a wide roster of similarly regulated bodies. It tells them how to manage ICT risk, and crucially, how to manage the ICT risk introduced by their suppliers.

You are not one of those financial entities, and DORA does not name you directly unless you fall under the critical ICT third-party provider designation described below. What has actually happened is that your customer now carries a new obligation, and the way that obligation gets discharged is by pushing specific terms down into the contract they sign with you, because their regulator holds them, not you, accountable for supplier risk.

There is one narrower path that does create direct exposure: the European Supervisory Authorities can designate a small number of very large infrastructure and cloud providers as critical ICT third-party providers, putting them under direct EU oversight. This is a formal, individually notified status. If nobody has told you that you hold it, you do not.

Direct application vs customer flow-down

Vendors in this situation encounter DORA as a flow-down obligation rather than a direct one, unless they are one of the small number of providers formally designated as critical ICT third-party providers. There is no certificate to earn and no return to lodge with a regulator. What you will encounter is a set of mandatory clauses in your customer's contract, and a register entry describing your service that lives in your customer's systems, not yours.

What is actually asked of you is narrower than it first appears: agree to workable versions of those clauses, show the operational resilience behind them, and give your customer the specific facts they need to complete their own risk register.

• —Direct: reserved for a small, formally designated list of critical ICT third-party providers
• —Flow-down: reaches you through mandatory contract clauses your EU financial customer is required to include, the situation for vendors who are not formally designated as critical ICT third-party providers
• —The classification decision belongs to your customer, not to you

What an EU financial customer will ask you to produce

In practice, the request usually turns up dressed as a routine vendor security review, with a set of DORA-specific questions bolted on.

• —Sign-off on the mandatory ICT third-party contract terms: exit rights, audit and access rights, service levels, subcontracting notification
• —A service description precise enough that your customer can log it correctly in their register of information
• —Your subcontracting position: who, where, and how changes get communicated
• —Business continuity and disaster recovery evidence backed by actual test results, not a document nobody has run
• —Incident detection and notification timelines you are prepared to put in a contract
• —Confirmation that the customer's audit and access rights over you meet what their regulator expects them to hold
• —A workable exit and termination plan for how their data and workloads leave your service without a disruptive scramble
• —Where you rely on a subcontractor for a material piece of the service, evidence that subcontractor accepts equivalent terms

Common misconceptions

“We're not a financial institution, so DORA has nothing to do with us.”

Right, as a matter of who the law is directly addressed to. Wrong as a matter of consequence: your EU financial customer's duty to manage you as a supplier risk is real and contractual, and it does not care what kind of company you are.

“We already work to APRA's CPS 230, so we've basically got this covered.”

CPS 230 experience gives Australian vendors a real vocabulary for this conversation (critical operations, tolerance thresholds, third-party dependency mapping), and that vocabulary carries over well. But CPS 230 is enforced by APRA against your Australian financial customers, not by any European authority against you for European ones. DORA's specific clause requirements and register-of-information mechanics are a distinct exercise you still have to do.

“We know our own product well enough to decide if it's a critical or important function.”

That call belongs to the financial entity, made against their own operational and regulatory picture, not against your product spec. If your customer has not told you, the accurate answer in a questionnaire is that you do not know yet.

“Being a well-established vendor with a strong reputation must mean we're a critical ICT third-party provider.”

That designation is a specific EU regulatory act, not a measure of how well known you are. Very few companies hold it. Assume you are not one unless a European authority has told you directly.

“We're ISO 27001 certified, so this box is already ticked.”

ISO 27001 is solid evidence of an information security management system, and it will help your case, but it does not on its own satisfy DORA's contract-specific demands: audit rights, exit planning, subcontracting notification and register data are asked for separately and need separate answers.

Practical checklist

1. 01List which customers are EU financial entities, including EU branches or subsidiaries of groups headquartered elsewhere
2. 02Ask outright whether your service has been classified as supporting a critical or important function, rather than assuming either way
3. 03Check your standard contract against exit rights, audit and access rights, and subcontracting notification, and prepare to strengthen these for EU financial customers
4. 04Keep a current subcontracting map for each EU financial customer's service
5. 05Actually test your business continuity and disaster recovery plan, and retain the test evidence, not just the plan itself
6. 06Set incident detection and notification timelines internally before agreeing to them in a contract
7. 07Write an exit and data-portability plan for the service, distinct from a generic data export button
8. 08Nominate someone who can answer register-of-information questions about your service on short notice
9. 09Where you already meet CPS 230 expectations for an Australian financial customer, map that evidence deliberately across to DORA's clause requirements rather than assuming it carries over on its own

Australian context

APRA's prudential standards CPS 230 and CPS 234 have already pushed Australian banks and insurers, and the vendors that serve them, toward disciplined operational-risk and information-security practice: mapping critical operations, managing third-party dependency, planning for outages. That background is a genuine advantage when a European financial customer's questionnaire lands, but the two regimes remain legally distinct: passing an APRA-style review does not automatically satisfy a DORA-driven contract request, and the reverse is also true.

Where the DORA question tends to arrive for an Australian vendor is not usually a direct sale to a European bank. It more often surfaces through a payments platform, a banking-as-a-service partner or a UK/EU processing arrangement, where an EU-regulated entity sits somewhere upstream in the chain without being the company you signed with originally.

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