---
name: "DORA ICT Provider Evidence Checklist"
version: "1.0"
updated: "2026-07-03"
source: "https://www.orbiqhq.com/templates/dora-ict-provider-evidence-checklist"
license: "Free to use and adapt within your organisation. Attribution appreciated. Not legal advice."
legal_basis:
  - "https://eur-lex.europa.eu/eli/reg/2022/2554/oj"          # DORA — Regulation (EU) 2022/2554 (Arts. 28, 29, 30)
  - "https://eur-lex.europa.eu/eli/reg_impl/2024/2956/oj"     # ITS — Register of Information standard templates
  - "https://eur-lex.europa.eu/eli/reg_del/2025/532/oj"       # RTS — subcontracting of ICT services supporting CIFs
---

# DORA ICT Provider Evidence Checklist (machine-readable template)

Purpose: build and maintain a DORA-aligned ICT third-party provider register, criticality
assessment, evidence collection plan, subcontracting-chain disclosure, and exit-strategy
tracker. Field names align with the structure of the ESAs' Register of Information (RoI)
templates under Commission Implementing Regulation (EU) 2024/2956 so collected data maps
onto the official reporting package. This file is self-contained: an agent can construct
a complete provider register from the definitions below.

Scope note: DORA applies to EU financial entities (applied since 2025-01-17) and, via the
EEA Agreement and the Norwegian DORA Act (in force 2025-07-01), to Norwegian entities
supervised by Finanstilsynet. Register submission windows are set by national competent
authorities (NCAs) — there is no single universal EU deadline for firms.

---

## 1. ICT Provider Register — field list

One record per contractual arrangement on the use of ICT services (DORA Art. 28(3):
ALL arrangements, not only critical ones).

| # | Field | Type | Definition / rule | RoI / DORA anchor |
|---|---|---|---|---|
| 1 | `provider_legal_name` | text | Registered legal name of the ICT third-party service provider | ITS provider identification (B_05) |
| 2 | `provider_lei` | text (LEI-20) | Legal Entity Identifier; if none, record alternative ID and `no_lei_reason` | ITS provider identification |
| 3 | `provider_country` | ISO 3166-1 alpha-2 | Country of establishment | ITS provider identification |
| 4 | `provider_parent` | text | Ultimate parent undertaking; flag `intra_group = true/false` | ITS provider identification |
| 5 | `ctpp_designated` | enum: `yes` / `no` | Whether the provider is on the ESAs' designated critical ICT third-party provider (CTPP) list | ESAs CTPP designations (first list 2025-11-18) |
| 6 | `contract_ref` | text | Unique contractual arrangement reference number (primary relational key) | ITS contractual arrangements (B_02) |
| 7 | `contract_type` | enum: `standalone` / `master_agreement` / `intra_group` / `subscription` | Nature of the contractual arrangement | ITS contractual arrangements |
| 8 | `ict_service_type` | enum (ESA taxonomy), e.g.: `cloud_iaas` / `cloud_paas` / `cloud_saas` / `data_analysis` / `software_licensing` / `network_infrastructure` / `ict_security_services` / `payment_services_tech` / `other` | Classify per the ESA service taxonomy annexed to the ITS | ITS ICT services (B_04) |
| 9 | `service_description` | text | Complete description of the ICT service provided | Art. 30(2)(a) |
| 10 | `supports_cif` | enum: `yes` / `no` / `under_assessment` | Whether the service supports a critical or important function — the pivotal DORA classification | Art. 28(2); Art. 3(22) |
| 11 | `function_supported` | text + `function_id` | Business function(s) supported by the service | ITS functions (B_06) |
| 12 | `data_locations_storage` | list of ISO country codes | Countries where data is stored | Art. 30(2)(b) |
| 13 | `data_locations_processing` | list of ISO country codes | Countries where data is processed / service managed from | Art. 30(2)(b) |
| 14 | `contract_start` | date (ISO 8601) | Start date | ITS contract fields |
| 15 | `contract_end` | date or `indefinite` | End date | ITS contract fields |
| 16 | `notice_period_provider` | duration (months) | Provider's termination notice period | Art. 30(3)(b) |
| 17 | `notice_period_entity` | duration (months) | Entity's termination notice period | ITS contract fields |
| 18 | `governing_law` | text | Governing law and jurisdiction of the contract | ITS contract fields |
| 19 | `annual_cost_eur` | number | Annual expense / estimated cost in EUR | ITS contract fields |
| 20 | `audit_rights` | enum: `full` / `pooled` / `certificates_only` / `none` | Access, inspection and audit rights granted (must be `full` for CIF services) | Art. 30(3)(e) |
| 21 | `incident_notification_sla` | duration (hours) | Contractual deadline for the provider to notify the entity of incidents | Art. 30(2)(f) |
| 22 | `exit_clause_present` | boolean | Contract contains exit strategy + mandatory adequate transition period | Art. 30(3)(f) |
| 23 | `criticality_tier` | enum: `tier_1_cif` / `tier_2_standard` / `tier_3_low` | Output of the criticality rubric (section 2) | Operational (see rubric) |
| 24 | `last_reviewed` | date | Last register-record review date | Art. 28(3) "maintain and update" |

