DORA in der Praxis: 10 Stolperfallen, die erst im Audit sichtbar werden

DORA in der Praxis: 10 Stolperfallen, die erst im Audit sichtbar werden

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.

Warum diese Stolperfallen so häufig sind

Viele Organisationen starten DORA mit einer „Projektlogik“: Man sammelt Anforderungen, erstellt Dokumente, schließt Lücken. Das ist nicht falsch – aber es reicht nicht. DORA verlangt vor allem Betriebsfähigkeit: Prozesse, Rollen, Tests, Meldungen und Nachweise müssen nicht nur existieren, sondern wiederholbar funktionieren. Genau an der Schnittstelle zwischen Papier und Betrieb entstehen die meisten Überraschungen.

Die gute Nachricht: Die meisten Stolperfallen lassen sich vermeiden, wenn Sie früh drei Fragen konsequent stellen:

• Wer entscheidet? (und ist das in der Praxis klar)
• Wer tut? (und kann das unter Zeitdruck wirklich leisten)
• Woran erkennt man, dass es getan wurde? (ohne „Belege-Sammeln“ als Parallelwelt)

Stolperfalle 1: „Wir haben Richtlinien“ – aber keine prüfbare Umsetzung

Typisches Audit-Signal: Es gibt saubere Dokumente, doch auf Nachfrage zeigt niemand konkrete Beispiele aus dem Betrieb. Oder es gibt Beispiele, aber sie sind nicht eindeutig einer Anforderung, einem Prozessschritt und einer Verantwortlichkeit zuordenbar.

Warum das passiert: Richtlinien werden oft als Ziel verstanden. Im Audit sind sie nur der Startpunkt. Prüfer wollen sehen, wie die Regel im Alltag wirkt – und wie Abweichungen erkannt und behandelt werden.

Pragmatische Gegenmaßnahme: Bauen Sie pro „kritischer“ Richtlinie eine Mini-Kette aus drei Artefakten auf:

• eine konkrete Arbeitsanweisung (1 Seite, kein Roman)
• ein Nachweisbeispiel aus dem Betrieb (Ticket, Protokoll, Report)
• ein Kontrollpunkt, der regelmäßig prüft, ob das wirklich passiert (z. B. monatlicher Stichproben-Check)

So entsteht eine „prüfbare Spur“, ohne dass Sie gleich ein großes Tool-Projekt starten müssen.

Stolperfalle 2: Kritische Services sind unklar – oder je nach Bereich unterschiedlich definiert

Typisches Audit-Signal: IT, Fachbereich und Einkauf nennen unterschiedliche Services als kritisch. Oder die Liste ist extrem lang („zur Sicherheit alles“), sodass sie im Ernstfall nicht handhabbar ist.

Warum das passiert: „Kritisch“ wird im Alltag gern mit „wichtig“ verwechselt. DORA zielt aber auf Services, deren Ausfall wesentliche Auswirkungen hätte – und zwar messbar.

Pragmatische Gegenmaßnahme: Definieren Sie eine klare Schwelle mit wenigen Kriterien. Bewährt haben sich Kombinationen aus:

• Auswirkung auf Kunden/Markt (z. B. Zahlungsfähigkeit, Kernprozesse, Meldepflichten)
• Ausfallzeit, ab der es kritisch wird (z. B. 2h, 4h, 24h – je Prozess)
• Abhängigkeit von externen Dienstleistern (Single Points of Failure)

Wichtig ist nicht die perfekte Theorie, sondern dass alle dieselbe Sprache nutzen und die Schwelle in Entscheidungen sichtbar wird.

Stolperfalle 3: Zuständigkeiten sind formal geklärt – praktisch aber „diffus“

Typisches Audit-Signal: Rollenbeschreibungen existieren, doch bei konkreten Fragen („Wer genehmigt X? Wer entscheidet im Incident?“) entsteht eine kurze Stille – und dann ein Verweis auf „das Team“.

Warum das passiert: In vielen Organisationen sind Prozesse historisch gewachsen. Verantwortung wird im Alltag über Erfahrung und Beziehungen gesteuert – das kann funktionieren, ist aber schlecht auditierbar.

