DORA register of information: how to build and maintain it with your SASE platform

Every financial entity regulated under DORA must submit a register of information to its national supervisor. The first submission rounds in early 2026 exposed a painful reality: roughly 235,000 validation errors across more than 1,000 participating institutions during the ESA dry run. Most errors came from missing fields, incorrect identifiers, and incomplete contract data. If your team is still working from spreadsheets, the odds are not in your favour.

This guide walks through what the register requires, how to build it from scratch, which mistakes get submissions rejected, and how your security architecture directly determines how complex the register becomes. For a broader look at how SASE maps to all five DORA pillars, see our guide to SASE for financial services under DORA.

What is the DORA register of information?

The DORA register of information is a structured dataset that financial entities must maintain under Article 28(3) of the Digital Operational Resilience Act. It documents every contractual arrangement with third-party ICT service providers, including contract terms, data storage locations, criticality assessments, sub-outsourcing chains, and exit strategies. National supervisors use the register to monitor concentration risk across the financial system. The European Supervisory Authorities can draw on aggregated register data to designate critical ICT providers for direct oversight.

What DORA Article 28 requires in the register

Article 28(3) mandates that financial entities maintain a complete register at entity level, sub-consolidated level, and consolidated level. This is not a simple vendor list. It is a relational dataset spanning 15 interconnected templates defined by the EBA’s Implementing Technical Standards (ITS), published under the Reporting Framework 4.0.

Each template captures a different dimension of the ICT third-party relationship. The main templates and their focus areas:

The templates form a relational structure. A contract ID in RT.02.01 links to the provider in RT.05.01, the functions it supports in RT.06.01, and the risk assessment in RT.07.01. Getting one field wrong can cascade errors across multiple templates.

The final submission format is xBRL-CSV. While some supervisors offered temporary Excel-based conversion for the first cycle, the expectation for 2026 onwards is that institutions submit directly in the prescribed format.

Which entities must maintain a register (and by when)

DORA applies broadly. Credit institutions, payment providers, insurance companies, investment firms, and crypto-asset service providers all fall within scope. The definition of “ICT service provider” is equally wide: any company delivering digital services, data services, or hardware support on a continuing basis. That includes your cloud hosting provider, your SaaS HR system, your managed firewall vendor, and your telecom provider.

Micro-enterprises receive limited exemptions from certain ICT risk management requirements, but the register obligation itself applies to virtually all regulated entities.

Benelux deadlines for 2026

Submission timelines vary by supervisor. All use 31 December 2025 as the reference date for active contracts.

The NBB strongly recommends testing submissions in the OneGate TEST environment before the production deadline. Given the error rates from the dry run, this is worth taking seriously.

Belgium has an estimated 200+ financial entities that must submit annually, spanning credit institutions, insurers, investment firms, and payment providers. For institutions with small compliance teams, the register competes for attention with NIS2 reporting, CyFun verification, and day-to-day operations.

Step-by-step: building your register from scratch

Step 1: Inventory every ICT service provider

Start with contracts, not technology. Pull your procurement records, accounts payable data, and existing vendor lists. Every supplier that provides a digital service, manages data, delivers software, or supports hardware on an ongoing basis belongs in the register.

Commonly overlooked categories include cybersecurity tools (VPN providers, firewall vendors, web filtering services, endpoint protection), SaaS platforms for non-core processes (HR, CRM, ticketing), telecom and connectivity providers, and hardware vendors with ongoing maintenance or firmware update agreements.

This is where your security architecture has its first impact on register complexity. An organisation running separate products for VPN access, web filtering, firewall management, and SD-WAN connectivity has four security vendors to document. An organisation using Jimber’s unified SASE platform, which combines ZTNA, SWG, FWaaS, and SD-WAN in a single service, documents one. The inventory step alone becomes substantially lighter.

Step 2: Collect contract details and assign identifiers

For each provider, gather the contract start and end dates, notice periods, renewal terms, and the Legal Entity Identifier (LEI). The LEI is a 20-character alphanumeric code that functions as a global ID for legal entities. Your supervisor uses it to aggregate concentration risk across the entire market.

Many mid-market ICT providers do not have an LEI. In that case, DORA allows the use of a European Unique Identifier (EUID), constructed as the ISO country code followed by a period and the national registration number. Get this format right. An incorrectly structured EUID triggers automatic rejection.

With a consolidated security stack, this step shrinks proportionally. One provider means one LEI to verify, one contract to document, one set of renewal terms to track. With five separate security vendors, you repeat this process five times, each with its own risk of data entry errors.

Step 3: Map services to business functions

Template RT.06.01 requires you to connect each ICT service to the licensed activities it supports. This is where compliance officers and IT managers need to collaborate. The compliance officer knows which activities are licensed. The IT manager knows which systems support them.

