Change-Management in der IT-Sicherheit: Änderungen kontrolliert planen, prüfen und freigeben

Das Change-Management in der IT-Sicherheit regelt, wie Änderungen an Systemen, Netzwerken, Anwendungen und Konfigurationen geplant, bewertet, genehmigt, umgesetzt und nachverfolgt werden, damit sie weder die Sicherheit noch die Verfügbarkeit gefährden. Ein großer Teil von Störungen und Sicherheitsvorfällen entsteht nicht durch Angriffe von außen, sondern durch eigene Änderungen: eine geöffnete Firewall-Regel, die nie wieder geschlossen wird, ein Update ohne Test oder eine Konfigurationsänderung, die niemand dokumentiert hat. In kleineren Betrieben wird häufig pragmatisch und unmittelbar geändert, weil Zeit und Personal fehlen. Das ist verständlich, birgt aber Risiken, die sich mit überschaubarem Aufwand begrenzen lassen. Der Beitrag beschreibt Änderungsarten, einen praktikablen Ablauf, Rollen, Bewertungskriterien und Dokumentationsanforderungen und stellt den Bezug zu ISO/IEC 27001 und zur DSGVO her. Er richtet sich an Geschäftsführung, IT-Leitung und Sicherheitsverantwortliche, die ihre Änderungsprozesse ordnen wollen, ohne die Agilität der IT zu ersticken. Die Hinweise sind so gewählt, dass sie auch in Betrieben mit kleinem IT-Team und externem Dienstleister praktikabel bleiben.

Titelbild: Foto von Albert Stoynov auf Unsplash.

Warum Änderungen ein Sicherheitsthema sind

Jede Änderung verändert die Angriffsfläche und das Verhalten eines Systems. Eine neue Schnittstelle schafft einen weiteren Zugangsweg, ein Update ändert Berechtigungen oder Standardeinstellungen, ein Umzug in die Cloud verschiebt Verantwortlichkeiten. Fehlt eine Prüfung, kann aus einer harmlosen Anpassung ein Einfallstor oder ein Ausfall werden.

Hinzu kommen Folgeprobleme der mangelnden Nachvollziehbarkeit. Wer nach einem Vorfall nicht rekonstruieren kann, welche Änderung wann durch wen vorgenommen wurde, verliert wertvolle Zeit bei der Ursachensuche. Im Mittelstand, in dem Wissen oft bei wenigen Personen liegt, kommt das Risiko des Wissensverlustes hinzu, wenn Konfigurationen nur im Kopf eines Administrators dokumentiert sind.

Anforderungen aus Normen und Recht

Die Norm ISO/IEC 27001 verlangt in Anhang A eine Steuerung von Änderungen an Informationsverarbeitungseinrichtungen und Informationssystemen. In der Fassung von 2022 ist dies als Maßnahme zur Änderungssteuerung enthalten (Anhang A, 8.32). Ergänzend betreffen weitere Maßnahmen die Trennung von Entwicklungs-, Test- und Produktionsumgebungen, die Handhabung von Konfigurationen und das Management technischer Schwachstellen. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) beschreibt im IT-Grundschutz vergleichbare Anforderungen an Änderungsmanagement und Konfigurationsmanagement.

Aus der DSGVO folgt in Artikel 32 die Pflicht, geeignete technische und organisatorische Maßnahmen zur Gewährleistung eines angemessenen Schutzniveaus zu treffen. Unkontrollierte Änderungen an Systemen, die personenbezogene Daten verarbeiten, können dieser Pflicht zuwiderlaufen. Wo Verarbeitungen wesentlich verändert werden, ist zusätzlich zu prüfen, ob Verzeichnis der Verarbeitungstätigkeiten oder Datenschutz-Folgenabschätzung angepasst werden müssen.

Änderungsarten und ihre Behandlung

Nicht jede Änderung benötigt dasselbe Verfahren. Ein zu schweres Verfahren für Routineänderungen führt dazu, dass es umgangen wird. Ein zu leichtes Verfahren für kritische Änderungen gefährdet den Betrieb. Üblich ist deshalb eine Einteilung in drei Klassen.

