Architektur-Governance für DORA und NIS2: Entscheidungen, Inventare und Abhängigkeiten

Architektur-Governance und regulatorische Dokumentation

Ein Architekturdiagramm ist schnell gezeichnet. Monate später muss das Unternehmen noch sagen können, warum eine Entscheidung fiel und wer sie genehmigt hat. Es muss auch wissen, welche Anwendungen einen kritischen Dienst stützen und wie sie voneinander abhängen. Fehlen diese Antworten, gerät ein Audit ins Stocken und eine aufsichtliche Prüfung wird mühsam.

Architektur-Governance umfasst die Gremien, Aufzeichnungen und Regeln, die die Architektur über die Zeit korrekt halten. Sie liefert einen Teil der Dokumentation, die DORA und NIS2 erwarten: Funktionen, IKT-Assets, ihre Abhängigkeiten und die Entscheidungen, die sie geprägt haben.

Sie macht ein Unternehmen nicht konform. Die zuständige Behörde und die Prüfer beurteilen die Konformität anhand der organisatorischen, vertraglichen und sicherheitsbezogenen Maßnahmen des Unternehmens. Ein Architektur-Repository hilft, das Getane zu dokumentieren und nachzuweisen; die Arbeit der Rechts-, Risiko- und Sicherheitsfunktionen bleibt vollständig bestehen.

Das Architecture Review Board

Das Architecture Review Board prüft bedeutende Änderungen, bevor sie beschlossen werden: eine neue Kernanwendung, eine größere Integration, ein neues Hosting-Modell. Es misst sie an den verabschiedeten Prinzipien. Risiko-, Sicherheits- und Resilienzfragen werden so behandelt, solange ihre Korrektur wenig kostet.

Ein Board trägt, wenn es schlank und regelmäßig bleibt: ein klarer Prüfumfang, wenige ständige Mitglieder, ein Rhythmus im Takt der Lieferungen. In ArchiLU setzen sich die Entscheidungsinstanzen nach Ihren Regeln zusammen, jede mit ihrem Mandat. Eine Instanz kann ein einziges Mitglied haben, und eine Person kann mehrere Profile vereinen.

Das Board in ArchiLU hat vier Ansichten: Zu bearbeiten, Fragen, In Überarbeitung und Historie. Ein Architekturdossier kann von einer Anfrage ausgehen oder eigenständig eröffnet werden. Das Board richtet Fragen an die Verantwortlichen, prüft die Antworten und entscheidet mit Begründung oder verlangt eine Überarbeitung mit neuer Einreichung. Die Entscheidung wird erfasst, wenn sie fällt.

Nachvollziehbare Entscheidungen

Eine Entscheidungsaufzeichnung hält für jede bedeutende Wahl den Kontext, die erwogenen Optionen, die getroffene Entscheidung und ihre Begründung fest. Sie beantwortet die schwierigste Prüfungsfrage, „Warum ist es so?“, ohne Suche in Postfächern und alten Foliensätzen.

In ArchiLU bewahrt das Entscheidungsprotokoll jede Entscheidung mit ihrer Instanz, ihrem Entscheider, ihrem Datum, ihrem Ergebnis und ihrer Begründung. Bei einem eingereichten Dossier bleiben Version, Präsentation und geprüfte Abwägungen einsehbar. Eine eingetragene Entscheidung wird nicht umgeschrieben: Eine andere ersetzt sie, oder die Instanz zieht sie zurück.

Die Folgen einer Entscheidung werden in den Prinzipien, Zielbildern und betroffenen Elementen festgehalten; die nächste Anfrage findet diese Bezüge wieder. Der Prüfer liest jede Entscheidung des Boards mit ihrer Begründung nach. Der Prüfpfad ist verkettet, überprüfbar und vom Administrator exportierbar. Die Funktionstrennung ist standardmäßig aktiv, und ihre Aufhebung wird protokolliert.

Die KI kann eine Entscheidung vorbereiten oder eine Ausnahme bewerten; es entscheiden nur die Mitglieder der Instanz.

