# DORA Register of Information: 2026 Guide for ICT Third-Party Risk

Source: https://www.cyadviso.com/dora-register-of-information
Last reviewed: 2026-04-29
Tags: DORA, Third-Party Risk

DORA Register of Information guide for 2026: required data fields, ICT third-party mapping, critical functions, validation controls and submission readiness.

---

**Last reviewed: 29 April 2026**

This guide covers the Register of Information specifically (DORA Article 28). For the full Articles 28–30 third-party ICT risk framework — strategy, concentration risk, contractual provisions, exit planning — see [DORA Third-Party ICT Risk: Articles 28–30 Guide →](/dora-third-party-ict-risk). For an anonymised sample Register in NCA format, see [DORA Register of Information sample →](/artefacts/register-of-information).

**Key takeaways**

- The Register of Information maps ICT third-party arrangements to entities, services, functions and contracts.
- Under DORA Article 28, the register needs current ownership and review, not one-off spreadsheet completion.
- Supervisors and partners ask whether critical functions, providers, subcontractors and exit arrangements are visible.
- Fastest path: consolidate suppliers -> classify ICT services -> map critical functions -> validate contracts.

## Short answer

The DORA Register of Information is the structured inventory of a financial entity's contractual arrangements with ICT third-party service providers.

Under DORA Article 28, financial entities must maintain this register as part of ICT third-party risk management. In 2026, the practical challenge is not knowing that the register exists. It is keeping the data current, consistent and review-ready.

A useful Register of Information connects:

- the regulated entity;
- ICT third-party provider;
- ICT service;
- contract;
- business function;
- critical or important function status;
- subcontracting;
- location and data considerations;
- exit and resilience evidence;
- responsible internal owner.

For EU fintechs, the register is one of the strongest supervisory evidence artefacts.

It shows how the business depends on external technology.

## What the Register of Information is for

The Register of Information is not only a reporting template. It is an operating control.

It helps the financial entity answer:

- Which ICT third-party providers support regulated services?
- Which providers support critical or important functions?
- Which legal entity owns each contractual arrangement?
- Which contracts have DORA Article 30 clauses?
- Where are material dependencies concentrated?
- Which subcontractors matter?
- Which services would be difficult to exit?
- Which provider data is incomplete or stale?

Supervisors and partner banks can use the register to understand ICT dependency risk. Internal teams can use it to connect procurement, legal, risk, security, technology and business ownership.

## Register of Information at a glance

| Register component | What it should show | Why it matters |
|---|---|---|
| Financial entity | Which regulated entity receives the ICT service | Scope and accountability |
| ICT third-party provider | Who provides the service | Provider identification and concentration |
| Contract | Which agreement governs the service | Legal enforceability and Article 30 review |
| ICT service | What technology service is provided | Service and dependency mapping |
| Function supported | Which business process depends on the service | Operational impact |
| Critical or important function | Whether the function has heightened DORA relevance | Risk prioritisation and contract depth |
| Subcontracting | Whether the provider relies on material subcontractors | Supply-chain visibility |
| Location / data | Where services or data processing occur | Resilience, legal and supervisory context |
| Exit | Whether there is a practical exit or migration path | Continuity and concentration risk |

## Who needs to maintain it

DORA applies to financial entities listed in Article 2. For fintech and financial-services firms, the register is commonly relevant to:

- credit institutions;
- payment institutions;
- electronic money institutions;
- investment firms;
- crypto-asset service providers authorised under MiCA;
- insurance and reinsurance undertakings;
- trading venues and other financial market infrastructure;
- other financial entities in DORA scope.

ICT third-party providers do not maintain the financial entity's register for it. Providers supply information, but the financial entity remains responsible for the completeness and quality of the register.

## What counts as an ICT third-party service

The register should cover contractual arrangements for ICT services. For fintechs, common examples include:

