Wann wird die Ausnahmegenehmigung zum Audit-Risiko?

Eine Ausnahmegenehmigung klingt nach pragmatischer Entlastung. Im Audit wird sie aber schnell riskant, wenn niemand mehr sieht, warum sie erlaubt wurde, wer sie trägt und wann sie endet.

Ausnahmegenehmigungen sind im IT-Betrieb kontrollierte Abweichungen von einer Regel. Das kann eine verzögerte Sicherheitsmaßnahme, ein zeitweise erlaubter Fremdzugang, ein späterer Patch, eine manuelle Kontrolle oder eine technische Sonderlösung sein. Sie sind nicht automatisch ein Fehler. Problematisch werden sie, wenn aus einer begründeten Abweichung ein stiller Dauerzustand wird.

Für ITSM-Generalisten und IT-Management ist das besonders relevant, weil Ausnahmen selten nur in einem Fachteam bleiben. Sie betreffen Risiken, Zuständigkeiten, Servicequalität, Prüfpflichten und oft auch Dienstleister. Wer Ausnahmen nur als einzelne Freigabe behandelt, übersieht den zweiten Teil der Steuerung: den kontrollierten Ablauf.

Die erste Freigabe ist nur der Anfang

Eine Ausnahme entsteht meistens aus einem nachvollziehbaren Grund. Ein System kann nicht sofort aktualisiert werden. Ein Provider braucht für kurze Zeit erweiterte Rechte. Eine Standardkontrolle passt nicht zu einer Altanwendung. Ein Projekt darf mit einer Übergangslösung starten, weil der Zielzustand noch nicht fertig ist. In solchen Situationen ist eine dokumentierte Ausnahme besser als eine heimliche Umgehung.

Der Fehler beginnt, wenn die Ausnahme nach der Freigabe nicht mehr geführt wird. Dann steht irgendwo ein genehmigter Sonderfall, aber niemand prüft, ob der Grund noch gilt. Das Audit fragt später nicht nur, ob es eine Freigabe gab. Es fragt auch, ob Risiko, Verantwortlichkeit, Frist und Nachprüfung erkennbar waren.

Ein Ablaufdatum schützt vor Gewöhnung

Die wichtigste Frage lautet deshalb: Wann endet diese Abweichung wieder? Ohne Ablaufdatum gewöhnt sich die Organisation an den Sonderfall. Aus einem Übergang wird ein Schattenprozess, aus einem technischen Provisorium wird ein Betriebsstandard und aus einer befristeten Risikofreigabe wird ein dauerhaftes Loch in der Kontrolle.

Ein gutes Ablaufdatum ist mehr als ein Kalendereintrag. Es muss mit einer Folgehandlung verbunden sein. Vor dem Termin braucht es eine Prüfung: Ist die Ursache beseitigt? Muss die Ausnahme verlängert werden? Hat sich das Risiko verändert? Wer entscheidet? Welche Ersatzkontrolle greift bis dahin? Erst diese Fragen machen die Befristung auditierbar.

Der Besitzer muss fachlich entscheiden können

Ausnahmen bleiben oft bei der Person liegen, die sie technisch angefragt hat. Für den Betrieb reicht das nicht. Eine Ausnahme braucht einen fachlichen Besitzer, der das Risiko versteht und die Auswirkungen vertreten kann. Das kann ein Service Owner, ein Risikoverantwortlicher, ein Informationssicherheitsbeauftragter oder eine klar benannte Betriebsrolle sein.

Wichtig ist die Trennung zwischen Umsetzung und Risikoannahme. Wer eine Abweichung technisch benötigt, sollte nicht allein entscheiden, dass die Abweichung fachlich akzeptabel ist. Im Audit wirkt eine Ausnahme deutlich belastbarer, wenn Antrag, Begründung, Genehmigung, Risikobewertung und Ablaufprüfung getrennt nachvollziehbar sind.

Die Ersatzkontrolle gehört neben die Ausnahme

Nicht jede Abweichung kann sofort geschlossen werden. Gerade bei Altverfahren, Lieferantenabhängigkeiten oder komplexen Changes braucht der Betrieb realistische Übergänge. Dann muss aber sichtbar sein, welche Ersatzkontrolle das Risiko begrenzt. Das kann ein zusätzlicher Log-Check, eine engere Zugangsprüfung, eine manuelle Freigabe, ein Monitoring-Alarm oder eine häufigere Review-Runde sein.

Diese Ersatzkontrolle darf nicht in Nebenabsprachen verschwinden. Sie gehört direkt zur Ausnahme. Sonst bleibt nur die Information, dass eine Regel nicht eingehalten wird. Für Governance und Audit ist aber entscheidend, wie die Organisation das Risiko bis zur Schließung steuert.

Ausnahmen brauchen eine eigene Warteliste

Einzelne Ausnahmen wirken harmlos. Gefährlich wird das Gesamtbild. Wenn mehrere offene Abweichungen denselben Service, denselben Provider oder dieselbe Kontrollfamilie betreffen, entsteht ein Risiko, das im einzelnen Ticket nicht sichtbar ist. Deshalb braucht der Betrieb eine laufende Liste mit Status, Frist, Besitzer, betroffener Kontrolle, Risiko und nächstem Prüftermin.

Diese Liste muss nicht kompliziert sein. Wichtig ist, dass sie aktiv genutzt wird. Ein monatlicher Blick auf offene Ausnahmen zeigt, welche Sonderfälle überfällig sind, welche Verlängerungen sauber begründet wurden und wo ein Muster entsteht. Gerade ITSM-Teams können hier viel leisten, weil sie Service, Störung, Änderung und Verantwortlichkeit zusammenführen.

Der Audit-Nachweis entsteht im Alltag

Auditfähigkeit entsteht nicht am Tag der Prüfung. Sie entsteht bei jeder Freigabe, jeder Verlängerung und jeder Schließung. Deshalb sollte jede Ausnahme einen kurzen, verständlichen Nachweis liefern: Grund, betroffener Service, Regelabweichung, Risiko, Genehmiger, Besitzer, Ersatzkontrolle, Ablaufdatum, Review-Ergebnis und Schließdatum.

Wenn diese Informationen fehlen, wird aus der Ausnahme ein Suchproblem. Dann müssen Teams im Audit alte Mails, Chatverläufe, Tickets und einzelne Erinnerungen zusammensuchen. Das kostet Zeit und wirkt unsicher. Besser ist ein klarer Standard, der schon bei der ersten Freigabe die spätere Prüfung mitdenkt.

Ein kleiner Review senkt das Risiko spürbar

Der praktische Einstieg ist einfach. Teams können die zehn jüngsten offenen Ausnahmen prüfen und fragen: Gibt es ein Ablaufdatum? Ist ein fachlicher Besitzer benannt? Ist die Ersatzkontrolle beschrieben? Ist die nächste Prüfung terminiert? Ist erkennbar, was zur Schließung passieren muss? Wenn eine dieser Antworten fehlt, ist die Ausnahme nicht sauber geführt.

So wird Governance greifbar. Es geht nicht darum, jede Abweichung zu verbieten. Es geht darum, befristete Ausnahmen als kontrollierte Risiken zu behandeln. Je klarer Ablauf, Besitzer und Nachweis sind, desto weniger wird das nächste Audit zur Suchaktion.

Quellen und Einordnung: NIST SP 800-53 zu Sicherheits- und Datenschutzkontrollen, NIST Risk Management Framework, AXELOS zur ITIL-4-Practice Risk Management. Stand der Quellenprüfung: 20.07.2026. Bildquelle: Pexels, Foto-ID 5922204, C00 Lizenz.