DORA Third-Party Management: Practical Report from a cross-border harmonization project

Initial Situation: Heterogeneous Processes Meet Ambitious Goals

In early summer 2024, a European fund service platform and master asset management company (KVG) with subsidiary companies in Germany, Luxembourg, and Ireland faced a complex initial situation. The DORA implementation had been established as a comprehensive programme with five parallel sub-projects: ICT Risk Management, Incident Management, Business Continuity Management, Operational Resilience Testing, and Third Party Risk Management. Whilst other consulting firms led the first four sub-projects, we were responsible for establishing group-wide third-party management.

The challenge was not that nothing existed. Quite the contrary: each subsidiary company had developed its own functional processes over the years. The German entity aligned with MaRisk requirements. Luxembourg followed CSSF regulations, and Ireland had to fulfil the requirements of the Central Bank of Ireland. Although each of these regulatory frameworks is based on the EBA Guidelines on Outsourcing Management (EBA/GL/2019/02), the implementation differs from country to country. This heterogeneous process landscape was not a problem in itself; however, it presented our project with the challenge of achieving group-wide harmonisation alongside pure DORA implementation, without discarding proven local approaches.

Data management reflected this fragmentation. All contracts existed digitally, but by no means all were maintained in the designated database or were up to date. Different companies used different lists. Some worked with professional vendor management platforms, others with Excel-based solutions. A central overview of ICT service providers did not exist. No statement could be made about which service providers were critical overall, where concentration risks existed, or how many ICT services were actually in use.

The governance structures were particularly unclear. The question was not who negotiates contracts—that was clearly the domain of the Corporate Legal Department. Rather, it was unclear what the fundamental distribution of roles in third-party management should be: What strategic role should the Group function assume? Which operational tasks would remain with the subsidiary companies? And how should the in-house IT company be integrated, which provided IT services for the other companies and thus itself became a service provider subject to assessment?

The timeline put additional pressure on the project. DORA requirements would apply from 17 January 2025. The information register with all ICT service providers had to be created with data as of 30 March 2025 and submitted to the relevant supervisory authorities by the end of April 2025. From July 2024 to April 2025, therefore, ten months remained for complete implementation—from stocktaking through harmonisation to register completion.

Phase 1: Stocktaking and Source Identification

In the first months of the project, we devoted ourselves to thorough stocktaking. We began where every good project starts: with listening and understanding. In structured conversations at two levels, we first clarified at Group level which central functions already existed and what requirements there were. At subsidiary company level, we were interested in how the processes for outsourcing management were specifically organised, who was responsible, and which tools were in use.

In parallel, we analysed all existing policies, process descriptions, and templates. Our goal was not to look for errors or weaknesses, but to find gems. Where were processes and approaches similar? Which subsidiary companies had already developed well-functioning and highly mature approaches that could serve as a basis for a group-wide rollout? What best practices already existed that we did not need to reinvent, but only needed to further develop?

This document analysis revealed interesting patterns. The subsidiary companies had achieved different levels of maturity. Some worked with sophisticated, systematic risk assessments based on quantitative scores. Others deliberately pursued minimalist approaches to avoid over-regulation or were forced to do so due to personnel resources. Nevertheless, each approach had its strengths and advantages, and we wanted to use precisely these for the Group solution.

Identification of Data Sources

The third major task in Phase 1 was the identification of possible data sources for ICT service providers. We searched for all available sources to create as complete a list as possible.

Three main sources crystallised: existing outsourcing registers, where they existed, offered an initial overview—although they typically contained only traditional outsourcings and, in some cases due to national requirements, no external procurements. Contract databases were a second source, although often not kept up to date. As a third source, we drew on an extract of payments to service providers from the Group accounting for the entire previous financial year, which was an enormous amount of data.

None of these sources was complete or directly usable in itself. Outsourcing registers often only recorded formal outsourcing contracts. Contract databases, whilst fundamentally more comprehensive, often suffered from lack of maintenance—not every contract amendment or extension was recorded. Payment data from accounting, in turn, contained no classification as to whether it was an ICT service.

The solution lay in consolidating all three sources. We brought the data together and supplemented it through interviews with the IT and specialist departments.

A recurring theme was the delimitation of ICT services. When is a service provider an ICT service provider within the meaning of DORA, and when is it not? The software of the human rights officer outsourced to the parent company—does that count? A facility manager who physically monitors the data centre—is that relevant?

We defined pragmatically: an ICT service provider was anyone who provides IT services for us or operates critical IT systems for us. Service providers who only use IT to provide their actual service did not fall within scope. In doing so, we oriented ourselves to the statements of the Federal Financial Supervisory Authority (BaFin) and the documents it made available.

At the end of Phase 1, we had documented the as-is situation of the organisational structure and processes at all levels, an overview of existing policies, processes, and templates, as well as identified best practices from various subsidiary companies. From three data sources and IT interviews, we had created a long list of potential ICT service providers. Importantly: this was not yet a complete or final list. The clear view of all ICT service providers only emerged at the end of the entire project, after we had systematically recorded the inventory.

