Skip to content

Third-party (ICT) risk assessment, start to finish

DORA — Regulation (EU) 2022/2554, Chapter V. A complete worked example of how to assess an ICT third-party provider across its whole lifecycle, from deciding whether the function is critical through to a tested exit. It comes with a working spreadsheet and a process document you can download and adapt.

The idea that runs through all of it: assess criticality first, and let everything else scale from there. Most assessments fail because they send the same enormous questionnaire to every vendor. DORA fixes the order, and the order is the point.

Artefacts

Artefact Type Format
TPRM Assessment Toolkit Tiered assessment workbook (8 tabs, CIF-driven) .xlsx
Process document and flowchart End-to-end SOP with RACI and regulatory map .docx

Download and adapt

Both files are hosted here on the domain, no third-party requests. The workbook is pre-wired so the CIF decision drives the assessment tier, which drives how deep the due diligence goes and which Article 30 clauses apply. Fill in the blue cells.

The process at a glance

The DORA third-party assessment lifecycle A sourcing need enters the process. Step one asks whether the function is critical or important, which sets the depth of everything after it. Step two sizes business impact, step three scores inherent risk into a tier, step four runs due diligence. Where the remaining gaps are not acceptable, the vendor is remediated, given added controls or declined, and the due diligence is re-run. Otherwise step five puts the risk into the contract, step six records the arrangement in the register of information, and step seven monitors it. Periodic review loops back to the business impact step, and the process ends with a tested exit. Sourcing need — new or changed 1 Critical or important? Art. 3(22). Decide this first — it sets the depth of every step that follows. 2 Business impact RTO, RPO and impact tolerance. These become your service levels. 3 Inherent risk Weighted domains scored before controls, giving an assessment tier. 4 Due diligence Depth by tier. Evidence per RTS 2024/1773 Art. 6, with every open gap logged. 5 Contracting Art. 30(2) baseline for all; 30(3) enhanced where the function is critical. 6 Register it Art. 28(3), on the ITS 2024/2956 template. Reportable to the NCA. 7 Monitor SLAs, KRIs, concentration and fourth parties. It does not stop at signature. Exit, and prove it works Tested exit plan, data return or deletion, transition. RTS 2024/1773 Art. 10. gaps not acceptable — remediate or decline periodic review, cadence by tier The DORA third-party assessment lifecycle A sourcing need enters the process. Step one asks whether the function is critical or important, which sets the depth of everything after it. Step two sizes business impact, step three scores inherent risk into a tier, step four runs due diligence. Where the remaining gaps are not acceptable, the vendor is remediated, given added controls or declined, and the due diligence is re-run. Otherwise step five puts the risk into the contract, step six records the arrangement in the register of information, and step seven monitors it. Periodic review loops back to the business impact step, and the process ends with a tested exit. Sourcing need — new or changed 1 Critical or important? Art. 3(22). Decide this first — it sets the depth of every step that follows. 2 Business impact RTO, RPO and impact tolerance. These become your service levels. 3 Inherent risk Weighted domains scored before controls, giving an assessment tier. 4 Due diligence Depth by tier. Evidence per RTS 2024/1773 Art. 6, with every open gap logged. gaps not acceptable, re-assess 5 Contracting Art. 30(2) baseline for all; 30(3) enhanced where the function is critical. 6 Register it Art. 28(3), on the ITS 2024/2956 template. Reportable to the NCA. 7 Monitor SLAs, KRIs, concentration and fourth parties. It does not stop at signature. periodic review, by tier Exit, and prove it works Tested exit plan, data return or deletion, transition. RTS 2024/1773 Art. 10.

The seven steps

1. Start with the function, not the vendor. Ask one question first: does this service support a critical or important function? A CIF is a function whose failure would materially harm the firm's financial performance, the continuity of its services, or its ability to meet regulatory obligations. This single decision sets how deep everything else needs to go, and whether the enhanced Article 30(3) regime applies.

