Legal hat einen Berater für DSGVO. Tech einen für NIS2. Compliance einen für DORA. Keiner weiß vom anderen.
Diese Seite beschreibt nicht die Lage — die Lage hat Regulation in a Box. Diese Seite beschreibt, wie ich daraus eine integrierte Architektur baue, statt drei Parallelwelten zu betreuen.
Diagnostisches Bild
Der Auditor fragt nach dem Gesamtbild. Drei Abteilungen liefern drei verschiedene.
Die IT zeigt ihre Systemarchitektur. Legal zeigt die Policies. Compliance zeigt die Risikobewertung. Aber sie referenzieren unterschiedliche Systeme, nutzen unterschiedliche Begriffe und beschreiben unterschiedliche Realitäten. Der Auditor sieht das in fünf Minuten.
Dieselben Themen, drei Mal gebaut.
Governance, Risikomanagement, Dokumentation, technische Maßnahmen – dieselben Themen tauchen in DORA, NIS2 und AI Act auf. Aber jedes Projekt baut seine eigene Struktur. Das Ergebnis: dreifacher Aufwand, dreifache Kosten, und Lücken, die keiner sieht.
Anforderungen
Risikomanagement
Dokumentation
Technische Maßnahmen
Drei Projekte. Ein Architekturproblem.
Was die meisten dann tun: ein weiteres Projekt aufsetzen. Und warum das scheitert.
Die typische Reaktion: noch ein Projekt. Diesmal für die „Integration“. Mit eigenem Budget, eigener Steuerung, eigenem Berater.
Der blinde Fleck: „Wir koordinieren das über ein Projektbüro.“ Aber ein PMO löst kein Architekturproblem. Es verwaltet die Parallelwelten – es ersetzt sie nicht.
Das eigentliche Problem ist das Fehlen einer gemeinsamen Struktur.
Was ich tue
Ich lese Ihre technische, organisatorische und regulatorische Realität zusammen – nicht getrennt. Ich finde die Überlappungen zwischen DORA, NIS2, AI Act und DSGVO und schließe die Lücken, die zwischen den Projekten entstanden sind.
Ich baue eine integrierte Struktur, die Legal, Tech und Regulatory gleichzeitig bedient. Einmal aufgesetzt, skaliert sie mit jeder neuen Anforderung – statt jedes Mal eine neue Parallelwelt zu erzeugen.
Wie das konkret funktioniert
Drei Werkzeuge, mit denen aus drei Projekten eine Architektur wird
Die Werkzeuge sind nicht neu — sie werden in regulierten Branchen seit Jahren angewendet. Neu ist der Anspruch, sie nicht für jede Regulierung einmal zu bauen, sondern als eine Struktur, die DORA, NIS2 und AI Act gleichzeitig bedient. Das ist der Unterschied zwischen Verwaltung und Architektur.
Eine Risikodaten-Quelle für alle drei Regulierungen
DORA verlangt ein ICT-Risikomanagement-Framework mit Asset-Register und Drittanbieter-Listing. NIS2 verlangt eine Risikoanalyse über die gesamte Lieferkette. Der AI Act verlangt ein Risiko-Klassifizierungs- und Risikomanagement-System für Hochrisiko-KI. Die fachliche Überschneidung ist groß: Assets, Abhängigkeiten, Kritikalität, Eintrittswahrscheinlichkeit, Wirkung. Drei getrennte Datenbanken bedeuten dreifache Pflege und unvermeidliche Inkonsistenzen — ein Asset wird in NIS2 als kritisch geführt, in DORA nicht; eine Drittpartei taucht im AI-Act-Provider-Register auf, im DORA-ICT-Drittanbieter-Register fehlt sie. Im Audit zeigt das fünf Minuten Inkonsistenz und drei Stunden Erklärung.
Was ich baue: Eine Risikodaten-Quelle mit gemeinsamem Schema und regulierungs-spezifischen Sichten. Das Asset wird einmal erfasst, mit allen Abhängigkeiten, Kritikalitäten und betroffenen Regulierungs-Tags. Die DORA-Sicht zieht die ICT-Drittanbieter heraus, die NIS2-Sicht die kritischen Subdienstleister, die AI-Act-Sicht die Hochrisiko-KI-Komponenten. Eine Datenpflege, drei Reports.
Ein Rollenmodell statt drei Verantwortungs-Welten
DORA Art. 5 verlangt aktive Genehmigung des ICT-Risikomanagement-Frameworks durch das Leitungsorgan. NIS2 Art. 20 verlangt persönliche Geschäftsleiter-Verantwortung mit Schulungspflicht. Der AI Act unterscheidet Provider und Deployer mit eigenen Pflichtenkatalogen. Drei getrennte Rollenmodelle bedeuten überlappende Zuständigkeiten ohne klare Eskalationswege: Wer entscheidet, wenn ein Vorfall sowohl ICT-Resilienz (DORA) als auch kritische Infrastruktur (NIS2) als auch eingesetzte KI (AI Act) berührt? In der Praxis: niemand — bis die Aufsicht fragt.
Was ich baue: Ein integriertes Governance-Layer mit benannten Rollen (Board-Sponsor, Operative Verantwortliche, ICT-Steward, AI-Steward), klaren Eskalationswegen und einer einheitlichen Sitzungs-Kadenz. Die regulatorischen Anforderungen werden zu Pflichtinhalten dieser Sitzungen — nicht zu eigenen Sitzungen. DORA-Genehmigung, NIS2-Briefing und AI-Act-Risikobewertung laufen im selben Board-Termin, mit denselben Personen, in dokumentiert nachvollziehbarer Reihenfolge.
Eine Audit-Spur, drei Prüfungsperspektiven
DORA verlangt nachweisbare aktive Genehmigung mit Datum und namentlicher Abstimmung. NIS2 verlangt dokumentierte Schulungen und Meldeketten. Der AI Act verlangt technische Dokumentation, Datenqualitäts-Belege und Konformitäts-Erklärungen. Drei Dokumentations-Logiken bedeuten drei Datenräume, drei Versionierungs-Logiken, drei Review-Zyklen — und in jedem Audit dieselbe Frage: „Können Sie mir das im Zusammenhang zeigen?“ Antwort meist: „Wir sammeln das.“
Was ich baue: Eine einheitliche Dokumentations-Logik mit Versionierung, Datums-Stempel und prüfbarer Genehmigungs-Spur. Jedes Dokument trägt seine regulatorischen Anker (DORA-Art., NIS2-§, AI-Act-Art.); jedes Genehmigungsereignis trägt Datum, Person, Beschluss-ID. Im Audit wird nicht gesammelt, sondern gefiltert: „Zeigen Sie mir alle DORA-Art.-5-Genehmigungen 2025 mit dem dazugehörigen Risikoregister-Stand zum Genehmigungs-Datum.“ Antwort: drei Klicks.
Methodik-Punkt
Diese drei Werkzeuge sind kein Tooling-Vorschlag (kein „Buy this software“). Sie sind Strukturentscheidungen, die ein Unternehmen einmal trifft — und die danach jede regulatorische Erweiterung einfacher machen, statt komplizierter. Die nächste Regulierung (Cyber Resilience Act, Critical Entities Resilience Directive, was auch immer die EU als Nächstes verabschiedet) wird zu einer zusätzlichen Sicht auf dieselbe Datenquelle, einer zusätzlichen Pflichtinhalt-Sektion in derselben Sitzung, einem zusätzlichen Ankertag in derselben Dokumentation. Nicht zu einem vierten Projekt.
Nächster Schritt
Sie erzählen, wie viele Projekte parallel laufen. Ich sage Ihnen, wo sie sich überlappen – und wie eine Struktur alle ersetzt.
Erst selbst testen: Wo Sie bei DORA stehen →
Gespräch anfragenAndere Anwendungsfelder der Methodik
- KPI-basierte Compliance-Systeme Wenn der Auditor fragt: „Können Sie es zeigen?“ →
- Zusammenarbeit: drei Welten, eine Sprache Wenn Legal, Tech und Business aneinander vorbeireden →
Anschluss in den Leistungen: Regulation in a Box (operationalisierte Architektur statt Einzelprojekten).