I 28 - Anhang_19.3_Change_Management_Reportingplattform_V.0.9.pdf

[Seite 1]

Anhang 19.3

Change Management

zu Anlage 19 Servicemanagement

zum Rahmenvertrag vom TT.MM.JJJJ

zwischen

Landesbank Hessen-Thüringen Girozentrale

Neue Mainzer Straße 52 -58

60311 Frankfurt

- nachfolgend Helaba oder Auftraggeber genannt –

und

[Adresszeile 1: Vollständige Firmierung des Auftragnehmers]

[Adresszeile 2: Straße des Auftragnehmers]

[Adresszeile 3: PLZ und Stadt des Auftragnehmers]

- nachfolgend [Kürzel des Auftragnehmers] oder Auftragnehmer ge-

nannt –

– zusammen auch „Vertragspartner“, „Vertragsparteien“ oder „Parteien“

genannt –

Version 0.9

[Seite 2]

Anhang 19.3 – Change Management

INHALTSVERZEICHNIS

1 Gegenstand .................................................................................................. 3

1.1 Abgrenzung des Dokuments .......................................................................... 3

1.2 Begriffsklärung ............................................................................................... 3

2 Leistungsbeschreibung .............................................................................. 3

2.1 Arten von IT-Changes .................................................................................... 3

2.2 Termine und Fristen ....................................................................................... 5

2.3 Bewertung von IT-Changes ........................................................................... 5

2.4 Veränderungen von eingestellten und genehmigten IT-Changes .................. 6

2.5 Test von IT-Changes ..................................................................................... 6

2.6 Leistungen und Verantwortlichkeiten ............................................................. 7

3 Prozesseinbindung und -schnittstellen ..................................................... 8

4 Reporting ...................................................................................................... 8

Seite 2 von 8

[Seite 3]

Anhang 19.3 – Change Management

1 Gegenstand

Gegenstand dieses Anhangs zu Anlage 19 Servicemanagement des Rahmenvertrages ist die Beschreibung von Leistungen und wesentlichen Aufgaben des Auftragnehmers bei der Zusammenarbeit im Change Management sowie die Definition erforderlicher Mitwirkungen durch den Auftraggeber.

1.1 Abgrenzung des Dokuments

Dieses Dokument beschreibt weder die internen Prozesse des Auftraggebers noch die des Auftragnehmers. Die Ausgestaltung der Prozesse des Auftraggebers verbleibt in der Hoheit des Auftraggebers ebenso wie die Ausgestaltung der Prozesse des Auftragnehmers in der Hoheit des Auftragnehmers verbleibt. Wechselseitige Ansprüche beschränken sich auf die Einhaltung bzw. Erfüllung der hier vereinbarten Abläufe, Schnittstellen und Rollen.

Die Regelungen dieses Anhangs stellen den grundlegenden fachlichen und prozessualen Rahmen für das Change Management dar. Sie enthalten keine abschließende operative Aus- gestaltung der im Einzelfall anzuwendenden Prozesse, technischen Anforderungen oder be- trieblichen Abläufe.

Die für den jeweiligen Leistungsgegenstand maßgeblichen Detailregelungen – insbesondere operative Prozessschritte, Rollen, Schnittstellen, technische Spezifikationen und Dokumenta- tionspflichten – werden von den Vertragsparteien im Rahmen der Leistungsübernahme ge- meinsam konkretisiert und außerhalb dieses Anhangs in einem Prozesshandbuch (vgl. An- lage 19 Servicemanagement) festgelegt. Dieses Dokument präzisiert die vorliegenden Rah- menvorgaben und ist für beide Vertragsparteien verbindlich einzuhalten.

Für den vereinbarten Leistungsgegenstand nicht relevante Anforderungen dieses Anhangs finden keine Anwendung.

1.2 Begriffsklärung

Unter Change Management im Kontext dieses Dokuments wird das operative IT-Change Ma- nagement verstanden, d.h. die Beantragung, Freigabe und Durchführung von Veränderungen an bestehenden IT-Services und IT-Assets und nicht die kaufmännische Beauftragung von neuen Services oder die Änderungen an Verträgen (siehe Kapitel 11 Änderungsmanage- ment des Rahmenvertrags).

2 Leistungsbeschreibung

Das Ziel des Change Managements ist die Durchführung von erfolgreich getesteten und qua- litätsgesicherten Änderungen an Software, Hardware, Firmware-Komponenten, Systemen und Sicherheitsparametern bei minimalem Risiko für die bestehende und zukünftige IT-Umgebung unter wirtschaftlichen Gesichtspunkten. Es umfasst alle Änderungen von Hard- oder Software- komponenten in den gesteuerten Umgebungen (Test-, Abnahme- und Produktions-Stages).

