Die Schnittstellen zwischen den Risiko- und Notfallmanagement-Disziplinen sind ein kritischer Erfolgsfaktor für eine effiziente und effektive Erhöhung der Widerstandsfähigkeit gegen Störungen, Notfällen und Krisen. Christian Zänker hat sich diese Schnittstellen im nachfolgenden Gastbeitrag für die BCM-News einmal aus Sicht des ITSCM angeschaut.

Das IT Service Continuity Management (ITSCM) sollte in die bestehenden Managementsysteme der Organisation integriert werden. Nur so lässt sich seine Wirksamkeit entfalten und über die zu definierenden Schnittstellen ein effektiver und unter Wirtschaftlichkeitsaspekten effizienter Workflow implementieren.

Managementsysteme sind durch die Befolgung des Plan – Do – Check – Act Zyklus (Deming Kreis) als zugrundeliegendes Prinzip gekennzeichnet und dienen der Etablierung eines kontinuierlichen Verbesserungsprozesses der Organisation. Alle ISO Managementsystemstandards, die in den letzten Jahren veröffentlicht wurden, spiegeln dies in ihrem Aufbau wider und weisen einen hohen Grad an Kompatibilität auf.

Die nachfolgenden ISO Standards geben die Basis, auf der die querschnittlichen und Steuerungsprozesse im Unternehmen idealerweise aufgesetzt sein sollten. Zu ihnen gehört ITSCM[1]:

ISO 9001	Quality Management
ISO 20000	IT Service Management
ISO 22301	Business Continuity Management System
ISO 27001	Information Security Management System
ISO 27005	Information Security Risk Management
ISO 27031	Guidelines for Information and Communications Technology, Readiness for Business Continuity (vormals BS25777: ITSCM)
ISO 31000	Risk Management – Principles and Guidelines

Ergänzend ließe sich auf ITIL, die BSI Grundschutzkataloge und die BSI Standards 100-1 bis 100-4 zurückgreifen.

ITSCM ist als Bestandteil des BCMS Prozesses definiert und gründet ebenfalls auf einem Managementsystem, dessen Ziel ist, sowohl das bestehende BCMS als auch das ISMS Programm zu ergänzen und zu untermauern.

ISO 27031 benennt fünf Schlüsselprinzipien des ITSCM:

1. Incident Prevention
2. Incident Detection
3. Response
4. Recovery
5. Improvement

Und sechs Schlüsselelemente des ITSCM:

1. People
2. Facilities
3. Technology
4. Data
5. Processes
6. Suppliers

Zur Implementierung eines nachhaltigen ITSCM (resiliency) müssen diese Kernbestandteile in einer eigenen Leitlinie (policy) im Unternehmen verortet werden und durch spezifische Richtlinien (guidelines) die Umsetzungsverfahren beschrieben und Verantwortlichkeiten zugewiesen werden. ITSCM muss komplementär zu den Managementsystemen für Business Continuity und Information Security aufgesetzt werden und entsprechend der Systematik und den Abläufen dieser Managementsysteme folgen.

Ein Verständnis dieses Zusammenspiels, des systematischen Ineinandergreifens der verschiedenen Steuerungsfunktion, ist elementar, wenn die unterschiedlichen Steuerungsfunktionen nicht wie früher in ihren Bereichsgrenzen wie in Silos eingemauert werden sollen.

Wenn wir von Ausfallszenarien sprechen, ergibt sich das jeweilige Schadensausmaß aus den durch das Szenarium direkt oder indirekt betroffenen Prozessen. Dies gilt für den IT-Ausfall wie für die drei anderen klassischen Ausfallszenarien Personal-, Gebäude- und Schnittstellenausfall.

Das Risikomanagement betrachtet hierbei dieselben Prozessausfallrisiken wie z.B. das BCM im Rahmen der Business Impact Analyse (BIA), nur dass dort nicht das zu begegnende Risiko im Fokus steht, sondern die Schadenswirkung.

