Change Management im ISMS: Änderungen sicher steuern

Warum Change Management Teil des ISMS ist

Informationssicherheit ist kein statischer Zustand. Systeme werden aktualisiert, Konfigurationen geändert, neue Software eingeführt, alte abgelöst. Jede dieser Änderungen kann die Sicherheitslage verbessern oder verschlechtern, und ohne einen strukturierten Prozess erfährst du erst dann davon, wenn etwas schiefgelaufen ist.

ISO 27001 adressiert dieses Thema in Annex A.8.32 (Change Management). Die Anforderung lautet: Änderungen an Informationsverarbeitungseinrichtungen und Informationssystemen müssen einem Änderungsmanagementverfahren unterliegen. Wer bereits ein ISMS aufgebaut hat, kennt die Norm-Anforderungen. Das klingt abstrakt, meint aber etwas sehr Konkretes: Bevor jemand an einem produktiven System etwas ändert, muss klar sein, was geändert wird, warum, welche Risiken damit verbunden sind, wer die Änderung genehmigt und wie sie rückgängig gemacht werden kann, falls etwas nicht wie geplant funktioniert.

In vielen mittelständischen Unternehmen fehlt genau dieser Prozess. Die IT-Abteilung installiert ein Update, konfiguriert eine Firewall-Regel um oder migriert einen Server, ohne dass jemand außerhalb der IT davon weiß. Das funktioniert so lange, bis es nicht mehr funktioniert: Ein fehlerhaftes Update legt den E-Mail-Server lahm, eine geänderte Firewall-Regel blockiert den Zugriff auf ein geschäftskritisches System, eine Migration bricht ab und hinterlässt inkonsistente Daten.

Change Management im ISMS soll nicht die IT-Abteilung ausbremsen oder mit Bürokratie überhäufen. Es soll sicherstellen, dass Änderungen bewusst, geplant und nachvollziehbar durchgeführt werden, und dass im Fehlerfall ein Plan B existiert.

Change-Typen: Standard, Normal und Emergency

Nicht jede Änderung braucht denselben Aufwand an Planung und Genehmigung. Ein routinemäßiges Windows-Update ist etwas grundsätzlich anderes als die Migration einer Datenbank auf ein neues System. Deshalb unterscheidet ein gutes Change-Management drei Typen, die jeweils unterschiedliche Prozesse durchlaufen.

Standard Changes

Standard Changes sind wiederkehrende Änderungen mit geringem Risiko, die vorab genehmigt wurden und nach einem festen Verfahren durchgeführt werden. Sie erfordern keine individuelle Risikobewertung und keine separate Genehmigung, weil beides bereits pauschal erfolgt ist.

Typische Beispiele für Standard Changes:

• Installation genehmigter Software aus dem Softwarekatalog
• Regelmäßige Betriebssystem-Updates und Sicherheitspatches (nach definiertem Patchzyklus)
• Anlegen, Ändern oder Deaktivieren von Benutzerkonten
• Austausch defekter Hardware durch identische Modelle
• Anpassung von Druckerberechtigungen oder Netzlaufwerk-Zuordnungen
• Zertifikatserneuerungen mit identischen Parametern

Damit eine Änderung als Standard Change gelten kann, muss sie drei Kriterien erfüllen: Sie wurde bereits mehrfach erfolgreich durchgeführt, das Risiko ist dokumentiert und als niedrig bewertet, und es existiert eine schriftliche Arbeitsanweisung für die Durchführung.

Standard Changes werden im Change-Log dokumentiert, aber nicht einzeln genehmigt. Die Vorab-Genehmigung erfolgt typischerweise einmal jährlich durch das Change Advisory Board oder den IT-Leiter.

Normal Changes

Normal Changes sind geplante Änderungen, die eine individuelle Risikobewertung und eine explizite Genehmigung erfordern. Sie machen den Großteil der Änderungen aus, die über Routinetätigkeiten hinausgehen.

Beispiele für Normal Changes:

