Das Schweizer Taschenmesser des IT-Betriebs: Change Management für IT-Dienstleister

Freitagmittag ruft ein Kunde an: „Könnt ihr mal eben den Port auf der Firewall freischalten? Wir müssen heute noch auf den Server.“

Der Techniker kennt den Kunden. Die Anfrage klingt plausibel, die Änderung dauert zwei Minuten und alle anderen sind gerade in Terminen. Also setzt er die Regel.

Acht Wochen später fragt jemand, warum dieser Port aus dem Internet erreichbar ist. Im Ticketsystem steht nichts. Der ursprüngliche Anrufer weiß nur noch, dass es damals dringend war. Ob die Regel weiterhin gebraucht wird, wer sie beauftragen durfte und weshalb keine Quelladressen eingeschränkt wurden, lässt sich nicht mehr beantworten.

Die eigentliche Änderung war klein. Das Loch in der gemeinsamen Erinnerung ist deutlich größer.

Die kurze Antwort

Change Management für IT-Dienstleister ist der geregelte Umgang mit Änderungen an den Systemen und technischen Umgebungen ihrer Kunden. Ein Change verbindet den Anlass mit dem betroffenen System, der notwendigen Entscheidung, der Umsetzung, einer Prüfung, dem möglichen Rückweg und dem tatsächlichen Ergebnis.

Das macht den Change zum Schweizer Taschenmesser des IT-Betriebs. Er kann aus einem Service Request, einem Incident, einem Problem, einer Schwachstelle oder einem Herstellerhinweis entstehen. Am Ende zeigt er immer: Was wurde warum an welchem System geändert – und was kam dabei heraus?

Nicht jede Änderung braucht denselben Aufwand. Der Austausch einer defekten Maus darf als vorab freigegebener Standard Change durchlaufen. Eine neue Firewallregel wird normalerweise für den konkreten Fall bewertet. Eine akut relevante kritische Schwachstelle kann einen verkürzten Emergency Change auslösen.

Die ISO 27001 liefert mit A.8.32 den passenden Normanker. Die Notwendigkeit versteht man aber auch ohne Norm: Wer Kunden-IT verändert, sollte später noch wissen, was er dort so alles angerichtet hat.

Ein Change ist mehr als eine Genehmigung

Viele Unternehmen verstehen Change Management als digitales Wartezimmer. Ein Techniker möchte arbeiten, das Ticket wartet auf eine Freigabe und irgendwann klickt jemand auf „Genehmigt“. Danach gilt der Prozess als erfüllt.

Das greift viel zu kurz. Eine Freigabe ist nur eine mögliche Entscheidung innerhalb des Changes. Der Vorgang sollte den gesamten roten Faden halten:

• Woher kommt die Änderung?
• Welcher Kunde, Service und welches System sind betroffen?
• Wer darf sie beauftragen und wer entscheidet über die Durchführung?
• Welche Auswirkungen und Abhängigkeiten sind bekannt?
• Wie wird die Änderung umgesetzt und geprüft?
• Wie kommen wir zurück, wenn sie nicht funktioniert?
• Wer muss vorher oder nachher informiert werden?
• Was ist tatsächlich passiert?

Dadurch verbindet der Change mehrere Teile des Betriebs, die sonst gern auseinanderfallen. Die Kundenanfrage steht im Service-Ticket, die technische Umsetzung im Chat, die Freigabe in einer E-Mail und das Ergebnis nur im Gedächtnis des Administrators. Das ist keine Dokumentation. Das ist eine Schnitzeljagd, die man immer verliert.

Wie Kundenmeldungen zunächst vollständig in einer gemeinsamen Arbeitslage ankommen, erklärt unser Artikel über das Ticketsystem für IT-Dienstleister. Der Change übernimmt, sobald aus einer Meldung eine kontrolliert durchzuführende Änderung wird.

Standard, Normal oder Emergency Change?

Die drei Change-Arten verhindern, dass jede Änderung dieselbe Genehmigungsoper durchlaufen muss.

Die Bezeichnungen stammen aus dem etablierten IT-Service-Management. Sie müssen deshalb kein vollständiges ITIL-Projekt starten. Die Unterscheidung löst schlicht ein sehr reales Problem: Geschwindigkeit und Kontrolle müssen zur jeweiligen Änderung passen.

Standard Change: Nein, die Maus braucht keine Einzelgenehmigung

Sobald jemand Change Management erwähnt, kommt zuverlässig die Frage:

„Wie jetzt, muss ich mir künftig jeden Austausch einer Maus freigeben lassen?“

Nein. Genau dafür gibt es Standard Changes.

