Bildquelle: Bildquelle: Pexels / Foto-ID 3760067 / Dokument und Stift als Motiv für Freigabenachweis und Audit-Prüfung / https://www.pexels.com/photo/3760067/ / C00 Lizenz
Eine Änderung kann technisch sauber umgesetzt sein und trotzdem im Audit schwer erklärbar werden. Der Grund liegt oft nicht im System, sondern im Ticket. Dort steht zwar, dass jemand freigegeben hat. Es fehlt aber der sichtbare Nachweis, wer welche Entscheidung getroffen hat, auf welcher Grundlage sie galt und warum sie für genau diesen Betriebsfall ausreichend war.
Für ITSM-Generalisten ist das kein Spezialproblem der Revision. Ein Freigabenachweis entscheidet im Alltag darüber, ob Betrieb, Service Desk, Security und Management später dieselbe Geschichte sehen. Wenn ein Audit, eine Störung oder eine Sicherheitsprüfung nachfragt, reicht ein Status wie „approved“ selten aus. Der Vorgang muss verständlich zeigen, welche Rolle entschieden hat und welche Grenze diese Freigabe hatte.
ITIL ordnet Change Enablement als Praxis ein, die Änderungen nutzbar und kontrolliert in den Betrieb bringen soll. ISO/IEC 20000-1 beschreibt Anforderungen an ein Service-Management-System. ISO 19011 gibt Leitlinien für Audits von Managementsystemen. Übersetzt in den Betriebsalltag heißt das: Nicht jede Freigabe braucht einen Roman, aber sie braucht eine nachvollziehbare Spur.
Ein Häkchen erklärt keine Entscheidung
Viele Ticketsysteme machen Freigaben bequem. Ein Klick, ein Statuswechsel, eine automatisch gespeicherte Person und ein Zeitstempel wirken auf den ersten Blick ausreichend. Für eine echte Nachvollziehbarkeit fehlt aber oft der fachliche Kontext. War es eine Standardänderung? Ging es um ein Produktivsystem? Gab es ein bekanntes Risiko? Wurde eine Ausnahme akzeptiert? War die Freigabe zeitlich begrenzt?
Genau diese Fragen tauchen selten während der Umsetzung auf. Sie kommen später, wenn ein Auditor den Ablauf prüft, wenn eine Störung auf eine Änderung zurückgeführt wird oder wenn Security wissen will, warum eine riskante Anpassung erlaubt wurde. Dann wird aus einem knappen Freigabestatus eine Sucharbeit durch Kommentare, Chatverläufe, E-Mails und alte Projektunterlagen.
Der Nachweis gehört in den normalen Ablauf
Ein guter Freigabenachweis muss nicht kompliziert sein. Er sollte aber im Ticket selbst oder über einen eindeutig verlinkten Nachweis erreichbar sein. Entscheidend sind vier Punkte: die freigebende Rolle, der konkrete Gegenstand der Entscheidung, der Zeitpunkt und die Begründung oder Regelbasis. Bei risikoreichen Änderungen kommt zusätzlich die Grenze der Freigabe dazu. Sie sagt, was nicht automatisch mitgenehmigt wurde.
Damit wird Governance praktisch. Der Service Desk muss nicht raten, ob eine Änderung wirklich in Ordnung war. Der Betrieb sieht, ob ein Rollback oder eine Rückfrage vorgesehen ist. Security erkennt, ob eine Ausnahme bewusst akzeptiert wurde. Das Management kann prüfen, ob der Prozess funktioniert oder nur formal grün aussieht.
Freigabe und Verantwortung dürfen nicht auseinanderfallen
Ein häufiger Bruch entsteht, wenn die Person im Ticket eine technische Aktivität bestätigt, die fachliche Verantwortung aber woanders liegt. Dann entsteht ein gefährlicher Eindruck: Das Ticket sieht freigegeben aus, obwohl die eigentliche Entscheidung nicht sichtbar getroffen wurde. Besonders heikel ist das bei produktiven Änderungen, Berechtigungen, Cloud-Ressourcen, Provider-Eingriffen und Sicherheitsausnahmen.
Der bessere Weg ist eine klare Trennung. Technische Durchführung, fachliche Entscheidung und Risikofreigabe dürfen verschiedene Rollen haben. Das Ticket muss diese Rollen aber lesbar machen. Ein Feld für „Freigegeben durch“ reicht nur, wenn klar ist, wofür diese Person zuständig war. Sonst bleibt die Verantwortung später interpretationsfähig.
Eine kleine Checkliste verhindert spätere Sucharbeit
- Jede produktive Änderung nennt die freigebende Rolle, nicht nur einen Namen.
- Das Ticket beschreibt kurz, was genau freigegeben wurde.
- Risiken, Ausnahmen und zeitliche Grenzen stehen direkt beim Nachweis.
- Externe Freigaben aus E-Mail, Portal oder Vertrag werden eindeutig verlinkt.
- Nach dem Go-live ist sichtbar, ob die Freigabe genutzt, geändert oder zurückgezogen wurde.
So wird der Freigabenachweis vom Pflichtfeld zum Betriebswerkzeug. Er schützt nicht vor jeder falschen Entscheidung. Er sorgt aber dafür, dass Entscheidungen später gefunden, verstanden und verbessert werden können. Genau das macht den Unterschied zwischen einem grünen Ticket und einem belastbaren Audit-Nachweis.
Quellen und Einordnung: AXELOS zu ITIL Service Management, ISO/IEC 20000-1 Service Management, ISO 19011 Leitlinien für Audits von Managementsystemen. Stand der Quellenprüfung: 22.07.2026. Bildquelle: Pexels, Foto-ID 3760067, C00 Lizenz.