• Einführung einer neuen Software oder eines neuen Cloud-Dienstes
• Migration von Systemen oder Datenbanken
• Änderungen an der Netzwerkarchitektur (Segmentierung, VPN-Konfiguration, Firewall-Regeln)
• Updates, die über reine Sicherheitspatches hinausgehen (Major Versions, Feature Releases)
• Änderungen an Verschlüsselungsstandards oder Authentifizierungsverfahren
• Einführung oder Änderung von Monitoring- und Logging-Systemen
• Umzug von Servern oder Netzwerkkomponenten
• Änderungen am Backup-Konzept

Normal Changes durchlaufen den vollständigen Change-Prozess: Antrag, Risikobewertung, Genehmigung, Planung, Durchführung, Test, Post-Implementation Review. Die Durchlaufzeit variiert je nach Komplexität und Risiko zwischen wenigen Tagen und mehreren Wochen.

Emergency Changes

Emergency Changes sind ungeplante Änderungen, die sofort durchgeführt werden müssen, weil eine akute Bedrohung oder ein schwerwiegender Ausfall vorliegt. Sie durchlaufen einen verkürzten Genehmigungsprozess, bei dem die Dokumentation nachgeholt wird.

Typische Situationen für Emergency Changes:

• Einspielen eines kritischen Sicherheitspatches bei einer aktiv ausgenutzten Schwachstelle (Zero-Day)
• Isolation eines kompromittierten Systems aus dem Netzwerk
• Sofortige Sperrung eines Benutzerkontos bei Verdacht auf Kompromittierung
• Notfall-Änderung an Firewall-Regeln zur Abwehr eines laufenden Angriffs
• Wiederherstellung eines Systems nach einem Ausfall, wenn dabei von der dokumentierten Konfiguration abgewichen werden muss

Der entscheidende Punkt: Emergency Changes umgehen den normalen Genehmigungsprozess, aber sie umgehen nicht die Dokumentation. Jeder Emergency Change muss innerhalb von 24 bis 48 Stunden nachträglich dokumentiert, bewertet und vom CAB bestätigt werden.

Change Advisory Board für KMU: pragmatisch statt bürokratisch

In großen Unternehmen ist das Change Advisory Board (CAB) ein formelles Gremium mit regelmäßigen Sitzungen, definierten Mitgliedern und einem eigenen Prozess. Im Mittelstand muss das nicht so aufwändig sein, aber die Funktion muss trotzdem erfüllt werden: Es braucht ein Forum, in dem Änderungen bewertet, diskutiert und freigegeben werden.

Zusammensetzung

Ein CAB für ein mittelständisches Unternehmen mit 50 bis 200 Mitarbeitern besteht typischerweise aus 3 bis 5 Personen:

• IT-Leiter oder Systemadministrator: Bewertet die technische Machbarkeit und das technische Risiko.
• Informationssicherheitsbeauftragter (ISB): Bewertet die Auswirkungen auf die Informationssicherheit.
• Vertreter der betroffenen Fachabteilung: Bewertet die Auswirkungen auf den Geschäftsbetrieb. Wer das ist, hängt von der jeweiligen Änderung ab.
• Optional: Geschäftsleitung oder deren Vertreter: Bei Änderungen mit hohem Risiko oder hohen Kosten.
• Optional: Externer IT-Dienstleister: Wenn die IT ganz oder teilweise ausgelagert ist.

Sitzungsformat

Das CAB muss sich nicht stundenlang zusammensetzen. Ein wöchentliches Meeting von 30 Minuten reicht in den meisten Fällen aus. Die Agenda ist einfach:

1. Offene Change Requests durchgehen (Risikobewertung prüfen, Fragen klären, genehmigen oder ablehnen)
2. Status laufender Changes prüfen (liegt alles im Plan?)
3. Abgeschlossene Changes reviewen (hat alles funktioniert, gibt es Lessons Learned?)
4. Emergency Changes der letzten Woche nachbewerten

Bei geringem Änderungsaufkommen kann das CAB auch zweiwöchentlich tagen. Wichtig ist die Regelmäßigkeit: Wenn das CAB nur bei Bedarf einberufen wird, schleicht sich schnell die Gewohnheit ein, Changes ohne Genehmigung durchzuführen.

Entscheidungsfindung

Das CAB entscheidet über die Genehmigung von Normal Changes. Für die Entscheidung gibt es vier Optionen:

