ISO 27002Kapitel 8.32 Änderungsmanagement

Worum geht es?

Im Alltag sind Änderungen im Bereich der IT unvermeidlich: neue Systeme, Releases, Patches, Konfigurationsanpassungen oder der Austausch von Komponenten. All dies erzeugt schnell Risiken – etwa durch fehlende Abstimmung, unklare Verantwortlichkeiten oder unzureichende Tests.

Geeignetes Change-Management sorgt dafür, dass Änderungen kontrolliert vorbereitet, bewertet, freigegeben, umgesetzt und dokumentiert werden. Dadurch sollen Vertraulichkeit, Integrität und Verfügbarkeit geschützt und gleichzeitig nachvollziehbar werden, wer was wann warum geändert hat.

In gut aufgestellten Organisationen wird hierfür ein formaler Änderungsantrag (Request for Change, RFC) genutzt, über das Informationen, Entscheidungen und Nachweise zusammenlaufen.

Was empfiehlt die ISO 27002?

Laut Kapitel 8.32 der ISO 27002 sollte es für neue Systeme und für relevante Änderungen an bestehenden Systemen klare Vorgaben geben:

• Alle Anforderungen und Änderungsvorhaben sind zu beschreiben;
• Risiken und Auswirkungen müssen beurteilt werden;
• Tests sind vorzusehen und auch nachweislich durchzuführen.

Erst wenn all dies erledigt ist, erfolgen Freigabe und Umsetzung.

Üblich und sinnvoll ist zudem eine Einordnung (Kategorisierung) und Gewichtung (Priorisierung) von Changes – z. B. nach ihrem Typ (Standard/Normal/Notfall) sowie nach Auswirkung und Dringlichkeit  – um den passenden Freigabeweg, die Planung und die erforderlichen Kontrollen festzulegen. Die beteiligten Rollen (z. B. Antragsteller, Umsetzer, Freigebender) müssen im Vorfeld eindeutig festgelegt und zugewiesen sein.

Ein normkonformes Änderungsmanagement berücksichtigt typischerweise mindestens die folgenden Aspekte:

1. Änderung vorbereiten und Auswirkungen bewerten – inklusive technischer und organisatorischer Abhängigkeiten. Vor einem Datenbank-Upgrade sollte beispielsweise eine Abhängigkeitsliste erstellt werden (etwa zu Schnittstellen, Batch-Jobs, Monitoring), und es wird abgeschätzt, was im Fehlerfall passiert. In diesem Schritt erfolgt häufig auch die Kategorisierung (Standard/Normal/Notfall) sowie eine erste Einstufung von Auswirkung und Dringlichkeit als Grundlage für die spätere Priorisierung.
2. Vor der Umsetzung muss grundsätzlich eine explizite Freigabe eingeholt werden; je nach Risiko durch vorbestimmte Rollen bzw. Gremien. Sehr risikoarme Changes könnten auch durch den Service Owner selbst freigegeben werden; kritischere Changes müssten zusätzlich über Change Manager oder sogar weitere Personen/Teams laufen. Die Priorisierung beeinflusst, wie schnell der Change durch den Prozess geführt und wann er umgesetzt wird (z. B. im nächsten Wartungsfenster vs. kurzfristig). Notfallchanges müssen ggf. beschleunigt freigegeben werden, aber dennoch mit klar definierten Mindestanforderungen (z. B. zwingende Risikoabschätzung, dokumentierte Entscheidung, nachgelagerte Nachweise).
3. Betroffene Stakeholder sollten immer rechtzeitig informiert werden. So sollte es selbstverständlich sein, Wartungsfenster vorab anzukündigen und Nutzern eine kurze Info zu möglichen Einschränkungen zu geben.
4. Änderungen sind zu testen und die Testergebnisse abzunehmen. Ohne Testnachweis erfolgt keine produktive Umsetzung.
5. Die Umsetzung sollte dann geplant durchgeführt werden (inkl. Zeitfenster, Schritte, Zuständigkeiten). Es ist auch sinnvoll, ggf. klare Kriterien für einen Abbruch festzulegen. In der Praxis unterstützt eine Priorisierung dabei, Changes in Change-Kalendern/Wartungsfenstern zu bündeln und Kollisionen mit anderen Vorhaben oder kritischen Betriebsphasen zu vermeiden.
6. An Notfall- und Ausweichoptionen sollte gedacht sein (inkl. Rückfall- und Umgehungswege).
   Falls die Umsetzung abgebrochen wird oder fehlschlägt, sollte ein Plan vorhanden sein, wie der vorherige Zustand wieder erreicht werden kann. Ein Fallback-/Rollback-Plan sollte dabei möglichst konkret sein (z. B. Wiederherstellung aus Backup/Snapshot, Rückkehr auf vorherige Version, Konfigurationsrücknahme), inkl. Verantwortlichkeiten, maximal tolerierbarer Downtime sowie klarer Entscheidungspunkte, ab wann zurückgerollt wird.
7. Änderungen vollständig protokollieren; von Planung bis Ergebnis. Üblich sind Change-Tickets mit Risikoabschätzung, Freigaben, Testnachweise, Umsetzungslog, Zeitpunkt und ggf. Nacharbeiten/Lessons Learned. Für wesentliche oder risikoreiche Changes ist außerdem ein Post-Implementation Review (PIR) sinnvoll bzw. üblich: Wurde das Ziel erreicht, gab es Abweichungen/Incidents, sind Maßnahmen offen, und müssen Standards/Checklisten angepasst werden?
8. Falls sich Abläufe ändern, müssen Betriebsdokumentation und Benutzeranleitungen aktualisiert und alte Versionen aus dem Verkehr gezogen werden.
9. Auch Kontinuitäts-, Reaktions- und Wiederherstellungsunterlagen sind nachzuziehen, falls die Änderung relevante Auswirkungen hat.

Fazit

In der Praxis entstehen viele Incidents nicht durch Hacker, sondern durch schlecht oder gar nicht gesteuerte Änderungen: ein Update zur falschen Zeit, eine Konfiguration ohne Review oder ein Release ohne ausreichenden Test. Besonders heikel ist die produktive Umgebung – hier können schon kleine Eingriffe Verfügbarkeit und Datenintegrität beeinträchtigen.

Ein gutes Änderungsmanagement macht Änderungen beherrschbar. Es reduziert Ausfälle und Sicherheitsrisiken, weil vor der Umsetzung geprüft und entschieden wird – und weil im Nachhinein klar ist, was geändert wurde.

Organisationen sollten daher prüfen,

• ob ein klar definierter Change-Prozess für Infrastruktur und Anwendungen existiert (inkl. RFC/Change-Ticket als verbindlicher Dokumentations- und Freigabenachweis),
• ob Auswirkungen/Abhängigkeiten, Tests und Freigaben vor produktiven Änderungen nachvollziehbar belegt sind (inkl. Kategorisierung und Priorisierung nach Impact/Dringlichkeit),
• ob Änderungen geplant umgesetzt werden und ein praktikabler Rückfallweg vorbereitet ist,
• ob Protokolle sowie Betriebs- und Notfalldokumente nach Änderungen zuverlässig aktualisiert werden (und ob für Notfallchanges ein nachgelagerter Review/PIR stattfindet).