Register maintenance rules:
- Maintain at entity level and, where applicable, sub-consolidated and consolidated levels (Art. 28(3)).
- Report at least yearly to the NCA on new arrangements, provider categories, contract types, and services/functions (Art. 28(3)).
- Validate against the EBA data model and validation rules before any NCA submission.

## 2. Criticality rubric

Determines `supports_cif` and `criticality_tier`. DORA's legal distinction is binary
(CIF vs non-CIF, Art. 28(2)); tiers 2 and 3 are an operational refinement for evidence
proportionality — they do NOT change legal obligations.

Step 1 — CIF test (Art. 3(22)): the function's disruption would materially impair
financial performance, soundness or continuity of services, or compliance with
authorisation conditions/obligations. If yes for any supported function →
`supports_cif = yes` → `tier_1_cif`.

Step 2 — for non-CIF services, assign:
- `tier_2_standard`: service failure would degrade internal operations or client
  experience within days (e.g. CRM, HR platform, ticketing).
- `tier_3_low`: ancillary, easily substitutable, no material operational dependency
  (e.g. marketing tools, non-production utilities).

Step 3 — record for every Tier 1 arrangement (feeds RoI assessments table, B_07):
| Field | Enum / type |
|---|---|
| `substitutability` | `easy` / `difficult` / `highly_complex` |
| `alternative_providers_identified` | boolean + names |
| `time_to_substitute` | duration (months) |
| `concentration_risk_flag` | boolean — dependence on this or closely connected providers (Art. 29) |
| `reassessment_due` | date — at least annually and on material change |

## 3. Evidence checklist — rows per tier

Status enum per row: `not_requested` / `requested` / `received` / `verified` / `expired`.
Cadence enum: `onboarding` / `annual` / `semiannual` / `quarterly` / `continuous` / `per_event`.

### Tier 1 — CIF-supporting providers (full set)

| Category | Evidence type | DORA anchor | Cadence |
|---|---|---|---|
| Security certification | ISO/IEC 27001 certificate (scope-checked) | Art. 28(4)-(5) due diligence | annual |
| Independent assurance | ISAE 3402 / ISAE 3000 report | Art. 30(3)(e) monitoring rights | annual |
| Service performance | SLA reports vs quantitative targets | Art. 30(3)(a) | quarterly |
| Material-change notices | Provider notifications affecting service delivery | Art. 30(3)(b) | per_event |
| Business continuity | BCP/DR test results and RTO/RPO evidence | Art. 30(3)(c) | annual |
| Security testing | Penetration test summary | Art. 30(3)(c) | annual |
| TLPT cooperation | Written confirmation of TLPT participation obligation | Art. 30(3)(d); Arts. 26-27 | per TLPT cycle (≥ every 3 years) |
| Incident cooperation | Incident notification SLA + 24/7 contact matrix | Art. 30(2)(f); Art. 19 | annual review |
| Subcontracting disclosure | Current subcontractor list with locations (section 4) | Art. 29; CDR (EU) 2025/532 | quarterly |
| Data locations | Storage/processing location statement | Art. 30(2)(b) | annual + per_event |
| Exit readiness | Data portability statement + tested exit plan | Art. 28(8); Art. 30(3)(f) | annual test |
| Financial soundness | Financial health indicator (report or rating) | Art. 28(4) due diligence | annual |

