DORA Register of Information: 2026 Guide for ICT Third-Party Risk
DORA Register of Information guide for 2026: required data fields, ICT third-party mapping, critical functions, validation controls and submission readiness.
In this article ↓
- Short answer
- What the Register of Information is for
- Register of Information at a glance
- Who needs to maintain it
- What counts as an ICT third-party service
- Data fields to capture
- Critical or important functions
- Classification questions
- Register ownership model
- How to build the Register of Information
- Step 1: Create the supplier universe
- Step 2: Decide what is in scope
- Step 3: Map services to functions
- Step 4: Classify criticality
- Step 5: Link contracts and clauses
- Step 6: Validate data quality
- Article 30 contract link
- Data quality controls
- Validation checklist
- Submission readiness
- Operating cadence
- Evidence pack for review
- Common mistakes
- Mistake 1: Treating the register as a one-off filing
- Mistake 2: Using vendor names instead of service dependencies
- Mistake 3: Classifying criticality by spend
- Mistake 4: Ignoring subcontractors
- Mistake 5: Keeping contract remediation outside the register
- Related reading
- Primary sources
- Bottom line
- FAQ
- What is the DORA Register of Information?
- Is the Register of Information the same as a supplier list?
- Who should own the Register of Information?
- How often should the Register of Information be updated?
- Should cloud providers be included in the Register of Information?
- What makes the register submission-ready?
Last reviewed: 29 April 2026
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 to identify the authority starting point.
Then verify the current instructions on the authority website.
DORA by competent authority
DORA applies as EU law, but day-to-day reporting, evidence and supervisory dialogue runs through your National Competent Authority (NCA). Pick the jurisdiction-specific guide that matches your authorisation:
| Jurisdiction | DORA competent authority | Guide |
|---|---|---|
| Cyprus | CBC | Cyprus guide → |
| Denmark | Finanstilsynet | Denmark guide → |
| Estonia | Finantsinspektsioon | Estonia guide → |
| France | ACPR | France guide → |
| Germany | BaFin | Germany guide → |
| Ireland | Central Bank of Ireland | Ireland guide → |
| Italy | Banca d'Italia | Italy guide → |
| Latvia | Latvijas Banka | Latvia guide → |
| Lithuania | Lietuvos bankas | Lithuania guide → |
| Luxembourg | CSSF | Luxembourg guide → |
| Malta | MFSA | Malta guide → |
| Netherlands | DNB | Netherlands guide → |
| Sweden | Finansinspektionen | Sweden guide → |
See the DORA National Competent Authorities selected-jurisdictions hub for the full directory and the difference between NCAs and the EU ESAs (EBA, ESMA, EIOPA).
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 for European Fintech SMBs: 2026 Evidence Roadmap
- DORA vs PSD2/PSD3: 2026 Guide for EU Payment Institutions and EMIs
- EBA Guidelines on ICT and Security Risk Management After DORA
- DORA Business Continuity and Disaster Recovery: Articles 11-12 Roadmap for 2026
- DORA National Competent Authorities — selected jurisdiction guides
Primary sources
- Regulation (EU) 2022/2554 — DORA, EUR-Lex
- European Banking Authority — Digital Operational Resilience Act (DORA)
- European Commission Implementing Regulation (EU) 2024/2956 — standard templates for the Register of Information
- EBA — Implementing Technical Standards to establish the Register of Information templates
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.