Der Begriff trägt im Deutschen zwei Bedeutungen, die nichts miteinander zu tun haben. Gemeint ist hier nicht das organisatorische Veränderungsmanagement, das Menschen durch Umstrukturierungen führt, sondern die Änderungssteuerung in der IT – im IT-Service-Management als Change Control oder Change Enablement geführt und durch ITIL verbreitet. Wer nach Phasenmodellen und Veränderungskurven sucht, ist beim anderen Begriff. Wer wissen will, wie eine Firewall-Regel geprüft und freigegeben wird, ist hier richtig.
Warum sind geplante Änderungen ein Sicherheitsrisiko?
Ein erheblicher Teil der Ausfälle und Fehlkonfigurationen entsteht nicht durch Angriffe, sondern durch beabsichtigte Änderungen mit unbeabsichtigten Nebenwirkungen: eine geöffnete Regel, die offen bleibt; ein Testzugang, der in die Produktion wandert; ein Update, das eine Protokollierung abschaltet.
Change-Management setzt genau dort an. Es verlangt, dass vor der Umsetzung jemand die Frage nach den Auswirkungen stellt, dass eine andere Person als der Umsetzende genehmigt und dass hinterher nachvollziehbar ist, wer wann was verändert hat.
Für Finanzunternehmen ist die Verknüpfung zwischen Änderung und Risikobewertung sogar ausdrücklich geregelt: Nach Artikel 8 Absatz 3 der Verordnung (EU) 2022/2554 führen Finanzunternehmen, die keine Kleinstunternehmen sind, bei jeder wesentlichen Änderung der Netzwerk- und Informationssysteminfrastruktur, der Prozesse oder Verfahren, die sich auf ihre IKT-gestützten Unternehmensfunktionen oder Assets auswirken, eine Risikobewertung durch. Artikel 8 Absatz 6 knüpft daran die Pflicht, die Bestandsverzeichnisse bei ebendiesen wesentlichen Änderungen zu aktualisieren. Damit ist die Kette Änderung → Risikobewertung → Inventar für diesen Sektor keine gute Praxis mehr, sondern Text.
Welche Schritte durchläuft eine Änderung?
- Antrag. Was soll sich ändern, warum, welche Systeme sind betroffen?
- Bewertung von fachlicher Auswirkung, Sicherheitsauswirkung, Rückfallplan und Testbedarf.
- Genehmigung durch die zuständige Rolle oder ein Gremium, abhängig von Risiko und Reichweite. Das Gremium heißt im IT-Service-Management Change Advisory Board (CAB); es berät und empfiehlt, die Entscheidung bleibt bei der benannten Genehmigungsrolle.
- Test in einer Umgebung, die der Produktion hinreichend ähnelt.
- Umsetzung im geplanten Zeitfenster, mit definiertem Rückfallpunkt.
- Nachbereitung: Ergebnis, Abweichungen vom Plan, Aktualisierung der Dokumentation und des Inventars.
Welche Änderungsarten unterscheidet man?
| Art | Merkmal | Sicherheitsanforderung |
|---|---|---|
| Standardänderung | wiederkehrend, geringes Risiko, vorab genehmigtes Verfahren | Verfahren einmalig bewertet und regelmäßig überprüft |
| Normale Änderung | Einzelfall mit Bewertung und Genehmigung | vollständige Sicherheitsbewertung vor der Umsetzung |
| Notfalländerung | zur Abwehr eines akuten Schadens | verkürzte Genehmigung, aber vollständige Nachdokumentation und nachträgliche Bewertung |
Die Liste der Standardänderungen ist der wirksamste Hebel für Akzeptanz: Sie befreit den Alltag von Formalismus und lenkt die Aufmerksamkeit auf die Änderungen, bei denen sie gebraucht wird. Sie muss dafür gepflegt werden: Ein einmal freigegebenes Verfahren, das sich seither verändert hat, ist keine Standardänderung mehr.
Wann ist ein Change Freeze sinnvoll?
Neben der Frage, ob eine Änderung freigegeben wird, steht die Frage, wann sie umgesetzt werden darf. Verbreitet sind festgelegte Sperrzeiten – im Englischen Change Freeze –, in denen nur Notfalländerungen zulässig sind: um Stichtage im Jahres- oder Quartalsabschluss, in Spitzenlastzeiten des Geschäfts, während eines Audits oder einer Migration, und rund um Zeiträume mit dünner Personaldecke.
Zwei Dinge entscheiden, ob eine Sperrzeit trägt. Sie muss vorher bekannt sein, damit Vorhaben daran geplant werden können statt an ihr aufzulaufen. Und sie braucht einen definierten Ausnahmeweg, sonst wird sie über den Notfallweg umgangen – und der Anteil der Notfalländerungen steigt aus einem Grund, der nichts mit der Bedrohungslage zu tun hat.
Welche Sicherheitsfragen müssen vor einer Freigabe beantwortet sein?
Vor der Genehmigung sollten wenige, immer gleiche Fragen beantwortet sein: Verändert die Änderung Zugriffsrechte, Netzübergänge oder Verschlüsselung? Werden Protokollierung oder Überwachung berührt? Kommen neue externe Verbindungen oder Komponenten Dritter hinzu? Verarbeitet das System künftig andere oder zusätzliche Daten? Existiert ein getesteter Rückfallplan? Ändert sich der Schutzbedarf?
Wer diese Fragen im Antragsformular führt, braucht kein separates Sicherheitsverfahren neben dem Change-Prozess.
Notfalländerungen
Der Notfallweg ist notwendig und wird am häufigsten überdehnt. Zwei Regeln begrenzen das: Die nachträgliche Dokumentation und Bewertung ist verpflichtend und wird nachgehalten, und der Anteil der Notfalländerungen an allen Änderungen wird als Kennzahl berichtet. Ein hoher Anteil ist ein Hinweis auf einen zu schwerfälligen Regelweg, nicht auf eine besonders ereignisreiche Lage.
Wie grenzt sich Change-Management von Konfigurations- und Releasemanagement ab?
| Begriff | Verhältnis zum Change-Management |
|---|---|
| Patch-Management | Sonderfall mit eigenem Auslöser und eigenen Fristen nach Schweregrad; läuft meist als vorab genehmigte Standardänderung |
| Konfigurationsmanagement | liefert die Grundlage: ohne bekannten Ist-Stand ist die Auswirkung einer Änderung nicht bestimmbar |
| Release- und Deployment-Management | regelt Bündelung und Auslieferung; die Freigabeentscheidung bleibt beim Change |
| Organisatorisches Veränderungsmanagement | derselbe deutsche Begriff, anderes Fach: Menschen und Akzeptanz statt Systeme und Freigaben |
Nachweis
Patch-Management ist ein Sonderfall des Änderungswesens mit eigenem Auslöser und eigenen Fristen; Konfigurations- und Releasemanagement liefern die Grundlage dafür, dass überhaupt bekannt ist, was verändert wird. Nachweisfähig wird das Ganze über den Änderungsdatensatz: Antrag, Bewertung, Genehmigung, Testergebnis, Umsetzungszeitpunkt, ausführende Person. Im Audit ist die Stichprobe aus diesen Datensätzen eine der ergiebigsten, vor allem der Abgleich mit tatsächlich veränderten Systemen.
Was eine Änderung in Rizzqo nach sich zieht
Die unangenehmen Änderungen sind nicht die, die schiefgehen, sondern die, die den Schutzbedarf verschieben, ohne dass es jemandem auffällt. Ein System wandert in die Cloud, ein Dienst übernimmt zusätzlich eine Aufgabe, eine Anwendung verarbeitet plötzlich personenbezogene Daten. Die Pflichten ändern sich mit, die Dokumentation nicht.
In Rizzqo hängt die Pflichtenliste an der Klassifizierung des Objekts, nicht an einem Dokument. Wird ein Asset umklassifiziert, kommen die nun zutreffenden Anforderungen hinzu und die nicht mehr zutreffenden entfallen; manuell angelegte Zuordnungen bleiben dabei erhalten. Wird die Verknüpfung zu einem primären Wert geändert, ändert sich auch der geerbte Schutzbedarf. Was Rizzqo beisteuert, ist die Folgewirkung auf die Anforderungen, die sonst niemand nachzieht.