The Digital Operational Resilience Act changed what an ICT contract has to say. DORA applies to a wide set of EU financial entities, from banks and insurers to investment firms and payment institutions, and it reaches their ICT third-party service providers through the contract itself. The regulation does not simply ask for sound vendor management, it specifies content that contractual arrangements are expected to contain.
Two articles carry most of the contracting weight. Article 28 sets general principles for managing ICT third-party risk, including the requirement to maintain a register of information on all contractual arrangements for the use of ICT services. Article 30 sets out the provisions those arrangements must include, with a stricter list where the service supports a critical or important function.
This guide describes those requirements at the level of the obligation, which is the level a vendor management or resilience lead works at. It is not legal advice, and the precise application to your entity and contract population should be confirmed with counsel.
What DORA expects every ICT contract to state
The baseline content applies to contractual arrangements for the use of ICT services whatever the criticality of the service. Most of it looks familiar to anyone who has drafted an outsourcing agreement, and most legacy contracts still fall short, usually because the service description is vague or the data locations are unstated.
- Service description and locations, a clear and complete description of the functions and services provided, plus the countries where the service is performed and where data is processed and stored.
- Data availability, access and return, provisions on the availability, authenticity, integrity and confidentiality of data including personal data, and on access to, recovery of and return of data in a usable format.
- Service levels, descriptions of the service levels that apply, kept current through updates and revisions, so performance is measurable rather than aspirational.
- Incident assistance and cooperation, a duty to assist the financial entity when an ICT incident occurs, at no additional cost or at a cost agreed in advance, and to cooperate fully with competent and resolution authorities.
- Termination and training, termination rights with notice periods that work for the entity and its supervisors, alongside conditions for the provider to support ICT security awareness and resilience training.
Where the service supports a critical or important function, the list grows. Full service level descriptions with precise quantitative and qualitative performance targets. Reporting duties covering developments that could materially affect the service. Contingency plans and security measures that are implemented and tested. Participation in threat led penetration testing where applicable. Unrestricted rights of access, inspection and audit. Conditions on subcontracting. Exit strategies with an adequate transition period.
If a service supports a critical or important function, the stricter provisions apply, so the criticality decision has to be made before the contract is drafted and recorded where the contract team can see it. Entities that classify after signature spend the following year reopening agreements they have already executed.
The register of information is a contract data problem
DORA also requires financial entities to maintain a register of information on all contractual arrangements for the use of ICT services, kept at entity level and, where relevant, at consolidated level, and to make it available to competent authorities. This is where document based contract management fails. The register asks for structured attributes about every arrangement, and those attributes sit inside documents never indexed for the purpose.
- Contract data has to be extracted, not summarized. Provider identity, service type, criticality, data locations, subcontracting terms and notice periods all need to exist as fields, because a register is a dataset, not a narrative.
- Criticality belongs on the contract record. Both the stricter clause set and the register depend on whether the service supports a critical or important function, so that classification should travel with the arrangement.
- Subcontracting chains need to be visible. Conditions on subcontracting only work when you know which providers subcontract the ICT service, to whom, and in which countries the subcontracted work is performed.
- Change has to be captured as it happens. Renewals, amendments, new subcontractors and moved data locations all change the register, so updates belong inside the contract workflow, not an annual data collection exercise.
- Evidence belongs with the obligation. Audit reports, resilience test results, incident notifications and exit test outcomes should attach to the contractual duty they satisfy, which turns a supervisory request into a query.
A five step roadmap to DORA ready ICT contracts
Step 1, Build the ICT contract population
Start by defining what counts as an ICT service in your entity, then find every contractual arrangement that provides one. Include cloud, software, hosting, managed services, data feeds and connectivity, plus intragroup arrangements. Expect the population to be larger than procurement expects, because ICT services arrive through business units and acquired entities as well as central sourcing.
Step 2, Classify criticality before you draft
Map each arrangement to the business functions it supports, then record whether any of those functions is critical or important under your own assessment methodology. Store the outcome as a field on the contract record with the date and the approver. Everything downstream, the clause set, the audit rights, the exit expectations and the register entry, depends on that attribute.
Step 3, Gap assess at clause level
Compare each in-scope agreement against the provision list, clause by clause, and record the result as present, partial or absent. Clause level output matters because remediation is negotiated clause by clause. A document level flag tells you an agreement is deficient, while a clause level finding tells your negotiator which paragraph to reopen and what fallback to offer.
Step 4, Remediate by exposure, not alphabetically
Sequence remediation by criticality, concentration and renewal date. Arrangements supporting critical or important functions come first, then providers you depend on across several functions, then anything with a renewal or amendment already in flight, because an open commercial conversation is the cheapest place to add clauses. Track each requested change as an open item with an owner.
Step 5, Operate the register and the obligations
Once the population is clean, the work becomes operational. New and amended arrangements update register fields as part of the contract workflow. Audit rights, test participation, notification duties and exit reviews become dated obligations with owners. Reporting then draws from one source instead of a quarterly reconciliation between legal files, procurement records and a resilience spreadsheet.
Map your ICT contracts to the provision list
Bring a sample of ICT agreements and your current register extract. We will show the clause level gap view, the register fields it populates, and the obligations that follow signature.
How this connects to the rest of third party risk
DORA is specific about ICT, but the machinery it needs is the machinery good third party risk management already needs: a known population, a criticality view, clause level visibility and post signature tracking. Our guide to third party risk contract automation covers the shared foundation, and the same controls answer the evidence requests in this third party risk and exam readiness checklist.
Provisions, register fields and evidence
The table below groups the requirements into the areas a reviewer works in, states what the contract needs to say, points to the register attributes each area feeds, and names the evidence worth retaining.
| Required provision area | What the contract must state | Where it lives in the register | Evidence to retain |
|---|---|---|---|
| Service description and criticality | Complete description of services, and whether they support a critical or important function | Arrangement and function records | Signed contract, criticality assessment |
| Data locations and processing | Countries of performance and data storage, with notice before change | Location and data fields | Change notifications, current location list |
| Service levels | Measurable levels, with quantitative and qualitative targets for critical services | Service level attributes | Performance reports, breach records |
| Access and audit | Access, inspection and audit rights, unrestricted for critical services | Rights flags on the arrangement | Audit plans, reports, remediation |
| Subcontracting and exit | Subcontracting conditions, exit strategy, transition period | Subcontractor and exit fields | Subcontractor approvals, exit test results |
Treat the provision list as a standing specification. Clause libraries, playbook fallbacks and register fields should reference the same list, so a new ICT agreement starts compliant instead of joining a remediation queue. Post signature, the duties move into an obligation register for financial services where owners, due dates and evidence live together, and confirm final positions with counsel.
For related guidance, see A DORA guide to ICT third-party contract registers, OCC and FFIEC expectations for vendor contract files and Vendor contract controls for OCC and FFIEC exam readiness.
