---
name: "DORA-Informationsregister-Vorlage"
version: "1.0"
updated: "2026-07-23"
source: "https://www.orbiqhq.com/de/vorlagen/dora-informationsregister-vorlage"
license: "Kostenlos nutz- und anpassbar innerhalb Ihrer Organisation. Namensnennung willkommen. Keine Rechtsberatung."
legal_basis:
  - "https://eur-lex.europa.eu/eli/reg/2022/2554/oj"          # DORA — Verordnung (EU) 2022/2554 (Art. 28(3))
  - "https://eur-lex.europa.eu/eli/reg_impl/2024/2956/oj"     # ITS — Standardvorlagen für das Informationsregister
---

# DORA-Informationsregister-Vorlage (maschinenlesbar)

Zweck: Führung eines menschenlesbaren Arbeits-Informationsregisters nach DORA Artikel 28(3),
strukturiert für das Mapping auf die offiziellen Register-of-Information-Templates der ESAs
(Durchführungsverordnung (EU) 2024/2956 der Kommission — 15 Templates in 8 Gruppen, verknüpft
über relationale Schlüssel). Diese Datei ist in sich geschlossen: Ein Agent kann aus den
nachstehenden Definitionen ein vollständiges Arbeitsregister aufbauen und pflegen und die
strukturierten Datensätze zum Meldezeitpunkt an einen xBRL-CSV-Konvertierungsschritt übergeben.

KRITISCHER HINWEIS ZUM ANWENDUNGSBEREICH — Arbeitsschicht, keine Einreichungsdatei: Die ESAs
erklären, dass sie kein Excel bereitstellen können, das die Einreichungsvalidierung bestehen
würde ("not the least due to the limitations of Excel" — EBA-FAQ zur DORA-RoI-Meldung,
aktualisiert am 28.03.2025). Die offizielle Einreichung ist ein Plain-CSV-/xBRL-CSV-(OIM-CSV-)
ZIP-Paket auf Basis der ESA-Taxonomie und des Datenpunktmodells, eingereicht über das Portal
der nationalen zuständigen Behörde — in Deutschland über das MVP-Portal der BaFin. Alles
Nachstehende ist die Schicht, die Sie ZWISCHEN den Einreichungen pflegen.

Meldekalender (ab 2026): Stichtag = 31. Dezember des Vorjahres; die Unternehmen reichen bei
ihrer NCA in national festgelegten Q1-Fenstern ein (Beispiele 2026: BaFin 9.–30. März über das
MVP-Portal, Korrekturen bis 24. April; DNB bis 20. März; irische Zentralbank 1.–31. März;
CSSF-eDesk offen ab 11. Februar); die NCAs leiten konsolidierte Register bis zum 31. März
jedes Kalenderjahres an die ESAs weiter. Eine einheitliche EU-Frist für Unternehmen gibt
es nicht.

EWR-Hinweis: DORA gilt in Norwegen über das EWR-Abkommen; das norwegische DORA-Gesetz ist
seit dem 01.07.2025 in Kraft, mit Finanstilsynet als zuständiger Behörde. UK kennt kein
Registerregime (FCA/PRA operationelle Resilienz: internes Mapping, keine RoI-Einreichung).

---

## 1. Unternehmen & Gruppe — mappt auf Template-Gruppe B_01

Ein Datensatz je juristischer Einheit oder Zweigniederlassung im Anwendungsbereich des Registers.

| # | Feld | Typ | Definition / Regel | RoI-Anker |
|---|---|---|---|---|
| 1 | `entity_legal_name` | Text | Eingetragener juristischer Name | B_01.01–B_01.03 |
| 2 | `entity_lei` | Text (LEI-20) | Pflicht für Finanzunternehmen; Zweigniederlassungen werden über ihren Hauptsitz identifiziert | B_01.01 |
| 3 | `register_role` | Enum: `register_maintainer` / `group_entity_in_scope` / `branch` | Das Register wird auf Unternehmens-, teilkonsolidierter und konsolidierter Ebene geführt (Art. 28(3)) | B_01.01–B_01.03 |
| 4 | `country` | ISO 3166-1 alpha-2 | Land der Niederlassung | B_01 |
| 5 | `entity_type` | Text | Art des Finanzunternehmens nach DORA Art. 2 (Kreditinstitut, Zahlungsinstitut usw.) | B_01.02 |
| 6 | `parent_lei` | Text (LEI-20) | Direktes oder oberstes Mutterunternehmen im Konsolidierungskreis | B_01.02 |
| 7 | `competent_authority` | Text | Beaufsichtigende NCA (BaFin, DNB, CBI, Finanstilsynet, …) | B_01.01 |
| 8 | `last_updated` | Datum (ISO 8601) | Pflegedatum des Registereintrags | Art. 28(3) |