- cloud hosting and infrastructure;
- core banking or ledger systems;
- payment processors and gateways;
- card-processing platforms;
- fraud, AML and transaction-monitoring tools;
- KYC and identity-verification services;
- customer-support platforms;
- data warehouses and analytics tools;
- cybersecurity monitoring and incident response tools;
- software development, maintenance or managed IT services.

The practical rule is simple.

Assess a provider for register inclusion if it delivers technology that supports:

- a regulated service;
- customer operations;
- a critical process;
- a data flow;
- a resilience capability.

## Data fields to capture

The exact technical format should follow the applicable DORA reporting package and competent-authority instructions. Operationally, the data model should cover the following categories.

| Data category | Example fields | Common source |
|---|---|---|
| Entity data | Regulated entity, country, licence type | Compliance / legal entity register |
| Provider identity | Provider legal name, identifier, group, country | Procurement / contract record |
| Contract data | Contract ID, start/end date, termination rights | Legal / procurement |
| Service data | ICT service name, description, delivery model | Technology owner |
| Function mapping | Business function, critical or important function flag | Risk / business owner |
| Risk classification | Criticality, substitutability, concentration risk | Risk / security |
| Data and location | Data types, processing/storage locations | Security / privacy |
| Subcontracting | Material subcontractors, locations, approval status | Vendor manager |
| Exit and continuity | Exit strategy, BCDR dependency, fallback options | Operations / technology |
| Review status | Data owner, last review, evidence link | Compliance / PMO |

The register will fail if it is owned only by procurement.

Procurement may know the vendor and contract. It usually does not know the full picture:

- service dependency;
- critical function;
- data flow;
- resilience requirement;
- business impact.

## Critical or important functions

The most important classification in the register is whether an ICT service supports a critical or important function.

This classification affects:

- risk prioritisation;
- depth of supplier due diligence;
- Article 30 contract requirements;
- exit planning;
- concentration-risk analysis;
- management reporting;
- supervisory review.

### Classification questions

| Question | Why it matters |
|---|---|
| Would failure disrupt a regulated service? | Links technology to business impact |
| Would customer funds, transactions or market activity be affected? | Shows operational and conduct exposure |
| Is the provider easily replaceable? | Supports substitutability assessment |
| Does the provider process sensitive or regulated data? | Links to data and security risk |
| Is the service part of incident detection, continuity or recovery? | Makes resilience dependency visible |
| Is there concentration on one provider or platform? | Supports concentration-risk analysis |

Do not classify based only on contract value. A low-cost SaaS tool can support a critical workflow. A high-cost vendor can be operationally replaceable.

## Register ownership model

A strong Register of Information has named owners for each part of the data.

| Role | Register responsibility |
|---|---|
| Compliance | Scope, NCA expectations, evidence index |
| Procurement | Supplier list, contract reference, renewal status |
| Legal | Contract clauses, termination and audit/access rights |
| CTO / technology owner | Service description, architecture dependency, technical owner |
| Security / CISO | ICT risk, data sensitivity, incident support, control expectations |
| Business owner | Function supported, criticality, business impact |
| Risk | Critical or important function assessment, concentration risk |
| Finance | Completeness check against payments to vendors |

The best control is a reconciliation process. Compare the register against procurement, finance, system inventory and architecture records. Differences should produce remediation items.

## How to build the Register of Information

### Step 1: Create the supplier universe

Start with all suppliers that may provide ICT services. Pull from procurement, finance, security tools, cloud accounts, SaaS spend, architecture diagrams and business-owner lists.

Output: one candidate ICT supplier list.

### Step 2: Decide what is in scope

Classify each supplier as ICT service provider, non-ICT provider, or unclear. Keep the decision trail for borderline cases.

Output: in-scope ICT third-party provider list.

### Step 3: Map services to functions

For each provider, identify the service and the business function it supports. Avoid vague descriptions such as "software" or "platform". Use service descriptions that a reviewer can understand.

Output: provider to service to function map.

### Step 4: Classify criticality

Assess whether the supported function is critical or important. Use business impact, customer impact, substitutability, data sensitivity and regulatory exposure.