• Genehmigt: Die Änderung darf wie beantragt durchgeführt werden.
• Genehmigt mit Auflagen: Die Änderung darf durchgeführt werden, aber unter bestimmten Bedingungen (z. B. außerhalb der Geschäftszeiten, mit erweitertem Monitoring, nach zusätzlichem Test).
• Zurückgestellt: Die Änderung wird nicht abgelehnt, aber es fehlen Informationen oder die Risikobewertung ist unvollständig. Der Antragsteller muss nacharbeiten.
• Abgelehnt: Die Änderung wird nicht durchgeführt. Die Begründung wird dokumentiert.

Risikobewertung vor Änderungen

Jeder Normal Change und jeder nachträglich bewertete Emergency Change braucht eine Risikobewertung. Diese Bewertung muss nicht wissenschaftlich exakt sein, aber sie muss die wesentlichen Risikodimensionen abdecken.

Die fünf Kernfragen der Change-Risikobewertung

1. Was kann schiefgehen? Identifiziere die realistischen Fehlszenarien. Ein Datenbankupgrade kann zu Inkompatibilitäten mit der Anwendungssoftware führen. Eine Firewall-Änderung kann legitimen Datenverkehr blockieren. Ein Serverwechsel kann zu Datenverlust führen, wenn die Migration fehlschlägt.

2. Wie wahrscheinlich ist ein Fehler? Basierend auf Erfahrungswerten, der Komplexität der Änderung und der Qualität der Vorbereitung. Ein einfaches Update auf einem Testsystem, das zuvor erfolgreich getestet wurde, hat eine geringere Fehlerwahrscheinlichkeit als eine erstmalig durchgeführte Migration ohne Testlauf.

3. Welche Auswirkungen hat ein Fehler? Auswirkungen auf Verfügbarkeit (Systemausfall), Integrität (Datenverlust, Dateninkonsistenz), Vertraulichkeit (unbeabsichtigter Datenzugriff) und den Geschäftsbetrieb (Produktivitätsverlust, Kundenbeschwerden, vertragliche Konsequenzen).

4. Welche Systeme und Prozesse sind betroffen? Abhängigkeiten identifizieren: Welche anderen Systeme hängen von dem betroffenen System ab? Welche Geschäftsprozesse nutzen es? Wie viele Benutzer sind betroffen?

5. Ist die Änderung reversibel? Kann die Änderung rückgängig gemacht werden, und wenn ja, wie schnell und mit welchem Aufwand? Ein Konfigurationschange ist in der Regel schnell reversibel. Eine Datenbankmigration oft nicht.

Risikomatrix für Changes

Ein bewährtes Modell für die Risikobewertung von Changes nutzt zwei Dimensionen: Auswirkung (niedrig, mittel, hoch, kritisch) und Wahrscheinlichkeit eines Fehlers (gering, mittel, hoch). Die Kombination ergibt eine Risikostufe, die den Genehmigungsprozess bestimmt.

Die Risikostufe bestimmt den Genehmigungsweg:

• Niedrig: IT-Leiter genehmigt allein, CAB wird informiert.
• Mittel: CAB genehmigt im regulären Wochenmeeting.
• Hoch: CAB genehmigt, Geschäftsleitung wird informiert, erweiterter Rollback-Plan erforderlich.
• Kritisch: Geschäftsleitung genehmigt persönlich, dediziertes Planungsmeeting, vollständiger Test auf Staging-Umgebung, Rollback getestet.

Genehmigungs- und Dokumentationsprozess

Der Change-Prozess von der Idee bis zum Abschluss folgt einem klaren Ablauf. Dieser Ablauf ist für Normal Changes vollständig und für Standard und Emergency Changes in angepasster Form gültig.

Phase 1: Change Request erstellen

Der Antragsteller füllt einen Change Request aus, der mindestens folgende Informationen enthält:

• Beschreibung der Änderung: Was genau soll geändert werden?
• Begründung: Warum ist die Änderung notwendig? Welches Problem löst sie?
• Betroffene Systeme und Dienste: Welche Infrastrukturkomponenten sind betroffen?
• Geplanter Zeitpunkt und Dauer: Wann soll die Änderung durchgeführt werden, und wie lange dauert sie voraussichtlich?
• Risikobewertung: Bewertung nach den fünf Kernfragen (siehe oben).
• Rollback-Plan: Wie wird die Änderung rückgängig gemacht, falls sie fehlschlägt?
• Testplan: Wie wird nach der Änderung überprüft, ob alles funktioniert?
• Kommunikationsplan: Wer muss vorab informiert werden?