## 2. Vertragliche Vereinbarungen — mappt auf Template-Gruppe B_02

Ein Datensatz je vertraglicher Vereinbarung über die Nutzung von IKT-Dienstleistungen —
ALLE Vereinbarungen, nicht nur Cloud und nicht nur kritische (Art. 28(3)).

| # | Feld | Typ | Definition / Regel | RoI-Anker |
|---|---|---|---|---|
| 1 | `contract_ref` | Text, eindeutig | Referenznummer der vertraglichen Vereinbarung — der PRIMÄRE RELATIONALE SCHLÜSSEL, der alle anderen Abschnitte verknüpft | B_02.01 |
| 2 | `arrangement_type` | Enum: `standalone` / `overarching_master` / `subsequent_under_master` / `intra_group` | Art der Vereinbarung | B_02.01 |
| 3 | `master_ref` | Text | Referenz der Rahmenvereinbarung, falls Folgevereinbarung | B_02.01 |
| 4 | `provider_legal_name` | Text | Muss in Abschnitt 3 (IKT-Dienstleister) existieren | B_02 → B_05.01 |
| 5 | `ict_service_type` | Enum `S01`–`S19` (geschlossene Liste, siehe Abschnitt 7) | Nur die S-Code-Kennungen sind gültig — kein Freitext | B_02.02, Anhang III |
| 6 | `service_description` | Text | Vollständige Beschreibung der IKT-Dienstleistung | Art. 30(2)(a) |
| 7 | `contract_start` | Datum (ISO 8601) | Beginndatum | B_02.02 |
| 8 | `contract_end` | Datum oder `indefinite` | Enddatum | B_02.02 |
| 9 | `notice_period_entity` | Ganzzahl (Tage) | Kündigungsfrist des Finanzunternehmens | B_02.02 |
| 10 | `notice_period_provider` | Ganzzahl (Tage) | Kündigungsfrist des Dienstleisters | B_02.02 |
| 11 | `governing_law` | ISO 3166-1 alpha-2 | Land des anwendbaren Rechts | B_02.02 |
| 12 | `annual_expense_eur` | Zahl, ohne Formatierung | Jährlicher Aufwand / geschätzte Kosten; keine Trennzeichen oder Symbole | B_02.01 |
| 13 | `supports_cif` | Enum: `yes` / `no` / `under_assessment` | Ob die Dienstleistung eine kritische oder wichtige Funktion unterstützt (Art. 28(2), Art. 3(22)) | B_02.02 |
| 14 | `function_ids` | Liste von `function_id` | Unterstützte Funktionen; müssen in Abschnitt 6 existieren | B_02 → B_06.01 |
| 15 | `data_storage` | Boolean | Ob die Dienstleistung die Speicherung von Daten umfasst | B_02.02 |
| 16 | `data_locations_storage` | Liste von ISO-Ländercodes | Wo Daten gespeichert werden | B_02.02 |
| 17 | `data_locations_processing` | Liste von ISO-Ländercodes | Wo Daten verarbeitet werden / von wo die Dienstleistung gesteuert wird | B_02.02 |
| 18 | `data_sensitiveness` | Enum: `low` / `medium` / `high` | Sensibilität der gehaltenen Daten | B_02.02 |
| 19 | `last_reviewed` | Datum (ISO 8601) | Datum der Überprüfung des Datensatzes | Art. 28(3) |

## 3. IKT-Drittdienstleister — mappt auf Template B_05.01

Ein Datensatz je Dienstleister (über alle Vereinbarungen dedupliziert).