Prinzipien, Regeln und Ausnahmen

Ein Prinzip beschreibt, was erwünscht ist, etwa „für personenbezogene Daten in der Europäischen Union gehostete Dienste bevorzugen“. Eine Regel macht es überprüfbar. Mit den Anwendungen und Entscheidungen verknüpft, die sie betreffen, zeigen Prinzipien und Regeln, wo die Architektur sie einhält und wo eine dokumentierte Ausnahme akzeptiert wurde.

In ArchiLU wird ein Prinzip in seinem Case vorbereitet und gilt, sobald das Board es verabschiedet hat. Eine spätere Anfrage wird daran gemessen: Sie hält das Prinzip ein, begründet eine Ausnahme oder schlägt eine Änderung vor. Offene Ausnahmen gehören zu den Befunden der Expositionsanalyse. Hat ein Prinzip einen Verantwortlichen und bleiben seine Ausnahmen sichtbar, ziehen die Teams es schon bei der Vorbereitung ihrer Optionen heran.

Das Inventar der Anwendungen und Funktionen

DORA verlangt von Finanzunternehmen, ihre IKT-gestützten Unternehmensfunktionen zu ermitteln, zu klassifizieren und angemessen zu dokumentieren (Artikel 8). Die Pflicht erfasst auch die Informations- und IKT-Assets, die diese Funktionen unterstützen, sowie deren Abhängigkeiten. Die Klassifizierung wird mindestens einmal jährlich überprüft; die Inventare werden regelmäßig und bei jeder wesentlichen Änderung aktualisiert.

Das Informationsregister nach Artikel 28 DORA ist ein anderes Dokument. Es betrifft die vertraglichen Vereinbarungen über IKT-Dienstleistungen, die IKT-Drittdienstleister erbringen. In ArchiLU entsteht es als regulatorischer Bericht aus derselben Kette.

NIS2 zählt das Management von Anlagen zu den Risikomanagementmaßnahmen im Bereich der Cybersicherheit (Artikel 21). In beiden Fällen bildet das Anwendungsinventar die Grundlage. Es bleibt aktuell, wenn es das Modell ist, das Architekten, Finanzen und Risikomanagement bereits nutzen. Für jedes Audit neu aufgebaut, wird es wieder zur Tabelle, die es ersetzen sollte. In ArchiLU liegen Anwendungen und Funktionen im selben Repository:

• Verantwortliche Person, Kritikalität, Lebenszyklus und Anbieter jeder Anwendung.
• Ein Funktionskatalog mit der Kritikalität nach DORA, der verantwortlichen Person und den Anwendungen, die jeder Funktion dienen.
• Die Verbindungen jeder Anwendung zu ihren Fähigkeiten, Prozessen, Schnittstellen, Technologien und Verträgen.
• Objekte ohne verantwortliche Person, die sichtbar bleiben, und alle zwölf Monate eine Aufgabe an jede verantwortliche Person, ihre Objekte zu bestätigen.

IKT-Abhängigkeiten und Expositionsanalyse

Die eigenen Anwendungen zu kennen genügt nicht. Eine Resilienzprüfung fragt, was stillsteht, wenn eine Komponente, ein Dienstleister oder ein Datenfluss ausfällt. DORA verlangt, die Verbindungen und Interdependenzen zwischen den Assets zu erfassen und die Prozesse zu ermitteln, die von IKT-Drittdienstleistern abhängen (Artikel 8).

In ArchiLU beginnt die Kette bei einer kritischen oder wichtigen Funktion. Sie folgt den verknüpften Prozessen und Fähigkeiten, den Anwendungen, dann den dokumentierten IKT-Diensten, Anbietern und Verträgen. Eine fehlende Verbindung bleibt sichtbar. Der Steckbrief der Funktion zeigt zudem die bereitgestellte Instanz mit Wiederherstellungszeit und tolerierbarem Verlust sowie den Ausstiegsplan der Anwendung.