Änderungsart	Beispiele	Verfahren
Standardänderung	Anlegen eines Benutzers, Zurücksetzen eines Passworts, Installation freigegebener Software	Vorab genehmigte Vorlage, Durchführung ohne Einzelgenehmigung, Dokumentation im Ticket
Normale Änderung	Neue Firewall-Regel, Update eines Servers, Einführung einer Anwendung	Antrag, Risikobewertung, Genehmigung, Test, Umsetzung, Nachkontrolle
Notfalländerung	Sofortiger Patch bei aktiv ausgenutzter Schwachstelle, Behebung eines Ausfalls	Verkürzte Genehmigung durch benannte Person, nachträgliche Dokumentation und Überprüfung

Notfalländerungen sauber regeln

Notfälle rechtfertigen ein schnelleres Vorgehen, aber keine Verzichte auf Nachvollziehbarkeit. Es sollte vorab festgelegt sein, wer eine Notfalländerung genehmigen darf, welche Mindestangaben vorliegen müssen und wie die nachträgliche Prüfung erfolgt. Ohne diese Vorgaben wird der Notfall zum Dauerzustand, in dem alles dringend ist und nichts geprüft wird.

Der Ablauf einer normalen Änderung

1. Änderungsantrag erfassen: Ziel, Begründung, betroffene Systeme, gewünschter Zeitpunkt und Antragsteller werden im Ticket festgehalten.
2. Auswirkungen und Risiko bewerten: Welche Systeme, Daten und Benutzer sind betroffen? Welche Sicherheitsrisiken entstehen? Was geschieht bei Misserfolg?
3. Genehmigung einholen: Fachverantwortlicher, IT-Leitung und bei kritischen Systemen die Informationssicherheit entscheiden anhand der Bewertung.
4. Test vorbereiten und durchführen: Nach Möglichkeit in einer Testumgebung, mit definierten Erfolgskriterien.
5. Rückfallplan festlegen: Wie wird der Ausgangszustand wiederhergestellt, und bis zu welchem Zeitpunkt ist das möglich?
6. Umsetzung durchführen: Im vereinbarten Zeitfenster, mit Information der Betroffenen und Überwachung während und nach der Änderung.
7. Ergebnis prüfen und dokumentieren: Funktionsprüfung, Sicherheitsprüfung, Abschluss des Tickets mit Datum und Ergebnis.
8. Konfigurationsdaten aktualisieren: Inventar, Netzplan und Dokumentation werden an den neuen Zustand angepasst.

Risikobewertung: Welche Kriterien zählen

Die Bewertung muss einfach genug sein, um im Alltag angewendet zu werden. Bewährt hat sich ein Raster mit wenigen Kriterien, aus denen sich die Stufe des Verfahrens ergibt.

Kriterium	Fragestellung	Ausprägung
Kritikalität des Systems	Wie wichtig ist das System für den Geschäftsbetrieb?	Niedrig, mittel, hoch
Datenbezug	Werden personenbezogene oder vertrauliche Daten berührt?	Nein, teilweise, ja
Reichweite	Wie viele Benutzer oder Standorte sind betroffen?	Einzelne, Gruppe, alle
Reversibilität	Lässt sich die Änderung ohne Verlust rückgängig machen?	Einfach, aufwändig, nicht möglich
Erfahrung	Wurde ähnliche Änderung bereits erfolgreich durchgeführt?	Ja, teilweise, nein

Aus den Ausprägungen ergibt sich beispielsweise: Geringes Risiko bedeutet Freigabe durch den Fachverantwortlichen, mittleres Risiko zusätzlich IT-Leitung, hohes Risiko zusätzlich Geschäftsführung und Informationssicherheit. Diese Abstufung lässt sich in wenigen Zeilen festlegen und verhindert, dass jede Änderung den gleichen Aufwand erzeugt.

Rollen und Verantwortlichkeiten

Klare Rollen sind wichtiger als aufwendige Gremien. In kleineren Unternehmen genügt es, wenn wenige Personen mehrere Rollen übernehmen, solange die Trennung zwischen Antragsteller und Genehmiger gewahrt bleibt. Die Funktionstrennung ist ein Kernprinzip der Informationssicherheit: Wer eine Änderung beantragt und durchführt, sollte sie nicht allein freigeben.

