DORA-Testing: Wie Sie TLPT-Logik pragmatisch vorbereiten, ohne sich zu verbrennen

Vorschlag Veröffentlichungsdatum: 15/09/2025 09:21

Tags: DORA, Resilienztests, TLPT, Krisenfähigkeit, Nachweise

Viele Unternehmen haben ein Risikoregister. Manche haben sogar ein sehr gutes: sauber strukturiert, regelmäßig aktualisiert, mit Kategorien, Bewertungen, Maßnahmen, Verantwortlichen und hübschen Heatmaps. Und trotzdem bleibt im Alltag oft ein irritierender Eindruck: Das Register ist da – aber Entscheidungen passieren woanders. Projekte laufen, Provider werden gewechselt, Releases gehen live, Incidents eskalieren, Budgets werden gekürzt oder umgeschichtet. Und das Risikoregister? Es wird gepflegt, berichtet, zur Kenntnis genommen. Aber es steuert nicht.

Das ist keine Seltenheit, sondern eher der Normalfall. Nicht, weil Risk Management unwichtig wäre, sondern weil es häufig als Dokumentationsdisziplin betrieben wird. Dann entsteht ein Artefakt, das „vollständig“ wirken soll, aber im entscheidenden Moment zu wenig liefert: eine klare Priorisierung, eine begründete Entscheidung, eine spürbare Veränderung im Betrieb. Genau an dieser Stelle lohnt sich ein Perspektivwechsel. Ein Risikoregister ist nicht das Ziel. Es ist nur ein Rohstoff. Das Ziel ist, aus Risiko eine Entscheidungsfähigkeit zu machen – und zwar so, dass man im Alltag schneller, klarer und nachvollziehbarer steuern kann.

AI Governance ist gerade dabei, zwei typische Extreme zu produzieren. Das erste Extrem ist „wir machen erst mal gar nichts, bis alles klar ist“. Das zweite Extrem ist „wir bauen sofort ein großes Programm, das alles abdeckt“. Beides führt in der Praxis selten zu einem stabilen Ergebnis. Das erste Extrem endet meistens in Schattennutzung und hektischer Nacharbeit. Das zweite endet oft in Überkomplexität, Widerstand und Workarounds. Die brauchbare Mitte ist unspektakulärer: Sie definieren ein Minimum, das sofort handlungsfähig macht – und ein Maximum, das sinnvoll ist, wenn Volumen, Kritikalität und externe Anforderungen steigen.

Der Trick dabei ist, AI Governance nicht als neues „Thema“ zu behandeln, sondern als Erweiterung dessen, was gute Organisationen ohnehin tun: Entscheidungen vorbereiten, Risiken steuern, Änderungen kontrollieren, Nachweise so ablegen, dass sie im Ernstfall und im Audit funktionieren. KI bringt dabei nur eine neue Dynamik hinein: Systeme verändern sich schneller (Modelle, Daten, Features), ihre Wirkung ist oft schwerer intuitiv einzuschätzen, und viele Bausteine liegen außerhalb Ihres direkten Einflusses (Cloud-Services, Anbieter, Modelle von Dritten). Genau deshalb braucht es eine Governance, die nicht nur „schön“ aussieht, sondern im Alltag belastbar ist.

NIS2 wird in vielen Unternehmen gerade mit hohem Tempo umgesetzt. Das ist verständlich: Die Erwartungshaltung ist groß, der Druck ist real, und niemand möchte in eine Situation kommen, in der man im Ernstfall oder in einer Prüfung erklären muss, warum etwas „noch nicht fertig“ ist. Genau hier entsteht aber ein typisches Nebenproblem, das ich in der Praxis immer wieder sehe: Nachweise werden zu früh als „Dokumentationsprojekt“ verstanden. Dann wächst die Menge an Artefakten schnell – aber die Prüfbarkeit wird nicht automatisch besser. Im Gegenteil: Wenn zu viele Dinge als Nachweis gelten sollen, wird es unklar, was wirklich zählt. Und Unklarheit ist im Audit der schnellste Weg zu Nachforderungen.

Dieser Artikel hilft Ihnen, die NIS2-Nachweispflichten pragmatisch zu sortieren. Nicht nach dem Motto „möglichst viel sammeln“, sondern nach dem Prinzip: Welche Artefakte belegen im Zweifel wirklich, dass Ihr Betrieb sicher und handlungsfähig ist? Und welche Artefakte sehen zwar ordentlich aus, bringen Ihnen aber wenig, weil sie weder Entscheidungen stützen noch die Umsetzung im Alltag nachvollziehbar machen?

Operational Resilience klingt wie ein großes Programm. In der Praxis entscheidet sich aber sehr vieles an einer erstaunlich einfachen Frage: Wie schnell wird aus einem technischen Problem eine klare Entscheidung – und wie schnell wird aus dieser Entscheidung ein koordinierter Ablauf? Genau an dieser Stelle sind Incident-Prozesse in vielen Organisationen zu langsam. Nicht, weil Menschen nicht reagieren. Sondern weil sie im entscheidenden Moment zu viel klären müssen, was eigentlich längst geklärt sein sollte.

Wenn DORA ernst genommen wird, verschiebt sich der Blick vom „Incident als IT-Aufgabe“ hin zu „Incident als Betriebsfähigkeit“. Das ist kein kosmetischer Unterschied. Ein IT-Team kann einen Fehler beheben und trotzdem kann das Unternehmen als Ganzes langsam sein: weil Auswirkung und Priorisierung unklar bleiben, weil Kommunikation zögert, weil Dienstleister nicht sauber eingebunden werden, weil Freigaben fehlen oder weil das Thema Wiederherstellung erst dann strukturiert wird, wenn bereits wertvolle Zeit verloren ist. In Audits zeigt sich das häufig in einem typischen Muster: Prozesse sind beschrieben, Tickets existieren, aber die End-to-end-Kette ist brüchig. Und wenn die Kette brüchig ist, wird Geschwindigkeit zur Glückssache.