Getting Started

This guide walks you through the complete process of filling out the DORA Register of Information, from initial configuration to final export. Follow the steps in order for best results — the templates have dependencies that require earlier data to be entered first.

Quick start with Excel: If you already have register data in a spreadsheet, you can import from Excel instead of entering data manually. The import parser maps your columns automatically and extracts settings from B_01.01.

After signing in, you land on the Dashboard — a summary view showing fill progress per template, total row counts, and quick links to validation. Use the Dashboard to track your overall completion status at any point.

Step 1: Configure Settings

Start on the Settings page. You need to configure:

  • LEI — The Legal Entity Identifier (20 alphanumeric characters) of the entity maintaining the register. This is used throughout the export and in file naming.
  • Entity name — The legal name of the financial entity.
  • Country — The ISO 3166-1 alpha-2 country code of the entity (e.g., LV for Latvia, DE for Germany).
  • Reporting type — Select IND for individual reporting or CON for consolidated (group) reporting. This affects which templates are relevant and validation rules.
  • Reference date — The reporting reference date, typically 2025-12-31 for the first submission.
  • Reporting currency — The base currency for monetary values (e.g., EUR).
  • Competent authority — The national supervisory authority the entity reports to (e.g., FKTK for Latvia, BaFin for Germany). This appears in the register header.

Important: LEI and Country must be configured before you can export. These values are embedded in the output filename and xBRL-CSV parameters.

The Settings page also includes a Data Backup section where you can export all register data and settings as a JSON file, or restore from a previous backup. Use this to transfer data between browsers or create snapshots before making significant changes.

Step 2: Fill Entity Information

Complete the entity templates in this order:

  1. B_01.01 — Entity maintaining the register
    Enter the details of the financial entity responsible for maintaining the register: LEI, name, country, entity type, competent authority, and reporting date. For individual reporting (IND), this template should have exactly one row.
  2. B_01.02 — List of entities within the scope of consolidation
    Only needed for consolidated reporting (CON). List all entities within the group scope, including their hierarchy position, parent LEI, and integration dates. Each entity must have a unique LEI.
  3. B_01.03 — List of branches
    Register any branches of entities that are located outside the home country. Each branch needs a unique identification code, the head office LEI (which must exist in B_01.02), branch name, and country.

Step 3: Register Contracts

Record all contractual arrangements with ICT third-party service providers:

  1. B_02.01 — Contractual arrangements — General information
    Create one row per contractual arrangement. Assign a unique reference number, select the type (standalone, overarching, or subsequent), and enter the annual cost. If the arrangement is subsequent (CA_3), you must reference the overarching agreement.
  2. B_02.02 — Contractual arrangements — Specific information
    Provide detailed information for each arrangement: the entity using the service, the provider (must exist in B_05.01), the function supported (must exist in B_06.01), ICT service type, dates, data storage locations, and sensitivity levels.

Tip: B_02.02 references providers from B_05.01 and functions from B_06.01. You may want to create at least your provider and function entries before filling in B_02.02, or create them in parallel and resolve references afterwards.

Step 4: Add Signatories

Record who signs each contractual arrangement:

  1. B_03.01 — Entities signing contractual arrangements
    Link each arrangement (by reference number from B_02.01) to the financial entity that signed it (by LEI).
  2. B_03.02 — ICT third-party service providers signing contracts
    Link each arrangement to the ICT provider that signed it (provider code must exist in B_05.01).
  3. B_03.03 — Financial entities providing ICT services
    Only for intra-group arrangements: link the arrangement to the financial entity within the group that acts as the ICT service provider (LEI must exist in B_01.02).

Step 5: Map Service Usage

  1. B_04.01 — Entities making use of ICT services
    For each arrangement, list which entities are actually using the ICT service. Specify whether the user is a branch or not. If it is a branch (NE_2), you must provide the branch identification code from B_01.03.

Step 6: Register Providers

  1. B_05.01 — ICT third-party service providers
    Enter comprehensive details for each ICT provider: identification codes (LEI or EUID), legal name, name in Latin alphabet, person type (legal or natural), headquarters country, and total annual expense. Each provider needs a unique identification code that is referenced from B_02.02, B_03.02, and B_05.02.
  2. B_05.02 — ICT service supply chain
    Map subcontracting relationships. For each arrangement, record the chain of providers involved, their rank (1 = direct provider, 2+ = subcontractor), and any sub-contracting relationships.

Step 7: Define Functions

  1. B_06.01 — Functions identification
    Create a taxonomy of the entity's functions supported by ICT services. Each function gets a unique identifier, is linked to a licensed activity, and is classified as critical/important or not. These function IDs are referenced from B_02.02 and B_07.01.

Step 8: Complete Assessments

  1. B_07.01 — Assessments of ICT services supporting critical or important functions
    For each ICT service that supports a critical or important function (marked as "Y" in B_06.01), complete a risk assessment. This includes substitutability, reintegration possibility, discontinuation impact, alternative providers, and RTO/RPO targets.

Note: B_07.01 is only required for arrangements linked to functions that are classified as critical or important in B_06.01. Non-critical functions do not need assessments.

Step 9: Add Definitions (Optional)

  1. B_99.01 — Entity definitions
    If your entity uses custom internal definitions for any closed-list field values, document them here. Each definition links an LEI, a field reference, and the definition text.

Step 10: Validate and Export

  1. Go to the Validate page — validation runs automatically when the page opens. The engine checks four layers: technical format, DPM rules, DORA business logic, and EBA validation rules. Fix all errors (warnings are advisory but should be reviewed). You can re-run validation at any time after making changes.
  2. Once validation passes with zero errors, click the Export Register button that appears on the validation page, or go directly to the Export page. The tool produces a ZIP file ready for submission to your competent authority.

See the Validation Guide and Export Guide for detailed information on these final steps.

Recommended Fill Order

The optimal order to fill templates accounts for foreign-key dependencies:

  1. Settings — Configure LEI, country, reporting type
  2. B_01.01 — Entity maintaining the register
  3. B_01.02 — Entities in consolidation (if CON)
  4. B_01.03 — Branches (if applicable)
  5. B_05.01 — ICT providers (needed by contracts)
  6. B_06.01 — Functions (needed by contracts)
  7. B_02.01 — Contractual arrangements (general)
  8. B_02.02 — Contractual arrangements (specific)
  9. B_03.01, B_03.02, B_03.03 — Signatories
  10. B_04.01 — Service usage
  11. B_05.02 — Supply chain
  12. B_07.01 — Assessments
  13. B_99.01 — Definitions (if needed)

Common Pitfalls

  • Forgetting to create providers before contracts — B_02.02 requires provider codes from B_05.01 and function IDs from B_06.01. Create these entries first.
  • LEI format errors — LEIs must be exactly 20 alphanumeric characters. Double-check against the GLEIF database.
  • Subsequent arrangements without overarching ref — If you select CA_3 (subsequent) in B_02.01, you must provide the reference number of the overarching (CA_2) arrangement.
  • Open-ended dates with termination reasons — If an arrangement has ended, update the end date from 9999-12-31 to the actual termination date.
  • Missing signatories — Every arrangement in B_02.01 should have at least one corresponding entry in B_03.01 or B_03.02 for entity and provider signatories.
  • Branch nature without branch code — In B_04.01, if you select NE_2 (Branch) as the nature, the branch identification code is mandatory and must match a code in B_01.03.