DORA ICT third-party risk contracts

What DORA requires for ICT third-party risk and contracts

Under DORA Article 28(1), a financial entity stays fully responsible for compliance whatever it outsources, so an ICT service contract never transfers the obligation to the provider. Before renewing or signing, the entity must run a documented ICT third-party risk strategy and policy, a pre-contract assessment, contract clauses that meet Article 30, and exit plans that have been tested. The effort varies with how many of your ICT services support critical or important functions, because that classification adds the stricter Article 30(3) terms, subcontracting controls and exit requirements. No auditor certifies DORA compliance, so the entity owns the evidence: the policy, the assessments, the signed contracts and the test records must be ready for a competent authority to inspect.

Start by listing every ICT service contract and marking which ones support a critical or important function. Delegated Regulation (EU) 2024/1773 requires the policy to name the assurance used for each provider, such as your own audits, independent audit reports, the provider's internal audit reports or appropriate certifications, and to be reviewed by the management body at least once a year. The pre-contract assessment under Article 29 asks harder questions: whether the service can be substituted, whether several of your functions depend on the same or connected providers, how deep the subcontracting chain runs, which third-country laws apply to the data, and whether insolvency law would affect data recovery. Confirm these answers in writing before the contract is signed, not after.

Contract clauses are where many gaps appear. Article 30(2) lists terms every ICT services contract must contain, and Article 30(3) adds precise service level targets, participation in threat-led penetration testing, unrestricted access and audit rights for your entity and the competent authority, and an exit strategy with a mandatory transition period. Delegated Regulation (EU) 2025/532 requires you to decide before contracting whether critical services may be subcontracted, to obtain equivalent access and audit rights from subcontractors, and to hold a right to object to material changes and terminate if they proceed anyway. Ask legal and procurement to map each clause against the articles, and keep the exit plan tested, because Article 28(8) requires it to be documented and tested for critical or important services. Costs for this work fall mainly on internal legal, procurement and risk staff, and recur whenever contracts renew or subcontractors change.

What must happen before a DORA ICT contract is signed

The pre-contract sequence under Articles 28 and 29 of DORA gives the financial entity a documented decision on whether the provider is acceptable, what risks it carries and what the contract must contain before any ICT service is bought. Each step leaves a record that the entity's management body and supervisors can review.

Decide whether the service supports a critical or important function
The business owner and the ICT risk function map the service to the business functions it supports and decide whether any of them are critical or important. This decision drives how much of the later work applies, including the mandatory contract terms for critical or important functions and the exit planning. The output is a classification record for the service, approved by the person accountable for that function, that states the reasons for the decision. Confirm the entity's internal definitions against the wording of the Regulation before the record is final.
Check supervisory conditions and regulatory constraints
Compliance and legal teams check whether the supervisor imposes any conditions on the use of the service, such as prior notification or specific restrictions on outsourcing the activity. They also confirm that the planned arrangement fits the entity's licence and sector rules. The output is a short note of applicable conditions and the actions needed to meet them, filed with the assessment record. Where the answer is unclear, the entity should ask its competent authority before proceeding.
Assess concentration and substitutability risk
The ICT risk function assesses whether the provider would be difficult to replace, and whether the entity already depends on the same provider or on providers that rely on the same underlying infrastructure. It also reviews the subcontracting chain behind the service. The output is a risk assessment that records the substitution options, the existing dependencies, and the residual concentration risk accepted by management. Ask the provider for a complete list of material subcontractors and their locations as part of this step.
Assess third-country law, data location and insolvency exposure
Legal and data protection staff review the law that applies to the provider and to any location where data is stored or processed, including the data protection implications. They also assess whether the provider's insolvency law could delay or prevent the recovery of the entity's data. The output is a written legal and data assessment that identifies the locations involved, the risks found and the contract or technical measures needed to address them. Self-hosted open-source deployments inside the entity's own infrastructure change parts of this analysis, so the assessment should describe exactly who operates the platform and where it runs.
Complete due diligence and identify conflicts of interest
The procurement and third-party risk teams gather information on the provider's financial position, technical capability, security practices, governance and any relationships that could compromise impartial decisions, including intra-group ties. They also record any conflicts of interest and how they will be managed. The output is a due diligence file with the sources used and a conflict of interest statement signed by the approving manager. Ask for evidence rather than accepting general statements, and record what was not provided.
Confirm appropriate information security standards and assurance
The security function checks that the provider meets information security standards appropriate to the sensitivity and criticality of the service, and records which assurance sources the entity relies on. Under the policy, these can include the entity's own audits, independent audit reports, the provider's internal audit reports and appropriate third-party certifications, with more than one source used where appropriate. The output is an assurance record that names each source, its date and scope, and any gaps that need contractual or operational remediation. Certifications and reports must be checked for scope, not only for existence.
Approve the decision and register the arrangement
The accountable manager and, where the policy requires it, the management body approve the contract on the basis of the completed assessments, with any residual risks formally accepted. The entity then records the arrangement in its register of information so that the contract and its data are captured before signature. The output is an approval record and a register entry that match the assessment file. Treat this as a gate: if an earlier step is incomplete, the contract should not be signed.