2.1 Arten von IT-Changes

• Normal IT-Change

Seite 3 von 8

[Seite 4]

Anhang 19.3 – Change Management

Für Änderungen von IT-Assets und IT-Services muss ein Change-Ticket erstellt werden. Über das Release Management des Auftraggebers vorbereitete und geplante Normal IT- Changes bedürfen ausreichenden Vorlaufs (siehe Ziffer 2.2 Termine und Fristen), sodass der IT-Change entsprechend bearbeitet werden kann.

• Standard IT-Change

Ein Standard IT-Change ist ein standardisiertes und genehmigtes Vorgehen für häufig durchzuführende Änderungen. Folgende Kriterien müssen zusätzlich zu einem Normal IT- Change erfüllt sein:

o häufig vorkommende, gleichartige Änderungen

o unterbrechungsfrei, ohne Auswirkung auf den betroffenen IT-Service oder andere IT- Services

o geringes und bekanntes Risiko in der Durchführung und somit für den Betrieb

o dokumentierter und von beiden Change Managements genehmigter Ablauf und voll- ständige Erfassung des IT-Changes inklusive Dokumentation der Vorgehensweise bei Misserfolg

Standard IT-Changes werden über Standard IT-Change Templates beauftragt.

• Notfall IT-Change

Bei Notfall IT-Changes handelt es sich um dringend notwendige Änderungen, die unmit- telbar durchgeführt werden müssen, um die Vertraulichkeit, Authentizität, Integrität und/oder Verfügbarkeit von Daten, Infrastrukturkomponenten und Anwendungssystemen zu gewährleisten bzw. um Schaden zu vermeiden oder zu begrenzen.

Die Grundlage für einen Notfall IT-Change ergibt sich grundsätzlich immer aus der Ein- schätzung des möglichen Schadens bei der Komplexitäts- und Risikobewertung. Notfall IT-Changes werden immer in der höchsten Risikostufe klassifiziert. Einem Notfall IT- Change muss immer ein Incident der beiden höchsten Prioritäten bzw. ein Major oder Security Incident vorausgehen. Ein sicherheitsrelevanter Notfall IT-Change resultiert aus einem Security Incident oder aus einem Problem, welches aufgrund eines Security In- cidents eröffnet wurde.

Für Notfall IT-Changes gibt es keine Fristen. Die Dokumentation (nachträglicher Change Request) muss innerhalb eines Arbeitstages erfolgen, inklusive der erforderlichen Unter- lagen (z.B. Fallback-Plan, Deployment-Drehbuch) und Nachweise (z.B. Test-Evidenz etc.).

Ist der IT-Change so kurzfristig, dass die festen Genehmigenden nicht mehr zustimmen können (Change-Koordinatoren der initiierenden oder der durchführenden Gruppe oder Change Manager des Auftragnehmers), werden die ausstehenden Genehmigungen nicht mehr erteilt. Somit können keine Genehmigungen des Auftraggebers eingetragen werden; stattdessen muss die Zustimmung per E-Mail oder telefonisch vom Auftraggeber eingeholt werden.

Seite 4 von 8

[Seite 5]

Anhang 19.3 – Change Management

2.2 Termine und Fristen

IT-Changes können generell sowohl vom Auftraggeber als auch vom Auftragnehmer einge- stellt werden, unter Beachtung der vereinbarten Vorgaben und der Vorlaufzeiten der vorgela- gerten Prozesse - insbesondere im Release und Deployment Management.

Die mittel- und langfristige Change-Planung (Vorerfassung und Klärung der Change-Daten, Austausch der Change-Kalender) erfolgt in Abstimmung mit dem Release Management des Auftraggebers gemäß den Fristen und Vorlaufzeiten aus dem Release und Deployment Ma- nagement des Auftraggebers. In besonders begründeten Fällen kann der Auftragnehmer mit entsprechender Begründung auch IT-Changes mit kürzeren Vorlaufzeiten einstellen. Ein Not- fall IT-Change kann auch unter Missachtung der Vorlaufzeiten eingestellt werden.

Die durch den Auftragnehmer gestellten IT-Changes werden vom Auftraggeber innerhalb der folgenden Zeiträume bearbeitet, genehmigt oder abgelehnt:

• bei Normal IT-Changes mit Risikostufe 1 bis 2 nach Einstufung des Auftraggebers min- destens innerhalb eines vollen Werktags (Bearbeitungszeit des Auftraggebers)

• Normal IT-Changes mit Risikostufe 3 bis 5 nach Einstufung des Auftraggebers mindes- tens innerhalb von fünf vollen Werktagen (Bearbeitungszeit des Auftraggebers).

