For most financial entities the operational burden of the Digital Operational Resilience Act has not been the incident reporting or the testing regime. It has been the contracts. DORA converted a set of outsourcing expectations that firms had treated as policy into specific contractual contents, and then required those contents to be reported in a structured register. That combination changes what a contract repository has to be able to do.
The change is easy to underestimate. A firm can be substantively resilient, with well-managed cloud and software providers, and still be unable to produce the register because the relevant terms are buried in PDFs across three business units and two legacy systems. Supervisors read the register. They do not read the PDFs first.
This guide sets out what the contractual requirements are in practical terms, how the critical or important function designation drives the clause set, which fields the register consumes, and the sequence that gets a legacy portfolio into shape. It builds on the broader vendor risk material in third-party-risk-contract-automation-guide.html.
The contractual contents DORA expects
Article 30 distinguishes a baseline set that applies to every ICT contractual arrangement from an extended set that applies where the service supports a critical or important function. The clause families below are where most remediation effort lands.
- Service description and locations, a clear and complete description of functions and services, and the countries where services are provided and where data is processed and stored
- Data provisions, availability, authenticity, integrity and confidentiality requirements for data, including personal data, and access and recovery rights on insolvency or termination
- Incident assistance, the provider duty to assist at no additional cost, or at a cost determined in advance, when an ICT incident relates to the service supplied
- Exit and termination, termination rights, minimum notice periods for the provider, and exit strategies with transition periods that let the entity migrate without disruption
- Audit, access and subcontracting, unrestricted access, inspection and audit rights, and the conditions under which subcontracting of critical or important functions is permitted
For arrangements supporting critical or important functions the requirements extend further, adding service level descriptions with precise quantitative and qualitative performance targets, notice periods and reporting obligations, participation in the entity security awareness and training programs, and the right to monitor performance on an ongoing basis. The distinction matters operationally because the designation is not static. A service can move into scope when a business changes how it is used, and the contract must follow.
Maintaining a register of information on all ICT third-party arrangements is what makes contract data quality a supervisory matter rather than an internal one. Every field in the register traces back to something a contract either says or fails to say. Firms that treated the register as a reporting project found themselves rebuilding contract metadata under deadline. Firms that treated it as a contract data project got the report as a by-product.
Where legacy agreements most often fall short
Repapering an ICT portfolio is expensive, so the practical question is which gaps genuinely require an amendment and which can be closed with documented evidence. These five come up repeatedly.
- Subcontracting chains. Older agreements permit subcontracting with notification rather than conditions, and rarely require the provider to disclose the chain supporting a critical function. This is usually a genuine amendment.
- Exit strategy substance. A termination right is not an exit strategy. DORA expects a transition period and cooperation obligations that let the entity move the service. Many contracts have the right and none of the mechanics.
- Data location specificity. Contracts frequently name a region rather than the countries of processing and storage. The register expects specificity, and a regional statement will not populate it.
- Audit rights scope. Pooled audit arrangements and report-based assurance are workable, but the contract has to permit them expressly alongside direct access rights, including for the competent authority.
- Performance targets. Critical or important function arrangements need precise quantitative targets. Best-efforts availability language and unquantified support commitments do not meet the standard.
A five-step roadmap to a register-ready portfolio
Step 1, Establish the population
Identify every contractual arrangement for ICT services, including intragroup arrangements and low-value software subscriptions bought outside procurement. Shadow spend is the usual source of register gaps, and finding it typically requires reconciling accounts payable data against the contract repository.
Step 2, Apply the criticality designation
Map each arrangement to the business function it supports and apply the critical or important function assessment consistently. Record the rationale, because the designation drives the clause set and supervisors will ask how it was reached. Build in a re-assessment trigger when the supporting business process changes.
Step 3, Extract contract terms as fields
Run clause extraction across the population and write the results to structured fields rather than to a document summary. Data location, subcontracting conditions, notice periods, audit rights, termination triggers and service targets each need to be independently queryable to feed the register.
Step 4, Prioritize remediation by exposure
Rank gaps by criticality designation and concentration rather than by contract value. A small provider supporting a critical function with no exit mechanics is a larger problem than a large provider supporting a non-critical one. Bundle amendments by provider to limit negotiation overhead.
Step 5, Operationalize the register
Generate the register from the contract data rather than maintaining it separately. Any manually maintained parallel register will diverge from the contracts within a reporting cycle, and reconciling the two becomes a recurring cost with no compliance benefit.
See contract data feed a supervisory register
Walk through clause extraction, criticality tagging and register field generation on ICT agreements.
Why this is a data model problem, not a template problem
The instinctive response to a new contractual requirement is to update the template, and updating the template is necessary. It is also insufficient, because the template only governs what the firm signs going forward and most ICT spend is committed under agreements already in force, frequently on provider paper that the firm has limited ability to change. What determines whether the firm can answer a supervisory question is whether the terms of those existing agreements have been captured as data. That is a repository and extraction problem. It also has a longer-term payoff beyond DORA, because the same structured fields answer questions from other regimes. Data location and subprocessor terms feed data protection reporting. Audit rights and performance targets feed operational resilience testing scope. Exit mechanics and concentration feed recovery and resolution planning. Firms that built a clause data model rather than a DORA spreadsheet found the marginal cost of the next regime much lower, which is the argument for treating this as infrastructure rather than as a deadline. The alternative is a new extraction project for each new obligation, run under pressure, with the same documents parsed again by a different team.
Clause families and the register fields they feed
The mapping below shows how contract terms translate into the structured fields a register consumes, and what typically has to change in legacy paper.
| Clause family | Register field it feeds | Common legacy gap |
|---|---|---|
| Service description | Function supported, service type | Generic descriptions that cannot be mapped to a function |
| Data location | Countries of processing and storage | Region named instead of specific countries |
| Subcontracting | Chain disclosure, approval conditions | Notification only, no conditions or chain visibility |
| Termination and exit | Notice period, transition support | Termination right with no transition obligations |
| Service levels | Quantitative performance targets | Best-efforts language with no measurable target |
DORA did not invent new ideas about outsourcing risk. It made existing expectations specific and then required firms to report against them in a structured form, which exposed how much contract knowledge was sitting in prose nobody had indexed. The firms that handled it well did not start with a clause template. They started by establishing the population, capturing the terms as fields, and then remediating in priority order against the gaps the data revealed.
For related guidance, see A DORA guide to ICT third-party contract registers, OCC and FFIEC vendor oversight, the contract controls and Vendor contract controls for OCC and FFIEC exam readiness.