Who is paid for what when a DORA contract is reviewed and remediated

This table lists each cost component of reviewing and remediating existing ICT contracts against DORA Articles 28 to 30, who is usually paid for it, whether it is one-time or recurring, and what to request in a written quote. Use it to separate internal effort from outside spend before asking for proposals. The main takeaway is that most of the cost sits in contract negotiation and evidence upkeep, not in the tools themselves.

Cost component	Who is paid	One-time or recurring	What drives it and what to request in a quote
Internal legal and procurement time	Your own legal and procurement staff	One-time for initial contract review, recurring for renewals and new ICT agreements	Number of ICT contracts and whether they support critical or important functions. Ask the partner or counsel to state the contract count and clause gaps assumed.
Internal risk and security staff	Your own risk, security and business continuity staff	One-time for the first gap mapping, recurring for the annual policy review and exit plan testing	Number of providers in scope and depth of due diligence. Confirm which tasks are internal and which are priced externally.
Provider contract changes	The ICT provider, often at its own cost, sometimes through a paid addendum	One-time for amendments, recurring if the provider charges for audit access or reporting	Negotiating leverage, standard terms offered and whether the provider requires a fee for Article 30 clauses. Ask providers in writing what they will and will not change.
Outside legal counsel	External law firm	One-time for template clauses and remediation of key contracts, recurring for new services and regulatory updates	Volume of non-standard contracts and jurisdictions involved, including third-country law under Article 29. Request a fixed fee per contract type or a capped estimate.
Implementation partner for register data and evidence packs	Implementation partner under a written scope	One-time for the initial register population, recurring for annual updates and evidence refreshes	Number of register fields to populate, data quality issues in existing records and frequency of updates. Ask for the deliverables list, data sources and the update cycle in the quote.
Tooling and records	Software vendor or your own platform team	One-time for setup and data migration, recurring for licences, hosting and maintenance	Whether the contract repository, register and exit plan records sit in existing systems. Ask for licence terms, hosting location and who maintains the records after handover.
Audit and assurance reviews of providers	Your internal audit team or an independent auditor you engage	Recurring, tied to the assurance cycle set in your third-party policy	Reliance on provider reports versus your own audits, and the number of critical or important providers. Confirm which assurance sources the policy accepts, as Delegated Regulation (EU) 2024/1773 requires the policy to specify them.

Which contract clauses every ICT agreement needs, and which apply to critical functions

DORA sets two layers of contract terms for ICT services: a baseline that every ICT services contract must contain, and a heavier set that applies when the service supports a critical or important function. The cards below separate the two layers so procurement and legal teams can map each clause to a contract, a schedule or a supporting document.

Baseline service and location terms

Article 30(2) requires every ICT services contract to describe the services in full, and to state where the services are provided and where data is processed and stored. Location terms matter because they feed the third-country law and data protection checks that Article 29 requires before contracting. Check that the service description is specific enough to test against, and that any change of location triggers a notice duty.

Data protection and return on exit

Every ICT contract must set out how data is protected and how it is returned to the financial entity when the contract ends. Ask the provider to confirm in writing the format and timing of data return, and whether deletion certificates are issued. Test the return process before a real exit is needed, because it is often the step that fails in practice.

Incident assistance and cost terms

The contract must require the provider to assist the entity when an ICT incident occurs, either at no cost or at a pre-agreed cost. Write down who pays for assistance, the response expectations, and the named contacts. Without this clause, a provider can delay help during a major incident while cost arguments continue, which weakens the entity's own reporting timelines.

