DORA ICT Third-Party Risk: A Board Oversight Guide

1. Start with the service the company must keep delivering

A procurement report normally starts with vendors, annual spend and renewal dates. A useful DORA board discussion starts with a customer outcome: paying a claim, executing a payment, maintaining an investment record or giving a customer access to an account. Then work backwards through the systems, external services and people needed to deliver that outcome.

This changes the question from “Have we assessed our cloud provider?” to “What happens to this service if the identity platform, hosting region or support provider is unavailable?” The second question exposes dependencies that a supplier scorecard can miss. A low-cost authentication service may stop more activity than a large software contract.

The legal starting point is that using ICT services does not transfer the financial entity’s obligations to its supplier. DORA places ICT third-party risk within the entity’s risk-management framework. See Article 28 of Regulation (EU) 2022/2554. The interpretation and working methods in this guide are practical suggestions; they are not an exhaustive statement of every requirement applicable to every type of entity.

For a board paper, ask the executive sponsor to identify the affected business service, accountable internal owner, tolerable disruption, current exposure and decision required. Keep technical detail in supporting material. Directors need enough detail to challenge an assumption, without becoming the incident team or negotiating every contract clause themselves.

2. Do not confuse a critical function with a designated critical provider

Two assessments answer different questions. Your entity determines which functions are critical or important within the DORA framework. The European Supervisory Authorities designate critical ICT third-party service providers for the Union oversight framework. ESMA explains that this oversight complements financial entities’ own responsibilities; it does not replace them. See ESMA’s DORA oversight explanation.

Apply this distinction to a small specialist provider. It may support your only route to an important financial service without appearing on a designated-provider list. Equally, buying a minor service from a very large designated provider does not remove the need to assess its actual use. Store these two classifications separately to prevent a misleading “critical: yes/no” field from driving all subsequent decisions.

3. Make the register complete, connected and explainable

The register is not limited to the contracts supporting critical or important functions. Article 28(3) covers all contractual arrangements for ICT services provided by ICT third parties, while distinguishing the arrangements supporting those functions. Implementing Regulation (EU) 2024/2956 provides the standard templates, including additional assessment and supply-chain information relevant to critical or important functions.

A practical completeness check starts by comparing the register with procurement records, recurring payments, the application inventory and service owners’ knowledge. Differences are investigation items, not automatic evidence of a breach: an invoice may represent a non-ICT service, or several invoices may belong to one arrangement. Document the conclusion instead of silently discarding the mismatch.

Ask someone outside the register-maintenance team to follow one dependency from end to end. Can they identify the contracting entity, actual service user, provider, supported function, responsible owner and current contract? Can they distinguish an external arrangement from the related internal group arrangement? If the links cannot be explained, exporting a technically valid file has not solved the management problem.

• Assign a named owner to unresolved classification and ownership questions.
• Record the date and reason for a change, especially after acquisitions or service migrations.
• Reconcile changes when a new service is approved, not only before a submission deadline.
• Show coverage gaps and ageing to executives instead of presenting only a total supplier count.

The board does not need to approve each spreadsheet row. It needs confidence that completeness has an owner, uncertainty is visible and important dependencies receive appropriate attention.

4. Turn the third-party policy into decision gates

A policy becomes useful when it changes a decision before the organisation becomes dependent. For entities subject to the relevant policy requirements, Delegated Regulation (EU) 2024/1773 addresses the lifecycle of arrangements supporting critical or important functions. It requires management-body review of the policy at least annually and an update where necessary. Applicability and proportionality should be checked against the entity’s regulatory category.

The following gates are a suggested operating model. Before selection, the business owner describes the service and the consequences of failure. Before signature, risk, security, legal and procurement identify unresolved issues together. Before going live, operations demonstrates that monitoring, support and recovery arrangements exist. At renewal or material change, the owner reassesses whether the original assumptions still hold.

At each gate, separate three statements: evidence obtained, judgement made and exception accepted. A supplier’s assurance report is evidence. A conclusion that it adequately covers your use of the service is a judgement. Proceeding despite an unresolved gap is an exception requiring an authorised decision, conditions and an expiry date.

Do not let every problem become “accepted by the business”. Identify who has authority to accept which exposure under the organisation’s governance arrangements. Escalate dependencies whose consequences exceed that authority. The board’s most valuable contribution may be funding a missing recovery capability or rejecting a rushed launch whose resilience assumptions remain untested.

5. Challenge concentration beyond the supplier-spend chart

Concentration is about correlated failure as well as commercial dependence. Two contracts with different company names may rely on the same underlying hosting platform, connectivity provider, identity service or specialist subcontractor. Two cloud regions may still share an administration plane. These are architectural questions that a purchasing pie chart cannot answer.

