Bundesamt für Sicherheit in der Informationstechnik

M 2.426 Integration des Patch- und Änderungsmanagements in die Geschäftsprozesse

Verantwortlich für Initiierung: Änderungsmanager, Behörden-/Unternehmensleitung

Verantwortlich für Umsetzung: Änderungsmanager

Je nach Art der durchgeführten Änderungen kann es notwendig sein, dass eine Anwendung oder ein IT-System neu gestartet werden muss, was zur Folge hat, dass diese über einen kurzen Zeitraum nicht im Produktivbetrieb benutzt werden können. Darüber hinaus können auch sorgfältig durchgeführte Tests nicht immer vermeiden, dass es zu Schwierigkeiten bei der betroffenen Anwendung oder gar zum Stillstand und damit Ausfall eines Systems durch die Verteilung von Hard- oder Software-Änderungen kommen kann.

Aus diesem Grund ist, unabhängig von durchgeführten Tests, auch die aktuelle Situation der betroffenen Geschäftsprozesse zu berücksichtigen. Es kann z. B. durchaus sinnvoll sein, eine Hard- oder Software-Änderung ein paar Tage später durchzuführen, obwohl das betroffene System zum aktuellen Zeitpunkt als sicherheitskritisch eingestuft wird. Eventuell werden durch das System wichtige Dienstleistungen erbracht, auf die die Institution angewiesen ist. Die Leitungsebene könnte das Risiko einer Unterbrechung von Geschäftsprozessen durch das Patch- und Änderungsmanagement höher bewerten als das Risiko durch eine noch nicht geschlossene Schwachstelle.

Um Hard- und Software-Änderungen zu verteilen, ist es daher notwendig, alle Beteiligten bezüglich der kommenden Änderungen und der zu erwartenden Ausfallzeiten zu benachrichtigen. Zu den einzelnen Parteien gehören alle Fachabteilungen, die das System benötigen. Insbesondere Fachabteilungen, deren Aufgabenerfüllung von den betroffenen Anwendungen und IT-Systemen abhängig ist, müssen in die Priorisierung von Änderungen und in die Terminfindung einbezogen werden.

Es muss mindestens eine Eskalationsebene über dem Änderungsmanager und dem CAB existieren, welche notfalls die Entscheidung über die Priorisierung (siehe M 2.422 Umgang mit Änderungsanforderungen ), übernimmt. Diese Eskalationsebene muss aus der Leitungsebene der Institution gewählt werden.

Prüffragen:

  • Wird die aktuelle Situation der von geplanten Änderungen betroffenen Geschäftsprozesse berücksichtigt?

  • Werden die relevanten Fachabteilungen über anstehende Änderungen informiert?

  • Gibt es eine Eskalationsebene, deren Mitglieder aus der Leitungsebene der Institution sind, die in Zweifelsfällen Entscheidungen bezüglich der Priorität und Terminplanung einer Hard- oder Software-Änderung treffen kann?

Stand: 13. EL Stand 2013