| # | Feld | Typ | Definition / Regel | RoI-Anker |
|---|---|---|---|---|
| 1 | `provider_legal_name` | Text | Eingetragener juristischer Name | B_05.01 |
| 2 | `provider_id_type` | Enum: `LEI` / `EUID` / `CC_CRN` / `CC_VAT` / `CC_PNR` / `CC_NIN` | Kennungsregeln: juristische Personen in der EU → LEI oder EUID; juristische Personen aus Drittländern → nur LEI; natürliche Personen in geschäftlicher Eigenschaft → Ländercode + CRN/VAT/PNR/NIN | B_05.01 |
| 3 | `provider_id` | Text | Die Kennung selbst; LEIs müssen 20 alphanumerische Großzeichen umfassen und dürfen nicht erloschen sein (gegen GLEIF validieren) | B_05.01 |
| 4 | `provider_country` | ISO 3166-1 alpha-2 | Land der Niederlassung | B_05.01 |
| 5 | `person_type` | Enum: `legal_person` / `natural_person` | — | B_05.01 |
| 6 | `ultimate_parent` | Text | Oberstes Mutterunternehmen | B_05.01 |
| 7 | `intra_group` | Boolean | Dienstleister gehört zur selben Gruppe | B_05.01 |
| 8 | `ctpp_designated` | Boolean | Auf der Liste der von den ESAs designierten kritischen IKT-Drittdienstleister (erste Designationen am 18.11.2025) | CTPP-Liste der ESAs |
| 9 | `total_annual_expense_eur` | Zahl | Aggregiert über alle Vereinbarungen | B_05.01 |

## 4. IKT-Unterauftragsketten — mappt auf Template B_05.02

Ein Datensatz je Glied der Kette hinter jeder Vereinbarung.

| # | Feld | Typ | Definition / Regel |
|---|---|---|---|
| 1 | `contract_ref` | Schlüssel → Abschnitt 2 | Vereinbarung, zu der diese Kette gehört |
| 2 | `rank` | Ganzzahl ≥ 1 | 1 = direkter Dienstleister; 2+ = Unterauftragnehmer, die den Dienst faktisch tragen (Art. 29; Del. VO (EU) 2025/532) |
| 3 | `provider_legal_name` | Text | Dienstleister oder Unterauftragnehmer auf diesem Rang |
| 4 | `provider_id` | Text | LEI/EUID nach den Regeln von Abschnitt 3 |
| 5 | `country` | ISO 3166-1 alpha-2 | Niederlassung dieses Kettenglieds |
| 6 | `ict_service_type` | Enum `S01`–`S19` | Auf diesem Rang erbrachte Dienstleistung |
| 7 | `service_underpinned` | Text | Was dieses Glied trägt / wer die weitervergebene Dienstleistung empfängt |

## 5. Unterzeichnende & nutzende Unternehmen — mappt auf Templates B_03.01–B_03.03 und B_04.01

| # | Feld | Typ | Definition / Regel |
|---|---|---|---|
| 1 | `contract_ref` | Schlüssel → Abschnitt 2 | — |
| 2 | `signing_entity` | Text + LEI | Unternehmen, das die Vereinbarung unterzeichnet (ggf. im Namen anderer Gruppenunternehmen) |
| 3 | `provider_signatory` | Text | IKT-Dienstleister, der die Vereinbarung unterzeichnet |
| 4 | `using_entity` | Text + LEI | Finanzunternehmen, das die IKT-Dienstleistung tatsächlich nutzt |
| 5 | `using_branch` | Text | Nutzende Zweigniederlassung, falls vorhanden |

## 6. Funktionen — mappt auf Template B_06.01

Ein Datensatz je Geschäftsfunktion, die von IKT-Dienstleistungen unterstützt wird.

| # | Feld | Typ | Definition / Regel |
|---|---|---|---|
| 1 | `function_id` | Text, eindeutig | RELATIONALER SCHLÜSSEL, referenziert aus Abschnitt 2 |
| 2 | `function_name` | Text | — |
| 3 | `licensed_activity` | Text | Zugelassene Tätigkeit, zu der die Funktion gehört |
| 4 | `performing_entity_lei` | Text (LEI-20) | Unternehmen, das die Funktion ausführt |
| 5 | `criticality` | Enum: `cif` / `not_cif` / `under_assessment` | Test nach Art. 3(22): Würde eine Störung die finanzielle Leistungsfähigkeit, Solidität oder Kontinuität der Dienstleistungen oder die Einhaltung der Zulassungspflichten wesentlich beeinträchtigen? |
| 6 | `criticality_reasons` | Text | Dokumentierte Gründe für die Bewertung |
| 7 | `assessment_date` | Datum (ISO 8601) | Mindestens jährlich und bei wesentlichen Änderungen |
| 8 | `discontinuation_impact` | Enum: `low` / `medium` / `high` | Auswirkung der Einstellung der Funktion |

## 7. KWF-Bewertungen — mappt auf Template B_07.01

Ein Datensatz je Vereinbarung mit `supports_cif = yes`.

