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:

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:

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:

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:

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:

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):

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:

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:

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:

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:

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:

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

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.