A Newcomer’s Account of a DORA Contract Compliance Implementation Project
The Digital Operational Resilience Act (DORA) requires financial institutions, effective January 17, 2025, to enforce new minimum contractual requirements for ICT (Information and Communication Technology) contracts with their ICT service providers. The topic of DORA has been with me since the start of my career. My project team and I were commissioned by a German financial institution to ensure its DORA contractual compliance. Based on this project experience, I would like to report in this article on our approach to the project and the insights we gained.
To ensure contractual DORA compliance for the financial institution’s ICT contracts, we first had to define a project approach. This involved determining the current and target states, as well as establishing a basis for measuring the project’s success. To this end, we defined the individual steps required to ensure that an ICT contract could be considered DORA-compliant and audit-proof in the eyes of BaFin.
Quelle: Eigene Darstellung
1. Define the project scope
DORA contract compliance involves ensuring the contractual content of ICT contracts. This includes retroactively amending existing ICT contracts and adapting new contracts to meet the minimum contractual requirements set forth by DORA. Accordingly, it made sense to select the achieved DORA compliance of a defined contract portfolio on an individual contract basis as the basis for measuring project success. The project scope was defined as the population of all ICT contracts existing at the time the project began. To do this, all of the company’s existing ICT contracts had to be identified. In our case, the financial institution’s internal third-party risk management team conducted a preliminary review of the entire portfolio of ICT contracts and provided us with a corresponding list as a result. And this is where we encountered our first stumbling block. On the one hand, we had to trust that these contracts, following the internal preliminary review, were indeed ICT contracts and thus DORA-relevant—a trust that later proved to be misplaced—and on the other hand, we initially had to assume that these were only active contractual relationships.
Learning
A robust definition of the project scope forms the foundation for a DORA implementation project that can be reported on. Ideally, the DORA relevance of the contracts and their status should have been carefully validated before the scope was defined to avoid additional effort and misallocations in the project later on.
2. Ensuring Data Quality
In addition to receiving the project scope, we were granted access to the company’s IT contract database, which allowed us to review contractual responsibilities, contact persons at relevant service providers, and the terms of IT contracts within our project scope. Given the client’s awareness of the poor data quality in the contract database, it was decided that ensuring data quality was worthwhile before communicating with the company’s affected service providers. We therefore coordinated with all contract managers listed in the system for the contracts within our project scope regarding the current contract status, contract responsibilities, and contact persons at the respective service providers. This proved to be particularly worthwhile, as more than a quarter of the contracts handed over turned out to be inactive contractual relationships, which accordingly did not require any adjustment to the contractual DORA minimum requirements and were removed from the scope of the project.
Since a large portion of the contract responsibilities and service provider contacts stored in the system were no longer up to date, the coordination effort increased significantly. As a result, this project step accounted for nearly a quarter of the total project effort. Thus, this effort could have been prevented in advance by integrating a role-based contract management system that is consistently maintained.
Learning
The systemic data quality of contract data is a major driver of effort. A consistently maintained, role-based contract management system reduces the resulting coordination effort.
3. Create DORA Contract Documents
To ensure compliance with the minimum contractual DORA requirements, contractual rights and obligations under DORA must be documented in writing, which means being able to present mutually accepted contract documents that meet the minimum DORA requirements. Thus, for all existing active ICT contracts within the project scope, we prepared a DORA addendum as a supplementary contract document, which is to be negotiated with the relevant service providers. In this project, it was a great advantage for us that the financial institution was already able to provide us with a contract template, which it had created in collaboration with the German Insurance Association (GDV) and which legally reflected all the minimum contractual DORA requirements. When drafting the documents, we only had to adjust the contractual identifiers—such as the contract number and contract name—to reference the main contract. This approach saved us a significant amount of effort in this step.
Learning
Standardized DORA contract templates create efficiency gains in the creation of DORA contract documents. The consistency of the uniform templates minimizes the operational effort required to manage and monitor ICT service providers as they implement the DORA contract terms.
4. Communication with Service Providers
We were then able to contact the service providers with the generated DORA annexes. This is where we encountered the next problem. We discovered that many of the service provider’s contact persons listed for us were no longer current or were no longer employed by the respective company at all. Even internally, the contract managers could not provide us with alternative contact persons, and systemically, new or, in some cases, any contact persons for the service provider were not recorded, resulting in our most frequent contact being “info@serviceproviders”. As one might imagine, prompt responses are often lacking with such email addresses. By consistently tracking all service provider contacts for each contract, we could have reduced additional effort and driven project progress more effectively.
Learning
Missing or outdated service provider contacts directly lead to delays in the communication process and hinder project progress. Here, too, a consistently maintained, role-based contract management system can help preventively reduce project workload.
5. Coordination of contractual clarification needs
When the service providers responded, the feedback to our inquiry varied widely, but in most cases they were not immediately inclined to sign the DORA annexes. Only in the case of a few contracts were the service providers willing to sign our DORA annex without negotiating any necessary adjustments. There were often discussions as to whether the contracts in question were even ICT contracts and thus subject to DORA. This likely resulted from the fact that the definition of ICT services under DORA allows for interpretation. Against this backdrop, it is advisable to develop a definition of an ICT service based on DORA’s guidelines as early as the preliminary review of the IT contract portfolio. This enables consistent and legally sound arguments regarding demarcation and classification issues when dealing with service providers. At this point, it turned out that approximately 5% of the contracts within our project scope did not, in fact, include ICT services as defined by DORA and were therefore not DORA-relevant. In these cases, a notification had to be sent to the service provider, which generated unnecessary project effort.
For the most part, the service providers wanted to enter into negotiations regarding the contents of the DORA annex. In order to proceed with negotiations with the service provider, we were referred to internal clarification bodies within the financial institution. The need for clarification varied in terms of technical and legal nature. Not only did this hinder project progress, but it also resulted in additional significant project overhead, which could have been prevented through realistic capacity planning of the internal legal department by the internal project management. This was primarily due to the fact that we observed that, as DORA progressed over time, the financial institution’s service providers developed a greater awareness of DORA contract compliance, leading to an increasing number of service providers wanting to enter into more concrete DORA contract negotiations.
In addition, there were instances where a service provider was consistently unwilling to discuss the issue of DORA contract compliance, or where DORA contract negotiations at failed to yield a result, resulting in a complete lack of DORA contract compliance. For these cases, the financial institution established an internal central escalation body that could decide whether to accept the risk of non-compliance with DORA or to terminate the relevant contracts. In this way, our project progress remained unaffected. Accordingly, for the success of such a project, it is worthwhile to identify all possible outcomes of a contract negotiation and to decide when a single task in the project is considered complete.
Learning
Early-stage definition of escalation and decision-making bodies, as well as realistic capacity planning for the legal department, are crucial for effective DORA contract negotiations. From a project perspective, it is therefore necessary for project success to agree on clear completion criteria for a task.
6. Signing the Contract Documents
Once a DORA addendum had been finalized with the service provider, the signing process could begin. In this project, this was handled digitally via signature software. This saved us the effort that would have been required by the process of analog signatures. We only needed the information regarding internal and external authorized signatories to whom we should address the digital signature request. Internally, we encountered the problem that we were supposed to obtain this information from the respective contract manager, but it later turned out that we had been given the names of individuals without power of attorney who were not authorized to sign such a document, and we consequently had to cancel the signing processes, coordinate again, and restart them. This could have been prevented through internal project management by creating a list of the financial company’s authorized signatories at the start of the project—organized according to the respective responsibilities of the departments to which the relevant ICT contracts are subject—and providing it to us.
In contrast, a common issue with service providers was that they failed to inform their own authorized signatories about the receipt of our signature requests, which forced us to manage an additional communication loop between the contact person and their authorized signatory or even triggered further contract negotiations regarding the DORA annex. As the project progressed, we were able to resolve this effectively using the experience we gained by including a preamble in the signature request via the signature software that referenced the finalized DORA contract negotiations with the respective contact person.
Learning
Digital signature software streamlines the signing process. However, this requires identifying internal authorized signatories early on and determining the external authorized signatories of each service provider during contract negotiations.
7. Documentation of the workflow and document storage
Once we had obtained all signatures for a DORA annex, the relevant contract was initially considered DORA-compliant. However, it is not audit-proof at this stage, as the signed DORA annex still needs to be archived. Initially, there was no established standard for naming the documents or specifying the exact system storage location. This led to a situation where, when reviewing existing signed DORA annexes for a service provider—which could be referenced to ensure DORA contract compliance for ICT contracts and reduce operational overhead in the procurement department’s day-to-day operations—the corresponding documents could not be found in the systems. So we developed a standard for document naming, which only needed to be supplemented with the respective contract number, and defined systems as well as unique storage locations within the given folder structure. This step is essential, particularly for the traceability of a project outcome at the contract level.
In addition, the ability to trace the workflow of each individual process is very important for project management. Implementation in the project was carried out via a project management platform that made it possible to transparently involve stakeholders of a contract—such as a contract manager or, in the case of contract negotiations with a service provider, internal decision-making bodies—and to coordinate tasks within the process accordingly. Given the sheer volume of contracts that needed to be processed in this project, such transparency in the workflow was particularly important to us in order to effectively handle many processes simultaneously without any loss of information.
Learning
Centralized workflow management is essential, particularly when dealing with a large volume of ICT contracts within the project scope, to ensure tasks can be coordinated in a traceable and transparent manner. A digital project management platform is highly recommended for this purpose. The associated audit-proof documentation requires a coordinated standard for naming and storing the signed DORA contract documents in a financial institution’s systems.
What Really Makes a DORA Implementation Project Successful
In practice, achieving DORA contract compliance is far more than just a legal requirement. This project made it clear that the actual success of the project does not depend primarily on the drafting and negotiation of legally compliant DORA contract documents, but rather on the organizational maturity of the financial institution itself.
I have found that DORA contract compliance should not be viewed as a purely contractual project, and that the actual transformation effort is often underestimated. In reality, it was a complex management project at the intersection of procurement, third-party risk management, business units, the legal department, and external ICT service providers. This is precisely where the greatest challenges arise, but also where the most important levers for a successful project lie.
Are you looking to discuss this topic? If so, please feel free to contact me at florian.mueller@complion.de with any further questions you may have.
Author: Florian Müller