Die große Überschneidung: Ein gemeinsamer Kontrollsatz für DORA, NIS2 und AI Act

Die meisten Organisationen machen denselben Fehler, wenn mehrere Regelwerke gleichzeitig relevant werden: Sie bauen drei Programme. DORA bekommt ein Projekt, NIS2 bekommt ein Projekt, der EU AI Act bekommt ein Projekt. Jedes Projekt erstellt Anforderungen, Maßnahmenlisten, Richtlinien, Reportings. Und jedes Projekt hat gute Gründe, weil jede Anforderung „irgendwie“ stimmt. Das Ergebnis ist trotzdem oft enttäuschend: viel Arbeit, viel Dokumentation, aber die Betriebsfähigkeit wird nicht proportional besser. Noch schlimmer: Teams beginnen zu „optimieren“, indem sie das jeweils nächste Audit bedienen, statt das System als Ganzes stabiler zu machen.

Die Abkürzungen sind unterschiedlich, aber die Realität dahinter ist erstaunlich ähnlich. Alle drei Rahmenwerke wollen im Kern, dass Sie Entscheidungen nicht dem Zufall überlassen. Sie wollen Verantwortlichkeiten, die im Alltag funktionieren. Sie wollen, dass Störungen beherrscht werden können. Sie wollen, dass kritische Abhängigkeiten gesteuert werden. Und sie wollen, dass Sie das belegen können – nicht durch schöne Texte, sondern durch eine nachvollziehbare Spur.

Der Trick ist deshalb nicht, „DORA umzusetzen“ oder „NIS2 umzusetzen“ oder „AI Act umzusetzen“. Der Trick ist, ein gemeinsames Kontrollsystem zu bauen, das diese Rahmenwerke bedient, ohne sich zu vervielfachen. Ein Kontrollsystem, das in der Sprache des Betriebs formuliert ist und als Nebenprodukt prüfbar ist. Genau das meine ich mit „gemeinsamer Kontrollsatz“: ein Kern an Kontrollen, die Sie wirklich leben – und die so formuliert sind, dass sie gleichzeitig DORA, NIS2 und AI Act adressieren. Dazu kommen nur noch wenige Ergänzungen je Rahmenwerk. Alles andere ist Doppelarbeit.

Dieser Beitrag zeigt, wie Sie diese große Überschneidung praktisch nutzen. Nicht als riesige Mapping-Tabelle, sondern als Steuerungslogik: Welche Kontrollen sind der gemeinsame Kern? Wie formuliert man sie so, dass sie nicht abstrakt bleiben? Wie koppelt man sie an echte Decision Points? Und wie sorgt man dafür, dass Evidenz im Prozess entsteht, statt später mühsam gesammelt zu werden?

Warum „ein gemeinsamer Kontrollsatz“ in der Praxis funktioniert

Kontrollen werden oft wie einzelne Häkchen behandelt: „Kontrolle X erfüllt, Kontrolle Y erfüllt.“ In der Realität wirken Kontrollen aber nur als System. Sie greifen an kritischen Pfaden: Incident-Pfad, Change-Pfad, Provider-Pfad, Daten-/Modell-Pfad (bei KI), Recovery-Pfad. Wenn diese Pfade stabil sind, ist die Organisation resilient und auditfähig. Wenn diese Pfade brüchig sind, hilft Ihnen auch eine lange Liste formaler Kontrollen nicht, weil sie die entscheidenden Stellen nicht absichert.

DORA zwingt viele Organisationen, diese Pfade stärker end-to-end zu denken. NIS2 legt den Fokus breiter auf Governance, Sicherheitsmaßnahmen und Lieferkette. Der EU AI Act bringt zusätzlich die Perspektive des Modell- und Datenlebenszyklus, Transparenz und Risikoklassifizierung hinein. Aber die Mechanik dahinter ist bei allen drei gleich: Es braucht klare Verantwortlichkeiten, klare Entscheidungspunkte, klare Nachweise.

Ein gemeinsamer Kontrollsatz funktioniert deshalb, weil er nicht „regelwerkspezifisch“ ist, sondern „betriebsfähig“. Er beschreibt, was Ihr Unternehmen ohnehin können muss, wenn es digitale Leistungen sicher betreiben will – unabhängig davon, welches Regelwerk gerade im Vordergrund steht.

