BaFin AI guidance: managing ICT risks at financial entities under DORA

Origins: from keynote to publication

The guidance was announced by Nikolas Speer, BaFin’s Chief Executive Director of Banking Supervision, on 4 December 2025 in his keynote “IT-Aufsicht im Finanzsektor: Das erste Jahr DORA” (IT supervision in the financial sector: the first year of DORA) — summed up in the line “Not a new rulebook, but a helping hand.” (our translation) On 18 December 2025, BaFin followed with the news release “Artificial intelligence: BaFin publishes guidance on ICT risks”. It was issued by Division CTF 5 of the Cyber Risks and Technology in the Financial Sector directorate. The German version (as of 18 December 2025, 38 pages) is the original; the English translation, “Guidance on ICT Risks in the Use of AI at Financial Entities” (version date 23 January 2026, 35 pages), was published on 30 January 2026.

Legal status: non-binding, but no free pass

The guidance describes itself as “non-mandatory advice”, is based among other things on discussions with financial entities, does “not constitute a binding interpretation of DORA by BaFin” and “does not define any supervisory expectations” (Ch. I and I.2); the measures in the case study are likewise expressly presented as examples. DORA, the RTS RMF and the RTS Subcontracting remain binding. BaFin’s 2025 Annual Report, however, refers to “updated expectations” (our translation) that were communicated in the form of the guidance. No obligations follow from this — but as a signal of supervisory practice, the wording deserves to be taken seriously.

Addressees and limits

The guidance is aimed at financial entities within the meaning of Art. 2(2) in conjunction with Art. 2(1)(a) to (t) DORA, in particular CRR institutions and Solvency II insurance undertakings; it is addressed primarily to BaFin-supervised entities that must comply with Art. 5 to 15 DORA. According to the guidance, the simplified framework under Art. 16 DORA must be considered separately and is not covered. In substance, it deals exclusively with ICT risks and their treatment under DORA and the supplementing RTS; mathematical modeling methodology, including data, development and validation, is out of scope (Ch. I.1).

The guidance describes itself as a “living document” (Ch. I.3); the versions currently authoritative are those of 18 December 2025 (DE) and 23 January 2026 (EN). BaFin already refers to it in “Risks in Focus 2026” of 28 January 2026 — which lists, among other AI risks, dependencies on third-party providers of cloud services and AI models as well as data and model poisoning — and in the BaFinJournal interview of 29 July 2026 on the KI-MIG (Germany’s AI Act market surveillance and innovation act).

Three steps to the definition (Ch. I.1)

1. 1
   Art. 3(1) AI ActAdopt the legal definition

   An AI system is a machine-based system that is designed to operate with varying levels of autonomy, that may exhibit adaptiveness after deployment, and that, for explicit or implicit objectives, infers from the input it receives how to generate outputs such as predictions, content, recommendations or decisions that can influence physical or virtual environments.

2. 2
   C(2025) 5053 final, para. 11Interpret “machine-based”

   AI systems are developed with the help of machines and run on them. According to the Commission Guidelines of 29 July 2025, the machine comprises hardware (processing units, memory, network devices, input/output interfaces) and software (including computer code, operating systems and applications).

3. 3
   Art. 3(2) DORAPlace it within DORA

   AI systems are thus a subset of network and information systems. What is meant is a combination of ICT assets and ICT infrastructure in which a complex mathematical model is implemented; the model itself is an ICT asset (software).

The AI Act elements of autonomy and adaptiveness are not considered, nor is the mathematical modeling methodology, including the data used, its development and validation. The guidance therefore does not ask how well a model computes, but how secure and resilient the system it runs in is. The nature and scope of an AI system depend on the individual case and must correspond in particular to the business purpose, the risk situation and the relevant context.

Hidden AI: when software quietly becomes an AI system

Ch. III.2 describes the challenge of identifying during testing whether applications integrate external AI models, for example via APIs — software originally planned as a non-AI application can thus become an AI system. Ch. III.1 adds that AI-generated code may invoke AI functions unknown to the user. According to the case study (Variant 3), AI assistants in standard software may be invoked without users’ knowledge; the conclusions note that they are often included in standard software.

The consequence for the inventory: a policy and procedures for managing information and ICT assets are an obligation (Art. 8(4) DORA in conjunction with Art. 4 and 5 RTS RMF). According to Ch. IV.1, the components of AI systems are also to be identified, classified, documented and continuously monitored. If you inventory only “AI projects”, you will miss the AI that arrives with the next standard software update or through an API.