| # | Feld | Typ | Definition / Regel |
|---|---|---|---|
| 1 | `contract_ref` | Schlüssel → Abschnitt 2 | — |
| 2 | `substitutability` | Enum: `easy` / `difficult` / `highly_complex` / `not_substitutable` | — |
| 3 | `substitutability_reason` | Text | Erforderlich, wenn nicht `easy` |
| 4 | `last_audit_date` | Datum (ISO 8601) | Letzte Prüfung oder Assurance-Review des Dienstleisters |
| 5 | `exit_plan_documented` | Boolean | Art. 28(8): dokumentiert, umfassend, ausreichend getestet, regelmäßig überprüft |
| 6 | `exit_plan_last_tested` | Datum (ISO 8601) | Ein ungetesteter Exit-Plan erfüllt Art. 28(8) nicht |
| 7 | `reintegration_possibility` | Enum: `easy` / `difficult` / `highly_complex` / `not_possible` | Rückführung der Dienstleistung ins eigene Haus |
| 8 | `discontinuation_impact` | Enum: `low` / `medium` / `high` | — |
| 9 | `alternative_providers` | Text | Identifizierte Alternativen (Art. 28(8)) |

### Geschlossene Liste — Arten von IKT-Dienstleistungen (ITS Anhang III; nur diese Kennungen sind gültig)

`S01` IKT-Projektmanagement · `S02` IKT-Entwicklung · `S03` Helpdesk und First-Level-Support ·
`S04` IKT-Sicherheitsmanagement-Dienstleistungen · `S05` Datenbereitstellungsdienste · `S06` Datenanalysedienste ·
`S07` IKT-Infrastruktur, Einrichtungen und Hosting (ohne Cloud) · `S08` Digitale Verarbeitungskapazitäten (ohne Cloud) ·
`S09` Datenspeicherplattform (ohne Cloud) · `S10` Telekommunikationssysteme und Flussmanagement ·
`S11` Netzinfrastruktur · `S12` Hardware und physische Geräte als Dienstleistung ·
`S13` Lizenzierung von On-Premises-Software (kein SaaS) · `S14` IKT-Betriebsmanagement ·
`S15` IKT-Beratung · `S16` IKT-Risikomanagement nach DORA · `S17` Infrastructure-as-a-Service (IaaS) ·
`S18` Platform-as-a-Service (PaaS) · `S19` Software-as-a-Service (SaaS)

## 8. Prüfungen vor der Einreichung (abgeleitet aus dem ESA-Probelauf 2024 und der Einsammlung 2025)

Im Probelauf der ESAs 2024 (~1.000 Unternehmen) bestanden nur 6,5 % der Register alle 116
Datenqualitätsprüfungen; 86 % der Fehler waren fehlende Pflichtangaben. Vor der Konvertierung
durchführen:

1. Kein Pflichtfeld in irgendeinem Abschnitt leer.
2. Jede LEI umfasst 20 alphanumerische Großzeichen, gehört zur richtigen juristischen Person
   und ist nicht erloschen (GLEIF-Prüfung).
3. Kennungstypen der Dienstleister folgen den Regeln aus Abschnitt 3 (juristische Personen
   in der EU: LEI oder EUID; Drittland: nur LEI).
4. `ict_service_type`-Werte sind ausschließlich S-Codes — kein Freitext.
5. Alle Daten in ISO 8601 und logisch konsistent (Beginn ≤ Ende; nichts nach dem Stichtag).
6. `contract_ref`-Werte eindeutig; jede abschnittsübergreifende Referenz löst auf (Verträge ↔
   Dienstleister ↔ Funktionen ↔ Bewertungen ↔ Unterauftragsketten).
7. Ländercodes ISO 3166-1 alpha-2; Währungen ISO 4217; Geldbeträge als reine Zahlen.
8. In das xBRL-CSV-Paket nach der ESA-Taxonomie konvertieren; EBA-Validierungsregeln laufen
   lassen; Fehler beheben und erneut prüfen.
9. Das Einreichungsfenster Ihrer NCA bestätigen — die Fenster unterscheiden sich je Land
   (Deutschland 2026: BaFin, 9.–30. März, MVP-Portal).

---

Gepflegt von Orbiq (orbiqhq.com). Menschenlesbare Seite mit Kontext, Quellen und den
XLSX-/PDF-Varianten: https://www.orbiqhq.com/de/vorlagen/dora-informationsregister-vorlage