Architektur-Governance für DORA & NIS2: Ein praktischer Leitfaden

Governance macht Architektur vertretbar

Die meisten Teams können ein Diagramm zeichnen. Weit weniger können Monate später beweisen, warum eine Entscheidung getroffen wurde, wer sie genehmigt hat, welche Anwendungen einen kritischen Dienst stützen und wie diese Anwendungen voneinander abhängen. In dieser Lücke geraten Audits ins Stocken und werden regulatorische Prüfungen unbehaglich.

Architektur-Governance schließt die Lücke. Sie ist die Menge an Foren, Aufzeichnungen und Regeln, die Ihre Architektur über die Zeit ehrlich halten — und, als nützlicher Nebeneffekt, erzeugt sie die Dokumentation und Nachweise, die Rahmenwerke wie DORA und NIS2 erwarten. Dieser Leitfaden durchläuft die einzelnen Bestandteile und wo jede Regulierung hineinpasst.

Ein Hinweis vorab, weil er wichtig ist: nichts hierin macht Sie rechtlich konform. DORA- und NIS2-Konformität wird von Aufsichtsbehörden und Prüfern gegen Ihre organisatorischen, vertraglichen und Sicherheitsmaßnahmen bestimmt. Eine Governance-Praxis und ein Tool helfen Ihnen, zu dokumentieren und nachzuweisen, was Sie tun; sie ersetzen keine juristische, Risiko- und Sicherheitsarbeit.

Das Architecture Review Board (ARB)

Das ARB ist das Entscheidungsforum. Bedeutende Änderungen — eine neue Kernanwendung, eine größere Integration, ein Wechsel zu einem neuen Hosting-Modell — werden gegen vereinbarte Architekturprinzipien geprüft, bevor sie festgeschrieben werden. Der Sinn ist nicht Bürokratie; es geht darum, Risiko-, Sicherheits- und Resilienzbedenken aufzufangen, solange ihre Behebung noch günstig ist.

Ein ARB verdient seinen Platz nur, wenn es schlank und konsequent ist: ein klarer Umfang dessen, was geprüft werden muss, eine kleine ständige Mitgliedschaft und ein Rhythmus, der zu den Liefertakten passt, statt sie zu blockieren. Archilu unterstützt dies mit strukturierten Review- und Genehmigungs-Workflows, sodass das, was das Board entscheidet, im Moment der Entscheidung erfasst wird, nicht nachträglich rekonstruiert.

Entscheidungsaufzeichnungen: der Architektur-Trail

Eine Entscheidungsaufzeichnung erfasst für jede bedeutende Wahl den Kontext, die erwogenen Optionen, die getroffene Entscheidung und die Begründung. Gut gemacht, beantwortet sie die schwierigste Audit-Frage — „Warum ist es so?“ — ohne hektisches Wühlen in Postfächern und alten Foliensätzen.

In Archilu sind Entscheidungen erstklassige Objekte, verknüpft mit den Anwendungen, Fähigkeiten und Richtlinien, die sie betreffen. Diese Verknüpfung verwandelt eine Liste von Entscheidungen in einen navigierbaren Trail: ein Prüfer kann von einem kritischen Geschäftsdienst zu den Anwendungen, die ihn stützen, und zu den Entscheidungen, die sie geformt haben, in wenigen Klicks gelangen.

Richtlinien und Prinzipien als lebendige Constraints

Prinzipien beschreiben, wie Gutes aussieht („für personenbezogene Daten EU-gehostete Dienste bevorzugen“); Richtlinien verwandeln Prinzipien in prüfbare Regeln. Der Wert entsteht durch die Verbindung mit dem Modell: wenn eine Richtlinie mit den Anwendungen und Entscheidungen verknüpft ist, die sie regelt, sehen Sie, wo Sie konform sind und wo Sie dokumentierte Ausnahmen akzeptiert haben.

Hier wird Governance auch proaktiv statt strafend. Eine Richtlinie mit klarem Eigentümer und einer sichtbaren Ausnahmeliste ist ein Werkzeug, das Teams nutzen, um bessere Entscheidungen zu treffen, keine Checkliste, die jemand im Nachhinein durchsetzt.

Das Anwendungsregister

Das Anwendungsregister — das registre des applications — ist das Rückgrat. Es ist das maßgebliche Inventar der Anwendungen, die Ihre Geschäftsdienste stützen, jede mit einem Eigentümer, einer Kritikalitätsbewertung, Hosting-Details und einem Lebenszyklusstatus. Aufsichtsbehörden in der Finanzwelt und über die wesentlichen und wichtigen Sektoren von NIS2 hinweg erwarten, dass Sie wissen, welche IKT-Assets Ihre kritischen Funktionen tragen; das Register ist Ihre Antwort darauf.