Citation note: in text extracts of the German PDF, the Commission Guidelines are cited as “para. 116”; this refers to para. 11 with footnote 6.

Why the lifecycle is the better organizing framework

According to Ch. I.2, specific ICT risks are not related to where an AI system sits in the value chain; they arise from its integration into the ICT landscape. The guidance therefore follows the AI lifecycle — from data acquisition through model development and deployment to ongoing operation and retirement. The security and resilience of the AI system should be ensured in every phase, and AI systems are to be included in the existing ICT risk management framework. Figure 1 maps five attack vectors: data and the AI model (Ch. III), input, output and the ICT system itself (Ch. IV); cyber and data security apply across the board (Ch. V).

Use cases per Ch. I

Proportionality under Art. 4 DORA

Art. 4 DORA requires ICT risk management to be applied proportionately, in line with size, overall risk profile and the nature, scale and complexity of services and activities. The guidance translates this for AI: applications integrated into critical or important functions need more extensive security and control measures than, say, AI-based self-service assistants that are completely under human supervision and not involved in decision-making processes (Ch. I.2). AI systems are assessed in the same way as ICT systems by risk profile, complexity and the functions they support (Ch. II.1). The guidance explicitly differentiates by criticality at these points:

• AI strategy: becomes more significant when AI supports critical or important functions (Ch. II.2).
• Control functions and internal audit: involvement in the roll-out depends on the criticality of the AI system (Ch. II.2).
• Testing: scope commensurate with criticality (Art. 16(2) RTS RMF); adversarial testing and stress tests “depending on criticality” (Ch. III.2).
• Detection: risk-based logging; thresholds and indicators of anomalous behavior where critical or important functions are supported (Ch. IV.1).
• Cloud: SLAs, exit strategy, contingency testing and audit rights covering the entire subcontracting chain where critical or important functions are supported (Ch. IV.2).

AI strategy and technology roadmap

According to Ch. II.2, financial entities “often” develop an AI strategy aligned with their overall strategy, risk strategy and, where applicable, ICT strategy and digital operational resilience (DOR) strategy, and have it approved by the management body — either as a stand-alone strategy or integrated into an overarching one. Its significance grows above all when AI supports critical or important functions. It can be based on a technology roadmap that defines the ICT resources, capacities and investments for AI deployment; continuous innovation management helps to evaluate new AI technologies. It makes sense to cover and document all steps, from strategy through development to retirement, along a single process. According to the guidance, it is important to check before implementation whether the relevant processes are designed for AI and whether there is awareness of how to handle information assets.

Obligation and practice at a glance

According to Ch. II.2, it is helpful to formulate general requirements that are consistent with the DOR strategy and with the information security policies and guidelines. Specific arrangements for ICT third-party service providers and their services should ideally take into account a risk assessment, information from the provider and the entity’s own risk reduction measures. The general requirements should be tailored to the use case, together with a review of whether additional AI-specific measures are necessary.

Skills anchor: the guidance bases its skills requirements on Art. 5(4) and Art. 13(6) DORA, not on Art. 4 AI Act. The AI Act’s AI literacy rule has applied in parallel since 2 February 2025; Regulation (EU) 2026/1744 has softened it: instead of ensuring, to their best extent, a sufficient level of AI literacy, measures are now to be taken to support the development of AI literacy.

Art. 6(1) DORA requires a sound, comprehensive and well-documented ICT risk management framework as part of the overall risk management system. The guidance highlights this provision in a quote box and lists, among the components of the framework: identification, protection and prevention, detection, response and recovery, learning and evolving, and communication (Art. 8 to 11, 13 and 14 DORA). On this basis, integrating AI systems includes identifying vulnerabilities, for example in model training, data pipelines or inference, and assessing quantitative and qualitative risk criteria (Ch. II.3).

What the guidance derives for each DORA building block

Important for drawing the line: the case study classifies hallucinations as not directly ICT-related (Phase 4). Of the various aspects of data quality, only integrity is a DORA protection objective; the regulation contains no provisions on the others (Ch. V.2). Monitoring of model drift appears as a treatment measure to be documented, not as an ICT risk in its own right. The guidance places data quality requirements among the typical components of governance structures for AI — high data quality, especially for training data, remains a key prerequisite for deploying AI.

Annual review and report