Eine Ablehnung eines IT-Changes bedarf immer einer aussagekräftigen Begründung. Eine Ablehnung der Change-Termine des Auftragnehmers im vereinbarten Wartungszeitfenster kann durch den Auftraggeber nur aus wichtigem Grund erfolgen. Bei Ablehnung kann eine Eskalation nach Anlage 7 Governance eingeleitet werden.

Für die Durchführung von Standard IT-Changes gelten keine Fristen. Sofern die Leistungen des Auftragnehmers Software- und Hardware-Patches beinhalten, wird der Auftraggeber hier- für Fristen für die Aktualisierungen vorsehen. Können die Fristen vom Auftragnehmer nicht eingehalten werden, finden die Eskalationsstufen in Anlage 7 Governance Anwendung.

2.3 Bewertung von IT-Changes

Jeder IT-Change wird hinsichtlich Auswirkung und Dringlichkeit analysiert. Die Auswirkungs- analyse erfolgt über die Auswertung der Attribute und Relationen von betroffenen Configura- tion Items (CIs) in der Configuration Management Database (z.B. Schutzklassen, wird benutzt von Anwendung etc.). Die Ergebnisse aus Auswirkungsanalyse und Dringlichkeit ergibt die Priorität, nach der der IT-Change bearbeitet wird.

Über die Bearbeitung eines IT-Changes wird auf Basis der Komplexität entschieden, welches auch die notwendige Autorisierungsebene bestimmt. Die Komplexität ist im Tool des Auftrag- gebers als "Risikostufe" abgebildet. Die Komplexitätsbewertung hängt von verschiedenen Faktoren ab, wie z.B. Erfahrungswerte mit vergleichbaren IT-Changes, Wiederholungsraten, Auswirkung auf Services, Dauer der Durchführung, Ausfallrisiko, Nachweis von erfolgreich durchgeführten Tests und voraussichtliche Dauer eines möglichen Rollbacks.

Die Einschätzung der Risikoklasse nehmen Auftraggeber und Auftragnehmer jeweils für sich vor und dokumentieren jeweils beide Risikostufen. Die Risikoeinschätzung der anderen Partei wird nicht verändert. Die Autorisierung eines IT-Changes erfolgt jeweils auf Basis der eigens ermittelte Risikostufe. Sofern die Verarbeitung von zwei getrennten Risikostufen technisch nicht möglich ist, kann das Change Management des Auftraggebers im Bedarfsfall einseitig

Seite 5 von 8

[Seite 6]

Anhang 19.3 – Change Management

die Risikoklasse der Bearbeitung anheben. Der Auftragnehmer wird dann diese Risikoklasse zur Autorisierung der Changes verwenden.

2.4 Veränderungen von eingestellten und genehmigten IT-Changes

Der Auftragnehmer stellt ein Verfahren bereit, das sicherstellt, dass sowohl interne Changes als auch vom Auftraggeber initiierte Changes die jeweils erforderlichen Genehmigungsebenen gemäß den vereinbarten Prozessen durchlaufen. Hierbei ist auch die Leitungsebene (Change Advisory Board) einzubinden. Wenn ein IT-Change beim Auftragnehmer die erste Genehmi- gungsinstanz zur Freigabe durchlaufen hat, darf der IT-Change inhaltlich und zeitlich nicht mehr verändert oder ergänzt werden. Wenn er dennoch verändert wird, zieht das eine voll- ständige Neuplanung nach sich. Bestehende Freigaben verfallen.

2.5 Test von IT-Changes

Das Testen der im Rahmen des IT-Changes durchgeführten Veränderung und deren Doku- mentation nach Vorgaben des Auftraggebers ist dem eigentlichen Change Management vor- gelagert und über Quality Gates in den Change Management-Prozess integriert.

Ein Fallback/Rollback-Szenario muss im Vorfeld mit den beteiligten Stakeholdern abgestimmt und getestet sein. Die Test-Bestätigung (z. B. Sign-off-Dokument) ist mindestens im Change- Ticket des Auftraggebers für die Produktionsumgebung abzulegen. Das Deployment-Dreh- buch muss im Change-Ticket des Auftraggebers abgelegt werden, damit die einzelnen Schritte nachvollziehbar sind.

Wenn im Rahmen des IT-Changes Softwareartefakte oder Komponenten verändert werden, deren Erstellung in der Verantwortung des Auftraggebers liegen (z.B. Deployment von Anwen- dungen des Auftraggebers auf der vom Auftragnehmer bereitgestellten Infrastruktur), stellt der Auftraggeber sicher, dass diese gemäß seinen eigenen Anforderungen und Verfahren ange- messen getestet sind. Der Auftraggeber stellt dem Auftragnehmer ein Sign-off-Dokument zur Verfügung. Dieses muss dem IT-Change hinzugefügt werden.