• Antragsteller: Beschreibt Ziel und Nutzen der Änderung und trägt fachliche Verantwortung.
• Änderungsverantwortlicher: Prüft Vollständigkeit, koordiniert Termine und überwacht den Ablauf.
• Genehmiger: Entscheidet nach Risikoklasse, zum Beispiel Fachbereich, IT-Leitung oder Geschäftsführung.
• Umsetzer: Führt die Änderung technisch durch und dokumentiert das Ergebnis.
• Informationssicherheitsbeauftragter: Bewertet sicherheitsrelevante Auswirkungen und prüft Ausnahmen.
• Beratungsgremium (Change Advisory Board): In größeren Organisationen ein regelmäßiges Gremium für komplexe Änderungen, in kleinen Betrieben eine kurze wöchentliche Abstimmung.

Beispiel: Neue Firewall-Regel für einen Dienstleisterzugang

Das Beispiel ist fiktiv. Ein Maschinenbauer möchte einem externen Servicepartner Fernzugriff auf eine Produktionsanlage einrichten. Die Änderung wird als normale Änderung mit hohem Risiko eingestuft, weil sie ein produktionsnahes Netz betrifft und Daten des Kunden berührt.

Schritt	Maßnahme	Verantwortlich
Antrag	Begründung, Zeitraum und Umfang des Zugriffs, Benennung des Partners	Produktionsleiter
Risikobewertung	Netzsegment, Protokolle, Authentifizierung, Protokollierung	Informationssicherheit
Freigabe	Zeitlich befristete Regel, Zugriff nur über Mehrfaktor-Authentifizierung	Geschäftsführung
Umsetzung	Regel anlegen, Verbindung testen, Zugangsdaten übergeben	IT-Administrator
Nachkontrolle	Protokolle prüfen, Regel nach Ablauf entfernen	IT-Administrator

Auffällig ist die zeitliche Befristung: Viele Firewall-Regeln bleiben unbemerkt jahrelang bestehen. Das Ticket enthält daher ein Ablaufdatum, und die Löschung der Regel ist Teil der Änderung. Ohne diese Disziplin entstehen Altlasten, die bei späteren Audits oder Angriffen zu Schwachstellen werden.

Eine Änderung ist erst abgeschlossen, wenn der Ausgangszustand dokumentiert, der neue Zustand geprüft und die Konfigurationsunterlagen angepasst sind.

Besonderheiten bei Cloud-Diensten und externen Dienstleistern

Viele Änderungen finden heute nicht mehr im eigenen Rechenzentrum statt. Cloud-Anbieter aktualisieren Dienste, ändern Funktionen oder Oberflächen und passen Standardeinstellungen an, teils ohne Zutun des Kunden. Auch hier gilt das Prinzip der Kontrolle: Der Betrieb muss wissen, welche Änderungen der Anbieter ankündigt, wie diese Hinweise eingehen und wer sie prüft. Ankündigungen von Wartungsfenstern und Funktionsänderungen sollten an eine benannte Stelle gehen und nicht in einem Sammelpostfach versanden.

Bei externen Dienstleistern ist vertraglich zu regeln, dass Änderungen an den betreuten Systemen angekündigt, dokumentiert und freigegeben werden. Ein Dienstleister, der Änderungen ohne Abstimmung durchführt, untergräbt jedes interne Verfahren. Sinnvoll sind ein gemeinsames Ticketsystem, definierte Wartungsfenster und der Anspruch auf einen Änderungsbericht nach jeder Maßnahme.

• Verträge: Pflicht zur Ankündigung, Dokumentation und Freigabe von Änderungen.
• Zugänge: Befristete, personengebundene Konten für externe Administratoren, keine Sammelkonten.
• Protokollierung: Nachvollziehbarkeit der Tätigkeiten externer Dienstleister, soweit technisch möglich.
• Abnahme: Prüfung des Ergebnisses durch den Auftraggeber, nicht nur Selbstbestätigung des Dienstleisters.

Verbindung zu Patch- und Schwachstellenmanagement

