Projektmanagement & ITIL

Change Advisory Board (CAB)

Overview

Das Change Advisory Board (CAB) ist ein Gremium aus Fach- und Technikvertretern, das beantragte Änderungen an produktiven IT-Systemen bewertet, priorisiert und den Change Manager bzw. die zuständige Change Authority bei der Entscheidung berät. Typische Mitglieder sind Change Manager, Systemverantwortliche, Vertreter der Fachbereiche, Product Owner und bei Bedarf externe Dienstleister. So werden Changes sowohl technisch als auch aus Geschäftssicht betrachtet.

Für dringende Änderungen, etwa nach einem schweren Incident oder bei einer aktiv ausgenutzten Sicherheitslücke, gibt es das Emergency CAB (ECAB): eine vorab festgelegte, kleine Besetzung mit definierten Befugnissen, die kurzfristig entscheidet.

Entwicklung: In ITIL v3 war das CAB das zentrale Freigabegremium. ITIL 4 spricht allgemeiner von der Change Authority und empfiehlt, Freigaben nach Risiko zu verteilen: Standard Changes sind vorab genehmigt, Peer Reviews oder automatisierte Prüfungen in CI/CD-Pipelines übernehmen Routinefälle, das CAB bleibt für risikoreiche Changes. Hintergrund sind Studien aus dem Buch Accelerate, nach denen externe Freigabegremien Durchlaufzeit und Deployment-Frequenz verschlechtern, ohne die Fehlerquote von Changes zu senken.

Abgrenzung: Change Management ist der Gesamtprozess, der Change Request das einzelne Antragsobjekt, das CAB eines der Entscheidungsgremien darin. Das Wartungsfenster legt fest, wann ein freigegebener Change umgesetzt wird, Release Management bündelt mehrere Änderungen zu einer Auslieferung.

How it works

Ein typischer CAB-Ablauf im Ticket-System:

  1. Der Antragsteller erfasst einen Change Request mit Beschreibung, betroffenen Configuration Items aus der CMDB, Risikobewertung, Test- und Rückfallplan.
  2. Der Change Manager klassifiziert den Change. Standard Changes laufen ohne CAB durch, Normal Changes mit mittlerem oder hohem Risiko kommen auf die Agenda.
  3. Das CAB tagt in festem Rhythmus oder stimmt sich elektronisch ab, bewertet Auswirkungen, Abhängigkeiten und Termine und gibt eine Empfehlung ab.
  4. Die Change Authority entscheidet über Freigabe, Auflagen oder Ablehnung, die Entscheidung wird am Ticket dokumentiert.
  5. Nach der Umsetzung betrachtet das CAB ausgewählte Changes im Post Implementation Review, insbesondere gescheiterte Changes und alle Emergency Changes.

Ergänzend pflegt das CAB oft den Forward Schedule of Changes (Change-Kalender), damit sich Änderungen an gemeinsam genutzten Systemen nicht überschneiden.

Benefits

  • Mehr Augen bei riskanten Änderungen: Abhängigkeiten zwischen Systemen, die ein einzelner Admin nicht sieht, fallen in der Runde auf, etwa wenn ein Firewall-Change die ERP-Schnittstelle trifft.
  • Terminabstimmung: Konflikte zwischen Changes, Monatsabschluss oder Produktionsspitzen werden vor der Umsetzung erkannt.
  • Nachvollziehbarkeit: Freigabeentscheidungen sind dokumentiert, das liefert Nachweise für ISO/IEC 20000, ISO 27001 und NIS2-Prüfungen.
  • Lerneffekt: Post Implementation Reviews zeigen, welche Change-Typen häufig scheitern und ob sich Standard Changes definieren lassen.

Practical example

Ein Lebensmittelhersteller mit 600 Mitarbeitenden und drei Werken hatte nach einem ungeplanten Datenbank-Update einen halben Tag Stillstand in der Produktionsplanung. Die IT führt ein wöchentliches CAB mit IT-Leitung, Netzwerk, ERP-Betreuung und einem Vertreter der Produktion ein, Standard Changes wie Client-Patches oder neue Benutzer laufen ohne CAB. Ein dreiköpfiges ECAB entscheidet bei kritischen Sicherheitsupdates telefonisch innerhalb einer Stunde. Nach einigen Monaten sind Changes mit Auswirkung auf die Produktion nur noch in abgestimmten Wartungsfenstern geplant, und das CAB hat mehrere wiederkehrende Changes zu Standard Changes erklärt.

Things to keep in mind

  • Bringe nur Changes mit relevantem Risiko ins CAB. Wenn jede Kleinigkeit dort landet, wird das Gremium zum Flaschenhals und Admins umgehen den Prozess.
  • Definiere Standard Changes aktiv und erweitere die Liste regelmäßig, das entlastet das CAB am stärksten.
  • Lege Besetzung, Erreichbarkeit und Befugnisse des ECAB vorab schriftlich fest, im Notfall ist keine Zeit für Grundsatzdiskussionen.
  • Verschicke die Agenda mit vollständigen Change Requests vorab, damit die Sitzung für Entscheidungen statt für Erklärungen genutzt wird.
  • Ziehe bei Cloud-Diensten wie Microsoft 365 auch angekündigte Herstelleränderungen aus dem Message Center in die Planung ein, auch wenn Du sie nicht freigeben kannst.

Conclusion

Ein CAB lohnt sich für Changes mit echtem Risiko und mehreren betroffenen Teams. Kombiniere es mit vorab genehmigten Standard Changes und einem kleinen ECAB, dann bleibt das Gremium schnell und wird nicht zum Bremsklotz.

Further reading

Related articles