What DORA is and why it covers SaaS
The Digital Operational Resilience Act (Regulation (EU) 2022/2554) is a single rulebook for the digital operational resilience of the EU financial sector. It has applied directly in all member states since 17 January 2025. It covers banks, insurers, investment firms, payment and e-money institutions, and other financial entities.
The regulation rests on five pillars: ICT risk management, ICT incident management and reporting, digital operational resilience testing, ICT third-party risk management, and information sharing. SaaS falls mainly under the third-party risk pillar.
Almost every SaaS application a financial entity uses, such as collaboration suites, CRM, HR, analytics, and document management, is an ICT service delivered by a third party. The contract therefore counts as an ICT third-party arrangement under DORA's chapter on third-party risk.
Critical ICT third-party providers are also overseen directly by the European Supervisory Authorities. That oversight does not shift accountability: the financial entity still answers to its own supervisor for the resilience of the functions that SaaS supports.
The register of information and the duty to assess
DORA requires every financial entity to keep a register of information covering all its ICT third-party arrangements, and every SaaS contract belongs in it. The register records the provider, the services, whether they support critical or important functions, the subcontracting chain, data locations, and termination rights.
Competent authorities receive the register and report on it to the European Supervisory Authorities. Incomplete SaaS records therefore surface during supervisory review instead of staying an internal gap. An accurate IT asset register is the practical starting point.
Assessment is a duty across the whole lifecycle, not a procurement formality. Before relying on a SaaS service, the entity must assess the provider's technical capacity, security practices, support quality and financial soundness, and repeat the review when circumstances change.
Concentration risk gets explicit attention. When many entities depend on the same few SaaS platforms, one provider's failure becomes a sector-wide event, so the register also shows how replaceable each service really is.
Contract terms DORA expects
DORA sets minimum contract content for ICT services. In practice, a SaaS agreement needs at least these provisions:
| Provision | What it requires |
|---|---|
| Audit and access rights | Inspection by the entity, auditors, and supervisors; marketing claims are not enough |
| Service description and levels | Clear functional description, measurable service levels, security matched to criticality |
| Data location, protection, and return | Data locations, protection, and verifiable return or deletion at contract end |
| Termination and exit strategy | Documented termination rights and a tested exit strategy for critical services |
| Subcontracting transparency | Material subcontractors disclosed, assessed, and reported when the chain changes |
Incidents and testing where SaaS dependencies surface
DORA harmonizes how major ICT-related incidents are classified and reported. An incident that starts at a SaaS provider is still the entity's own incident. The entity must detect that a dependency is degraded and assess the impact on its own functions.
Not every major incident is a data breach. A provider outage that stops a critical service can be reportable too. Initial, intermediate, and final reports must arrive within the set deadlines, which requires knowing in advance which functions rest on which services.
Resilience testing must include the third-party dimension. Testing programmes, including threat-led penetration testing (TLPT) for entities designated by the authority, should cover scenarios where a SaaS service is unavailable, degraded or compromised. They should verify that recovery and exit arrangements hold under stress, not only that they exist on paper.
Requirements and their status
Not every duty applies to every service in the same way. Duties like these are usually run through a compliance management process, and the status shown below depends on scope.
| Requirement | Applies to | Status |
|---|---|---|
| Register of information | Every ICT third-party arrangement | Mandatory |
| Major incident reporting | All financial entities | Mandatory |
| Exit strategy | Services supporting critical or important functions | Critical only |
| Threat-led penetration testing (TLPT) | Entities designated by the authority | Designated only |
Where SaaS controls fall short
No single control covers the whole SaaS picture. Contract review checks the paperwork, while the inventory and activity logs show what is actually used. Services adopted without approval, the core of shadow IT, sit in the gap between them.
| Control | Finds unapproved SaaS | Limits data uploads | Leaves an activity trail |
|---|---|---|---|
| Contract review at procurement | |||
| Application inventory | |||
| Activity logging | |||
| Data loss prevention on uploads |
What good SaaS security looks like under DORA
The regulation sets the duties, but the practice starts with knowing which SaaS the organization actually runs. Services adopted by individual teams never enter the register and are never assessed, yet they carry the same data flows as approved ones.
None of the controls below is named in the regulation. Without them, however, the obligations the regulation does name are hard to meet. Deciding which data may reach which service is the job of data loss prevention.
- 1
Start with the inventory
Record every SaaS application in use, including those employees adopt on their own.
- 2
Classify the data
Decide which data may reach which service.
- 3
Cover the entry channels
Apply data loss prevention to browser uploads, sync clients, and email, so regulated data reaches only services in the register.
- 4
Log user activity
Keep an evidence trail in and around SaaS applications for incident classification and supervisory questions.
Where to start
Start with the data whose exposure would hurt most, then map the services that can receive it. A data classification policy gives every contract and every control the same reference point.
Further reading: The concept of "Zero Trust".
A SaaS contract is only as strong as the list of services it covers.
Anexet Team