Der häufigste Irrweg: Mapping ohne Betrieb

Viele Unternehmen starten mit großen Mapping-Tabellen: DORA-Anforderung → ISO-Kontrolle → NIS2-Maßnahme → AI-Act-Artikel. Das kann für Ordnung hilfreich sein, aber es löst selten das Kernproblem. Denn eine Tabelle zeigt nicht, ob eine Kontrolle im Alltag funktioniert. Sie zeigt nur, dass Sie sie irgendwo zugeordnet haben.

Prüfer und Revisionen sind dafür inzwischen zu erfahren. Sie steigen sehr schnell aus Mapping-Diskussionen aus und fragen stattdessen: „Zeigen Sie mir einen Fall.“ Ein Incident. Eine Übung. Ein Provider-Review. Ein KI-Use-Case, der klassifiziert und freigegeben wurde. Eine wesentliche Änderung. Genau dort entscheidet sich, ob Ihr System trägt. Deshalb sollte der gemeinsame Kontrollsatz nicht als „Mapping-Produkt“ entstehen, sondern als „Betriebsprodukt“: Kontrollen werden so definiert, dass sie in realen Abläufen Evidenz erzeugen.

Wie man einen gemeinsamen Kontrollsatz sinnvoll schneidet

Der sinnvolle Schnitt ist nicht „alle Kontrollen, die in allen Regelwerken vorkommen“. Der sinnvolle Schnitt ist: Kontrollen, die kritische Pfade absichern und dadurch mehrere Anforderungen gleichzeitig erfüllen. In der Praxis lassen sich diese Kontrollen in wenige Cluster bündeln. Das ist bewusst eine leichte Struktur, damit es steuerbar bleibt.

Cluster 1: Governance & Verantwortung
Hier geht es darum, dass Verantwortung nicht nur beschrieben ist, sondern in Entscheidungen sichtbar wird. Ein gemeinsamer Kern besteht typischerweise aus Kontrollen wie: klarer Owner pro kritischem Service, definierte Entscheidungspunkte (z. B. Major Incident, externe Kommunikation, Risikoakzeptanz), Stellvertretungslogik, regelmäßiger Management-Review mit dokumentierten Entscheidungen und Prioritäten. Das ist DORA-relevant (Steuerung, Evidenz), NIS2-relevant (Managementverantwortung, Organisation), und AI-Act-relevant (Governance-Struktur, Verantwortlichkeit für KI-Systeme).

Cluster 2: Risiko als Entscheidungsinstrument
Ein Register allein reicht nicht. Der gemeinsame Kontrollsatz muss sicherstellen, dass Risiko an echte Decision Points gekoppelt ist: Go-Live kritischer Services, wesentliche Provider-Änderungen, Ausnahmen vom Standard, KI-Klassifizierung und Freigabe, Major Incidents. Diese Kopplung bedient DORA (IKT-Risiken, Resilienz), NIS2 (Risiko- und Maßnahmenmanagement) und AI Act (risikobasierte Einordnung, Pflichten ableiten).

Cluster 3: Incident-Fähigkeit end-to-end
Hier liegt die größte Überschneidung, weil alle drei Rahmenwerke letztlich Betriebsfähigkeit unter Störung wollen. Der gemeinsame Kontrollsatz sollte nicht „Incident-Prozess existiert“ sagen, sondern die Kette absichern: Erkennung, Einstufung, Auswirkung, Entscheidungspunkte, Kommunikation, Dienstleistereinbindung, Maßnahmen, Lernen. Für KI kommt als Ergänzung oft ein spezifischer Punkt hinzu: Umgang mit KI-Fehlverhalten (Stop/Limit/Fallback). Aber die Grundlogik ist identisch.

Cluster 4: Drittparteiensteuerung als Takt
DORA und NIS2 betonen Lieferkette stark, AI Act erweitert die Perspektive auf KI-Lieferkette (Anbieter, Modelle, Subprozessoren). Der gemeinsame Kern ist hier: Kritikalität definieren, Owner festlegen, wiederkehrender Review-Takt, Eskalationswege testen, relevante Änderungen bewerten, Minimalfallback/Exit-Logik. Wenn dieser Takt steht, erfüllen Sie sehr viel auf einmal – und vermeiden, dass jedes Programm ein eigenes Lieferantenformular erfindet.