Cooperation, termination and awareness training

Article 30(2) requires cooperation with competent authorities, termination rights, and the provider's participation in the entity's ICT security awareness programmes. Termination rights should be listed as specific triggers, not general language. Confirm that the provider's staff who access the entity's systems will attend the entity's training, and record that commitment in the contract.

Critical function service levels and reporting

For services that support critical or important functions, Article 30(3) adds precise service level targets, notice duties, reporting duties and business contingency plans. Targets should be measurable and tied to remedies. Ask for a defined reporting cadence and a notice period for material changes. Confirm the provider's continuity arrangements are tested and compatible with the entity's own continuity plans.

Audit, access and exit transition

Critical function contracts must grant unrestricted access, inspection and audit rights to the entity and its competent authority, and must include participation in threat-led penetration testing. They also require an exit strategy with a mandatory transition period. Confirm the transition period length with counsel and the provider, and check that exit plans are documented and tested under Article 28(8). Also consider Article 30(4), which asks parties to consider standard contractual clauses developed by public authorities for specific services. Confirm the current text of all clauses with counsel before signing.

How subcontracting and audit rights work in practice

Under Delegated Regulation (EU) 2025/532, the subcontracting decision is made before the contract is signed, not after the provider proposes a change. For any ICT service that supports a critical or important function, the entity must decide whether that service may be subcontracted at all and, if so, under what conditions. The practical test is to map the provider's dependencies in the pre-contract assessment: which parts of the service a subcontractor would run, where those subcontractors are located, and whether the entity could still meet its own resilience obligations if one of them failed. Record that decision in the policy on ICT services and in the register of information, so the position can be shown to a supervisor without reconstructing it from email. The contract then has to carry the terms that make the decision enforceable. The entity should require that subcontractors give it the same access and audit rights the provider gives, not a weaker version passed down through the provider. The contract should also set a notice period for material subcontracting changes, a right to approve or object within that period, and a termination right if the provider makes the change anyway. Competent authorities hold their own access, inspection and audit rights under Article 30(3), and those rights should reach the subcontracting chain as well. Ask the provider to confirm in writing which subcontractors would be covered by these terms, and check that the clauses name them or describe them precisely enough to apply. When supervision begins, the entity must be able to show that these terms exist and work. Keep the executed contract clauses, the subcontracting decision record, the notices received from the provider and the entity's responses, and evidence of any audit or access exercised on a subcontractor. Test the mechanism at least once by asking for a subcontractor change and recording how long the notice took and what the entity decided. If the provider cannot produce subcontractor lists or accept audit access on request, treat that as a finding to escalate before a supervisor finds it. Confirm the notice periods and approval mechanics with your legal team, since the exact drafting depends on your contract and the regulation's wording.

When a DORA contract can be terminated and how to test the exit

Article 28(7) of DORA requires that contracts with ICT third-party service providers can be terminated in defined circumstances. The Regulation does not leave termination to general contract law. The entity must be able to end the agreement when specific conditions arise, so the right has to be written into the contract before the service starts. Four situations are named, and each needs its own clause.

Significant breach: the provider materially breaches applicable laws, regulations or contractual terms. The contract should define what counts as significant and who decides.
Circumstances altering performance: events that change how the provider can deliver the service, such as a change of control, a material change to its subcontracting or a change that affects its ability to perform.
Evidenced ICT risk management weaknesses: weaknesses in how the provider manages ICT risk, shown by evidence such as audit findings, incident records or assessment results rather than by suspicion alone.
Supervision becoming impossible: a situation in which the competent authority can no longer effectively supervise the entity through the provider, for example because of the provider's location or legal constraints.

Check that each trigger is drafted as a termination right, not only as a remedy, and that notice periods and transition arrangements are stated. Ask counsel to confirm how each trigger maps to the provider's contract template.

How the register of information links every contract to supervision

Article 28(3) of DORA requires a financial entity to keep a register of information covering all of its ICT service contracts, not only the ones tied to critical or important functions. The register is maintained in the templates of Implementing Regulation (EU) 2024/2956, which set out 15 templates, and the entity reports it each year through its competent authority to the European Supervisory Authorities. For the contract owner, this means every ICT agreement signed, renewed or ended must appear in the register in the form the templates require. For the register owner, it means the register is only as accurate as the contract files behind it.

