The DORA Article 28 ICT register — what it must actually contain
The short answer
A DORA Register of Information (Article 28) must capture every contractual arrangement with an ICT third-party provider and, for each one: who the provider is, the specific ICT service, which critical or important function it supports, the criticality assessment, the sub-contracting chain behind it, and the exit/substitutability position. The point most registers miss is that it is not a procurement inventory — it is a concentration-risk picture. A supervisor reads it to see how exposed you are if one provider, or one provider's sub-contractor, fails. Build it so it answers that question, keep it current, and be able to hand it to a competent authority on request. DORA has applied since 17 January 2025.
The register checklist — seven moves
- 01
Enumerate every ICT third-party arrangement
List every contractual arrangement for ICT services — not just the big platforms. Shadow SaaS, embedded providers, and the small tools count. A register that omits arrangements understates concentration risk.
- 02
Map each arrangement to a function — and flag critical or important ones
For each provider, record which business function the ICT service supports, and whether that function is 'critical or important'. The arrangements supporting critical or important functions carry the heavier obligations and are where supervisory attention lands.
- 03
Record the contractual essentials
Capture the terms DORA expects in arrangements for critical or important functions — service levels, audit and access rights, exit strategies and transitional periods, sub-contracting conditions, and termination rights. A gap here is a contractual remediation item, not just a register field.
- 04
Trace the sub-contracting chain
Record the sub-contractors behind each provider that support the service. Concentration risk often hides one layer down — several of your providers may rest on the same underlying cloud or data-centre.
- 05
Assess concentration risk explicitly
The register is a concentration-risk picture, not a list. Surface where one provider (or one fourth-party) supports many critical functions, and where substitutability is low. This is the analysis a procurement inventory never produces.
- 06
Assess substitutability and exit
For each critical arrangement, how hard would it be to move, and is there a tested exit plan and transitional period? 'We could switch' without an exit strategy is the gap that turns a provider incident into an existential one.
- 07
Keep it current and authority-ready
The register is a living artifact you must be able to provide to a competent authority. Assign an owner and a review cadence, and keep a change log — a register that was accurate at sign-off and never updated fails the moment it is requested.
The register is a concentration-risk picture, not a procurement inventory
This is the line that separates a register that survives supervisory scrutiny from one that doesn’t. Many organisations build the Register of Information by exporting the supplier master from procurement and reformatting it. That produces a list of who you pay — which is not what Article 28 is for.
A supervisor opens the register to answer a different question: how exposed is this entity if one ICT provider, or one provider’s sub-contractor, goes down? That question is only answerable if the register maps each arrangement to the critical or important function it supports, traces the sub-contracting chain, and makes concentration visible — several “different” providers resting on the same underlying cloud is exactly the exposure the register is meant to expose.
Regulation is operational, not legal
DORA is not an abstract legal risk — it is an operational requirement with a live application date, specific evidence artifacts, and a register you must be able to hand to a competent authority. The operator who treats it as a documentation discipline — build the register, map the functions, trace the chain, maintain the change log — produces something defensible. Reserve counsel for genuinely ambiguous interpretation, not for populating fields.
The deeper treatment of what supervisory authorities actually look for — across both DORA and the EU AI Act — is in the essay What supervisory authorities actually look for in DORA and EU AI Act compliance.
This guide is an operator’s plain-language summary, not legal advice. Confirm obligations against Regulation (EU) 2022/2554 and its regulatory technical standards, and with qualified counsel.
Frequently asked
When did DORA come into force?
The Digital Operational Resilience Act (Regulation (EU) 2022/2554) has applied since 17 January 2025. The Register of Information and the wider ICT third-party risk obligations are in force now, not pending.
Is the DORA register just a list of suppliers?
No — and treating it as one is the most common mistake. A supplier list tells you who you pay; the Register of Information tells a supervisor how exposed you are if a provider or its sub-contractor fails. It maps arrangements to critical-or-important functions and surfaces concentration risk, which a procurement list does not.
What is ICT concentration risk under DORA?
Concentration risk is the exposure created when too much of your critical capability depends on a single ICT provider — or on a single fourth-party several providers quietly share. DORA expects you to assess it, which is why the register has to trace the sub-contracting chain, not stop at the direct contract.
Is this legal advice?
No. This is an operator's plain-language view of what the register has to capture. The Vihren Labs regulatory products are organizational and evidence tools, not legal opinions — confirm your specific obligations against the Regulation and the regulatory technical standards, and with qualified counsel.
The full operator essay goes deeper on what supervisors actually look for:
Read the DORA deep-dive essay →Written by Petko Petkov — 15 years inside enterprise IT operations. Vihren Labs publishes operator-grade templates and playbooks for the enterprise IT stack.