Cluster 5: Change- und Release-Disziplin auf kritischen Pfaden
Viele Störungen sind „hausgemacht“ durch Änderungen. Der gemeinsame Kontrollsatz sollte sicherstellen: Risiko-Check vor Änderungen an kritischen Services, klare Freigabespur, Rollback/Notbetrieb, und Nachweis, dass die Änderung kontrolliert war. Für KI-Änderungen ist das besonders wichtig, weil Modelle und Daten sich schnell ändern können. DORA sieht das als Resilienzthema, NIS2 als Sicherheits- und Betriebsfähigkeit, AI Act als Lifecycle-/Änderungskontrolle im Einsatzkontext.

Cluster 6: Evidenz als Betriebsgedächtnis
Hier wird es sehr konkret: Ein gemeinsamer Kontrollsatz funktioniert nur, wenn Nachweise nicht „überall“ liegen. Sie brauchen eine Paketlogik: Incident-Paket, Provider-Review-Paket, Test-/Übungspaket, Change-Paket, KI-Akte (Steckbrief, Klassifizierung, Tests, Betrieb, Änderungen). Diese Pakete sind die Übersetzung der Kontrollen in prüfbare Realität. Ohne Pakete wird jeder Audit eine Suchaktion.

Wie ein gemeinsamer Kontrollsatz formuliert sein muss, damit er lebt

Viele Kontrollen scheitern, weil sie als abstrakte Sätze formuliert sind. „Es existiert ein Prozess.“ „Es werden regelmäßige Reviews durchgeführt.“ „Es wird ein Register gepflegt.“ Solche Sätze sind im Audit leicht angreifbar, weil sie sofort die Gegenfrage provozieren: „Wie genau? Wie oft? Von wem? Wo ist der Nachweis?“

Ein gemeinsamer Kontrollsatz muss deshalb immer drei Dinge klar machen: Trigger, Owner, Artefakt. Das ist keine Bürokratie, sondern Praktikabilität. Trigger heißt: wann greift die Kontrolle? Owner heißt: wer verantwortet, dass sie passiert? Artefakt heißt: welcher Nachweis entsteht automatisch? Wenn diese drei Dinge klar sind, wird eine Kontrolle lebbar. Und wenn sie lebbar ist, wird sie auch prüfbar.

Ein Beispiel: Statt „Drittparteien werden regelmäßig bewertet“ formulieren Sie (sinngemäß) eine Kontrolle wie: „Für kritische Provider wird quartalsweise ein Review durchgeführt, der Leistung/Abweichungen, relevante Änderungen, Sicherheitsereignisse und offene Maßnahmen dokumentiert; der Service Owner bestätigt die Entscheidung (akzeptieren/reduzieren/eskalieren); das Review-Protokoll wird als Provider-Paket zentral abgelegt.“ Das ist nicht länger, weil man gern länger schreibt. Es ist länger, weil es entscheidungsfähig ist. Und es erzeugt Evidenz, die sich nicht wegdiskutieren lässt.

Dasselbe gilt für KI: Statt „KI-Anwendungen werden klassifiziert“ formulieren Sie (sinngemäß): „Jede KI-Anwendung wird vor produktiver Nutzung in drei Stufen eingestuft; Begründung und Mindestkontrollen werden dokumentiert; bei wesentlichen Änderungen (Datenquelle, Modell, Zweck, Nutzergruppe) erfolgt Re-Klassifizierung; die KI-Akte enthält Steckbrief, Freigabe, Testnachweis und Betriebsanker (Monitoring/Incident/Fallback) und ist im Register verlinkt.“ Damit bedienen Sie AI Act-Anforderungen, aber gleichzeitig auch DORA/NIS2-Logik, weil Sie Betriebsfähigkeit und Nachweis koppeln.

Die „große Überschneidung“ wird erst sichtbar, wenn Sie über Evidenz sprechen

