DORA audit 2026 – no more relief

From audit year 2026, DORA audits come without relief

With the audit of the annual financial statements for the 2026 financial year, the relief granted for the audit of the requirements under the Digital Operational Resilience Act (DORA) no longer applies. In the first audit year, 2025, the German Federal Financial Supervisory Authority (Bafin) still accepted this relief at the proposal of the Institute of Public Auditors in Germany (IDW). Where findings are likely can already be anticipated. In December 2025, Bafin and Deutsche Bundesbank presented first insights from their own DORA inspections, and the European Supervisory Authorities (ESAs) have published their first analyses of the registers of information and of incident reporting.

What changes with audit year 2026

The relief set out in Bafin’s letter to the IDW of 11 August 2025 (in German) applied to financial entities under direct Bafin supervision and only in the year of the first audit. It mainly concerned the audit report: deficiencies that had been fully remedied did not have to be presented individually, and the auditor merely pointed out that they had existed. In the following years, full reporting is required again, and the audit of operating effectiveness must cover the entire reporting period.

The audit standard has also been finalised. The IDW has published the final version of its auditing standard IDW PS 528 (in German) on the audit of the DORA requirements, as at 6 July 2026. For insurance undertakings, the new Section 40b of the Audit Report Regulation (Prüfungsberichteverordnung, PrüfV) on ICT was promulgated in May 2026. For investment firms, the revised Section 15 of the Investment Firm Audit Report Regulation (Wertpapierinstituts-Prüfungsberichtsverordnung, WpIPrüfbV) followed in September 2026.

The conclusion drawn by Bafin and Bundesbank (in German) from their own inspections is mixed. All financial entities inspected have taken action, and some ongoing programmes have milestones extending to 2027 or 2028. The written policies and procedures have been adapted, but in some cases their quality is insufficient and they were only finalised shortly before the inspection began. Content or approvals were missing, and the rules were not sufficiently tailored to the entity inspected. Implementation in day-to-day operations is often still pending. For 2026 and 2027, the supervisors have announced that regular testing and the improvement of operational resilience will be the focus of inspections. Inspections will become more entity-specific, and further follow-up inspections will take place.

Six audit areas with findings

The supervisors’ findings are taken from their presentation of December 2025 (in German) and relate to the inspections conducted up to that point. In our practical experience, the points remain relevant today. Critical or important functions come first, because almost every other requirement builds on them.

01 | Critical or important functions

Bafin and Bundesbank report that many inspections resulted in findings on the identification of critical or important functions. The process was not documented in a traceable manner, the inventory was implausible or incomplete, and the supporting information assets and ICT assets had not been fully identified and assessed. In addition, in the supervisors’ words, derivations had “not been thought through to the end”.

In our view, one key cause lies in the concept of a function. It is broad, yet it is often understood to mean only the existing business processes. DORA itself does not define the term. In its answer to question DORA019-2959, the European Insurance and Occupational Pensions Authority (EIOPA) describes functions as activities, services, processes or operations, individually or in combination. This also includes support functions, down to purely internal services such as payroll. In our view, however, ICT systems, service providers, staff and buildings are not functions. They are resources that are mapped to the functions.

The task itself is not new. Under MaRisk and BAIT, institutions already had to determine themselves which of their activities and processes are time-critical for contingency management and to classify them according to the protection objectives. MaRisk did not prescribe a binding scope for this. DORA does not change that. According to EIOPA’s answer, each financial entity defines its own internal taxonomy that reflects its business model and organisation. According to the European Commission, there is no official list of critical or important functions. Since the MaRisk version of 30 June 2026 (in German), contingency management under AT 7.3 is also linked to critical or important functions. What is new is that the business process alone is no longer a sufficient reference point. A function within the meaning of DORA covers more than business processes. What is also new is that availability is no longer the only criterion. According to Bafin’s FAQ on DORA (in German), a function can, for example, also be critical or important from a confidentiality perspective.

Under Article 3(22) DORA, a function is critical or important if its disruption would materially impair the financial performance of the financial entity, or the soundness or continuity of its services and activities. The same applies if the discontinued, defective or failed performance of that function would materially impair the continuing compliance of the financial entity with the conditions and obligations of its authorisation, or with its other obligations under applicable financial services law.

