Wo sucht der Betrieb den Audit-Nachweis im Ernstfall?

Ein Audit-Nachweis beruhigt nur, solange ihn jemand rechtzeitig findet. Im Störungsfall zählt nicht die perfekte Ablage, sondern die Frage, ob der Betrieb belegen kann, wer entschieden hat, welche Änderung freigegeben wurde und welche Kontrolle wirklich stattgefunden hat.

Audit-Nachweise sind Belege für Kontrollen, Entscheidungen und Prüfungen. Dazu gehören Freigaben, Ticketverläufe, Protokolle, Risikoabwägungen, Testbelege, Ausnahmen, Review-Termine oder Screenshots aus Systemen. Für ITSM-Generalisten ist der praktische Kern einfach: Ein Nachweis muss dort anschlussfähig sein, wo Service, Störung, Änderung und Verantwortung im Alltag zusammenlaufen.

Regelwerke wie ISO/IEC 20000, ISO/IEC 27001, NIS2 und DORA verlangen nicht nur gute Absichten. Sie erwarten nachvollziehbare Steuerung, wirksame Kontrollen und belastbare Dokumentation. Die Details unterscheiden sich je nach Organisation und Anwendungsbereich. Der operative Effekt ist aber ähnlich: Wer im Ernstfall nur weiß, dass ein Dokument irgendwo existiert, hat noch keine brauchbare Prüfspur.

Die Ablage gewinnt selten gegen den Störungsdruck

Vor einem Audit wird häufig aufgeräumt. Dokumente werden gesucht, Freigaben ergänzt, Ordner benannt und Zuständigkeiten nachgezogen. Das kann für die Prüfung reichen. Es hilft dem Betrieb aber wenig, wenn eine kritische Störung, ein Sicherheitsereignis oder eine kurzfristige Provider-Rückfrage auftaucht. Dann will niemand zuerst wissen, wie der Ablagebaum heißt. Die relevante Frage lautet: Welche Entscheidung führte zu diesem Zustand?

Ein Nachweis gehört deshalb nicht nur in ein Governance-Laufwerk. Er braucht eine Verbindung zum operativen Objekt. Das kann ein Service, ein Change, ein Risiko, ein Anbieter, ein System, ein Notfallprozess oder ein Tickettyp sein. Ohne diese Verbindung entsteht eine gefährliche Lücke. Der Nachweis ist vielleicht vorhanden, aber nicht nutzbar. Der Betrieb verliert Zeit, Verantwortliche rekonstruieren alte Entscheidungen und die Organisation wirkt schlechter gesteuert, als sie tatsächlich ist.

Gute Prüfspuren beginnen bei normalen Arbeitsschritten

Eine belastbare Prüfspur muss nicht kompliziert sein. Sie entsteht, wenn alltägliche Arbeitsschritte Belege hinterlassen. Ein Change enthält die Freigabe und den Testnachweis. Eine Risikoausnahme enthält den Grund, den Besitzer und das Ablaufdatum. Ein Serviceeintrag zeigt, welche Kontrolle für Backup, Zugriff, Provider oder Wiederanlauf gilt. Ein Incident verweist auf den betroffenen Service und die letzte relevante Änderung.

Der Vorteil liegt in der Nähe zum Prozess. Wer später sucht, beginnt nicht bei einer leeren Dokumentenablage, sondern beim Fall selbst. Welche Änderung war beteiligt? Welche Ausnahme war aktiv? Welche Kontrolle wurde übergangen oder bestätigt? Welche Person hatte die Entscheidung? Dadurch wird Dokumentation nicht zum nachträglichen Sammelordner, sondern zum Teil des Betriebsmodells.

Nachweisqualität ist mehr als ein Dateiname

Ein Dateiname kann gut aussehen und trotzdem wenig beweisen. Für den Betrieb zählt, ob der Nachweis vollständig, aktuell, verständlich und zuordenbar ist. Ein Screenshot ohne Datum, ein Freigabeprotokoll ohne Entscheidung, ein Ticket ohne betroffenen Service oder eine Ausnahme ohne Ende erzeugen nur scheinbare Sicherheit. Im Audit und in der Störung bleiben dann dieselben Rückfragen offen.