Ein Standard Change ist nicht ungenehmigt. Er wurde vorab für einen klaren Anwendungsfall freigegeben. Ablauf, Grenzen, Zuständigkeit und gegebenenfalls notwendige Nachweise sind bekannt. Der Mitarbeiter muss deshalb nicht bei jeder Durchführung dieselbe Grundsatzentscheidung erneut einholen.

Geeignete Kandidaten können sein:

• Austausch eines üblichen defekten Peripheriegeräts;
• Installation eines freigegebenen Standardsoftwarepakets;
• Erweiterung einer festgelegten Verteilergruppe;
• standardisierte Benutzeranlage innerhalb eines vereinbarten Services;
• Austausch einer Komponente nach einer erprobten Anleitung.

Die konkrete Liste hängt von Ihren Leistungen und Kundenvereinbarungen ab. Eine Benutzeranlage mit weitreichenden administrativen Rechten wird kaum allein dadurch risikoarm, dass sie häufig vorkommt. „Machen wir dauernd“ ist noch keine Risikobewertung.

Normal Change: Bewerten, ohne ein Theaterstück aufzuführen

Eine neue Firewallregel, eine größere Migration oder eine wesentliche Konfigurationsänderung passt nicht zuverlässig in eine vorab genehmigte Schablone. Der konkrete Fall muss betrachtet werden.

Das bedeutet nicht automatisch, dass am Donnerstag zwölf Personen zusammentreten und sich eine Präsentation über die Mausbewegungen des Administrators ansehen müssen.

Für viele Normal Changes reichen nachvollziehbare Antworten im Ticket:

• Was soll geändert werden und warum?
• Ist der Anforderer dazu berechtigt?
• Welches System und welcher Service sind betroffen?
• Welche Auswirkungen sind möglich?
• Wer setzt um und wer autorisiert?
• Wie wird das Ergebnis geprüft?
• Welche Rückfallmöglichkeit gibt es?

Die entscheidende Stelle muss fachlich entscheiden können. Der Geschäftsführer ist nicht automatisch der richtige Freigeber für eine einzelne Firewallregel. Wenn er weder Zeit noch technische Entscheidungsgrundlage besitzt, erzeugt seine Unterschrift vor allem feierliche Verantwortungsdekoration. Besser ist eine festgelegte operative Rolle mit klaren Entscheidungsgrenzen.

Emergency Change: Schnell bedeutet nicht regellos

Und dann ist Freitagabend eine kritische Schwachstelle bekannt. Das betroffene System steht erreichbar im Internet, ein funktionierender Exploit kursiert und der Hersteller stellt eine Gegenmaßnahme bereit.

„Dann warten wir wohl bis Montag, bis die Geschäftsführung wieder da ist.“

Natürlich nicht! Dafür braucht der IT-Dienstleister einen Emergency-Change-Weg.

Ein Emergency Change verkürzt Bewertung und Autorisierung auf das betrieblich Notwendige. Vorher sollte feststehen:

• Wer darf außerhalb der normalen Zeiten entscheiden?
• Welche Informationen werden mindestens benötigt?
• Welche Sicherung oder Rückfallmöglichkeit ist machbar?
• Wer muss beim Kunden informiert werden?
• Wie werden Umsetzung und Ergebnis anschließend vervollständigt und überprüft?

Emergency bedeutet nicht „Der schnellste Admin gewinnt“. Auch unter Zeitdruck muss jemand die Verantwortung für die Entscheidung übernehmen. Dokumentation darf teilweise nachgezogen werden, aber sie darf nicht dauerhaft verschwinden.

Auch ein CVSS-Wert von 9,9 löst nicht automatisch bei jedem Kunden einen Emergency Change aus. Das Produkt muss tatsächlich eingesetzt werden. Version, Erreichbarkeit, Ausnutzbarkeit, vorhandene Schutzmaßnahmen und mögliche Folgen gehören zur Entscheidung. Ein hoher Wert in einem Herstellernewsletter ist ein Anlass zur Prüfung, kein ferngesteuerter Patchbefehl.

Alles läuft irgendwann in einen Change

Genau hier zeigt sich das Schweizer Taschenmesser:

• Ein Service Request bestellt eine vereinbarte Änderung.
• Ein Incident kann eine Änderung benötigen, um den Dienst wiederherzustellen.
• Ein Problem kann zu einer dauerhaften Änderung führen, die seine Ursache beseitigt.
• Eine Schwachstelle kann Patch, Konfigurationsanpassung oder kompensierende Maßnahme auslösen, auch diese sind Änderungen an Systemen.
• Ein Herstellerhinweis kann eine notwendige Änderung an betreuten Systemen ankündigen.
• Eine interne Verbesserung kann Monitoring, Backup oder Betriebsablauf verändern.

