DORA Contract Remediation Workflow

Start with the register of information and procurement inventory, not with a blank contract template. DORA requires financial entities to maintain and update a register of information for contractual arrangements on the use of ICT services provided by ICT third-party service providers.

Create one remediation row per contractual arrangement and link it to the financial entity using the service, the signer, the direct ICT third-party provider, the supported function, the ICT service type, start and end dates, and any termination status. This lets the team identify which contracts need the additional Article 30(3) terms and which need only the baseline Article 30(2) terms.

DORA and the cited technical standards are binding. The remediation row, clause matrix, owner model, and close-out package below are practical workflow controls; they do not replace the required written contract, legal-entity assessment, or competent-authority process.

For each contract, decide whether the ICT service supports a critical or important function before selecting remediation depth. DORA defines a critical or important function by the effect of disruption, defective performance, or failed performance on financial performance, service continuity, authorisation conditions, or other financial-services-law obligations.

Where a contract supports a critical or important function, the remediation file should also cover concentration risk, subcontracting chains, audit and access rights, business continuity, exit strategy, and notification to the competent authority for planned arrangements or when a function becomes critical or important.

Use a clause matrix that separates Article 30(2) terms for every ICT service contract from the additional Article 30(3) terms for services supporting critical or important functions. Applying the enhanced list to every contract can hide a more serious error: omitting a baseline term from an ordinary ICT service arrangement.

Every ICT service contract must be in one written, downloadable, durable, and accessible document and cover the service and functions, service and data locations, data availability and protection, data access, recovery and return, service levels, incident assistance, cooperation with authorities, termination rights and notice periods, and conditions for provider participation in security-awareness and resilience training.

For contracts supporting critical or important functions, add full service levels with quantitative and qualitative targets, notice and reporting duties for developments that may materially affect delivery, tested business-contingency and ICT security commitments, participation and cooperation in TLPT where relevant, ongoing monitoring, access, inspection, and audit rights, and an exit transition period that lets the financial entity move to another provider or in-house delivery without disrupting the service.

Subcontracting review should be separate from general supplier due diligence. If an ICT third-party provider may subcontract ICT services supporting critical or important functions or material parts, the contract should say exactly which services may be subcontracted, the conditions for doing so, the provider's monitoring and reporting duties, and the financial entity's rights when subcontracting changes.

The financial entity should be able to identify subcontractors that effectively underpin the ICT service, assess the chain length and complexity, understand where subcontractors and data are located, consider concentration and transferability risks, and preserve equivalent access, inspection, and audit rights through the subcontracting chain. Reliance on the provider's subcontractor assessment does not remove the financial entity's responsibility for its own DORA obligations.

Do not close a remediation row when the contract is signed but the register and operating evidence still disagree. The close-out package should show the remediated clause set, the risk assessment result, the due-diligence and assurance basis, the subcontracting position, the exit plan, and the updated register fields. A residual-risk approval can record an unresolved issue, but it does not replace a contract term that DORA requires.

The evidence file should also show how the contract will be monitored after remediation. Delegated Regulation 2024/1773 expects documented monitoring of performance, reports, incident information, service delivery, ICT security, business continuity measures, testing, shortcomings, and updates to the risk assessment.

Close with one recorded outcome: execute the compliant amendment and update the register; keep the item open with a named owner and deadline while a non-mandatory residual risk is decided; or invoke the documented objection, termination, and exit branch when the provider will not accept a required term or an unacceptable subcontracting change. Reopen the row at renewal, material service or location change, function-criticality change, significant incident, adverse audit finding, or exit-plan failure.