nexalign

Decision guide · Compliance

Building the DORA register of information: completeness, classification, supervisory reporting

The DORA register of information under Art. 28 (3) is not a spreadsheet annex but the central supervisory artefact of every financial entity. Building it means choosing between three approaches: GRC module (ServiceNow, OneTrust), in-house in Excel/Confluence or hybrid decision-memo-plus-register. The first 2025 review wave shows that completeness and classification are the most common deficiencies.

TL;DR

The register of information is a supervisory artefact. Completeness before tool choice, classification before detail.

Who owns this decision

CISO or CRO as owner, management body as accountable party under Art. 5 DORA. Procurement, Legal, IT architecture, Compliance and Internal Audit as active stakeholders.

Key criteria to weight

  • Completeness of contract capture

    Every ICT third-party arrangement must be in the register, including cloud marketplace purchases, open-source support, sub-outsourcing chains.

  • Classification critical / important / supporting

    Three categories with different duties. Wrong classification is the most common supervisory finding.

  • Fields per RTS and ITS

    Final Draft RTS/ITS of the ESAs (2024/2025) define mandatory fields, JSON schema, transmission format to national supervisors.

  • Sub-outsourcing transparency

    Art. 30 requires sub-outsourcing of critical functions to be known and approved. Four-level depth is the minimum expectation.

  • Concentration risk indicators

    Multiple critical functions with one provider, sub-providers overlap, geographic clustering.

  • Update discipline

    The register is a living document. Every new contract, every change, every provider switch triggers an update within 15 working days.

Step-by-step decision flow

  1. 1

    Contract inventory

    Capture all ICT third-party contracts from procurement, IT, business units, subsidiaries. Shadow IT path: credit card purchases, SaaS marketplace, open-source support contracts.

  2. 2

    Classification per contract

    Critical or important function (definition Art. 3 (22) DORA), impact on operational resilience, substitutability, data sensitivity. Document the decision.

  3. 3

    RTS/ITS mapping

    Map mandatory fields from Final Draft RTS to templates 2024/01: B_01.01 (entity), B_02.01 (branches), B_02.02 (ultimate parent), B_03.01 (contracts), B_03.02 (sub-outsourcing), B_05.01 (assessments).

  4. 4

    Decide on tooling

    GRC module (ServiceNow IRM, OneTrust DORA, MetricStream) for more than 200 contracts. Excel or Confluence sufficient up to about 50 contracts. Decision memo as audit trail per material contract, always alongside the register.

  5. 5

    Probe sub-outsourcing chain

    Supplier questionnaires with mandatory answers, sub-outsourcing transparent to level 4. Contracts with missing disclosure are risk indicators.

  6. 6

    First supervisory submission

    Annual submission to the national supervisor (BaFin in Germany, ACPR in France, CSSF in Luxembourg). First wave April 2025, annual thereafter. Format and transmission path are defined in the RTS.

Compliance note

DORA Art. 28 (3) mandates the register. Final Draft RTS and ITS of the ESAs concretise fields and format (Commission Implementing Regulation 2024/2956). BaFin's 2025 supervisory communication on first application emphasises completeness and classification. Fines for structural deficiencies via Art. 50 DORA in conjunction with national law (KWG, VAG).

Common pitfalls

  • !Shadow IT contracts are missing from the register. Supervisory sample check uncovers this.
  • !Classification too conservative: everything supporting, to avoid mandatory clauses. Supervisor reclassifies.
  • !Sub-outsourcing information missing because main provider does not answer. Provider risk is not escalated.
  • !Register is built once and not maintained. Contract changes are not reflected.
  • !Concentration risk analysis completely missing (Art. 29). The register lists providers, risks are not aggregated.

FAQ

Which contracts belong in the DORA register of information?

All ICT third-party arrangements within the meaning of Art. 3 (18) DORA: cloud contracts, SaaS, managed services, software licences with processing, IT outsourcing, sub-outsourcing, communication services. Pure licences without external processing are not unambiguously in scope; national supervisory interpretation is pending.

How do I distinguish critical, important and supporting?

Critical (Art. 3 (22)): a function whose failure would materially impair operational resilience or regulatory compliance. Important: a function that contributes to a critical function but is not critical itself. Supporting: anything else. The decision must be reasoned and documented; supervisory findings for wrong classification are common.

In which format is the register submitted to the supervisor?

Final Draft ITS defines an XBRL-based format with specified templates (B_01.01 to B_07.01). Submission in Germany to BaFin via the MVP platform (Melde- und Veröffentlichungsplattform). First full submission in April 2025, annually by 30 April thereafter.

Is Excel sufficient as the tool for the register?

Up to roughly 50 ICT contracts Excel or a Confluence table is feasible, if XBRL conversion is solved. From 200 contracts, multiple subsidiaries or complex sub-outsourcing chains a GRC module is almost unavoidable. ServiceNow IRM, OneTrust DORA module and MetricStream are the DACH-typical choices.

What happens if the register is incomplete?

Supervisory deficiency letter at first, then an order for remediation. For systematic deficiencies, fines under national law (in Germany under KWG, VAG). More serious: in case of an incident with a non-registered critical provider, supervisory response is markedly stricter because concentration risk was not steered.

Run this decision in DecisionOS →What is DecisionOS?