Der Beitrag Service Request oder Incident? erklärt, weshalb diese Auslöser zunächst unterschiedliche Vorgänge bleiben. Der Change verbindet sie mit der tatsächlichen Veränderung, ohne sie in einen universellen Sammeltopf zu kippen.

Beim wiederkehrenden Terminalserverausfall aus unserem Artikel über Problem Management für IT-Dienstleister könnte das so aussehen: Das Problem-Ticket enthält Ursachenanalyse und betroffene ähnliche Systeme. Der verknüpfte Change steuert Patch, Freigabe, Umsetzung, Rückweg und Ergebnis für die konkrete Kundenumgebung.

Der Change gehört zum betroffenen Asset

Ein Change ohne Verbindung zum betroffenen System verschenkt einen großen Teil seines Nutzens.

Wenn der Vorgang mit dem Asset oder technisch verwalteten Bestandteil verbunden ist – in der ITIL-Sprache häufig Configuration Item oder CI genannt –, entsteht mit der Zeit eine technische Lebensgeschichte:

• wann das System eingerichtet wurde;
• welche Konfigurationen verändert wurden;
• welche Incidents und Probleme Änderungen ausgelöst haben;
• welche Patches, Umbauten oder Erweiterungen durchgeführt wurden;
• welche Changes erfolgreich waren oder zurückgerollt werden mussten;
• wann Komponenten wiederholt ausgetauscht wurden.

Das setzt eine brauchbare Asset- und Konfigurationssicht für den Kundenbetrieb voraus. Der Server muss nicht nur „der bei Müller“ heißen. Das Team muss den Change dem richtigen System und der richtigen Kundenverantwortung zuordnen können.

Aus Change-Historie wird Beschaffungswissen

Mit der Verbindung zu Assets kann der IT-Dienstleister mehr tun als einzelne Änderungen nachweisen. Er kann den eigenen Betrieb auswerten.

Angenommen, Produktserie A wird bei zwölf Kunden eingesetzt und erzeugt laufend Störungen, Treiberwechsel, Neustarts und Austausch-Changes. Produktserie B läuft in vergleichbaren Umgebungen weitgehend unauffällig. Dann ist das eine interessante Information für kommende Projekte.

Vielleicht wird Serie A künftig nicht mehr beschafft. Vielleicht werden vorhandene Geräte früher ersetzt. Vielleicht zeigt die Analyse aber auch, dass nicht das Produkt, sondern eine bestimmte Konfiguration oder Einsatzumgebung die Probleme verursacht.

Die reine Zahl der Changes reicht deshalb nicht. Ein häufig erweitertes System kann viele Changes haben und trotzdem hervorragend funktionieren. Aussagekräftig werden beispielsweise:

• Change-Anzahl im Verhältnis zur Zahl eingesetzter Geräte;
• Störungen und ungeplante Changes;
• benötigte Arbeitszeit;
• Rückrollquote;
• wiederkehrende Ursachen;
• Alter, Version und Einsatzbedingungen;
• Auswirkungen auf den Kundenbetrieb.

So wird aus operativer Dokumentation echtes Lernen. Der Dienstleister entscheidet bei der nächsten Beschaffung nicht allein nach Einkaufspreis und Bauchgefühl, sondern auch nach den Wartungserfahrungen aus seinen Kundenmandaten. Welche erarbeiteten Lösungen das Team anschließend wiederverwenden kann, behandelt unser Beitrag zum Wissensmanagement für IT-Dienstleister.

Was in einem Change mindestens stehen sollte

Der Umfang darf zur Änderung passen. Ein Mauswechsel braucht keine Abhandlung, eine neue Internetfreigabe etwas mehr.

Mindestens erkennbar sein sollten:

1. Anlass und gewünschtes Ergebnis;
2. Kunde, Service und betroffenes Asset;
3. Anforderer und notwendige Autorisierung;
4. Change-Art und Dringlichkeit;
5. mögliche Auswirkungen und Abhängigkeiten;
6. geplanter Umsetzungsweg;
7. erforderliche Prüfung oder Erfolgskontrolle;
8. Rückfallmöglichkeit, soweit sinnvoll und machbar;
9. Verantwortlicher und Zeitpunkt;
10. Kundenkommunikation und tatsächliches Ergebnis.