The ICT risk management framework must be reviewed at least once a year and after major ICT-related incidents, supervisory instructions or findings from testing and audits (Art. 6(5) DORA). Upon request of the competent authority, a report on the review must be submitted; Art. 27 RTS RMF prescribes a searchable electronic format for it. The mandatory content under Art. 27(2) RTS RMF includes a summary of the current and near-term ICT risk profile and the threat landscape, the date of approval by the management body, findings with their severity, and remediation measures with deadlines and owners. The guidance adds that the report can, if required, be supplemented with specific information on AI systems.

Skills: who needs to know what

According to Ch. III.1, staff with AI-related tasks face the challenge of acquiring skills on how the AI systems work, their risks and the specifics of cloud and on-premises operation; the more technical the task, the more specific the knowledge required. Given the rapid pace of progress, the guidance considers regular training and continuous monitoring of developments necessary. For the management body and management, it refers to Art. 5(4) and Art. 13(6) DORA. Where business units build their own applications with AI assistants, it cites Art. 16(9) RTS RMF — that provision anchors the equal treatment of end-user computing, while the skills obligations themselves follow from DORA.

Obligation and practice in the development process

Training process: four approaches that, per the guidance, have proven helpful

• Training and test data come from trustworthy sources.
• (Open-source) libraries and software packages used in training contain no known vulnerabilities.
• The entire training process is documented and versioned.
• Security analyses uncover hidden manipulations in the model or the training data.

According to Ch. III.1, open-source libraries — in the extreme case an open-source model implemented, trained and operated on the entity’s own hardware — bring two additional risks: injected malicious code, and libraries that are no longer maintained after a few years and leave identified but unresolved vulnerabilities behind. AI-generated code is subject to the same rules as human-written code. The challenge lies in checking whether it invokes AI functions unknown to the user; among other things, this can be established through static code analysis (Art. 16(3) RTS RMF). Deeper source code analyses can provide additional assurance, and appropriate documentation has proven advisable for downstream testing.

What the RTS RMF makes binding

Financial entities must develop, document and implement tests. The scope of testing must be commensurate with the criticality of the business procedures and ICT assets concerned and must verify that new ICT systems — and hence AI systems — are appropriate for their intended purpose (Art. 16(2) RTS RMF). Before deployment to production, source code must be checked for anomalies using static and dynamic testing, including security testing of internet-exposed systems (Art. 16(3) RTS RMF). Proprietary software and, where feasible, source code from ICT third-party service providers and open-source projects must be analyzed and tested before going live (Art. 16(8) RTS RMF).

Three AI-specific challenges (Ch. III.2)

Testing components by criticality

Operating processes should cover the entire lifecycle — development, installation, operation and deinstallation — and document all operating activities, such as log files from model inference processes (Art. 8 RTS RMF). Information and ICT assets, including AI components, are to be identified, classified, documented and continuously monitored (Art. 8(4) DORA in conjunction with Art. 4 and 5 RTS RMF; see Chapter 2). The guidance describes role-based access rights to AI models and training data as an effective tool that is to be regularly verified and documented; Art. 21 RTS RMF requires least privilege and a review of access rights at least once a year, and at least every six months for systems supporting critical or important functions.

Operational building blocks at a glance

The wording shows how much of this is obligation and how much is practice: the plans “must” be tested at least once a year (Art. 11(6)(a) DORA), and Art. 10 RTS RMF prescribes automated vulnerability scans at least weekly for assets supporting critical or important functions. Continuous monitoring, comprehensive logging of AI decisions and AI-specific thresholds for anomalous behavior, by contrast, are described by the guidance as useful, advisable or beneficial — the general obligation to have detection mechanisms with alert thresholds (Art. 10(1) and (2) DORA) remains unaffected. For the operation and maintenance of an AI assistant (Phases 4 and 5), the case study adds situation-specific monitoring of AI interactions, automated updates, a security incident response plan (SIRP) and a compliance dashboard showing model version, risk assessments and responsibilities. Chapter 9 covers deinstallation.

Evidence you can present (VamiSec)

• AI inventory with components, criticality, owner, data provenance and vendors’ end-of-support dates, including deprecation dates for model versions
• Capacity planning and monitoring reports for the AI infrastructure
• Logging policy with thresholds and evidence of effectiveness testing
• Recertification of access rights to models and training data
• Test records for business continuity plans covering AI outage scenarios

The guidance already identifies the risk in Ch. II.1: the uncontrolled reuse or unsafe disposal of AI applications can jeopardize sensitive model or company data. The case study is more specific — historical data and models can be misused or unintentionally disclosed to the public. It concludes that the retirement of LLMs and associated data sources is to be planned “as with all ICT assets”. Ch. II.2 already suggests covering and documenting all AI-relevant steps in a single process, from strategy through to retirement.