In our view, critical or important functions should be determined from the interplay of two assessments. The business impact analysis (BIA) shows what consequences a disruption would have. Confidentiality, integrity and authenticity are assessed through a classification of the function and its information assets. In our approach, a function is critical or important if the BIA shows that a disruption exceeds the defined intolerability threshold, making the function relevant for business continuity management. The same applies if the classification shows that a breach of a protection objective exceeds a predefined impact level, such as significant or existential damage. Under recital 70 DORA, functions considered critical in resolution planning are also covered.

The supervisors consider different approaches to be permissible. As a basis, they consider, for example, a process inventory with dependencies and interfaces to be useful. All ICT assets supporting a critical or important function must be identified, and the classification must be reviewed at least annually and whenever there is a specific reason.

How critical or important functions are identified

The identification and classification of functions and of information assets and ICT assets is therefore the basis for the risk-based implementation of DORA. Among other things, it determines which protection measures must be implemented. Errors at this point therefore carry through to everything else. The links in the register of information become inconsistent, the criticality of ICT third-party service providers cannot be justified, the recovery objectives lack a basis, and incident classification and testing scope miss the mark. Addressing this point resolves several findings at once.

02 | Register of information

In April 2025, the ESAs published the most common errors in the reporting of the registers of information. According to this publication, rejections were caused, among other things, by technical errors such as broken references between templates, missing primary keys or missing filing indicators.

For the 2026 submission, Bafin states its own figure (in German): around 90 percent of the registers of information submitted via Bafin received data quality feedback from the ESAs. In our view, this is consistent with the weaknesses Bafin and Bundesbank found in the inventories during their inspections: functions, processes and ICT systems recorded incompletely, missing dependencies, unclear responsibilities and data quality problems. The formal errors in the register of information can be checked automatically. An auditor needs no interpretation for this, the validation report is sufficient.

The supervisors recommend complete, up-to-date inventories with clear responsibilities and, where possible, automated data quality controls. In our view, this is where a core problem lies. Many institutions still compile the register of information largely by hand. Functions, assets, ICT third-party service providers and contracts are not held in a common database, for example in a governance, risk and compliance (GRC) tool, from which the register could be generated at the push of a button.

03 | Contractual arrangements under Article 30

The supervisors expect security requirements for ICT third-party service providers to be clearly set out in contracts and monitored regularly. In the inspections, they observed that ICT third-party service providers were not sufficiently involved and that contractual provisions on security requirements were incomplete or missing. Prioritising the amendments by criticality ensures a robust status for the contracts relating to critical or important functions by the time of the audit.

04 | Exit and concentration

For ICT services supporting critical or important functions, a financial entity must have an exit strategy in place. It must be able to exit the contractual arrangement without disrupting its business activities. Under Article 28(8), exit plans must be comprehensive and documented, sufficiently tested and reviewed periodically. How far testing must go depends on the principle of proportionality under Article 4(2). In our view, DORA does not require a trial switch of providers. A pure desktop review, in which the plan is merely read for completeness, is unlikely to be sufficient, however. One possible approach combines three elements:

Tabletop exercise with all parties involved. A realistic scenario such as insolvency, termination or a prolonged outage of the ICT third-party service provider is walked through step by step. Participants include the business unit, IT, third-party management, procurement and legal, and ideally the provider itself. The exercise traces triggers, decision-making paths, the target architecture or backsourcing, and the time required.
Technical sample test. The financial entity requests a data export from the provider and checks whether the data is complete, readable and usable in a replacement or test environment.
Review of assumptions. Notice periods and transitional provisions in the contract, available alternative providers and the estimated time required are compared against the recovery objectives from the BIA.

Results, gaps and measures should be documented and tracked. For particularly complex arrangements, a trial migration of individual data sets or components may also be useful.