Phase 2: Bewertung und Genehmigung

Der Change Request wird dem CAB vorgelegt. Das CAB bewertet die Risikobewertung, prüft den Rollback-Plan und entscheidet über die Genehmigung. Bei hohem Risiko kann das CAB zusätzliche Maßnahmen verlangen: einen erweiterten Test, eine Durchführung außerhalb der Geschäftszeiten, die Bereitstellung zusätzlicher Ressourcen oder die Beteiligung eines externen Spezialisten.

Die Genehmigung wird schriftlich dokumentiert. Das kann ein Eintrag in einem Change-Management-Tool sein, eine signierte E-Mail oder ein Vermerk im Change-Log. Entscheidend ist, dass die Genehmigung nachvollziehbar und einem Datum sowie einer Person zugeordnet ist.

Phase 3: Planung und Vorbereitung

Nach der Genehmigung wird die Änderung vorbereitet. Dazu gehört:

• Alle betroffenen Personen und Abteilungen informieren
• Backup der betroffenen Systeme erstellen und verifizieren
• Testumgebung vorbereiten (falls erforderlich)
• Rollback-Materialien bereitstellen (Konfigurationsdateien, Backup-Medien, Installationsmedien)
• Zeitfenster im Kalender blockieren und Bereitschaftsdienst organisieren

Phase 4: Durchführung und Test

Die Änderung wird gemäß dem dokumentierten Plan durchgeführt. Jeder Schritt wird protokolliert, einschließlich Abweichungen vom Plan und deren Begründung. Nach der Durchführung werden die definierten Tests ausgeführt, um die korrekte Funktion zu verifizieren.

Wenn die Tests fehlschlagen, wird der Rollback-Plan aktiviert. Der Rollback wird ebenfalls protokolliert und der Change Request mit dem Status „fehlgeschlagen" abgeschlossen.

Phase 5: Abschluss und Dokumentation

Nach erfolgreicher Durchführung und bestandenem Test wird der Change Request formal abgeschlossen. Die IT-Dokumentation wird aktualisiert: Netzwerkdiagramme, Systemdokumentation, Konfigurationsdatenbank (CMDB), Betriebshandbücher. Der Change wird im Change-Log als abgeschlossen vermerkt.

Der Rollback-Plan

Ein Rollback-Plan ist keine optionale Ergänzung, sondern ein Pflichtbestandteil jedes Normal und Emergency Changes. Er beschreibt, wie die Änderung rückgängig gemacht wird, falls sie fehlschlägt oder unerwartete Auswirkungen hat.

Inhalte eines Rollback-Plans

• Auslösekriterien: Unter welchen Bedingungen wird der Rollback ausgelöst? Nicht jede Abweichung erfordert einen Rollback. Definiere klare Kriterien: „Wenn der E-Mail-Server nach dem Update nicht innerhalb von 15 Minuten erreichbar ist" oder „Wenn die Antwortzeiten des ERP-Systems nach der Migration dauerhaft über 5 Sekunden liegen".
• Rollback-Schritte: Konkrete, schrittweise Anleitung zur Rückkehr zum vorherigen Zustand. Nicht „Backup wiederherstellen", sondern: „1. Dienst XY stoppen. 2. Konfigurationsdatei /etc/app/config.yaml durch Backup-Version vom Zeitpunkt T ersetzen. 3. Datenbank aus Snapshot vom Zeitpunkt T wiederherstellen (Befehl: ...). 4. Dienst XY starten. 5. Funktionstest durchführen."
• Zeitrahmen: Wie lange dauert der Rollback maximal? Diese Information ist wichtig, um das Wartungsfenster korrekt zu planen.
• Verantwortliche Person: Wer führt den Rollback durch? Wer entscheidet, ob der Rollback ausgelöst wird?
• Kommunikation: Wen muss ich informieren, wenn der Rollback ausgelöst wird?

Rollback testen