Output: critical-or-important function flag and rationale.

### Step 5: Link contracts and clauses

Connect each register entry to the governing contract and review DORA-relevant clauses, especially where the service supports a critical or important function.

Output: contract status and Article 30 clause tracker.

### Step 6: Validate data quality

Check identifiers, dates, ownership, provider names, group relationships, subcontractor data, locations and missing fields.

Output: data-quality exceptions and remediation tracker.

## Article 30 contract link

The register and contract review should be connected. A register entry that identifies a critical ICT service should trigger a deeper contract review.

| Contract area | Why it matters |
|---|---|
| Service description | Confirms what the provider is responsible for |
| Security requirements | Sets baseline controls and assurance expectations |
| Access and audit rights | Supports supervisory and internal assurance |
| Incident notification | Ensures provider cooperation during ICT incidents |
| Subcontracting | Controls visibility over supply-chain changes |
| BCDR and recovery | Links provider obligations to resilience requirements |
| Data return and deletion | Supports exit and customer protection |
| Exit assistance | Makes migration or termination operationally possible |

The register should show which contracts need remediation, which have been reviewed and which risks have been accepted.

## Data quality controls

Most Register of Information problems are data-quality problems.

Typical issues include:

- duplicate provider names;
- missing contract IDs;
- expired contract dates;
- unclear service descriptions;
- inconsistent criticality flags;
- provider group and subsidiary confusion;
- missing subcontractor information;
- unsupported location assumptions;
- no internal owner;
- register not reconciled against finance or procurement records.

### Validation checklist

| Control | Test |
|---|---|
| Completeness | Compare register against finance and procurement vendor lists |
| Ownership | Every entry has business, contract and technical owner |
| Criticality | Every critical-or-important flag has rationale |
| Contract link | Every service has a contract or documented exception |
| Provider identity | Provider names and identifiers are standardised |
| Review date | Every entry has a last-reviewed date |
| Exceptions | Missing data is tracked with owner and due date |

## Submission readiness

Local submission timing, channels and technical instructions can depend on the competent authority and the applicable DORA reporting package. Do not assume that a spreadsheet used internally is submission-ready.

Before any submission or supervisory request, confirm:

- current NCA instruction;
- required format;
- reporting perimeter;
- entity-level vs group-level expectation;
- data cut-off date;
- validation rules;
- sign-off owner;
- evidence retained after submission.

Use the [DORA National Competent Authorities selected-jurisdiction hub](/dora-national-competent-authorities) to identify the authority starting point.

Then verify the current instructions on the authority website.

## Operating cadence

The register should not be refreshed only before a filing. It should be linked to normal vendor and change-management workflows.

| Event | Register action |
|---|---|
| New ICT supplier | Create entry and classify scope |
| Contract renewal | Review Article 30 clauses and exit terms |
| New product or service | Map ICT dependencies to functions |
| Material system change | Reassess criticality and data flow |
| Supplier incident | Update risk assessment and incident history |
| BCDR test | Update dependency and recovery evidence |
| Board review | Report critical providers and open gaps |

This cadence keeps the register alive and reduces year-end remediation pressure.

## Evidence pack for review

When a supervisor, partner bank or auditor reviews third-party ICT risk, the register should sit inside a wider evidence pack.

| Evidence area | Documents / records |
|---|---|
| Register | Current Register of Information, data dictionary, owner list |
| Scope | DORA scope note, critical-function register |
| Suppliers | Supplier assessments, due-diligence records, review notes |
| Contracts | Clause tracker, contract gap analysis, remediation decisions |
| Risk | Concentration-risk assessment, substitutability assessment |
| Resilience | BCDR tests, exit strategies, provider recovery commitments |
| Governance | Board reporting, risk acceptances, remediation tracker |

This pack makes the register defensible. The register itself is the index; the supporting documents prove the entries are real.

## Common mistakes

### Mistake 1: Treating the register as a one-off filing

The register becomes stale quickly if it is not tied to procurement, finance, technology and change-management workflows.

