DORA for SaaS vendors: what your financial customers will ask for

The Digital Operational Resilience Act (DORA, Regulation (EU) 2022/2554) has applied since 17 January 2025. It regulates EU financial entities, from payment and e-money institutions to investment firms and other regulated firms. It does not regulate most software vendors directly. It still lands on your desk the moment one of those firms uses your product, because DORA requires them to manage you as an "ICT third-party service provider". That duty flows into your contract, your incident process and the way you report on reliability.

This is a practical summary for SaaS teams, not legal advice. The regulation text and your customer's contract decide the exact obligations.

How DORA reaches a vendor

It arrives through three channels.

1. The register. Every financial entity keeps a register of information on all of its contracts for ICT services (Article 28(3)), in the standard templates set by Implementing Regulation (EU) 2024/2956. It reports on those contracts to its supervisor at least once a year and hands over the full register on request. Expect requests for your legal entity identifier (an LEI or EUID), the services you provide, where they run and who your subcontractors are.
2. The contract. Article 30 lists terms that every ICT services contract must contain, and a longer list when your service supports one of the customer's critical or important functions. Expect a DORA addendum during procurement or at renewal.
3. The incident clock. Your customer's reporting deadlines start when they become aware of an incident, and your outage can be their incident. How fast and how precisely you tell them decides whether they can meet those deadlines.

The largest providers can be designated as critical and overseen directly by EU supervisors. Most SaaS vendors are not, and meet DORA through their customers' contracts.

The contract terms that touch reliability

Article 30 is long. These are the terms that change how a SaaS team runs:

The terms in paragraph 3 apply when your service supports a critical or important function of the customer's, though many customers send the full list regardless. The remaining terms cover data protection, cooperation with supervisors, termination rights, participation in the customer's security awareness training and, for critical functions, participation in threat-led penetration testing.

Point 3(a) is the one most vendors are least ready for. "99.9% uptime" in a marketing page is not a full service level description. The customer needs a target per service, a definition of what counts as downtime, the exclusions and a way to monitor it themselves.

The clock your customer is on

When something breaks, your customer has to decide quickly whether it is a major incident and, if so, report it.

• Classification. Delegated Regulation (EU) 2024/1772 sets the criteria: clients, financial counterparts and transactions affected, reputational impact, duration and service downtime, geographical spread, data losses, the criticality of the services affected, and economic impact. Duration runs from the moment the incident occurred. When it started before anyone noticed, it runs from the moment it shows up in logs or other data sources.
• Reporting. Under Delegated Regulation (EU) 2025/301, the initial notification is due within 4 hours of classifying the incident as major, and no later than 24 hours after becoming aware of it. An intermediate report follows within 72 hours of the initial notification, with an updated one when regular activities have been recovered, and a final report within one month of the latest intermediate report.
• Their clients. Under Article 19(3), when a major incident has an impact on clients' financial interests, the firm must inform those clients without undue delay as soon as it becomes aware of it, including the measures taken to mitigate the adverse effects.

Every one of those criteria needs facts that only you have if the incident started in your service. In the first hour, your customer needs to know when it started, which of your services are affected, which of their users, regions or transactions are hit, whether any data is affected, what is being done and when the next update will come. They need it in writing, timestamped and specific to them. A generic "We are investigating reports of elevated errors" on a public status page does not let anyone classify an incident, let alone meet a 4-hour deadline.

A readiness checklist

1. Know which customers are regulated and what they depend on. Keep a map of customers to the services they use, and flag the services that support a customer's critical functions.
2. Turn service levels into measurements. For each service: a target, a period, a written definition of downtime and degraded, the exclusions and the time zone. Publish the method so a customer can check your numbers.
3. Notify per customer, not only per page. Affected customers should hear from you directly, through a channel they chose, and you should be able to show what was sent, to whom and when.
4. Prepare the facts a classifier needs. Start time, detection time, affected services and regions, customer impact, data impact and the next update time, in a template you can fill in within minutes.
5. Report monthly with evidence. Attainment per service and per customer, incidents with their postmortems, and a format the customer can verify later.
6. Document where data lives and who your subcontractors are, and how you announce changes before they happen.
7. Make exit real. A full export in a usable format, and a written exit and transition plan.
8. Agree incident assistance terms before you need them, including what you provide and at what cost.
9. Expect questionnaires, audit requests and requests for continuity test evidence, and keep the answers current.

If your customers are regulated in the UK rather than the EU, expect similar questions under the operational resilience rules of the FCA and the PRA.

Where Observer fits

Observer does not make anyone DORA compliant, and it does not file reports with supervisors. It covers the reliability evidence and the customer communication in the middle of that checklist:

• Measured status. Status comes from your own metrics, read by an agent inside your network, and every change of status is timestamped after a short confirmation window, so the start and end of an incident come from data rather than memory.
• Customer-specific communication. Customer-scoped pages and per-service subscriptions by email, Slack, Microsoft Teams or signed webhook let the customers who are affected hear about it, with a delivery record for each notification.
• Service levels you can prove. SLOs and the SLA Ledger hold per-customer contracts with a target per service, your downtime definition and exclusions. Monthly statements show the working, wait for approval by default, and carry a SHA-256 hash and an Ed25519 signature that customers can check on your Reliability Center against Observer's published keys. The worked examples in how to calculate SLA credits show the terms a contract needs.
• Data location. Customer data at rest is held in the EEA and the UK, as set out on the security page.

Keep reading

• How to calculate SLA credits, with worked examples
• Incident update templates, and how often to post them
• Why status pages lie
• Status page best practices