For a wealth management firm, the portfolio management system maps to investment services. The email platform maps to client communication. A SASE platform like Jimber maps to network access controls, web security, and security monitoring, all documented as functions of one service rather than three or four separate entries in the template.

Step 4: Assess criticality and document data locations

Template RT.02.02 asks whether each ICT service supports a “critical or important function.” This classification triggers additional requirements: documented exit strategies, audit rights, and more detailed risk assessments in RT.07.01.

For each service, record where data is stored and processed. Country-level granularity is expected. If your web security vendor processes traffic through nodes in the EU but stores metadata in the United States, that matters. It triggers additional documentation requirements around data transfer safeguards.

Jimber processes all data within the EEA, which makes the data location field in RT.02.02 straightforward: one entry, one jurisdiction, no cross-border transfer documentation required. Compare this with a US-headquartered security vendor where you need to document CLOUD Act exposure, Standard Contractual Clauses, and residual risk assessments for every service component.

Step 5: Document sub-outsourcing and supply chains

Template RT.05.02 covers sub-contractors. If your cloud security vendor uses a US-based infrastructure provider, that relationship must be documented. Ask each provider for their sub-outsourcing arrangements in writing. Many will not volunteer this information without a direct request.

Fewer vendors means fewer sub-outsourcing chains to trace. A single SASE provider with a transparent architecture gives you one supply chain to document instead of five.

Step 6: Complete risk assessments and exit strategies

For services classified as critical or important, RT.07.01 requires documented risk assessments and confirmation that exit strategies exist. The exit strategy must be more than a clause in a contract. It should describe how you would transition to an alternative provider or bring the function in-house, including timelines, data portability mechanisms, and impact assessments.

Cloud-native platforms like Jimber simplify exit planning because there is no proprietary hardware dependency. Configuration can be exported via API, logs follow standardised formats, and access policies are documented centrally. Contrast this with a legacy firewall vendor where exit means decommissioning physical appliances at every site.

Five mistakes that get registers rejected

The ESA dry run produced roughly 235,000 validation errors. These patterns accounted for the majority.

Missing mandatory fields. This was the single largest error category, accounting for over 86% of all validation failures. Incomplete contract records, missing function mappings, and blank criticality assessments are the most common culprits. The fix is systematic: run a completeness check against every mandatory field in the ITS specification before submission.

Invalid or expired LEI codes. LEI codes must be current and correctly formatted. An expired LEI or a typo in the 20-character string triggers an automatic rejection. Verify every LEI against the Global LEI Foundation database before submission. This accounted for roughly 6.5% of errors.

Non-standard values in dropdown fields. The ITS templates use prescribed code lists for fields like service type, criticality level, and country codes. Entering free text where a dropdown value is expected, or using internal terminology instead of the EBA’s taxonomy, causes rejection. About 4.3% of errors fell into this category.

Overlooking secondary ICT providers. Organisations tend to register their core banking provider and cloud host but forget about the web filtering service, the VPN vendor, the endpoint protection tool, and the SaaS ticketing system. Each of these is an ICT service provider under DORA’s broad definition. This is one of the strongest practical arguments for vendor consolidation: when your VPN, firewall, web filter, and SD-WAN are all part of one Jimber SASE subscription, there is nothing to forget.

Treating the register as a one-time exercise. Article 28(3) requires continuous updates. When you change providers, add a new SaaS tool, or reclassify a service as critical, the register must reflect that change. Submitting a static snapshot that was accurate six months ago but has since drifted is a compliance gap.

How a SASE platform simplifies your register

The number of rows in your register is directly determined by your security architecture. A mid-market financial institution running a typical fragmented stack, with separate vendors for VPN, firewall, web filtering, SD-WAN connectivity, and endpoint management, needs to document each of those providers individually. That means five separate entries in RT.05.01, five contracts in RT.02.01, five criticality assessments, five exit strategies, and five sets of sub-outsourcing documentation.

Jimber consolidates ZTNA, SWG, FWaaS, and SD-WAN into a single cloud-managed platform. The impact on the register is immediate.

Fewer entries means fewer opportunities for validation errors, less contract administration, and a more manageable annual update cycle.

Data sovereignty and the CLOUD Act question

Template RT.02.02 requires you to declare where data is stored and processed. If your security vendor is US-headquartered, the US CLOUD Act gives American authorities the power to compel data disclosure regardless of where servers are physically located. For European financial institutions, this creates an additional layer of documentation: you must explain the safeguards in place, typically Standard Contractual Clauses, and assess the residual risk.

Jimber is European-headquartered with all data processing within the EEA. That means the data location field in RT.02.02 is straightforward to complete and the risk assessment in RT.07.01 does not need to address cross-border data transfer concerns. For more on why European organisations are re-evaluating US vendor dependencies, see our analysis of European SASE alternatives.

Centralised logging as audit evidence

The register requires you to demonstrate that controls exist for each ICT service. With five separate security tools, that means compiling evidence from five dashboards, five log formats, and five reporting interfaces.