The practical risk is drift between two records that describe the same relationship. The contract names the legal entity, the service description, the service and data locations and any subcontractors. The register has to repeat those facts using the identifiers and fields the templates define. If a provider is renamed, a subcontracting chain changes, or a data location moves, and only one record is updated, the supervisor receives a register that disagrees with the signed contract. Before the next reporting cycle, ask procurement, legal and the ICT risk owner to agree one shared record per contract, with a named owner for each field, and a check that compares contract clauses against register entries before submission.

Confirm three things with your competent authority before you build that record: which register templates and submission format it expects, how it wants provider identifiers and legal entity codes presented, and how it wants subcontracting chains represented where a critical service depends on several layers of providers. Then confirm that your contract repository can export the fields the templates need. Where a contract has no clear owner or its data sits only in a procurement inbox, treat that gap as a finding to close before the first annual submission, not after it.

What to have in place before a DORA third-party review

A supervisor or internal auditor reviewing ICT third-party risk will start by asking for documents and then test whether they match what happens in practice. The six items below connect the inventory, the criticality decisions, the policy, the contracts, the provider evidence and the exit plans, so each one should be checked against the others.

Current ICT services inventory

Keep a complete list of every contract for ICT services, including those with intra-group providers, cloud platforms and open-source software you host yourself under a support agreement. Map each service to the business functions it supports, so a reviewer can see which services sit under critical or important functions. Check that the inventory matches accounts payable records and procurement logs, because services bought outside the process are the most common gap. The same inventory feeds the register of information, so identifiers must agree in both places.

Documented criticality decision per service

For each service, record whether it supports a critical or important function, who made the decision, the date and the reasons. Reviewers test this by picking a service with a high business impact and asking how the decision was reached. Reassess the decision when the service scope, the function or the provider changes, not only at contract renewal. Include the concentration and substitutability considerations that Article 29 requires, so the decision explains the risk and not only the label.

Third-party policy approved by the management body

The ICT third-party strategy and the policy on services supporting critical or important functions need management body approval and a documented review at least once a year. Check the approval record, the date of the last review and whether the policy names the assurance sources the entity accepts for each provider. Confirm that the policy content follows Delegated Regulation (EU) 2024/1773, not just that a document with the right title exists.

Contract clause checklist

Build a checklist from Article 30 and mark, for every contract, which mandatory clauses are present and where they sit. Services supporting critical or important functions need the additional clauses, including service level targets, business continuity plans, participation in threat-led testing and audit and access rights for the competent authority. Check the signed versions, not the negotiated drafts, and confirm that subcontracting terms and termination rights are in the same document set.

Assurance evidence for each provider

For each provider, hold the assurance the policy says you rely on, such as your own audit results, an independent audit report, the provider's internal audit report or a recognized certification. Note the scope and period each report covers, since a report that excludes the service you buy does not evidence it. Reviewers will ask when the evidence was last checked and what you did about any exceptions or open findings. Confirm with the provider which evidence it will share before you rely on it.

Tested exit plan

Each service supporting a critical or important function needs a documented exit plan that is tested, not just written. Check that the plan names the steps to move data and processes, the alternative providers or internal options and the owners responsible. Ask when the plan was last tested and what the test showed. Confirm that the contract contains a transition period long enough to make the plan workable, because the exit plan is only as good as the terms that allow it to run.

Questions buyers ask about DORA third-party contracts

Can we remediate our ICT contracts for DORA without outside help?

Yes, in principle. The financial entity owns its third-party risk framework, its contracts and its decisions, and nothing in DORA requires an outside firm. What usually makes the work heavy is volume and coordination: every ICT service contract has to be inventoried, classified against critical or important functions, checked for the mandatory clauses in Article 30 and tied to a register of information. Many teams keep ownership in-house and bring in help for specific pieces, such as a gap review, a clause comparison or exit plan testing. Confirm internally whether procurement, legal and security have the capacity to finish a written plan on your own timetable.

What does DORA contract remediation need from procurement, legal and IT?

Each function carries a distinct part of the work:

Procurement maintains the supplier inventory, the contract dates and the notice periods that drive renegotiation.
Legal reviews the mandatory clauses in Article 30, the termination rights in Article 28(7), subcontracting terms and data location commitments.
IT and security identify which services support critical or important functions, document technical dependencies, confirm service levels and test exit plans under Article 28(8).