Pragmatische Gegenmaßnahme: Definieren Sie für die wichtigsten DORA-Abläufe eine Entscheidungsmatrix mit genau drei Feldern:

• Entscheidung (z. B. „Major Incident einstufen“, „Kundeninformation auslösen“)
• Entscheider (eine Rolle, nicht „Gremium“)
• Stellvertretung und Eskalationsweg (wenn Entscheider nicht erreichbar ist)

Das ist banal – aber es nimmt Prüfern den Wind aus den Segeln, weil Sie im Stressfall nicht improvisieren müssen.

Stolperfalle 4: Incident-Prozesse sind „IT-zentriert“ – und verlieren die Geschäftsrealität

Typisches Audit-Signal: Der Prozess beschreibt technische Störungen gut, aber nicht die business-relevanten Entscheidungen: Kommunikation, Priorisierung nach Auswirkungen, Einbindung von Dienstleistern, Lessons Learned.

Warum das passiert: Incident Management wurde oft für technische Verfügbarkeit gebaut. DORA fordert stärker die Perspektive „Service“ und „Auswirkung“.

Pragmatische Gegenmaßnahme: Ergänzen Sie Ihren Incident-Prozess um einen kurzen „Business-Teil“, der immer gleich abläuft:

• Auswirkungscheck (welcher Service, welche Kunden, welche Frist)
• Kommunikationsentscheidungen (intern/extern, wann, wer zeichnet ab)
• Einbindung des Dienstleisters (SLA, Ansprechpartner, Eskalation)
• Nachweisablage (wo liegt das Incident-Paket vollständig)

Wenn dieser Teil sauber läuft, sinkt der Aufwand für spätere Berichte und Prüfungen drastisch.

Stolperfalle 5: Drittparteien sind bewertet – aber nicht wirklich gesteuert

Typisches Audit-Signal: Es gibt Risikobewertungen und Vertragsakten, aber kaum Nachweise über laufende Steuerung: regelmäßige Reviews, Leistungsberichte, Sicherheits-Checks, Exit-Planung.

Warum das passiert: Lieferantenmanagement und Informationssicherheit arbeiten oft nebeneinander. Der Vertrag ist „im Einkauf“, die Kontrollen sind „bei IT/Security“, die Auswirkungen kennt der Fachbereich – und niemand bündelt es.

Pragmatische Gegenmaßnahme: Führen Sie für kritische Dienstleister einen schlanken, wiederkehrenden Takt ein (z. B. quartalsweise):

• Leistung & Verfügbarkeit (1 Seite Kennzahlen)
• Sicherheitsereignisse & Änderungen (kurzer Review)
• Offene Maßnahmen & Fristen (max. 10 Punkte)
• Risikoentscheidung (akzeptieren, reduzieren, eskalieren)

Entscheidend: Es muss ein Owner geben, der diesen Takt wirklich lebt.

Stolperfalle 6: Tests werden gemacht – aber nicht so, dass sie als Nachweis taugen

Typisches Audit-Signal: Es gibt Testaktivitäten (z. B. Notfallübungen), doch die Dokumentation ist zu dünn: kein klares Ziel, keine Kriterien, keine Ergebnisse, keine Maßnahmen, keine Nachverfolgung.

Warum das passiert: Übungen werden gern als „Training“ gesehen. Für DORA sind sie auch ein Nachweis, dass die Organisation den Ernstfall durchdacht und verbessert hat.

Pragmatische Gegenmaßnahme: Nutzen Sie für jede Übung eine feste, kurze Struktur:

• Szenario (1 Absatz, realistisch)
• Ziel (was soll nach der Übung besser sein?)
• Kriterien (woran erkennen wir Erfolg?)
• Ergebnis (kurz, ehrlich)
• Maßnahmen mit Verantwortlichen und Datum

Das lässt sich in einem Dokument ablegen und ist sofort prüfbar.

Stolperfalle 7: Änderungen passieren schnell – aber die Steuerung ist zu langsam

Typisches Audit-Signal: Neue Systeme, Cloud-Umzüge, Provider-Wechsel – doch die Risiko- und Kontrollsicht wird erst Monate später aktualisiert. Das wirkt im Audit wie „Blindflug“.