Phase 2: Harmonisation and Governance Development

With the stocktaking as a solid foundation, we began in Phase 2 to develop a harmonised governance model and group-wide standards. The central challenge was to achieve a balancing act: we needed uniform group-wide requirements for DORA compliance, but at the same time had to meet the local requirements of MaRisk, CSSF, and CBI and preserve the expertise and acceptance of the subsidiary companies.

Development of the Target Operating Model

One of the most important deliverables was the Target Operating Model. This document described how the system would continue to operate after the project ended: How are new ICT service providers identified and onboarded? Who is responsible for what? How does ongoing monitoring work, and at what intervals do reviews take place? Which reports are produced when? The TOM ensured that the project did not remain a flash in the pan, but was transferred into sustainable operational processes.

In addition, the development of a Group strategy for managing third parties was a central deliverable. This document established the strategic requirements: what objectives do we pursue with third-party management? How do we position ourselves in the procurement of ICT services—group-internal or direct procurement? The strategy formed the foundation for everything that followed.

Building on this and on the TOM, we created the Group policy for managing third parties. It translated the strategy into an operational framework with concrete processes, clearly defined roles, and unambiguous responsibilities. The art lay in being detailed enough to create clarity, but remaining flexible enough to accommodate local particularities where necessary. A rigid one-size-fits-all solution would have failed in the reality on the ground and would not have been accepted either.

The heart of the governance was a Target Operating Model that clearly distributed responsibilities.

The Group function assumed the strategic role: it set group-wide standards and requirements, consolidated information from all subsidiary companies, and maintained the group-wide information register. It was not responsible for every operational detail, but it ensured consistency and completeness at Group level.

The subsidiary companies retained operational responsibility for their local ICT service providers. They conducted due diligence and risk analyses, provided the ICT service was not used group-wide, were responsible for their local information registers, and reported relevant information to the Group function. This decentralisation was deliberately chosen: the operational teams on the ground knew their ICT service providers best and should continue to bear primary responsibility.

The Group's own IT company occupied a special position. As a sister company that provided IT services for other Group companies, it had a dual role: on the one hand, it was itself an ICT service provider subject to assessment that had to be evaluated according to DORA criteria like any external provider—including contractual relationships, service level agreements, and exit strategies. On the other hand, it was an indispensable technical expert for the technical assessment and provision of information on external ICT service providers and served as an interface to these service providers. This dual role had to be clearly regulated in the governance to avoid conflicts of interest. The solution: when evaluating external service providers, the IT subsidiary acted as a technical expert. In its own evaluation, it was supported by a dedicated third-party management team.

Parallel to strategy and policy development, we created standardised templates for operational work. A questionnaire for due diligence of third parties helped the subsidiary companies to systematically query all relevant aspects. A template for risk analyses of ICT service providers ensured that all companies evaluated according to the same criteria. The contract checklist ensured that all minimum contractual contents were agreed. A template for regular monitoring defined which KPIs should be monitored and at what intervals reviews took place. It was important to us that we followed a risk-oriented approach; the scope of the questionnaire and also the risk analyses depended on whether it was a critical ICT service provider, whether subcontractors were used, or whether concentration risks existed.

The process by which these documents were created was just as important as their content. Instead of holding three-day workshops with all companies and then presenting finished concepts, we chose a different path: we established a fortnightly, regular exchange with all participants throughout the entire project duration. In these calls, we informed about project progress, presented drafts of strategy, policy, and templates for discussion, obtained feedback, and identified potential implementation barriers early.

This continuous dialogue had several advantages over punctual workshops. Firstly, it prevented the subsidiary companies from being run over with finished concepts. Secondly, it enabled iterative improvements: we could readjust based on feedback before documents were finally approved. Thirdly, it optimally used local expertise. When the Luxembourg subsidiary company explained why a particular process step must run differently at CSSF-regulated companies, we could incorporate this directly into the policy. And fourthly, this approach created acceptance and ownership. Participants felt: we are being heard. Our expertise is flowing in. This is not another consultant document being imposed on us, but a joint solution.

The harmonisation did not work according to the principle: we take the approach of company X and roll it out everywhere. Rather, we identified which elements from which companies functioned particularly well and used these as building blocks for the Group solution. We combined the systematic risk assessment logic of one company with the strong monitoring focus of another and the pragmatic anti-over-regulation approach of a third. The result was a multi-stage assessment model: a simplified basic assessment for all ICT service providers and a detailed, in-depth assessment for those classified as critical or important by the parallel ICT Risk Management sub-project.

At the end of Phase 2, we had a Group strategy and Group policy approved by management, a documented governance model with clear roles and escalation paths, as well as standardised templates for due diligence, risk assessment, contract review, and monitoring. More importantly: we had gained acceptance from all subsidiary companies. No one felt overridden or confronted with unrealistic requirements.