IT-Change-Management-Prozess (SOC 2 CC8.1)

Was ist it-change-management-prozess (soc 2 cc8.1)?

Change Management wird fast immer als der lange Weg dokumentiert: Antrag, Bewertung, Sitzung des Change Advisory Board, Freigabe, Test, Release. Und dann läuft der Großteil der tatsächlichen Änderungen an diesem Weg vorbei, weil er vier Tage dauert. Falsch ist nicht der Prozess. Falsch ist, dass er nur einen einzigen Pfad kennt.

Ein Diagramm, das einen Walkthrough übersteht, hat deshalb drei Spuren: Standardänderungen, die vorab freigegeben sind und ohne Einzelfreigabe laufen, normale Änderungen, die Bewertung und Freigabe durchlaufen, und Notfalländerungen, die zuerst ausgerollt und danach freigegeben werden dürfen, innerhalb einer Frist und mit dokumentierter Begründung. Die Klassifizierung ist die erste Entscheidung im Ablauf, keine Randnotiz in der Verfahrensanweisung.

Das Zweite, was ein Auditor prüft, ist die Funktionstrennung: Darf die Person, die eine Änderung entwickelt hat, sie selbst in die Produktivumgebung bringen? Diese Frage beantwortet nur ein Diagramm, in dem Freigabe und Deployment in getrennten Swimlanes mit jeweils eigener verantwortlicher Rolle liegen.

Was dieses Flussdiagramm abdeckt

In dieser Vorlage

• Der Änderungsantrag: wer antragsberechtigt ist, was beschrieben werden muss (Zweck, betroffene Systeme und Rücksetzplan) und wie der Antrag erfasst wird
• Klassifizierung in Standardänderung, normale Änderung und Notfalländerung, die Verzweigung, die festlegt, welchen Freigabeweg eine Änderung nimmt
• Auswirkungs- und Risikoanalyse: betroffene Systeme und Daten, erwartete Ausfallzeit, Abhängigkeiten und Auswirkungen auf die Informationssicherheit
• Freigabe durch den Change Manager oder das Change Advisory Board (CAB), mit einem eigenen Zweig für abgelehnte und zurückgestellte Änderungen
• Test und Abnahme in der Testumgebung, einschließlich der Anforderung eines dokumentierten Rücksetzplans, bevor die Änderung freigegeben wird
• Deployment mit Funktionstrennung zwischen Entwicklung und Freigabe, anschließende Verifikation, Rollback im Fehlerfall und eine abschließende Nachbetrachtung der Notfalländerungen

Wann Sie diese Vorlage verwenden sollten

• Sie stehen vor einem SOC-2-Audit, in dem der CC8.1-Walkthrough genau eine Frage stellt: Wie gelangt eine Änderung in die Produktivumgebung?
• Notfalländerungen sind zum Normalweg geworden, weil der formale Prozess zu langsam ist, und Sie wollen sichtbar machen, warum
• Entwicklerinnen und Entwickler bringen ihre eigenen Änderungen in Produktion, und Sie müssen die Funktionstrennung entweder belegen oder einführen
• Sie nutzen Jira oder ServiceNow für die einzelnen Vorgänge, haben aber keine gelenkte Beschreibung des Prozesses selbst
• SOC 2 CC8.1 und ISO 27001 A.8.32 sollen beide abgedeckt sein, und Sie wollen einen Prozess statt zweier Beschreibungen, die Unterschiedliches behaupten

Dokumentierte Controls

• CC8.1
• ISO 27001 A.8.32

So funktioniert es

1. Beginnen Sie mit der Klassifizierung

   Definieren Sie Standardänderung, normale Änderung und Notfalländerung mit konkreten Beispielen aus Ihren eigenen Systemen. Eine Klassifizierung, die niemand ohne Rückfrage anwenden kann, wird in der Praxis für alles zu „normal“.

2. Geben Sie Standardänderungen vorab frei

   Führen Sie eine Liste der Änderungen, die risikoarm und wiederkehrend sind, und lassen Sie sie ohne Einzelfreigabe laufen. Nur so bleibt der formale Weg für das reserviert, wofür er gedacht ist.

3. Trennen Sie Freigabe und Deployment

   Beide Schritte gehören in getrennte Swimlanes mit jeweils eigener verantwortlicher Rolle. Genau das prüft ein SOC-2-Walkthrough zuerst, und genau das lässt sich im Nachhinein kaum noch belegen.

4. Zeichnen Sie den Notfallweg mit seiner Frist

   Eine Notfalländerung darf vor der Freigabe ausgerollt werden, aber die nachträgliche Freigabe und Bewertung braucht eine Frist, die am Knoten steht. Ohne Frist ist der Notfallweg eine Umgehung.

5. Enden Sie in der Nachbetrachtung

   Ergänzen Sie den Schritt, in dem fehlgeschlagene und zurückgerollte Änderungen ausgewertet werden. Dort werden die Muster hinter misslungenen Deployments sichtbar, und genau dieser Schritt fehlt am häufigsten.

Häufig gestellte Fragen

Was verlangt SOC 2 CC8.1 zum Change Management?

CC8.1 (Änderungen mit Auswirkung auf das System) verlangt dokumentierte Verfahren zur Bewertung, Freigabe, zum Test und zum Ausrollen von Änderungen, sowie den Nachweis, dass das Verfahren für die im Auditzeitraum gezogenen Stichproben tatsächlich eingehalten wurde.

Worin unterscheidet sich QueryChart von einem Ticketsystem wie Jira im Change Management?

Ticketsysteme verfolgen die einzelnen Änderungsvorgänge; sie dokumentieren nicht die gelenkte, aktuell gültige Fassung des Change-Management-Prozesses selbst. QueryChart dokumentiert den Prozess (das gelenkte Dokument), damit Auditoren das Design sehen, bevor sie den Betrieb in Jira oder ServiceNow stichprobenartig prüfen.

Was ist der Unterschied zwischen Standardänderung, normaler Änderung und Notfalländerung?

Eine Standardänderung ist risikoarm, wiederkehrend und vorab freigegeben, etwa eine routinemäßige Zertifikatserneuerung. Eine normale Änderung durchläuft Auswirkungsanalyse und Freigabe, bevor sie ausgerollt werden darf. Eine Notfalländerung behebt eine akute Betriebsstörung und darf zuerst ausgerollt werden, sofern Freigabe und Bewertung innerhalb einer festgelegten Frist nachgeholt werden. Alle drei Spuren müssen im Diagramm stehen, sonst beschreibt es nicht den Prozess, der tatsächlich gelebt wird.

Muss jede Änderung durch das Change Advisory Board (CAB)?

Nein, und ein CAB, das alles behandelt, wird zum Engpass, an dem die Organisation vorbeiarbeitet. Lassen Sie das Gremium die Änderungen bewerten, die bereichsübergreifend sind, Kunden betreffen oder Ausfallzeit erfordern, und lassen Sie die übrigen von einem namentlich benannten Change Manager freigeben. Für den Auditor entscheidend ist, dass das Kriterium für die CAB-Pflicht im gelenkten Prozess steht, nicht, dass das Gremium alles gesehen hat.