# DORA Checklist for AI Presentation Software in Financial Services
> DORA has applied since 17 January 2025. A practical checklist for assessing AI presentation software as an ICT third party service: contracts, register, testing, exit.
- Author: [Maximilian Betz](https://www.offgen.ai/en/authors/maximilian-betz)
- Published: 2026-08-26
- Updated: 2026-08-26
- Category: Banking & Finance
- Labels: Banking & Finance, Security & EU Regulation
- Canonical URL: https://www.offgen.ai/en/blog/dora-ai-presentation-software-checklist
> This article is for information only and does not constitute legal advice.
## Evidence for this article

This article supports its claims with 5 sources. Key sources include:

1. [Regulation (EU) 2022/2554 on digital operational resilience (DORA)](https://eur-lex.europa.eu/eli/reg/2022/2554/oj) (EUR-Lex)
2. [DORA overview](https://www.bafin.de/DE/Aufsicht/DORA/DORA_node.html) (BaFin)
3. [BaFin publishes guidance notes on the implementation of DORA](https://www.bafin.de/SharedDocs/Veroeffentlichungen/EN/Meldung/2024/meldung_2024_07_08_DORAGap_en.html) (BaFin)

[Full source list](#sources)
DORA applies to your institution, not to the software you buy. That single sentence resolves most of the confusion I encounter in these conversations.

Regulation (EU) 2022/2554 entered into force on 17 January 2023 and has applied since 17 January 2025. For in scope financial entities it makes ICT risk management and ICT third party risk management a core supervisory expectation. If an AI presentation tool processes your data or supports a business function, it is an ICT service provided by a third party, and it belongs inside that framework.

So no vendor can sell you DORA compliance. What a vendor can do is supply the contractual provisions, evidence, transparency and assistance that your arrangement needs in order to hold up. That is the lens for everything below.

<Callout title="Scope and legal review">
  This is operational guidance, not legal advice. DORA scope, proportionality and the classification of functions depend on your entity type, size, risk profile and national implementation. Have ICT risk, compliance and legal own the assessment.
</Callout>

## Step 1: establish whether this is even in scope for you [#step-1-establish-whether-this-is-even-in-scope-for-you]

Before any vendor questions, answer two internal ones.

**Is your entity in scope?** DORA covers a broad range of financial entities. Scope, and the availability of the simplified ICT risk management framework, depends on entity type and characteristics. BaFin has issued supervisory statements to support implementation, including guidance aimed at smaller and less complex entities on the simplified framework.

**What function does the tool support?** Not "presentations". The specific function. Producing supervisory reporting packs is a different answer from producing internal town hall material, and the two sit at different points on your criticality assessment.

Write that function down before you evaluate anything. Everything downstream depends on it.

## Step 2: assess criticality honestly [#step-2-assess-criticality-honestly]

The question DORA asks is whether the arrangement supports a critical or important function. For most presentation tools the honest answer is no, but you have to reach that answer through assessment rather than assumption, and the answer is not automatic.

Consider:

* Would a failure or compromise materially impair your financial performance?
* Would it affect the soundness or continuity of your services and activities?
* Would it impair your ability to meet regulatory obligations, including reporting deadlines?
* What is the impact of unavailability, over what timeframe?
* What is the impact of a confidentiality or integrity failure in the material produced?

A tool used to assemble regulatory submission packs deserves closer attention than one used for internal updates. If both use cases run on the same tool, assess against the more demanding one, and consider whether they should be separated.

Document the assessment and the reasoning. A supervisor asking about a tool wants to see that you thought about it, not that you concluded quickly.

## Step 3: the contractual provisions [#step-3-the-contractual-provisions]

DORA expects specific contractual content for ICT services, and more for arrangements supporting critical or important functions. Work through this with legal rather than accepting standard terms.

<Checklist>
  * A clear and complete description of the services and the functions supported.
  * All locations where services are provided and where data is processed and stored, with notification of changes.
  * Provisions on availability, integrity, confidentiality and the protection of personal data.
  * Access, inspection and audit rights for your institution and your competent authority, exercisable in practice and not only on paper.
  * Full cooperation obligations with your supervisory authorities.
  * Service level descriptions with measurable targets and consequences.
  * Incident notification obligations, with defined timelines and content.
  * Obligations to participate in and support your ICT security awareness and resilience testing where relevant.
  * Subcontracting conditions, including notification and objection rights for material subcontracting.
  * Termination rights, including for material breach, supervisory instruction and circumstances impairing the arrangement.
  * Exit strategy support: transition assistance, data return, format, timelines and deletion confirmation.
</Checklist>

Two of these get glossed over most often. Audit and access rights that exist in the contract but are practically impossible to exercise are not audit rights. And subcontracting notification with no objection right leaves you accepting changes to your own risk profile without a say.

## Step 4: the register of information [#step-4-the-register-of-information]

Where the arrangement is in scope, it goes in your register of information, in the prescribed machine readable format.

What that requires practically, for a presentation tool:

* The contractual arrangement and its identifiers.
* The provider identity, including the legal entity identifier where applicable.
* The function supported, and whether it is a critical or important function.
* Subcontractors involved in providing the service.
* Processing and data storage locations by country.
* The date of the last risk assessment and the criticality determination.
* Contract dates, termination notice periods and governing law.

Firms consistently report the register as one of the harder DORA obligations, and the reason is not the format. It is that vendor metadata is inconsistent, contract inventories are incomplete, and nobody owns the subcontractor chain. Solve those before the reporting deadline rather than during it.

Practical advice: ask the vendor for the register fields in a structured form during procurement. A vendor who has this ready has been through it before. A vendor who has to construct it from scratch will delay your submission.

## Step 5: concentration risk [#step-5-concentration-risk]

Look at the arrangement in the context of your whole ICT estate, not in isolation.

* Does this provider sit on the same underlying cloud infrastructure as several of your other critical providers?
* Which model providers or subprocessors are in the chain, and do they appear elsewhere in your estate?
* If this provider became unavailable, how many of your functions would be affected simultaneously?
* Is the service substitutable, and how quickly?

That last question connects directly to output format, which is why I keep returning to it. A tool that produces native, portable files is substitutable. A tool that holds your material in a proprietary format is not, whatever the exit clause says, because the contract can promise data return and still leave you with files you cannot use.

## Step 6: testing and resilience [#step-6-testing-and-resilience]

Assess how the arrangement fits your resilience testing programme.

* What availability commitments exist and how are they evidenced?
* What is the provider's own continuity and disaster recovery posture?
* Can you test failure scenarios, including with non sensitive data, before and during the relationship?
* How would the business function continue during an outage? For presentation workflows, the honest answer is usually that people work in PowerPoint directly, which is a genuine advantage of native output.
* Does the provider participate in your testing where the arrangement warrants it?

## Step 7: incident handling [#step-7-incident-handling]

Connect the tool to your existing ICT incident process rather than treating it as separate.

* Contractual notification timelines and content, aligned with your own reporting obligations.
* A named contact and an escalation path that works outside business hours.
* What logs and forensic information you can obtain, and how quickly.
* How incidents affecting subcontractors reach you.
* How the tool's incidents are classified against your existing taxonomy.
* Whether users know how to report a problem, including near misses and wrong uploads.

## Step 8: exit [#step-8-exit]

The most commonly under specified area in software procurement, and the one supervisors increasingly ask about.

<Checklist>
  * A documented exit plan for this specific arrangement, not a generic template.
  * Data export format and completeness, tested rather than assumed.
  * Timescales for transition and the vendor's assistance obligations.
  * How the business function continues during transition.
  * Deletion confirmation after transition, with evidence.
  * Trigger events for exit, including supervisory instruction.
  * Cost and resource estimate for executing the exit.
</Checklist>

The test I would apply: if you had to leave this provider in ninety days, what would you actually get back, in what format, and could your teams use it on day ninety one? For a presentation tool the answer should be your files, in native PowerPoint, usable immediately. If the answer involves a bulk export of proprietary objects, you have a dependency you have not priced.

## What to ask the vendor, specifically [#what-to-ask-the-vendor-specifically]

<Checklist>
  * Can you provide the register of information fields in a structured format?
  * Can you list all subcontractors, their locations and the notification process for changes?
  * Where do support engineers sit and what can they access?
  * Are audit and inspection rights exercisable in practice, and how have they been exercised before?
  * What are the incident notification timelines, and what has your track record been?
  * What availability commitments apply, and how are they evidenced?
  * Is customer data used for model training, contractually rather than as a policy statement?
  * What is the data export format on exit, and can we test it now?
  * Can we run failure scenarios against a non production environment?
  * Which other financial entities use this service, in aggregate terms relevant to concentration?
</Checklist>

## The relationship between DORA, GDPR and the AI Act [#the-relationship-between-dora-gdpr-and-the-ai-act]

These three frameworks overlap in this procurement and are frequently conflated, so keep them separate.

**DORA** governs your operational resilience and your ICT third party arrangements. It regulates you.

**The GDPR** governs the processing of personal data in the workflow. Presentations carry more personal data than most teams assume, and the Article 28 processor arrangement is a distinct requirement from DORA's contractual provisions, although one contract can address both.

**The EU AI Act** applies according to the system and your role. The AI literacy duty under Article 4 has applied to deployers since 2 February 2025 and transparency obligations under Article 50 since 2 August 2026. Annex III high risk obligations were deferred to 2 December 2027 by Regulation (EU) 2026/1744.

One vendor assessment can gather evidence for all three, but the conclusions are separate and should be documented separately.

## Where offgen fits [#where-offgen-fits]

We publish the material that supports this assessment rather than asking you to take it on trust. Our [trust center](/en/security/trust-center), [security overview](/en/security) and [data processing agreement](/en/data-processing-agreement) cover processing locations, subprocessors, retention, support access and the contractual position on training.

On the substitutability question: offgen produces native PowerPoint. Your material is usable without our application, which is a meaningful answer to the exit and concentration questions rather than a design preference.

More on the sector view is on our [banking page](/en/industries/banking).

The framing I would hold to throughout: you are not buying compliance, you are building an arrangement that has to survive supervisory scrutiny. Assess the vendor on whether they make that easier or harder, and treat unusually confident compliance claims as a signal rather than as reassurance.
## Frequently asked questions

### Does DORA apply to AI presentation software?

DORA applies to in scope financial entities, not to software. If a presentation tool processes your data or supports a business function, it is an ICT service provided by a third party, so it falls inside your DORA framework: contractual requirements, register of information where applicable, risk assessment, testing, incident handling and exit planning.

### Can a vendor be DORA compliant?

No. DORA regulates the financial entity. A vendor can support your compliance by providing the contractual provisions, evidence, audit and access rights, subcontractor transparency and exit assistance that the regulation expects of your arrangements. Any vendor claiming to sell you DORA compliance has told you something about their rigour.

### When did DORA start applying?

DORA, Regulation (EU) 2022/2554, entered into force on 17 January 2023 and has applied since 17 January 2025. Supervisors have moved from implementation guidance towards examining evidence of compliance, and BaFin has published supervisory statements including guidance on the simplified ICT risk management framework.

### Does an AI presentation tool support a critical or important function?

Usually not, but you must assess it rather than assume. Ask whether a failure or compromise would materially impair your financial performance, the soundness or continuity of services, or your ability to meet regulatory obligations. A tool used for supervisory reporting packs may sit closer to that line than one used for internal town halls.

### What goes in the register of information for a presentation tool?

Where the arrangement is in scope, the register records the contractual arrangement, the provider identity, the function supported, whether it supports a critical or important function, the subcontractors involved, processing and data locations, and the criticality assessment, in the prescribed machine readable format.

### What is the most commonly missed DORA question in software procurement?

Exit. Firms document onboarding thoroughly and exit vaguely. You need a tested plan: data export format, timescales, vendor assistance obligations, deletion confirmation and how the business function continues during transition. Native output formats matter here more than teams expect.
## Sources

1. [Regulation (EU) 2022/2554 on digital operational resilience (DORA)](https://eur-lex.europa.eu/eli/reg/2022/2554/oj) — EUR-Lex, 2022-12-14; accessed 2026-08-26.
2. [DORA overview](https://www.bafin.de/DE/Aufsicht/DORA/DORA_node.html) — BaFin; accessed 2026-08-26.
3. [BaFin publishes guidance notes on the implementation of DORA](https://www.bafin.de/SharedDocs/Veroeffentlichungen/EN/Meldung/2024/meldung_2024_07_08_DORAGap_en.html) — BaFin, 2024-07-08; accessed 2026-08-26.
4. [Regulation (EU) 2016/679 (General Data Protection Regulation)](https://eur-lex.europa.eu/eli/reg/2016/679/oj?locale=en) — EUR-Lex, 2016-04-27; accessed 2026-08-26.
5. [Trust Center](https://www.offgen.ai/en/security/trust-center) — offgen; accessed 2026-08-26.
## Related articles

- [AI in Banking Presentations: Use Cases, Risks, and Governance](https://www.offgen.ai/en/blog/ai-banking-presentations)
- [Enterprise AI Presentation Software: Evaluation Checklist for 2026](https://www.offgen.ai/en/blog/enterprise-ai-presentation-software-checklist)
- [AI Presentation Governance: A Practical Framework for Enterprise Teams](https://www.offgen.ai/en/blog/ai-presentation-governance-framework)