Obligation, practice, recommendation — clearly separated

An AI system leaves behind more than an application. The information and ICT assets listed in the guidance include training data sets, model implementations, software libraries, hardware, and internally and externally developed software (Ch. IV.1); for deletion, the case study adds historical AI interactions. In our experience, RAG knowledge bases, model copies in backups, and API keys and service accounts belong on the same list.

Retirement runbook (VamiSec recommendation)

1. 1
   Define trigger and scope

   Retirement, version changes and provider changes trigger the same process. Derive all artifacts from the AI inventory: model versions, training data, knowledge bases, logs, interfaces, accounts.

2. 2
   Cut dependencies

   Deactivate interfaces, service accounts and API keys; block user access (Art. 21 RTS RMF). Deactivate obsolete model versions deliberately — don’t just take them out of routing.

3. 3
   Weigh retention against deletion

   Logs are subject to the retention periods set under Art. 12 RTS RMF; interactions containing personal data are subject to the GDPR. Resolve the conflict, and document how, before deleting anything.

4. 4
   Delete irretrievably

   Delete models, data and copies — including in backups and at the provider; where possible, use cryptographic wiping by destroying the keys (Art. 7 RTS RMF).

5. 5
   Document evidence and close the inventory entry

   File the deletion log and the provider’s confirmation, set the inventory status to “retired” and feed the lessons learned back into the ICT risk assessment.

The case study’s measures are illustrative; what is binding is the deinstallation requirement in the RTS RMF. For cloud AI, we believe deletion at the provider belongs in exit planning (Chapter 10).

The structural template is the supervisory statement on outsourcing to cloud service providers — the joint assessment by BaFin and the Deutsche Bundesbank, which revises the November 2018 guidance on cloud outsourcing. Some of its aspects “can also be applied to AI systems” (Ch. IV.2). One terminological difference remains: the supervisory statement thinks in terms of (material) outsourcing, DORA in terms of critical or important functions.

Where the obligation begins

What is binding is DORA itself: before entering into any contractual arrangement on ICT services, financial entities must assess the risks and carry out due diligence (Art. 28(4) DORA); the minimum content under Art. 30(2) DORA applies to all contracts. Additional contractual provisions (Art. 30(3)), exit strategies (Art. 28(8)) and the RTS Subcontracting apply only to critical or important functions. In our view, a writing assistant with no role in decision-making therefore needs a leaner set of contracts than a scoring model in a critical or important function — but the classification must still be documented (Art. 8(1) DORA).

Three citation subtleties

• Art. 3(6) ITS on the register of information governs the identifier of subcontractors (LEI or EUID); the obligation to record them is in Art. 3(2)(b).
• Art. 28(8), third subparagraph, DORA concerns the testing of exit plans; Art. 11(4) DORA, which the guidance cites in Ch. IV.1, is the more precise basis for emergency tests of outsourced critical or important functions (VamiSec interpretation).
• For the return of data and its format, Art. 30(2)(d) DORA is the more precise basis; BaFin does not cite it (VamiSec interpretation).

The starting point is Art. 9(2) DORA: financial entities must design, procure and implement ICT security policies, procedures, protocols and tools. According to the guidance, AI systems should be adequately considered in these — with measures for network security, data transmission (Art. 2(1) RTS RMF) and protection against data misuse. For AI, this means that, besides model access, the data exchange between training data, model components and end users should also be secured.

Five proven measures for AI systems

• Continuous real-time monitoring for anomalous behavior, e.g. unexpected decision patterns
• Protective mechanisms against adversarial inputs, such as filters
• Logging of relevant output and API calls for subsequent analysis
• Regular updates of the AI system to counter new threats
• Contingency plan for security incidents in the AI system

Important for your evidence: the guidance names these five measures as proven practice immediately after its reference to Art. 24 and 25 DORA — they are not backed by those articles. The testing program is the obligation; how it is designed for AI is practice. The binding minimum frequencies are set out in the legal text:

The guidance views AI primarily as a target. With ESRB warning ESRB/2026/3 of 25 June 2026 and the ECB letter of 7 July 2026, AI is now also in focus as an attack tool: the ESRB describes frontier models that find vulnerabilities and generate working exploits; the ECB has asked significant institutions to submit an action plan to their Joint Supervisory Team by 31 October 2026. In our view, both are aimed mainly at an area that Art. 10 RTS RMF already governs — vulnerability and patch management, only at a much faster pace.