Sind hierzu Tests durch den Auftragnehmer erforderlich (z.B. zur Prüfung der Kompatibilität zwischen der Software des Auftraggebers und den Infrastrukturkomponenten des Auftragneh- mers), unterstützt der Auftragnehmer den Auftraggeber entsprechend.

Umgekehrt verantwortet der Auftragnehmer den Test von Komponenten in seinem Zuständig- keitsbereich gemäß seiner eigenen internen Vorgaben und Regeln.

Zur Sicherstellung, dass nur nach den entsprechenden Vorgaben getestete IT-Changes durch- geführt werden, wird ein Kontrollpunkt („Quality Gate“) bei der Change-Initiierung in den Change-Prozess aufgenommen:

• Quality Gate 1: „Testkonzeption/Testplanung/Testdurchführung/Testdokumentation“ liegt vor“

Der IT-Change darf erst erstellt werden, wenn die Kriterien des Quality Gates 1 erfüllt worden sind, insbesondere entsprechende Test-Bestätigungen zur Dokumentation eines erfolgten und erfolgreichen Tests vorhanden sind. Insbesondere relevant ist hier das Sign-off Dokument auf Basis der vorhergehenden Stage. Hierzu lädt der Change-Initiator bei der Erstellung des IT- Changes die entsprechende Test-Bestätigung zum Nachweis über die Durchführung der not- wendigen bzw. vorgegebenen Tests hoch.

Zur Change-Validierung nach Change-Durchführung wird ein zweites Quality Gate eingeführt:

Seite 6 von 8

[Seite 7]

Anhang 19.3 – Change Management

• Quality Gate 2: „Validierung nach Change-Implementierung“

Kein Change-Abschluss darf ohne nachweisliche Validierung zur Überprüfung von Wirksam- keit und Auswirkung bleiben. Gegenstand dieses Quality Gates ist es, dafür zu sorgen, dass ein IT-Change erfolgreich umgesetzt wurde und dass im Nachhinein keine Produktionsstörun- gen auftreten. Hierzu wird der IT-Change unmittelbar nach seiner Durchführung durch den Auftragnehmer stichprobenartig validiert.

Eine Validierung in diesem Kontext ist eine Überprüfung der grundlegendsten Funktionalitäten der geänderten Komponente. Beispiel: Nach der Installation einer Anwendung wird diese auf- gerufen, um zu validieren, dass die Anwendung grundsätzlich verfügbar ist und die eingeführte Änderung nachweislich umgesetzt wurde.

Die Validierung wird vom Durchführenden des IT-Changes ausgeführt. Er protokolliert die zur Validierung vorgenommenen Aktivitäten und das Ergebnis, bevor er den IT-Change als abge- schlossen markiert.

Der Auftraggeber unterstützt bei Bedarf die Validierung, wenn diese auf Anwendungsseite nur durch den Auftraggeber vorgenommen werden kann.

Bei jedem fehl- oder teilfehlgeschlagenen IT-Change/Task ist ein Post Implementation Review (PIR) durchzuführen.

Identifizierte Störungen, die in einem IT-Change begründet sind, werden über den Prozess Incident Management gemeldet und abgewickelt. Der hierzu erfasste Incident ist mit dem IT- Change zu verknüpfen.

2.6 Leistungen und Verantwortlichkeiten

Im Folgenden sind die für das Change Management notwendigen Leistungen, die durch die Auftragnehmer (AN) und den Auftraggeber (AG) zu erbringen sind, definiert. Dabei ist jeder Leistung eine Verantwortlichkeit gemäß RACI-Matrix aus Anlage 19 Servicemanagement zugeordnet.

Seite 7 von 8

[Seite 8]

Anhang 19.3 – Change Management

Tabelle 1: Change Management RACI

3 Prozesseinbindung und -schnittstellen

Im Rahmen der Serviceerbringung arbeitet der Auftragnehmer eng mit dem Auftraggeber zu- sammen.

Die konkrete Umsetzung des Change-Prozesses wird im Zuge der Leistungsübernahme ge- meinsam von beiden Parteien festgelegt, in konkrete Prozessschritte überführt und entspre- chend dokumentiert.

Die operative Zusammenarbeit erfolgt entweder über eine Toolschnittstelle oder durch ein On- boarding des Auftragnehmers in das System des Auftraggebers.

Unabhängig von der technischen Umsetzung muss sichergestellt werden, dass dem Auftrag- geber alle notwendigen Informationen zur Bewertung des IT-Changes im Sinne der MaRisk AT 9 – Auslagerung übermittelt werden.

4 Reporting

Der Auftragnehmer stellt dem Auftraggeber die in Anlage 2 Berichtswesen definierten Ser- vice Level-Reports zum Change Management in der vereinbarten Form bereit.

Seite 8 von 8