Grundschutz++ Änderungsmanagement: die Praktik Änderungen und Tests (TEST)
Grundschutz++ Änderungsmanagement verständlich: was die Praktik TEST zu Tests, Freigabe und Rollout verlangt und wie kleine Betriebe sinnvoll einsteigen.
Beim Grundschutz++ Änderungsmanagement geht es um eine einfache Frage: Wie stellen Sie sicher, dass eine Änderung an Ihrer IT nicht mehr kaputt macht, als sie verbessert? Die Praktik «Änderungen und Tests» (Kürzel TEST) im neuen IT-Grundschutz des BSI regelt, wie neue Programme, Updates, Umbauten oder das Abschalten alter Geräte geplant, getestet, freigegeben und eingeführt werden.
Warum das wichtig ist
Viele Ausfälle entstehen nicht durch Angreifer, sondern durch gut gemeinte Änderungen: ein Update, das die Warenwirtschaft lahmlegt, eine neue Firewall-Regel, die den Fernzugang kappt, ein Server, der ohne Absprache neu gestartet wird. Wer Änderungen geregelt durchführt, vermeidet solche Störungen und kann im Ernstfall schnell zum alten Stand zurück.
Was verbindlich ist
Verpflichtend sind die Grundlagen: Es muss festgelegte Abläufe für Änderungen geben, sie müssen aufgeschrieben, Zuständigen zugewiesen, bekannt gemacht und regelmäßig überprüft werden. Weitere Empfehlungen betreffen Folgenabschätzung, Tests, Freigabe, einen Rückfallplan und die Information der Betroffenen.
Der erste Schritt
Legen Sie fest, wer im Betrieb Änderungen an der IT vornehmen darf und wer sie vorher absegnet. Halten Sie in einer einfachen Liste fest, was wann geändert wurde und wie man es rückgängig macht. Das ist bereits der Kern eines Änderungsverfahrens.
Die Praktik «Änderungen und Tests» (TEST) ist der Teil des Anwenderkatalogs Grundschutz++, der das klassische Change Management abdeckt. Dieser Artikel erklärt das Grundschutz++ Änderungsmanagement anhand des Katalogstands vom 22. Oktober 2026: Ziel, Gruppen, verbindliche Anforderungen, Nachweise und einen praxistauglichen Einstieg.
Ziel der Praktik
Der Katalog beschreibt das Ziel so: Die Praktik stellt sicher, «dass alle geplanten Veränderungen an Informationssystemen systematisch und kontrolliert ablaufen, um ungewollte Störungen, Sicherheitsrisiken oder Compliance-Verstöße zu vermeiden (Change Management)». Sie umfasst die Vorbereitung, Planung und Durchführung von Tests, die Freigabe und den Rollout von Änderungen sowie die begleitende Dokumentation.
Erfasst sind nicht nur Änderungen im engeren Sinn. Bereits die erste MUSS-Anforderung nennt Neueinführungen, Änderungen und die Entfernung von Komponenten.
Aufbau: fünf Gruppen, 36 Anforderungen
| Gruppe | Inhalt |
|---|---|
| TEST.1 Grundlagen | Verfahren und Regelungen, Zuständigkeiten, Überprüfung, Einschränkung von Änderungen auf Administrierende |
| TEST.2 Vorbereitung | Versionshistorie, Folgenabschätzung, Kategorisierung, Dokumentation von Änderungen und Abhängigkeiten |
| TEST.3 Tests | Sicherheitstests, Testdaten, Testumgebung, Integrität von Softwareartefakten, Testabdeckung; bei erhöhter Stufe unter anderem Lasttests, Fuzzing, Chaos Engineering |
| TEST.4 Freigabe | Autorisierung kritischer Änderungen, Staging, Freigabedokumentation, Rückfalllösung, Notfalländerungen |
| TEST.5 Bereitstellung | Information Betroffener, verschlüsselte Bereitstellung, stufenweiser Rollout, Persistenz, Rückblick |
Die verbindlichen MUSS-Anforderungen
Alle fünf MUSS-Anforderungen der Praktik stehen in der Gruppe TEST.1 und betreffen das Verfahren selbst:
TEST.1.1 «Änderungen und Tests MUSS Verfahren und Regelungen zum Management von Neueinführungen, Änderungen oder der Entfernung von Komponenten für den Informationsverbund, pro Geschäftsprozess oder pro IT-System verankern.»
TEST.1.1.1 «Änderungen und Tests MUSS die Verfahren und Regelungen dokumentieren.»
TEST.1.1.2 «Änderungen und Tests MUSS die mit den Verfahren und Regelungen verbundenen Aufgaben zuständigen Personen oder Rollen zuweisen.»
TEST.1.1.3 «Änderungen und Tests MUSS die zuständigen Personen oder Rollen über die Verfahren und Regelungen informieren.»
TEST.1.2 «Änderungen und Tests MUSS die Verfahren und Regelungen regelmäßig und anlassbezogen auf Aktualität überprüfen.»
MUSS bedeutet nach der Begriffsdefinition der Stand-der-Technik-Bibliothek eine uneingeschränkte Anforderung. Die eigentliche Ausgestaltung, also wie getestet und freigegeben wird, ist überwiegend als SOLLTE formuliert. SOLLTE heißt laut BSI, dass eine Anforderung «normalerweise erfüllt werden muss», Abweichungen aber «sorgfältig abgewogen und stichhaltig begründet» werden müssen.
Wichtige SOLLTE-Anforderungen
TEST.2.2 «Änderungen und Tests für Administrierende SOLLTE zu einer strukturierten Folgenabschätzung vor wesentlichen Änderungen anweisen.»
TEST.3.1 «Änderungen und Tests SOLLTE vor wesentlichen Änderungen die Einhaltung der Sicherheitsanforderungen testen.»
TEST.3.1.4 «Änderungen und Tests SOLLTE die Testfälle abdeckende, aber unkritische Testdaten verankern.»
TEST.4.1 «Änderungen und Tests SOLLTE kritische Änderungen anhand von Kriterien einschließlich der Sicherheitsanforderungen autorisieren.»
TEST.4.3 «Änderungen und Tests SOLLTE eine Rückfallösung verankern.»
TEST.4.4 «Änderungen und Tests SOLLTE Regelungen für Notfalländerungen einschließlich Vorgehensweise, Zuständigkeiten, erforderlicher Ressourcen und minimaler Prüfschritte verankern.»
Die Notfalländerung verdient Beachtung: Gerade bei kritischen Sicherheitsupdates muss es schnell gehen. Der Katalog verlangt dafür kein Aussetzen des Verfahrens, sondern ein eigenes, verkürztes Verfahren mit minimalen Prüfschritten.
Normale und erhöhte Sicherheitsstufe
Jede Anforderung ist einer Sicherheitsstufe zugeordnet: «normal-SdT» (Standard-Sicherheitsstufe) oder «erhöht». In TEST gehören 27 Anforderungen zur normalen Stufe (5 MUSS, 22 SOLLTE) und 9 zur erhöhten Stufe, alle als KANN formuliert. KANN-Anforderungen sind nach BSI keine generelle Verpflichtung, sondern zeigen Maßnahmen, die «je nach Situation (d.h. nach Risikoanalyse) sinnvoll sein» können.
Zur erhöhten Stufe gehören unter anderem kontinuierliche automatische Tests (TEST.3.1.6), Chaos Engineering (TEST.3.1.7), Fuzzing (TEST.3.1.9), Lasttests (TEST.3.1.10), Penetrationstests bei kritischen Änderungen (TEST.3.1.11), die Autorisierung durch eine von der Implementierung unabhängige Person (TEST.4.1.1), die Signatur der Freigabeerklärung (TEST.4.2) und der stufenweise Rollout (TEST.5.3).
Typische Nachweise
Jede Anforderung nennt im Feld «Dokumentation», wo ihre Umsetzung typischerweise festgehalten wird. In TEST dominieren:
- IT-Betriebskonzept (15 Anforderungen): Verfahren, Folgenabschätzung, Kategorien, Freigabe, Rückfalllösung, Notfalländerungen
- Freigabeplan (10): Testinhalte, Prüfschritte, Ergebnisse, Integritätstests
- Konfigurationshistorie (4): Testdaten, verschlüsselte Bereitstellung, Rollout, Persistenz
- Übungs- und Prüfplan (3): regelmäßige Überprüfung, Testabdeckung, Rückblick
- außerdem Geschäftsverteilungsplan, Audit Log, Ergebnisprotokoll und Systemdokumentation
Betroffene Zielobjekte
Die Anforderungen von TEST sind fast durchgehend ohne Einschränkung auf ein Zielobjekt formuliert. Sie betreffen damit alle Änderungen im Informationsverbund. Einzige Ausnahme ist TEST.2.2 mit dem Zielobjekt «Administrierende».
Bezug zum bisherigen IT-Grundschutz
Im bisherigen Kompendium war das Thema vor allem in den Bausteinen OPS.1.1.3 Patch- und Änderungsmanagement und OPS.1.1.6 Software-Tests und -Freigaben verortet. Der Mapping-Entwurf des BSI vom IT-Grundschutz 2023 zum Grundschutz++ ordnet Anforderungen aus diesen Bausteinen der Praktik TEST zu. Das Patchen selbst findet sich im Grundschutz++ in der Praktik Detektion (Gruppe DET.5) und in der Praktik Konfiguration (Gruppe KONF.8).
Grundschutz++ Änderungsmanagement im kleinen Unternehmen
Ein formales Change Advisory Board braucht ein Betrieb mit zehn Arbeitsplätzen nicht. Die MUSS-Anforderungen lassen sich schlank erfüllen:
- Kurzes Verfahren schreiben: eine Seite im IT-Betriebskonzept, die festlegt, was als wesentliche Änderung gilt, wer Änderungen durchführt und wer sie freigibt.
- Zuständigkeiten benennen: etwa Geschäftsführung als Freigabe für kritische Änderungen, interne IT oder Dienstleister als Durchführende. Bei externer Betreuung gehört das Verfahren in die Vereinbarung mit dem Dienstleister.
- Änderungsprotokoll führen: ein Ticket oder eine Tabelle mit Datum, Änderung, Begründung, Test, Freigabe und Rückweg deckt Versionshistorie, Dokumentation und Freigabenachweis zugleich ab.
- Rückfallplan vorab klären: vor jedem größeren Update eine aktuelle Sicherung oder einen Snapshot anlegen.
- Testumgebung pragmatisch lösen: Oft genügt eine virtuelle Maschine oder ein einzelner Testrechner, auf dem Updates zuerst laufen.
- Jährlich prüfen: das Verfahren einmal im Jahr und nach größeren Störungen durchsehen, das erfüllt TEST.1.2.
Wer Software-Updates über eine zentrale Verwaltung verteilt, kann mit einer kleinen Pilotgruppe beginnen. Das ist im Katalog zwar erst für die erhöhte Stufe als KANN vorgesehen (TEST.5.3), senkt aber auch im kleinen Betrieb das Risiko.
Häufige Fragen
Muss jedes Windows-Update ein formales Änderungsverfahren durchlaufen?
Der Katalog spricht bei Tests, Folgenabschätzung und Freigabe von «wesentlichen» oder «kritischen» Änderungen. Sie legen im Verfahren selbst fest, welche Änderungen darunter fallen. Routine-Updates können als Standardänderung mit vereinfachtem Ablauf geregelt werden.
Was ist der Unterschied zwischen MUSS und SOLLTE in dieser Praktik?
Die MUSS-Anforderungen betreffen nur das Verfahren: verankern, dokumentieren, Aufgaben zuweisen, bekannt machen, regelmäßig überprüfen. Tests, Freigabe und Rollout sind als SOLLTE formuliert. Davon dürfen Sie nur mit sorgfältiger Abwägung und stichhaltiger Begründung abweichen.
Brauche ich eine eigene Testumgebung?
TEST.3.1.5 empfiehlt als SOLLTE eine dedizierte Testumgebung. Wie aufwendig sie sein muss, hängt von Ihren Systemen ab. In kleinen Umgebungen genügt oft ein Testrechner oder eine virtuelle Maschine.
Wie gehe ich mit dringenden Sicherheitsupdates um?
Dafür sieht TEST.4.4 Regelungen für Notfalländerungen vor, mit festgelegter Vorgehensweise, Zuständigkeiten, Ressourcen und minimalen Prüfschritten. Das Verfahren wird also verkürzt, nicht übersprungen.