Die entscheidende Designwahl ist, dass das Register dasselbe Modell sein sollte, das Ihre Architekten, Finanz- und Risikoteams bereits nutzen — kein paralleles Artefakt, das für jedes Audit neu aufgebaut wird. Wenn das Register lebt, bleibt es aktuell, während Anwendungen hinzugefügt, ausgemustert werden oder den Eigentümer wechseln, statt zurück in die Tabelle zu driften, die es ersetzte.

• Eigentümer, Kritikalität und Lebenszyklusstatus für jede Anwendung
• Hosting- und Datenresidenz-Attribute für Residenzfragen
• Verknüpfungen zu den Geschäftsdiensten und Fähigkeiten, die jede Anwendung stützt
• Kontinuierlich gepflegt, nicht pro Audit neu aufgebaut

IKT-Abhängigkeitskartierung

Seine Anwendungen zu kennen ist notwendig, aber nicht ausreichend. Resilienzprüfungen stellen eine härtere Frage: wenn eine bestimmte Komponente, ein Anbieter oder ein Datenfluss ausfällt, welche kritischen Dienste sind betroffen? Das zu beantworten erfordert kartierte Abhängigkeiten — zwischen Anwendungen, zwischen Anwendungen und den Dritten, die sie hosten oder speisen, und zwischen Anwendungen und den Geschäftsdiensten darüber.

Archilu behandelt diese Abhängigkeiten als Teil des Modells, sodass die Impact-Analyse eine Abfrage statt eines Workshops ist. IKT-Abhängigkeiten zu kartieren ist auch das praktische Fundament für das Denken über Impact-Toleranz und Konzentrationsrisiko, zu dem Rahmenwerke wie DORA Organisationen drängen — wiederum als Dokumentation und Analyse, nicht als Konformitätsurteil.

Wo DORA und NIS2 tatsächlich hineinpassen

DORA (der EU Digital Operational Resilience Act) zielt auf die IKT-Resilienz von Finanzunternehmen und ihren kritischen Anbietern; NIS2 weitet die Cybersicherheitspflichten über wesentliche und wichtige Sektoren aus. Beide stützen sich stark auf dieselben zugrunde liegenden Fakten: Sie müssen Ihre IKT-Assets, Ihre Abhängigkeiten und Ihre kritischen Funktionen kennen, und Sie müssen Ihre Governance zeigen können.

Architektur-Governance erzeugt genau diese Fakten. Ein gepflegtes Register, kartierte Abhängigkeiten, aufgezeichnete Entscheidungen und ein Audit-Trail sind das Rohmaterial, aus dem eine Resilienz- oder Aufsichtsprüfung schöpft. Aber — und der Hinweis wird bewusst wiederholt — DORA- und NIS2-Konformität ist eine rechtliche Feststellung, die Ihre Aufsichtsbehörde und Ihre Prüfer gegen organisatorische, vertragliche und Sicherheitskontrollen treffen. Archilu ist eine Nachweis- und Dokumentationshilfe, keine Konformitätsgarantie. Kombinieren Sie es mit Ihren juristischen, Risiko- und Sicherheitsfunktionen; die verlinkte DORA- & NIS2-Architektur-Checkliste ist ein Ausgangspunkt für die architekturseitige Dokumentation.

BIAN für Banken, und Governance dauerhaft verankern

Banken stehen vor einer zusätzlichen Dimension: ein gemeinsames Referenzmodell hilft der Governance zu skalieren. BIAN (das Banking Industry Architecture Network) bietet eine Standard-Servicedomänen-Landschaft für das Bankwesen, gepflegt von der BIAN-Vereinigung. Ihr Fähigkeits- und Anwendungsmodell an eine Referenz im BIAN-Stil auszurichten, macht das Register über Teams hinweg leichter nachvollziehbar und im Einklang mit der Art, wie Aufsichtsbehörden über Bankfunktionen denken.

Welcher Sektor auch immer: Governance hält nur, wenn sie dort lebt, wo die Arbeit geschieht. Das Muster, das funktioniert, ist, das ARB, die Entscheidungsaufzeichnungen, die Richtlinien und das Register mit Ihren bestehenden Rhythmen zu verbinden — Budgetzyklen, Anbieter-Verlängerungen, Transformations-Meilensteine — statt ein separates Konformitätsprojekt zu betreiben, das um Aufmerksamkeit konkurriert. Starten Sie dort, wo Sie stehen: Archilus kostenlose EA-Reifegradbewertung bewertet zehn Dimensionen, einschließlich Governance, und liefert in etwa zehn Minuten einen priorisierten Plan, und der verlinkte Governance-Tool-Leitfaden und die DORA- & NIS2-Checkliste verwandeln diese Prinzipien in konkrete nächste Schritte.