Wenn in der Praxis über DORA gesprochen wird, geht es oft zuerst um interne Themen: Prozesse, Rollen, Tests, Meldungen, Nachweise. Das ist nachvollziehbar, weil man dort „direkt“ gestalten kann. Der größte Hebel für die operative Stabilität liegt aber in vielen Unternehmen an einer anderen Stelle: bei externen Dienstleistern. Nicht, weil Dienstleister per se schlecht wären – im Gegenteil. Sondern weil moderne IT-Landschaften ohne Provider, SaaS, Plattformen, Rechenzentren, Integrationspartner und spezialisierte Services kaum noch sinnvoll betrieben werden können. Genau dadurch entsteht jedoch ein Risiko, das in Audits und im Ernstfall besonders sichtbar wird: Ihr Dienstleister kann Ihr größtes Ausfallrisiko sein – und zwar selbst dann, wenn Ihre interne Organisation sauber aufgestellt ist.

Third-Party Risk klingt als Begriff schnell nach „Vendor Management“. In der Realität ist es viel konkreter: Es geht um Abhängigkeiten, um Reaktionsfähigkeit, um Eskalationswege, um das Zusammenspiel im Incident – und um die Frage, ob Sie als Kunde die Steuerung wirklich in der Hand haben. DORA verschärft diese Perspektive, weil es nicht reicht, einen Vertrag zu haben oder einmal im Jahr eine Bewertung auszufüllen. DORA zielt auf laufende Beherrschung: wiederholbar, nachvollziehbar und im Betrieb sichtbar.

Der Moment, in dem DORA plötzlich „real“ wird, ist selten das Kick-off, selten das erste Requirements-Dokument und auch nicht die hundertste Folie. Real wird DORA meistens dann, wenn jemand fragt: „Zeigen Sie mir das bitte.“ Nicht: „Erklären Sie mir, wie Sie es machen.“ Nicht: „Schicken Sie mir Ihr Konzept.“ Sondern: „Zeigen Sie mir konkret den Nachweis, dass es im Betrieb funktioniert.“

Genau hier trennt sich in der Praxis die Spreu vom Weizen. Viele Organisationen haben nach ein paar Monaten DORA-Projektlaufzeit sehr ordentliche Unterlagen: Policy-Stacks, Prozessbeschreibungen, Rollenmodelle, Gremienstrukturen, Kontrolldatenbanken. Und trotzdem entsteht im Audit Stress. Warum? Weil Prüfer nicht auf der Suche nach „viel Material“ sind, sondern nach einer belastbaren Spur: Entscheidung → Umsetzung → überprüfbarer Nachweis. Wenn diese Spur nicht klar und schnell auffindbar ist, wirkt selbst gute Arbeit plötzlich unfertig.

NIS2 bringt viele Organisationen in eine vertraute Komfortzone: Anforderungen lesen, Maßnahmen ableiten, Dokumente erstellen, Checklisten abhaken. Das fühlt sich nach Fortschritt an – und ein Teil davon ist auch wirklich notwendig. Trotzdem gibt es ein Problem, das in der Praxis häufig erst dann sichtbar wird, wenn es ernst wird: „Compliant“ heißt nicht automatisch „resilient“.

Compliance beantwortet primär die Frage: „Haben wir Anforderungen umgesetzt?“ Resilienz beantwortet eine andere Frage: „Können wir Störungen aushalten, schnell reagieren und den Betrieb stabil wiederherstellen – und zwar unter Stress, mit echten Abhängigkeiten und begrenzten Ressourcen?“ Zwischen beiden liegt eine Lücke, die Sie nicht mit noch mehr Papier schließen, sondern nur mit funktionierenden Abläufen.

Es gibt zwei typische Reaktionen, wenn der EU AI Act im Unternehmen „landet“: Entweder wird er als reines Rechtsprojekt verstanden („Jura klärt, IT liefert irgendwann nach“). Oder er wird als Technikthema gesehen („Wir machen ein KI-Register, dann passt das schon“). Beide Perspektiven greifen zu kurz. Der EU AI Act ist vor allem eine Steuerungsfrage: Wer entscheidet was, nach welchen Kriterien, mit welchem Nachweis – und wie bleibt das auch dann tragfähig, wenn aus 5 KI-Anwendungen plötzlich 50 werden?

In diesem Beitrag geht es nicht um Paragrafen-Exegese. Es geht um einen praktikablen Weg zu einer Governance-Struktur, die schnell startfähig ist und dabei nicht beim ersten Wachstumsschub auseinanderfällt. „Schnell“ heißt hier nicht oberflächlich, sondern: mit wenigen Bausteinen so viel Ordnung schaffen, dass Sie Risiken einordnen, Entscheidungen treffen und Nachweise liefern können – ohne Ihr Unternehmen mit Bürokratie zu blockieren.

DORA klingt auf dem Papier oft klar: Risiken rund um digitale Dienstleistungen beherrschbar machen, Ausfälle reduzieren, Nachweise liefern. In der Umsetzung zeigt sich aber ein Muster, das ich in Projekten immer wieder sehe: Im Alltag wirkt vieles „irgendwie geregelt“ – bis ein Audit oder eine Prüfung fragt: Wo ist das belastbar belegt? Dann tauchen Lücken auf, die vorher niemand auf dem Radar hatte.

Dieser Beitrag ist bewusst praktisch gehalten. Er beschreibt zehn typische Stolperfallen, die meist erst dann schmerzhaft werden, wenn jemand von außen den Finger in die Wunde legt – Revision, Prüfer, Aufsicht, Kunden oder ein großer Dienstleister im Vertragsgespräch. Zu jeder Stolperfalle finden Sie: ein kurzes Erkennungszeichen, warum das passiert, und was Sie konkret tun können, ohne das Unternehmen mit zusätzlichen Programmen zu überfrachten.