Dokumentiere Ausnahmefreigaben mit Ablaufdatum und Owner. Sonst wird aus Risiko Routine

Eine Ausnahmefreigabe wirkt oft wie ein pragmatischer Ausweg. Ein Update muss schnell live, ein Sicherheitscheck ist noch nicht vollständig, ein Provider braucht länger als geplant. Kritisch wird es, wenn die Ausnahme im Ticket stehen bleibt, aber niemand mehr weiß, wann sie endet und wer sie wieder einsammelt.

Change Management bedeutet im IT Service Management, Änderungen an IT-Services geordnet zu planen, zu prüfen und freizugeben. Es soll verhindern, dass eine schnelle technische Lösung später als Ausfall, Sicherheitslücke oder Audit-Fund zurückkommt. Ausnahmefreigaben gehören in diese Logik, weil sie bewusst erlauben, dass ein normaler Kontrollpunkt vorübergehend nicht vollständig erfüllt ist. Genau deshalb brauchen sie mehr Nachweis, nicht weniger.

Eine Ausnahme ist keine zweite Standardspur

Im Alltag entstehen Ausnahmefreigaben aus nachvollziehbaren Gründen. Ein wichtiger Kunde wartet auf eine Fehlerkorrektur. Eine Störung blockiert den Betrieb. Ein Lieferant stellt ein Update bereit, bevor alle Nachweise fertig sind. Oder ein Service muss kurzfristig weiterlaufen, obwohl eine technische Bedingung noch offen ist. Das Problem ist selten die erste Entscheidung. Das Problem entsteht, wenn aus der kurzfristigen Entscheidung eine stille Routine wird.

Atlassian beschreibt Change Management als Verfahren, mit dem Teams Änderungen standardisieren, Risiken verringern und den Kontext für Entscheidungen sichtbar machen. BMC ordnet Change Enablement ähnlich ein und betont, dass Änderungen nicht nur umgesetzt, sondern bewertet, autorisiert und nachvollziehbar gemacht werden müssen. Für Ausnahmefreigaben heißt das: Der Betrieb darf eine Abweichung akzeptieren, aber er muss sie als Abweichung führen. Sonst sieht ein späteres Audit nur einen fehlenden Kontrollpunkt und kein bewusst gesteuertes Risiko.

Das Ticket muss vier Antworten geben

Eine brauchbare Ausnahmefreigabe braucht keine lange Akte. Sie braucht vier Felder, die ein Service Desk, ein Change Advisory Board oder ein Audit später ohne Detektivarbeit versteht. Erstens: Welche Regel oder welcher Kontrollpunkt wird vorübergehend nicht erfüllt? Zweitens: Warum ist die Ausnahme fachlich vertretbar und welcher Schaden würde entstehen, wenn man die Änderung stoppt? Drittens: Wer ist Owner der Ausnahme und darf über Verlängerung oder Schließung entscheiden? Viertens: Bis wann muss die Ausnahme überprüft oder geschlossen werden?

Diese vier Antworten trennen eine gesteuerte Ausnahme von einer Ausrede. Ohne Regelbezug bleibt unklar, was eigentlich abweicht. Ohne Begründung wirkt die Freigabe nachträglich. Ohne Owner wandert die Verantwortung zwischen Betrieb, Security, Fachbereich und Provider. Ohne Ablaufdatum kann niemand sagen, ob die Ausnahme noch bewusst gilt oder nur vergessen wurde.

Der Owner darf nicht nur der technische Umsetzer sein

In vielen Tickets steht als Verantwortlicher die Person, die die Änderung technisch ausführt. Für Ausnahmefreigaben reicht das nicht. Der technische Umsetzer kann dokumentieren, was getan wurde. Er ist aber nicht automatisch die richtige Rolle, um ein Risiko gegen Servicewirkung, Compliance, Kundenversprechen oder Betriebsstabilität abzuwägen.