Bei Changes mit hohem oder kritischem Risiko sollte der Rollback vorher getestet werden, idealerweise auf einer Testumgebung. Ein Rollback-Plan, der nie getestet wurde, ist ein Hoffnungsplan, und Hoffnung ist keine Strategie.

Post-Implementation Review

Der Post-Implementation Review (PIR) ist der Schritt, den die meisten Unternehmen überspringen und damit eine wichtige Lernchance verspielen. Er findet nach Abschluss einer Änderung statt und bewertet, ob die Änderung erfolgreich war und was beim nächsten Mal besser laufen kann.

Zeitpunkt

Der PIR sollte nicht am Tag der Änderung stattfinden, sondern nach einer angemessenen Beobachtungsperiode. Für einfache Änderungen reicht eine Woche. Für komplexe Migrationen oder Systemeinführungen können 2 bis 4 Wochen sinnvoll sein. Dieser Zeitraum gibt ausreichend Gelegenheit, Probleme zu erkennen, die erst im laufenden Betrieb auftreten.

Inhalte des PIR

• Zielerreichung: Wurde das Ziel der Änderung erreicht? Hat sich das Problem gelöst, das den Change ausgelöst hat?
• Planabweichungen: Gab es Abweichungen vom Plan? Wenn ja, warum und mit welchen Auswirkungen?
• Unvorhergesehene Probleme: Sind nach der Änderung Probleme aufgetreten, die in der Risikobewertung nicht identifiziert wurden?
• Rollback-Einsatz: Musste der Rollback-Plan aktiviert werden? Wenn ja, hat er funktioniert?
• Zeitaufwand: Wie lange hat die Änderung tatsächlich gedauert im Vergleich zur Planung?
• Verbesserungsvorschläge: Was würdest du beim nächsten Mal anders machen?

Ergebnisse nutzen

Die Erkenntnisse aus dem PIR fließen in drei Bereiche ein:

1. Change-Prozess verbessern: Wenn sich herausstellt, dass die Risikobewertung regelmäßig bestimmte Risiken übersieht, wird die Bewertungsmethode angepasst.
2. Standard Changes definieren: Wenn ein Normal Change mehrfach erfolgreich und ohne Komplikationen durchgeführt wurde, kann er als Standard Change eingestuft werden.
3. Lessons Learned dokumentieren: Erkenntnisse werden im Change-Log festgehalten und stehen für zukünftige, ähnliche Änderungen als Referenz zur Verfügung.

Emergency Changes: Der verkürzte Weg

Emergency Changes sind der Lackmustest für ein funktionierendes Change Management. Sie zeigen, ob der Prozess auch unter Druck funktioniert, wenn keine Zeit für ein reguläres CAB-Meeting bleibt.

Wann ist ein Change ein Emergency?

Ein Emergency Change liegt vor, wenn eine der folgenden Bedingungen erfüllt ist:

• Ein Sicherheitsvorfall ist aktiv und erfordert sofortige Maßnahmen
• Eine kritische Schwachstelle wird aktiv ausgenutzt und ein Patch muss unverzüglich eingespielt werden
• Ein geschäftskritisches System ist ausgefallen und die Wiederherstellung erfordert Abweichungen von der Standardkonfiguration
• Ein regulatorischer Verstoß muss unverzüglich behoben werden

Der IT-Leiter oder der ISB entscheidet, ob ein Change als Emergency eingestuft wird. Diese Entscheidung sollte nicht leichtfertig getroffen werden, denn Emergency Changes umgehen wichtige Kontrollen.

Verkürzter Prozess

Bei einem Emergency Change entfällt die formale CAB-Genehmigung vor der Durchführung. Stattdessen gilt:

1. Telefonische oder Chat-Genehmigung durch den IT-Leiter oder den ISB. Bei Nichterreichbarkeit entscheidet der diensthabende Administrator, dokumentiert aber die gescheiterten Kontaktversuche.
2. Durchführung mit Protokollierung aller Schritte in Echtzeit (Logbuch, Ticket, Chat-Protokoll).
3. Sofortige Benachrichtigung des CAB und der betroffenen Fachabteilungen nach Durchführung.
4. Nachträgliche Dokumentation innerhalb von 24 bis 48 Stunden: vollständiger Change Request mit Risikobewertung, Begründung der Dringlichkeit und Durchführungsprotokoll.
5. Nachträgliche Bewertung im nächsten CAB-Meeting: War die Emergency-Einstufung gerechtfertigt? Wurde korrekt gehandelt? Gibt es Verbesserungsbedarf?