1. Finanzielle Risiken
2. Reputationsrisiken
3. Compliance Risiken
4. Strategische Risiken

Zur Erhebung des finanziellen Impacts sollte man unter anderem auf das Controlling und auf betriebswirtschaftliche Berechnungen zurückgreifen. Welchen Anteil hat jeder der betroffenen Geschäftsprozesse am Betriebsergebnis z.B. der letzten drei Jahre? Oder wie hoch war der jeweilige Anteil am Gewinn vor Zinsen, Steuern, Abschreibungen? Zu Risiken aus Compliance-Verletzungen, Reputationsschäden oder Verlust der strategischen Steuerungsfähigkeit des Unternehmens sind wiederum querschnittliche und Steuerungsfunktionen wie das Controlling, Compliance und Unternehmenskommunikation einzubinden.

Wenn diese genannten querschnittlichen und Steuerungsfunktionen über Schnittstellen eingebunden sind, ist es letztlich gleich, wo die Kritikalität der einzelnen Prozesse und der sie tragenden Ressourcen erhoben wird. Im Risikomanagement wie in der Informationssicherheit spielen im Gegensatz zu BCM aber die präventiven, vorbeugenden Maßnahmen eine herausragende Rolle.

Für Prozesse, deren Schadensausfallwirkung so schwerwiegend ist, dass nach allen vorgesehenen Präventionsmaßnahmen das Restrisiko immer noch als untragbar erscheint, wird durch Informationssicherheit und Risikomanagement eine Notfallplanung (BCM) als zusätzliche Maßnahme definiert, um bei eintretendem Ereignis, die Schadensauswirkung zu minimieren.

Diese Prozesse werden an das BCM weitergegeben und dort der Business Impact Analyse unterzogen. In der BIA wird die Schadensentwicklung im zeitlichen Verlauf bewertet und festgestellt, ab welcher vordefinierter Zeitperiode das missionskritische Schadensausmaß erreicht wird, und daraus abgeleitet das Wiederanlaufziel sowie die hierfür benötigten Ressourcen festgesetzt.

Ähnlich zeigt sich die Schnittstelle zur Information Security. Diese unterscheidet
Primary Assets: Geschäftsprozesse und Kernaufgaben sowie Informationswerte (lebenswichtige, strategische, kostenintensive, personenbezogene Informationen) von den Supporting Assets: Hardware, Software, Datennetze, Personal, Gebäude und  Organisationsstrukturen (s.o. Schlüsselelemente des ITSCM).

Für die Supporting Assets wird ein Basis Schutzniveau (IT Grundschutz) festgelegt. Für die Primary Assets wird ein erhöhter Schutzbedarf bestimmt. Hier ergibt sich die Schnittstelle zwischen ITSCM und BCMS sowie ISMS über die BIA. Aus ihr werden auch die Anforderungen an das ITSCM abgeleitet.

BCM als Notfallplanung bezieht sich auf die Prozesse, die in einer festgesetzten Zeitspanne wiederanlaufen müssen, z.B. 1h – 4h – 8h – 24h – 72h – 120h. Dies ist zu planen, zu implementieren und zu testen, damit diese kritischen Prozesse in der geforderten Wiederanlaufzeit aufgenommen werden können. Die Prozesse, die nicht als kritisch eingestuft werden, gehen bei diesem Ansatz nicht verloren, sondern werden priorisiert und wenn sie Abhängigkeiten zu kritischen Prozessen aufweisen, wie bisher durch die BIA erfasst und als Zuliefer- oder Weiterverarbeitungsprozesse ins BCMS integriert.

In den meisten Organisationen werden die Anforderungen an die IT, intern wie extern, über Service Level Agreements (SLA) zwischen den Geschäftsbereichen und der IT als zentralem Service Provider vereinbart. Diese Anforderungen beziehen sich auf die Verfügbarkeit im Normalprozess (Availability). Sie ist die wichtigste Schnittstelle des BCMS und sollte deswegen im organisationseigenen Prozessablauf mit höchster Priorität definiert werden.