Bei einem Standard Change können viele dieser Punkte bereits in der vorab genehmigten Vorlage stehen. Die einzelne Durchführung dokumentiert dann nur noch Kunde, Asset, Zeitpunkt, Bearbeiter und Ergebnis. Das ist nicht weniger kontrolliert. Es ist vernünftig wiederverwendet.

Was A.8.32 damit zu tun hat

ISO 27001 A.8.32 behandelt die Änderungssteuerung für Informationsverarbeitungseinrichtungen und Informationssysteme. Änderungen sollen angemessen gesteuert werden. Genau dafür liefert der abgestufte Change-Prozess eine praktische Umsetzung.

Die Norm schreibt weder ITIL-Begriffe noch ein bestimmtes Ticketsystem oder ein aufwendiges Freigabegremium vor. Sie erwartet auch keine identische Behandlung jeder Änderung. Entscheidend ist, dass sicherheitsrelevante technische Änderungen nicht unkontrolliert zwischen Telefonat und Feierabend verschwinden.

A.8.9 zum Konfigurationsmanagement unterstützt den Zusammenhang: Relevante Konfigurationen sollen festgelegt und beherrscht werden. Changes zeigen, weshalb und wie sich dieser Zustand verändert hat. Die ISO beschreibt Konfigurationsmanagement entsprechend als wichtige Grundlage, um Änderungen sichtbar zu halten und unbefugte oder fehlerhafte Veränderungen zu vermeiden.

Unser allgemeiner Artikel zum Änderungsmanagement nach ISO 27001 grenzt außerdem technische Changes nach A.8.32 von geplanten Änderungen am ISMS nach Abschnitt 6.3 ab. Für diesen Beitrag reicht die Kurzfassung: Hier geht es um die Kunden-IT, nicht um den Umbau Ihres Managementsystems.

Typische Fehler

Jede Kleinigkeit braucht dieselbe Freigabe

Dann umgehen Mitarbeiter das Verfahren oder warten wegen einer Maus auf den Geschäftsführer. Standard Changes sind die vorgesehene Entlastung.

Standard Change bedeutet freie Fahrt

Ohne definierte Grenzen, Ablauf und Vorabfreigabe ist es kein Standard Change. Es ist nur Gewohnheit mit einem professionell klingenden Namen.

Emergency Change bedeutet keine Regeln

Gerade im Notfall müssen Entscheidungsbefugnis, Kommunikation und Rückweg klar sein. Sonst ergänzt der Dienstleister die ursprüngliche Krise um eine selbst verursachte.

Genehmigt bedeutet erledigt

Der Change wurde freigegeben und umgesetzt. Ob das gewünschte Ergebnis eintrat, prüft niemand. Eine Erlaubnis ist noch kein Wirksamkeitsnachweis.

Das Asset fehlt

Dann existieren hundert Change-Tickets, aber niemand kann zeigen, was an einem bestimmten Server oder einer Produktserie bereits verändert wurde.

Die Historie wird nie ausgewertet

Das Unternehmen dokumentiert jahrelang Wartungsaufwand und Rückrollen, kauft aber weiterhin dieselben auffälligen Komponenten. Dann dient die Historie nur dem Archiv, nicht dem Betrieb.

So starten Sie pragmatisch

Nehmen Sie die letzten 30 technischen Änderungen aus echten Kundenmandaten. Sortieren Sie nicht nach Lehrbuch, sondern nach dem tatsächlichen Aufwand.

1. Welche Änderungen waren wiederkehrend, verstanden und risikoarm?
2. Welche davon können als Standard Change vorab freigegeben werden?
3. Welche benötigten eine fallbezogene Bewertung?
4. Welche echten Notfälle traten auf und wer durfte entscheiden?
5. Waren Auslöser und betroffenes Asset jeweils verknüpft?
6. Wurden Ergebnis und gegebenenfalls Rückrolle dokumentiert?
7. Welche Assets oder Produktarten tauchten auffällig oft auf?

Definieren Sie anschließend wenige Standard Changes, einen schlanken Normal-Change-Weg und eine erreichbare Emergency-Entscheidung. Verbinden Sie neue Changes konsequent mit den betroffenen Assets. Mehr braucht es für einen brauchbaren Start nicht.

Damit erhält Ihr ISMS für IT-Dienstleister keinen weiteren dekorativen Prozess. Es erhält eine gemeinsame Stelle, an der der Kundenbetrieb Änderungen entscheidet, durchführt und aus ihnen lernt.

Interesse geweckt?

Sie möchten technische Änderungen im Kundenbetrieb schnell steuern, ohne Freigaben, Rückwege und wertvolle Betriebserfahrung zu verlieren? Sprechen Sie mit uns.