### Tier 2 — standard providers

| Category | Evidence type | DORA anchor | Cadence |
|---|---|---|---|
| Security certification | ISO/IEC 27001 certificate or equivalent attestation | Art. 28(4)-(5) | annual |
| Service description | Contract-complete service description + data locations | Art. 30(2)(a)-(b) | annual review |
| Incident cooperation | Incident notification commitment | Art. 30(2)(f) | annual review |
| Subcontracting disclosure | Subcontractor list | Art. 29 | annual |

### Tier 3 — low-dependency providers

| Category | Evidence type | DORA anchor | Cadence |
|---|---|---|---|
| Baseline security | Security attestation or questionnaire | Art. 28(1) proportionality | onboarding, refresh on renewal |
| Register completeness | Contract + service data captured in register | Art. 28(3) | annual review |

## 4. Subcontracting-chain fields (Tier 1 arrangements)

Per CDR (EU) 2025/532, identify and assess the chain that effectively underpins the
CIF-supporting service. One record per subcontractor:

| Field | Type / enum | Definition |
|---|---|---|
| `subcontractor_name` | text | Legal name |
| `subcontractor_country` | ISO 3166-1 alpha-2 | Country of establishment |
| `service_underpinned` | text | Which part of the ICT service this subcontractor effectively underpins |
| `chain_position` | integer | 1 = direct subcontractor of the provider, 2 = next layer, etc. |
| `data_locations` | list of ISO country codes | Storage/processing locations in the chain |
| `third_country_risk` | boolean | Non-EU/EEA jurisdiction with enforceability or data-protection concerns (Art. 29) |
| `chain_length_concern` | boolean | Chain too long/complex to monitor effectively |
| `material_change_notice` | date | Last provider notification of subcontracting change |

Rule: no fixed numerical limit on chain layers exists, but the entity must be able to
monitor the chain effectively; unmonitorable chains are a risk finding.

## 5. Exit-strategy checklist (Tier 1 arrangements — Art. 28(8), Art. 30(3)(f))

| Item | Field / enum | Requirement |
|---|---|---|
| Documented exit plan exists | boolean | Plan must be comprehensive and documented |
| Alternative solution identified | `alternative_provider` / `in_house` / `none_yet` | Identify alternative solutions |
| Transition plan in place | boolean | Enables removal and secure, integral transfer of services and data to alternative or in-house |
| Mandatory transition period in contract | duration (months) | Art. 30(3)(f) adequate transition period during which provider continues service |
| Data return format agreed | text (e.g. open format, full export) | Supports secure and integral transfer |
| Contingency measures defined | boolean | Maintain business continuity if provider fails or quality deteriorates |
| Exit plan last tested | date | Must be sufficiently tested and periodically reviewed |
| Exit trigger scenarios documented | list | Provider failure, service deterioration, disruption, termination under Art. 28(7) |

## 6. Suggested workflow

1. Populate section 1 for every ICT arrangement (completeness before depth).
2. Run section 2 rubric; set `criticality_tier` on each record.
3. Instantiate section 3 evidence rows per provider per tier; track status + next-due dates.
4. For every Tier 1 record, complete sections 4 and 5.
5. Quarterly: refresh Tier 1 evidence, subcontracting disclosures, and any changed criticality.
6. Before NCA submission: map records to the ITS templates (Implementing Regulation
   (EU) 2024/2956) and run the EBA validation rules. Confirm the submission window with
   your NCA — windows are national (commonly February–March, e.g. Ireland: 2–31 March
   2026, reference date 31 December 2025).

---
Orbiq — European Trust Center & compliance platform · https://www.orbiqhq.com/templates/dora-ict-provider-evidence-checklist · v1.0 · 2026-07-03