2. Size the impact. For a critical function, set the recovery time objective, the recovery point objective and the impact tolerance. How long can it be down, how much data can you lose, where is the line the business cannot cross. These numbers become your service levels, so define them before you negotiate.

3. Score inherent risk, then tier. Rate data sensitivity, access, substitutability, concentration, jurisdiction, sub-outsourcing, financial health and regulatory exposure, before any controls. The weighted score plus the CIF flag gives you a tier, and the tier tells you how much due diligence is proportionate.

4. Do due diligence at the right depth. Use real evidence. RTS 2024/1773 Article 6 lists what you can rely on: your own audits, independent audit reports, the vendor's internal audit, appropriate certifications such as ISO 27001 or SOC 2, and other reliable information. Record what you saw and every gap that is still open.

5. Write the risk into the contract. Article 30(2) sets the baseline for every ICT contract. Article 30(3) adds the enhanced set for critical functions: quantitative service levels, tested contingency plans, threat-led testing cooperation, unrestricted audit and access rights for you and the regulator, and an exit strategy. The clause-by-clause checklist is in the Articles 28 to 30 post.

6. Register it. Every arrangement goes in the register of information (Article 28(3)), kept current and reportable to the competent authority on request. The template set is ITS 2024/2956. More in the register of information post.

7. Monitor, and keep a tested exit. The assessment does not end at signature. Watch performance, concentration and fourth parties, and test the exit plan before you need it. RTS 2024/1773 Article 10 requires a documented, tested exit plan for each critical arrangement.

Key definitions (DORA Article 3)

The terms below are used throughout this page. They are quoted verbatim from Article 3 of DORA, with the definition number in brackets.

Term Definition (Article 3)
Critical or important function (22) "a function, the disruption of which would materially impair the financial performance of a financial entity, or the soundness or continuity of its services and activities, or the discontinued, defective or failed performance of that function would materially impair the continuing compliance of a financial entity with the conditions and obligations of its authorisation, or with its other obligations under applicable financial services law"
ICT services (21) "digital and data services provided through ICT systems to one or more internal or external users on an ongoing basis, including hardware as a service and hardware services which includes the provision of technical support via software or firmware updates by the hardware provider, excluding traditional analogue telephone services"
ICT third-party service provider (19) "an undertaking providing ICT services"
ICT third-party risk (18) "an ICT risk that may arise for a financial entity in relation to its use of ICT services provided by ICT third-party service providers or by subcontractors of the latter, including through outsourcing arrangements"
Critical ICT third-party service provider (23) "an ICT third-party service provider designated as critical in accordance with Article 31"
ICT concentration risk (29) "an exposure to individual or multiple related critical ICT third-party service providers creating a degree of dependency on such providers so that the unavailability, failure or other type of shortfall of such provider may potentially endanger the ability of a financial entity to deliver critical or important functions, or cause it to suffer other types of adverse effects, including large losses, or endanger the financial stability of the Union as a whole"

On the word \"material\"

DORA does not define "material" or "materiality" as a standalone term in Article 3. The materiality threshold lives inside the critical or important function test itself: the disruption must materially impair financial performance, the soundness or continuity of services, or continuing compliance. In practice you set that threshold through your business impact analysis and impact tolerances (step 2), which is why criticality is assessed first.

A note on scope: DORA and the EBA guidelines

DORA is now the lead regime for ICT third-party risk. The older EBA guidelines on outsourcing (EBA/GL/2019/02) are being narrowed to cover non-ICT arrangements, so the two will sit side by side rather than overlap. If your service is ICT, work to DORA. Treat the EBA position as still moving and verify its current status before you rely on it.

Verify before you rely on it

This is a practitioner template, not legal advice. Article and standard references are drawn from the primary texts but should be checked against the current version on EUR-Lex before operational use. The first designations of critical ICT third-party providers were expected from 2025; confirm the current list against the ESAs directly.

Primary sources

More official texts are in the DORA resource library.