13.3 Genehmigungen, Change Authority, CAB und Change-Kalender

Kurz erklärt

Nicht jede Änderung darf sofort umgesetzt werden.

Abhängig vom Risiko, den Auswirkungen und der Bedeutung eines Changes müssen geeignete Personen oder Gremien über dessen Durchführung entscheiden.

ITIL verwendet hierfür den Begriff Change Authority.

Zusätzlich unterstützen ein Change Advisory Board (CAB) sowie ein Change-Kalender die koordinierte Planung und Durchführung von Änderungen.

Warum Genehmigungen notwendig sind

Änderungen können erhebliche Auswirkungen auf IT-Services haben.

Beispiele:

Ausfall geschäftskritischer Systeme,

Sicherheitsprobleme,

Datenverlust,

Unterbrechung der Produktion,

Beeinträchtigung mehrerer Standorte.

Deshalb sollte vor der Umsetzung geprüft werden,

ob der erwartete Nutzen die möglichen Risiken rechtfertigt.

Was ist eine Change Authority?

Die Change Authority ist die Person oder Gruppe,

die über einen Change entscheidet.

ITIL schreibt keine feste Rolle vor.

Je nach Organisation kann dies beispielsweise sein:

Teamleiter,

Service Owner,

Change Manager,

Fachbereich,

Projektleitung,

IT-Leitung.

Die Entscheidung richtet sich nach Risiko und Auswirkungen des Changes.

Nicht jeder Change benötigt dieselbe Genehmigung

Ein Standard Change ist bereits vorab genehmigt.

Ein Normal Change benötigt häufig eine individuelle Freigabe.

Ein Emergency Change nutzt meist ein beschleunigtes Genehmigungsverfahren.

Die Genehmigung sollte immer zum Risiko passen.

Genehmigungen nach Risiko

Ein mögliches Beispiel:

Risiko	Mögliche Change Authority
gering	Teamleitung
mittel	Change Manager
hoch	Change Authority oder CAB
sehr hoch	Management oder Geschäftsleitung

Die konkrete Zuordnung legt jede Organisation selbst fest.

Was ist ein Change Advisory Board (CAB)?

Ein Change Advisory Board (CAB) ist ein beratendes Gremium.

Es unterstützt die Change Authority,

indem es Änderungen bewertet und Empfehlungen ausspricht.

Das CAB entscheidet nicht automatisch selbst über jeden Change.

Die endgültige Entscheidung trifft die zuständige Change Authority.

Aufgaben des CAB

Das CAB unterstützt beispielsweise bei:

Risikobewertung,

Auswirkungsanalyse,

Terminplanung,

Ressourcenplanung,

Konflikterkennung,

Priorisierung,

Abstimmung zwischen Teams.

Dadurch verbessert sich die Qualität von Entscheidungen.

Mögliche Teilnehmer eines CAB

Je nach Change können unterschiedliche Personen beteiligt sein.

Beispiele:

Change Manager,

Service Owner,

Systemadministratoren,

Netzwerkadministratoren,

Information Security,

Fachbereiche,

Projektleitung,

Lieferanten.

Nicht jeder Teilnehmer ist bei jedem Change erforderlich.

Emergency CAB (ECAB)

Für besonders dringende Änderungen kann ein Emergency Change Advisory Board (ECAB) eingesetzt werden.

Es besteht meist aus wenigen entscheidungsbefugten Personen.

Dadurch können dringende Entscheidungen schneller getroffen werden.

Typische Situationen:

kritische Sicherheitslücke,

Produktionsausfall,

Ransomware-Angriff,

schwerwiegender Netzwerkausfall.

Der Change-Kalender

Ein Change-Kalender dokumentiert,

wann geplante Änderungen stattfinden.

Typische Informationen:

Termin,

betroffene Services,

Verantwortliche,

Wartungsfenster,

Status,

Risiko.

Dadurch lassen sich Überschneidungen vermeiden.

Vorteile eines Change-Kalenders

Ein Change-Kalender hilft dabei,

Kollisionen zu vermeiden,

Wartungsfenster zu koordinieren,

Ressourcen besser zu planen,

betroffene Teams rechtzeitig zu informieren,

Risiken zu reduzieren.

Er verbessert die Übersicht über geplante Änderungen.

Beispiel eines Change-Kalenders

Datum	Service	Art des Changes
12.09.	VPN	Softwareupdate
13.09.	ERP	Datenbankupdate
14.09.	Firewall	Firmwareupdate
15.09.	WLAN	Controller-Aktualisierung

So erkennen Administratoren frühzeitig mögliche Konflikte.

Warum Terminüberschneidungen problematisch sind

Werden mehrere kritische Änderungen gleichzeitig durchgeführt,