Durch die unterschiedlichen Service Level wird für jede einzelne IT-Anwendung festgelegt, wie schnell die Störung im Normalprozess behoben werden muss, damit es erst gar nicht zum Notfall in der Prozessabwicklung kommt. Auch hier liefert die BIA den Anforderungskatalog für alle IT-Services, die zur Durchführung der kritischen Prozesse benötigt werden.

Durch die definierte Schnittstelle von BIA und SLA oder besser Service Level Request (SLR), muss gewährleistet werden, dass auch das Ausfallszenarium IT-Ausfall in das SLA einfließt. Wie gesagt, ist in den gängigen SLA nur die Availability geregelt. Das Disaster Recovery, der IT Notfall oder auch K-Fall, bleibt zumeist ausgespart. Weil sich bei einem IT-Notfall keine Wiederanlaufzeit garantieren lässt, sollte durch BCM in den SLA nicht nur das Wiederanlaufziel, Recovery Time Objective (sic!), Aufnahme finden, sondern auch beinhaltet sein, dass der RTO als Priorisierung in der Wiederanlaufreihenfolge für den K-Fall Rechnung getragen wird.

Die Geschäftsbereiche stellen Ihre Anforderungen (SLR) an das IT Service Management:

• Kapazitätsmanagement / Kapazitätsplan
• Budget für Infrastruktur und Support
• Benötigte Ressourcen gemäß Business Impact Analyse
• Akzeptiertes Risiko und Schadenslevel gemäß Risk Assessment
• Availability und IT-Service Continuity
• Service und Support
• Implementierung

Vom IT Service Management werden daraus folgende Anforderungen an das ITSCM generiert:

• IT Service Continuity und IT Recovery Pläne: Absicherung der von den BCM Plänen geforderten Ressourcen
• Umsetzung der Anforderungen aus der Business Impact Analyse an die IT Ressourcen: IT Notfallpläne sind aktuell und in Übereinstimmung mit den Anforderungen der Geschäftsprozesse
• Einhaltung der Anforderungen aus der Risikoanalyse: das Niveau der IT Services und die vorgesehenen Notfallmaßnahmen bewegen sich im vorgegebenen Rahmen akzeptierter Geschäftsrisiken

Der Workflow von der BIA über die SLR zu den SLA wird wiederum von BCM mit der BIA Gap-Analyse geschlossen. Diese vergleicht unter anderem die in der BIA erhobenen Anforderungen an die IT mit den in den SLA definierten IT-Services und überprüft, ob diese abgedeckt sind, oder ob sich hierbei Lücken (Gaps) ergeben, die als objektive Risiken an die Geschäftsbereichsleitung und an das zentrale Risikomanagement gemeldet werden.

Als Managementsysteme müssen BCMS, ISMS und ITSCM ihren turnusmäßigen Input in ein Reporting an die Geschäftsleitung leisten. Aufgrund der Haftung von Vorstand und Aufsichtsrat für die Risiken des jeweiligen Instituts, die regulatorisch vorgegeben sind, ist die Integration in das Risiko-Reporting anzustreben. In ihm wird die Erfüllung der Anforderungen aus den Geschäftsprozessen durch das IT Service Management und durch ein etabliertes ITSCM ebenso wie Abweichungen und daraus resultierende Risiken für die Organisation turnusmäßig berichtet, um so dem verantwortlichen Management die Möglichkeit zu geben, seiner institutionellen Verantwortung gerecht zu werden.

[1] Obwohl im neuen Standard als ICT respektive IRBC (ICT Readiness for Business Continuity) bezeichnet, ist die alte Bezeichnung ITSCM (IT Service Continuity Management) weiterhin die allgemein gebräuchliche Kurzform.