Jimber’s single management console provides one unified audit trail covering access controls (ZTNA), web security (SWG), network policy (FWaaS), and connectivity (SD-WAN). When your supervisor asks how you monitor the ICT services documented in the register, you point to one platform and one log stream. That is a fundamentally different conversation than explaining how five separate vendor dashboards work together.

Exit strategies made practical

Article 28(8) requires documented exit strategies for ICT services supporting critical functions. With a cloud-native platform, demonstrating portability is more straightforward than with hardware-dependent solutions. Jimber’s API-based configuration export, standardised log formats, and the absence of proprietary on-premise appliances mean your transition plan can be concrete rather than theoretical. You can run a documented test migration and log the results as evidence for template RT.07.01.

A Belgian wealth manager cut security costs by 58% after consolidating from multiple point products to Jimber’s SASE platform. The compliance benefit was a side effect of the operational simplification: fewer vendors to manage, fewer contracts to track, and a single provider to document in the register.

Belgian and Benelux context

DORA applies as a lex specialis for the financial sector, taking precedence over NIS2 for entities within its scope. In practice, many Belgian organisations face both regulations simultaneously. A bank classified as an essential entity under NIS2 must comply with both the CyFun verification framework (deadline: 18 April 2026) and the DORA register submission to the NBB.

The Centre for Cybersecurity Belgium (CCB) administers CyFun, while the NBB and FSMA handle DORA supervision. The overlap creates both burden and opportunity. Organisations that have completed their CyFun asset inventory and supply chain assessment already have much of the foundational data needed for the DORA register. The asset management and supplier controls in CyFun’s Identify and Protect functions translate directly to the provider inventories and criticality assessments in the ITS templates.

For NIS2 compliance obligations and the practical NIS2 compliance checklist, we have dedicated guides that cover the CyFun framework in detail.

A practical challenge for Belgian institutions is language. The EBA templates are in English, but NBB and FSMA communications about validation errors may arrive in Dutch or French. International teams need to ensure that the people filling in the templates and the people handling supervisor feedback can work across languages without introducing translation errors into the data.

The Netherlands activated its Cyberbeveiligingswet in Q1 2026, bringing Dutch financial institutions under parallel NIS2 and DORA obligations. DNB expects xBRL-CSV format for 2026 submissions, with limited tolerance for Excel-based workarounds. Dutch institutions that relied on temporary conversion support during the first cycle should plan for direct xBRL-CSV submission.

Frequently asked questions

What is the DORA register of information?

The register of information is a structured dataset required by Article 28(3) of the Digital Operational Resilience Act. It documents all contractual arrangements between a financial entity and its third-party ICT service providers. The register uses 15 interconnected templates defined by the EBA’s Implementing Technical Standards and must be submitted annually to the relevant national supervisor.

How often must the register be updated?

The register is not a static annual report. DORA requires continuous maintenance. Any change in contractual arrangements, new ICT service providers, reclassification of a service as critical, or modifications to sub-outsourcing chains must be reflected promptly. The annual submission to your supervisor is a snapshot, but the underlying register should be current at all times.

Does DORA apply to ICT service providers themselves?

DORA directly regulates financial entities, not their ICT providers. However, ICT service providers that are designated as “critical” by the European Supervisory Authorities fall under a direct oversight framework. Even non-critical providers face indirect pressure: their financial sector clients will require contractual provisions covering audit rights, incident notification, exit strategies, and data location transparency.

What happens if we miss the submission deadline?

DORA gives national supervisors the authority to impose administrative penalties and remedial measures. The specific sanctions vary by country and entity type. Beyond regulatory penalties, a missed or incomplete submission signals weak ICT governance to your supervisor, which may trigger increased scrutiny and more frequent reporting requirements.

Do we need to include cloud infrastructure providers like AWS in the register?

Yes. Any provider delivering ICT services on a continuing basis falls within DORA’s scope. That includes infrastructure-as-a-service providers, platform-as-a-service providers, SaaS applications, and managed service providers. If AWS hosts your core banking application, it belongs in the register with full contract details, data location information, and a criticality assessment.

How does consolidating security tools affect the register?

Directly. Each separate ICT service provider requires its own entries across multiple templates: provider details, contract information, criticality assessment, risk evaluation, and exit strategy documentation. Consolidating from five security point products to Jimber’s unified SASE platform reduces the number of provider entries from five to one. That means one LEI to verify, one contract to document, one risk assessment to complete, and one exit strategy to maintain. For a mid-market institution, this can reduce the security-related portion of the register by up to 80%.

Building a DORA register that survives validation is part data management, part architecture decision. The fewer ICT providers you need to document, the simpler the register becomes, and the lower your risk of errors in the annual submission. If your team is preparing for the next reporting cycle, book a demo to see how consolidating your security stack with Jimber changes the equation.