Warum das passiert: Change-Prozesse sind häufig auf technische Stabilität fokussiert. Die Governance-Aspekte hängen hinterher, weil sie als „Dokumentation“ verstanden werden.

Pragmatische Gegenmaßnahme: Ergänzen Sie in Ihrem Change-Flow zwei verpflichtende Fragen für relevante Änderungen:

• Ändert sich die Kritikalität eines Services oder die Abhängigkeit von Dienstleistern?
• Müssen Nachweise, Tests oder Kommunikationswege angepasst werden?

Damit wird Governance Teil des Change, statt Nacharbeit.

Stolperfalle 8: Meldungen und Schwellen sind nicht geübt – im Ernstfall wird diskutiert

Typisches Audit-Signal: Die Organisation kann die Meldewege beschreiben, aber nicht zeigen, dass Schwellen, Rollen und Abläufe praktisch eingeübt wurden. Im Incident würde man „erst mal sprechen“.

Warum das passiert: Meldungen wirken wie ein Sonderfall. In der Realität sind sie zeitkritisch. Diskussion kostet Minuten, Minuten kosten Vertrauen.

Pragmatische Gegenmaßnahme: Führen Sie einmal pro Halbjahr eine kurze „Tabletop“-Übung durch, nur zum Thema: Einstufung + Entscheidung + Meldung. Kein großes Szenario, 45 Minuten reichen. Das Ergebnis ist ein sauberer Nachweis und ein deutlich besseres Gefühl im Team.

Stolperfalle 9: Evidenz ist „überall“ – und damit nirgends

Typisches Audit-Signal: Nachweise liegen in E-Mail-Postfächern, lokalen Laufwerken, Ticketsystemen, SharePoint-Ordnern, Teams-Chats. Im Audit dauert jede Frage zu lange, weil niemand sicher sagen kann, wo die „finale“ Version liegt.

Warum das passiert: Im Alltag reicht „ich finde das schon“. Im Audit zählt aber Nachvollziehbarkeit: Version, Verantwortlicher, Datum, Zusammenhang.

Pragmatische Gegenmaßnahme: Legen Sie für DORA-relevante Nachweise einen sehr einfachen Standard fest:

• ein Ablageort pro Nachweisklasse (Incidents, Tests, Lieferantenreviews …)
• ein eindeutiges Benennungsschema (Datum_Service_Thema)
• ein Owner, der Stichproben macht und Ordnung hält

Das klingt trivial, ist aber einer der größten „Audit-Stress-Reducer“.

Stolperfalle 10: Management-Reporting ist zu technisch – oder zu geschönt

Typisches Audit-Signal: Reporting zeigt viele Zahlen, aber keine Entscheidungen. Oder es zeigt nur grüne Ampeln, sodass Prüfer sofort nach „unterdrückten Problemen“ fragen.

Warum das passiert: Berichtswesen wird oft als Pflicht verstanden: „Wir müssen etwas berichten“. DORA braucht aber Steuerung: „Wir entscheiden auf Basis des Berichts“.

Pragmatische Gegenmaßnahme: Machen Sie Reporting entscheidungsfähig, indem Sie pro Bericht genau drei Fragen beantworten:

• Was hat sich seit dem letzten Mal relevant verändert?
• Wo ist das Risiko gestiegen oder die Resilienz gesunken?
• Welche Entscheidung oder Priorisierung folgt daraus?

Und: Erlauben Sie „gelb“ und „rot“. Ein ehrliches Reporting wirkt reifer als ein perfektes.

Ein praktikabler 30-Tage-Plan, um die größten Lücken zu schließen

Wenn Sie nicht mit einem Mammutprogramm starten wollen, hilft ein kurzer, fokussierter Sprint. Ein Vorschlag:

• Woche 1: Kritische Services festziehen, Owner benennen, einheitliche Kriterien dokumentieren.
• Woche 2: Incident- und Meldepfad als „End-to-End“-Kette prüfen (inkl. Dienstleisterkontakt und Kommunikationsfreigaben).
• Woche 3: Evidenz-Standard festlegen (Ablage, Benennung), für zwei Nachweisklassen konsequent umsetzen.
• Woche 4: Eine Tabletop-Übung durchführen und Maßnahmenliste erzeugen – inklusive Nachverfolgung.

