305
Auch sollte der Provider akzeptierten, dass der IT-Sicherheitsbeauftragte des Kunden – bei Gefahr im Verzuge – gegenüber den Mitarbeitern des Providers in sicherheitsrelevanten Angelegenheiten, die den Kunden betreffen, weisungsbefugt ist. Dadurch sollte aber weder ein Arbeitsverhältnis begründet werden noch ein Fall der Arbeitnehmerüberlassung i.S.v. §§ 1 ff. AÜG vorliegen.
ee) Berichte und Prüfungen
306
Der Provider sollte den Kunden durch regelmäßige Berichte informieren und bei Bedarf im Einzelfall den IT-Sicherheitsbeauftragten des Kunden, um diesem jederzeit einen aktuellen, umfassenden und detaillierten Überblick über die Sicherheitslage zu geben.
307
Der Provider sollte dabei dem Kunden gestatten (ggf. durch einen beauftragten Dritten), Sicherheitsüberprüfungen beim Provider durchzuführen. Der Provider sollte dem Kunden die relevanten Berichte, die die interne Revision des Kunden benötigt, auch zur Verfügung stellen. Falls der Provider über Zertifizierungen verfügt (z.B. ISO/IEC 27001, SAS70 etc.), sollte er Kopien der Zertifikate und Zertifizierungsberichte (Audit Reports) dem Kunden auch zur Verfügung stellen.
308
Die durch den Provider umzusetzenden Sicherheitsmaßnahmen (was ist zu tun) sowie deren Ausgestaltung (wie ist es zu tun) können sich z.B. aus den aktuellen Versionen des Rahmenwerks „Sicherer IT-Betrieb“ des SIZ ergeben. Die dort empfohlenen Maßnahmen einschließlich der Empfehlungen für erhöhten und hohen Schutzbedarf (z.B. Maßnahmen der Qualifizierungsstufe A, B, C und Z des IT-Grundschutz-Katalogs) sollten auch wesentlicher Vertragsbestandteil sein.
309
Eventuell sind ergänzende oder abweichende Sicherheitsmaßnahmen durch den Provider umzusetzen, insofern sie sich aus den nachfolgenden Verpflichtungen ergeben:
| – |
individuelle Vereinbarungen (z.B. Aufträge), |
| – |
interne Vorgaben des Kunden (z.B. Organisationsanweisungen, OPDV), |
| – |
externe Vorgaben (z.B. BDSG, GoBS, KWG) und |
| – |
Sicherheitsmaßnahmen gemäß individueller Risikoanalyse bei sehr hohem Schutzbedarf. |
310
Dabei können die nachfolgenden aufgeführten Sicherheitsmaßnahmen und Services als Beispiele dienen, welche IT-Security Leistungen der Provider zu erbringen hat und welche man dazu im Outsourcing-Vertrag vereinbaren kann:
| – |
mehrstufiges Firewall-System sowie kontinuierliche Überwachung der Firewall-Systeme, um bei Angriffen verzugslos steuernd reagieren zu können, |
| – |
mehrstufiges Anti-Spam Verfahren, |
| – |
zentrales System zur Verschlüsselung von E-Mails mit verschiedenen Verfahren (einschließlich S/Mime, PGP, HTTPS und StartTLS). |
| – |
automatisches Provisioning von beantragten Benutzerberechtigungen an die IT Systeme um sicherzustellen, dass die genehmigten Berechtigungen (Soll-Zustand) mit dem in den IT-Systemen tatsächlich bestehenden (Ist-Zustand) übereinstimmt. |
311
Ein Notfall in der Erbringung der IT-Services (teileweise wird auch der Begriff K-Fall/Katastrophen-Fall verwendet) liegt vor, wenn absehbar wird, dass eine Störung zu einer existenzbedrohenden Betriebsunterbrechung geschäftskritischer IT-Systeme und IT-Prozesse führt. Es wird angenommen, dass ein derartiger Notfall durch den Ausfall des (Produktions-) Rechenzentrums eintreten kann. Ziel ist es – unabhängig davon, was den Ausfall des (Produktions-) Rechenzentrums ausgelöst hat – den Notbetrieb der IT Services in einem Ausweich-Rechenzentrum zur Verfügung zu stellen, solang bis der Wiederanlauf des (Produktions-) Rechenzentrums erfolgt ist.
312
Nach dem ITIL2011 Prozess IT Service Continuity Management, das sich am „Sicheren IT-Betrieb“, der ISO/IEC 27031 oder dem IT-Grundschutz-Standard 100-4 ausrichtet, werden hierzu konkrete Regelungen im Vertrag vereinbart. Dabei kann die Kritikalität der IT-Anwendungen anhand der möglichen Auswirkungen eines Ausfalls in folgende Stufen klassifiziert werden:
| – |
A (existenzbedrohend), |
| – |
B (wesentlich) und |
| – |
C (tolerierbar). |
313
Für Anwendungen der Kritikalität A und B sollte der Provider eine entsprechende Notfallplanung haben. Die Notfallplanung sollte so ausgestaltet sein, dass durch diese sachkundige Dritte in die Lage versetzt werden, die jeweiligen Anwendungen im Ausweich-Rechenzentrum anzufahren und den Notbetrieb einschließlich der Schnittstellen, Batchverarbeitungen und Infrastrukturkomponenten zu gewährleisten.
314
Die Notfallplanung muss so ausgestaltet sein, dass die Anwendung mindestens innerhalb definierter Service Levels im Notbetrieb wieder zur Verfügung steht. Die Notfallplanung und die Datensicherungsverfahren müssen so ausgestaltet sein, dass die Anwendungen in einem Notfall maximal einen Datenverlust in einem kleineren Umfang erleiden.
315
Die Notfallplanung ist durch den Provider zu dokumentieren und bei Bedarf zu aktualisieren. Mindestens halbjährlich ist durch den Provider zu prüfen, ob eine Aktualisierung der Notfallplanung erforderlich ist. Diese Prüfung, wie auch Aktualisierungen, sind in den jeweiligen Dokumenten zu vermerken.
316
Die aktuelle Dokumentation der Notfallplanung ist so aufzubewahren, dass diese im Notfall für alle Mitarbeiter des Providers und des Kunden, die diese benötigen, um dem Notfall zu begegnen, zugänglich ist. Ansonsten ist die Dokumentation der Notfallplanung vertraulich zu behandeln.
317
Der Kunde sollte das Recht haben, einmal jährlich pro Anwendung die Notfallplanung in einem Praxistest (Notfall-Test, K-Fall-Test, Disaster-Recovery-Test) zu überprüfen. Dabei sollte der Kunde (oder die IT-Revision) festlegen, welche Anwendungen zu welchem Zeitpunkt, in welcher Zusammenstellung und in welcher Tiefe getestet werden sollen. Dazu muss natürlich der Provider eine detaillierte Dokumentation einschließlich erkannter Schwächen und Verbesserungsmöglichkeiten zur Verfügung stellen.
318
Beim BPO wird ein strategischer Wert durch die genaue Analyse eines Prozesses und einer gezielten Änderung der Art und Weise, wie dieser Prozess ausgeführt wird, erreicht. Es ist also mehr als nur ein Wechsel der Personen, die den Prozess ausführen. Der Dienstleister übernimmt bei BPO nicht nur die Verantwortung für die Durchführung des Prozesses, sondern er nimmt auch ein Business Process und IT Reengineering (inkl. Standardisierung und Optimierung) desselben vor. Immer häufiger werden dazu Provider engagiert, weil wichtige Geschäftsabläufe von IT-Prozessen und der entsprechenden IT-Infrastruktur getragen werden. Dies bedeutet vor allem auch, dass die adäquateste IT-Infrastruktur und IT-Prozesse zur Unterstützung und Verbesserung des Prozesses verwendet werden.[299] Im Gegensatz zum konventionellen (IT) Outsourcing ist der BPO-Anbieter somit in der technischen Umsetzung frei. Der Kunde bezieht das Prozessergebnis, ohne in den Verantwortungsbereich oder die Infrastruktur der Datenverarbeitung einbezogen zu sein,[300] sofern dies nicht für den Erfolg des BPO notwendig ist. So empfiehlt sich z.B. beim HR-Outsourcing, sich nicht ganz auf das Prozessergebnis allein zu verlassen. Der BPO-Kunde sollte hierbei ein Mitbestimmungsrecht haben, in welchen Datenstandard (z.B. SAP HR) seine Personenstammdaten gespeichert werden, damit er die Möglichkeit besitzt, ohne größere Aufwände den BPO-Provider zu wechseln. Dies ist natürlich nicht möglich, wenn der BPO Provider die Datenstammsätze des BPO-Kunden auf einem nicht kompatiblen Exoten-System pflegt.
Читать дальше