The Digital Operational Resilience Act, or DORA, enters its second year, which means most banks, insurers, and IT providers are now realising the gaps in their ICT contracts after spending a year rewriting the ones for their largest clients and classifying critical or important functions.
DORA's contract requirements impact in-house Legal teams in a very direct way, establishing what every ICT services contract must contain, and setting a stricter set of terms for contracts that support critical or important functions.
While banks and insurers are affected directly, software vendors, cloud providers and managed service providers experience DORA through contractual requirements demanded by their clients. Under Articles 28 to 30, IT contracts with banks must now include detailed service level agreements (SLAs) with data processing locations, mandatory audit and access rights for banks and regulatory authorities and business continuity, exit, and transition plans in case of provider failure.
To help your team maneuver all the changes and ensure they apply to either all ICT contracts or to the only critical/important functions, we developed this DORA compliance checklist. It works through DORA’s requirements clause by clause and serves as a template you can use for your own gap analysis.
For a more comprehensive analysis, book a LEGALFLY demo. We will walk you through the DORA Compliance Checklist using ICT contracts relevant to your portfolio.
To find out how LEGALFLY could work for you, schedule a call with one of our experts.
DORA in 2026: from implementation to supervision
Three important changes stand out:
The information register must now follow an annual cycle
Under Article 28(3), financial entities must keep a register of information on all contractual arrangements with ICT third-party service providers, and report it at least yearly. The ESAs set March 31st as the deadline for competent authorities to provide them with their registers, but national authorities can set earlier deadlines for the entities they supervise.
Supervisors can see the gaps
The register records the service, the provider, the function supported, the locations, the subcontracting chain and whether key terms exist for each contract. If one lacks an Article 30 provision, it will show up as a missing data point, or an inconsistency, across entities that use the same provider.
The subcontracting rules are settled
The Commission's final Regulatory Technical Standard was introduced on July 22nd 2025, and contracts signed or renewed since then are expected to reflect it. In other words, DORA compliance is no longer a repapering project with an end date but a contract standard that has to hold across every new deal, renewal and amendment, and that supervisors can test each year.
The Scope of the DORA Checklist
Article 30(2): what every ICT services contract must contain
Nine provisions serve as the baseline for every ICT contract, regardless of the function it supports, and are also where most first-generation DORA amendments fall short, because they were quickly drafted to meet implementation deadlines.
Any ICT contract must, therefore, include:
Service description and subcontracting. A clear and complete description of all functions and ICT services, stating whether subcontracting of a service supporting a critical or important function is permitted and, if so, on what conditions. A product catalogue or an order form reference is not a complete description.
Locations. The regions or countries where services are provided and data is processed, including storage locations, with an obligation on the provider to notify you in advance before any change
Data protection. Provisions on availability, authenticity, integrity and confidentiality of data, including personal data. It must also cover non-personal data, not only GDPR DPA.
Access, recovery and return. Access to, recovery of, and return of personal and non-personal data in an easily accessible format in the cases the provider becomes insolvent, enters resolution, discontinues its business, or the contract ends.
Service levels. Service level descriptions, including how they are updated and revised, and whether the provider can change them unilaterally without notice.
Incident assistance. An obligation on the provider to assist when an ICT incident related to the service occurs, at no additional cost or at a cost determined in advance.” Reasonable assistance at our then-current rates" does not meet this criteria.
Cooperation with authorities. An obligation to cooperate fully with competent authorities and resolution authorities, including the persons appointed to do so. It must also cover future authorities and not be limited by confidentiality clauses.
Termination rights and notice periods. Termination rights and minimum notice periods that meet the expectations of competent and resolution authorities. See the termination section below for the Article 28(7) triggers.
Training. The conditions for the provider's participation in your ICT security awareness programmes and digital operational resilience training, under Article 13(6).
Beware of location clauses that name a "primary" region but allow processing anywhere for support or backup, incident assistance capped at a fixed number of hours, with the extra ones then billed at standard rates, and cooperation clauses that exist in the DORA addendum but are overridden by a confidentiality clause in the master agreement, because the order of precedence was never checked.
Article 30(3): the stricter set for critical or important functions
Article 30(3) adds six more provisions on top of the nine of the previous baseline. This is where supervisors look hardest, and where provider pushback is strongest.
Contracts supporting critical or important functions must contain:
Full service levels. Complete service level descriptions with precise quantitative and qualitative performance targets, so you can monitor them and take corrective action without undue delay. Check for numerical targets, measurement periods, reporting and remedies, not just an uptime figure.
Notice and reporting obligations. Notice periods and reporting obligations on the provider, including notice of any development that could materially affect its ability to deliver the service in line with agreed service levels. Check that "material impact" is defined and the notice window is fixed.
Business contingency and security. Requirements for the provider to implement and test business contingency plans, and to maintain ICT security measures, tools and policies that give an appropriate level of security under the regulatory framework. Check for test frequency, your involvement in tests and access to results.
Threat-led penetration testing. An obligation to participate and fully cooperate in your threat-led penetration testing (TLPT) under Articles 26 and 27 (for more information, check the TLPT section below).
Monitoring, access, inspection and audit. A right to monitor the provider's performance on an ongoing basis, including:
Unrestricted rights of access, inspection and audit for you, a third party you appoint and the competent authority, including the right to take copies of relevant documents on site when critical to the provider's operations, without being impeded or limited by other contractual arrangements or implementation policies;
The right to agree on alternative assurance levels if other clients' rights are affected;
An obligation on the provider to cooperate fully during on-site inspections and audits; and
An obligation to provide details on the scope, procedures to follow and frequency of inspections and audits.
Exit strategies. Exit arrangements, in particular, a mandatory adequate transition period during which the provider keeps delivering the service to reduce the risk of disruption and/or support resolution and restructuring, and which lets you move to another provider or bring the service in house, consistent with the complexity of the service.
Beware of audit rights limited to one audit a year with 60 days' notice and no exception for the regulator, access rights that require you to rely on pooled audits or certifications only, with no fallback, and nd exit clauses that promise "reasonable transition assistance" but set no minimum period, and allow the provider to charge whatever it chooses.
Subcontracting: what the final RTS dropped, and what must still be in the contract
The final subcontracting RTS underwent several changes from its early 2024 drafts, including the deletion of Article 5 regarding the monitoring of the chain of ICT subcontractors. This might seem like a softening of the decision as a whole, but its scope is narrower than that.
What was dropped
The drafted Article 5 required the contract itself to establish how the financial entity monitors the whole subcontracting chain, including clauses on identifying the chain and monitoring the conditions agreed with subcontractors. As the Article was removed, these contract terms no longer apply and the entity's own obligations on supply chain oversight remain.
What still has to be in the contract
The final RTS keeps the requirements on the conditions for subcontracting. Whenever the contract permits subcontracting of a service supporting a critical or important function, check that it:
☑️ Identifies which services may be subcontracted, and on what conditions;
☑️ Keeps the provider responsible for services delivered by its subcontractors;
☑️ Requires the provider to monitor its subcontractors and establishes its monitoring and reporting obligations to you;
☑️ Requires the provider to assess risks linked to the location of subcontractors, and covers where subcontractors process or store data;
☑️ Requires the provider to flow down obligations into its own subcontracts, including monitoring and reporting duties, business continuity and ICT security requirements, and access, inspection and audit rights needed by you and the competent authority;
☑️ Requires the provider to make sure the service continues through the chain if a subcontractor fails;
☑️ Requires advance notice of any material change to subcontracting arrangements, with enough time for you to assess the risk and object, or require changes before it takes effect; and
☑️ Gives you a right to terminate if the provider makes material changes despite your objection or subcontracts without permission.
Be aware you are still responsible for due diligence and risk assessment before allowing subcontracting, and must still oversight and register entries for subcontractors that effectively underpin the service. It might not be a contractual obligation, but you should know your chain.
The register of information, now in an annual cycle
The register may not be a legal document but it is based on all your contracts. For each arrangement, the templates in the implementing technical standards ask about the parties, the ICT services, the function supported and its criticality, start and end dates, notice periods, governing law, service and data locations, the subcontracting chain for critical functions, and exit arrangements.
This means there is a direct link between contract drafting and regulatory reporting. If a contract does not state a data location, the register cannot report one accurately. If the same provider appears under different legal entity identifiers across group companies, the inconsistency will be visible when the ESAs consolidate the data. And so on and so forth. In order to prevent these disalignments, you must ensure your contracts include the following data:
Checklist: contracts that feed the register
☑️ Each ICT contract identifies the provider by full legal name and, where available, its legal entity identifier.
☑️ Start date, term, renewal mechanics and termination notice periods for both parties are stated in the contract, not only in commercial correspondence.
☑️ Governing law and the locations of service delivery and data storage are stated explicitly.
☑️ The functions supported are identified clearly enough to map to your function classification.
☑️ For critical or important functions, the contract requires the provider to give you the subcontractor information you need for the register, and to tell you when it changes.
☑️ Amendments, renewals and terminations are captured in the register as they happen, not reconstructed once a year.
Termination rights and exit strategies
Article 28(7) establishes that ICT contracts can be terminated in at least four situations. Article 30(2)(h) then requires termination rights and minimum notice periods that meet supervisors' expectations. Combined, they set the floor for any termination clause.
Checklist: termination triggers under Article 28(7)
☑️ A significant breach by the provider of applicable laws, regulations or contractual terms.
☑️ Circumstances identified through monitoring of ICT third-party risk that are deemed capable of altering the performance of the contracted functions, including material changes affecting the arrangement or the provider's situation.
☑️ Evidenced weaknesses in the provider's overall ICT risk management, in particular in how it ensures the availability, authenticity, integrity and confidentiality of data.
☑️ Circumstances in which the competent authority can no longer effectively supervise the entity as a result of the conditions of, or circumstances related to, the contract.
Be aware that these rights should not depend on any clauses that would deem them unusable in practice, such as the provider's agreement, a long cure period or a termination fee.
Exit strategies for critical or important functions.
Article 28(8) requires exit strategies for ICT services supporting critical or important functions. They must account for provider failure, deterioration of service quality, business disruption from inappropriate or failed service, material risk arising from the deployment of the service, and termination. Exit plans must be comprehensive, documented and sufficiently tested, and reviewed periodically.
Checklist: exit terms in the contract
☑️ A mandatory transition period, long enough for the complexity of the service, during which the provider continues to deliver at contracted service levels (Art. 30(3)(f)).
☑️ Transition assistance covering data migration, documentation and cooperation with a successor provider or your internal team.
☑️ Return of all data in an easily accessible, documented format, with a timetable and verification of completeness.
☑️ Fixed or pre-agreed pricing for exit and transition support.
☑️ Survival of access, audit and cooperation rights during the transition period.
☑️ Exit rights that apply in insolvency, resolution and discontinuation scenarios, not only on ordinary termination.
Incident cooperation, TLPT and standard clauses
Three further areas often sit outside the main Article 30 schedule, but they decide whether the contract works when it is tested:
Incident cooperation
Your own major incident reporting runs on a tight clock. Under the DORA incident reporting standards, the initial notification to your competent authority is due within four hours of classifying an incident as major and no later than 24 hours after becoming aware of it, followed by an intermediate report within 72 hours and a final report within one month. You cannot meet those deadlines if your provider takes days to tell you. Article 30(2)(f) covers assistance. The contract should also cover speed.
The provider must notify you of ICT incidents affecting the service within a fixed period, measured in hours.
Notices must contain enough information for you to classify the incident under DORA, with updates as facts develop.
The provider must support root cause analysis and provide the information you need for intermediate and final reports.
Threat-led penetration testing
Entities required to run TLPT must include ICT third-party providers supporting critical or important functions within scope. Article 30(3)(d) requires the provider to participate and cooperate fully. Article 26(4) allows pooled testing where a provider's participation could affect the quality or security of services to other clients, or the confidentiality of their data.
The provider must participate in and fully cooperate with your TLPT, including through testers you appoint.
Pooled testing is available as an alternative where Article 26(4) applies, with results shared with you.
Confidentiality, liability and scheduling terms for testing are agreed in advance, so they cannot be used to delay a test.
Standard contractual clauses. Article 30(4) asks entities and providers to consider standard contractual clauses developed by public authorities for specific services. Where such clauses exist for a service you buy, starting from them shortens negotiation and gives supervisors a familiar reference point.
Running DORA contract compliance with LEGALFLY
The previous checklist is the standard, but represents less than half the work. The bulk of it lays in applying it to hundreds of ICT contracts and keeping them aligned as the rules change. LEGALFLY, the legal operating system for in-house teams streamlines the process, from request to outcome, always within the guardrails set by Legal.
Wealins, part of the Foyer Group, uses LEGALFLY for regulatory monitoring and review. Its DORA proof of concept was resolved within hours, and the team has recovered up to a fifth of its working time. Its CEO, Luc Rasschaert, describes the shift as moving from searching for regulatory change to judging whether it is relevant.
Agent Studio
Agent Studio allows both the Legal and Compliance teams to build an automated workflow together.
It starts with Legal Radar detecting regulatory updates, such as a new RTS, ESA guidance or a national supervisor's expectation. If they have a high impact, the affected contracts are identified in SharePoint or in LEGALFLY. Next, Drafting produces the redrafts, applying your approved clause positions and fallbacks. Lastly, Legal reviews and approves every change, and the updated documents are uploaded back where they belong.
To find out how LEGALFLY could work for you, schedule a call with one of our experts.
Anonymisation
Banks and insurers often cannot let client or contract data reach a third-party model in identifiable form.
Anonymisation, the only legal AI that anonymises documents before analysis, solves that problem. It anonymises documents at import, before any analysis begins, so personally identifiable data never leaves your environment, and all processing happens on protected data. It is available in SaaS, single tenant or with on-premise anonymisation, on a platform that is ISO 27001 certified and SOC 2 Type II compliant.
To find out how LEGALFLY could work for you, schedule a call with one of our experts.
Contract Intelligence
With DORA, supervisors can now ask for notice periods, exit terms and renewal dates.
Contract Intelligence, launching now, provides full visibility across the contract lifecycle, from negotiation to monitoring renewals, notice periods, obligations and key dates. Your contracts will still be stored in CLM, LEGALFLY just understands them.
To find out how LEGALFLY could work for you, schedule a call with one of our experts.
Multi Review
Multi Review takes your ICT contract estate from SharePoint or your document system, anonymises every file, and applies one Article 30 playbook across all of it. It flags missing clauses, deviations and high-risk outliers, and extracts key fields such as locations, notice periods and subcontracting terms into a single dataset with source links.
It then exports the results to Excel to support your register of information. With LEGALFLY's DORA playbooks, both sides of the table are covered: the financial entity reviewing provider paper, and the ICT provider reviewing a bank's DORA amendment.
To find out how LEGALFLY could work for you, schedule a call with one of our experts.
FAQs About DORA Compliance Checklist
What does a DORA compliance checklist for contracts need to cover?
The nine Article 30(2) provisions for all ICT contracts, the six additional Article 30(3) provisions for contracts supporting critical or important functions, the Article 28(7) termination triggers, the Article 28(8) exit strategy requirements, and the subcontracting conditions in Delegated Regulation (EU) 2025/532.
Did the final subcontracting RTS remove the need to monitor the subcontracting chain?
No. It removed draft Article 5, which would have required specific contract terms on how the financial entity monitors the chain. The conditions for subcontracting, the provider's own monitoring and flow-down obligations, notice of material changes and termination rights all remain, and so do your own oversight and register obligations.
When is the DORA register of information due?
From 2026, competent authorities must submit registers to the ESAs by 31 March each year. Your national authority sets an earlier deadline for your entity. The register must also be kept up to date and made available on request.
Do all ICT contracts need audit rights under DORA?
The unrestricted access, inspection and audit rights in Article 30(3)(e) are mandatory for contracts supporting critical or important functions. All ICT contracts must include full cooperation with competent and resolution authorities under Article 30(2)(g).