In November 2025, the ESAs designated the first list of 19 critical ICT third-party service providers. The list is updated annually, and the designation for 2026 is still pending. Nikolas Speer, Bafin’s Chief Executive Director of Banking Supervision, made clear in December 2025 (in German) that financial entities are expected to anticipate, assess and manage the growing concentration risks themselves. In the medium term, he sees a new concentration risk in providers of artificial intelligence. The European oversight of these providers does not relieve financial entities of their responsibility. The incident statistics show why: across the EU, 29 percent of major ICT-related incidents in 2025 were caused by a failure at a third party, in Germany around half, according to Bafin (in German). According to Bafin, around 40 percent of the attacks reported in Germany targeted a service provider of the financial entity.

05 | Business continuity, detection and patch management

On business continuity, Bafin and Bundesbank report that the recovery objectives determined in the BIA are not adequately reflected in ICT business continuity management. Response and recovery plans are incomplete, outdated or untested. Tests and exercises are not realistic, staff are not familiar with the plans, improvement measures are not tracked, and ICT third-party service providers are insufficiently involved in plans and tests.

On detection, ICT systems supporting critical or important functions are not fully connected to the central monitoring system (security information and event management, SIEM). Detection scenarios are not systematically developed and tested, and alert handling outside business hours is not ensured.

Vulnerability and patch management is neither comprehensive nor automated, remediation deadlines are not met, and there is no central tracking. The incident statistics show the consequences. 46.7 percent of German incidents (in German) were caused by system failures, with Bafin citing faulty patches and updates as a frequent cause.

06 | Management body

Article 5(2) assigns specific responsibilities to the management body. These include, among others:

It bears the ultimate responsibility for managing the financial entity’s ICT risk.
It sets and approves the digital operational resilience strategy, including the determination of the appropriate risk tolerance level of ICT risk.
It approves, oversees and periodically reviews the ICT business continuity policy and the ICT response and recovery plans.
It approves and periodically reviews the ICT internal audit plans and the policy on arrangements regarding the use of ICT services provided by ICT third-party service providers.
It allocates an appropriate budget, including for training, and puts in place reporting channels through which it is informed of major ICT-related incidents and of relevant planned material changes regarding ICT third-party service providers.

In their inspections, Bafin and Bundesbank found that objectives and the risk tolerance level were not defined in a verifiable manner and that the management body had not approved and overseen them. The objectives of the digital operational resilience strategy were not documented coherently, and the written policies and procedures were incomplete or not specific enough. In addition, the necessary independence of the ICT risk control function was not ensured, and its staffing was insufficient.

Eight questions the management body should answer now

The questions follow the audit areas in which the supervisors report findings. If one of them cannot be answered with a document within a few minutes, evidence is missing at that point, regardless of the state of implementation.

Does our concept of a function go beyond the existing business processes, and are we already applying the definition of a function within the meaning of DORA completely and correctly?
Is our register of information generated from a common, maintained database, or do we compile it by hand every year?
Which contracts relating to critical or important functions still lack mandatory contractual provisions?
When did we last test the exit strategies for ICT third-party service providers supporting critical or important functions?
Have we analysed the concentration risks relating to our ICT third-party service providers, and have they been identified and addressed?
When did we last actually restore the ICT assets supporting a critical or important function, and what was followed up as a result?
Are all ICT systems supporting critical or important functions connected to the central monitoring system/SIEM?
Do we meet our own patch management deadlines, and where is this tracked centrally?

What should still be tackled by year-end

Determine functions under DORA and derive critical or important functions. Capture core functions for each authorised activity and all support functions, including purely internal ones. Map ICT systems, service providers, staff and buildings to them as resources. Determine availability through the BIA, and confidentiality, integrity and authenticity through the classification of the function and its information assets. Reconcile with critical functions from resolution planning, where available. Document the reasons for classifying a function as critical or important in writing, have the classification approved by the management body and pass it on to the supporting ICT assets.
Set up a common database. Bring functions, information assets and ICT assets, ICT third-party service providers and contracts together in one database, for example in a GRC tool. The register of information can be generated from it and checked continuously against the validation rules.
Test an exit plan. For the most important ICT third-party service provider of a critical or important function, conduct a tabletop exercise with all parties involved, technically check a data export and document the results and measures.

We support institutions all the way, from the initial assessment to the full implementation of the DORA requirements. This includes deriving the functions, building a common database for the register of information, amending contracts by criticality, testing exit plans and recovery, and preparing for the audit. If you are looking for support, please get in touch.