Hilfreich ist ein kleiner Mindeststandard. Jeder wichtige Nachweis beantwortet fünf Punkte: Wofür gilt er? Wer trägt Verantwortung? Welche Entscheidung oder Kontrolle belegt er? Bis wann ist er gültig? Wo hängt er am operativen Objekt? Diese fünf Felder wirken schlicht, verhindern aber viele Suchläufe. Sie machen aus Dokumentation eine nutzbare Betriebsinformation.

Regelwerke prüfen Wirkung, nicht Ordnerästhetik

ISO/IEC 27001 spricht über Informationssicherheits-Management und geeignete Kontrollen. ISO/IEC 20000 behandelt Service-Management. NIS2 setzt in Europa stärkere Anforderungen an Cyber- und Risikomanagement für viele wichtige und wesentliche Einrichtungen. DORA richtet sich an den Finanzsektor und betont digitale operationale Resilienz. Gemeinsam zeigen diese Regelwerke eine Richtung: Kontrollen müssen nachweisbar funktionieren.

Für ITSM bedeutet das nicht, jedes Regelwerk in ein riesiges Formular zu übersetzen. Wichtiger ist die Übersetzung in Betriebsfragen. Wo ist der Nachweis zur letzten kritischen Änderung? Wie erkennt der Service Desk eine aktive Ausnahme? Wer kann bei einem Provider-Ausfall zeigen, welche Wiederanlaufanforderung vereinbart war? Welche Kontrolle schützt privilegierte Zugänge? Solche Fragen verbinden Governance mit Arbeitsfähigkeit.

Ein Register allein reicht nicht

Viele Organisationen bauen Register für Risiken, Ausnahmen, Services oder Kontrollen. Das ist sinnvoll. Ein Register wird aber schwach, wenn es neben dem Betrieb steht. Dann enthält es schöne Felder, aber keine lebendige Verbindung zu Tickets, Monitoring, Changes oder Provider-Kommunikation. Im Ernstfall entsteht wieder Handarbeit.

Besser ist ein doppelter Ansatz. Das Register hält die Übersicht. Der operative Prozess hält den direkten Bezug. Ein Serviceeintrag verweist auf die relevante Kontrolle. Ein Change verweist auf den Test. Ein Incident verweist auf den betroffenen Service und bekannte Ausnahmen. Eine Review-Aufgabe erinnert an Ablaufdaten. So bleibt der Nachweis dort auffindbar, wo der nächste Fall entsteht.

Der erste Schritt ist eine Suchprobe

ITSM-Verantwortliche können das Thema pragmatisch starten. Sie wählen drei reale Szenarien und suchen die Nachweise unter Zeitdruck. Erstens: Eine kritische Änderung verursacht eine Störung. Zweitens: Ein Auditor fragt nach der letzten Prüfung eines privilegierten Zugangs. Drittens: Ein Provider muss nachweisen, welche Wiederherstellungszusage gilt. Wenn die Suche stockt, zeigt die Probe den Verbesserungsbedarf besser als jede Grundsatzdiskussion.

Aus der Suchprobe entsteht eine einfache Nachweiskarte. Welche Belege werden gebraucht? Wo liegen sie heute? Welches operative Objekt muss darauf verweisen? Wer ist Besitzer? Welche Lücke kostet im Ernstfall Zeit? Danach lässt sich gezielt verbessern, ohne ein neues Bürokratieprojekt zu starten.

Governance wird erst im Betrieb belastbar

Auditfähigkeit entsteht nicht am Tag vor der Prüfung. Sie entsteht in den Momenten, in denen Teams eine Änderung freigeben, eine Ausnahme erlauben, ein Risiko akzeptieren oder eine Wiederanlaufzusage dokumentieren. Wenn diese Momente sauber mit dem Betrieb verbunden sind, wird der Audit-Nachweis nebenbei nutzbar.

Der entscheidende Prüfpunkt lautet deshalb nicht, ob irgendwo ein Dokument existiert. Entscheidend ist, ob der Betrieb im Ernstfall vom Service, Ticket oder Change zum passenden Nachweis kommt. Genau dort zeigt sich, ob Governance den Alltag unterstützt oder nur einen Ordner füllt.

Quellen und Einordnung: ISO zu ISO/IEC 20000-1 Service Management, ISO zu ISO/IEC 27001 Informationssicherheits-Management, Europäische Kommission zur NIS2-Richtlinie, DORA-Verordnung im Amtsblatt der EU, AXELOS zum ITIL-4-Verbesserungsmodell. Stand der Quellenprüfung: 18.07.2026. Bildquelle: Pexels, Foto-ID 7947663.