Missbrauch verhindern

Ein häufiges Problem: Wenn Emergency Changes einfacher durchzusetzen sind als Normal Changes, werden sie inflationär genutzt. Teams umgehen den regulären Prozess, indem sie Änderungen als dringend deklarieren, obwohl sie es nicht sind. Dem kannst du auf zwei Arten begegnen:

Erstens durch regelmäßige Auswertung der Emergency-Change-Quote. Wenn mehr als 10 bis 15 Prozent aller Changes als Emergency eingestuft werden, stimmt etwas nicht. Entweder ist der reguläre Prozess zu langsam und muss beschleunigt werden, oder die Teams nutzen die Emergency-Kategorie missbräuchlich.

Zweitens durch konsequente nachträgliche Bewertung. Jeder Emergency Change wird im CAB nachbesprochen. Wenn sich herausstellt, dass die Dringlichkeit nicht gegeben war, wird das dokumentiert und mit dem Team besprochen.

Zusammenhang mit Schwachstellen- und Patch-Management

Change Management und Patch Management sind eng miteinander verzahnt. Jeder Patch ist eine Änderung an einem System und muss als solche behandelt werden. Gleichzeitig schafft ein strukturiertes Schwachstellenmanagement oft den Anlass für Changes.

Patch Management als Change-Prozess

Regelmäßige Sicherheitspatches sollten als Standard Changes definiert sein. Das bedeutet: Der Patchzyklus ist vorab genehmigt, das Verfahren ist dokumentiert, die Risiken sind bekannt und als niedrig bewertet. Patches werden gemäß dem festgelegten Zyklus eingespielt (z. B. monatlich am Patch-Tuesday plus 7 Tage für Tests), ohne dass für jeden einzelnen Patch ein Change Request gestellt werden muss.

Ausnahmen: Patches, die über einen einfachen Sicherheitsfix hinausgehen (Feature Changes, Major Updates), werden als Normal Changes behandelt. Kritische Out-of-Band-Patches für aktiv ausgenutzte Schwachstellen werden als Emergency Changes eingespielt.

Schwachstellenmanagement als Change-Treiber

Wenn ein Schwachstellen-Scan oder ein Penetrationstest Sicherheitslücken identifiziert, generiert das in der Regel Changes: Konfigurationsänderungen, Systemhärtungen, Softwareupdates oder Architekturanpassungen. Diese Changes durchlaufen den regulären Prozess, werden aber priorisiert, basierend auf der Kritikalität der Schwachstelle.

Die Verknüpfung sieht in der Praxis so aus:

1. Schwachstellen-Scan identifiziert Schwachstelle X mit CVSS-Score 8.5 (hoch).
2. IT erstellt einen Change Request zur Behebung der Schwachstelle.
3. CAB bewertet den Change, berücksichtigt die Kritikalität der Schwachstelle bei der Priorisierung.
4. Change wird durchgeführt.
5. Nachfolgender Schwachstellen-Scan bestätigt, dass die Schwachstelle behoben ist.
6. PIR dokumentiert den gesamten Vorgang.

Dokumentation verknüpfen

Im ISMS sollten Change-Log, Schwachstellenregister und Patch-Status miteinander verknüpft sein. In ISMS Lite lassen sich Changes, Risikobewertungen und Genehmigungen zentral dokumentieren und mit den zugehörigen Schwachstellen verknüpfen. Wenn ein Auditor fragt, wie eine bestimmte Schwachstelle behandelt wurde, musst du den Weg von der Erkennung über die Risikobewertung und den Change Request bis zur Bestätigung der Behebung lückenlos nachweisen können.

Praxisbeispiel: Change Management im 80-Mitarbeiter-Unternehmen

Ein mittelständischer Maschinenbauer mit 80 Mitarbeitern, davon 3 in der internen IT, führt Change Management wie folgt ein:

CAB: IT-Leiter, ISB (in Personalunion mit dem Qualitätsmanager), Produktionsleiter. Wöchentliches Meeting am Dienstagnachmittag, 30 Minuten. Bei Abwesenheit eines Mitglieds wird per E-Mail abgestimmt.