Risk or compliance should own the overall plan, the assurance decisions and the link to the register of information. Agree these responsibilities in writing before work starts, because gaps usually appear where no one owns the handoff.

Can an auditor certify our ICT contracts as DORA compliant?

No. DORA sets no certification scheme, so no auditor or certification body can issue a DORA certificate for contracts or for the entity. Competent authorities supervise compliance using their powers under Article 50, and they will review your contracts, registers and decisions directly. The only attestation the Regulation provides for is the one confirming that a threat-led penetration test met its requirements under Article 26(7). An independent auditor can still test controls or review assurance reports as an input to your own assessment, but the conclusion on compliance remains with the entity and its supervisor.

How long does DORA contract remediation take?

It depends on the scope: the number of ICT contracts, how many support critical or important functions, how many already contain the required clauses and how much renegotiation the providers will accept. Timing also depends on contract renewal dates and notice periods, which can set the pace more than internal effort does. The practical approach is to inventory first, prioritize critical or important functions, then agree a dated plan in writing with owners and milestones. Ask any outside party to set its timeline against that written scope and to state which assumptions it depends on, such as provider response times.

What drives the cost of DORA ICT third-party contract work?

The main cost drivers are the number of ICT contracts in scope, the share that support critical or important functions, the number of providers that must agree to new clauses, and the depth of subcontracting chains that need mapping. Costs also rise when the entity lacks an up-to-date inventory or when exit plans must be designed and tested for the first time. Internal staff time is a recurring cost, since reviews, assurance checks and register updates must repeat each year. When you request a quote, ask for the scope by contract, the deliverables, who performs each task, what is one-time and what recurs, and which activities depend on provider cooperation.

Is an ICT provider's SOC 2 or ISO 27001 report enough for DORA?

No. A SOC 2 or ISO 27001 report is one assurance input the entity can use under its policy, and Delegated Regulation (EU) 2024/1773 expects the policy to specify which assurance is used and to combine more than one source where appropriate. Other inputs include the entity's own audits, the provider's internal audit reports and relevant third-party certifications. A report covers the provider's controls at a point or period and against its own scope, so it does not establish the contract clauses, subcontracting conditions, data location commitments or exit arrangements that DORA requires. Check the report's scope, period and carve-outs before relying on it, and document the reasoning in your assessment.

Which DORA contract clauses are hardest to get from providers?

Providers often resist the clauses that give the entity and its competent authority the most control, including unrestricted access, inspection and audit rights, participation in threat-led penetration testing, and subcontracting approval or termination rights. Exit strategies with a mandatory transition period and precise service level targets for critical or important functions are also frequent points of negotiation. Standard contractual clauses published by public authorities for specific services can help, since Article 30(4) asks parties to consider them. Start negotiations early, prioritize the clauses that cannot be waived, and record any provider refusal together with the risk decision that follows.

How DeployOpen works on this

DeployOpen works on DORA third-party evidence as an implementation partner: we prepare the systems, contract records and exit documentation that a financial entity needs, inside the client's own infrastructure. The organization owns its third-party risk decisions and contracts, and only an independent auditor or supervisor assesses them.

How we scope

We agree a written scope listing which self-hosted platforms, ICT services and providers are covered before work starts.
We map which services support critical or important functions, so evidence effort goes where supervisors will look first.
Engagements are fixed-scope, with deliverables and timelines confirmed in writing, and a quote follows from that scope.

How we build

We draft the register of information entries and supporting inventory for in-scope services, mapped to the client's own data.
We set up due diligence records, assurance evidence and monitoring checkpoints the client's policy can point to.
We test exit plans for self-hosted platforms, including data return, migration steps and recorded test results.

How we hand over

We deliver documented contract clause checklists, mapped to the client's agreements, for legal and procurement review.
We hand over runbooks, configuration records and exit test reports that the client's own staff can maintain.
We confirm with the client's auditor or supervisor which evidence formats they expect before final delivery.

How we support

Ongoing support, upgrades and periodic exit plan retests are available as a retainer after the initial engagement.
We update register entries and evidence packs when a provider, subcontractor or platform version changes.
Security testing of ICT services and providers can run alongside the programme, with findings tracked to closure.

DORA ICT third-party risk and contracts