Die Expositionsanalyse beginnt bei einem Dienstleister und führt zu den Prozessen und den kritischen oder wichtigen Funktionen, die von ihm abhängen. Sie berechnet ihre Befunde: Konzentration, Obsoleszenz, kritische Objekte ohne Verantwortliche, offene Ausnahmen. Jeder Befund führt zu einer Anfrage, zu einem Risiko oder zu einer Entscheidung des Boards.

Die von DORA verlangte Resilienzstrategie legt die Risikotoleranzschwelle für IKT-Risiken fest und untersucht die Toleranz gegenüber den Auswirkungen von IKT-Störungen (Artikel 6). Vor einer Vereinbarung, die eine kritische oder wichtige Funktion unterstützt, bewertet das Unternehmen zudem das Konzentrationsrisiko (Artikel 28 und 29). Diese Beurteilungen bleiben beim Unternehmen; die Kette dokumentiert ihren Gegenstand.

Wo DORA und NIS2 ansetzen

Die Verordnung (EU) 2022/2554, kurz DORA, gilt seit dem 17. Januar 2025 für die in ihrem Artikel 2 genannten Finanzunternehmen. Sie regelt das IKT-Risikomanagement, die Meldung schwerwiegender IKT-bezogener Vorfälle, das Testen der Resilienz und das Risiko durch IKT-Drittdienstleister. Sie schafft zudem einen Überwachungsrahmen für kritische IKT-Drittdienstleister.

Die Richtlinie (EU) 2022/2555, kurz NIS2, gilt für wesentliche und wichtige Einrichtungen in zahlreichen Sektoren. Die Mitgliedstaaten mussten sie bis zum 17. Oktober 2024 umsetzen. Ein Finanzunternehmen kann als wesentliche oder wichtige Einrichtung eingestuft sein. DORA gilt dann als sektorspezifischer Rechtsakt im Sinne von Artikel 4 NIS2 (Artikel 1 Absatz 2 DORA).

Beide Texte nehmen das Leitungsorgan in die Pflicht. Nach DORA legt es den IKT-Risikomanagementrahmen fest, genehmigt und überwacht ihn und ist für seine Umsetzung verantwortlich (Artikel 5). Nach NIS2 billigen die Leitungsorgane die Risikomanagementmaßnahmen, überwachen ihre Umsetzung und können verantwortlich gemacht werden (Artikel 20).

DORA verlangt zudem, dass die Resilienzstrategie die IKT-Referenzarchitektur und die für bestimmte Geschäftsziele nötigen Änderungen erläutert (Artikel 6 Absatz 8). In ArchiLU trägt jede Landschaft den Ist-Zustand, das Zielbild und eine datierte Roadmap. Die Lücke gibt jedem Element sein Arbeitspaket und seine Fälligkeit.

Ein gepflegtes Inventar, erfasste Abhängigkeiten, begründete Entscheidungen und ein Prüfpfad sind das Material einer Resilienz- oder Aufsichtsprüfung. Die Checkliste zu DORA und NIS2 hilft, die zu erstellende Architekturdokumentation zu erfassen.

BIAN für Banken und eine Governance, die trägt

Eine Bank kann sich zudem auf eine Branchenreferenz stützen. BIAN, das Banking Industry Architecture Network, veröffentlicht Referenzmodelle; seine Service Landscape ordnet Service Domains. In ArchiLU wird ein Branchenmodell, BIAN für Banken, über die Arbeitsmappe geladen. Die Fachverantwortlichen prüfen anschließend jede Zuordnung zu ihren Fähigkeiten und Anwendungen.

Governance hält, wenn sie den bestehenden Rhythmen folgt: Budgetzyklen, Vertragsverlängerungen, Transformationsmeilensteine. Board, Entscheidungen, Prinzipien und Inventar hängen daran, ohne ein separates Konformitätsprojekt, das um die Aufmerksamkeit der Teams konkurriert.

In ArchiLU gehören die DORA-Kette und die Expositionsanalyse zum Angebot APM & Risk. Architekturdossiers und Board gehören zum Angebot Enterprise Architecture, das APM & Risk einschließt. Der Testmonat läuft auf Ihrer eigenen Instanz.