Das Ergebnis ist kein „fertiges DORA“, aber ein belastbarer Kern, der im Audit sichtbar wirkt.

Zum Schluss: Weniger Papier, mehr Takt

Viele DORA-Probleme sind keine Wissensprobleme. Sie sind Taktprobleme: Wer macht was wie oft – und wie wird es belegt? Wenn Sie diesen Takt sauber setzen, werden Audits ruhiger, Lieferantengespräche professioneller und Incidents weniger chaotisch.

Praxisbeispiel: Wenn „alles da“ ist – aber die Kette fehlt

Stellen Sie sich einen typischen Fall vor: Ein externer Dienstleister betreibt eine Plattform, auf der mehrere Kernprozesse laufen. Es kommt zu einem Ausfall am frühen Abend. Technisch reagiert das Team schnell, der Dienstleister liefert eine Statusmeldung, nach zwei Stunden läuft der Service wieder. Am nächsten Tag fragt die Revision: „Welche Auswirkungen hatte das? Wer hat wann entschieden, ob Kunden informiert werden? Und wo liegt das vollständige Incident-Paket?“

Was dann häufig passiert: Die technischen Tickets sind vorhanden, die Kommunikation liegt in Chat-Logs, die Entscheidung wurde telefonisch getroffen, das Management bekam eine kurze E-Mail. Alles existiert – aber nicht als zusammenhängende Akte. Im Audit wirkt das wie fehlende Steuerung, obwohl operativ gut gearbeitet wurde.

Die Lösung ist nicht „mehr Dokumentation“, sondern ein einfacher Standard: Nach dem Incident werden die relevanten Artefakte in einem Paket zusammengeführt (Ticket-Referenzen, Zeitlinie, Entscheidungspunkte, Kommunikation, Maßnahmen). Das dauert beim ersten Mal vielleicht 30 Minuten – beim zehnten Mal nur noch 10. Und genau das ist der Unterschied zwischen hektischer Nacharbeit und routiniertem Nachweis.

Mini-Checkliste: 12 Fragen, die ein Audit sehr wahrscheinlich stellt

• Welche Services sind kritisch – und warum genau diese?
• Wer ist der Owner je kritischem Service (Name/Rolle)?
• Welche wesentlichen Abhängigkeiten zu Dienstleistern bestehen?
• Wie stellen Sie sicher, dass Sicherheits- und Verfügbarkeitsanforderungen im Betrieb eingehalten werden?
• Wie wird ein schwerwiegender Vorfall eingestuft – und durch wen?
• Wie ist der Weg von der technischen Störung zur Business-Auswirkung dokumentiert?
• Welche Tests/Übungen wurden durchgeführt und was hat sich dadurch verbessert?
• Wie werden offene Maßnahmen nach Übungen und Vorfällen verfolgt und abgeschlossen?
• Wie wird sichergestellt, dass Änderungen (z. B. Provider-Wechsel) die Nachweis- und Meldewege nicht brechen?
• Wo liegen die Nachweise – und wie verhindern Sie „Schattenablagen“?
• Wie sieht Ihr Management-Reporting aus, und welche Entscheidungen wurden daraus abgeleitet?
• Was waren die drei größten Probleme im letzten Quartal – und was haben Sie konkret dagegen getan?

Wenn Sie diese Fragen ohne Sucherei und ohne „wir müssten mal schauen“ beantworten können, sind Sie auditseitig schon sehr weit.

Ein Satz, der intern hilft

Wenn Diskussionen in Ihrem Projekt zu abstrakt werden, hilft ein einfacher Leitsatz: „Was wir nicht in 3 Minuten zeigen können, gilt im Audit als nicht vorhanden.“ Das ist nicht böse gemeint – es ist die Realität externer Prüfung. Der Satz zwingt dazu, Nachweise so zu gestalten, dass sie schnell auffindbar und eindeutig sind.

Im nächsten Beitrag dieser Reihe zeige ich, wie man DORA-Nachweise so strukturiert, dass sie sowohl Steuerung als auch Prüfung bedienen – ohne eine zweite „Evidenz-Welt“ aufzubauen.