Das Einspielen von Sicherheitsupdates ist eine Änderung und sollte im Rahmen des Verfahrens erfolgen. Dennoch dürfen Patches nicht durch Formalismus verzögert werden. Praktikabel ist, regelmäßige Updates als Standardänderung zu behandeln: Für Arbeitsplätze und Server werden feste Wartungsfenster, ein Testkreis und ein Rückfallverfahren festgelegt. Für kritische Schwachstellen, die aktiv ausgenutzt werden, greift das Notfallverfahren mit verkürzter Freigabe.

Entscheidend ist die Kombination aus Geschwindigkeit und Kontrolle. Wer Patches monatelang aufschiebt, weil das Verfahren zu träge ist, schafft ein Sicherheitsproblem. Wer sie ohne Test einspielt, riskiert Ausfälle. Ein abgestufter Ablauf mit einem kleinen Pilotkreis, anschließender Breite und klarer Rücknahmemöglichkeit löst diesen Zielkonflikt in den meisten Fällen.

Dokumentation und Nachvollziehbarkeit

Die Dokumentation sollte so gestaltet sein, dass auch nach Jahren erkennbar bleibt, was geändert wurde und warum. Für die Praxis bieten sich ein Ticketsystem oder ein einfaches Änderungsprotokoll an. Wichtiger als das Werkzeug ist die Einheitlichkeit der Angaben.

• Eindeutige Kennung, Datum und Antragsteller.
• Beschreibung der Änderung, betroffene Systeme und Begründung.
• Risikoeinstufung und Freigabe mit Datum und Name.
• Testergebnis, Umsetzungsdatum und Umsetzer.
• Rückfallplan und gegebenenfalls erfolgte Wiederherstellung.
• Ergebnis der Nachkontrolle und Verweis auf aktualisierte Dokumentation.

Ergänzend ist ein aktuelles Inventar der IT-Werte sinnvoll, weil jede Änderung an Systemen sich dort spiegeln sollte. Eine Konfigurationsbasis (Baseline) für Server, Netzwerkgeräte und Arbeitsplätze erleichtert den Vergleich und erkennt unerlaubte Abweichungen.

Beispielhafte Zeitplanung für Wartungsfenster

Ein festes Wartungsfenster reduziert Abstimmungsaufwand und Betriebsstörungen. Das folgende Raster ist ein fiktiver Vorschlag für einen Betrieb mit Tagesschicht und einer überschaubaren Zahl produktiver Systeme.

Systemgruppe	Wartungsfenster	Testkreis	Rückfall
Arbeitsplätze	Zweiter Dienstag im Monat, früh am Tag	Fünf Pilotgeräte aus verschiedenen Abteilungen	Rücknahme des Updates über Softwareverteilung
Server intern	Samstag, nach Datensicherung	Testsystem mit gleicher Konfiguration	Wiederherstellung aus Snapshot oder Sicherung
Netzwerkgeräte	Nach Absprache außerhalb der Betriebszeiten	Sicherung der Konfiguration vorab	Einspielen der gesicherten Konfiguration
Produktionsnahe Systeme	Nur mit Freigabe der Produktionsleitung	Herstellervorgaben, Abstimmung mit Wartungsvertrag	Rückkehr zum geprüften Softwarestand

Wichtig ist, dass vor jedem Fenster eine aktuelle Datensicherung vorliegt und deren Wiederherstellbarkeit zumindest stichprobenartig getestet wurde. Eine Sicherung, die nie zurückgespielt wurde, ist keine belastbare Grundlage für einen Rückfallplan.

Typische Fehler im Mittelstand

• Änderungen am Prozess vorbei: Administratoren ändern direkt am System, weil das Ticket zu aufwändig scheint.
• Ein Verfahren für alles: Alle Änderungen durchlaufen denselben Weg, wodurch das Verfahren umgangen wird.
• Kein Rückfallplan: Misslingt die Änderung, gibt es keinen Weg zurück.
• Fehlende Tests: Updates werden direkt in der Produktion eingespielt.
• Dauerhafte Notfallregeln: Temporäre Freigaben bleiben bestehen, weil niemand ihre Entfernung plant.
• Veraltete Dokumentation: Netzpläne und Inventare werden nach Änderungen nicht angepasst.
• Fehlende Information: Betroffene Benutzer erfahren von Wartungsfenstern erst bei der Störung.