According to the guidance, classification by confidentiality, integrity and availability is the “most important basis” for secure processing and storage: it determines how and where data can be processed and stored — and, per Ch. V.2, is a valuable addition when AI is operated in the cloud. The guidance cites Art. 5(2)(b) and Art. 11(2)(k) RTS RMF. Strictly speaking, point (b) sets criteria for assessing the criticality of assets and point (k) sets requirements for assets operated by ICT third-party service providers; in our reading, the general obligation to classify information and ICT assets is found in Art. 8(1) DORA.

Proven practices — adaptable to each entity

• Encryption and signing of models against unauthorized modification
• Operation in secure environments, e.g. containers
• Zero-trust model for access to AI services
• Protection against injection attacks; rate limiting against denial of service

For LLM assistants, the case study starts protection at the source: automated detection of confidential data, differential privacy against inferences from multiple queries, tokenization of sensitive data before processing — and, for Variant 3, a lower data clearance level that users cannot exceed of their own accord (case study, Phase 1 and Variant 3).

Data quality: only integrity is a DORA protection objective

According to the guidance, data quality typically covers completeness, accuracy, validity, consistency, appropriateness or representativeness, and integrity. Only integrity is a DORA protection objective; the regulation contains no provisions on the other aspects. Even so, the accuracy, reliability and performance of AI depend on them, especially where training data is concerned — which is why data quality requirements typically belong in AI governance. Fittingly, the case study counts hallucinations among the challenges that are not directly ICT-related.

Ch. V.2 relies exclusively on the RTS RMF (Art. 5, 6, 7, 11 and 14); the guidance cites no DORA articles in this section.

The figures come from BaFin’s analysis of the 2025 ICT incidents reported under DORA and from the BaFinJournal article “Vernetzung vervielfacht IT-Risiken” (“Interconnectedness multiplies IT risks”, in German) of 16 July 2026, which presents that analysis. They cover all reported ICT incidents; BaFin does not publish AI-specific figures. The third-party share is instructive nonetheless: in our view, anyone sourcing a model via an API also depends on their provider’s incident record.

Not every ICT-related incident in an AI system has to be reported — but every one has to be recorded (Art. 17 DORA). Whether an incident is major is determined by the classification criteria under Art. 18 DORA, which the guidance itself does not cite. Significant cyber threats may be notified on a voluntary basis (Art. 19 DORA).

Proven measures per the guidance

1. 1
   Identify AI-specific threats

   Identify AI-specific threats in a targeted way, e.g. the manipulation of training data.

2. 2
   Detect AI incidents

   Detect model errors, data loss or performance problems in a way that allows immediate action.

3. 3
   Analyze impact, classify severity

   Impact analysis, e.g. of data loss, and classification of severity levels.

4. 4
   Integrate into incident response

   Integrate incidents from AI systems into the general incident response policy — with the roles and the communication and escalation paths that Art. 17 DORA requires in any case.

5. 5
   Analyze root causes and learn

   Detailed root cause analysis to remedy systematic weaknesses in models and processes and to prevent recurrences for good.

For AI in the cloud, the guidance also recommends arrangements for reporting ICT incidents that arise in AI systems, as well as sufficient qualified internal resources for assessment and response. For AI assistants, the case study adds a security incident response plan (SIRP) and simulated cyberattacks to test response times (Phase 5).

Outlook: the Commission’s Digital Omnibus proposal of 19 November 2025 (COM(2025) 837 final) — not to be confused with the Digital Omnibus Regulation on AI, Regulation (EU) 2026/1744, which has already entered into force — provides, among other things, for routing reports under Art. 19(1) DORA through a single entry point. It is only a proposal; Art. 19 DORA as currently in force remains authoritative.

It examines three infrastructure variants (Figure 2): on-premises, cloud with the AI application in the entity’s own tenant, and cloud with the AI application outside its own tenant. Hybrid forms are explicitly possible; the risk discussion should then be adjusted accordingly. The case study does not consider investment or operating costs. Financial entities should implement the measures best suited to their specific risk situation.

Six phases: risks that apply in every variant

Three variants, three risk profiles

The case study and Ch. VI contain no DORA citations. Anyone linking the case study’s measures to legal anchors is making their own mapping — the obligations themselves derive from DORA and the RTS RMF.

AI Act and KI-MIG: where banks and insurers are directly affected

