Bildquelle: Pexels / Foto-ID 3760067 / Dokumentenprüfung als Motiv für Audit-Ausnahme, Governance und Nachweisführung / https://www.pexels.com/photo/3760067/
Eine Ausnahme im Audit klingt nach kontrollierter Abweichung. Im Alltag kann daraus aber eine neue Schattenregel werden, wenn Ablaufdatum, Besitzer und Rückkehrplan fehlen.
Ein Audit ist eine geordnete Prüfung. Es soll zeigen, ob Prozesse, Nachweise und Kontrollen zu den eigenen Regeln, zu Standards oder zu gesetzlichen Erwartungen passen. Für ITSM-Generalisten ist dabei nicht nur die formale Prüfung wichtig, sondern die Frage, ob der Betrieb nach einer Ausnahme wieder in einen sauberen Regelzustand zurückfindet.
Standards und Frameworks wie ITIL, COBIT oder das NIST Cybersecurity Framework geben Organisationen keine magische Sicherheit. Sie helfen, Verantwortlichkeiten, Risiken, Kontrollen und Verbesserungen systematisch zu steuern. Eine Audit-Ausnahme ist deshalb kein Freifahrtschein, sondern ein befristeter Hinweis: Die Regel ist bekannt, wird aber aus einem begründeten Grund noch nicht erfüllt.
Eine Ausnahme braucht mehr als eine Begründung
Im IT-Betrieb gibt es legitime Gründe für Abweichungen. Ein Altverfahren kann eine Modernisierung verzögern. Ein kritischer Hersteller kann eine technische Änderung noch nicht liefern. Ein Migrationsprojekt kann eine Übergangsfrist brauchen. Problematisch wird es erst, wenn die Ausnahme zwar genehmigt, danach aber nicht mehr geführt wird.
Dann verwandelt sich die Abweichung in eine stillschweigende neue Norm. Der alte Zugriff bleibt bestehen, die schwache Kontrolle wird weiter akzeptiert, der manuelle Workaround wird zur Dauerpraxis. Im nächsten Audit steht derselbe Punkt wieder im Bericht, aber niemand kann erklären, warum er weiterhin offen ist und wer ihn wirklich schließen muss.
Der operative Schaden entsteht zwischen zwei Prüfungen
Governance scheitert selten am ersten Formular. Sie scheitert an der Zeit danach. Eine sauber formulierte Ausnahme verliert ihren Wert, wenn kein Wiedervorlagetermin, kein verantwortlicher Owner und kein messbarer Schließpunkt hinterlegt sind. Gerade in ITSM-Werkzeugen, Risiko-Registern und Change-Prozessen sollte eine Ausnahme deshalb wie ein eigener Arbeitsgegenstand behandelt werden.
Das NIST Cybersecurity Framework beschreibt Governance als Grundlage dafür, Risiken, Rollen und Entscheidungen im Kontext der Organisation zu steuern. COBIT betont ebenfalls, dass Governance und Management von Unternehmens-IT getrennte, aber verbundene Aufgaben sind. Auf den Alltag übersetzt heißt das: Eine Ausnahme darf nicht nur technisch erklärt werden. Sie muss als Managemententscheidung sichtbar bleiben.
Der Owner entscheidet über die Rückkehr zur Regel
Eine Ausnahme ohne Besitzer ist besonders gefährlich. Der Fachbereich verweist auf die IT, die IT auf den Hersteller, der Hersteller auf die Roadmap und das Auditteam auf den Bericht. So bleibt die Abweichung formal bekannt, aber praktisch herrenlos. Der bessere Weg ist eine klare Zuordnung: Wer trägt das Risiko, wer liefert die Korrektur und wer darf die Ausnahme verlängern?
Diese Rollen müssen nicht kompliziert sein. Für jede Ausnahme reichen oft fünf Pflichtfelder: Grund, Risiko, Owner, Ablaufdatum und Rückkehrkriterium. Das Rückkehrkriterium ist der entscheidende Punkt. Es beschreibt nicht nur, dass etwas irgendwann verbessert werden soll, sondern woran der Betrieb erkennt, dass die Ausnahme beendet werden darf.
Verlängerungen brauchen eine neue Entscheidung
Eine Ausnahme kann verlängert werden. Sie darf aber nicht automatisch weiterlaufen, nur weil niemand widersprochen hat. Jede Verlängerung sollte dieselbe Frage neu beantworten: Ist das Restrestrisiko noch akzeptabel, oder kaschiert die Ausnahme inzwischen eine strukturelle Schwäche?
Atlassian beschreibt Change Management als kontrollierten Umgang mit Änderungen, damit Risiken vor der Umsetzung bewertet werden. Für Audit-Ausnahmen gilt eine ähnliche Logik nach der Genehmigung. Die Entscheidung muss später wieder auf den Tisch, weil sich Umgebung, Risiko, Nutzerzahl, Lieferantensituation und Priorität verändern können.
Das Reporting darf nicht nur offene Punkte zählen
Ein Audit-Report mit offenen Punkten ist hilfreich, aber allein zu grob. Besser ist eine kleine Ausnahme-Landkarte. Sie zeigt, welche Abweichungen neu sind, welche verlängert wurden, welche älter als geplant sind, welche ein hohes Risiko tragen und welche keinen aktiven Owner haben. So sieht das Management nicht nur die Menge der Abweichungen, sondern ihre Qualität.
Besonders wichtig ist die Altersstruktur. Eine Ausnahme, die seit drei Wochen läuft, ist oft ein normaler Übergang. Eine Ausnahme, die seit neun Monaten verlängert wird, ist ein anderes Signal. Sie kann bedeuten, dass Budget fehlt, ein Anbieter blockiert, ein Prozess falsch geschnitten ist oder eine Kontrolle im Alltag nicht funktioniert.
Die Kontrollfrage vor dem nächsten Audit
Vor dem nächsten Audit sollte jedes IT-Team eine einfache Prüfung machen: Welche Ausnahme würden wir heute nicht noch einmal genehmigen, wenn sie neu auf den Tisch käme? Genau diese Punkte gehören zuerst in die Eskalation. Nicht weil jede Abweichung sofort verschwinden muss, sondern weil dauerhafte Ausnahmen eine bewusste Entscheidung brauchen.
Eine gute Governance-Kultur behandelt Ausnahmen nicht als Makel, sondern als Steuerungssignal. Sie erlaubt Abweichungen, wenn der Betrieb sie braucht. Sie verhindert aber, dass daraus heimliche Standards entstehen. Der Unterschied liegt in Nachweis, Frist, Owner und einer echten Rückkehrentscheidung.
Quellen und Einordnung NIST Cybersecurity Framework, ISACA COBIT, AXELOS zu ITIL Service Management, Atlassian zu Change Management. Stand der Quellenprüfung: 08.07.2026. Bildquelle: Pexels, Foto-ID 3760067.