Einführung in sechs Schritten

1. Ist-Zustand erfassen: Wie werden Änderungen bisher durchgeführt, dokumentiert und freigegeben?
2. Änderungsklassen festlegen: Standard, normal und Notfall mit Beispielen und Verfahren definieren.
3. Rollen und Freigabestufen bestimmen: Wer beantragt, wer prüft, wer genehmigt, wer setzt um?
4. Werkzeug wählen: Ticketsystem oder strukturierte Formulare, die sich im Alltag nutzen lassen.
5. Schulung und Einführung: Administratoren und Fachbereiche einweisen und mit einem Pilotbereich beginnen.
6. Kontrolle und Verbesserung: Stichproben, Auswertung von Störungen nach Änderungen und halbjährliche Anpassung der Regeln.

Kennzahlen zur Steuerung

Der Reifegrad des Änderungsmanagements lässt sich mit wenigen Kennzahlen beobachten. Dazu zählen der Anteil der Änderungen mit Freigabe vor der Umsetzung, die Zahl fehlgeschlagener oder zurückgenommener Änderungen, der Anteil von Notfalländerungen an allen Änderungen und die Zeit zwischen Antrag und Umsetzung. Ein hoher Notfallanteil weist auf mangelhafte Planung oder fehlende Wartungsfenster hin, eine sehr lange Durchlaufzeit auf ein zu schwerfälliges Verfahren.

Werden diese Werte regelmäßig an die Geschäftsführung berichtet, entsteht ein Bild darüber, ob das Verfahren genutzt wird und wirkt. Abweichungen, etwa nicht dokumentierte Änderungen, die bei Audits oder Konfigurationsvergleichen auffallen, sollten als Anlass zur Verbesserung dienen, nicht als Anlass für Schuldzuweisungen.

Checkliste für das Change-Management

• Gibt es eine schriftliche Regelung mit Änderungsklassen und Verfahren?
• Sind Rollen, Freigabestufen und Vertretungen benannt?
• Gibt es für jede normale Änderung eine Risikobewertung und einen Rückfallplan?
• Werden Änderungen vor der Produktion getestet, soweit möglich?
• Ist die Notfalländerung mit nachträglicher Prüfung geregelt?
• Werden Inventar, Netzplan und Konfigurationsunterlagen nach Änderungen aktualisiert?
• Werden befristete Freigaben mit Ablaufdatum versehen und kontrolliert?
• Werden Kennzahlen erhoben und regelmäßig ausgewertet?

FAQ

Braucht ein kleiner Betrieb ein formales Change-Management?
Ein formaler Prozess im Umfang großer Organisationen ist nicht erforderlich, doch auch kleine Betriebe benötigen Mindestregeln: dokumentierte Änderungen, Freigabe nach Risiko, Rückfallplan und Aktualisierung der Unterlagen. Das lässt sich mit einfachen Mitteln umsetzen.

Was unterscheidet eine Standard- von einer normalen Änderung?
Eine Standardänderung ist risikoarm, wiederkehrend und nach einer vorab genehmigten Vorlage durchführbar. Eine normale Änderung wird im Einzelfall bewertet, genehmigt und getestet.

Wer darf Notfalländerungen freigeben?
Das legt der Betrieb vorab fest, typischerweise IT-Leitung oder eine Vertretung. Wichtig ist, dass die nachträgliche Dokumentation und Überprüfung verbindlich vorgeschrieben sind.

Wie hängen Patch-Management und Change-Management zusammen?
Patches sind Änderungen und unterliegen daher dem Verfahren. Häufig werden regelmäßige Patches als Standardänderung mit festen Wartungsfenstern geregelt, kritische Sicherheitsupdates als Notfalländerung.

Welche Rolle spielt die Dokumentation bei Audits?
Auditoren prüfen Stichproben von Änderungen auf Antrag, Bewertung, Freigabe, Test und Abschluss. Lückenlose Nachvollziehbarkeit ist daher zentral für eine erfolgreiche Zertifizierung oder Prüfung.