IKT-Referenzarchitektur: was DORA verlangt und wie Sie sie aufbauen

Diese Seite gilt für den Vollrahmen nach Art. 5 bis 15 DORA, etwa für CRR-Kreditinstitute, Versicherungsunternehmen und Kapitalverwaltungsgesellschaften. Welcher Rahmen für Sie gilt, klärt die Seite DORA-Anwendungsbereich. Für Institute im vereinfachten Rahmen nach Art. 16 steht weiter unten, was davon bleibt.

Wo steht die IKT-Referenzarchitektur in DORA?

In Art. 6 Abs. 8 lit. d. Oft wird sie Art. 8 zugeordnet, im Amtstext steht der Begriff aber nur an dieser einen Stelle: Die Strategie für die digitale operationale Resilienz (DOR-Strategie) schließt Methoden ein, um IKT-Risiken anzugehen und IKT-Ziele zu erreichen, indem „die IKT-Referenzarchitektur und etwaige Änderungen erläutert werden, die für die Erreichung spezifischer Geschäftsziele erforderlich sind“. Die englische Fassung sagt gleichbedeutend „explaining the ICT reference architecture and any changes needed to reach specific business objectives“. Der RTS 2024/1774 verwendet den Begriff nicht.

Eine Definition fehlt. Die BaFin weist darauf hin, dass der Begriff neu ist und nicht in Art. 3 DORA definiert wird, sodass in der Abgrenzung „ggf. Unschärfen auftreten können“. Sie hält die Anforderung für vergleichbar mit der strategischen Entwicklung der IT-Architektur nach BAIT und VAIT Kapitel 1.2 lit. d (Aufsichtsmitteilung vom 08.07.2024, Abschnitt 1.1). Weil die Referenzarchitektur Teil der DOR-Strategie ist, legt das Leitungsorgan sie mit der Strategie fest und genehmigt sie (Art. 5 Abs. 2 lit. d). Was die DOR-Strategie sonst enthalten muss, zeigt die Seite IKT-Risikomanagement nach DORA.

Was verlangt Art. 8 DORA?

Art. 8 regelt die Identifizierung: Funktionen, Assets und Abhängigkeiten werden ermittelt, klassifiziert, dokumentiert und in Inventaren gepflegt. Informationsassets sind Sammlungen materieller oder immaterieller Informationen, die geschützt werden sollten, IKT-Assets sind Software oder Hardware in den Netzwerk- und Informationssystemen (Art. 3 Nr. 6 und 7).

Der RTS 2024/1774 konkretisiert das in Art. 4 und 5. Die Richtlinie für das Management von IKT-Assets regelt den Lebenszyklus und schreibt vor, welche Angaben je IKT-Asset aufzuzeichnen sind (Art. 4 Abs. 2 lit. b i bis ix, Beispiel unten). Das Verfahren nach Art. 5 legt die Kriterien fest, nach denen die Kritikalität der Assets bewertet wird: das IKT-Risiko der unterstützten Funktionen und die Auswirkungen eines Verlusts von Vertraulichkeit, Integrität und Verfügbarkeit. Welche Funktionen kritisch oder wichtig sind, entscheiden Sie mit der Methode auf der Seite kritische oder wichtige Funktionen einstufen.

Wie hängen Referenzarchitektur und Inventare zusammen?

Die Referenzarchitektur ist das Zielbild, die Inventare nach Art. 8 sind der Ist-Stand. Lit. d verlangt beides zusammen zu denken, denn die DOR-Strategie soll die Änderungen erläutern, die zum Erreichen der Geschäftsziele nötig sind. Diese Änderungen ergeben sich aus dem Abgleich von Zielbild und Ist-Stand. Wir arbeiten deshalb in drei Stufen:

1. Zielbild: Architekturprinzipien und Strukturmodelle, die festlegen, wie die IKT aufgebaut sein soll. Produktunabhängig, damit es nicht mit jeder Beschaffung veraltet.
2. Ist-Stand: die Inventare nach Art. 8 Abs. 6 mit Funktionen, Assets, Konfiguration, Verbindungen und Dienstleistern.
3. Änderungen: jede Abweichung wird eine Maßnahme mit Begründung, Priorität und Verantwortlichem. Die wesentlichen Änderungen erläutert die DOR-Strategie.

