Freitagabend, 18 Uhr: Der Administrator aktualisiert die Firewall-Firmware — ohne Change Request, ohne Testlauf, ohne Rollback-Plan. Am Montagmorgen funktioniert der VPN-Zugang nicht mehr. 200 Mitarbeitende im Homeoffice können nicht arbeiten. Die Ursache: Eine neue Firmware-Version hat das VPN-Profil zurückgesetzt. A.8.32 existiert, damit genau das nicht passiert: Jede Änderung an IT-Systemen folgt einem kontrollierten Prozess mit Planung, Genehmigung, Test und Rollback-Option.
Was verlangt die Norm?
- Formaler Änderungsprozess. Alle Änderungen an Informationsverarbeitungseinrichtungen folgen einem definierten Verfahren.
- Planung und Auswirkungsanalyse. Jede Änderung wird geplant und ihre Auswirkung bewertet — einschließlich Sicherheitsauswirkungen.
- Genehmigung. Änderungen werden von einer autorisierten Person genehmigt, bevor sie umgesetzt werden.
- Test und Validierung. Änderungen werden vor der Umsetzung getestet und nach der Umsetzung validiert.
- Dokumentation. Jede Änderung wird dokumentiert: Was, Warum, Wann, Wer, Ergebnis.
- Rollback-Plan. Für jede Änderung existiert ein Plan zur Rückkehr zum vorherigen Zustand.
In der Praxis
Change-Request-Formular standardisieren. Ein einheitliches Formular für alle Änderungsanträge: Beschreibung, Begründung, betroffene Systeme, Risikobewertung, Testplan, Rollback-Plan, Zeitfenster. Das Formular stellt sicher, dass nichts vergessen wird.
Change Advisory Board (CAB) einrichten. Für mittlere und große Organisationen: Ein wöchentliches oder bi-wöchentliches Meeting, in dem anstehende Änderungen besprochen, bewertet und genehmigt werden. Für kleine Organisationen reicht ein vereinfachtes Genehmigungsverfahren.
Wartungsfenster definieren. Änderungen mit Ausfallpotenzial werden in definierten Wartungsfenstern durchgeführt — typischerweise außerhalb der Geschäftszeiten. Kommunikation der Wartungsfenster an alle Betroffenen.
Post-Implementation Review. Nach jeder Änderung: Hat die Änderung das gewünschte Ergebnis erzielt? Sind unerwartete Auswirkungen aufgetreten? Was kann beim nächsten Mal besser laufen? Die Ergebnisse fließen in die Prozessverbesserung.
Typische Audit-Nachweise
- Change-Management-Richtlinie — dokumentierter Prozess für Änderungen (→ Konfigurations- und Änderungsmanagement im Starter Kit)
- Änderungsprotokoll — vollständige Historie aller Änderungen (→ Änderungsprotokoll im Starter Kit)
- Change Requests — ausgefüllte Anträge mit Genehmigung
- Test- und Validierungsergebnisse — Nachweis, dass Änderungen getestet wurden
- CAB-Protokolle — Dokumentation der Change-Advisory-Board-Entscheidungen
KPI
Anteil der Änderungen mit formalem Change-Management und Sicherheitsbewertung
Gemessen als Prozentsatz: Wie viele deiner Änderungen haben den definierten Change-Prozess durchlaufen? Ziel: über 95% (unter 100% wegen dokumentierter Notfalländerungen).
Ergänzende KPIs:
- Anzahl der fehlgeschlagenen Änderungen pro Quartal (Ziel: abnehmend)
- Anteil der Änderungen mit funktionierendem Rollback-Test
- Mittlere Durchlaufzeit eines Change Requests
BSI IT-Grundschutz
- OPS.1.1.3 (Patch- und Änderungsmanagement) — der Kernbaustein. Verlangt einen dokumentierten Änderungsprozess, Genehmigungsverfahren, Tests, Dokumentation und Rollback-Fähigkeit.
Verwandte Kontrollen
- A.8.9 — Konfigurationsmanagement: Definiert den Soll-Zustand, den Änderungen verändern.
- A.8.8 — Verwaltung technischer Schwachstellen: Patches als Spezialfall von Änderungen.
- A.8.31 — Umgebungstrennung: Änderungen durchlaufen die Umgebungen (Dev → Test → Prod).
Quellen
- ISO/IEC 27001:2022 Annex A, Control A.8.32 — Änderungsmanagement
- ISO/IEC 27002:2022 Abschnitt 8.32 — Umsetzungshinweise
- BSI IT-Grundschutz, OPS.1.1.3 — Patch- und Änderungsmanagement