### Mistake 2: Using vendor names instead of service dependencies

A provider list is not enough. DORA needs visibility into the ICT service and the function it supports.

### Mistake 3: Classifying criticality by spend

Criticality depends on operational impact, substitutability, data and regulatory exposure, not only cost.

### Mistake 4: Ignoring subcontractors

Material subcontracting can create hidden concentration and location risk. It should be captured where relevant and available.

### Mistake 5: Keeping contract remediation outside the register

If Article 30 contract gaps are not linked to register entries, the third-party risk picture is incomplete.

## Related reading

- [DORA Compliance Checklist 2026: Practical Implementation Guide](/dora-compliance-guide)
- [DORA Compliance Guide for European Fintech SMBs: 2026 Evidence Roadmap](/comprehensive-guide-dora-compliance-fintech-smb)
- [DORA vs PSD2/PSD3: 2026 Guide for EU Payment Institutions and EMIs](/dora-vs-psd2-psd3)
- [EBA Guidelines on ICT and Security Risk Management After DORA](/ebas-guidelines-on-ict-and-security-risk-management)
- [DORA Business Continuity and Disaster Recovery: Articles 11-12 Roadmap for 2026](/dora-business-continuity-and-disaster-recovery)
- [DORA National Competent Authorities — selected jurisdiction guides](/dora-national-competent-authorities)

## Primary sources

- [Regulation (EU) 2022/2554 — DORA, EUR-Lex](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554)
- [European Banking Authority — Digital Operational Resilience Act (DORA)](https://www.eba.europa.eu/activities/direct-supervision-and-oversight/digital-operational-resilience-act)
- [European Commission Implementing Regulation (EU) 2024/2956 — standard templates for the Register of Information](https://eur-lex.europa.eu/eli/reg_impl/2024/2956/oj)
- [EBA — Implementing Technical Standards to establish the Register of Information templates](https://www.eba.europa.eu/activities/single-rulebook/regulatory-activities/operational-resilience/implementing-technical-standards-establish-templates-register-information?version=2024)

## Bottom line

The DORA Register of Information is not an administrative appendix. It is the operational map of ICT third-party dependency.

A useful register shows:

- which ICT providers support regulated services;
- which functions are critical or important;
- which contracts need DORA clauses;
- which dependencies create concentration or exit risk;
- who owns each entry;
- when the data was last reviewed;
- which evidence supports the record.

That is what makes the register useful for supervision, partner due diligence and day-to-day resilience management.

## FAQ

### What is the DORA Register of Information?

The Register of Information is the structured record of ICT third-party service arrangements maintained under DORA Article 28. It connects providers, services, functions, contracts, criticality, locations, subcontracting and ownership.

### Is the Register of Information the same as a supplier list?

No. A supplier list names vendors. The Register of Information must show the ICT service provided, the financial entity using it, the function supported, contractual details, criticality and other operational-risk information.

### Who should own the Register of Information?

Ownership usually sits with compliance, risk, procurement or a vCISO function, but the register needs inputs from technology, legal, finance, operations and business owners. A single accountable owner should control quality and review cadence.

### How often should the Register of Information be updated?

It should be updated when suppliers, contracts, services, criticality, locations or subcontractors change. A quarterly quality review is a practical baseline, with event-driven updates for material supplier and product changes.

### Should cloud providers be included in the Register of Information?

Yes, where they provide ICT services to the financial entity or support regulated services, critical or important functions, resilience, security or data processing. The entry should reflect the actual service and contractual arrangement.

### What makes the register submission-ready?

A submission-ready register is complete, internally reconciled, owner-approved, mapped to the required template or format, checked against current NCA instructions and supported by contract, supplier, risk and governance evidence.

---

Authored by Andrey Gubarev — CISO for EU fintechs (CISM, CDPSE, SABSA).
CyAdviso · DORA / ICT risk / vCISO programmes for EU-licensed fintechs.
Canonical HTML: https://www.cyadviso.com/dora-register-of-information