Standard Changes: Monatliche Windows-Updates, Benutzerverwaltung (Anlegen, Ändern, Sperren), Druckerkonfiguration, Routinewartung der Produktionsanlagen-IT (nach Wartungsplan). Die Liste der Standard Changes wird einmal jährlich vom CAB überprüft und bei Bedarf aktualisiert.

Normal Changes: Alles, was über Standard Changes hinausgeht. Letzte Beispiele: Einführung einer neuen MES-Schnittstelle zur ERP-Anbindung, Migration des Fileservers in eine neue Virtualisierungsumgebung, Umstellung der VPN-Lösung.

Emergency Changes: Selten, aber vorgekommen: Sofortige Sperrung eines kompromittierten Admin-Accounts, Notfall-Patch für eine kritische Exchange-Schwachstelle am Wochenende.

Dokumentation: Change Requests und Change-Log werden in einem einfachen Ticketsystem geführt. Jeder Change Request hat ein Formulartemplate mit den Pflichtfeldern. Der PIR ist ein kurzer Kommentar im Ticket, der die fünf PIR-Fragen beantwortet.

Kennzahlen: Das CAB wertet quartalsweise aus: Anzahl Changes gesamt, davon Standard/Normal/Emergency, Anzahl fehlgeschlagener Changes, durchschnittliche Durchlaufzeit von Normal Changes. Diese ISMS-Kennzahlen fließen ins Management-Review ein.

Tipps für die Einführung

Wenn du noch kein formales Change Management hast, starte nicht mit einem 50-seitigen Prozesshandbuch. Fang klein an und baue aus:

Monat 1: Definiere die drei Change-Typen und erstelle ein einfaches Change-Request-Formular. Lege fest, wer im CAB sitzt und wann das erste Meeting stattfindet. Beginne damit, alle Änderungen an produktiven Systemen zu dokumentieren, auch wenn die Bewertung und Genehmigung noch informell läuft.

Monat 2 bis 3: Etabliere den wöchentlichen CAB-Rhythmus. Führe die Risikobewertung für Normal Changes ein. Erstelle die erste Liste der Standard Changes. Definiere den Emergency-Change-Prozess.

Monat 4 bis 6: Führe den Post-Implementation Review ein. Beginne mit der Verknüpfung von Change Management und Schwachstellenmanagement. Erstelle Rollback-Plan-Templates. Definiere Kennzahlen und werte sie zum ersten Mal aus.

Ab Monat 7: Optimiere den Prozess basierend auf den Erfahrungen der ersten Monate. Automatisiere, wo möglich (z. B. automatische Erinnerungen für PIR, Dashboard für Change-Kennzahlen). Erweitere die Standard-Change-Liste. Überprüfe, ob der Prozess auch für die Fachabteilungen funktioniert oder ob er als reines IT-Thema wahrgenommen wird.

Der Schlüssel zum Erfolg liegt nicht in der Perfektion des Prozesses, sondern in der Konsequenz der Anwendung. Ein einfacher Prozess, der konsequent gelebt wird, ist im Audit mehr wert als ein umfassender Prozess, der regelmäßig umgangen wird.

Weiterführende Artikel

• ISMS aufbauen: Der komplette Leitfaden für Unternehmen mit 50 bis 500 Mitarbeitern
• Patch Management für den Mittelstand: Schwachstellen schließen, bevor es knallt
• Risikobewertung im ISMS: Von der Identifikation zur Risikoanalyse
• Sicherheitsvorfälle erkennen, melden und richtig reagieren
• Internes ISMS-Audit durchführen: Planung, Checkliste und Bericht

Änderungen an IT-Systemen werden nie aufhören. Neue Anforderungen, Sicherheitsupdates, technische Weiterentwicklungen sorgen dafür, dass sich die Infrastruktur kontinuierlich verändert. Change Management gibt dieser Veränderung eine Struktur, die sicherstellt, dass jede Änderung bewusst, geplant und nachvollziehbar erfolgt. Das schützt nicht nur vor vermeidbaren Ausfällen, sondern liefert dem Auditor den Nachweis, dass dein ISMS auch im operativen Alltag funktioniert.