---
title: "What does DORA make a bank ask its AI or LLM vendor? - S-PRO"
url: https://s-pro.io/blog/dora-compliance-banks
lang: en
description: "DORA never mentions AI. Here is our reading of its ICT third-party rules as questions a bank puts to an AI or LLM vendor, by article, with a Swiss FINMA note."
updated: 2026-11-09T06:06:03+00:00
source: S-PRO (https://s-pro.io)
---

[Back to insights](https://s-pro.io/blog)

Article

# What does DORA make a bank ask its AI or LLM vendor?

Author

[Igor Izraylevych](https://s-pro.io/author/igor-izraylevych)

CEO and Co-founder of S-PRO

Published

November 6, 2026

Time to read

12 min

Table of content

- Key Takeaways
- Table of Contents
- Does DORA apply to an AI or LLM vendor at all?
- The question list, by article
- A short plan for running the questions
- Swiss banks: FINMA Circular 2018/3 and DORA
- Our perspective
- How AI agent projects fit around these questions
- FAQ
- How S-PRO helps banks and financial institutions
- Sources

Share

The text of DORA does not mention AI, so applying its ICT third-party rules to an AI or LLM vendor is our reading, not a regulatory statement. Whether a given service counts as an ICT service (Art. 3(21)) or supports a critical or important function (Art. 3(22)) is a decision each bank makes for itself.

This article turns the relevant articles of [Regulation (EU) 2022/2554](https://eur-lex.europa.eu/eli/reg/2022/2554/oj/eng) into a question list for procurement, compliance and technology teams. DORA entered into force on 16 January 2023 and has applied to in-scope EU financial entities since 17 January 2025, according to [ESMA](https://www.esma.europa.eu/esmas-activities/digital-finance-and-innovation/digital-operational-resilience-act-dora).

S-PRO

Build AI with compliance in mind

S-PRO builds AI agents and software for financial institutions, with solutions designed with FINMA, DORA and EU AI Act requirements in mind.

[Explore S-PRO](https://s-pro.io/)

## Key Takeaways

- DORA regulates ICT third-party risk by service and function, not by technology. An AI or LLM service falls under it when the bank treats it as an ICT service.
- The bank classifies the service. The vendor cannot do it for the bank, and neither can a generic checklist.
- Six questions cover most of the ground: scope, register, contract, subcontracting chain, incidents, and audit and exit.
- Incident clocks run for the bank. The bank files its own reports, and the vendor’s role is to give it the facts in time.
- Swiss banks apply DORA only through EU entities, branches or EU clients. Their baseline is FINMA Circular 2018/3.

## Table of Contents

- The question list, by article
- A short plan for running the questions
- Our perspective
- FAQ
- Sources

## Does DORA apply to an AI or LLM vendor at all?

It applies through the bank, not through the technology. DORA covers credit institutions and more than 20 other categories of financial entity under Article 2, and it obliges them to manage the risk of the ICT third parties they use, as the [regulation text](https://eur-lex.europa.eu/eli/reg/2022/2554/oj/eng) sets out. The bank stays responsible even when a service is outsourced.

An LLM API, a hosted agent platform or an AI copilot embedded in a banking workflow can all be digital or data services provided on an ongoing basis through ICT systems. That is the shape of the definition in Art. 3(21). Whether a particular service meets it is a judgment the bank documents. The same goes for Art. 3(22): the bank decides whether the service supports a function whose disruption would materially impair its performance or compliance.

Two practical consequences follow:

1. A proof of concept on synthetic data and a production agent that triages sanctions alerts are different cases. Classify each one separately and write down why.
2. The vendor’s own description (“just a model”, “just a SaaS tool”) does not change the bank’s classification.

If you are mapping where AI sits in your operations before you classify anything, our overview of AI agents for banks shows the typical workflow touchpoints.

## The question list, by article

The table below gives one question per DORA topic, the article that drives it, and what to ask the vendor. The wording of the vendor questions is ours. The article references are DORA’s, and the incident rows add [Delegated Regulation (EU) 2025/301](https://eur-lex.europa.eu/eli/reg_del/2025/301/oj/eng) and [Delegated Regulation (EU) 2025/532](https://eur-lex.europa.eu/eli/reg_del/2025/532/oj/eng).

| Question | Article | Ask the vendor |
| --- | --- | --- |
| Is this service in scope of our ICT third-party framework? | Art. 28(2)-(4), list not exhaustive | Which components do you provide: model access, hosting, orchestration, data pipelines, monitoring? Which of them does our use depend on? |
| Can we enter it in the register of information? | Art. 28(3) | Can you supply the data points we need for the register: legal entity, services, locations, subcontractors? Will you update them when they change? |
| Does the contract carry the mandatory terms? | Art. 30(2), Art. 30(3)(e)(i); microenterprise caveat | Does your contract describe services, data locations, support, cooperation with authorities, and termination rights? Does it give us access, inspection and audit rights? |
| Who else sits in the delivery chain? | Art. 30(2), Delegated Regulation (EU) 2025/532 | Which subcontractors, including model providers and cloud hosts, support the service? What conditions apply when you add or change one? |
| How will we learn of an incident, and how fast? | Art. 19(1), 19(4), 19(5); Art. 5 of Regulation (EU) 2025/301 | What do you notify us of, in what format and through which channel, so we can classify and report on our own timeline? |
| Can we audit the service and leave it in an orderly way? | Art. 28(8), Art. 30(3)(e)(i) | What does an audit of your service look like in practice? What does exit look like: data return, transition support, a fallback to another provider? |

The sections below explain each row.

### Scope and register (Art. 28(2)-(4), Art. 28(3))

Before signing, the bank assesses the arrangement against its ICT third-party risk strategy and enters it in the register. Article 28 requires an ICT third-party risk strategy that is reviewed regularly, a pre-contract assessment, and a register of all contractual arrangements on ICT services, as the [regulation](https://eur-lex.europa.eu/eli/reg/2022/2554/oj/eng) lays out. The list of things to assess in Art. 28 is not exhaustive, so a bank can add AI-specific questions of its own.

For an AI vendor the register work is mostly about identification. A single contract may bundle a model, a hosting layer and an integration service. Ask the vendor to describe each element separately so the bank can record what it actually depends on.

### Contract terms (Art. 30(2), Art. 30(3)(e)(i))

Article 30(2) lists the provisions every ICT contract must contain, and Art. 30(3) adds more for services supporting critical or important functions. Among the additions is the right of unrestricted access, inspection and audit under point (e)(i).

Two points matter in negotiations:

- Standard vendor terms for AI services are often written for broad customer bases. Compare them line by line with Art. 30, rather than assuming equivalence.
- Article 30 has a caveat for microenterprises. If your vendor is that small, read the wording in the [regulation](https://eur-lex.europa.eu/eli/reg/2022/2554/oj/eng) before you rely on the standard position.

### The delivery chain (Art. 30(2), Delegated Regulation 2025/532)

An AI service is rarely a single supplier. A vendor may use a foundation model from one company, run it on another’s cloud and rely on a third for monitoring. For services supporting critical or important functions, Delegated Regulation (EU) 2025/532 specifies what the bank determines and assesses when ICT services are subcontracted, and its recitals explain that indirect reliance on subcontractors can affect the bank’s ability to manage its risks.

Ask for the chain in writing, ask how changes are notified, and check that the contract lets the bank object to or exit from a change it cannot accept.

### Incidents (Art. 19, Regulation 2025/301)

The bank’s reporting clock is the bank’s own. Under Art. 19(1) it manages and classifies incidents, and under Art. 19(4) it notifies major ICT-related incidents to its competent authority in three stages. Art. 5 of [Regulation (EU) 2025/301](https://eur-lex.europa.eu/eli/reg_del/2025/301/oj/eng) sets the timings:

| Stage | Deadline |
| --- | --- |
| Initial notification | Within 4 hours of classifying the incident as major, and no later than 24 hours from becoming aware of it |
| Intermediate report | Within 72 hours of the initial notification |
| Final report | Within one month of the latest updated intermediate report |

Three reading notes. First, the reports are the bank’s: Art. 19(5) allows a bank to outsource the filing but leaves the responsibility with it. Second, the weekend and holiday relief in the timing rules does not extend to credit institutions, so a bank’s clock runs through weekends. Third, DORA sets no hour figure for the vendor. Fix the vendor’s notification time in the contract, sized so the bank can meet its own deadlines.

For an AI service, agree up front what counts as an incident worth notifying: an outage, a data exposure, a model change that alters outputs in a regulated workflow, or a security event at a subcontractor.

### Audit and exit (Art. 28(8), Art. 30(3)(e)(i))

For critical or important functions the bank needs exit strategies, and the contract needs audit rights to match. Art. 28(8) requires exit strategies and transition plans for services supporting critical or important functions. Ask what data the bank can retrieve, in what format, how long the vendor supports a transition, and whether an alternative provider or an in-house fallback is realistic. For an LLM-based workflow, check whether prompts, configurations, evaluation sets and logs are portable.

## A short plan for running the questions

Start with classification, then work down the table. A workable order is:

1. Describe the AI service and the workflow it supports, in one page.
2. Classify it under Art. 3(21) and 3(22) and record the reasoning.
3. Send the six vendor questions in writing and keep the answers with the register entry.
4. Compare the vendor contract with Art. 30, and the chain with Delegated Regulation 2025/532.
5. Agree incident notification terms that fit the bank’s own deadlines.
6. Document audit and exit before go-live, not after.

If you are moving agents from a pilot into a production workflow, these steps are the gate. Our guide to AI agent pilot to production describes how we structure that path.

Talk to our engineers about your vendor assessment

## Swiss banks: FINMA Circular 2018/3 and DORA

DORA reaches a Swiss bank only through EU entities. It applies to EU-headquartered entities, and per [EIOPA’s Q&A of 25 November 2024](https://www.eiopa.europa.eu/qa-regulation/questions-and-answers-database/dora-137-3195_en), an EU entity applies it to its non-EU branches while non-EU subsidiaries are separate legal entities outside Article 2(1). A Swiss bank with an EU subsidiary or branch should map which legal entities are in scope.

For the Swiss entity itself, the binding baseline is [FINMA Circular 2018/3 on outsourcing](https://www.finma.ch/en/news/2017/12/20171205-mm-rs-outsourcing/), in the version of 4 November 2020. Margin number 26, paraphrased, sits in the part on the outsourcing agreement and the bank’s control over what it hands to a provider. Read it against the neighbouring margin numbers in the circular’s own text. In practice, the same six questions serve both regimes, which lets a Swiss group run one vendor assessment instead of two.

|  | DORA | FINMA Circular 2018/3 |
| --- | --- | --- |
| Applies to | EU financial entities, including EU branches of non-EU banks’ parent structures as the entity rules provide | Swiss banks, securities firms and insurers |
| Status for a Swiss bank | Only for EU entities | Binding |
| Vendor questions | Scope, register, contract, chain, incidents, audit and exit | Largely the same themes, set out in the circular’s own structure |

## Our perspective

> We build AI agents for banks, and the vendor questions in this article are the ones we expect from a careful client. A bank that asks them early ends up with a better architecture, not a slower project.
>
>
>
> Our reading is that the strongest answer to DORA is traceability: which model, which data, which subcontractor, which version, and who was told when something changed. We design agents around that, with human-in-the-loop steps and audit trails that a compliance team can inspect.
>
>
>
> Our team includes Claude-certified engineers and architects, and S-PRO is a Certified partner in the Claude Partner Network. We therefore see how foundation-model choices affect the chain a bank has to document, and we help clients keep that chain short and visible.
>
>
>
> *The S-PRO team*

## How AI agent projects fit around these questions

Build the vendor file in parallel with the engineering work, not after it. A bank that treats the six questions as design requirements gets the register data, contract terms and incident channel ready by the time the agent reaches production.

For teams adding Claude to regulated workflows, our [page on Claude for financial services](https://s-pro.io/blog/claude-for-financial-services) covers how we approach it. For the wider programme, including [IT strategy](https://s-pro.io/blog/it-strategy-for-banks) and vendor governance, see our [technology consulting services](https://s-pro.io/technology-consulting-services).

Talk to S-PRO about your AI agent project

Get in touch

## FAQ

### Does DORA mention artificial intelligence?

No. The text of DORA does not mention AI. Its ICT third-party rules apply to any ICT service a bank uses, so applying them to an AI or LLM vendor is our reading. Each bank decides whether a particular AI service is an ICT service and whether it supports a critical or important function.

### Who files the incident report when the vendor causes the incident?

The bank does. Art. 19 puts the classification and reporting duty on the financial entity, and Art. 19(5) lets it outsource the filing while keeping responsibility. The vendor’s contractual duty is to tell the bank quickly and completely, so the bank can meet its own deadlines under Regulation (EU) 2025/301.

### Does a Swiss bank have to comply with DORA?

Only where it has EU entities in scope. DORA applies to EU financial entities, and EU entities apply it to their non-EU branches, while non-EU subsidiaries are separate legal entities. The Swiss entity itself works under FINMA Circular 2018/3 on outsourcing, in its version of 4 November 2020.

### Can the vendor tell us its service is DORA compliant?

No vendor statement replaces the bank’s own assessment. DORA’s obligations sit with the financial entity, which classifies the service, keeps the register, and reviews the contract. Ask the vendor for facts: services, locations, subcontractors, notification terms and audit rights. Then record your own conclusions in the file.

## How S-PRO helps banks and financial institutions

S-PRO is an international Swiss-American firm with offices in Zurich and Salt Lake City, and global delivery, founded in 2014, with 250+ engineers. We are ISO 27001 and ISO 27701 certified. We build AI agents and software for banks, wealth and asset managers and fintechs, using our own agentic platform, S-PRO Agents, and we can run the solution as a service.

We design with [EU AI Act](https://s-pro.io/blog/eu-ai-act-high-risk-banks-2027), FINMA and DORA requirements in mind, and we help your teams prepare the vendor documentation described above. If you are preparing to put an AI agent into production, book a discovery call with our team.

## Sources

- [Regulation (EU) 2022/2554 (DORA), EUR-Lex](https://eur-lex.europa.eu/eli/reg/2022/2554/oj/eng)
- [Delegated Regulation (EU) 2025/301, EUR-Lex](https://eur-lex.europa.eu/eli/reg_del/2025/301/oj/eng)
- [Delegated Regulation (EU) 2025/532, EUR-Lex](https://eur-lex.europa.eu/eli/reg_del/2025/532/oj/eng)
- [Digital Operational Resilience Act (DORA), ESMA](https://www.esma.europa.eu/esmas-activities/digital-finance-and-innovation/digital-operational-resilience-act-dora)
- [DORA Q&A 137 – 3195, EIOPA, 25 November 2024](https://www.eiopa.europa.eu/qa-regulation/questions-and-answers-database/dora-137-3195_en)
- [FINMA publishes outsourcing circular (Circular 2018/3), FINMA](https://www.finma.ch/en/news/2017/12/20171205-mm-rs-outsourcing/)

Last updated 4 November 2026

Subscribe

Get technical insights, and industry news

Thank you!

Get ready! You will receive handpicked content right to your inbox.

---

Contact

You will talk to engineers who build for banks, not to a sales script. Share your ideas, findings and questions with us.

- **Security and privacy first**ISO 27001 and ISO 27701 certified.
- **Claude Partner Network**S-PRO is a Certified partner in the Claude Partner Network. Our team includes Claude-certified engineers and architects.
- **Proven in regulated finance**Banks, wealth managers and fintechs in Switzerland, the EU and the US.

Who you’ll talk to

**Michael Barskyi**Head of Banking & Fintech

**Dustin Schulze**Senior Business Analyst

Prefer email or phone?

[hi@s-pro.ioEmail](mailto:hi@s-pro.io)[+41 41 539 15 83Phone](tel:+41415391583)

Claude Certified Services Partner(Anthropic)

**4.9**46 reviews on Clutch

Contact us

### Send us your request

Share your ideas, findings and questions with us.

Link copied to clipboard

Get in touch