Der Owner sollte deshalb die Rolle sein, die den Service und die Folgeentscheidung verantwortet. Das kann der Service Owner, ein Change Manager, ein Sicherheitsverantwortlicher oder ein fachlicher Entscheider sein. Wichtig ist, dass diese Rolle ausdrücklich im Ticket steht. Wenn eine Ausnahme verlängert werden soll, muss genau diese Rolle die neue Lage prüfen. Wenn sie geschlossen wird, muss das Ticket zeigen, wodurch der fehlende Kontrollpunkt nachgeholt wurde.

Ablaufdatum heißt nicht automatische Freigabe

Ein Ablaufdatum ist kein Kalenderdekor. Es ist der Moment, an dem die Ausnahme erneut auf den Tisch muss. Bis dahin sollte klar sein, welche Nachweise fehlen, welche Maßnahme offen ist und welche Auswirkung ein weiteres Offenlassen hätte. Ein Ablaufdatum ohne Wiedervorlage ist fast wertlos, weil niemand rechtzeitig erinnert wird.

Praktisch hilft eine einfache Regel: Jede Ausnahme bekommt direkt beim Erstellen einen Rückfrage-Termin im Ticket oder im Change-Kalender. Der Termin fragt nicht nur, ob die Aufgabe erledigt ist. Er fragt, ob das Risiko noch tragbar ist, ob der Owner weiter zuständig ist und ob der ursprüngliche Grund noch gilt. Wenn sich der Kontext verändert hat, braucht die Ausnahme eine neue Entscheidung statt einer stillen Verlängerung.

Audits suchen keine perfekte Welt, sondern prüfbare Entscheidungen

NIST beschreibt im Leitfaden zum Security-Focused Configuration Management, dass Konfigurationsänderungen kontrolliert, dokumentiert und in ihrer Sicherheitswirkung betrachtet werden sollen. Für ITSM-Generalisten ist daran vor allem ein Punkt wichtig: Prüfbarkeit entsteht nicht erst im Audit. Sie entsteht im Moment der Entscheidung. Wer im Ticket sauber zeigt, welche Abweichung erlaubt wurde, warum sie zeitlich begrenzt ist und wer die Rückkehr zum Normalzustand verantwortet, macht aus einem Risiko eine steuerbare Aufgabe.

Das schützt auch den Service Desk. Bei einer Störung kann das Team schneller erkennen, ob eine bekannte Ausnahme beteiligt sein könnte. Bei einer Kundenfrage lässt sich erklären, ob eine Abweichung bewusst akzeptiert und verfolgt wurde. Bei einem internen Review muss niemand alte Mails, Chatnachrichten oder mündliche Zusagen zusammensuchen.

So wird die Ausnahme wieder geschlossen

Der Abschluss gehört genauso ins Ticket wie die Freigabe. Wurde der fehlende Test nachgeholt? Ist der Providernachweis angekommen? Wurde eine temporäre Berechtigung entfernt? Ist die Konfiguration wieder im Standard? Erst wenn diese Antwort sichtbar ist, endet die Ausnahme wirklich.

Der kleine Zusatzaufwand lohnt sich. Ausnahmefreigaben bleiben möglich, ohne dass sie den Kontrollrahmen aushöhlen. Der Betrieb behält Tempo, aber nicht auf Kosten der Nachvollziehbarkeit. Und das nächste Audit findet nicht nur eine Abweichung, sondern eine dokumentierte Entscheidung mit Ablaufdatum, Owner und sauberem Rückweg.

Quellen und Einordnung: Atlassian zu Change Management im ITSM-Kontext, BMC zu ITIL Change Enablement, NIST SP 800-128 zu Security-Focused Configuration Management. Stand der Quellenprüfung: 25.07.2026. Bildquelle: Pexels / Foto-ID 8815849 / https://www.pexels.com/photo/a-person-signing-a-contract-8815849/ / C00 Lizenz.