Under Annex III, point 5(b) AI Act, systems used to evaluate the creditworthiness of natural persons or establish their credit score are high-risk — except those used to detect financial fraud — as are, under point 5(c), systems used for risk assessment and pricing in relation to natural persons in life and health insurance. Under the Digital Omnibus Regulation on AI (Regulation (EU) 2026/1744), the high-risk obligations (Chapter III, Sections 1–3 AI Act) apply to these systems from 2 December 2027 instead of the original date of 2 August 2026.

Under section 2(3) KI-MIG, BaFin supervises AI systems that are directly connected with a regulated financial activity and are placed on the market, put into service or used by supervised entities — according to BaFin, for example, customer chatbots, creditworthiness assessments and risk assessment in life and health insurance. AI in human resources remains with the Federal Network Agency. BaFin’s focus here is on prohibited practices (Art. 5), transparency obligations (Art. 50) and AI literacy (Art. 4 AI Act); from 2 December 2027, the high-risk systems under Annex III, points 5(b) and (c) will be added. In the BaFinJournal interview on the KI-MIG of 29 July 2026, BaFin explicitly refers to the guidance.

EU supervision: same direction, different emphases

• EIOPA, Opinion of 6 August 2025 (EIOPA-BoS-25-360): explains to national supervisory authorities, in a risk-based and proportionate manner, how the IDD, Solvency II and DORA apply to AI at insurers — without introducing new requirements; prohibited and high-risk AI under the AI Act is excluded.
• EBA, factsheet of 21 November 2025: maps the AI Act’s high-risk requirements (with a focus on creditworthiness) against the CRD/CRR, DORA and other banking supervisory law — no significant contradictions; the EBA does not consider new EBA guidelines necessary.
• ESMA, public statement of 30 May 2024: AI in investment services for retail clients must comply with MiFID II obligations; responsibility remains with the management body.
• EBA, EIOPA and ESMA, statement JC 2026 25 of 31 July 2026: DORA and the AI Act as a sound basis for addressing ICT risks from frontier AI models; prevention includes a complete asset inventory that covers AI/ML components.

The explainability requirement for AI models is not new in the 9th MaRisk amendment; it was already contained, with identical content, in AT 4.3.5 of the 7th amendment (Circular 05/2023 (BA)).

1. 1
   Phase 0 · Month 1Clarify mandate and scope

   The management body confirms its ultimate responsibility (Art. 5(2)(a) DORA) and provides a budget; check whether Art. 5–15 or the simplified framework under Art. 16 DORA applies; name the people accountable for AI outputs in each function.

2. 2
   Phase 1 · Months 1–3Create transparency

   Build an AI inventory — including AI consumed via API and embedded in standard software (Art. 8(4) DORA in conjunction with Art. 4 and 5 RTS RMF); record criticality, infrastructure variant, data classes and owner for each system.

3. 3
   Phase 2 · Months 3–6Adapt the framework

   AI strategy or an AI section in the DOR strategy; embed AI in the ICT risk management framework, security policies (Art. 9(2) DORA), incident policy (Art. 22 RTS RMF) and third-party contracts (Art. 28–30 DORA).

4. 4
   Phase 3 · Months 6–9Harden and test

   Pre-production tests proportionate to criticality (Art. 16(2) RTS RMF), supplemented by adversarial testing for AI in critical or important functions; thresholds for anomalous AI behavior in critical or important functions (Art. 10(1), second subparagraph, in conjunction with Art. 10(2) DORA); Governance Shield for Variant 3; test business continuity plans (Art. 11(6)(a) DORA, Art. 25 RTS RMF).

5. 5
   Phase 4 · Months 9–12Demonstrate effectiveness

   Annual review of the ICT risk management framework (Art. 6(5) DORA) with an AI section in the report under Art. 27 RTS RMF; feed in lessons learned (Art. 13(3) DORA); test exit plans (Art. 28(8) DORA); document training (Art. 5(4), Art. 13(6) DORA).

Metrics the board understands

Proportionality applies to the roadmap, too: an AI-based self-service assistant that is entirely under human supervision and not involved in decision-making processes does not need the same control depth as AI in a critical or important function (Art. 4 DORA, Ch. I.2). Starting with the inventory allows you to scale that depth on a reasoned basis — and to document the reasoning.

The guidance is non-mandatory advice, not a binding interpretation of DORA by BaFin. What is binding are DORA, the RTS RMF and the RTS Subcontracting. The roadmap is a VamiSec recommendation and does not constitute legal advice.