D
er 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.
Dieser Beitrag zeigt, wie Sie DORA-Evidenz so aufbauen, dass sie wirklich prüfbar wird – ohne eine zweite Parallelwelt zu erzeugen, in der Teams nachträglich „Belege sammeln“. Der wichtigste Gedanke dabei ist simpel: Evidenz ist kein Export aus PowerPoint. Evidenz ist ein Nebenprodukt eines sauberen Betriebs. Wenn der Betrieb gut organisiert ist, entsteht Evidenz fast automatisch. Wenn der Betrieb improvisiert, wird Evidenz zur hektischen Nacharbeit.
Bevor wir in ein Vorgehen einsteigen, lohnt sich ein kurzer Reality-Check: Was meinen Prüfer eigentlich, wenn sie „Evidenz“ sagen? In der Praxis suchen sie nach drei Eigenschaften. Erstens: Nachvollziehbarkeit – der Zusammenhang zwischen Anforderung, Prozessschritt und Artefakt ist klar. Zweitens: Integrität – es ist erkennbar, dass der Nachweis nicht „fürs Audit“ gebaut wurde, sondern aus dem Betrieb stammt (Zeitstempel, Ticketverlauf, Freigabeweg, Versionierung). Drittens: Auffindbarkeit – die Organisation kann den Nachweis ohne lange Suche liefern, idealerweise innerhalb weniger Minuten. Wenn eines dieser Elemente fehlt, wird aus einem normalen Auditgespräch schnell eine Liste an Nachforderungen.
Warum ist das so schwer? Weil viele Teams unbewusst zwei Welten aufbauen. Welt 1 ist der Betrieb: Tickets, Changes, Incidents, Provider-Calls, Chatverläufe, Reports. Welt 2 ist „Compliance“: Word-Dokumente, Excel-Listen, Folien, Maßnahmenpläne. Solange es ruhig ist, koexistieren beide Welten. Unter Auditdruck kollidieren sie. Dann beginnt das große Übersetzen: „Wo steht das in der Policy?“, „Welche Kontrolle deckt diesen Schritt ab?“, „Gibt es dazu ein Protokoll?“, „Wer hat das freigegeben?“ – und plötzlich merken alle, dass die Informationen zwar existieren, aber nicht als geschlossene Akte.
Wenn Sie DORA-Evidenz nachhaltig lösen wollen, müssen Sie nicht mehr dokumentieren. Sie müssen anders dokumentieren: so, dass Betrieb und Nachweis dieselbe Spur nutzen. Das gelingt am besten, wenn Sie sich von einer Idee lösen: der Idee, dass Evidenz eine große Sammlung ist. In der Praxis ist Evidenz keine Bibliothek, sondern eher eine Reihe kleiner, standardisierter Pakete – jeweils passend zu typischen DORA-Fragen. Ein Prüfer fragt selten „Geben Sie mir alle Nachweise“. Er fragt zielgerichtet: „Wie steuern Sie kritische Dienstleister?“, „Wie testen Sie Resilienz?“, „Wie läuft Incident Handling end-to-end?“, „Wie stellen Sie Änderungen sicher?“ Genau für diese Fragen brauchen Sie robuste Pakete.
Ein hilfreicher Einstieg ist deshalb, Evidenz nicht nach Dokumentarten zu denken („Policy“, „Protokoll“, „Report“), sondern nach Betriebsereignissen. Im Alltag wiederholt sich vieles in immer ähnlichen Mustern: Ein Incident tritt auf. Ein Change wird umgesetzt. Ein Dienstleister wird bewertet und gesteuert. Ein Test wird durchgeführt. Ein Risiko wird neu bewertet. Wenn Sie für diese Ereignisse eine Standardstruktur schaffen, wird Evidenz plötzlich greifbar. Und nebenbei wird der Betrieb ruhiger, weil weniger improvisiert werden muss.
Schauen wir auf ein sehr typisches Beispiel, das in Audits fast immer auftaucht: Incident Management. Viele Organisationen können ihren Incident-Prozess hervorragend erklären. Die Prüffrage ist aber meist nicht „Haben Sie einen Prozess?“, sondern: „Zeigen Sie mir einen Vorfall und die vollständige Spur.“ Und genau da gibt es oft Brüche. Das technische Ticket existiert, aber die Auswirkung auf den Service ist nur mündlich geklärt. Entscheidungen wurden getroffen, aber nicht sauber dokumentiert. Kommunikation fand statt, aber über mehrere Kanäle verteilt. Lessons Learned gibt es, aber ohne klare Maßnahmenverfolgung. Für die Organisation ist das Alltag – für den Prüfer ist das eine Lücke, weil die End-to-end-Kette nicht geschlossen ist.
Die pragmatische Lösung ist ein Incident-Paket. Nicht als neues Tool, sondern als Standard: Nach einem relevanten Vorfall muss es einen Ort geben, an dem in kompakter Form immer dieselben Bausteine liegen. Eine Zeitlinie (wann wurde was erkannt, wann wurde was entschieden). Die Einstufung und Begründung (warum major oder nicht). Die Auswirkungsbewertung (welcher Service, welche Nutzer, welche Fristen). Die Kommunikation (intern/extern, Freigaben, Kernbotschaften). Die technische Bearbeitung (Referenz auf Tickets). Und am Ende: Maßnahmen mit Owner und Termin. Dieses Paket kann ein kurzes Dokument sein, kann ein Tickettyp sein, kann ein definierter Ordner sein – das ist zweitrangig. Entscheidend ist: Es existiert immer in derselben Struktur. Dann wird aus „wir haben reagiert“ ein „wir können es zeigen“.
Dasselbe Prinzip lässt sich auf Drittparteien übertragen. Auch hier sind Audits selten an Ihrem Vendor-Register interessiert, sondern an der Frage: „Wie stellen Sie sicher, dass kritische Dienstleister wirklich gesteuert werden?“ Viele Organisationen haben dafür Risikoanalysen, Verträge, SLA-Kataloge. Was häufig fehlt, ist ein wiederkehrender, prüfbarer Steuerungstakt: regelmäßige Reviews, nachvollziehbare Entscheidungen, dokumentierte Eskalationen und – ganz wichtig – eine realistische Exit- oder Fallback-Logik. Im Audit wird dann sichtbar, dass die Steuerung eher „bei Bedarf“ stattfindet. Und „bei Bedarf“ ist aus Prüfersicht zu wenig, weil Bedarf häufig erst erkannt wird, wenn es bereits knallt.
Eine Evidenzstruktur, die hier gut funktioniert, ist das quartalsweise Dienstleisterpaket für jeden kritischen Provider. Es ist bewusst klein gehalten, damit es durchgehalten wird. Im Kern enthält es: den Leistungsüberblick (Verfügbarkeit, Störungen, wesentliche SLA-Abweichungen), die Sicherheits- und Änderungsübersicht (relevante Incidents, größere Releases, Zertifikatswechsel, Standortthemen), offene Maßnahmen (mit Status), sowie eine klare Entscheidung: akzeptieren, reduzieren, eskalieren. Wenn Sie diese vier Bausteine quartalsweise sauber ablegen, können Sie im Audit zeigen, dass Steuerung nicht nur geplant, sondern gelebt ist. Und Sie müssen nicht in zehn E-Mails nach dem „einen“ Review-Protokoll suchen.
Jetzt kommt die Frage, die in der Praxis alles entscheidet: Wo liegt diese Evidenz – und wie findet man sie? Hier scheitern viele Teams an einem unterschätzten Detail: Uneinheitliche Ablage. Nachweise sind oft überall: in Ticket-Systemen, SharePoint-Strukturen, lokalen Laufwerken, Teams-Chats, E-Mail-Postfächern, Provider-Portalen. Das ist verständlich, weil Betrieb so funktioniert. Für Prüfbarkeit ist es aber gefährlich. Denn Audits sind nicht geduldig. Wenn Sie zehn Minuten suchen müssen, um eine eindeutige Version zu finden, wirkt das wie fehlende Kontrolle. Selbst wenn die Kontrolle existiert.
Darum ist eine der wirksamsten DORA-Maßnahmen erstaunlich unspektakulär: eine saubere Evidenzlogik mit klaren Ablageorten. Das bedeutet nicht, dass Sie alles in ein System pressen müssen. Es bedeutet, dass Sie pro Nachweisklasse einen „finalen“ Ort definieren. Zum Beispiel: Incident-Pakete liegen in genau einem Ordnerbereich oder Tickettyp. Testnachweise liegen in einem eigenen Bereich. Drittparteien-Reviews liegen zentral und nicht in privaten Laufwerken. Und jedes Paket folgt einem Benennungsschema, das sofort verstanden wird. In der Praxis reicht häufig ein einfaches Muster wie Datum_Service_Thema. Der Effekt ist enorm: Statt zu suchen, können Teams zeigen. Und statt zu erklären, können sie belegen.
Ein zweiter unterschätzter Hebel ist die Frage der Versionierung. Audits lieben klare Stände. Wenn es zu einem Thema fünf Versionen gibt, entsteht sofort Misstrauen: Welche ist gültig? Wer hat freigegeben? Was gilt im Betrieb? Die Lösung ist nicht „nur eine Version haben“. Die Lösung ist: klare Kennzeichnung des gültigen Stands und saubere Freigabespur. Das kann in einem Dokumentmanagementsystem passieren, kann aber auch pragmatisch über ein „Final“-Label und einen definierten Owner passieren. Wichtig ist: Das Unternehmen muss den gültigen Stand ohne Diskussion benennen können.
Wenn Sie jetzt denken: „Das klingt nach zusätzlicher Arbeit“, dann ist die Gegenfrage: Wie viel Arbeit kostet heute die Nacharbeit? Viele Organisationen investieren Wochen in Auditvorbereitung, weil Evidenz nachträglich zusammengezogen wird. Wenn Sie dieselbe Energie in Standardpakete und Ablage-Logik investieren, sinkt der Aufwand im Audit drastisch – und der Betrieb wird nebenbei stabiler. Der Trick ist, nicht mehr Informationen zu produzieren, sondern Informationen so zu strukturieren, dass sie wiederverwendbar sind.
Ein guter Indikator, ob Sie auf dem richtigen Weg sind, ist die sogenannte Drei-Minuten-Regel: Alles, was Sie im Audit nicht innerhalb von drei Minuten finden und erklären können, gilt praktisch als nicht vorhanden. Das klingt hart, ist aber realistisch. Prüfer arbeiten mit Stichproben, sie prüfen Zusammenhänge und suchen nach Systematik. Wenn Sie die Systematik zeigen können, sind sie oft zufrieden – selbst wenn nicht alles perfekt ist. Wenn Sie aber nur „irgendwo“ etwas haben, wird es schnell unerquicklich.
Wie baut man diese Systematik auf, ohne die Organisation zu überfrachten? Ein pragmatischer Ansatz ist, sich auf fünf Evidenzpakete zu konzentrieren, die fast immer im Fokus stehen. Sie müssen diese Pakete nicht so nennen, aber Sie sollten sie in Ihrer Organisation als standardisierte Schubladen haben. Erstens: Incident-Paket (end-to-end). Zweitens: Test-/Übungspaket (Szenario, Ziel, Ergebnis, Maßnahmen, Re-Test). Drittens: Drittparteien-Steuerungspaket (Review, Entscheidung, Maßnahmen). Viertens: Change-/Release-Paket für kritische Services (Risiko-Check, Freigaben, Rollback-Plan, Nachweise). Fünftens: Management-Steuerungspaket (Reporting, Entscheidungen, Prioritäten). Wenn diese fünf Pakete sauber sind, wirkt Ihr DORA-System im Audit reif – selbst wenn Sie nicht jede Nebenbaustelle schon perfekt abgedeckt haben.
Der vielleicht wichtigste Perspektivwechsel betrifft das Verhältnis zwischen „Kontrolle“ und „Evidenz“. In vielen Köpfen ist Kontrolle etwas, das man ausführt, und Evidenz etwas, das man danach sammelt. In einem stabilen System ist es anders: Evidenz entsteht in der Kontrolle. Das heißt ganz konkret: Jede wichtige Kontrolle muss ein Artefakt erzeugen, das automatisch entsteht, weil es Teil des Ablaufs ist. Ein Freigabeprozess erzeugt eine Freigabe. Ein Review erzeugt ein Protokoll oder ein Ticket. Ein Test erzeugt ein Ergebnisdokument. Ein Incident erzeugt eine Zeitlinie und Maßnahmen. Wenn Sie Kontrollen so designen, dass das Artefakt „nebenbei“ entsteht, müssen Sie später nichts mehr zusammensuchen. Dann ist DORA-Evidenz nicht Zusatzaufwand, sondern Betriebshygiene.
Damit das wirklich greift, brauchen Sie einen letzten Baustein: einen kleinen Qualitätstakt. Evidenz kippt oft nicht, weil niemand will, sondern weil niemand prüft, ob die Standards eingehalten werden. Sie brauchen dafür kein großes Auditprogramm. Eine kleine Stichprobe reicht: einmal im Monat 30 Minuten, zwei Pakete ansehen. Ist es vollständig? Ist es auffindbar? Ist die Entscheidung dokumentiert? Fehlt etwas? Wenn ja: sofort korrigieren und Standard nachschärfen. Dieser kleine Takt wirkt wie Wartung beim Betriebssystem. Ohne Wartung wird jedes System langsam unzuverlässig. Mit Wartung bleibt es stabil.
Wenn Sie heute starten wollen, dann starten Sie nicht mit „mehr Dokumenten“. Starten Sie mit einem Paket. Nehmen Sie einen relevanten Incident der letzten Monate oder einen kritischen Dienstleister-Review und bauen Sie das Paket so, dass es prüfbar wäre. Legen Sie den finalen Ablageort fest. Definieren Sie ein Benennungsschema. Und testen Sie die Drei-Minuten-Regel: Kann jemand, der nicht beteiligt war, das Paket in drei Minuten finden und erklären? Wenn ja, sind Sie auf dem richtigen Weg. Wenn nein, ist das kein Drama – es zeigt nur, wo die Struktur fehlt.
Und noch ein praktischer Hinweis, der oft unterschätzt wird: Evidenz muss nicht „schön“ sein. Sie muss eindeutig sein. Prüfer schätzen Klarheit mehr als Layout. Ein sauberes Ticket, ein nachvollziehbarer Zeitstempel, eine eindeutige Freigabe, eine klare Maßnahmenliste – das ist in der Praxis stärker als ein perfekt gestaltetes PDF, das aber keinen Bezug zum Betrieb hat.
Wenn DORA-Evidenz so aufgebaut ist, verändert sich auch die Kultur. Teams merken, dass sie weniger diskutieren müssen, weil Entscheidungen und Verantwortlichkeiten klarer sind. Management bekommt weniger „Status“ und mehr Handlungsempfehlungen. Revision bekommt weniger Suchen und mehr klare Spuren. Und das Unternehmen gewinnt ein Stück operative Ruhe – genau das, was DORA am Ende bezweckt: nicht Papier, sondern Widerstandskraft.
Im nächsten Beitrag können wir darauf aufbauen und das Thema noch konkreter machen: Wie ein evidenzfähiges Nachweissystem aussieht, das sowohl Betrieb als auch Prüfung bedient – und wie man es so gestaltet, dass es in der Praxis nicht als „Zusatzaufwand“ wahrgenommen wird.