DORA Article 29 addresses the assessment of ICT concentration risk. For a practical board discussion, ask management to present a small number of plausible dependency failures and show which business services fail together. Make the assumptions visible: availability of staff, access to keys, connectivity, data consistency and capacity at the proposed alternative.

Multiple suppliers can also increase complexity, operating cost and coordination risk. The practical objective is not a universal ban on concentration or a demand for duplicate infrastructure everywhere. It is an informed choice about a specific exposure, supported by credible options and a clear owner. Record why the selected mitigation is proportionate and what event would trigger reconsideration.

6. Review contract evidence against the service you actually use

A label saying “DORA addendum signed” is too coarse for effective oversight. Article 30 sets contractual requirements, with additional provisions for ICT services supporting critical or important functions. Legal advisers should map the applicable requirements to the actual arrangement. The comparison below is a practical challenge tool, not substitute contract wording.

Read assurance reports with their boundaries in view. Which period do they cover? Which service configuration was assessed? Are customer responsibilities assumed? Does the report exclude a component on which your recovery plan relies? A current certificate can be useful while leaving a specific operational question unanswered.

Keep a concise gap log linking each issue to a business consequence, compensating measure, owner and due date. Bring the board material unresolved exposures and decisions beyond delegated authority. Avoid burying a consequential gap beneath a high percentage of clauses marked complete: one missing capability can matter more than many low-impact items closed.

7. Test whether the exit plan can be executed

A contractual right to leave and an operational ability to leave are different assets. DORA’s exit provisions for services supporting critical or important functions appear in Article 28(8). In practice, a board should challenge the assumptions underneath the plan: destination, data, people, time, money and continued service.

Separate a planned migration from an emergency disruption. A six-month migration programme may be commercially realistic yet useless as the immediate response to a service outage. The recovery plan may keep the service operating while the exit plan addresses the longer-term dependency. Ask management to explain the relationship instead of presenting either document as a universal solution.

1. Choose a representative service and define the exit trigger.
2. Export a controlled sample of required data with appropriate protection.
3. Verify that the destination can read and reconcile the data, not just store a file.
4. Check access rights, licences, specialist skills and contracted transition support.
5. Measure time and identify manual work, missing dependencies and untested assumptions.
6. Update the cost, sequence, accountable owner and next test date.

This is a suggested test sequence, not a requirement to perform an uncontrolled production migration. Select safe tests appropriate to the service and document their limits. If only a small sample was tested, say so. If an alternative is not ready, report that limitation openly and show the interim risk decision. A green status should never mean merely that a document exists.

8. Use a short board pack with decisions attached

A useful oversight pack can fit around five questions: what changed, what could fail together, what assurance weakened, what options remain and what decision is needed? This is a suggested reporting structure. Frequency should reflect the organisation’s risks and governance arrangements rather than an invented universal DORA quarterly timetable.

Include the small number of dependencies with the greatest business consequences, recent changes affecting them, overdue material actions and the next relevant contract or migration decision. Explain trends. An increasing supplier count may reflect better inventory coverage rather than increased exposure. Fewer open actions may reflect genuine remediation or a change in how actions are counted.

• Link every material risk to a supported business service and accountable executive.
• Distinguish tested recovery capability from a target or supplier promise.
• Show contract exceptions, unresolved assurance gaps and their ageing.
• Identify concentration changes and assumptions that require new evidence.
• State the decision requested, alternatives considered and the consequence of deferral.

Use the DORA board reporting dashboard guide to connect these measures to broader ICT risk oversight. For a practical exercise, take one high-consequence dependency into the board incident-response tabletop. The board should recognise the same service names, risk owners and recovery assumptions across all three discussions.

9. Prepare the next discussion around one real dependency

Do not begin by asking every team to redesign every report. Select one important service and request a coherent evidence chain: function assessment, register entry, contract, assurance review, recovery test and exit plan. Ask different owners to walk through it together. Conflicting identifiers, outdated assumptions and unowned actions will quickly become visible.

Turn the findings into a short improvement plan. First resolve ownership and inventory gaps. Then address decisions that are time-sensitive because of renewal, migration or exposure. Finally improve the recurring oversight process so the same gaps do not reappear. Give each action a deliverable that can be checked, not simply an instruction to “enhance governance”.

Directors also need a shared understanding of their role. The guide to DORA board training requirements explains how to connect learning to governance responsibilities. BlueTeam Academy’s Cybersecurity Training for Executives & Boards provides an introductory starting point for leadership teams at financial entities within DORA’s scope. Its introductory course is not an assessment of the organisation’s compliance. Pair learning with your own service-specific evidence, decisions and follow-up.