DORA schreibt dafür keine Methode vor. Die BaFin beschreibt DORA als standardneutral, der RTS verlangt nur, führende Praktiken und gegebenenfalls Normen zu berücksichtigen (RTS Art. 2 Abs. 2 lit. h). Wir nutzen Begriffe aus dem TOGAF Standard von The Open Group als Methode: Zielarchitektur (Target Architecture), Ausgangsarchitektur (Baseline Architecture) und Architekturprinzipien. Eine TOGAF-Zertifizierung oder ein TOGAF-Projekt ist dafür nicht nötig.

Was gehört in eine IKT-Referenzarchitektur?

Den Inhalt legt DORA nicht fest. Unsere fachliche Empfehlung sind zwei Ebenen in einem Dokument:

Architekturprinzipien sind dauerhafte Grundsätze für Planung, Beschaffung und Betrieb, je Prinzip mit Name, Aussage und Begründung. Beispiele sind identitätsbasierter Zugriff statt Vertrauen aufgrund der Netzposition (oft „Zero Trust“ genannt), Sicherheit als Entwurfskriterium von Anfang an, mehrere unabhängige Schutzebenen, Kopplung von Systemen nur über dokumentierte Schnittstellen und ein festgelegtes Betriebsmodell für Cloud-Dienste. Keines dieser Prinzipien schreibt DORA vor. Sie helfen aber, die Anforderungen des RTS dauerhaft einzuhalten.

Strukturmodelle beschreiben den Aufbau auf konzeptioneller und logischer Ebene, ohne Produkte, Versionen oder IP-Adressen. Für mehrere Modelle gibt es im Vollrahmen einen Anker im RTS 2024/1774:

Die Netzwerkarchitektur und das Konzept für die Netzwerksicherheit sind einmal jährlich zu überprüfen, bei Kleinstunternehmen regelmäßig (RTS Art. 13 lit. i). Wie privilegierte Zugriffe technisch gesteuert werden, zeigt unsere Firmenseite zu privilegierten Zugriffen unter DORA.

Prüffrage für jede Aussage: Beschreibt sie einen dauerhaften Grundsatz oder ein Muster, unabhängig von Produkten? Dann gehört sie ins Zielbild. Beschreibt sie einen aktuellen Zustand, ein Produkt oder eine Konfiguration? Dann gehört sie ins Inventar.

Beispiel: Referenzarchitektur der Muster-Kreditbank AG

Fiktives Beispiel, kein Kunde. Die Muster-Kreditbank AG ist ein CRR-Kreditinstitut mit 140 Beschäftigten. Das Kernbankensystem betreibt ein Rechenzentrumsdienstleister, Arbeitsplätze und Netzwerk ein Managed-Service-Provider (MSP). Ihre Referenzarchitektur hat diese Gliederung, jeder Baustein ist den Fundstellen und den Inventaren zugeordnet:

Ein Eintrag im Asset-Inventar der Bank enthält die Angaben aus RTS Art. 4 Abs. 2 lit. b:

Die Wiederherstellungsziele stimmen mit der BIA überein, die auf der Seite IKT-Risikomanagement für dieselbe Bank gezeigt ist.

Was gilt im vereinfachten Rahmen nach Art. 16?

Eine Referenzarchitektur ist dort keine ausdrückliche Vorgabe. Die BaFin findet weder die Anforderung aus Art. 6 Abs. 8 lit. d noch die strategische Entwicklung der IT-Architektur nach BAIT 1.2 lit. d im vereinfachten Rahmen wieder (Aufsichtsmitteilung vom 21.08.2025, Abschnitt 2.1), und die jährliche Altsystembewertung nach Art. 8 Abs. 7 ist nicht erforderlich (Abschnitt 4.1). Die Identifizierung bleibt: Kritische oder wichtige Funktionen, die unterstützenden Informations- und IKT-Assets und ihre wechselseitigen Abhängigkeiten sind zu ermitteln, zu klassifizieren und zu dokumentieren (RTS Art. 30 Abs. 1), ebenso die von Dienstleistern unterstützten Funktionen und die wesentlichen Abhängigkeiten von IKT-Drittdienstleistern (RTS Art. 30 Abs. 2, Art. 16 Abs. 1 lit. e DORA). Eine CMDB verlangt die BaFin dafür nicht (Abschnitt 3.1). Die übrigen Pflichten zeigt die Seite Art. 16 DORA.

Drei typische Lücken

Wie wir unterstützen

Wir entwickeln mit Ihnen das Zielbild, gleichen es mit Ihren Inventaren nach Art. 8 ab und leiten die nötigen Änderungen für die DOR-Strategie ab. Wo Sie zuerst wissen wollen, wo Ihr Rahmen insgesamt steht, beginnen wir mit der DORA-Gap-Analyse.