kann dies zu Problemen führen.

Beispiel:

Firewall-Update,

Core-Switch-Austausch,

Storage-Migration

am selben Abend.

Bei einer Störung wird die Ursachenanalyse deutlich erschwert.

Der Change-Kalender hilft,

solche Situationen zu vermeiden.

Wartungsfenster

Viele Changes werden innerhalb geplanter Wartungsfenster durchgeführt.

Typische Vorteile:

geringere Auswirkungen auf Benutzer,

besser planbare Arbeiten,

ausreichende Zeit für Rollback,

koordinierte Kommunikation.

Wartungsfenster sollten frühzeitig angekündigt werden.

Kommunikation vor einem Change

Vor größeren Änderungen sollten relevante Personen informiert werden.

Beispiele:

Benutzer,

Service Desk,

Administratoren,

Management,

externe Dienstleister.

Die Information sollte unter anderem enthalten:

Zeitpunkt,

betroffene Services,

erwartete Auswirkungen,

Ansprechpartner.

Dokumentation der Genehmigung

Jede Genehmigung sollte nachvollziehbar dokumentiert werden.

Beispiele:

wer genehmigt hat,

Zeitpunkt,

Risiko,

Bedingungen,

besondere Auflagen.

Dadurch bleiben Entscheidungen transparent.

Praxisbeispiel

Ein Unternehmen plant,

die Firmware aller Core-Switches zu aktualisieren.

Die Risikobewertung ergibt:

hoher Business Impact,

mehrere Standorte betroffen.

Der Change wird:

im CAB besprochen,

in den Change-Kalender eingetragen,

für ein Wartungsfenster am Wochenende geplant.

Alle betroffenen Fachbereiche werden vorab informiert.

Typische Fehler

Fehler 1

Änderungen werden ohne Genehmigung durchgeführt.

Fehler 2

Der Change-Kalender wird nicht gepflegt.

Fehler 3

Mehrere kritische Changes finden gleichzeitig statt.

Fehler 4

Das falsche Entscheidungsgremium wird beteiligt.

Fehler 5

Emergency Changes werden nicht dokumentiert.

Fehler 6

Benutzer werden nicht informiert.

Fehler 7

Genehmigungen sind nicht nachvollziehbar.

Fehler 8

Wartungsfenster werden nicht eingehalten.

Fehler 9

Externe Dienstleister werden zu spät eingebunden.

Fehler 10

CAB-Sitzungen beschäftigen sich mit Standard Changes,

die bereits vorab genehmigt sind.

Checkliste Genehmigung

Checkliste Change-Kalender

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker sind häufig an der Vorbereitung und Umsetzung von Changes beteiligt.

Typische Aufgaben:

Risiken einschätzen,

technische Informationen bereitstellen,

Wartungsfenster abstimmen,

Change-Kalender pflegen,

Änderungen dokumentieren,

Benutzer informieren,

Monitoring nach dem Change überwachen.

Sie liefern wichtige Entscheidungsgrundlagen für die Change Authority.

Zusammenfassung

Change planen

↓

Risiko bewerten

↓

Change Authority bestimmen

↓

Genehmigung einholen

↓

Change-Kalender aktualisieren

↓

Beteiligte informieren

↓

Umsetzung vorbereiten

Merksätze

Die Change Authority entscheidet über einen Change.

Das CAB unterstützt die Entscheidung – es ersetzt sie nicht.

Standard Changes benötigen normalerweise keine erneute Genehmigung.

Ein gepflegter Change-Kalender verhindert Konflikte zwischen Änderungen.

Gute Kommunikation reduziert Risiken und Überraschungen.

Verwandte Seiten

13.1 Ziele und Grundlagen des Change Enablement

13.2 Change-Typen und Risikobewertung

13.4 Umsetzung, Tests und Rollback

13.5 Zusammenspiel mit Incident, Problem, Service Configuration Management und Monitoring

Service Configuration Management

Incident Management

Monitoring and Event Management

Quellen und Versionsstand

Offizielle Grundlagen

PeopleCert – ITIL Practice Guide: Change Enablement

ITIL Foundation – Version 5

Einordnung

ITIL verwendet den Begriff Change Authority für die Person oder Gruppe, die einen Change genehmigt. Ein Change Advisory Board (CAB) besitzt in ITIL eine beratende Funktion und unterstützt die Entscheidungsfindung. Der Einsatz eines CAB, eines Emergency CAB (ECAB) und eines Change-Kalenders richtet sich nach Größe, Komplexität und Risiko der jeweiligen Organisation.

Behandelter Framework-Stand: ITIL Version 5
Zusätzlich berücksichtigt: aktuelle ITIL-4-Practice-Guidance
Fachlicher Stand: August 2026