Skip to content
DataHalt
Book a workflow review(opens in a new tab)

Financial services / ICT third-party risk

DORA ICT third-party contract requirements

Connect ICT contract terms to the service they support. Use this guide to frame the review, identify connected protections and put the remaining decision with the right owner.

By DataHaltSource-linked guide
Explore the contract topicsView official sources

Contract review

Start with the ICT contract baseline.

Article 30(1)–(2). Grouped for review, not a substitute for the full text. Open a topic for a practical question and suggested owners.

Written agreement and service scope

Article 30(1), (2)(a)

A written, accessible full contract including SLAs; clear services and applicable subcontracting conditions.

Ask in the negotiation

Do the MSA, schedules and service descriptions refer to the same scope and version?

Suggested owners
Legal · Third-Party Risk
Source: Article 30(1), (2)(a)

Service and data locations

Article 30(2)(b)

Identify service and data locations, with advance notification of intended changes.

Ask in the negotiation

Are contracted and subcontracted locations visible, including storage? Who reviews a change?

Suggested owners
Third-Party Risk · Privacy
Source: Article 30(2)(b)

Data protection and recovery

Article 30(2)(c)–(d)

Protect data; provide accessible recovery and return on provider failure or contract termination.

Ask in the negotiation

Can the operational team retrieve usable data, and do exit terms support that promise?

Suggested owners
Security · Privacy · Legal
Source: Article 30(2)(c)–(d)

Service levels and incident assistance

Article 30(2)(e)–(f)

Describe service levels; provide incident assistance free or at a pre-agreed cost.

Ask in the negotiation

Are incident support, service commitments and charges consistent across the order form and schedules?

Suggested owners
Security · Service owner
Source: Article 30(2)(e)–(f)

Authority cooperation and termination

Article 30(2)(g)–(h)

Provide supervisory cooperation, termination rights and relevant minimum notice periods.

Ask in the negotiation

Could a confidentiality clause or another schedule undermine cooperation or the agreed termination right?

Suggested owners
Legal · Third-Party Risk
Source: Article 30(2)(g)–(h)

Awareness and resilience training

Article 30(2)(i)

Set conditions for provider participation in security-awareness and resilience training.

Ask in the negotiation

Is participation workable for the service, with clear responsibilities on both sides?

Suggested owners
Security · Third-Party Risk
Source: Article 30(2)(i)

Additional requirements

Add the critical-or-important-function requirements.

Article 30(3) supplements the baseline; it does not replace it. Use the financial entity’s assessment of the supported function—not whether a provider is designated critical under the separate oversight framework.

Performance targets and reporting

Article 30(3)(a)–(b)

Measurable service targets; notice and reporting of materially relevant developments.

Ask in the negotiation

Would the customer learn about deterioration early enough to intervene?

Suggested owners
Service owner · Third-Party Risk
Source: Article 30(3)(a)–(b)

Continuity, security and testing

Article 30(3)(c)–(d)

Tested contingency plans, security measures and cooperation with applicable threat-led penetration testing.

Ask in the negotiation

Which evidence supports the commitments, and what happens if it becomes stale?

Suggested owners
Security · Operational resilience
Source: Article 30(3)(c)–(d)

Access, inspection and audit

Article 30(3)(e)

Effective access, inspection, audit and cooperation rights, with specified scope, procedures and frequency.

Ask in the negotiation

Do report-only language, notice restrictions or other documents impede the rights the entity needs?

Suggested owners
Legal · Security · Third-Party Risk
Source: Article 30(3)(e)

Exit and transition

Article 30(3)(f)

An adequate mandatory transition period supporting continued service and migration or insourcing.

Ask in the negotiation

Do transition support, data return, charges and the exit plan work together?

Suggested owners
Legal · Operational resilience · Service owner
Source: Article 30(3)(f)

Look beyond one clause

Review the connected conditions.

  • Subcontracting needs its own review

    The subcontracting technical standard adds assessment, contractual and change-management detail for services supporting critical or important functions. Map the chain and proposed changes; do not treat a generic permission to subcontract as the whole review.

    Delegated Regulation (EU) 2025/532

  • Contract terms are one part of the work

    Third-party-risk assessment, due diligence, the register of information and exit planning sit alongside the terms. Keep their owners and records connected to the negotiation.

    Articles 28–29

From the terms to the next action

What changes the decision?

This example shows a customer-configured authority boundary, not a legal conclusion about a particular agreement.

Illustrative customer policy · No live action

The vendor narrows audit access.

Requested action
Progress a counterproposal for an ICT service that the customer has assessed as supporting a critical or important function.
Policy condition
The customer’s approved policy prohibits the proposed report-only audit fallback for this scope. A current assurance report does not satisfy that policy condition.
BLOCK / Next permitted step
Require an acceptable audit position and re-evaluate the package. An internal approval cannot waive a legal requirement.

DataHalt’s role

Make the authority operational.

Your team determines applicability and approves the policy. DataHalt connects that policy to the proposed vendor response, its evidence and the people who must decide.

Start with one vendor workflow. Agree the supplier facts, approved policy and evidence your teams need, then validate the decisions before live use.

  1. Prepare the decision

    Identify changed positions and assemble the connected agreement, third-party-risk context and evidence.

  2. Evaluate the complete package

    Check current policy, required evidence, package dependencies and functional decision rights. Route exceptions to their responsible owners.

  3. Recheck before progression

    Live vendor responses require human approval and a fresh check of current authority, exact content and destination. A permit or wording approval alone is not permission to send.

Explore the execution boundaryInspect the decision record

Sources and scope.

Official sources reviewed on 5 October 2026. Use the current legislation and applicable guidance when setting policy; this is a focused contracting overview, not an exhaustive regulatory checklist.

  1. DORA — Regulation (EU) 2022/2554

    Articles 2, 28–30 and 64: scope, third-party risk, contract provisions and application date.

  2. ICT subcontracting — Delegated Regulation (EU) 2025/532

    Further detail on subcontracting services supporting critical or important functions.

This guide is general operational information, not legal advice or compliance certification. The customer retains responsibility for legal interpretation, risk classification and signing authority. DataHalt evaluates configured authority for supported actions; it does not replace the customer’s compliance programme or contract-lifecycle system.

Keep the context connected

Financial-services workflow

Connect the arrangement context to a scoped vendor negotiation.

Contract negotiation authority

See how policy and connected terms shape the next permitted action.

UK GDPR processor guide

Review the processor obligations alongside the ICT terms.

All contract guides

From requirements to the next decision

See the problem in practice.
Make the authority clear.

Explore an illustrative vendor response and the decisions it needs. No sign-up or contract upload required.

Explore a vendor decision

Deployment scope. These workflows are available for pilot validation, not presented as verified live capabilities. Confirm the enabled scope and current release evidence before live use. Examples are illustrative, not customer outcomes or permissions. Live vendor responses require human approval and a fresh check of current authority, exact content and destination. A permit or wording approval alone is not permission to send.