Viele Organisationen unterschätzen, wie stark Evidenz die gemeinsame Klammer ist. DORA ist hier am härtesten, weil es evidenzorientiert ist. NIS2 wird in der Praxis ebenfalls evidenzorientiert, weil Aufsicht und Prüfer nachvollziehbare Umsetzung sehen wollen. Der EU AI Act wird evidenzorientiert, weil Klassifizierung, Transparenz und Lifecycle-/Änderungskontrolle ohne Nachweise nicht glaubwürdig sind.

Wenn Sie Evidenz als Paketlogik aufsetzen, entsteht automatisch ein gemeinsamer Kontrollsatz, weil die Pakete dieselben Kernfragen beantworten: Was war die Entscheidung? Wie wurde umgesetzt? Was war das Ergebnis? Was wurde verbessert? Das ist die Sprache, die alle drei Rahmenwerke verstehen.

Ein praktischer Nutzen: Wenn Ihre Evidenzpakete sauber sind, brauchen Sie weniger Richtlinien. Sie brauchen weniger separate Reportings. Und Sie vermeiden „PowerPoint-Compliance“, weil Sie immer auf reale Artefakte referenzieren können. Das erhöht auch intern die Akzeptanz, weil Teams merken, dass Nachweise nicht Zusatzarbeit sind, sondern Struktur, die Zeit spart.

Wo die echten Ergänzungen je Rahmenwerk liegen

Ein gemeinsamer Kontrollsatz heißt nicht, dass alles identisch ist. Es gibt echte Ergänzungen – aber sie sind überschaubar, wenn der Kern steht.

Bei DORA sind Ergänzungen typischerweise: spezifische Erwartungen an Resilienztests, teils strengere Evidenzanforderungen, besondere Tiefe bei Drittparteiensteuerung im Finanzkontext und bei testingbezogenen Nachweisen.

Bei NIS2 sind Ergänzungen typischerweise: Breite der Sicherheitsmaßnahmen, organisatorische Erwartungen und der Fokus auf Managementverantwortung sowie sektorale Unterschiede in der Umsetzung.

Beim EU AI Act sind Ergänzungen typischerweise: risikobasierte Klassifizierung, Transparenzanforderungen, Anforderungen an Daten-/Modell-Lifecycle, Dokumentation spezifischer KI-Eigenschaften, und je nach Rolle in der Lieferkette zusätzliche Pflichten (z. B. gegenüber Anbietern oder beim Einkauf).

Wenn Ihr gemeinsamer Kontrollsatz jedoch die kritischen Pfade abdeckt, bleiben diese Ergänzungen wirklich Ergänzungen – statt drei parallele Programme zu werden.

Was sich im Alltag ändert, wenn der gemeinsame Kontrollsatz steht

Das wichtigste Ergebnis ist nicht „Compliance“, sondern Ruhe. Die Organisation diskutiert weniger über Begriffe und mehr über Entscheidungen. Release-Freigaben werden klarer, weil Risiko-Checks standardisiert sind. Incidents werden schneller geführt, weil Entscheidungspunkte und Kommunikationswege klar sind. Providersteuerung wird belastbarer, weil es einen Rhythmus gibt. KI-Nutzung wird steuerbar, weil Register und Akte nicht nur Listen sind, sondern Entscheidungsspuren. Audits werden kürzer, weil Evidenzpakete existieren, statt dass man „alles zusammenkramen“ muss.

Und noch etwas: Ein gemeinsamer Kontrollsatz reduziert die Wahrscheinlichkeit von Schattenwelten. Wenn Governance flach und nachvollziehbar ist, nutzen Teams sie eher. Wenn Governance dreifach existiert, wird sie umgangen. Das ist keine Moralfrage, sondern eine Alltagslogik: Menschen wählen den Weg, der ihren Job ermöglicht. Ein gemeinsamer Kontrollsatz macht den richtigen Weg einfacher.

Wenn Sie aktuell DORA, NIS2 und AI Act parallel „irgendwie“ bearbeiten, ist das kein Vorwurf. Es ist der Normalzustand in vielen Unternehmen. Der entscheidende Schritt ist, die Programme aus der Tabellenwelt herauszuholen und in ein gemeinsames Betriebssystem zu übersetzen: Trigger, Owner, Artefakt – entlang der kritischen Pfade. Dann wird aus drei Baustellen ein steuerbares System. Und dann wird die Überschneidung nicht nur sichtbar, sondern nutzbar.