Prüfung outgesourcter Informatikleistungen ... · Der Sarbanas-Oxley Act ist ein Gesetz, welches im Jahre 2002 in den USA erlassen wurde, mit dem Ziel die Investoren vor falscher

Prüfung outgesourcter Informatikleistungen – Prüfprozessoptimierung im IT-Security Bereich

Diplomarbeit

Institut für Rechnungswesen und Controlling

der Universität Zürich

Prof. Flemming Ruud, PhD

Prof. Dr. Gerhard Schwabe

Studienrichtung: Wirtschaftsinformatik

Fach: Auditing

Verfasser: Bimal Mathews

Baselmattweg 147, 4123 Allschwil

00-705-038

061 481 19 16

[email protected]

Abgabedatum: 16.09.2005

Inhaltsverzeichnis I

Danksagung

Ich möchte mich an dieser Stelle bei allen Personen bedanken, die zum Gelingen dieser Arbeit

beigetragen haben.

Ein spezielles Dankeschön für die investierte Zeit und den sehr hilfreichen Informationen geht an

die Interviewpartner Patrik Allenspach (Luzerner Kantonalbank), Mark Dambacher

(PricewaterhouseCoopers), Frank Hammer (IBM Deutschland), Michel Huissoud

(Eidgenössische Finanzkontrolle), Jürg Illi (Credit Suisse Group), Frank Mühlenbrock (IBM

Deutschland) und Thomas Pfister (Unisys).

Zusätzlich will ich mich bei Tom Schmidt (Ernst & Young) für die Hilfestellung beim SAS 70

Prüfkonzept bedanken.

Nicht zuletzt bedanke ich mich bei Kathrin Bütikofer, Sarah Bütikofer, Philip Michel und

Angelo Vergari für die Durchsicht meiner Arbeit und die tolle Hilfeleistung während den sechs

Monaten.

Inhaltsverzeichnis II

Abstract

Beim Auslagern von Informatikleistungen wird die ganze IT oder Teile davon einem Service

Anbieter übergeben. Die Verantwortung über die ausgelagerten Bereiche verbleiben aber beim

Outsourcer und sind somit weiterhin Teil seiner Internal Control. Damit der Outsourcer sicher

sein kann, dass die ausgelagerte IT weiterhin den eigenen Ansprüchen genügt, müssen direkte

Prüfungen beim Service Anbieter durchgeführt werden. Direkte Prüfungen kosten jedoch

personelle und zeitliche Ressourcen für den Service Anbieter wie auch für den Outsourcer. Aus

diesem Grund entstand die SAS 70 Prüfung. Dabei wird die Internal Control des Service

Anbieter durch eine externen Prüfgesellschaft beurteilt (SAS 70 Typ I) und auf deren Effektivität

getestet (SAS 70 Typ II). Die Resultate dieser Prüfungen werden den einzelnen Outsourcern zur

Verfügung gestellt. Der Sarbanes-Oxley Act anerkennt den SAS 70 Report als Bestätigung der

Section 404. Im Rahmen dieser Arbeit wird ein Ansatz für einen SAS 70 Prüfprozess erarbeitet.

Beispielhaft wird dabei die IT-Security als Prüffokus dienen.

Inhaltsverzeichnis III

Inhaltsverzeichnis

1 Einleitung ................................................................................................................................ 1

1.1 Problemstellung .............................................................................................................. 1

1.2 Zielsetzung...................................................................................................................... 2

1.3 Vorgehensweise und Aufbau.......................................................................................... 2

2 Grundlagen des Outsourcing ................................................................................................ 4

2.1 Definition Outsourcing ................................................................................................... 4

2.2 Entwicklung und Gründe für Outsourcing ..................................................................... 5

2.2.1 Entwicklung des Outsourcing ............................................................................. 5

2.2.2 Gründe für Outsourcing ...................................................................................... 7

2.3 Outsourcing-Dimensionen............................................................................................ 11

2.3.1 IT-Outsourcing.................................................................................................. 11

2.3.2 Business Application Outsourcing.................................................................... 13

2.3.3 Business Process Outsourcing .......................................................................... 14

2.3.4 Business Transformation Outsourcing.............................................................. 15

2.4 Organisatorische Formen des IT-Outsourcing.............................................................. 16

2.5 Rechtliche Aspekte des IT-Outsourcing....................................................................... 19

2.5.1 Der Outsourcing-Vertrag .................................................................................. 19

2.5.2 Service Level Agreement.................................................................................. 20

2.5.3 Haftung im IT-Outsourcing .............................................................................. 21

2.6 Gefahren und Risiken des IT-Outsourcing ................................................................... 22

2.6.1 Risiken aus der Outsourcer-Sicht...................................................................... 23

2.6.2 Risiken aus der Service Anbieter Sicht............................................................. 24

2.7 Zusammenfassung ........................................................................................................ 24

3 Internal Control mit Fokus auf die IT-Security................................................................ 26

3.1 Definition Internal Control ........................................................................................... 26

3.1.1 Verantwortlichkeiten für die Internal Control .................................................. 28

3.1.2 COSO Framework ............................................................................................ 29

3.1.3 Chancen und Gefahren für die Internal Control durch den IT-Einsatz............. 32

Inhaltsverzeichnis IV

3.2 Relevante Framework und Standards für den IT-Bereich ............................................ 34

3.2.1 COBIT............................................................................................................... 34

3.2.2 ITIL................................................................................................................... 36

3.3 Rolle der IT-Security in der Internal Control ............................................................... 37

3.3.1 Definition IT-Security....................................................................................... 38

3.3.2 Konkrete Bedrohungen für die Unternehmen................................................... 39

3.3.3 Sicherheitsaspekte im COBIT Framework ....................................................... 41

3.3.4 Weitere Sicherheitsrichtlinien und Standards für eine korrekte IT-

Security ............................................................................................................. 42

3.3.5 Kontrollverfahren.............................................................................................. 46


4 Outsourcing und der Einfluss auf den Outsourcer und Service Anbieter...................... 49

4.1 Überblick der Zusammenarbeit im Outsourcing .......................................................... 49

4.2 Änderung der Aufgaben für die Internen Revision ...................................................... 50

4.2.1 Aufgaben vor dem Outsourcing-Verhältnis...................................................... 51

4.2.2 Aufgaben im Outsourcing-Verhältnis............................................................... 53

4.3 Änderung der Aufgaben für die externen Prüfgesellschaften....................................... 54

4.4 Koordination des IT-Sicherheitskonzept für das Outsourcing- Vorhaben ................... 55

4.4.1 Beteiligte Personen ........................................................................................... 57

4.4.2 Relevante Themen für das IT-Sicherheitskonzept............................................ 59

4.5 Überprüfbarkeit der IT-Security im Outsourcing ......................................................... 63


5 SAS 70 ................................................................................................................................... 66

5.1 SAS 70 – Vorstellung und Gründe ............................................................................... 66

5.2 Typen ............................................................................................................................ 68

5.3 Prüfgebiete und Schwierigkeiten eines SAS 70 Audits................................................ 69

5.3.1 Prüfgebiete eines SAS 70 Audit ....................................................................... 69

5.3.2 Schwierigkeiten und Schwächen eines SAS 70 Audit...................................... 70

5.4 Mehrwert durch einen SAS 70 Report.......................................................................... 72

5.4.1 Mehrwert für den Service Anbieter .................................................................. 72

5.4.2 Mehrwert für den Outsourcer............................................................................ 73

Inhaltsverzeichnis V

5.5 Sarbanas-Oxley und SAS 70 ........................................................................................ 73

5.5.1 Der Sarbanes-Oxley Act ................................................................................... 73

5.5.2 Zusammenhang Sarbanes-Oxley Act und SAS 70 ........................................... 75

5.6 International vergleichbare Reports.............................................................................. 76

5.6.1 Prüfungsstandard 402 (Schweiz) ...................................................................... 76

5.6.2 Section 5900 (Kanada)...................................................................................... 77

5.6.3 FIT 1/94 und FRAG 21/94(UK) ....................................................................... 78

5.6.4 Australien.......................................................................................................... 78

5.7 Mögliche Alternativen zu SAS 70 im IT-Security Bereich.......................................... 79

5.7.1 Trust Services.................................................................................................... 80

5.7.2 Unterschiede von SAS 70 zu Trust Services .................................................... 82

5.7.3 Unterschiede von SAS 70 zu ISO 9000 bzw. ISO 17799................................. 85


6 SAS 70 Prüfprozessansatz mit Fokus auf die IT-Security ............................................... 88

6.1 Überblick Prüfprozess .................................................................................................. 88

6.2 Überblick IT-Prüfung ................................................................................................... 90

6.3 Prüfungsvorgehen zur Erfüllung der Sarbanes-Oxley Act Anforderungen.................. 92

6.4 Der SAS 70 IT-Security-Prüfprozess ........................................................................... 95

6.4.1 Vorbemerkungen............................................................................................... 97

6.4.2 Vorbereitung ..................................................................................................... 98

6.4.3 Planung ........................................................................................................... 102

6.4.4 Durchführung.................................................................................................. 105

6.4.5 Abschlussarbeiten ........................................................................................... 114

6.4.6 Schlussbemerkungen zum Prüfprozess........................................................... 115

6.5 Zusammenfassung ...................................................................................................... 115

7 Schlussbetrachtung ............................................................................................................ 116

7.1 Zusammenfassung ...................................................................................................... 116

7.2 Schlussfolgerungen..................................................................................................... 117

7.3 Ausblick...................................................................................................................... 117

8 Literaturverzeichnis........................................................................................................... 119

Inhaltsverzeichnis VI

9 Anhang ................................................................................................................................ 125

9.1 Experteninterviews ..................................................................................................... 125

Wolfgang Pfister, Senior Consultant Unisys .............................................................. 126

Patrik Allenspach, Leiter IT-Revision Luzerner Kantonalbank ................................. 134

Jürg Illi, Interne Revision, Credit Suisse Group......................................................... 143

Michel Huissoud, Vize-Direktor Eidgenössische Finanzkontrolle ............................ 151

Frank Mühlenbrock, IT Architect, IBM Deutschland ................................................ 158

Frank Hammer, Manager Business Compliance & Risk Management pan IOT ....... 158

Mark Dambacher, Senior Manager, PricewaterhouseCoopers................................... 171

9.2 IT-Sicherheitsstandards .............................................................................................. 177

1. Einleitung VII

Abbildungsverzeichnis

Abbildung 1: Verschiedene Sichten in einer Outsourcing-Beziehungen........................................8

Abbildung 2: Kunden-Anbieter-Beziehungen beim Outsourcing (1) ...........................................17

Abbildung 3: Kunden-Anbieter-Beziehungen beim Outsourcing (2) ...........................................18

Abbildung 4: Risiken aus Outsourcer-Sicht..................................................................................23

Abbildung 5: Die prozessabhängige und prozessunabhängige Internal Control ..........................27

Abbildung 6: COSO Framework...................................................................................................30

Abbildung 7: COBIT Framework .................................................................................................35

Abbildung 8: ITIL Überblick ........................................................................................................37

Abbildung 9: Verhältnis von Informationssicherheit und IT-Security .........................................38

Abbildung 10: Bedrohungsarten für Unternehmen.......................................................................40

Abbildung 11: IT-Prozesse im COBIT Framework mit Bezug auf Sicherheitsfragen .................41

Abbildung 12: Managementgebiete und Massnahmen im ISO 17799 .........................................43

Abbildung 13: Entwicklung zum Common Criteria .....................................................................45

Abbildung 14: Überblick über die Zusammenarbeit der verschienden Parteien im Outsourcing 50

Abbildung 15: Involvierte Parteien bei der IT-Sicherheitskonzepterstellung...............................57

Abbildung 16: Unterschiede SAS 70 Report Typ I und Typ II ....................................................68

Abbildung 17: Beispiele von Bereichen und Prozessen einer SAS 70 Prüfung ...........................70

Abbildung 18: Unterschiede zwischen SAS 70 und Trust Services .............................................84

Abbildung 19: Unterschiede SAS 70 zu ISO 9000.......................................................................85

Abbildung 20: Die vier Phasen eines Prüfprozesses .....................................................................89

Abbildung 21: Beziehung Generellen Kontrollen zu Applikationskontrollen..............................91

Abbildung 22: Verbuchung eines Warenverkaufs inkl. möglicher Risiken und Kontrollen ........93

Abbildung 23: Konzeptüberblick SAS 70 Prüfprozess.................................................................96

Abbildung 24: Auswahl Interviewpartner für SAS 70 Prüfung..................................................101

Abbildung 25: Vorschlag für den Prozess zur Risikoidentifizierung .........................................104

Abbildung 26: Beschreibung der Kontrollen ..............................................................................109

Abbildung 27: Beispielfrage der Logischen Sicherheit für Kunde ABC...................................112

Abbildung 28: IT-Sicherheitsstandards.......................................................................................177

1. Einleitung VIII

Abkürzungsverzeichnis

AGS Auditing Guidance Statement

AICPA American Institute of Certified Public Accountants

ASP Application Service Provider

AUS Auditing Standard

BPO Business Process Outsourcing

BS British Standard

BSI Bundesamt für Sicherheit in der Informationstechnik

BTO Business Transformation Outsourcing

CC Common Criteria

CICA Canadian Institute of Chartered Accountants

COBIT Control Objectives for Information and Related Technology

COCO Criteria of Control Board

CoP Code of Practice

COSO The Committee of Sponsoring Organizations of the Treadway Commission

CSA Control Self Assessment

CTCPEC Canadian Trusted Computer Product Evaluation Criteria

DS Delivery and Support

DSG Datenschutzgesetz

EBK Eidgenössische Bankenkommission

FC Federal Criteria

FIT Faculty of Information Technology

GzA Grundsatz zur Abschlussprüfung

IC Internal Control

ICAEW Institute of Chartered Accountants in England and Wales

IFAC International Federation of Accountants

IIA The Institute of Internal Auditors

ISA International Standards on Auditing

1. Einleitung IX

ISACA Information Systems Audit and Control Organization

ISK Interne Steuerung und Kontrolle

ISMS Informationssicherheits-Managementsystem

ISO International Organization for Standardization

IT Informationstechnologie

IT-GSHB IT-Grundschutzhandbuch

ITIL IT Infrastructure Library

ITSEC Information Technology Security Evaluation Criteria

KGI Key Goal Index

KPI Key Performance Index

OGC Office of Government Commerce

OR Obligationenrecht

PCAOB Public Company Accounting Oversight Board

PS Prüfungsstandard

RS Rundschreiben

SAP Statement on Auditing Procedures

SAS Statement on Auditing Standard

SEC Securities and Exchange Commission

SLA Service Level Agreement

SOX Sarbanes-Oxley Act

SRA Self Risk Assessment

VPN Virtual Private Network

1. Einleitung 1

1 Einleitung

1.1 Problemstellung

Das Auslagern von internen Informatikleistungen (Outsourcing) an Service Anbieter ist eine

Bestrebung, die seit Jahren besteht und weiterhin sehr aktuell ist. Mit der Übergabe von

Informatikleistungen gehen auch die Risiken an den betreffenden Service Anbieter über. Es stellt

sich nun die Frage, ob mit der Übergabe auch die Probleme abgegeben werden können. Die

Diskussion dieser Aussage ist unter anderem Teil dieser Arbeit. Dabei kommt insbesondere der

Internen Revision des Outsourcer eine wichtige Rolle zu. Inwiefern wird die Interne Revision als

Bestandteil der Internal Control durch das Auslagern der Leistungen entlastet bzw. belastet?

Kann die Interne Revision auf Outsourcing-Entscheide Einfluss nehmen?

Darüber hinaus wird nicht nur der Internen Revision des Outsourcer bei einem Outsourcing eine

besondere Stellung zugewiesen, auch die externe Prüfgesellschaft des Outsourcer muss bei ihrer

jährlichen Attestierung abklären, inwiefern die ausgelagerten Komponenten für die

Abschlussprüfung relevant sind. Kommt diese zum Schluss, dass eine Wesentlichkeit besteht, so

müssen Vorkehrungen getroffen werden. Die Handlungsmöglichkeiten werden in der folgenden

Arbeit besprochen.

Auf Service Anbieterseite bestehen ebenfalls weitgehende Problemfelder. Der Service Anbieter

muss sicherstellen können, dass Kundendaten persistent und vor Eindringlingen (interne und

externe Personen) geschützt sind. Um diese Sicherheit zu gewährleisten, müssen die Systeme,

die Infrastruktur und die personelle Organisation des Service Anbieters von einer externen

Instanz geprüft werden. Es existieren verschiedene Standards und Zertifikate, die eine solche

Sicherheit gewährleisten können.

Neben den verschiedenen Zertifizierungsmöglichkeiten nimmt der SAS 70 Report immer mehr

an Bedeutung zu. Dieser Standard wurde vom AICPA im Jahre 1992 mit dem Ziel veröffentlicht,

die Internal Control und dabei insbesondere die Interne Steuerungs- und Kontrollprozesse der

Service Anbieter offenzulegen und zusätzlich eine Aussage über deren Qualität vorzunehmen.

Eine SAS 70 Prüfung beinhaltet dabei sehr viele Einsatzbereiche. Ein Bereich, der Bestandteil

einer SAS 70 Prüfung sein kann, ist die IT-Security. Dabei steht die Diskussion im Vordergrund,

wie der Service Anbieter mittels Infrastruktur, Zugriffskontrollen und weiteren

Sicherheitsrichtlinien gewährleisten kann, dass die Kundendaten vor Angriffen oder vor

1. Einleitung 2

Fremdzugriffen geschützt sind. Es müssen entsprechende Kontrollen und Vorkehrungen

vorhanden sein, die mittels SAS 70 auf ihre Effektivität hin geprüft werden.

Der Sarbanas-Oxley Act ist ein Gesetz, welches im Jahre 2002 in den USA erlassen wurde, mit

dem Ziel die Investoren vor falscher finanzieller Berichterstattung des Unternehmen zu schützen.

Dieses Gesetz fordert und fördert die stärkere Sensibilisierung auf die Internal Control, was auch

dem SAS 70 verhilft, eine immer bedeutendere Rolle zu spielen. In den USA bereits üblich bzw.

Pflicht, ist SAS 70 in Europa und insbesondere in der Schweiz noch nicht verbreitet. SAS 70

gewinnt aber unter den Service Anbietern immer mehr an Popularität, denn es kann im harten

Markt ein entscheidendes Auswahlkriterium für den potentiellen Outsourcer sein.

Da die SAS 70 Prüfung keine Checklistenprüfung darstellt und dementsprechend kein

standardisiertes Prüfverfahren existiert, sind Schwierigkeiten bei der Prüfung zu erwarten. Ein

Vorschlag für ein Prüfverfahren wird im Verlaufe dieser Arbeit erarbeitet.

1.2 Zielsetzung

Durch das Outsourcing ergeben sich Veränderungen bezüglich der Aufgaben der Externen und

Internen Revision. Die vorliegende Arbeit zeigt, inwiefern sich die Arbeit der Revisoren durch

das Outsourcing ändert. Eine Möglichkeit die Arbeit diesbezüglich zu vereinfachen, bietet der

SAS 70 Report. Da dieser Report in der Schweiz bis jetzt noch kaum angewendet wird, hat diese

Arbeit zum Ziel, SAS 70 und den daraus entstehenden Nutzen für die Parteien tiefgründig

vorzustellen. In den weiteren Ausführungen wird ersichtlich, dass SAS 70 keine Vorschriften

bezüglich des Prüfumfangs macht. Deshalb wird im letzten Teil der Arbeit ein Konzept für eine

SAS 70 Prüfung im IT-Security Bereich erarbeitet, mit dem Ziel, dem Leser eine mögliche

Vorgehensweise für eine SAS 70 Prüfung näher zu bringen. Durch diesen erarbeiteten

Prüfprozess kann der Unterschied zwischen einer gewöhnlichen Prüfung und einer SAS 70

Prüfung hervorgehoben werden.

1.3 Vorgehensweise und Aufbau

Einleitend werden die theoretischen Grundlagen betreffend den Themen Outsourcing und

Internal Control gegeben. Nachdem die Grundlagen der Internal Control beschrieben werden,

wird der Fokus vermehrt auf die IT und dabei insbesondere auf die IT-Security gelegt. Durch die

beiden Grundlagenkapitel kann mit dem vierten Kapitel die Verknüpfung der beiden

1. Einleitung 3

vorangehenden Kapitel stattfinden, die mit Expertenaussagen ergänzt werden. Dabei rückt

wiederum die IT-Security ins Zentrum. Nachdem ein theoretischer Einschub mit dem Kapitel

über SAS 70 gemacht wird, kommt im letzten Teil der Arbeit der zweite praktische Teil zum

Zuge. Mittels den Erkenntnissen der erarbeiteten Theorie und den aus den Experteninterviews

gewonnenen Informationen, wird ein SAS 70 Prüfprozess mit speziellem Fokus auf die IT-

Security erarbeitet.

2. Grundlagen des Outsourcing 4

2 Grundlagen des Outsourcing

Das Auslagern von Aufgaben an Dritte ist eine Bestrebung, die seit Jahren besteht. Angetrieben

durch die geplatzte IT1-Blase in den 90er Jahren und dem daraus resultierenden Leistungsdruck,

stellten sich Unternehmen zunehmend die Frage nach dem Nutzen der bis anhin getätigten

Investitionen im IT-Bereich und im gleichen Atemzug nach der Leistungsfähigkeit ihrer

bestehenden IT-Infrastruktur.

Ziel dieses Kapitels ist, die Thematik des Outsourcing näher zu bringen. Ausgehend von der

Definition werden die Gründe, die verschiedenen Varianten und organisatorische Formen

aufgezeigt. Im letzten Teil werden die rechtlichen Aspekte eines Outsourcing besprochen und

auf die Risiken hingewiesen.

2.1 Definition Outsourcing

Der Begriff Outsourcing stammt aus den Wörtern Outside und Resourcing, die Bezeichnung für

Auslagerung und Ausgliederung.2 Outsourcing beschreibt die Abspaltung von

Unternehmensaufgaben und –strukturen an Drittunternehmen, sogenannten Service Anbietern3.

Diese Service Anbieter haben sich darauf spezialisiert, Bereiche bzw. Services anzubieten, die

nicht zu den Kernkompetenzen des Outsourcer4 gehören. Das Outsourcing unterscheidet sich

von der blossen Auftragsvergabe dadurch, dass es sich meist um Unternehmenstätigkeiten

handelt, die vorher selbst erbracht wurden. Eine Käufer-Verkäufer Beziehung, wie sie bei einer

Auftragsvergabe typisch ist, existiert im Outsourcing nicht. Vielmehr beschreibt das Outsourcing

eine gemeinsame Partnerschaft, die je nach Komplexität bis zu zehn oder fünfzehn Jahre

andauern kann.5

„Die“ Definition für Outsourcing existiert nicht. Da es unterschiedliche Varianten von

Outsourcing gibt, ergeben sich unterschiedliche Arten von Definitionen.6 Alle Definitionen

1 Information Technology. 2 Vgl. Heinrich (2002), S. 105. 3 Service Anbieter nennt man auch Insourcer, Dienstleistungsanbieter oder Outsourcing Provider. In dieser Arbeit wird konsequent die Bezeichnung „Service Anbieter“ verwendet. 4 Als Outsourcer wird in dieser Arbeit als das Unternehmen bezeichnet, welches Bereiche zum Service Anbieter auslagert und somit als Leistungsempfänger fungiert. 5 Vgl. Abschnitt 2.5.1 Der Outsourcing-Vertrag. 6 Vgl. Abschnitt 2.3 Outsourcing-Dimensionen.


zielen aber darauf hin, dass durch die Aufspaltung der Wertschöpfungskette Aufgaben an

Service Anbieter abgegeben werden, um die eigene Kernkompetenzfokussierung anzustreben.

Im Rahmen dieser Arbeit wird der Fokus im speziellen auf das IT-Outsourcing, eine Variante

des Outsourcing, gelegt. Mit IT-Outsourcing wird der längerfristige externe Bezug einer

wesentlichen Leistung oder Funktion im Aufbau oder im Betrieb der IT-Infrastruktur

verstanden.7 Durch die teilweise oder ganze Auslagerung ihrer IT beansprucht der Outsourcer

Dienstleistungen vom Service Anbieter, damit die Geschäftstätigkeit gewährleistet werden kann.

Darunter fallen z.B. Dienstleistungen wie: Systementwicklung, Betreuung von Softwareappli-

kationen oder Management der IT-Infrastruktur. Im Abschnitt 2.3.1 wird die Thematik

eingehend vorgestellt.

2.2 Entwicklung und Gründe für Outsourcing

Ziel dieses Abschnittes ist es, den historischen Hintergrund und die rasante Entwicklung des

Outsourcing zu erläutern. Die Entwicklung wurde durch verschiedene externe Gegebenheiten,

wie z.B. die bis anhin andauernden wirtschaftlich schwierigen Zeiten und die daraus

resultierenden Sparmassnahmen für die Unternehmen beeinflusst. Im Abschnitt 2.2.1 wird die

Entwicklung des Outsourcing von den Anfängen bis zum jetzigen Stand erläutert. Wieso sich

Outsourcing so grosser Beliebtheit erfreut, wird in Abschnitt 2.2.2 aus den verschiedenen

Perspektiven der Outsourcing-Teilnehmer erläutert.

2.2.1 Entwicklung des Outsourcing

Outsourcing kann als Weiterführung der Rationalisierungsbestrebungen der Unternehmen

betrachtet werden. Angeführt durch die Fliessbandarbeit Anfang des letzten Jahrhunderts und

dem Mitte der 80er Jahre aufkommenden Konzepts der „Lean Production“8, schreitet

Outsourcing als neue Möglichkeit der Wertschöpfungsketteoptimierung in den Vordergrund.

Dabei kann Outsourcing als Weiterführung der Lean-Philosophie betrachtet werden. Beim Lean

7 Vgl. Billeter (1995), S. 11. 8 Lean Production heisst zu Deutsch: schlanke Produktion. Die japanische Automobilindustrie prägte den Begriff der Lean Production. „Just-in-time-Herstellung“ wird oftmals als Synonym für Lean Production verwendet.


Management9 geht es darum, das eigene Unternehmen schlanker zu gestalten, um so die

Effizienz zu erhöhen. Durch organisatorische Massnahmen wird jede Form von Überkapazitäten

abgebaut. Die Qualität der Produkte und Prozesse werden verbessert und die Abläufe werden

vereinfacht.10

Viele westliche Unternehmen waren aus wirtschaftlichen Gründen dazu gezwungen, die

Prinzipien der schlanken Produktion zu übernehmen und in sämtlichen Unternehmensbereichen

anzuwenden.11 Outsourcing stellt dabei eine Möglichkeit dar die Organisation schlanker zu

gestalten und die Kernkompetenzfokussierung anstreben.

Im IT-Bereich fanden bereits in den 60er Jahren des 20. Jahrhunderts erste Bestrebungen statt,

Teile der Datenverarbeitung auszulagern. Als Meilenstein des IT-Outsourcing wird das Kodak

Outsourcing-Geschäft12 aus dem Jahre 1989 genannt. Es war das erste bekannte und erfolgreiche

Outsourcing-Vorhaben eines grossen Unternehmens. Dieses Geschäft löste einen regelrechten

Outsourcing Boom aus.

In den letzten Jahren hat die Relevanz des IT-Outsourcing etwas abgenommen. Das Ziel der

Senkung kurzfristiger operativer Kosten wird immer mehr von Erschliessung strategischer

Potentiale im Rahmen von langfristigen Partnerschaften abgelöst. In diesem Kontext sind neue

Outsourcing-Formen wie das „Business Process Outsourcing“ entstanden. Die Entwicklung des

Outsourcing ist damit nicht abgeschlossen. Als dritte Welle der Outsourcing-Entwicklung rückt

das „Business Transformation Outsourcing“ immer mehr in den Vordergrund. Dabei wird die

Partnerschaft mit dem Service Anbieter gewählt, damit die Neugestaltung der Prozesse für den

Outsourcer einen Mehrwert generiert. 13

Trotz Outsourcing bleibt der Kosteneinsparungsdruck für die Unternehmen weiterhin bestehen.

Aus diesem Grund werden Dienstleistungen vermehrt ins Ausland verlagert, in sogenannte

Billiglohnländer wie beispielsweise Indien. In diesem Zusammenhang spricht man von

Offshoring. Beim Offshoring werden die physisch vorhandenen Arbeitsplätze und die

Tätigkeiten ins Ausland transferiert. Durch die geographische Ferne wurde der

Koordinationsaufwand für die Unternehmen zu einer starken Belastung. Deswegen kam Ende

9 „Lean Management“ ist aus dem Begriff „Lean Production“ hevorgegangen und hat im Grunde die gleiche Bedeutung, mit dem Unterschied, dass „Lean Management“ einen breiteren Anwendungsbereich hat, z.B. in den Bereichen Handel, Dienstleistung und Industrie. 10 Vgl. Hässig (2000), S. 24. 11 Vgl. Hässig (2000), S. 24 – 25. 12 Die Zusammenarbeit zwischen Kodak und IBM hatte ein Volumen von 250 Millionen US Dollar über zehn Jahre. 13 Business Process Outsourcing und Business Transformation Outsourcing wird eingehend in den Abschnitten 2.3.3 bzw. 2.3.4 vorgestellt und diskutiert.


der 90er Jahre die Bestrebung auf, die Tätigkeiten und Arbeitsplätze nicht ins „entfernte“

Ausland auszulagern, sondern es wurde die Nähe zum eigenen Unternehmen gesucht. So wurden

europäische Billiglohnländer wie Polen, Tschechien oder Ungarn immer beliebter. Diese

Möglichkeit wird als Nearshoring bezeichnet.

2.2.2 Gründe für Outsourcing

Das Bestreben, ein Outsourcing-Geschäft zu vollziehen, hat vielseitige Gründe. Grundlagen für

ein Outsourcing sind nicht nur unternehmensinterne Bedingungen, sondern auch Änderungen in

der Umwelt. Bei der Outsourcing-Diskussion geht es weitgehend um folgende Frage: Welche

Leistungen erbringen für das Unternehmen einen wesentlichen Beitrag zur Wertschöpfung und

welche kostenintensive Leistungsbereiche leisten wenig bzw. kaum was bei? Die

kostenintensiven Leistungen mit einem geringen Beitrag zur Wertschöpfung werden nach

Möglichkeit an Service Anbieter ausgelagert. Kostenüberlegungen sind nicht die einzigen

Treiber der „make-or-buy“-Entscheidung. Strategische Gründe sprechen auch für das Auslagern

von bestimmten Aufgaben. Die strategische Bedeutung der IT innerhalb des Unternehmens ist

ein entscheidender Faktor für die Outsourcing-Entscheidung. Die IT degeneriert immer mehr zu

„Commodity“, d.h. sie wird immer mehr als Massenware angesehen. Die IT-Infrastruktur bleibt

zwar eine wichtige Einflussgrösse für den Wettbewerb, jedoch machen sie die allgemeine

Verfügbarkeit und die kostant sinkenden Preise auf der Unternehmensebene zunehmend

ungeeignet, um sich von Wettbewerbern zu unterscheiden. Mit dem Outsourcing von Bereichen,

die nicht zum Kerngeschäft gehören, resultiert eine schlankere Organisation, die an Schlagkraft

gewinnt, wovon die Anteilseigner auch profitieren.14

In den weiteren Ausführungen werden verschiedene Gründe und Treiber einer Outsourcing-

Entscheidung erläutert. Dies geschieht unter der Berücksichtigung der verschiedenen

Perspektiven: Outsourcer-, Markt- und Service Anbietersicht.

14 Vgl. Deutsche Bank Research (2004), S. 4.


Kostendruck

(Outsourcer)

RegulatorischeÄnderungen

(Outsourcer)

Outsourcing Beziehung

Revenue-Zwang

(Service Anbieter)

Änderung der Marktbedingungen

Technologie-Änderungen

Outsourcer Markt Service Anbieter

Abbildung 1: Verschiedene Sichten in einer Outsourcing-Beziehungen

Die folgenden Ausführungen zeigen, welche Gründe hinter den in Abbildung 1 dargestellten

verschiedenen Sichten stecken und wie die Sichten bzw. deren Interessen miteinander in

Beziehung stehen.

a) Outsourcer Sicht

Das Management des Outsourcer besitzt zwei Hauptbeweggründe, um sich über Outsourcing

Gedanken zu machen: Kosten und Qualität.15 Können die jetzigen Services billiger bereitgestellt

werden, ohne dass die Qualität leiden muss? Insbesondere Kosten sind dabei oftmals

Beweggründe einer Outsourcing-Entscheidung.16 Doch lässt sich das Outsourcing-Vorhaben

nicht nur auf Kostenüberlegungen reduzieren. Vielmehr sind Überlegungen in finanzieller und

auch personeller Hinsicht zu berücksichten. Die einzelnen Komponenten werden im Folgenden

erläutert:

15 Vgl. Applegate /Austin / McFarlan (2003), S.566. 16 Vgl. Anhang Interview Allenspach.


Kosten

Der Outsourcer wird durch den wirtschaftlichen Druck dazu gezwungen seine Kosten zu senken.

Das Outsourcing ermöglicht Kostentransparenz und durch das Ausschöpfen von Grössen- und

Breitenvorteilen des Service Anbieters können die Kosten reduziert werden.17 Die bis anhin

variablen Kosten werden in Fixkosten umgewandelt, was die Kosten für das Management besser

planbar macht.

Qualität

Durch den Zugang zu neuen Technologien kann gewährleistet werden, dass spezielles Know-

how sichergestellt wird und die neuesten Technologien verwendet werden können. Diese

Möglichkeiten erhöhen die Qualität für das eigene Unternehmen und ermöglichen, dass durch

die laufend erneuerte Technologie die Geschwindigkeit hinsichtlich der eingesetzten IT-

Infrastruktur und IT-Diensleistungen erhöht wird.

Personal

Eine grosse Schwierigkeit des Unternehmens ist, Mitarbeiter zu finden, die genügend Know-how

im IT-Bereich mitbringen. Diese besitzen sehr oft ein spezifisches Fachwissen der IT. Diese

Tatsache ermöglicht, dass eine Abhängigkeitsbeziehung zwischen ihnen und dem Unternehmen

zu Stande kommt. Durch das Outsourcing kann gewährleistet werden, dass das Unternehmen

sich nicht darauf konzentrieren muss, Fachpersonen zu rekrutieren, und dass eine Abhängigkeit

von Personen mit Spezial-Know-how verringert wird. Durch den Übergang der IT-Fachpersonen

an die Service Anbieter kann der Personalkostenblock, der ein wesentlicher Bestandteil der

Kosten eines Unternehmens ausmacht, gedrückt bzw. eliminiert werden.

Finanzen

Ein Outsourcing hat zur Folge, dass die hohen Investitionen, die für eine Wartung bzw. neu

einzurichtende IT-Infrastruktur nötig wären, nicht mehr anfallen. Durch diese Reduktion des

gebundenen Kapitals kann die Zahlungsfähigkeit des Unternehmens verbessert werden. Dies

kann einerseits durch den allfälligen Verkauf der IT-Infrastruktur an den Service Anbieter

17 Vgl. Billeter (1995), S.41.


begünstigt werden, und andererseits kann ein positiver Einfluss auf die Jahresrechnung erzielt

werden.18

b) Service Anbieter Sicht

Wie alle Unternehmen stehen auch die Service Anbieter dem Zwang gegenüber, Erlöse zu

generieren. Ein Auftrag von einem Kunden zu erhalten, heisst nicht nur, dass mehr Ertrag für

den Service Anbieter generiert wird, vielmehr sollte auch die daraus entstehende Reputation

berücksichtigt werden. Wird ein sogenannter „Mega Deal“ erreicht, so wird dieser nachhaltig

bekannt bleiben. Dies führt dazu, dass die Reputation bei einer Outsourcing-Entscheidung ein

zentraler Wettbewerbsfaktor sein kann.

Durch die langfristigen Outsourcing-Verträge, bei der die Mindestleistungen im Vertrag fixiert

werden, sind anfallende Kosten und der minimal erreichbare Umsatz über Jahre hinweg besser

planbar. Im Vergleich zum Projektgeschäft ist ein Outsourcing-Vertrag wegen der beschrie-

benen Berechenbarkeit lukrativer.19 Ein weiterer Grund der durch die Experten genannt wurde,

ist die Möglichkeit eigenen Ressourcen einzusparen, da durch das Outsourcing die Prozesse

vereinheitlicht und auf mehrere Kunden angewendet werden können.20

c) Markt Sicht21

Der technologische Fortschritt im IT-Bereich hatte einen radikalen Wandel in den

Wirtschaftsstrukturen zur Konsequenz. Das Wachsen der IT-Branche mit der Möglichkeit,

Informationen ohne Zeitverlust einfach und wirtschaftlich auszutauschen, hat die Tendenz zur

Globalisierung der Märkte vorangetrieben. Der Industriesektor unterzog sich dem Wandel von

einem nationalen oder allenfalls kontinentalen in einen globalen Wettbewerb. Durch diesen

rasanten Wandel im Markt entstehen für die am globalen Markt teilnehmenden Firmen,

zusätzlichen Druck, der zwangsläufig auch Konsequenzen in den Leistungs- und

Organisationsstrukturen bewirkt.

Die Wettbewerbssituation wird aufgrund der zunehmenden Marktransparenz intensiviert.

Existierenden und neuen Marktteilnehmern fällt es immer schwerer, dem Kunden einen

18 Vgl. Billeter (1995), S.42. 19 Vgl. Anhang Interview Pfister. 20 Vgl. Anhang Interview Mühlenbrock / Hammer. 21 Vgl. Billeter (1995), S. 16.


Mehrwert zu bieten. Erschwerend für die Marktteilnehmer treten neben den technologischen

Innovationen immer mehr staatliche Regulatorien in den Vordergrund.

2.3 Outsourcing-Dimensionen

Outsourcing wird oftmals nur mit IT in Verbindung gebracht. Outsourcing lässt sich aber nicht

nur auf die IT reduzieren, sondern weist ein weites Spektrum auf. Dieser Abschnitt zeigt ausser

dem IT-Outsourcing die weiter bestehenden Outsourcing-Dimensionen auf. Diese Outsourcing-

Varianten haben in den letzten Jahren immer mehr an Bedeutung dazu gewonnen.

2.3.1 IT-Outsourcing

Das IT-Outsouring als bekannteste Outsourcing-Form, beinhaltet das Auslagern von IT-

Systemen an einen Service Anbieter. Für diese Auslagerung gibt es verschiedene Varianten, die

nachfolgend erläutert werden:

Umfassendes IT-Outsourcing

Die umfangreichste Form des IT-Outsourcing ist die komplette Ausgliederung und Übergabe der

gesamten IT an einen Service Anbieter. Meist übernimmt der Service Anbieter in einem solchen

Fall ganze IT-Abteilungen des Kunden, wobei die Mitarbeiter direkt zum Service Anbieter oder

in ein Joint Venture Unternehmen22 zwischen Outsourcer und Service Anbieter wechseln. Beim

Komplett-Outsourcing handelt es sich immer um individuelle Dienstleistungen, da der Service

Provider sich auf die Prozesse und die existierende IT-Landschaft der Kunden einstellen muss.

Auslagern einzelner IT-Aufgaben

Anstatt eines umfassenden IT-Outsourcing können auch ausgewählte IT-bezogene Aufgaben

ausgelagert werden. In diesem Zusammenhang wird von „selektivem Outsourcing“ oder

„Outtasking“ gesprochen. Outtasking Services gehen von der Konzipierung über den Betrieb bis

zur Wartung der IT Systeme. Dabei wird die operative IT-Verantwortung übernommen, jedoch

bleibt die Kontrolle beim Kunden.

22 Ein Joint Venture entsteht, wenn Unternehmen miteinander kooperieren wollen und aus diesem Zweck eine neue, rechtlich selbständige Geschäftseinheit bilden, an der die Gründungsunternehmen neben Kapital wesentliche Ressourcenanteile wie Technologie, Know-how oder Betriebsanlagen einbringen.


Nachfolgend werden die möglichen Formen des Teil-Outsourcing besprochen: 23

Facilities Management

Der Service Anbieter übernimmt den Betrieb der physischen IT-Infrastruktur des Outsourcer und

ist dabei für die Bereitstellung der geforderten Qualität verantwortlich. Das Facilities

Management beinhaltet drei verschiedene Optionen:

1. Netzwerk-Outsourcing: Der Service Anbieter übernimmt den Netzwerkbetrieb eines

Unternehmens. Dabei unterscheidet man zwischen:

„Managed Networks“: 24

Die gesamte Netzwerkleistung wird dem Service Anbieter übertragen. Bei diesem

Netzwerk-Outsourcing verpflichtet sich der Service Anbieter, gemäss den Service Level

Agreements25 die geforderte Leistung zu erbringen. Er trägt die alleinige

unternehmerische und operationelle Verantwortung für die eingesetzte Technologie und

Organisation.

Netzwerk-Management Outsourcing:

Bei dieser Variante besitzt das Unternehmen eine eigene Netzwerkinfrastruktur, jedoch

wird die Betriebsverantwortung dem Service Anbieter übertragen. Man spricht dabei von

Outsourcing der Netzwerk-Management-Verantwortung.

„Virtual Private Networks“ (VPN)

VPN kann als Umkehrung des Netzwerk-Management-Outsourcing betrachtet werden.

Hierbei hat das Unternehmen eine eigene Betriebsorganisation, verzichtet jedoch auf den

Aufbau einer eigenen Netzwerkinfrastruktur. Der Service Anbieter stellt den

Unternehmen physische Ressourcen in seinem Netzwerk zu Verfügung und zusätzlich

noch Werkzeuge für die Konfiguration und Überwachung.

23 Vgl. Billeter (1995), S. 241 – 260. 24 Vgl. Billeter (1995), S. 245. 25 Service Level Agreements (SLA) sind vetraglich fixierte Abmachungen zwischen dem Outsourcer und dem Service Anbieter. Sie definieren den Leistungsumfang, der vom Service Anbieter erbracht werden muss. Eine weiterführende Diskussion zu SLA wird in Abschnitt 2.5.2 geführt.


Hardware-Outsourcing

Beim Hardware-Outsourcing geht es um die Übertragung der physischen Komponenten vom

Outsourcer an den Service Anbieter. Die Unterscheidungen, die man hier antrifft, sind:

Rechenzentren

Der Betrieb der Rechenzentren und damit die Verantwortung über die Server werden

dem Service Anbieter übertragen. Dieser ist für den korrekten Betrieb und Wartung des

Rechenzentrums verantwortlich.

Dezentrale Einrichtungen

Die Verbreitung von Computern am Arbeitsplatz dezentralisierte die IT-Kapazitäten. Der

Service Anbieter wird mit der Installation und dem Betrieb von Computernetzwerken und

der Betreuung der Benutzer beauftragt. Die Betreuung der Client-Server-Technologien

fällt hier immer mehr ins Gewicht.

Spezialleistungen

Zu den spezialisierten Leistungen zählen vor allem die Bereitstellung von Backup-

Infrastrukturen im Rechenzentrumbereich. Die Spezialleistungen sind Nischenmärkte, die

meistens auch sehr stark lokal geprägt sind.26

2.3.2 Business Application Outsourcing

Bei einem Application Outsourcing wird dem Kunden durch den Service Anbieter eine

Standardsoftware zur Benützung zur Verfügung gestellt, mit dem Ziel, dem Kunden kurzfristige

Kosteneinsparung zu ermöglichen. Grundsätzlich kann zwischen Application Hosting und

Application Service Providing (ASP) unterschieden werden.

Application Hosting

Das Application Hosting ist eine Dienstleistung vom Service Anbieter, bei der Standardsoftware

gegen finanzielle Entschädigung zur Verfügung gestellt wird, wobei die Software an den Kunden

26 Vgl. Billeter (1995), S. 249.


angepasst wird (one-to-one-approach).27 Die für den Kunden optimierte Standardsoftware wird

aus einem Rechenzentrum des Service Anbieters betrieben. Der Zugriff auf die Leistungen des

Application Host Anbieters erfolgt über verschiedene Verbindungen und VPN-Leitungen. Die

Software-Lizenz geht an den Kunden und der Service Anbieter ist für die Wartung und

Aktualisierung der Software verantwortlich.

Application Service Providing (ASP)28

Unter ASP wird eine Dienstleistung verstanden, bei der dem Kunden Standardsoftware zur

Verfügung gestellt wird, die jedoch nicht an den Kunden angepasst wurde (one-to-many-

approach). Wie beim Application Hosting werden die Softwarepakete in einem Service-

Rechenzentrum zur Verfügung gestellt, in dem die Kunden die Leistung beziehen können. Die

Software-Lizenz bleibt, anders als beim Application Hosting, im Besitz des Service Anbieters.

Der Service Anbieter ist weiter für die Wartung, Aktualisierung und dem Benutzerservice

verantwortlich.

2.3.3 Business Process Outsourcing29

Das Business Process Outsourcing (BPO) konzentriert sich auf die internen Dienstleistungs- und

Verwaltungsprozesse. Es beinhaltet das Auslagern von vollständigen Geschäftsprozessen wie

z.B. Personalwesen, Logistik oder Administration an einen Service Anbieter. Im Unterschied zu

IT-Outsourcing werden beim BPO kerngeschäftsnahe und betriebswirtschaftliche Bereiche

ausgelagert.

27 Die Anpassung der Standardsoftware an die spezifischen Wünsche des Kunden nennt man in der Fachliteratur auch „Customizing“. 28 Vgl. Heinrich / Riedl (2004), S. 80. 29 Zu Deutsch: Geschäftsprozess-Outsourcing.


Das BPO lässt sich durch zwei Merkmale kennzeichnen:30

Orientierung des Outsourcer an strategischen Zielen

Als strategische Ziele kann sich der Outsourcer z.B. die Erhöhung des Service Grads oder

die Eröffnung neuer Geschäftsmöglichkeiten vornehmen. Durch das BPO wird dem

Outsourcer ermöglicht, seine strategischen Ziele konsequenter einzuhalten bzw. zu

verfolgen.

Individualtität der Geschäftsbeziehung zwischen Outsourcer und Service Anbieter:

Die Individualität zeigt sich durch die Anpassung der angebotenen Services an das

individuelle Umfeld des Unternehmen. Diese Beziehung wird oft auch als Customization

oder „one-to-one“ - Beziehung bezeichnet.

BPO nimmt in der heutigen Zeit eine immer grössere Stellung ein. Diese Entwicklung wird

durch weitere Kosteneinsparungen der Unternehmen getrieben. Da die Unternehmen gezwungen

sind, weiter Kosten zu senken, werden die Potentiale nicht nur in der IT gesucht, sondern nun

vermehrt auch im Back-office der Unternehmen.

2.3.4 Business Transformation Outsourcing31

Zusätzlich zu den bisher erwähnten Outsourcing Dimensionen ist das Business Transformation

Outsourcing (BTO) in den letzten Jahren vermehrt in den Vordergrund gerückt. Im

vorhergehenden Abschnitt wurde das Business Process Outsourcing vorgestellt, bei dem ein

Service Anbieter einen Geschäftsprozess unverändert mit dem Ziel der Effizienzsteigerung

übernimmt. BTO geht deutlich weiter. Beim BTO werden die übernommenen Prozesse

verbessert oder gegebenfalls neuzugestalten versucht. Vom Service Anbieter wird ein

Management der Prozesse, der IT-Anwendungen und/oder – der Infrastruktur verlangt, um so

das kostengünstigste Modell für die Leistungsterbringung bereitzustellen. Ziel eines BTO sind

Geschäftsverbesserungen, Leistungssteigerungen und Kosteneffizienz.

Beim klassischen Outsourcing werden Funktionen ausgelagert, die keine oder nur geringe

strategische Bedeutung für das Unternehmen aufweisen. BTO nimmt die Vorgehensweise des

30 Vgl. Riedl (2003), S. 7. 31 Vgl. Schaarschmidt (2003), S. 46 – 50.


klassischen Outsourcing auf, wobei durch die Kombination der Auslagerung von Prozessen,

Applikationen und Infrastruktur die Erfolge erzielt werden. Der Service Anbieter wird zum

Partner auf globaler Ebene, der langfristig gemeinsam mit dem Unternehmen Kostenstrukturen

und Servicegrad ständig optimieren kann. Durch ein BTO sinkt das operative Risiko für den

Outsourcer. 32

BTO wird in der Literatur auch als Synonym für BPO dargestellt.33 Die Gründe für eine

Trennung der zwei Begriffe konnten zu Beginn des Abschnittes erläutert werden. Die

Verschmelzung des BTO zu BPO findet dann statt, wenn die Definition des BPO weit gefasst

und die Neugestaltung der Prozesse als Bestandteil des BPO angesehen wird.

2.4 Organisatorische Formen des IT-Outsourcing

Die Auslagerung von IT kann auf vier unterschiedliche Arten geschehen. Abbildung 2 und

Abbildung 3 veranschaulichen die vier möglichen Formen, die anschliessend erläutert werden.

32 Das BTO wird insbesondere von der IBM bei ihrer „on-demand“ Kampagne vermarktet. Bei einem „on-demand“ Business geht es darum, dass die Geschäftsprozesse durchgängig im eigenen Unternehmen und bei wichtigen Geschäftspartnern, Lieferanten und Kunden integriert sind, damit flexibel und schnell auf die unterschiedlichsten Kundenanforderungen, Marktchancen oder externe Risiken reagiert werden kann. 33 Vgl. Dittrich / Braun (2004), S. 4.


Abbildung 2: Kunden-Anbieter-Beziehungen beim Outsourcing (1)34

1. Inhouse Outsourcing

Das Inhouse Outsourcing ist die schwächste Form des Outsourcing. Die Informatikabteilung

wird zu einem eigenständigen Unternehmen abgespaltet, die alle Informatikdienstleistungen für

den Konzern liefert.35 Unternehmen A und B beziehen ihre IT-Leistungen ausschliesslich vom

konzerninternen Informatikunternehmen.

2. Fallweiser Zukauf von Fremdleistungen

Die zweite Variante ergibt sich, wenn die interne Informatikunternehmung extern die Hardware

oder verschiedene Leistungen einkauft, aber innerhalb des Konzerns immer noch als die einzige

IT-Dienstleistungsquelle fungiert. Die Unternehmen A und B erkennen im besten Fall nicht, dass

das interne Informatikunternehmen seine Leistungen teilweise extern bezieht.

34 Vgl. Bauknecht (2003), S. 13. 35 Vgl. Krcmar (2003), S. 296.


Abbildung 3: Kunden-Anbieter-Beziehungen beim Outsourcing (2)36

3. Gründung einer am Markt tätigen Tochtergesellschaft

Das interne Informatikunternehmen wird am Markt platziert. So ist es in der Lage auch für die

externe Unternehmen C und D Leistungen zu erbringen und zu beziehen. Das

Informatikunternehmen bleibt aber im Konzern enthalten und bietet weiterhin seine

Dienstleistungen den Unternehmen A und B an.

4. Weitgehendes Outsourcing / Gründung strategische Allianz

Ein externer Service Anbieter integriert die ehemalige interne Informatikabteilung des

Outsourcers vollständig. Zur Erbringung der Dienstleistungen der Unternehmen A und B ist nun

der Service Anbieter zuständig. Der Konzern und der Service Anbieter gehen eine strategische

Allianz37 ein, mit dem Ziel beidseitig Synergieeffekte zu erzielen.

36 Vgl. Bauknecht (2003), S. 14. 37 Eine strategische Allianz ist eine Partnerschaft, bei der die Handlungsfähigkeit der beteiligten Unternehmen in den von der Kooperation betroffenen Bereichen massgeblich eingeschränkt ist. Eine solche Verbindung wird von den beteiligten Unternehmen dann eingegangen, wenn ihre langfristige Existenz und langfristiger Erfolg von einer Kooperation abhängen.


2.5 Rechtliche Aspekte des IT-Outsourcing

Der Erfolg oder Misserfolg eines Outsourcing hängt massgeblich vom Outsourcing-Vertrag ab.

Die detaillierte Ausarbeitung des Vertrages ist der Hauptbestandteil einer erfolgreichen Partner-

schaft. Im Folgenden wird näher auf den Outsourcing-Vertrag eingegangen. Darüber hinaus

werden Service Level Agreements als wichtigste Vertragsbestandteile vorgestellt. Kommt es zu

einem Schadensfall im Outsourcing, so muss die Haftungsfrage diskutiert werden. Auf die

Komplexität dieser Thematik wird in Abschnitt 2.5.3 näher eingegangen.

2.5.1 Der Outsourcing-Vertrag

Angesichts der breiten Palette an möglichen Szenarien im IT-Outsourcing existiert kein

Outsourcing-Mustervertrag. Outsourcing-Verträge sind sogenannte Innominatsverträge.

Innominatsverträge sind Verträge, die gesetzlich nicht geregelt sind und vertragstypologische

Mischformen enthalten.38 Die für das Outsourcing im Vordergrund stehenden Vertragstypen

sind: 39

Werkvertrag

Auftrag

Kaufvertrag

Gesellschaftsvertrag

Je nach Inhalt des Outsourcing-Vertrages liegt es näher, die eine oder andere

vertragstypologische Bestimmung zur Anwendung zu bringen.

Ein Outsourcing-Vertrag ist grundsätzlich auf eine lange Dauer ausgerichtet. Oftmals ist eine

Zeitdauer von 3 - 5 Jahren üblich.40 Bei komplexen Umgebungen und Betrieben kann auch eine

Dauer von 10 - 15 Jahren gängig sein.41 Trotz der langfristigen Auslegung sollte der

Outsourcing-Vertrag möglichst flexibel gestaltet werden.

38 Vgl. Honsell (2001), S. 402. 39 Vgl. Weber (2003), S. 124. 40 Vgl. Anhang Interview Pfister. 41 Vgl. Neuenschwander (2003), S. 72.


Eine Möglichkeit, die sich zur Flexibilisierung bietet, ist die Ausgestaltung des Outsourcing-

Vertrages als Rahmenvertrag42 mit Einzelprojektverträgen für einzelne Projekte, Projektphasen,

IT-Umgebungen oder Dienstleistungskomplexe. Im Rahmenvertrag werden die grundlegenden

Rechte und Pflichten der Parteien festgehalten. Mit Ausnahme von eventuellen Nebenpflichten43

schafft der Rahmenvertrag als solcher noch keine konkreten Leistungsvereinbarungen zwischen

den Parteien. Mit Abschluss der verschiedenen Einzelprojektverträgen respektive Einzelverträge,

die auf dem Rahmenvertrag basieren, entstehen die Pflichten. Für jeden Einzelprojektvertrag

wird eine eigene Leistungsbeschreibung, Preisfestsetzung oder auch Auflösungsbestimmung

festgelegt. Die Einzelprojektverträge werden häufig als Service Level Agreement44 bezeichnet.

Der Vorteil einer solchen modularen Vertragsstruktur liegt in der Flexibilität bezüglich

Zufügung oder auch Ablösung von einzelnen Leistungskomponenten bei gleichbleibenden

allgemeinen Vertragsbestimmungen, was für alle Beteiligten Managementzeit und

Anwaltskosten einspart.

2.5.2 Service Level Agreement

Service Level Agreements (SLA) sind Bestandteile eines Outsourcing-Vertrages. Jede

Einzelleistung bzw. jedes Leistungskriterium, welches vom Service Anbieter erbracht werden

muss, wird in SLA definiert. Anhand der SLA lässt sich die Leistung des Service Anbieter

überprüfen und messen. Bei einer Nichterreichung der Leistungskriterien treffen ihn die im SLA

festgelegten Konsequenzen.

Ein SLA im Outsourcing Bereich lässt sich wie folgt definieren:

„Ein Service Level Agreement ist eine Vereinbarung zwischen einem Kunden und einem

Outsourcing Provider, mit welcher die Parteien messbare Leistungskriterien für die in einem

zwischen diesen Parteien abgeschlossenen Dienstleistungsvertrag festlegen und die Folgen der

Nichteinhaltung dieser Leistungskriterien regeln.“45

42 Im angelsächsischem Raum häufig Master Agreement genannt. 43 Z.B. Geheimhaltungs- und/oder Konkurrenzenthaltungspflichten. 44 Service Level Agreements werden aufgrund ihrer Wichtigkeit separat in Abschnitt 2.5.2 behandelt. 45 Gurovits Kohli (2003), S. 100.


Ein SLA sollte mindestens folgende Punkte regeln: 46

a) Vertragsgegenstand: Der Vertragsgegenstand soll die zu messende Dienstleistung

beschreiben.

b) Spezifikation der Leistungskriterien: Hier werden die Leistungen, die vom Service

Anbieter im Outsourcing gefordert werden, definiert. Die Kriterien sind von beiden

Parteien sehr sorgfältig zu definieren, denn mittels den Leistungskriterien wird die

Leistung des Service Anbieters gemessen.

c) Messverfahren: Für die Messung der definierten Leistungskriterien, wird in diesem Punkt

das konkrete Messverfahren bestimmt. Darüber hinaus wird auch geregelt, welche Partei

die Messungen vornehmen soll.

d) Folgen der Nichteinhaltung der Leistungskriterien: Werden die Leistungskriterien nicht

erreicht, so müssen entsprechenden Sanktionen definiert werden. Für den Service

Anbieter geht es bei der Festlegung der Konsequenzen um Abwägung von Ertrag und

Risiken. Für den Kunden geht es primär darum, ein Druckmittel in den Händen zu halten.

e) Weitere Bestimmungen: Weitere Punkte für eine SLA-Definition sind: Aufbau- und

Ablauforganisation, Prozesse, physische Umgebung, Preis, Change Management47,

Vertragsdauer und allgemeine Bestimmungen48.

2.5.3 Haftung im IT-Outsourcing

Die Frage der Haftung tritt dann auf, wenn Leistungen fehlerhaft erbracht wurden oder Schäden

entstanden sind. Die beste Präventivmassnahme um Unstimmigkeiten zu vermeiden, liegt in der

sorfältigen Aushandlung des Outsourcing-Vertrages d.h. in der sorgfältigen Aushandlung der

SLA. In den SLA werden die verschiedenen Konsequenzen für die Parteien geregelt. Ist ein

Schaden in den SLA definiert, so beschränkt sich die Haftung des Service Anbieters oftmals auf

die Rückerstattung eines Teils des Outsourcing-Betrages, dem sogenannten „Penalty“.49

46 Vgl. Gurovits Kohli (2003), S. 100 – 102. 47 Das Change Management stellt sicher, dass Veränderungen mit Auswirkungen auf die Servicequalität plan- und steuerbar werden. Es steuert dabei Veränderungen im IT-Betrieb unter Berücksichtigung von wirtschaftlichen Gesichtspunkten und minimiert negative Auswirkungen auf die Service Qualität. 48 Z.B. Gerichtsstand. 49 Vgl. Anhang Interview Allenspach.


Es lassen sich jedoch nicht alle zukünftigen Ereignisse vorhersehen und in den SLA definieren.

Entsteht ein Schaden oder eine Fehlleistung, die in den SLA nicht festgehalten sind, so treten die

haftpflichtrechtlichen Gründsätze des dem Outsourcing-Vertrages zu Grunde liegenden Vertrags

in den Vordergrund.50

Bei der Haftung müssen die haftpflichtrechtlichen Grundsätze beachtet werden, ungeachtet der

Frage, welcher Vertragstyp dem Outsourcing-Vertrag zu Grunde liegt. Folgende Aspekte stehen

im Vordergrund: 51

Hilfspersonenhaftung52: Setzt der Service Anbieter für die Aufgabenerledigung

Mitarbeiter ein, hat er für deren Tätigkeiten einzustehen.

Delegation53: Wird die zu leistende Arbeit vom Service Anbieter weitervergeben, ein

sogenanntes Double-Outsourcing, dann ist die Haftung auf die gehörige Sorgfalt bei der

Wahl und Instruktion des Dritten beschränkt.

Die Schadensberechnung in einem Schadensfall wird für alle Vertragstypen nach dem positiven

Vertragsinteresse berechnet, d.h. der Geschädigte wird dabei mit dem entgangenen Gewinn

entschädigt. 54

2.6 Gefahren und Risiken des IT-Outsourcing

Durch die enge Zusammenarbeit zwischen Outsourcer und Service Anbieter können, wie in

Abschnitt 2.2.2 beschrieben wurde, einige Synergieeffekte und Vorteile der Zusammenarbeit

erzielt werden. Ein Outsourcing hat dennoch seine Schattenseiten, die im Folgenden erläutert

werden. Einerseits werden die Risiken aus Outsourcer-Sicht und andererseits aus der Service

Anbieter Sicht vorgestellt.

50 Vgl. Haftung im Auftragsverhältnis Art. 398, 399 und 403 OR, Werkvertrag Art. 367 OR, Kaufvertrag Art. 191 OR. 51 Vgl. Weber (2003), S. 124. 52 Vgl. Art. 101 OR. 53 Vgl. Art. 398 Abs. 3 und Art. 399 Abs. 2 OR 54 Vgl. Honsell (2001), S. 102.


2.6.1 Risiken aus der Outsourcer-Sicht

Die Risiken aus der Outsourcer-Sicht lassen sich in die Kategorien: Kosten, Personal,

Technologie, Datenschutz, Know-how und Insourcing55 gliedern. Abbildung 4 nennt Risiken, die

auftreten können:

Kosten Hohe einmalige Umstellungskosten (Switching Costs), die für den

Transfer der IT-Infrastruktur oder Umstellungen in der Organisation

anfallen

Risiken der vertraglichen Preisfixierung

Nichteintreffen erwarteter Kostensenkungen

Personal

Personalpolitische und arbeitsrechtliche Probleme hervorgerufen

durch mögliche Kündigungen oder Vertragsänderungen, die beim

Wechsel zum Service Anbieter vorgenommen werden müssen

Verlust von Schlüsselpersonen und deren Know-how

Technologie Starre Bindung an die Technologie des Service Anbieter

Gefahr einer zu grossen Standardisierung

Know-how Transfer von Know-how und damit verbundenen Wettbewerbs-

vorteilen an Konkurrenten

Zunehmende Auslagerungsaktivitäten ziehen einen Verlust von IT-

Kompetenzen und Know-how mit sich

Insourcing Durch den Know-how Verlust bei einem Outsourcing, ist es schwierig

das nötige Know-how in der eigenen Firma wieder aufzubauen

Langfristige Bindungen an Outsourcing-Verträge verunmöglichen die

Flexibilität.

Abbildung 4: Risiken aus Outsourcer-Sicht56

55 Als Insourcing wird das Bestreben bezeichnet, die ausgelagerten Bereiche wieder in die eigene Unternehmung zu integrieren. 56 In Anlehnung an Krcmar (2003), S. 295.


2.6.2 Risiken aus der Service Anbieter Sicht

Aus Sicht der Service Anbieter wird insbesondere das personelle Risiko hervorgehoben. Durch

das Outsourcing werden Personen und dementsprechend eine fremde Unternehmenskultur durch

den Service Anbieter übernommen. Diese Integration der Personen stellt nicht nur ein

zusätzlicher Kostenblock für den Service Anbieter dar, welcher insbesondere durch erhöhte

Schulungsaufwände für die Einarbeitung in die Umgebung des Service Anbieters geprägt sind.

Problematischer ist der Integrationsprozess der Personen in die Unternehmenskultur des Service

Anbieters. Diese Umstellung ist nicht ein kurzfristiger, sondern vielmehr ein längfristiger

Prozess.57

Durch die Integration der Prozesse oder Systeme werden SLA definiert, die den Service Anbieter

zur Einhaltung verpflichten. Der Druck die SLA einzuhalten kann ein Risiko darstellen, denn

eine Nichteinhaltung der SLA hat nicht nur finanzielle Nachteile, sondern damit kann auch der

Ruf des Service Anbieters einen Schaden erleiden.

Wie beim Outsourcer kann auch das Rückführen der Systeme nach Beendigung des

Outsourcing-Vertrags ein Risiko darstellen. Wurde eine langfristige Outsourcing-Beziehung

eingegangen, so wird die Abspaltung der Systeme und Personen für die Reintegration zum

Outsourcer durch die entstande Vernetzung in der Service Anbieter Umgebung erschwert bzw.

teilweise verunmöglicht.

2.7 Zusammenfassung

In diesem Kapitel wurde der Begriff des Outsourcing differenzierter betrachtet. Dabei wurde das

Outsourcing als Weiterentwicklung der Lean-Philosophie beschrieben. Nachdem eingehend die

Gründe für ein Outsourcing-Vorhaben vorgestellt wurden, wurden neben dem IT-Outsourcing,

welches im Zentrum dieser Arbeit steht, mit dem Business Application Outsourcing, BPO und

BTO drei weitere Outsourcing-Dimensionen vorgestellt.

Im weiteren Verlauf dieses Kapitels wurde der Fokus spezifisch auf das IT-Outsourcing gelegt

und dabei wurden die verschiedenen organisatorischen Möglichkeiten des IT-Outsourcing

aufgezeigt. Im nächsten Schritt wurden die rechtlichen Aspekte einer IT-Outsourcing-Beziehung

betrachtet. Dabei wurde auf die Komplexität des Outsourcing-Vertrages eingegangen und darauf

hingewiesen, dass keine Outsourcing-Musterverträge bestehen, jedoch die Verträge oftmals eine

57 Vgl. Anhang Interview Mühlenbrock / Hammer.


Mischform zwischen verschiedenen Vertragstypen enthalten. Als Kern des Outsourcing-

Vertrages wurden die SLA vorgestellt. Diese regeln die messbaren Leistungskriterien zwischen

den Outsourcing-Parteien, wie auch die Folgen der Nichteinhaltung. Da nicht alle

Vorkommnisse vor einer Outsourcing-Beziehung voraussehbar sind, wurde dargestellt, welche

mögliche Haftungsfolgen, neben den in den SLA spezifizierten, möglich sind.

Am Schluss des Kapitels wurde der Fokus auf die negativen Seiten des IT-Outsourcing gelegt

und dabei die Risiken aus Outsourcer – und Service Anbieter Sicht erläutert.

3. Internal Control mit Fokus auf die IT-Security 26

3 Internal Control mit Fokus auf die IT-Security

Zu Beginn dieses Kapitels wird eine Einführung in das abstrakte Konzept der Internal Control

gegeben. Neben den Verantwortlichkeiten für die Umsetzung der Internal Control im

Unternehmen wird das COSO Framework vorgestellt, das gewährleisten soll, dass eine

erfolgreiche Umsetzung der Internal Control im Unternehmen gesichert werden kann. Aufgrund

des IT-Einsatzes bestehen Chancen und Gefahren für die Internal Control. Diese werden in

Abschnitt 3.1.3 dargelegt. Durch die betriebswirtschaftliche Auslegung des COSO Framework

und des dabei nicht expliziten Bezugs auf die IT, wird das COBIT Framework als Framework

mit explizitem IT-Bezug näher vorgestellt. Mit ITIL wird neben COBIT ein weiteres Framework

beschrieben, welches die korrekte IT-Behandlung innerhalb des Unternehmens zur Aufgabe hat.

Im letzten Abschnitt wird der Fokus auf die IT-Security gelegt. Ausgehend von der Definition

der IT-Security werden die Bedrohungen und auch einige verschiedene Standards bzw.

Zertifikate aufgezeigt, die im IT-Security Bereich vorherrschen. Da Sicherheitstandards alleine

nicht genügen, sondern deren korrekte Umsetzung und periodischer Kontrolle ebenso von

Wichtigkeit sind, werden in Abschnitt 3.3.5 Kontrollverfahren vorgestellt. Diese verhelfen, dass

das entsprechende Sicherheitsniveau im Unternehmen aufrechterhalten werden kann.

3.1 Definition Internal Control

Das „Committee of Sponsoring Organizations of the Treadway Commission“ (COSO) definiert

Internal Control (IC) als “ein Prozess, beeinflusst durch den Verwaltungsrat, das Management

und andere Mitarbeitende, konzipiert, um eine zweckmässige Sicherheit in Bezug auf die

Erreichung von Zielen in den folgenden Kategorien bieten zu können:

Effektivität und Effizienz der Tätigkeiten

Verlässlichkeit der finanziellen Berichterstattung

Gesetzes- und Normenkonformität.“ 58

58 Vgl. Committee of Sponsoring Organizations of the Treadway Commission (1994), S. 3.


IC ist im Gegensatz zum Controlling und der Internen Revision keine Funktion im Unternehmen.

Vielmehr ist IC ein abstraktes Konzept. Dabei kann „Control“ als Prozess angesehen werden,

welcher darauf ausgerichtet ist, ein System oder andere Prozesse zu steuern und zu kontrollieren,

damit die Zielerreichung nicht durch Zwischenfälle behindert wird und die Zielvorgaben erreicht

werden können. Der Begriff Control darf dabei nicht nur als Kontrolle aufgefasst werden, bei

dem es darum geht Mängel aufzudecken und korrektive Massnahmen einzuleiten. Wichtiger ist,

dass neben der Kontrolle zusätzlich lenkende Massnahmen, welche ein gewünschtes Verhalten

fördern, sowie präventive Massnahmen, welche ein unerwünschtes Verhalten oder Ereignis

verhindern sollen, miteinbezogen werden.59

Das IC-Konzept umfasst sowohl eine prozessabhängige als auch eine prozessunabhängige

Control. Abbildung 5 illustriert den Verbund.

Abbildung 5: Die prozessabhängige und prozessunabhängige Internal Control60

Die Prozessabhängige Control, welche auch Interne Steuerung und Kontrolle (ISK) genannt

wird, beinhaltet dabei sowohl lenkende und präventive Massnahmen als auch die Steuerung und

Kontrolle durch die Mitarbeitenden, welche im Control-Prozess involviert sind. Die

Prozessunabhängige Control, als nicht am Prozess teilnehmende und damit unabhängige Stelle,

59 Vgl. Ruud / Jenal (2005), S. 456. 60 Ruud / Jenal (2005), S. 456.

Internal Control (IC)

Prozessabhängige Control

= Interne Steuerung und Kontrolle (ISK)

Prozessunabhängige Control

= Interne Prüfung


dient zur Überprüfung der ISK. Als wichtigster Vertreter dieser prozessunabhängigen IC ist die

Interne Revision61 zu nennen.

Zusammenfassend gesagt umfasst IC alles, was zu einem Unternehmen gehört und darauf

ausgerichtet ist, die Ereignisse, welche die Unternehmenszielerreichung beinträchtigen können,

zu steuern und zu kontrollieren. Darüber hinaus sind Mängel zu erkennen und korrektive

Massnahmen zu ergreifen. Oftmals wird die ISK als Synonym für IC verwendet. Durch die

vorher beschriebene Unterscheidung zwischen prozessabhängiger und prozessunabhäniger

Control kann jedoch aufgezeigt werden, dass ISK nicht als Synonym wirken kann. Die ISK

umfasst nur die prozessabhangige Control. Somit ist die IC durch den Einbezug beider

Bestandteile umfassender als die ISK.

Obwohl IC ein Konzept ist, das abstrakt ist und darum teilweise kompliziert wirkt, besitzt jedes

Unternehmen eine IC. Eine IC besteht schon ansatzweise, wenn z.B. Funktionentrennung oder

das Vieraugenprinzip angewendet wird. Eine angemessene IC besteht nicht ausschliesslich aus

Grundsätzen, Handbücher oder Dokumenten, vielmehr muss die IC durch ein gesundes

Bewusstsein für Steuerungs- und Kontrollfragen in der Unternehmenskultur integriert sein.62

3.1.1 Verantwortlichkeiten für die Internal Control

Die IC hat durch den „Sarbanes-Oxley Act“63 und durch den „Turnbull Report“64 stark an

Bedeutung dazu gewonnen. Der Sarbanes-Oxley Act nimmt durch die „Section 302: Corporate

Responsibility for Financial Reports” und „Section 404: Management Assessment of Internal

Control“ die Unternehmensleitung bzw. dem Verwaltungsrat in die Verantwortung, ein IC zu

betreiben (Section 302) und eine Stellungnahme zur Angemessenheit der internen

Kontrollstrukturen und –prozesse zu geben (Section 404).65 Wie der Sarbanes-Oxley Act,

schreibt auch der Turnbull Report die Verantwortung dem Verwaltungsrat zu:

„The board of directors is responsible for the company’s system of internal control. It should set

appropriate policies on internal control and seek regular assurance that will enable it to satisfy

61 Im Englischen Internal Audit genannt. 62 Vgl. Ruud / Jenal (2004), S. 1045. 63 Weitere Ausführungen betreffend Sarbanes-Oxley Act sind im Abschnitt 5.5.1 zu finden. 64 Der Turnbull Report entstand im Jahre 1999 auf Initiative des „Institute of Chartered Accountants“, der Wirtschaftsprüfervereinigung aus England und Wales. Es enthält Richtlinen über die praktische Anwendung der internen Kontrollsysteme und des Risk Management System. 65 Vgl. Ruud / Jenal (2004), S. 1045.


itself that the system is functioning effectively. The board must further ensure that the system of

internal control is effective in managing risks in the manner which it has approved.”66

Auch das Schweizerische Gesetz und der „Swiss Code of Best Practice“67 hat die Verantwortung

für die IC dem Verwaltungsrat, also dem obersten Gremium des Unternehmens, als

unübertragbare Aufgabe vorgeschrieben bzw. empfohlen.68 Im Verwaltungsrat ist es üblich ein

„Audit Committee“ zu bilden. Dieser Ausschuss trägt die Verantwortung und hat die

Oberaufsicht über eine angemessene Implementierung und Haltung der IC im Unternehmen. Die

operative Ausgestaltung der IC wird oftmals dem Management delegiert. Das Management ist

dem Verwaltungsrat respektive dem Audit Committee laufend rechenschaftspflichtig, damit der

Verwaltungsrat der Oberaufsicht nachkommen kann. Der Verwaltungsrat und das Management

sind somit dafür zuständig, dass das IC effektiv ausgestaltet ist, damit eine ordnungsmässige und

effiziente Geschäftsführung möglich ist.69

3.1.2 COSO Framework

Das COSO Framework wurde im Jahre 1992 durch COSO herausgegeben. Dieses Framework

integriert die verschiedenen Sichten, die bei der IC existieren, woraus ein allgemein gültiger Best

Practice70 - Ansatz resultiert, um eine IC in einem Unternehmen zu etablieren. Abbildung 6 zeigt

die verschiedenen Komponenten des Framework, die gemäss COSO Report und SAS 9471 in den

Managementprozess integriert werden sollen.72

66 The Institute of Chartered Accountants in England & Wales (1999), § 16. 67 Der Swiss Code of Best Practice wurde von der Economiesuisse, dem Wirtschafts-Dachverband der Schweiz, erlassen, mit dem Ziel Empfehlungen für die in der Schweiz kotierten Aktiengesellschaften betreffend einer geeigneten Corporate Governance zu geben. 68 Vgl. Art. 716a OR und Economiesuisse (2002), Abs. 19 und Abs. 24. 69 Vgl. Ruud / Pfister (2005), S. 29. 70 Best Practice lässt sich als “Vorbildslösung” übersetzen. Sie sind Hinweise auf besonders gute Lösungen, die beispielsweise aus bereits durchgeführten Projekten eingesetzt und den dort gemachten Erfahrungen gewonnen wurden. 71 SAS steht für “Statements on Auditing Standards”. Die SAS interpretieren die allgemein gültigen und akzeptierten Auditing Standards. SAS 94 hat den Titel: „The Effect of Information Technology on the Auditor’s Consideration of Internal Control in a Financial Statement Audit“. Vgl. dazu Abschnitt 3.1.3. 72 Vgl. Ricchiute (2003), S. 201.


Abbildung 6: COSO Framework73

Die fünf Komponenten sind:74

Kontrollumfeld

Das Kontrollumfeld ist das Fundament für alle anderen IC-Komponenten. Es schreibt die

Disziplin, Struktur, Integrität und ethische Werte des gesamten Unternehmens vor. Das

Kontrollumfeld repräsentiert das Verhalten, Bewusstsein und die Aktionen der Unternehmens-

leitung gegenüber der IC. Dadurch wird sichtbar, welchen Stellenwert die IC im Unternehmen

durch das Management geniesst. Die Wichtigkeit der IC im Unternehmen zeigt sich z.B. durch

ein aktives Audit Committee, eine kompetente Interne Revision Abteilung oder direkte Manage-

mentkontrolle über die delegierten Verantwortlichkeiten. 75

Risk Assessment

Jedes Unternehmen ist extern und intern entstehenden Risiken ausgesetzt. Ein externes Risiko

kann z.B. die Veränderung der Kundennachfrage oder regulatorische Veränderungen darstellen.

Beispiele für interne Risiken wären die Angestellten des Unternehmens oder ein System-

73 SOX-Online.com (2005), o.S. 74 Vgl. Internal Auditor (2005), S. 53. 75 Vgl. Ricchiute (2003), S. 202.


unterbruch zu betrachten. Das Risk Assessment ist der Prozess vom Identifizieren und

Analysieren der relevanten Risiken, die eine Zielerreichung gefährden könnten, mit dem Ziel ein

Vorgehen zu finden, wie die Risiken kontrolliert und minimiert werden können.

Steuerungs- und Kontrollaktivitäten76

Steuerungs- und Kontrollaktivitäten sind Richtlinien und Prozeduren, die vom Management

erlassen wurden, um eine angemessene Sicherheit zu gewährleisten, damit die Ziele erreicht

werden können. Kontrollaktivitäten erfolgen im gesamten Unternehmen, auf allen Ebenen und in

allen Funktionen. Die Kontrollaktivitäten umfassen unter anderem folgende Bereiche:77

Performance Reviews: Das Management ist verantwortlich, dass Unternehmens-

ziele verfolgt werden. Dazu bedarf es einer aktiven Teilnahme des Managements

in der periodischen Überwachung der Tätigkeiten. Ein Management, welches

öfters an einem Performance Review teilnimmt, hat mehr Möglichkeiten Fehler

zu entdecken, als ein Management ohne Teilnahme.

Segregation of Duties: Um eine effektive IC zu gewährleisten, müssen

funktionelle Verantwortlichkeiten personell voneinander getrennt werden. Als

Beispiel sei die Trennung von einer Authorisation und Durchführung einer

Transaktion genannt. Diese Aktivitäten müssen von mindestens zwei

verschiedenen Parteien unternommen werden.

Physische Kontrollen: Zugang zu wichtigen Dokumenten, Formularen oder

Programmdaten darf nur Mitarbeitern gewährt werden, die auch eine

entsprechende Authorisation besitzen.

Information & Kommunikation

Relevante Informationen, interne oder externe, müssen filtriert und den Verantwortlichen in

einer angebrachten Zeitspanne übermittelt werden, damit Entscheide rechtzeitig getroffen

werden können. Eine effektive Kommunikation verläuft durch das ganze Unternehmen: Vom

Management bis zu den Angestellten und wieder zurück. Die Kommunikation mit externen

76 Oftmals auch Kontrollprozeduren genannt. 77 Vgl. Robertson / Louwers (2002), S.150-155.


Partnern, wie Zulieferer, Kunden oder Behörden gehört ebenso zu einer effektiven

Kommunikationspolitik.78

Überwachung

Durch die Überwachungskomponente wird gewährleistet, dass die IC permanent verbessert wird

und Abweichungen aufgedeckt werden. Unregelmässigkeiten werden direkt an das Management

gemeldet, damit Massnahmen ergriffen werden können. Im Fall von Abweichungen werden

Vorkehrungen getroffen, um die Effizienz und Effektivität weiterhin zu gewährleisten.

Neben dem COSO-Framework existieren weitere IC-Modelle. Das COSO-ERM79 Modell stellt

eine Erweiterung des COSO Framework im Risikomanagement-Bereich dar. Dabei handelt es

sich um einen umfassenden Ansatz, womit Risiken sowohl identifiziert als auch analysiert

werden können.

Neben diesen zwei Modellen ist das kanadische „Guidance on Control Framework“, welches

vom „Criteria of Control Board“ („CoCo“) des „Canadian Institute of Chartered Accountants“

veröffentlicht wurde, zu nennen. CoCo hat jedoch eine geringere Verbreitung als COSO,

obschon die Zielsetzung praktisch identisch ist.80

3.1.3 Chancen und Gefahren für die Internal Control durch den IT-Einsatz

Der IT-Einsatz erbringt einiges an Nutzen, um eine effiziente und effektive IC zu erzielen. Die

Wichtigkeit wird dabei ersichtlich, dass mit dem SAS 94 ein separater Standard mit der

Thematik des Einflusses der IT auf die IC geschaffen wurde. Weiterführend sind hier Vorteile

der IT-Nutzung genannt, die gemäss SAS 92 Abs. 18 für die IC des Unternehmens von

Bedeutung sind: 81

Möglichkeit grosse Transaktionsvolumen oder Datenmengen zu verarbeiten

78 Vgl. Internal Auditor (2005), S. 53. 79 ERM = Enterprise Risk Management. 80 Weitere Informationen zum CoCo-Modell können unter: http://www.mcgill.ca/internalaudit/tools/coco/ abgerufen werden. 81 Vgl. Public Company Accounting Oversight Board (2002), Abs. 18.


Verfügbarkeits- und Genauigkeitserhöhung der Informationen sowie schnellere

Verfügbarkeit

Möglichkeit, die Informationen zusätzlich zu analysieren

Überwachungsmöglichkeiten der Leistungen, Regelungen und Prozeduren der einzelnen

Bereiche

Reduktion des Risikos, dass Kontrollen umgangen werden

Möglichkeit eine effektive Trennung der Verantwortlichkeiten durch die

Implementierung von Sicherheitskontrollen in Applikationen, Datenbanken und

Betriebsystemen zu vollziehen.

Etwas relativiert werden die Vorteile durch die Risiken respektive Gefahren eines IT-Einsatzes

für die IC. SAS 92 Abs. 19 streicht einige Risiken heraus: 82

Zu viel Vertrauen in die Systeme oder Programme, ohne Bedenken, dass diese ungenaue

Daten oder Daten ungenau verarbeiten

Unauthorisierter Zugriff auf die Daten, Systeme oder Programmen mit der Möglichkeit

Veränderungen vorzunehmen

Unpassende manuelle Veränderungen

Verlust aller Daten.

Ob der IT-Einsatz einen positiven oder negativen Einfluss auf die IC hat, lässt nur eine situativ

und nicht generell bezogene Aussage zu. Aufgrund der Menge an Informationen, die innert

kürzester Zeit verarbeitet und analysiert werden müssen, stellt die IT mit Sicherheit eine

erhebliche Unterstützung bei der Bewältigung dieser Aufgabe dar. Die erläuterten Risiken zeigen

jedoch, dass eine Vollautomatisierung mittels der IT nicht möglich ist. Vielmehr muss ein

Zusammenspiel zwischen der IT, als Unterstützung, und den Anwendern, als Kontrollinstanz

geschaffen werden.

82 Vgl. Public Company Accounting Oversight Board (2002), Abs. 19.


3.2 Relevante Framework und Standards für den IT-Bereich

Nachdem in Abschnitt 3.1.2 das COSO Framework als eigentliche Referenz vorgestellt wurde,

um eine IC in einem Unternehmen zu implementieren, werden in diesem Teil Frameworks bzw.

Standards vorgestellt, die einen speziellen Fokus auf den IT-Bereich haben. COSO hat die IT-

Komponente nicht expliziert modelliert. In diesem Zusammenhang werden nachfolgend mit

COBIT und ITIL die gängigsten Frameworks vorgestellt, die eine Leitlinie für die Revisoren,

wie auch für das Unternehmen bilden, damit die IT richtig eingesetzt wird.

3.2.1 COBIT

„Control Objectives for Information and Related Technology“ (COBIT) wurde in einer ersten

Version im Jahre 1996 durch die Information Systems Audit and Control Organization

(ISACA83) veröffentlicht.

Das COBIT Framework kombiniert 41 nationale und internationale Standards aus den Bereichen

Kontrolle, Qualitätssicherung, Sicherheit und Ordnungsmässigkeit. Daraus resultierend entstand

das in Abbildung 7 gezeigte Modell. COBIT richtet sich mit bestimmtem Zweck an folgende

Gruppen:84

Management: Unterstützung beim Risikoumgang in einer sich ändernden Umwelt.

Benutzer: Gewährleisten der Sicherheit und Kontrolle der unterstützten IT-Dienst-

leistungen, die von einem Service Anbieter angeboten werden.

Revisor: Unterstützung bei der Meinungsbildung über die IC des Unternehmens.

Im Gegensatz zum vorherig vorgestellten COSO Framework integriert das COBIT Framework

explizit die zwei Perspektiven: „Business“ und „IT“.

83 Bei der ISACA handelt es sich um eine globale Experten-Organisation, die sich aus IT-Fachpersonen (Führung, Management, Praktiker) aus über 100 Ländern zusammensetzt. Anfängliches Ziel der Organisation war die Auswirkung der IT auf die Revisionstätigkeit und der eingesetzten Methoden zu ermitteln. Seit 1994 wurde die Tätigkeit ausgeweitet, indem Management und Sicherheit von IT als weitere Felder aufgenommen wurden. ISACA stellt ihre Erkenntnisse unter http://www.isaca.org zur Verfügung. 84 IT Governance Institute (2000a), S. 6.


• Personal

• Applikationen

• Technologie

• Anlagen

• Daten

Information

Planung & Organisation (11 IT-Prozesse)

Akquisition & Implementation

(10 IT-Prozesse)Auslieferung & Unterstützung

(13 IT-Prozesse)

Überwachung (4 IT-Prozesse)

IT-Ressourcen

•Effektivität

•Effizienz

•Vertraulichkeit

•Integrität

•Verfügbarkeit

•Gesetzesm

ässigkeit

•Zuverlässigkeit

UNTERNEHMENSZIELE / -PROZESSE

COBIT

Abbildung 7: COBIT Framework85

Im Zentrum des Framework steht die Fragestellung, ob die Geschäftsziele und -prozesse optimal

durch die fünf verfügbaren IT-Ressourcen - Daten, Applikationen, Technologien, Anlagen und

Personal - unterstützt werden. Für die Beurteilung des Zusammenspiels zwischen den

Geschäftsprozessen und IT-Ressourcen ist die Qualität der aufbereiteten Informationen

ausschlaggebend. COBIT definiert zu Beurteilungszwecken der Informationen sieben

Informationskriterien: Effektivität, Effizienz, Vertraulichkeit, Integrität, Verfügbarkeit,

Gesetzesmässigkeit und Zuverlässigkeit der Informationen. Damit diese Informationskriterien

erfüllt werden können, müssen die eingesetzten IT-Ressourcen geplant, entwickelt,

implementiert, umgesetzt und überwacht werden. COBIT formuliert dafür 34 IT-Prozesse, die in

vier Domänen eingeteilt sind: Planung & Organisation, Akquisition & Implementation,

Auslieferung & Unterstützung und Überwachung. Somit wird durch die Domänen der ganze IT-

Lebenszyklus abgedeckt. Für jeden der 34 IT-Prozesse ist dokumentiert, wie gut es zur Erfüllung

der verschiedenen Informationskriterien beiträgt. Desweiteren sind die Kernaufgaben und die zu

erfüllenden Kontrollziele definiert. Insgesamt beschreibt COBIT für die 34 IT-Prozesse 318

Kontrollziele. Mit Hilfe dieser Kontrollziele ist es für den IT-Revisor möglich, sich eine

85 In Anlehnung an IT Governance Institute (2000a), S. 5.


Meinung über die IT-Landschaft zu bilden, wobei in der Praxis die Revisionsfirmen sich bei der

Prüfung, aufgrund des Umfangs, oftmals auf eine Untermenge fokussieren.

Die aktuellste Version86 des COBIT stellt dem Management zusätzlich einige Mittel zur

Verfügung, die eine Leistungsmessung für strategische Entscheide und Benchmark-Vergleiche

erlauben. Mittels Key Performance Indicators (KPI) wird die Leistung der vorgängig erwähnten

fünf IT-Ressourcen gemessen. Key Goals Indicators (KGI) messen den Erreichungsgrad der im

Voraus geplanten Prozessziele und durch die kritischen Erfolgsfaktoren (Critical Success

Factors) besteht die Möglichkeit, die Prozesse unter Kontrolle zu bringen.

3.2.2 ITIL

Die „IT Infrastructure Library“ (ITIL), die Ende der 80er Jahre des 20. Jahrhunderts, durch das

„Office of Government Commerce“ (OGC) entwickelt wurde, hat sich inzwischen als weltweit

akzeptierter Defacto-Standard für Gestaltung, Implementierung und Management von

wesentlichen IT-Prozessen etabliert. ITIL ist eine generische Verfahrensbibliothek, die

Erfahrungen aus der Praxis zusammenträgt und vermittelt. Das Ziel von ITIL ist, die IT-

Organisation prozess-, service- und kundenorientiert auszurichten, um nachhaltig zur Qualität

von IT-Services beizutragen und dadurch auch zum Gesamterfolg des Unternehmens. Somit hilft

ITIL einem Unternehmen seine bisherigen Prozesse zu optimieren und an die Bedürfnisse der

Kunden auszurichten.

Abbildung 8 zeigt einen Überblick über die verschiedenen IT-Service Management Themen, die

in ITIL behandelt werden. Zu jedem einzelnen Thema gibt es eine Buch-Publikation, die Ansätze

zeigt, was gemäss Best Practice getan werden muss, um die IT-Organisation prozess- und

serviceorientiert auszurichten. Wie die Implementierung stattfinden soll, wird in den Bändern

nicht beschrieben. Diese Aufgabe bleibt den jeweiligen Unternehmen überlassen.

86 Anmerkung: 3rd Edition.


Abbildung 8: ITIL Überblick87

Seit 2003 besteht für Unternehmen die Möglichkeit, sich durch die BS 15000 Zertifizierung die

ITIL-Konformität bestätigen zu lassen. Somit kann der Kunde sicher sein, dass das Unternehmen

ITIL anwendet und das Unternehmen kann durch die Zertifizierung sicher sein, dass ITIL richtig

umgesetzt wurde. Die Zertifizierung bietet somit eine interne und externe Sicherheit.88

ITIL ist kein Standard bzw. Framework, das explizit für IC- oder Revisionszwecken geschaffen

wurde. COBIT und ITIL besitzen aber Schnittpunkte, insbesondere im Sicherheitsbereich,

weswegen ITIL einem Revisor auch eine gewisse Möglichkeit bietet sich eine Meinung über das

Unternehmen zu bilden.89

3.3 Rolle der IT-Security in der Internal Control

Dieser Abschnitt hat zum Ziel, den Fokus verstärkt auf die IT-Security innerhalb der IC zu

setzen. Ausgehend von der IT-Security-Definition werden verschiedene Bedrohungen, die für

Unternehmen vorherrschen, aufgezeigt. Als wichtigstes Framework im IT-Bereich wurde das

COBIT Framework im Abschnitt 3.2.1 vorgestellt. Im Abschnitt 3.3.3 wird gezeigt, welche

Beachtung die IT-Security im COBIT besitzt. Neben dem COBIT Framework existieren viele

87 ITIL.org (2005), o.S. 88 Vgl. Zimmermann (2005), S. 39. 89 Vgl. IT Governance Institute (2004a), 16-22.


weitere Standards oder Zertifizierungen bezüglich der IT-Security. Die in der Praxis geläufigsten

werden in Abschnitt 3.3.4 eingehend behandelt. Im letzten Teil werden einige Kontrollverfahren

beschrieben, die es erlauben das Sicherheitsniveau im Unternehmen zu testen und

dementsprechend aufrecht zu erhalten.

3.3.1 Definition IT-Security

Der Ausdruck IT-Security fällt unter den Oberbegriff Informationssicherheit. Informations-

sicherheit ist ein ganzheitliches Konzept, das sich auf eine organisatorische, betriebliche und

technische Ebene bezieht. Abbildung 9 zeigt den Zusammenhang zwischen dem Oberbegriff

Informationssicherheit und IT-Security. Während sich Informationssicherheit als Sicherheit von

Informationen jeglicher Form, d.h. Dokumente in Papierform, Informationen in bildlicher und

akustischer Form sowie den Kombinationen daraus verstanden wird, bezieht sich die IT-Security

ausschliesslich auf die IT sowie auf die von diesen Systemen verarbeiteten Daten.90

Informations-sicherheit

Geschäftsprozesse

IT-Applikationen

IT-Security

Prozessschritte mit IT-Unterstützung

Prozessschritte ohne IT-Unterstützung

Abbildung 9: Verhältnis von Informationssicherheit und IT-Security

Die zentrale Frage der IT-Security lautet: Wie kann ein IT-System und seine Betriebsmittel

(insbesondere Daten) vor Angriffen (innen und aussen) geschützt werden?

90 Vgl. Czurda (2002), S. 49.


Die Ziele und Anforderungen, die an die IT-Security gestellt werden sind nachfolgend

aufgelistet: 91

Verfügbarkeit: Auf ein System und die darauf gespeicherten Daten oder Programme

kann zu einer bestimmten Zeit, an einem bestimmten Ort und zu

einem spezifischen Zweck zugegriffen werden.

Vertraulichkeit: Objekte dürfen nur von tatsächlich berechtigten Personen nach

definierten Zugriffsregeln und in klar definierten Zeiträumen

eingesehen werden.

Integrität: Daten oder Programme dürfen weder ganz noch teilweise ohne

Erlaubnis durch die autorisierten Personen verändert, gelöscht oder

erzeugt werden, sei es nun willentlich oder zufällig.

Bei der ganzen IT-Security Betrachtung ist gemäss der gegebenen Definition immer zu beachten,

dass die drei genannte Kernziele bzw. Anforderungen kumulativ gegeben sein müssen. Wird

eine Anforderung nicht erfüllt, so stellt dies ein Verstoss gegen die IT-Security dar.

Im Allgemeinen werden die zwei Begriff Informationssicherheit und IT-Security oftmals als

Synonyme verwendet. Die vorhin getätigte Differenzierung mit der IT-Security als Bestandteil

der Informationssicherheit bleibt bestehen. Die Informationssicherheit befasst sich mit der

Sicherheit aller möglichen Informationen und die IT-Security reduziert sich darauf, dass nur

Fragestellungen rund um die IT betrachtet werden. Die IT-Fokussierung bedeutet aber nicht,

dass nur technischen Problemstellungen nachgegangen wird, sondern organisatorische und

betriebliche Fragestellungen rund um die IT stehen auch im Fokus der IT-Security.92

3.3.2 Konkrete Bedrohungen für die Unternehmen

Durch die immer weiterschreitende Vernetzung der Unternehmen und damit resultierende

Internetverbindungen für die Geschäftsgänge, kommen auf die Unternehmen neue Bedrohungen

zu. Die Bedrohungen lassen sich in absichtlich (passive- und aktive Angriffe) sowie

91 Vgl. Czurda (2002), S. 55 – 58 und Anhang Interview Pfister. 92 Vgl. Anhang Interview Pfister.


unabsichtliche unterteilen. Abbildung 10 zeigt eine Übersicht über die verschiedenen

Bedrohungsarten und illustriert dazu einige Beispiele.

Abbildung 10: Bedrohungsarten für Unternehmen93

Wie aus Abbildung 10 ersichtlich wird, lassen sich Bedrohungen für die Unternehmen in

verschiedene Gruppen einteilen. Es sind nicht nur die Menschen, die dem Unternehmen Schaden

zufügen können. Weitere Bedrohungen sind exogen zu finden, wie z.B. Naturkatastrophen oder

Umwelteinflüsse. Bedrohungen anderer Art, die daneben auftreten, sind die auftretende

Komplexität der Systeme und deren fortschreitende Geschwindigkeit. Waren früher IT-Systeme

normale Input-Output Maschinen, haben sie heute einen Status erlangt, in dem sie hochkomplexe

Berechnungen innert kürzester Zeit durchführen können. Dafür müssen die Maschinen spezielle

Architekturen aufweisen, weswegen Revisoren oder auch Mitarbeiter der Unternehmen

spezielles Know-how mitbringen müssen, um diese Systeme zu verstehen. Ist dieses Wissen

nicht vorhanden, so können die Systeme mehr Schaden als Mehrwert bringen.

93 BITKOM (2003), S. 13.


3.3.3 Sicherheitsaspekte im COBIT Framework

Im COBIT-Framework, das als wichtigste Referenz für eine ordnungsmässige Führung der IT

gilt, stellt die Sicherheit ein zentrales Element dar. Zu erkennen ist dies ahand der in Abschnitt

3.3.1 beschriebenen Sicherheitsanforderungen: Vertraulichkeit, Integrität und Verfügbarkeit.

Diese Anforderungen finden im COBIT-Framework in den Informationskriterien ihren

Niederschlag. Einen weiteren Beweis dafür, dass die Sicherheit im COBIT einen sehr grosse

Rolle spielt, wird in Abbildung 11 illustriert.

Abbildung 11: IT-Prozesse im COBIT Framework mit Bezug auf Sicherheitsfragen94

Abbildung 11 zeigt auf, dass nahezu alle IT-Prozesse in irgendeiner Form sich mit

Sicherheitsfragen auseinandersetzen.

Zusätzlich stellt das COBIT Framework in der Domäne „Delivery & Support“ mit dem IT-

Prozess „DS5: Ensure Systems Security“ explizit einen Leitfaden bzw. Kontrollziele zur

Verfügung, die einem Unternehmen verhelfen sollen die Systeme gemäss der IT-Security-

Definition aufrecht zu erhalten. DS5 definiert insgesamt 21 Unterprozesse, die verhelfen sollen

94 IT Governance Institute (2004b), S. 11.


das DS5-Oberziel „to safeguard information against unauthorised use, disclosure or

modification, damage or loss“95 zu erreichen.

3.3.4 Weitere Sicherheitsrichtlinien und Standards für eine korrekte IT-Security

Neben ITIL und insbesondere COBIT existieren weitere Richtlinien und Standards, die den

Fokus unter anderem oder ausschliesslich auf eine korrekte IT-Security im Unternehmen haben.

Diese schon vorgestellten sowie die nachfolgenden Standards erlauben dem Unternehmen, ein

angemessenes Sicherheitsniveau zu erreichen. Welcher Standard der richtige für ein

Unternehmen ist, hängt von einigen Faktoren ab: 96

Art des Unternehmens

IT-Relevanz im Unternehmen

Relevanter Unternehmensbereich für die Standardisierung

Relevante Charakteristika des Standards.

Nachfolgend sind Sicherheitsstandards aufgelistet, die häufig eingesetzt werden. Eine

ausführliche Zusammenstellung verschiedener Sicherheitsstandards ist im Anhang zu finden.97

ISO 17799 und BS 7799-298

Der ISO 17799 Standard entspricht dem ersten Teil des BS 779999, der 1995 vom British

Standard Institution, einer unabhängigen Einrichtung für die Erstellung von britischen Standards,

veröffentlicht wurde. Aufgrund des internationalen Interesses wurde der erste Teil des BS 7799

im Jahre 2000 eine international verbindliche ISO-Standardisierung. Der ISO 17799 Standard

beschreibt einen Leitfaden für den Aufbau und Führen eines Informationssicherheits-

Managementsystems (ISMS). Für diesen Zweck enthält ISO 17799 einen Katalog mit 110

95 IT Governance Institute (2000b), S. 100. 96 Vgl. BITKOM (2005), S. 10. 97 Vgl. Anhang. 98 Der ISO 17799 Standard wurde überarbeitet und wird in Kürze offiziel veröffentlicht. Im Vergleich zu den bisherhigen Strukturen des ISO 17799 Standard ändert teilweise die Namensgebung der verschiedenen Kapitel und zusätzlich wurde ein neues Kapitel mit dem Namen: „Information Security incident handling“ geschaffen. Vgl. Plate (2005), S. 51-52. 99 Der erste Teil des BS 7799 wird auch als „Code of Practice (CoP) of Information Security Management“ bezeichnet.


allgemein anerkannten Sicherheitsanforderungen, die grundsätzlich und für jedes Unternehmen

gültig sind – sogenannte „Baseline Controls“. Der Massnahmenkatalog wird in folgende zehn

Kategorien bzw. Managementgebiete unterteilt:

Managementgebiete Massnahmen

1. Informations-Sicherheitspolitik: Schriftlich festgehaltenen Direktiven des

Managements

2. Sicherheitsorganisation: Sicherheitsausschuss, Verantwortlichkeiten,

Verträge mit Externen, Koordination

3. Klassifizierung und Steuerung der

Vermögenswerte:

Klassifizierungsrichtlinien

4. Personelle Sicherheit: Stellenbeschreibung, Rekrutierung,

Vertraulichkeitsvereinbarungen, Schulung

5. Physische und umgebungsbezogene

Sicherheit:

Zutrittsregelungen, Lieferanten, „Clean

Desk“-Politik, Sicherheit der Räumlichkeiten

6. Management der Kommunikation des

Betriebs:

Dokumentation von Abläufen,

Funktionentrennung, Datenaustausch

7. Zugangssteuerung (Zutritt, Zugriff,

Zulassung):

Berechtigungsadministration, Sicherheit von

Netzwerk- und Rechnerzugriff

8. Systementwicklung und – wartung: Festlegung von Sicherheitsanforderungen,

Entwicklungsstandards

9. Management des kontinuierlichen

Geschäftsbetriebs:

Notfall-Organisation, Notfallkonzept

10. Erfüllung der Verpflichtungen (rechtliche

und organisatorische Anforderungen):

Erfüllung der gesetzlichen und vertraglichen

Verpflichtungen

Abbildung 12: Managementgebiete und Massnahmen im ISO 17799100

100 Vgl. Schweizerische Normen-Vereinigung (2001) in Anlehnung an das Inhaltsverzeichnis, welches die Struktur von ISO 17799 wiedergibt.


Der zweite Teil des Standards, BS 7799-2, beschreibt die zugehörigen Anforderungen an ein

ISMS, die Gegenstand einer Zertifizierung sein können. Während ISO 17799 die

Managementgebiete, Massnahmenziele und Massnahmen zum Management von

Informationssicherheit benennt, beschäftigt sich BS 7799-2 mit dem zugrundeliegenden ISMS

und liefert ein Modell zum Aufsetzen und Führen eines effizienten ISMS. BS 7799-2 beschreibt

hierzu konkret die Prozesse zur Implementierung, Überwachung, Prüfung, Instandhaltung und

Verbesserung eines ISMS.

IT-Grundschutzhandbuch101

Das IT-Grundschutzhandbuch (IT-GSHB) des deutschen Bundesamtes für Sicherheit in der

Informationstechnik (BSI) wurde erstmals 1995 veröffentlicht und seitdem laufend

weiterentwickelt. Das IT-GSHB basiert auf dem 1992 durch das BSI publizierte IT-

Sicherheitshandbuch. Darin wurde ein Verfahren beschrieben, mit dem der aktuelle

Sicherheitsstatus eines IT-Einsatzes festgestellt und die IT-Security gewährleistet werden kann.

Die vier Stufen - Ermittlung der Schutzbedürftigkeit, Bedrohungsanalyse, Risikoanalyse und

Erstellung des IT-Sicherheitskonzeptes - wurden in insgesamt zwölf Schritte gegliedert.

Aufgrund der Anwendungskomplexität des Verfahrens, insbesondere für die kleineren und

mittleren Unternehmen, wurde durch das IT-GSHB ein geeignetere Vorgehensweise

beschrieben.

Der Inhalt des IT-GSHB stellt eine Sammlung von Handlungsanweisungen und Ratschlägen, wie

IT-Systeme abgesichert werden können. Das Ziel ist, die Erstellung eines IT-

Sicherheitskonzeptes zu vereinfachen und ein Sicherheitsniveau zu erreichen, das für den

mittleren Schutzbedarf angemessen und ausreichend ist und als Basis für hochschutzbedürftige

IT-Anwendungen dienen kann. Darüber hinaus bietet das IT-GSHB im begrenzten Umfang

Risikoanalysen an. Dabei bietet es vor allem in technischen, organisatorischen, personellen

sowie infrastrukturellen Fragen eine Hilfestellung.

Das BSI ermöglicht den Unternehmen ihre IT-Grundschutz-Tauglichkeit mittels einer

Zertifizierung bestätigen zu lassen.

101 Vgl. Bundesamt für Sicherheit in der Informationstechnik (2004), o.S.


Common Criteria102

Wie Abbildung 13 aufzeigt, sind die Common Criteria (CC) aufgrund der Standardisierungs-

wünsche aus den europäischen „Information Technology Security Evaluation Criteria (ITSEC)“,

den amerikanischen „Federal Criteria (FC)“ und den kanadischen „Canadian Trusted Computer

Product Evaluation Criteria (CTCPEC)“ entstanden. Mittlerweile wurden CC aufgrund der

häufigen Anwendung in der Praxis international als ISO 15408 standardisiert.

Abbildung 13: Entwicklung zum Common Criteria

Die CC stellt gemeinsame Kriterien für die Prüfung und Bewertung der Sicherheitsfunktionen

von IT-Produkten und IT-Systemen zusammen. Es stellt somit eine weltweit akzeptierte

Möglichkeit dar, die Sicherheit von Produkten und Systemen der IT nach definierten

Evaluationskriterien objektiv und abgestuft bewerten und zertifizieren zu lassen. Das

Unternehmen kann durch CC einschätzen, ob das IT-Produkt oder IT-System eine ausreichende

Sicherheit für die beabsichtigte Anwendung besitzt und ob die Sicherheitsrisiken bei dessen

Gebrauch toleriert werden können.

102 Eine eingehende Dokumentation über Common Criteria kann unter: http://www.bsi.de/cc/ abgerufen werden.


3.3.5 Kontrollverfahren

Durch die Wahl bzw. Anlehnung an ein oder mehrere Sicherheitsstandard wird gewährleistet,

dass von einer angemessenen Sicherheit der IT-Systeme ausgegangen werden kann. Aufgrund

der Zertifizierungsmöglichkeiten der einzelnen Standards und die jährliche Bestätigung wird

sichergestellt, dass der Sicherheitsgedanke nicht nur eine einmalige Aktion war, sondern

Leistungen zur Einhaltung des Sicherheitsstands laufend gefragt sind. Aufgrund der

Schnelllebigkeit der IT und die oft ändernden organisatorischen Begebenheiten werden

Kontrollverfahren benötigt, die in einem sich ständig wandelnden Umfeld prüfen, ob die

Sicherheitsmassnahmen noch angemessen sind. Insbesondere im täglichen Betrieb werden

Kontrollverfahren benötigt. Einige Beispiele für Kontrollmassnahmen im täglichen Betrieb sind:

103

Überprüfung der Passwortänderungen bzw. Passwortregelungen

Rechteüberprüfung der Mitarbeiter, d.h. besitzt jeder Mitarbeiter nur die Rechte, die zur

Erfüllung der Aufgaben benötigt werden

Überprüfung, ob nur benötigte Anwendungen auf dem jeweiligen System installiert sind

Überprüfung, ob die Sicherheits-Updates von allen Mitarbeitern auch tatsächlich

installiert wurden.

Um die Effektivität der Sicherheitsmassnahmen zu testen, können z.B. Penetrationstests

durchgeführt werden. Ein Penetrationstest ermittelt die potentiellen Ziele von Hacker104-

Angriffen und analysiert allfällige Schwachstellen hinsichtlich ihrer Gefährdung, die für das

Unternehmen anfallen könnten. Bei der Durchführung eines Penetrationstests simulieren die

Sicherheitsexperten der Unternehmen einen vermeintlichen Angriff eines Hackers. Es werden

Methoden angewandt, die auch von einem Hacker angewendet werden würden, um

unautorisierten Zugriff auf das Unternehmenssystem zu erhalten. Durch diesen Angriff wird

103 Vgl. BITKOM (2003), S. 52-53. 104 Als Hacker wird eine Person bezeichnet, die eingehendes Computerwissen insbesondere in der Programmierung und Netzwerktechnik besitzt. Oftmals wird die Bezeichnung Hacker nur für Personen verwendet, die ihre Computerkenntnisse illegal einsetzen, z.B. durch Angriffe auf Fremdnetzwerke und –Rechner, um Schaden anzurichten. In dieser Arbeit wird die Bezeichnung Hacker für eine Person verwendet, die durch einen Angriff Schaden im Fremdnetzwerk bzw. –rechner bewirken wil.


ersichtlich, ob die verschiedenen Kontrollmechanismen, seien es Administratoren, Filter105 oder

andere Sicherheitsmassnahmen, ausreichend sind.

Durch Penetrationstests wird nur die technische Umgebung getestet und damit nur eine

Momentaufnahme des IT-System dargestellt. Mit Hilfe von Sicherheitsaudits kann das komplette

Umfeld regelmässig nach Risiken überprüft werden. Es werden nicht nur aktuelle technische

Einstellungen überprüft, sondern auch die Dokumentationen, Methoden, wie auch die

Mitarbeiterhandlungen genauer inspiziert. Ergebnisse dieser eingehenden Überprüfung des

gesamten Umfelds werden mittels Massnahmenempfehlungen hinterlegt, die dann umgesetzt

werden sollten. Das Ziel dabei ist, dass die angefallenen Fehler in Zukunft vermieden werden.

Sicherheitsaudits können von externen IT-Revisoren oder von internen Revisoren vorgenommen

werden.

Die Expertenbefragung zeigt, dass insbesondere auf die täglichen Kontrollmassnahmen viel Wert

gelegt wird. Penetrationstests sind ein gutes Mittel, jedoch auch sehr aufwendig und schwierig zu

bewerkstelligen, da parallel zum Penetrationstest das normale Geschäft weiterlaufen muss. Der

Penetrationstest stellt in erster Linie eine Möglichkeit für den Sicherheitsbeauftragten einer

Firma dar, die Sicherheit z.B. in einem Netzwerk zu testen. Die Revision, d.h. die interne und

externe, prüft eher auf konzeptionelle Ebene. Dabei wird das Konzept der Sicherheits-

überprüfung, die Testanzahl und –resultate hinterfragt. Damit stellt der Penetrationstest eher kein

Mittel für die Revison dar, sondern dient als Leistungsüberprüfer für die internen Sicherheits-

beauftragten.106

3.4 Zusammenfassung Mit dem IC wurde ein abstraktes Konzept erklärt, das einem Unternehmen verhelfen soll, die

definierten Unternehmensziele zu erreichen, indem Ereignisse, die dabei die Zielerreichung

beeinträchtigen können, gesteuert und kontrolliert werden. Mit dem COSO Framework wurde

das gängiste Framework für die IC-Implementierung im Unternehmen vorgestellt. Aufgrund der

IT-Fokussierung dieser Arbeit und der nicht expliziten Modellierung der IT durch das COSO

Framework, wurden mit COBIT und ITIL zwei Framework bzw. Standards vorgestellt, die die

IT im Fokus ihres Modells sehen.

105 Im englischen Firewalls genannt. Diese Filter sind Software oder / und Hardwarelösungen, die ein Computernetzwerk oder ein einzelner Computer vor unerwünschten Zugriffen aus dem Internet schützen sollen. 106 Vgl. Anhang Interview Illi.


Mit der IT-Security wurde anschliessend eine Defintion gegeben, die insbesondere zum Ziel

hatte, die IT-Security vom Begriff der Informationssicherheit zu unterscheiden. Mittels dem

COBIT Framework wurde aufgezeigt welche Rolle die IT-Security für die IC besitzt. Die

Wichtigkeit der IT-Security zeigte sich unter anderem damit, dass COBIT für die IT-Security

verschiedene IT-Prozesse definiert, die sich ausschliesslich oder teilweise mit der Thematik der

IT-Security befassen. Da sich COBIT und auch die anderen vorgestellten Framework nicht

ausschliesslich nur mit der IT-Security beschäftigt, wurden die in der Praxis gängigsten Standard

und Zertifikate erläutert, die den Fokus rein auf der IT-Security-Thematik haben.

Dieses Kapitel trägt als theoretisches Grundlagenkapitel vieles für das folgende Kapitel bei, in

dem der Einfluss des Outsourcing auf den Outsourcer und den Service Anbieter näher erläutert

wird. Dabei werden insbesondere die IT-Security und die gemeinsame Sicherstellung derer

während eines Outsourcing ins Zentrum gerückt. Darüber hinaus hat dieses Kapitel wertvolle

Konzepte, Standards, Frameworks und Zertifikate vorgestellt, die im sechsten Kapitel bei der

Vorstellung des Prüfprozess eine gute Hilfestellung bieten.

4. Outsourcing und der Einfluss auf den Outsourcer und Service Anbieter 49

4 Outsourcing und der Einfluss auf den Outsourcer und Service Anbieter

In den vorhergehenden Kapiteln wurde eine Einführung in das Outsourcing und in die IC-

Thematik mit Fokus auf die IT-Security gegeben. Dieses Kapitel hat nun zum Ziel, die Brücke

zwischen den zwei vorausgehenden Kapiteln zu schlagen.

Beginnen werden die Ausführungen bei der Aufgabenänderung für die Interne und Externe

Revision im Outsourcing-Fall. Um den Fokus wiederum auf die IT-Security im Outsourcing zu

legen, wird in Abschnitt 4.4 das IT-Sicherheitskonzept als zentrales Koordinations- und

Verantwortlichkeitselement zwischen den verschiedenen Parteien eingehend beschrieben.

Aufgezeigt werden einerseits die verschiedenen integrierten Parteien bei der Ausarbeitung des

IT-Sicherheitskonzeptes und andererseits die relevanten Themen eines Sicherheitskonzepts.

Zum Schluss wird die Überprüfbarkeit der IT-Security im Outsourcing betrachtet. Damit soll

analysiert werden, ob sich eine IT-Security Prüfung im Outsourcing-Fall gegenüber einer

normalen IT-Security-Prüfung unterscheidet und zusätzlich werden die in der Praxis gängigen

Prüfungsarten beschrieben.

4.1 Überblick der Zusammenarbeit im Outsourcing

Durch die Outsourcing-Situation ergeben sich Aufgabenänderungen für die beteiligten Parteien.

Welche Parteien in dieser Situation involviert sind, ist in Abbildung 14 illustriert. Die Abbildung

zeigt auf, dass insbesondere der Outsourcing-Vertrag, welcher in Abschnitt 2.5.1 erläutert wurde,

und der Prüfungsstandard 402 (PS 402) existieren, die das Outsourcing-Verhältnis formell

regeln. Darüber hinaus gibt es Branchenlösungen, wie das Rundschreiben 99/2 der

Eidgenössischen Bankenkommission107 (EBK RS 99/2), das regelt, wie das Outsourcing-

Geschäft für die Finanzbranche auszusehen hat.

107 Die Eidgenössische Bankenkommission (EBK) ist eine unabhängige Verwaltungsbehörde des Bundes, die einerseits die Aufsicht der Banken und Effektenhändler zum Auftrag hat und andererseits auch die Prüfgesellschaften der Banken beaufsichtigt. Weitere Informationen sind unter: http//www.ebk.ch abrufbar.


Outsourcer Service Anbieter

Outsourcing - Vertrag

Interne Revision

Externe Prüfer des Outsourcer

Externe Prüfer des

Service Anbieters

Interne Revision

PS 402

PS 402 Zif. 11 ff.

Abbildung 14: Überblick über die Zusammenarbeit der verschienden Parteien im Outsourcing

Die Abbildung 14 wird nachfolgend aus der Sicht des Outsourcer betrachtet. Die Perspektive des

Service Anbieters wird nur gelegentlich miterläutert. Aufgrund der sich ändernden Situation für

die Parteien des Outsourcer durch ein Outsourcing, steht diese Sicht im Fokus der weiteren

Ausführungen.

Abschnitt 4.2 beschäftigt sich nachfolgend mit der Aufgabenänderung der Internen Revision. Die

Aufgabenänderung für die Externen Revision bzw. externe Prüfgesellschaft ist Thema des

Abschnittes 4.3. Bei beiden Ausführungen wird - so weit dies möglich ist - zwischen Aufgaben

vor und während dem Outsourcing differenziert. Die folgenden Beschreibungen basieren auf den

verschiedenen Standards und den Erkenntnissen aus den Experteninterviews.

4.2 Änderung der Aufgaben für die Internen Revision

Aufgrund des Outsourcing kommen verschiedene Anforderungen auf die IC und dabei

insbesondere auf die prozessunabhängige Stelle, die Internen Revision, zu. Im Gegensatz zu der

Externen Revision, die mit dem PS 402108 das Outsourcing-Verhältnis geregelt findet, hat das

108 Vgl. Abschnitt 4.3.


Institute of Internal Auditors (IIA)109 keine entsprechende Regelung festgehalten. Mit dem

Ratschlag 2050-2110 hat das IIA zwar einen Vorschlag ausgearbeitet, um die Rolle der Internen

Revision beim Einkauf von externen Prüfungs- und Beratungsleistungen zu beschreiben. Aus

den darin gegebenen Vorschlägen lassen sich auch einzelne Punkte für die Rolle im

Outsourcing-Verhältnis anwenden. Jedoch eine Regelung, auf die sich die Interne Revision im

Outsourcing stützen kann, wurde bis jetzt nicht ausgearbeitet.

Die Finanzbranchen hat die Aufgabenstellung der Internen Revision konkretisiert. Mit dem EBK

RS 99/2 wurde speziell für Banken eine verbindliche Richtlinie geschaffen, die die

Verantwortlichkeiten im Outsourcing-Verhältnis definiert und somit die Rolle der Internen

Revision beschreibt. Gemäss den Expertenmeinungen bedeutete die Einführung des EBK RS

99/2 keine Neuerung ihrer Arbeit. Organisatorische wie auch aufgabenbezogene Änderungen

haben für die einzelnen Banken nicht stattgefunden. Vielmehr war die Aufgabe des

Rundschreibens, das Bewusstsein der Thematik zu wecken und die Verantwortlichkeiten

schriftlich festzuhalten.111

Nachfolgend werden spezielle Regelungen des EBK RS 99/2 und Meinungen der Experten

bezüglich der Aufgaben der Internen Revision vor und im Outsourcing-Verhältnis dargelegt.

4.2.1 Aufgaben vor dem Outsourcing-Verhältnis

Wie in der Einleitung dieses Kapitels erwähnt, besteht keine Revisionsnorm, die regelt,

inwiefern die Interne Revision auf Outsourcing-Entscheide Einfluss nehmen kann bzw. muss.

Aufgrund der Unabhängigkeit der Internen Revision innerhalb des eigenen Unternehmens und

der Übersicht über alle Bereiche, besitzt die Internen Revision Wissen, was ein früher Einbezug

in die Outsourcing-Entscheidung durch die Geschäftsleitung rechtfertigt.112 Durch ihre Stellung

sind folgende Aufgaben für die Interne Revision vor dem Outsourcing-Verhältnis denkbar:113

Darauf achten, dass die Prozesse, deren Auslagerung vorgesehen sind, für das eigene

Unternehmen nicht von strategischer Bedeutung sind.

109 Das Institute of Internal Auditors ist ein internationaler Zusammenschluss von Mitgliedern des Berufstandes der Internen Revision. Die Aufgabe besteht u.a. darin, Standards, Zertifzierungen, Schulungen und Forschung im Gebite der Internen Revision zu betreiben. Nährere Informationen: http://www.theiia.org. 110 Vgl. The Institute of Internal Auditors (2002), o. S. 111 Vgl. Anhang Interview Allenspach und Illi. 112 Vgl. Anhang Interview Huissoud. 113 Vgl. Huissoud (2002), S. 13 -14.


Wissen für das eigene Unternehmen vermitteln, welches für die Auswahl und

anschliessend für die Kontrolle des Service Anbieters notwendig ist.

Erstellen eines vollständigen Pflichtenheft, bevor die Suche nach einem geeigneten

Service Anbieter eröffnet wird.

Dafür sorgen, dass das Unternehmen im Auswahlverfahren des Service Anbieters von

optimalen Verhandlungsbedingungen profitieren kann.

Insbesondere in wichtigen Fällen vor Abschluss des Outsourcing-Vertrags eine Prüfung

durchführen.

Begutachten des Vertragsentwurfs und anschliessende Stellungnahme vor der

eigentlichen Unterzeichnung.

Aufgrund der Expertenaussagen lassen sich die aufgeführten Punkte etwas nüchterner

betrachten. In der Praxis wird das Einspracherecht der Internen Revision sehr verschieden

gehandhabt. Einen aktiven Einbezug in den Auswahl- und Entscheidungsprozess ist bei allen

befragten Personen (noch) nicht der Fall. Vielmehr muss sich die Interne Revision von sich aus

anbieten. Der Entscheid, ein Outsourcing zu begehen sowie die Auswahl eines Service

Anbieters, ist Sache des Managements. Die Interne Revision kann sich beratend einbringen und

ihre revisionstechnischen Anforderungen vertreten. Zu diesen Anforderungen zählt das

Revisionsrecht der Internen Revision. Das Revisionsrecht besagt, dass die Interne und Externe

Revision des Outsourcer die Möglichkeit haben muss, Prüfungen direkt beim Service Anbieter

durchführen. Diese Möglichkeit sehen alle befragten Experten als Grundvoraussetzung, um

einem Outsourcing-Geschäft zustimmen zu können. Diese Vorraussetzung ist insbesondere für

Unternehmen von Bedeutung, die dem EBK RS 99/2 unterstehen. Das EBK RS 99/2 besagt

unter anderem, dass das auslagernde Unternehmen weiterhin die Verantwortung für die

ausgelagerten Geschäftsbereiche trägt.114 Noch detaillierter schreibt das Rundschreiben vor, dass

der ausgelagerte Geschäftsbereich in die IC des eigenen Unternehmens zu integrieren und eine

interne Stelle zu definieren ist, die sich für die Überwachung und Kontrolle des Service

Anbieters verantwortlich zeichnet.115 Aufgrund der Verantwortlichkeitsregelung durch das EBK

RS 99/2 wird klar, weswegen das Revisionsrecht ein wichtiger Bestandteil im Outsourcing-

Vertrag ist.

114 Vgl. Eidgenössische Bankenkommission (1999), Grundsatz 3 Ziffer 26 und Ziffer 27. 115 Vgl. Eidgenössische Bankenkommission (1999), Grundsatz 2 Ziffer 24.


4.2.2 Aufgaben im Outsourcing-Verhältnis

Hat man sich dazu entschlossen, ein Outsourcing mit einem Service Anbieter zu betreiben, so

muss wie im vorangehenden Abschnitt erwähnt, durch den Outsourcer gewährleistet sein, dass

die abgegebenen Bereiche weiterhin unter seiner Kontrolle stehen. Eine diesbezügliche

Möglichkeit besteht darin, das Revisionsrecht beim Service Anbieter vertraglich durchsetzen.

Dieses Recht wird von den Experten befürwortet.116 Wie oft eine direkte Prüfung durchgeführt

werden darf, ist Bestandteil der Vertragsverhandlung. Gemäss den Expertenaussagen ist jedoch

weniger die Prüfungsdurchführung das Problem, sondern vielmehr die Akzeptanz der Internen

Revision beim Service Anbieter. Wird eine Feststellung mit Verbesserungsaufforderung durch

die Internen Revision verfasst, so kann diese oftmals nicht direkt dem Service Anbieter

zugestellt werden, sondern muss den Umweg über die vom Outsourcing betroffene Abteilung

durchlaufen. Diese Abteilung muss dann den Wunsch äussern, dass die Feststellungen behoben

werden.117

Eine Möglichkeit um diesen Umstand zu umgehen, besteht darin, wenn die Interne Revision oder

die externe Prüfgesellschaft des Service Anbieters die Prüfung selber vornimmt. Damit

gewährleistet ist, dass die gewünschten Themen des Outsourcer ebenfalls im Prüffokus liegen,

müssen zu Beginn des Geschäftsjahres die Prüfbereiche durch die Interne Revision des

Outsourcer explizit kommuniziert werden, damit diese in die Jahresplanung der Internen und

Externen Revision des Service Anbieters einfliessen können.118

Gemäss den Expertenaussagen liegt die SLA-Überprüfung nicht zwingend im Prüffokus der

Internen Revision des Outsourcer. Dafür ist die IT-Controlling-Abteilung des Outsourcer

verantwortlich. Diese Abteilung überprüft jedoch mehrheitlich die finanzielle Richtigkeit des

Outsourcing-Geschäfts.119 Die Interne Revision nimmt dabei eher Ordnungsmässigkeits-

prüfungen vor.120 Ordnungsmässigkeit bedeutet in diesem Zusammenhang, dass Prüfungen

durchgeführt werden, die untersuchen, ob die Prozesse und Kontrollen des Service Anbieters

zeitgerecht, systematisch angelegt, zeitgemäss organisiert und nachprüfbar sind.

116 Vgl. Anhang Interview Allenspach und Illi. 117 Vgl. Anhang Interview Illi. 118 Vgl. Anhang Interview Allenspach. 119 Vgl. Anhang Interview Allenspach. 120 Vgl. Anhang Interview Huissoud.


4.3 Änderung der Aufgaben für die externen Prüfgesellschaften

Bei der Externen Revision besteht im Gegensatz zu der Internen Revision eine internationale

Revisionsnorm, die International Standard on Auditing 402 (ISA 402), die durch das

International Federation of Accountants121 (IFAC) erlassen wurde, die die Pflichten der Externen

Revision im Outsourcing-Verhältnis regelt. Diese Revisionsnorm wurde im Jahre 2001 in den

Grundsatz zur Abschlussprüfung (GZA 18) „Outsourcing-Verhältnis“ der schweizerischen

Treuhand-Kammer übernommen. Mittlerweile wurde der GZA 18 in die Schweizerischen

Prüfungsstandards (PS) als PS 402 vollständig integriert. PS 402 mit dem Titel: „Unternehmen,

die Dienstleistungsorganisationen in Anspruch nehmen – Auswirkungen auf die

Abschlussprüfung“ verweist in den Ausführungen darauf, dass der Prüfer die Auswirkungen der

vom Service Anbieter erbrachten Dienstleistungen auf die Buchhaltungs- und die ISK-Prozesse

des Unternehmens bewerten muss, damit ein effizienter Prüfansatz gewählt werden kann. Der

Prüfer hat darauf zu achten, wie wesentlich Aktivitäten von Service Anbietern für die

Unternehmen und wie relevant sie für die Abschlussprüfung sind. Um die wesentlichen

Aktivitäten festzustellen, beschreibt der PS 402 unter anderem folgende ausgewählte Punkte, die

in Betracht zu ziehen sind: 122

Art der vom Service Anbieter erbrachten Dienstleistungen

Auftragsbedingungen und Beziehungen zwischen Kunde und Service Anbieter

Wesentliche Aussagen im Abschluss, welche durch die Inanspruchnahme eines Service

Anbieters beeinflusst werden

Informationen über den Service Anbieter, wie sie etwa Benutzerhandbüchern oder

technischen Anleitungen entnommen werden können

Leistungsfähigkeit und Finanzkraft des Service Anbieters

Informationen über interne Kontrollen (einschliesslich automatisierter Kontrollen),

soweit sie für die Anwendung des Kunden relevant sind.

Kommt der Prüfer augrund der genannten Punkte zum Schluss, dass der Service Anbieter keinen

wesentlichen Einfluss auf die Aktivitäten des Outsourcer einnimmt, so erübrigt sich die Prüfung

121 Weitere Informationen unter: http://www.ifac.org. 122 Vgl. Treuhandkammer (2004), PS 402 Ziff. 5.


beim Service Anbieter und somit ist auch der PS 402 nicht anzuwenden. Werden hingegen die

Aktivitäten für den Outsourcer als wesentlich betrachtet, so muss der Prüfer gemäss PS 402

„(...) hinreichende Informationen erlangen, um (...) die interne Kontrolle zu verstehen und um das

Kontrollrisiko entweder maximal oder - im Anschluss an verfahrensorientierte Prüfungs-handlung

– als gering einzuschätzen.“123

Der PS 402 gibt drei Möglichkeiten wieder, die zur Anwendung kommen müssen, falls die

vorliegenden Informationen für eine Einschätzung der Kontrollen nicht ausreichen: 124

1. Der Prüfer bittet den Service Anbieter sich durch seine externe Prüfgesellschaft so

prüfen zu lassen, dass die entsprechenden fehlenden Informationen nachgereicht

werden können.

2. Der Prüfer hat die Möglichkeit beim Service Anbieter selber nach den fehlenden

Informationen anzufragen und somit eine Einhalteprüfung durchzuführen.

3. Der Prüfer nimmt die Berichte, die durch die externe Prüfgesellschaft des Service

Anbieters vorgängig angefertigt wurden und verschafft sich so ein Verständnis der

internen Kontrollen und verwendet sie ausserdem für die Einschätzung des

Kontrollrisikos beim Service Anbieter.

Somit ist im PS 402 klar geregelt, wie die externe Prüfgesellschaft vorzugehen hat. Da der PS

402 ein Standard ist, der die Prüfgesellschaften verpflichtet sich nach ihm zu richten, werden die

erläuterten Punkte auch in der Praxis umgesetzt.125

4.4 Koordination des IT-Sicherheitskonzept für das Outsourcing- Vorhaben

Durch den IT-Outsourcing-Vertrag wird mittels den SLA festgelegt, welche Dienstleistungen

vom Service Anbieter in welchem Umfang erbracht werden müssen. Dabei ist die

123 Treuhandkammer (2004), PS 402 Ziff. 7. 124 Vgl. Treuhandkammer (2004), PS 402 Ziff. 8 und 9. 125 Vgl. Anhang Interview Dambacher.


Verantwortlichkeitsverteilung klar geregelt und die Konsequenzen bei Nicht-Erfüllung sind

entsprechend vorhanden. Bei der IT-Security hingegen sind die Verantwortlichkeiten nicht

mittels den SLA geregelt. Die spezielle Thematik der IT-Security ist Bestandteil einer

Kollaboration zwischen dem Service Anbieter und dem Outsourcer. Damit gewährleistet werden

kann, dass mit Applikationen oder Kundendaten auch beim Service Anbieter sicher umgegangen

wird, wird zwischen den Outsourcing-Parteien ein sogenanntes IT-Sicherheitskonzept erstellt. In

diesem Sicherheitskonzept sind die verschiedenen Verantwortlichkeiten, dazu widmet sich

Abschnitt 4.4.1, und die relevanten Themen, welche in Abschnitt 4.4.2 eingehend behandelt

werden, geregelt.

Die zentrale Frage bei der Erstellung eines IT-Sicherheitskonzeptes lautet: Welchen Schutz

benötigen welche IT-Systeme? Es ist zu beachten, was genau geschützt werden muss und

wogegen die Systeme geschützt werden müssen. Wurde eine entsprechende Risikoanalyse

vorgenommen, so muss man sich mit der Frage auseinandersetzen, wie ein wirksamer Schutz

erreicht werden kann und ob der Nutzen des Schutzes einen potentiellen Schaden auch

übersteigt. Damit sind die Kernbestandteile eines IT-Sicherheitskonzeptes zusammen: 126

Schutzbedarfsfeststellung

Risikoanalyse

Massnahmenauswahl

Wirtschaftlichkeitsbetrachtung.

Der Service Anbieter schliesst mit jedem einzelnen Kunden ein separates Konzept ab. Ein IT-

Sicherheitskonzept entsteht aus Verhandlungen zwischen Service Anbieter und Outsourcer,

wobei hinzugefügt werden muss, dass nicht alle Themen des Sicherheitskonzeptes verhandelbar

sind. Dies gilt für Kunden, die z.B. einem „Shared Service“ angehören. Das sind Kunden, die

sich beim Service Anbieter im gleichen Netzwerk oder Rechenzentrum wie andere Kunden

befinden. In einer solchen Situation gibt der Service Anbieter die Pflichten an.127

126 Bundesamt für Sicherheit in der Informationstecknik (2004), Kapitel M 2.195: „Erstellung eines IT-Sicherheitskonzepts“. 127 Vgl. Anhang Interview Mühlenbrock / Hammer.


4.4.1 Beteiligte Personen

Die Erstellung des IT-Sicherheitskonzeptes ist im Idealfall eine Zusammenarbeit zwischen dem

Outsourcer und dem Service Anbieter. Diese Vorgehensweise wird in der Praxis auch so

gehandhabt. Bei geringer Outsourcing-Tätigkeit ist eine gemeinsame Erarbeitung des Sicher-

heitskonzepts nicht zwingend.128

Abbildung 15 zeigt die verschiedenen Parteien auf, die einen Einfluss auf die Erarbeitung des

Sicherheitskonzeptes haben können. Diese Abbildung gibt die Situation in einer üblichen 1:1-

Beziehung zwischen Outsourcer und Service Anbieter wieder. Denkbar wäre diese Abbildung

auch bei einer n:1-Beziehung, d.h. mehrere Outsourcer, die sich zusammengeschlossen haben,

wie es bei der AGI-Kooperation129 der Fall ist, und einem Service Anbieter: 130

Abbildung 15: Involvierte Parteien bei der IT-Sicherheitskonzepterstellung

Abbildung 15 ist so zu verstehen, dass Vertreter der jeweiligen Abteilung in das Erstellungsteam

gesandt, die dann so lange diesem Gremium angehören, wie die Outsourcing-Beziehung gemäss

128 Vgl. Anhang Interview Illi. 129 Vgl. Anhang Interview Allenspach. 130 Die Abbildung und die Ausführungen entstammen den Erkenntnissen aus den Experteninterviews. Vgl. dazu Anhang Interviews Allenspach, Illi, Pfister und Mühlenbrock / Hammer.

Service Anbieter

IT-Security-

Verantwortlicher

Rechtsabteilung

„Business“

Personalabteilung

Sicherheits-

konzept

IT-Security-

Verantwortlicher

Kundenverant-

wortlicher

Rechtsabteilung

Outsourcer


Vertrag dauert. Ein solches Gremium wird üblicherweise IT-Securty-Board genannt.131

Nachfolgend wird auf die einzelnen Rollen und Verantwortlichkeiten der verschiedenen Parteien

näher eingegangen:

IT-Security-Verantwortlicher

Die IT-Security-Verantwortlichen, oftmals sind dies die Chief Security Officer (CSO) der

Unternehmen, haben zu beachten, dass die eigenen internen Sicherheitsrichtlinien in das

Sicherheitskonzept integriert werden. Die Experteninterviews haben gezeigt, dass die Service

Anbieter Vorlagen der Sicherheitskonzepte besitzen, die an die jeweiligen Kunden angepasst

werden. Diese Vorlagen sind mit den Richtlinien und Weisungen des Service Anbieters

bezüglich der IT-Security versehen. Die Einbringung der Richtlinien des Outsourcer gehört zu

den Pflichten des IT-Security-Verantwortlichen des Outsourcer.

Rechtsabteilung

Die Rechtsabteilung prüft die formelle Richtigkeit des Konzeptes. Das Sicherheitskonzept ist

kein eigentlicher Vertrag, jedoch hat die Rechtsabteilung die Verantwortung, die Interessen der

einzelnen Parteien zu wahren.

„Business“

Mit „Business“ sind die Personen gemeint, die an der täglichen Geschäftstätigkeit involviert

sind. Die IT-Security-Massnahmen sollten einerseits ihre Tätigkeit so weit es geht schützen und

andererseits dürfen sie nicht einschränkend wirken. Aus diesem Grund bringen diese Personen

ihre Argumente ein, damit die Geschäftstätigkeit nicht zu fest eingeschränkt wird.

Personalabteilung

Durch die Arbeit mit den Daten des Outsourcer werden auch Anforderungen an das eingesetzte

Personal gestellt. Für den Outsourcer sind der Rekrutierungsprozess des Service Anbieters und

131 Vgl. Anhang Interview Allenspach.


die Massnahmen betreffend den Schulungen der Mitarbeiter von Interesse. Um solche

Restriktionen einbrinigen zu können, nimmt die Personalabteilung an den Verhandlungen teil.132

Kundenverantwortlicher

Oftmals wird jedem Outsourcer durch den Service Anbieter einen persönlichen

Kundenverantwortlicher zur Verfügung gestellt. Dieser Kundenverantwortlicher nimmt nicht nur

Aufgaben bezüglich der IT-Security wahr, sondern dient ausserdem als Ansprechspartner und

Schnittstelle zum Service Anbieter für alle auftretenden Probleme und Wünsche seitens des

Outsourcer. Für die Erstellung des Sicherheitskonzeptes dient der Kundenverantwortlicher als

Kontaktperson und Vermittler. Er besitzt die Übersicht über die ganze Beziehung, weswegen er

die verhandelten Punkte des Sicherheitskonzeptes am besten im gesamten Kontext betrachten

kann.

4.4.2 Relevante Themen für das IT-Sicherheitskonzept

ISO 17799 und das IT-GSHB stellen in der Praxis oftmals die Basis und Richtlinie bei der

Themenwahl des IT-Sicherheitskonzeptes dar.133 Die nachfolgenden Beschreibungen stützen

sich auf die Expertenmeinungen, sowie Vorschläge gemäss ISO 17799 und IT-GSHB, deren

Aufbau in Abschnitt 3.3.4 vorgestellt wurde.

Ein IT-Sicherheitskonzepte hat folgende Bereiche abzudecken:

IT-Sicherheitspolitik134

Um eine gemeinsame Linie zu verfolgen und die nötige Unterstützung für die IT-Security durch

das Management zu erhalten, bedarf es einer gemeinsamen Erarbeitung einer IT-

Sicherheitsstrategie bzw. –richtlinie. Das Management des Outsourcer und des Service Anbieters

wird beauftragt, eine schriftliche Verankerung der gemeinsamen IT-Sicherheitsstrategie zu

132 Vgl. Anhang Interview Allenspach. 133 Vgl. Anhang Interview Illi, Pfister, und Mühlebrock / Hammer. 134 Vgl. Schweizerische Normen-Vereinigung (2001), S. 1 -2 und Bundesamt für Sicherheit in der Informationstecknik (2004), Kapitel 3.0: „IT-Sicherheitsmanagement“.


erstellen und diese allen Mitarbeitern zu kommunizieren. Gemäss ISO 17799 müssen mindesten

folgende Grundlagen abgedeckt werden: 135

Eine Definition der IT-Security, Ziele, Zweck und Wichtigkeit der Sicherheit.

Eine Aussage des Management über die Grundlagen der IT-Security-Richtlinie und die

Absicht, die Ziele vollumfänglich zu verfolgen.

Erklärung der Sicherheitspolitik, Prinzipien, Standards und Konformität für das

Unternehmen.

Definition einer generellen und spezifischen Verantwortlichkeit gegenüber der IT-

Security.

Referenzierungen zu Dokumentationen, die die festgelegte Sicherheitspolitik

konkretisieren bzw. verhelfen diese besser zu verstehen.

Die aufgestellte IT-Sicherheitsrichtlinie bedarf einer ständigen Kontrolle, ob die festgesetzten

Regeln dem aktuellen Zustand entsprechen, damit die Effektivität der Richtlinien weiterhin

bestand hat.

Organisation der Sicherheit136

Dieser Regelung soll der Organisation verhelfen die IT-Security innerhalb des Unternehmens

korrekt aufzubauen und zu betreiben, damit ein Mindestschutzniveau eingehalten werden kann.

Dazu gehört, dass z.B folgende Punkte bestimmt werden:

Verantwortlichkeiten inkl. Verantwortlichkeitstrennungen

Betriebsmittelverwaltung

Reaktionen auf Verletzung der Sicherheitspolitik resp. –richtlinen

Unabhängige IT-Security-Kontrollinstanzen.

135 Vgl. Schweizerische Normen-Vereinigung (2001), S. 2. 136 Vgl. Schweizerische Normen-Vereinigung (2001), S. 2 – 8 und Bundesamt für Sicherheit in der Informationstecknik (2004), Kapitel 3.1: „Organisation“.


Physische Sicherheitsmassnahmen137

Diebstahl oder Beschädigung der IT-Ressourcen138, nicht authorisierte Weitergabe von

Informationen sowie die Unterbrechung der Unterstützung für Geschäftsprozesse gehören zu den

Risiken, die aufgrund von physischen Zugang zu den IT-Ressourcen auftreten können. Aus

diesem Grund müssen physische Zugangskontrollen eingerichtet werden, um diese Risiken und

potenzielle Datenverluste zu vermeiden.

Themen die unter physische Sicherheitsmassnahmen fallen, sind nachfolgend mit einer kurzen

Erläuterung aufgelistet:

Zugang zum Rechenzentrum: Ausschliesslich Mitarbeiter des Service Anbieters, deren

Arbeitsbereiche innerhalb des Rechenzentrums liegen, sowie Personen, die aus ge-

schäftlichen Gründen Zugang zu diesen Bereichen erhalten müssen, darf der Zugang

gewährt werden.

Zugang zu kontrollierte Bereiche: Kontrollierte Bereiche bringen grosse, mittlere oder

verteilte Computersysteme sowie Wechselmedien139 unter, die nicht in einem Rechen-

zentrum stehen. Diese Bestandteile müssen je nach Bedeutung und Wert der Hardware

entsprechend geschützt werden.

Sicherung der Anlagen: Physischer Schutz der Anlagen vor Sicherheitsbedrohungen und

Umweltgefahren, wie z.B. Feuer, Wasser oder Explosionen. Unter Sicherung der

Anlagen gehören Unterthemen wie z.B. Sicherheit der Strom- und Telekommunikations-

verkabelung oder Anlagenwartung.

Logische Zugriffskontrollen140

Logische Zugriffskontrollen behandeln die Zugriffe auf Grossrechner, sogenannten Host-

Systeme, oder LAN-Systeme141.

137 Vgl. Schweizerische Normen-Vereinigung (2001), S. 13 – 19. 138 Vgl. Ausführungen im COBIT Framework Abschnitt 3.2.1. 139 Unter Wechselmedien fallen z.B. Disketten, CD-ROM / DVD oder Tape, die bis zu mehreren Petabyte an Daten speichern können. 140 Vgl. Schweizerische Normen-Vereinigung (2001), S. 33 – 46. 141 LAN steht für Local Area Network und beschreibt ein Computernetzwerk innerhalb eines beschränkten Raumes in der Grösse von maximal 1 km².


Themen von logischen Zugriffskontrollen lauten wie folgt:

Identifizieren und Authentifizieren von Benutzern: Zum Schutz der Informationen müssen

für die Systeme entsprechende Vorkehrungen getroffen werden. Mittel dazu sind die

Vergabe von Benutzer-Identifikationen (ID)142 und Kennwörtern.

o Benutzer-IDs werden an Personen mit Zugriffsberechtigung für ausgewählte

Systeme vergeben. Die Identität von Benutzern und Anwendungen müssen

vorgängig kontrolliert werden.

o Kennwörter dienen zur Identifizierung von Benutzern. Die Zuverlässigkeit des

gewählten Kennworts ist der wichtigste Faktor für den Schutz von Systemen.

Dementsprechend werden im Sicherheitskonzept Kennwortregeln definiert.

Schutz von Objekten: Unter Objekte werden z.B. Texte, Programme oder Daten

verstanden. Diese Objekte werden üblicherweise klassifiziert in: Allgemein, für

bestimmte Personen oder nur für bestimmte Funktionen zugänglich. Entsprechend der

Klassifikation sind die jeweiligen Halter der Objekte für den Schutz verantwortlich. Für

den Schutz der Objekte können Verschlüsselungen dienen. Verschlüsselungsfunktionen

dienen zum Umsetzen des Inhalts von Textdateien in verschlüsselten Texten.

Administratorenberechtigung: Administratoren besitzen einen Sonderstatus, da sie über

alle Rechte eines oder mehrerer Systeme verfügen und für die Rechtevergabe und

Administration zuständig sind. Anforderungsprofile und Kontrolle der Administratoren

müssen im Sicherheitskonzept definiert werden.

Zugriffsprotokollierung: Die Zugriffe auf Systeme, Objekte oder Funktionen müssen in

einer definierten Form dokumentiert und aufbewahrt werden.

Personelle Sicherheit143

Das Personal, welches mit den Kundendaten und Systemen arbeitet, muss sorgfältig rekrutiert

werden. Diesbezüglich müssen wichtige Stellen, wie z.B. der Administrator genaustens ausge-

sucht und geschult werden. Weitere Punkte, die es zu beachten sind und geregelt werden müssen,

sind z.B. Stellvertretungsregelungen, kontinuierliches Besuchen von Schulungen, Vertrautlich-

142 Oftmals auch Username oder User-ID genannt. 143 Vgl. Schweizerische Normen-Vereinigung (2001), S. 10 – 13 und Bundesamt für Sicherheit in der Informationstecknik (2004), Kapitel 3.2: „Personal“.


keitserklärung, Umgang mit Mitarbeiter bei Fehlleistungen und Verfahrensweise bei

Ausscheiden eines Mitarbeiters.

Klassifikation und Kontrolle der Anlagen und Informationen144

Bei diesem Sicherheitskonzept-Thema geht es darum, dass alle Anlagen und Objekte in einer

Inventarliste aufgenommen werden und für jede Anlage bzw. Objekt ein Verantwortlicher

bestimmt wird. Damit kann gewährleistet werden, dass diese mit gebührender Sorgfalt benutzt

und gewartet werden und ausserdem kann somit klargemacht werden, welche Anlagen während

und nach dem Outsourcing-Geschäft weiterhin im Besitz des Kunden respektive dem Service

Anbieter bleiben.

Vorgehensweise bei Sicherheitsnotfällen und Notfallvorsorge145

Ein Sicherheitszwischenfall kann interne oder externe Ursachen haben, sich auf externe

Standorte auswirken und in seiner Wertigkeit varrieren. Als IT-Sicherheitszwischenfälle

bezeichnet man u.a. Systemeinbrüche, die Zerstörung und Manipulationen von Daten, kriminelle

Handlungen oder andere schwerwiegenden Beeinträchtigungen der Systemsicherheit. Die

Notfallvorsorge umfasst Massnahmen, die die Betriebsfähigkeit der IT-Systeme nach deren

Ausfall, sei es nach fahrlässiger oder vorsätzlicher Handlung geschehen, wiederherstellen sollen.

Die präsentierten Ausführungen zeigen die wichtigsten Punkte des ISO 17799 und des IT-GSHB

herauszufiltrieren und daraus einen Minimalkatalog an Konzeptthemen zu bestimmen. ISO

17799 und IT-GSHB gehen mit ihren Beschreibungen und Verpflichtungen sehr viel weiter,

weswegen die vorhergende Auflistung nicht als abschliessend angesehen werden darf.

4.5 Überprüfbarkeit der IT-Security im Outsourcing

Die Überprüfung der IT-Security im Outsourcing-Fall besitzt im Prüfungsvorgehen keine

wesentliche Unterschiede zu einer „normalen“ IT-Security-Prüfung auf. Egal, ob die Leistungen

intern oder extern erbracht werden, die Prüfung erfolgt aufgrund der jährlichen Risikonanalyse.

144 Vgl. Schweizerische Normen-Vereinigung (2001), S.8 – 10. 145 Vgl. Vgl. Schweizerische Normen-Vereinigung (2001), S. 56 – 60 und Bundesamt für Sicherheit in der Informationstecknik (2004), Kapitel 3.3: „Notfallvorsorge-Konzept“.


Tauchen während dieser Risikoanalyse Risiken auf, die beim Service Anbieter zu prüfen sind, so

wird dies durch die Interne Revision des Outsourcer direkt geprüft.146

Oftmals kann eine Zertifizierung durch eine externe und unabhängige Stelle eine hinreichende

Möglichkeit darstellen, die IT-Security des Service Anbieters überprüfen zu lassen und die

resultierende Bestätigung den Kunden zukommen zu lassen. Für den IT-Security Bereich wird

dabei oft auf die ISO 17799 Zertifizierung zurückgegriffen. Das Zertifikat bestätigt gemäss ISO-

Norm die hinreichende Sicherheit der Systeme. Somit erübrigt sich beim Service Anbieter eine

direkte Prüfung durch den Outsourcer.147

Eine weitere Möglichkeit, die IT-Security des Service Anbieters zu testen bzw. zu beurteilen, ist

die Konsultation eines sogenannten SAS 70 Report. Mit einem SAS 70 Report wird die IC des

Service Anbieters durch eine unabhängige externe Prüfgesellschaft überprüft und auf dessen

Effektivität hin getestet. Da eine SAS 70 Prüfung auf einzelne Bereiche angewandt werden kann,

ist es für den Service Anbieter möglich, sich nur einer SAS 70 Prüfung betreffend der IT-

Security zu unterziehen. Durch den Bericht der externen Prüfgesellschaft betreffend dem

Kontrollwesen im IT-Security Bereich des Service Anbieters und der Aussage betreffend der

Effektivität der eingesetzten Kontrollen, kann sich der Outsourcer ein Bild über die IT-Security-

Massnahmen des Service Anbieters machen.

4.6 Zusammenfassung

Durch die Outsourcing-Tätigkeit stehen die Interne und Externe Revision des Outsourcer vor

neuen Herausforderungen. Der Outsourcer hat trotz der Auslagerung weiterhin die

Verantwortung über die ausgelagerten Bereiche. Aus diesem Grund wurde in diesem Kapitel

beschrieben, welche Änderungen auf die Interne und Externe Revision in einer Outsourcing-

Beziehung zukommen. Bei dieser Betrachtung wurde aufgezeigt, dass für die Externe Revision

mit dem PS 402 eine Revisionsnorm besteht, die das Outsourcing-Verhältnis regelt. Im

Gegensatz dazu gibt es für die Interne Revision keinen Standard, auf das sie sich stützen kann.

Daraufhin wurden aufgrund der Expertenaussagen einige Aufgaben für die Interne Revision vor

und im Outsourcing-Verhältnis beschrieben.

146 Vgl. Anhang Interview Illi. 147 Vgl. Anhang Interview Pfister.


Das Outsourcing wirft einige Verantwortlichkeitsfragen auf. Mit der IT-Security wurde eine

Fragestellung aufgegriffen und das IT-Sicherheitskonzept vorgestellt, das die Sicherstellung der

IT-Security im Outsourcing-Fall gewährleisten soll. Neben den verschieden Parteien, die an der

Ausarbeitung des IT-Sicherheitskonzepts involviert sind, wurden Beispielthemen eines IT-

Sicherheitskonzepts vorgestellt.

Der letzte Teil des Kapitels wurde der Überprüfbarkeit der IT-Security im Outsourcing

gewidmet. Dabei wurde aufgezeigt, dass für die Überprüfung der IT-Security beim Service

Anbieter direkte Prüfungen durch die Interne oder Externe Revision des Outsourcer in Frage

kommen. Eine Möglichkeit die direkten Prüfungen zu vermeiden und damit den Aufwand und

die Kosten zu sparen, besteht darin, sich auf Zertifikate oder Reports, wie z.B. der SAS 70

Report, zu verlassen.

Im nächsten Kapitel wird auf den SAS 70 Report näher eingegangen. Dabei wird unter anderem

die Entstehung und der Mehrwert des SAS 70 Report eingehend beschrieben.

5. SAS 70 66

5 SAS 70

Dieses Kapitel beschäftigt sich rund im die Thematik des Statement on Auditing Standard Nr. 70

(SAS 70). Im vorhergehenden Kapitel wurde auf die Schwierigkeit der Überprüfung der IT-

Security im Outsourcing-Verhältnis eingegangen. SAS 70 bietet eine Möglichkeit, ohne selber

direkte Prüfungen beim Service Anbieter vorzunehmen, trotzdem die Sicherheit zu haben, dass

die Geschäftstätigkeit des Service Anbieters den eigenen Ansprüchen entsprechen. Nachdem in

den Abschnitten 5.1, 5.2 und 5.3 der SAS 70 Standard inhaltich vorgestellt wird, wird im

darauffolgenden Abschnitt näher auf die Vorteile des SAS 70 eingegangen. Dabei werden die

Vorteile eines SAS 70 Report für den Service Anbieter wie auch dem Outsourcer dargelegt. Da

der SAS 70 ein in den USA entstandener Standard ist und in den letzten Jahren vermehrt zum

Einsatz kam, wird in Abschnitt 5.5 die Begründung für die Verbreitung des SAS 70 erläutert. In

diesem Zusammenhang wird vorgängig der Sarbanes-Oxley Act näher beschrieben, welcher mit

eines der Gründe ist, wieso ein SAS 70 Report immer mehr an Bedeutung gewinnt. Nachdem in

Abschnitt 5.6 der Vergleich mit International ähnlichen Standard gemacht wird, wird

abschliessend auf ähnliche Verfahren zu einem SAS 70 eingegangen. Dabei werden

insbesondere die Unterschiede zu den möglichen Alternativen aufgezeigt.

5.1 SAS 70 – Vorstellung und Gründe

Statement on Auditing Standards (SAS) Nr. 70 mit dem Titel „Service Organizations”, ist ein

international anerkannter Standard, der vom AICPA ins Leben gerufen wurde. SAS 70 wird auch

als „Third Party Report on Controls“ oder „Service Auditor’s Report“ bezeichnet. SAS 70 ist

ein gezielt für die Prüfung von Outsourcing-Geschäften angelegter Standard. Es enthält

insbesondere die Regelungen, unter welchen Voraussetzungen sich der externe Prüfer des

Outsourcer auf die Prüfungsergebnisse Dritter beim Service Anbieter verlassen kann und

inwiefern die Prüfungsergebnisse verwertet werden dürfen. Durch das SAS 70 erfolgt eine

Berichterstattung über die implementierten Kontrollziele und Kontrollen beim Service Anbieter.

Falls ein SAS 70 Typ II148 durchgeführt wurde, enthält der Bericht zusätzlich eine Beschreibung

der Prüfungen, die vom externen Prüfer vorgenommen wurden, um die Kontrollen zu testen,

sowie eine Aussage über die Wirksamkeit der vom Service Anbieter eingesetzten Kontrollen.

Dieser Bericht, der SAS 70 Report genannt wird, wird vom externen Prüfer des Service

148 Vgl. Abschnitt 5.2.

5. SAS 70 67

Anbieters verfasst. Da durch den SAS 70 Report das Kontrollwesen des Service Anbieters

offengelegt wird, ist es für den Outsourcer möglich, sich ein Bild über die eingesetzten Mitteln

beim Service Anbieter zu machen, um so zur notwendigen Sicherheit zu gelangen, dass die

Dienstleistungen mit der notwendigen Sorgfalt erbracht werden.

Historisch betrachtet wurde mit dem SAS 70 Standard kein Novum bezüglich der Themen

Interne Kontrolle und Service Anbieter geschaffen. Mit dem SAP 29149 aus dem Jahre 1958

wurde das erste Mal ein Standard veröffentlicht, dessen Zweck war, einen unabhängigen Bericht

über die Internen Kontrollen eines Unternehmens anfertigen zu lassen. Mit dem SAS 44150 aus

dem Jahre 1982 beschäftigte sich erstmals ein Standard mit dem Thema der Beurteilung der

Internen Kontrolle beim Service Anbieter. Im Juli 1984 wurde mit dem Standard SAS 48 der

Effekt der IT für die Interne Kontrolle und speziell der Jahresabschlussprüfung gewidmet. Seit

1992 regelt das SAS 70 die ganze Outsourcing-Beziehung bezüglich der Internen Kontrolle. Die

genannten Standards sind beim SAS 70 nicht alle vereint, jedoch bildeten sie die Basis für die

Erstellung des SAS 70 Standards.

Aufgrund der vermehrten Outsourcing-Tätigkeiten der Unternehmen wurden mit dem SAS 70

die Anforderungen der Berichterstattung seitens den Behörden geklärt. Wie in Abschnitt 4.2

erläutert, nimmt ein Outsourcing den Outsourcer bezüglich der Kontrolle der ausgelagerten

Tätigkeiten weiterhin in die Pflicht. Weitere Gründe, weshalb ein SAS 70 Report von Nöten ist,

sind nachfolgend aufgelistet: 151

Die Qualität und Verlässlichkeit der Kontrollen des Service Anbieters haben

Auswirkungen auf das Risikomanagement des Outsourcers und beeinflussen damit

dessen finanziellen Erfolg

Der Outsourcer muss die Prozesse und Kontrollen des Service Anbieters verstehen und

überwachen können

SAS 70 fordert ein Prüfungsvorgehen und Reporting, das dem Outsourcer und dessen

Abschlussprüfer die notwendigen Informationen zur Überwachung des Service Anbieter

liefert.

149 Standard on Auditing Procedures (SAP) kann als Vorgänger der SAS – Interpretationen betrachtet werden. Der SAP Nr. 29 trägt den Titel: „Scope of the Independent Auditor’s Review of Internal Control”. 150 SAS 44 wurde im Dezember 1982 publiziert und trägt den Titel: „Special-Purpose Reports on Internal Accounting Control at Service Organizations”. 151 Vgl. PricewaterhouseCoopers (o.J.), S. 6.

5. SAS 70 68

Durch den SAS 70 Standard wird die Berichterstattung von Service Anbietern vereinheitlicht

und er macht die Prüfungsergebnisse vergleichbar.

5.2 Typen

Der SAS 70 Standard unterscheidet zwei Typen von Prüfungen bzw. dem daraus resultierenden

SAS 70 Report. SAS 70 Typ I beschreibt die Kontrollen des Service Anbieters an einem

spezifischen Zeitpunkt. Der Typ II erweitert den Typ I indem die beschriebenen Kontrollen

zusätzlich in einer minimal vorgegebenen Periode von sechs Monaten getestet werden. Der SAS

70 Report nach Typ II beinhaltet demnach die Meinung der externen Prüfgesellschaft über das

Kontrollwesen beim Service Anbieter, eine Beschreibung der Kontrollen, Angaben über die

Prüfperiode, Beschreibung der Prüfmethode und eine Aussage über die Wirksamkeit der

Kontrollen. Abbildung 16 fasst die unterschiedlichen Bestandteile des Berichts je nach Typ

zusammen:

Bestandteile des Report Typ I Report Typ II Report

Unabhängiger Bericht der externen

Prüfgesellschaft (The Auditors opinion

Letter)

Beschreibung der Kontrollen des Service

Anbieters

Informationen durch den externen Prüfer

mit Aussagen über die angewandten

Tests, den Resultaten und die Aussagen

betreffend der Effektivität der Kontrollen

Nicht enthalten

Andere Informationen z.B. Glossar Optional Optional

Abbildung 16: Unterschiede SAS 70 Report Typ I und Typ II152

Wie Abbildung 16 zeigt, besteht der Unterschied zwischen den zwei verschieden Typen darin,

dass beim Typ I keine Aussage betreffend der angewandten Tests, den Resultaten und der

152 In Anlehung an SAS 70 (2005a), o.S.

5. SAS 70 69

Effektivität der Kontrollen gemacht wird. Insbesondere der fehlenden Effektivitätsbeschreibung

kommt jedoch eine entscheidende Rolle zu, wieso oftmals die Typ II Prüfung trotz höherem

Aufwand einer Typ I Prüfung vorgezogen wird. Die Effektivitätsbeschreibung ist ein wichtiger

Bestandteil für die Sarbanes-Oxley Act Konformität. Mehr dazu wird in Abschnitt 5.5

beschrieben.

5.3 Prüfgebiete und Schwierigkeiten eines SAS 70 Audits

Die folgenden Ausführungen beschäftigen sich rund um die Prüfgebiete einer SAS 70 Prüfung.

Eng mit dieser Thematik zusammenhängend lassen sich die Schwierigkeiten einer SAS 70

Prüfung beschreiben, auf die in Abschnitt 5.3.2 näher eingegangen wird.

5.3.1 Prüfgebiete eines SAS 70 Audit

Als Hauptmerkmal einer SAS 70 Prüfung gilt, dass der Prüfumfang und die daraus abgeleitete

Gebiete vom SAS 70 Standard bzw. AICPA nicht weiter vorgegeben werden. Der Prüfumfang

muss je nach Art der ausgelagerten Dienstleistungen für jeden SAS 70 Prüfauftrag definiert

werden.153 Somit besitzen der Service Anbieter, die Outsourcer und die externen Prüfer einen

sehr hohen Freiheitsgrad bei der Gestaltung und Durchführung einer SAS 70 Prüfung. Dieser

hohe Freiheitsgrad wird gemäss Expertenaussagen auch als Schwäche der SAS 70 Prüfung

angesehen.154

Die SAS 70 Prüfung kennt bezüglich des Einsatzgebiets keine Einschränkungen. Zum Prüffokus

können alle Bereiche eines Unternehmens genommen werden oder daraus einzelne betrachtet

werden. Nachfolgend sind einige Bereiche und mögliche Prozesse aufgelistet, die durch eine

SAS 70 Prüfung abgedeckt werden können.

153 Vgl. Dambacher / Hug (2005), S. 22. 154 Vgl. Anhang Interview Dambacher und Abschnitt 5.3.2.

5. SAS 70 70

Bereiche Prozesse

Portfolio Management z.B. Kunden Kontoadministration und

Wartung, Überwachung der Performance,

Erfüllung von Richtlinien und Restriktionen

Handel z.B. Authorisation, Einhaltung von trade limits

Rechnungswesen des Kunden und Reporting z.B. Bewertungsgrundsätze, Bestätigung von

Investitionen, Einkünfte und Ausgaben

Informationssicherheit z.B. Logische und physische Zutrittskont-

rollen, Change Management, Systembetrieb,

Datenmanagement

Abbildung 17: Beispiele von Bereichen und Prozessen einer SAS 70 Prüfung155

Insbesondere der Bereich der Informationssicherheit respektive das Teilgebiet, die IT-Security,

wird in Kapitel 6 dieser Arbeit näher behandelt.

5.3.2 Schwierigkeiten und Schwächen eines SAS 70 Audit

Eine SAS 70 Prüfung hat neben verschiedenen positiven Eigenschaften, die im Abschnitt 5.4

erläutert werden, auch Schwächen bzw. Schwierigkeiten, die rund um die SAS 70 Prüfung

auftreten können. Im vorherigen Abschnitt wurde mit dem erhöhten Freiheitsgrad beim

Prüfungsumfang eines der Hauptschwächen einer SAS 70 Prüfung erwähnt. Folgende Aus-

führungen erläutern neben dem Freiheitsgrad noch weitere Schwierigkeiten, die zum Stolperstein

einer SAS 70 Prüfung werden können:156

Kein eigentlicher Standard

SAS 70 ist kein Standard, der einem Unternehmen vorschreibt, welche Dinge zu beachten sind,

um die Prüfung durch die externe Prüfgesellschaft zu bestehen. In einer SAS 70 Prüfung ist der

Service Anbieter selber dafür verantwortlich, die Kontrollziele und –aktivitäten zu definieren

und umzusetzen. Ist ein Kontrollziel bzw. eine Kontrolle durch den Service Anbieter nicht

155 In Anlehung an PricewaterhouseCoopers (o.J.), S. 8. 156 Vgl. Gossels (2001), S. 1 – 2.

5. SAS 70 71

definiert, so wird im SAS 70 Report keine Bemerkung über die fehlende Kontrolle gemacht.

SAS 70 schreibt keine Kontrollen vor, die eingehalten werden müssen, so dass deshalb ein SAS

70 Report nie negativ ausfällt. Der externe Prüfer muss gemäss SAS 70 Richtlinien die vom

Service Anbieter definierten Kontrollziele betrachten und die entsprechenden Kontrollen

beurteilen. Dabei muss beurteilt werden, ob mit diesen Kontrollen die entsprechenden

Kontrollziele erreicht werden können. Im Auditors Opinion Letter, als Bestandteil des SAS 70

Report, besteht die Möglichkeit eine Bemerkung über die fehlenden Kontrollen anzubringen,

jedoch ist dies eine subjektive Einschätzung der Prüfer und die muss nicht mit der

Kontrollphilopsophie bzw -priorisierung des Service Anbieters übereinstimmen.

CPA-Prüfung

Eine SAS 70 Prüfung darf nur durch ein Certified Public Accountant (CPA)157 Unternehmen

vorgenommen werden. Insbesondere bei SAS 70 Prüfungen bezüglich der Informationssicherheit

wäre ein Einbezug von Technologieexperten wünschenswert, was gewährleisten würde, dass

spezielles Know-how in die Prüfung einfliessen würde.

Kosten- und Aufwandsintensiv

Eine SAS 70 Prüfung ist je nach Typ unterschiedlich teuer. Jedoch sind die Kosten für beide

Typen sehr hoch. Die Kosten und der Aufwand einer Prüfung können ansteigen, wenn die beim

Service Anbieter angestrebten Kontrollziele und die eingesetzten Kontrollen nicht angemessen

dokumentiert sind. Ist dies der Fall, so muss die ganze Dokumentation mit Hilfe der externen

Prüfgesellschaft erarbeitet werden, was die Kosten weiter ansteigen lässt.158

Da die IT einer sehr schnellen Entwicklung untersteht, werden IT-Systeme bzw. die Infrastruktur

sehr oft ersetzt. Wird eine Umstellung vorgenommen, so Bedarf es einer neuen SAS 70 Prüfung

in diesem Bereich, da eventuell Umstellungen der Kontrollen vorgenommen wurden, was

wiederum die Kosten erhöht.

157 In der Schweiz schliesst ein graduierter Wirtschaftsprüfer mit dem Titel diplomierter Wirtschaftsprüfer ab, was in den USA dem CPA Titel entspricht. 158 Vgl. Anhang Interview Dambacher.

5. SAS 70 72

5.4 Mehrwert durch einen SAS 70 Report

Nachdem im vorhergehenden Abschnitt auf die Schwierigkeiten und Schwächen einer SAS 70

Prüfung eingegangen wurde, hat dieser Abschnitt zum Ziel die Vorteile aufzuzeigen. Hierfür

wird zwischen Vorteile für den Service Anbieter, was in Abschnitt 5.4.1 behandelt wird, und

Vorteile für den Outsourcer unterschieden.

5.4.1 Mehrwert für den Service Anbieter159

Durch die genaue Überprüfung und Dokumentation der Kontrollen durch die externe

Prüfgesellschaft, wird dem Kunden, d.h. den aktuellen oder potentiellen Outsourcern, die

Möglichkeit gegeben sich ein direktes Bild des Service Anbieters zu machen. Dies führt zu

einem verstärkten Vertrauensverhältnis zwischen Outsourcer, deren externe Prüfgesellschaft und

dem Service Anbieter. Ein Prüfbericht nach SAS 70 kann dementsprechend nicht nur ein Mittel

sein, um bestehende Kunden zu überzeugen, sondern es kann auch als Marketing-Instrument für

den Service Anbieter dienen, um potentielle Neukunden zu akquirieren. Durch den SAS 70 Typ

II Report wird dem Service Anbieter durch eine externe Prüfgesellschaft bestätigt, dass die

eingesetzten Kontrollen effektiv sind. Diese externe Bestätigung und somit der SAS 70 Report

kann bei der Wahl des Service Anbieters ein entscheidender Wettbewerbsfaktor sein.

Im Abschnitt 4.2 wurde beschrieben, dass der Outsourcer weiterhin für die ausgelagerten

Prozesse verantwortlich ist. Somit werden vom Outsourcer oder dessen externer Prüfgesellschaft

auch direkte Prüfungen beim Service Anbieter notwendig sein, um die Sicherheit zu erhalten,

dass die Leistungen durch den Service Anbieter korrekt erbracht werden. Durch einen SAS 70

Report kann der Service Anbieter den Kunden und insbesonderen den externen

Prüfgesellschaften ein Exemplar von diesem Report aushändigen. Die darin detailliert

festgehaltenen Kontrollen, Prüfvorgehensweise und Effektivitätsangaben sollten genügen, um

eine direkte Prüfung zu vermeiden. Somit sparen der Service Anbieter und das Umfeld des

Kunden Zeit, Geld und personelle Ressourcen, da eine direkte Prüfung nicht mehr zwangsläufig

notwendig ist bzw. nun gezielter durchgeführt werden kann. Durch einen SAS 70 Report kann

beidseits Gewissheit geschaffen werden, dass relevante Standards wie z.B. das EBK 99/2 oder

der Sarbanes-Oxley Act160 (Section 404) erfüllt werden.

159 Ausführungen basieren auf SAS 70 (2005a), o.S., SAS 70 Solutions (2005b), o.S. und Expertenmeinung vgl. dazu Anhang Interview Dambacher. 160 Vgl. Abschnitt 5.5.1.

5. SAS 70 73

Als letztes Argument kann die Lernfähigkeit eines SAS 70 Report dienen. Ein SAS 70 Report

mit den Kontrollen und der Effektivitätsbeurteilung als Inhalt kann für den Service Anbieter

selbst eine gute Möglichkeit darstellen, potentielle Optimierungsmöglichkeiten der Kontrollen zu

entdecken und dementsprechend Massnahmen zu ergreifen.

5.4.2 Mehrwert für den Outsourcer161

Die Vorteile, die der Outsourcer durch einen SAS 70 Report erhält, sind Gegenstand dieses

Abschnittes. Neben den im vorherigen Abschnitt erwähnten Einsparung von Ressourcen durch

Verminderung der Prüftätigkeit beim Service Anbieter, trägt ein SAS 70 Report unter anderem

auch viel zur Transparenz bei. Durch den SAS 70 Report erhält der Outsourcer einen Einblick in

die Organisation des Service Anbieters sowie dessen Prozesse und Kontrollmassnahmen. Somit

ist es für den Outsourcer möglich, eigene bestehende Prozessabläufe effizienter zu gestalten und

Risiken zu identifizieren. Ein SAS 70 Report verhilft dem Outsourcer die jährlich zu

bestätigende Sarbanes-Oxley-Zertifizierung zu erlangen, sofern der Outsourcer diesem Gesetz

untersteht.162

5.5 Sarbanas-Oxley und SAS 70

Im Verlauf dieser Arbeit wurde der Begriff „Sarbanes-Oxley Act“ (SOX) eingeführt. Der SAS

70 Standard hat in den letzten Jahren insbesondere in den USA sehr an Beliebtheit

dazugewonnen. Dies hat SAS 70 unter anderem dem SOX zu verdanken. Bevor auf die

Beziehung zwischen dem SOX und SAS 70 eingegangen wird, wird im Abschnitt 5.5.1 der SOX

erklärt. Danach wird in Abschnitt 5.5.2 die Verknüpfung zwischen dem SOX und SAS 70

erläutert.

5.5.1 Der Sarbanes-Oxley Act

Der SOX wurde durch die Urheber Senator Paul Sarbanes und Mitglied des

Repräsentantenhauses Micheal Oxley als Investorenschutzgesetz erschaffen. Mit der Unter-

zeichnung am 30. Juli 2002 durch den Präsidenten der Vereinigten Staaten von Amerika trat

161 Vgl. SAS 70 (2005a), o.S. 162 Vgl. Abschnitt 5.5.1.

5. SAS 70 74

dieses Gesetz per sofort in Kraft. Verpflichtend ist dieses Gesetz für alle bei der amerikanischen

Börsenaufsichtsbehörde SEC163 registrierten Unternehmen und deren Wirtschaftsprüfer.164

Vorangetrieben wurde das Gesetz durch die Bilanzierungsskandale wie z.B. Enron und

Worldcom. Der Zweck des neuen Gesetzes ist, die Inverstoren durch Verbesserungen der

Genauigkeit und Zuverlässigkeit der Unternehmensberichterstattung vor Falschinterpretationen

zu schützen. Die Unternehmensberichterstattung soll durch mehr Transparenz verbessert werden.

Das Gesetz umfasst 66 Seiten.165 Zusammenfassend geht es beim Sarbanes-Oxley weitgehenst

um:166

Bestätigung der Vollständigkeit und Richtigkeit aller Angaben in den regelmässigen

Unternehmensreportings (Financial Statements) sowie das Aufzeigen bekannt

gewordener Schwachstellen im IC und durchgeführte Veränderungen an der IC

gegenüber den Wirtschaftsprüfern und dem Audit Committee (Section 302)

Implementierung eines IC, das die Einhaltung der Forderung von Section 302 sowie die

Dokumentation dieser IC (Section 404) entspricht

Alle Geschäftsprozesse, im Kern allerdings um die (Kontroll-) Prozesse, die in

unmittelbarem Zusammenhang mit der Rechnungslegung stehen.

Für diese Arbeit sind insbesondere die in Abschnitt 3.1.1 erwähnten Section 302 und 404 von

Interesse. Im nächsten Abschnitt wird die Wichtigkeit verdeutlicht.

Zusammenfassend kann festgestellt werden, dass der Sarbanes-Oxey Act viel zur Transparenz

der finanziellen Berichterstattung und Stärkung der Corporate Governance beiträgt. Bis zum

31.12.2006 müssen alle an der US-Börse kotierten Unternehmen die SOX-Tauglichkeit

bestätigen. Die SOX-Konformität muss jährlich bestätigt werden. Werden die Grundsätze nicht

eingehalten, so drohen teilweise drastische straf- und haftungsrechtlichen Sanktionen.167

163 SEC steht für Securities and Exchange Commission. 164 An der SEC wird ein Unternehmen registriert, wenn es an der amerikanischen Börse kotiert ist, mindestens 500 Angestellten umfasst und die Bilanzsumme des letzten Geschäftsjahres mindestens zehn Millionen US-Dollar betrug. Da einige grosse schweizerische Unternehmen auch in den USA an der Börse kotiert sind, sind auch diese dem Sarbanes-Oxley Act unterworfen. 165 Unter http://news.findlaw.com/hdocs/docs/gwbush/sarbanesoxley072302.pdf kann der gesamte Sarbanes-Oxley Act eingesehen werden. 166 Vgl. DCA-Consulting (2005), o.S. 167 Z.B. kann eine absichtliche Verletzung der Richtlinien eine Geldstrafe bis zu 5 Mio. US-Dollar und eine Gefängnissstrafe von bis zu 20 Jahren nach sich ziehen.

5. SAS 70 75

5.5.2 Zusammenhang Sarbanes-Oxley Act und SAS 70

Section 302, welches die Unternehmensleitung bzw. den Verwaltungsrat verpflichtet eine IC zu

betreiben, dient als Grundlage zur Section 404, welches zu einer jährlichen Stellungnahme

betreffend der Angemessenheit der IC verpflichtet. Das in Abschnitt 3.1.2 erläuterte COSO-

Framework wird gemäss SEC, die zusammen mit dem PCAOB168 für die weiteren Ausführungen

des SOX beauftragt worden sind, als Referenzmodell einer IC-Implementierung im

Unternehmen anerkannt:

„The US Securities and Exchange Commission (SEC) has mandated the use of a recognized

internal control framework. The SEC in its final rules regarding the Sarbanes-Oxley Act made

specific reference to the recommendations of the Committee of the Sponsoring Organizations of

the Treadway Commission (COSO).“169 170

Gemäss Section 404 muss eine Stellungnahme zur Angemessenheit der IC gegeben werden. In

einem Outsourcing-Fall sind die Outsourcer wie in Abschnitt 4.2.1 beschrieben weiterhin für die

Kontrolle der ausgelagerten Bereiche zuständig. Um die Kontrolle aufrecht zu erhalten kann der

vorgestellte SAS 70 Report dienen. Gemäss folgendem Auszug ist ein SAS 70 Report vom Typ

II ausreichend, um die SOX-Konformität zu gewährleisten:

„Traditionally, audit opinions commonly known as SAS 70 reports (Section 5900 in Canada) have

been performed for service organizations. If these audit reports do not include test of controls,

results of the tests and the service auditor’s opinion on operating effectiveness, they may not be

deemed sufficient for purposes of Sarbanes-Oxley compliance. In such cases, organizations may

wish to consult with theirs external auditors and understand the specific requirements. Particular

attention should be paid to the period covered by the SAS 70 and ensure that the controls in the

SAS 70 cover the environment, platforms and applications utilized by the company.”171 172

168 PCAOB steht für Public Company Accounting Oversight Board. Diese Non-Profit-Behörde wurde durch das SOX geschaffen und hat die Aufsicht über die Wirtschaftsprüfungsgesellschaften zur Aufgabe. 169 IT Governance Institute (2004c), S. 5. 170 Herv. d. Verf. 171 IT Governance Institute (2004c), S. 44. 172 Herv. d. Verf.

5. SAS 70 76

Der SAS 70 Report Typ I reicht für die SOX-Konformität nicht aus, da keine Aussagen über die

Effektivität der Kontrollen gemacht werden. Diese werden aber gemäss Section 404 verlangt,

was erst ein SAS 70 Report Typ II bieten kann.

Durch die SOX-Anerkennung hat der SAS 70 Report einen grösseren Stellenwert eingenommen.

Da ein SAS 70 Report für die SOX-Konformität genügt und deshalb direkte Prüfungen durch

den Outsourcer beim Service Anbieter nicht mehr nötig sind, unterziehen sich die Service

Anbieter immer mehr einer SAS 70 Prüfung.173

5.6 International vergleichbare Reports

SAS 70 ist ein Standard, welcher in jüngster Vergangenheit in den USA entstanden ist und sich

allmählich auch auf andere Kontinente verbreitet. Nachfolgende Ausführungen zeigen Standards,

die eine ähnliche Ausrichtung und Umfang, wie SAS 70 besitzen. Vorgestellt werden mit

Section 5900, FIT 1/94 und FRAG 21/94 Standards, die lange in Kraft sind bzw. teilweise

erneuert wurden. Mit dem Prüfungsstandard 402 hat die Schweiz seit Januar 2005 einen ähnlich

ausgelegten Standard.

5.6.1 Prüfungsstandard 402 (Schweiz)

Der schweizerische Prüfungsstandard 402 (PS 402) wurde in Abschnitt 4.3 vorgestellt. PS 402,

welches dem ISA 402 entstammt, stellt keine exakte Kopie des SAS 70 dar, jedoch besitzt dieser

Standard inhaltlich eine ähnliche Ausrichtung. Wie das SAS 70 unterscheidet der PS 402 auch

zwei Typen der Berichterstattung, die den gleichen Umfang wie die SAS 70 Typen beinhalten:174

Typ A: Bericht über die Angemessenheit der Konzeption. Dabei muss der externe Prüfer

unter anderem die Beschreibung der internen Kontrolle des Service Anbieters sowie die

Korrektheit der Beschreibung und die Angemessenheit der Konzeption der Kontrollen

dokumentieren.

Typ B: Zusätzlich zum Typ A muss über die Wirksamkeit der internen Kontrolle

aufgrund von Prüfungshandlungen eine Aussage gemacht werden. Neben dem Urteil des

173 Vgl. Anhang Interview Mühlenbrock / Hammer. 174 Vgl. Treuhandkammer (2004), PS 402 Ziff 12.

5. SAS 70 77

externen Prüfers über die Wirksamkeit der Kontrollen, muss dieser noch Angaben zu den

durchgeführten Prüfungshandlungen und deren Ergebnisse dokumentieren.

Die Ähnlichkeit des PS 402 zum SAS 70 wird auf Grund der zwei Typen der Berichterstattung

ersichtlich. Wie das SAS 70 macht auch der PS 402 keine Angaben zur Prüftiefe und -umfang

des Typ B. Der Freiheitsgrad für den externen Prüfer ist dementsprechend gross. Im Unterschied

zu SAS 70 gelangt der PS 402 nur zum Einsatz, wenn wie in Abschnitt 4.3 beschrieben,

wesentliche Aktivitäten ausgelagert wurden.

5.6.2 Section 5900 (Kanada)

Das kanadische Äquivalent zum SAS 70 ist die Section 5900 mit dem Titel „Opinions on

Control Procedures at a Service Organization“. Dieser Abschnitt wurde 1987 im „Handbook of

Auditing” vom Canadian Institute of Chartered Accountants (CICA) hervorgerufen.

Wie SAS 70 unterscheidet die Section 5900 auch zwei Prüftypen. Typ I beschreibt zu einem

bestimmten Zeitpunkt die Meinung der externen Prüfer betreffend der Existenz und der

Kontrollprozeduren. Es wird keine Aussage über die Effektivität der Kontrollen gemacht. Typ II

macht im Gegensatz zum Typ I eine Periodenbetrachtung. Der Prüfer ist angehalten, Tests

durchzuführen und Meinungen des Management einzuholen, um eine Aussage über die

Effektivität der Kontrollprozeduren zu erlangen. Im Gegensatz zu SAS 70, schreibt die Section

5900 keine Testperiode von sechs Monaten vor. Die Periode hängt von der Erfahrung des Prüfers

ab, innerhalb welcher Zeit ein verlässliches Bild der Kontrollprozeduren gemacht werden kann.

Ab dem 1. Januar 2006 tritt die überarbeitete Version der Section 5900 in Kraft, die im Moment

noch in Bearbeitung ist. Die Bestimmungen von 1987 wurden aufgrund der immer weiter

steigenden Outsourcing-Aktivitäten der Unternehmen komplett überarbeitet. Ziel der

überarbeiteten Fassung ist, die Section 5900 dem SAS 70 anzugleichen.175

175 Vgl. Canadian Institute of Chartered Accountants (o.J.), o.S.

5. SAS 70 78

5.6.3 FIT 1/94 und FRAG 21/94(UK)

Die Faculty of Information Technology (FIT) des Institute of Chartered Accountants in England

and Wales (ICAEW) brachte im Jahre 1994 den technischen Report FIT 1/94 heraus. Dieser trägt

den Titel: „Reports on the Processing of Transactions by Service Organizations“. Genau gleich

wie beim SAS 70 Report und Section 5900, definiert FIT 1/94 auch zwei Prüfmöglichkeiten. Der

Prüfer ist angehalten seine Meinung über die Kontrollprozeduren an einem Zeitpunkt zu machen

oder als zweite Prüfmöglichkeit werden die Kontrollen während einer Zeitperiode getestet. Diese

Zeitperiode ist wie beim Section 5900 nicht fixiert, jedoch wird wie beim SAS 70 Report eine

sechs monatige Periode vorgeschlagen.

Die Reporting and Auditing Group (FRAG) des ICAEW hat im Jahre 1994 eine dem FIT 1/94

ähnliche Richtlinie geschaffen. Der Technical Report FRAG 21/94 mit dem Titel „Reports on

Internal Controls of Investmenet Custodian Made Available to Third Parties“, hat jedoch einen

enger gesteckten Zweck, als der FIT 1/94 Report. Der Fokus liegt primär auf das Anlagegeschäft

der Banken. Andere Bereiche werden nicht adressiert. Jedoch kann sich der Prüfer eine Meinung

über die Kontrollen bilden, da FRAG 21/94 dem Unternehmen bzw. Verwaltungsrat vorschreibt,

unter anderem einen Bericht über „details of each of the specific control procedures designed to

achieve the control objectives“ und „details of any significant changes to the objectives and

procedures during the period“ 176 177 zu verfassen. Im Gegensatz zu FIT 1/94 schlägt FRAG

21/94 keine minimale Betrachtungsperiode vor. Eine weitere Spezialität des FRAG 21/94 ist,

dass die Effektivität der Kontrollen nicht von den Prüfern bewertet werden müssen, sondern vom

Management bestätigt werden. Eine entsprechende Vorlage ist im FRAG 21/94 Anhang zu

finden.178

5.6.4 Australien

Australien hat mit dem Auditing Standard 404 (AUS 404) seit dem Juli 2002 einen Standard, der

sich mit dem Outsourcing-Geschäft beschäftigt. AUS 404 mit dem Titel „Audit Implications

Relating to Entities Using a Service Entity“ orientiert sich im Aufbau und in der Beschreibung

dem ISA 402 und ist dementsprechend dem schweizerischen PS 402 gleichzusetzen.179

176 Institute of Chartered Accountants in England and Wales (1997), S. 4 Absatz 8. 177 Herv. d. Verf. 178 Vgl. The Institute of Chartered Accountants in England and Wales (1997), S. 16. 179 Vgl. Abschnitt 4.3 für die Ausführungen zu ISA 402 bzw. PS 402.

5. SAS 70 79

Der AUS 404 ist nicht die einzige Richtlinie für das Outsourcing-Geschäft. Seit dem Jahre 1997

existiert der Audit Guidance Statement 1026 (AGS 1026) mit dem Titel „Superannuation Funds

– Auditor Reports on Externally Managed Assets“. AGS 1026 ist dem britischen FRAG 21/94

Report sehr ähnlich. Der AGS 1026 richtet sich jedoch nur auf Pensionskassengeschäfte

(Superannuation Funds) respektive ist eine Hilfestellung für deren externe Prüfer, die sich ein

Bild über die ausgelagerten Bereiche machen wollen. Der Report ist geschaffen worden, um die

Bedürfnisse der Treuhänder und Prüfer zu befriedigen und um mehr Konsistenz in die Berichte

der Prüfer der externen Manager zu bekommen.180

Der AGS 1026 Report beinhaltet die Meinung des externen Prüfers über die Effektivität der

internen Kontrollen der Anlagen, die der externe Pensionskassenverwalter bei sich verwaltet.

AGS 1026 bestimmt zu diesem Zweck, wie der FRAG 21/94 Report, keine minimal zu

betrachtende Periode. Wie beim FRAG 21/94, müssen die Kontrollkriterien nicht vom Prüfer

bewertet werden, sondern diese Tätigkeit obliegt dem Management.

5.7 Mögliche Alternativen zu SAS 70 im IT-Security Bereich

Ein häufig genannter Grund wieso ein Unternehmen sich nicht für ein SAS 70 Report

entscheidet, sind die anfallenden hohen Kosten.181 SAS 70 Prüfungen sind in ihrer Prüfdauer

sehr zeitintensiv. Für grosse Service Anbieter mit einer Vielzahl von Kunden sind sie von

Vorteil, da eine SAS 70 Prüfung den direkten Prüfungen durch die Outsourcer zu bevorzugen

ist.182

Viele kleinere Unternehmen können sich die kostenintensive SAS 70 Prüfung nicht leisten.

Trotzdem wollen diese Unternehmen den Kunden die Sicherheit und Zuverlässigkeit ihrer

Systeme kommunizieren. Vielfach wird darum im IT-Security Bereich zu ähnlichen Verfahren

wie SysTrust gegriffen. SysTrust stellt jedoch keine direkte Alternative zum SAS 70 dar.

Nachfolgende Ausführungen stellen mit den Trust Services, SysTrust und WebSecure,

Dienstleistungen bzw. Zertifizierungen vor, die häufig im Einsatz sind. Dass diese Trust Services

keine direkte Alternativen zum SAS 70 sind, wird in Abschnitt 5.7.2 erläutert. Oftmals wird die

ISO 17799 Zertifizierung als hinreichende Alternative zu einer SAS 70 Prüfung angenommen.

180 Vgl. Australian Accounting Research Foundation (1999), Absatz 5, S. 6. 181 Vgl. Anhang Interview Allenspach. 182 Vgl. dazu Abschnitt 5.4.

5. SAS 70 80

Abschnitt 5.7.3 betrachtet den ISO 17799 Standard, der in Abschnitt 3.3.4 eingehend besprochen

wurde, und vergleicht ihn mit dem SAS 70 Standard.

5.7.1 Trust Services

Das AICPA definiert Trust Services wie folgt:

„(..) a set of professional assurance and advisory services based on a common framework (that is,

a core set of principle and criteria) to address the risks and opportunities of IT.”183

Gemäss dieser Definition dienen Trust Services zur Zusicherung und Beratung, um Risiken und

Möglichkeiten der IT unter Kontrolle zu bekommen, um einen Nutzen aus diesen zu generieren.

Durch die Zertifizierung, die jährlich zu bestätigen ist, wird dem Unternehmen die Möglichkeit

geboten, den Kunden auf die Sicherheit der eingesetzten Systeme aufmerksam zu machen. Trust

Services bestehen seit Januar 2003 und vereint die beiden Dienstleistungen SysTrust und

WebTrust, die einige Gemeinsamkeiten aufwiesen. Trotz der Vereinigung von SysTrust und

WebTrust zu Trust Services, ist es weitherhin möglich einzelen WebTrust- und SysTrust-Module

separat prüfen zu lassen.184 Nachfolgend werden SysTrust und WebTrust näher erläutert:

SysTrust

SysTrust wurde durch das AICPA und dem kanadischen Pendant dazu, dem CICA, im Jahre

1999 veröffentlicht. Im Jahre 2000 wurde mit der Version 2.0 die zur Zeit aktuellste Version

publiziert. Dieser Service ermöglicht den externen Prüfern eine hinreichende Zusicherung zu

geben, dass das System gemäss SysTrust zuverlässig ist. Unter System definiert AICPA in

diesem Zusammenhang Infrastruktur, Software, Personal, Prozeduren und Daten im Kontext der

Geschäftstätigkeit um ein bestimmtes Ziel zu erreichen.185 Ein zuverlässiges System, system

reliability, beschreibt AICPA als:

183 American Institute of Certified Public Accountants (2003), S. 2. 184 Vgl. Meyer (2004), S. 212. 185 Vgl. American Institute of Certified Public Accountants (2003), S. 4 Fussnote 2.

5. SAS 70 81

„A system that operates without material error, fault or failure during a specified time in a

specified environment.”186

SysTrust definiert vier Prinzipien, die die Zuverlässigkeit des Systems garantieren und

beschreiben sollen. Dazu werden den vier Prinzipien insgesamt 58 Kriterien zugeteilt: 187

Verfügbarkeit: Das System ist für Berechnungen und Benutzung während der gemäss

SLA definierten Zeit verfügbar.

Sicherheit: Das System ist gegen unauthorisierte physische und logische Zugriffe

geschützt.

Integrität: Die Verarbeitung durch das System wird komplett, fehlerfrei, zeitgerecht und

authorisiert durchgeführt.

Wartbarkeit: Das System kann aktualisiert werden, so dass keine Beeinträchtigung der zu

leistenden Aufgaben stattfindet und die Verfügbarkeit, Sicherheit und Integrität des

Systems gewährleistet ist.

Diese Prinzipien können einzeln oder zusammen geprüft werden. Die dazugehörigen Kriterien

sollen sicherstellen, dass Regeln existieren, die geeignet erscheinen, um eine hinreichende

Systemleistung zu sichern.188 Beim SysTrust wird wie beim SAS 70 ein Report erstellt. Dieser

Report beinhaltet folgende Bestandteile: Eine Beschreibung des Systems über die Grenzen

während der Prüfung, eine Zusicherung des Management über die Kontrollen, die dem System

unterliegen und einen Bericht des externen Prüfers, dass das System gemäss den SysTrust

Kriterien geprüft wurde.189

WebTrust

WebTrust wurde im Jahre 1997 durch das AICPA und CICA veröffentlicht. Im Jahre 2000 fand

bisher die letzte Überarbeitung von WebTrust statt, so dass WebTrust nun in der dritten Version

vorliegt. Der grosse Unterschied zu SysTrust besteht darin, dass sich WebTrust nur auf Internet-

186 American Institute of Certified Public Accountants (2005), S. 20. 187 Vgl. American Institute of Certified Public Accountants (2003), S. 4 beschrieben. Die hier verwendeten weiterführenden Informationen sind der Quelle Champlain (2003), S. 84-85 entnommen. 188 Vgl. Meyer (2004), S. 208. 189 Vgl. Boritz / Mackler / McPhie (1999), S. 75.

5. SAS 70 82

basierende Systeme bezieht. WebTrust dient zur Schaffung von Vertrauen im Internet.

WebTrust-Prüfungen sind spezielle IT-System- und Prozessprüfungen im E-Commerce-Umfeld.

Die bei SysTrust beschriebenen vier Prinzipien, haben auch bei WebTrust ihre Gültigkeit. Die

Kriterien definieren sich aus Best Practice Erfahrungen im E-Commerce Bereich. Die Prüfung

der verschiedenen Kriterien ist in einzel prüfbare Module unterteilt. Folgende Themen werden

von den Modulen abgedeckt:190

Datenschutz: Ohne ausdrückliche Genehmigung, dürfen keine Informationen über

Personen gespeichert und gesammelt werden. Somit kann verhindert werden, dass diese

Informationen die Person identifizieren oder identifizierbar machen.

Integrität: Prüfung der Transaktionen auf Richtigkeit und Vollständigkeit.

Datensicherheit: Schutz privater Daten vor unberechtigtem Zugriff durch Dritte. Dies

bedingt eine effiziente Abwehr gegen Eindringungsversuche, Kontrolle der

Verschlüsselung und der Firewall.

Verfügbarkeit: WebTrust definiert einen Katalog von Massnahmen, um die Verfüg-

barkeit eines IT-Systems im E-Commerce zu sichern.

Vertraulichkeit: WebTrust definiert auch für die Vertraulichkeit einen Katalog von

Massnahmen, welche die Vertraulichkeit der Daten im Geschäftsverkehr zwischen

Unternehmen im Intranet oder Internet gewährleisten sollen.

Eine WebTrust Prüfung zu bestehen bedingt, dass alle Grundsätze und Kriterien eingehalten

werden. Ein externer Prüfer muss dies durch seine Bestätigung anerkennen. Mit Bestehen der

Prüfung erlangt das Unternehmen keinen Report, wie es beim SAS 70 oder SysTrust der Fall ist,

sondern es erhält ein Zertifikat. Dieses Zertifikat wird auf der Webseite publiziert und muss alle

sechs Monate erneuert werden.

5.7.2 Unterschiede von SAS 70 zu Trust Services

Dieser Abschnitt hat zum Ziel, die Unterschiede zwischen SAS 70 und den Trust Services heraus

zu streichen. Hierzu werden die Trust Services mit dem Typ II des SAS 70 Audit verglichen. Der

190 Vgl. Messier (2003), S. 744.

5. SAS 70 83

Grund hierfür ist, dass der SAS 70 Typ I nicht vergleichbar zu den Trust Services ist, da beim

Typ I keine Tests vorgenommen werden.

Abbildung 18 verdeutlicht die Unterschiede zwischen den Trust Services und SAS 70:

5. SAS 70 84

Charakteristika Typ II SAS 70 Audit Trust Services

Zweck des Report Unterstützt den externen

Prüfer mit Informationen über

die Kontrollen des Service

Anbieters.

Sichert zu, dass das Unter-

nehmen eines oder mehrere

Trust Service Prinzipien und

die Kriterien erfüllt.

Gegenstand der Bericht-

erstattung

Kontrollen des Service An-

bieters, die einen Einfluss auf

die Jahresrechung des Out-

sourcer haben können.

Interne Kontrolle bzw. IC die

mit finanziellen oder nicht

finanziellen Systemen in Be-

ziehung stehen.

Eigenschaft des Report Liefert eine Beschreibung der

Kontrollen, die Angemessen-

heit der Kontrollen und eine

Aussage über die Effektivität

der Kontrollen

Sichert zu, dass die

Kontrollen des Unterneh-

mens über ein definiertes

System die Trust Service

Kriterien befriedigen und die

Prinzipien untersucht wurden.

Adressate des Report Service Anbieter, Kunden des

Service Anbieters und deren

externe Prüfgesellschaften,

potentielle Kunden, Ge-

schäftspartner und Behörden.

Beliebige Anteilshaber des

Unternehmen, wie z.B.

Management, Kunden und

Business Partner.

Spezifische Kontrollziele

und –aktivitäten

Kontrollziele und –aktivitäten

sind in SAS 70 nicht definiert,

da SAS 70 keine Best Practice

Prüfung ist.

Prinzipien und Kriterien sind

durch das AICPA definiert.

Diese sind für das Bestehen

der Prüfung unerlässlich.

Abbildung 18: Unterschiede zwischen SAS 70 und Trust Services191

191 In Anlehnung an SAS 70 Solutions (2005a), o.S.

5. SAS 70 85

5.7.3 Unterschiede von SAS 70 zu ISO 9000192 bzw. ISO 17799

Im Zusammenhang einer SAS 70 Prüfung kann angenommen werden, dass die ISO-Zertifi-

zierungen eine Alternative zum SAS 70 bieten. Insbesondere ISO 17799 wird dabei als

hinreichende Alternative verwendet.193 Beginnen werden die Ausführungen mit dem ISO 9000

Standard. Dieser wurde in dieser Arbeit nicht eingehend vorgestellt. ISO 9000 ist eine

Ansammlung von Qualitätsstandards, die bzgl. der Systeme eines Unternehmens zu gelten

haben. ISO 9000 vereint die Standards: ISO 9000, 9001 und 9004. ISO 9001 vereinigt wiederum

seit dem Jahre 2000 die früheren ISO Standard 9001, 9002 und 9003. Seit dieser Vereinigung

gilt ISO 9001 als der Standard in der ISO 9000 „Familie“, der eine Zertifizierung beim Service

Anbieter ermöglicht. Somit gilt der ISO 9001 als eine mögliche Alternative zu einem SAS 70

Report. Tabellarisch werden in Abbildung 19 die wichtigsten Unterschiede aufgezeigt:

Vergleichsgebiete SAS 70 ISO 9000 bzw. ISO 9001

Durchführung der Prü-

fungen

Durch ein Certified Public

Accounting Unternehmen.

Jegliches Unternehmen, das

durch ISO authorisiert wurde

Zertifizierungen

durchzuführen.

Resultat der Prüfung Detaillierter Report. ISO-Zertifizierung.

Was steht im Fokus der

Prüfung?

Die ganze interne Kontrolle

bzw. IC.

Qualitätsmangementprozesse.

Abbildung 19: Unterschiede SAS 70 zu ISO 9000194

Abbildung 19 zeigt auf, dass der Umfang einer ISO 9000 auf die Qualitätsfragen beschränkt ist

und demnach einen geringeren Umfang als SAS 70 aufweist. Im Gegensatz zu einem SAS 70

Report wird bei ISO 9000 eine Zertifizierung erteilt und somit werden keine detaillierten

192 Komplett heisst der Standard ISO 9000:2000. 2000 soll hinweisen, dass der Standard im Jahre 2000 überarbeitet wurde. Für die weiteren Ausführungen, wird der Zusatz 2000 weggelassen. 193 Vgl. Anhang Interview Pfister. 194 In Anlehnung an SAS 70 (2005b), o.S.

5. SAS 70 86

Kontrollen aufgezeigt. Gemäss Section 404 des SOX ist damit keine hinreichende

Dokumentation dargestellt, um SOX-konform zu sein. Im Falle eines Outsourcing kann das

Zertifikat nicht als Sicherheit für den Abschlussprüfer des Outsourcer dienen, was eine

zusätzliche Prüfung beim Service Anbieter zur Folge hat.

Der in Abschnitt 3.3.4 vorgestellte ISO 17799 Standard hat den Fokus auf die IT-Security gelegt.

Es ist aber kein Standard, der wie SAS 70 das Kontrollwesen des Service Anbieters offenlegt,

sondern es beschreibt die Prozesse für die Umsetzung der IT-Security Richtlinien im

Unternehmen. Aus diesem Grund erfüllt ISO 17799 die Anforderungen der Section 404 des SOX

nicht. Ein weiterer Unterschied besteht darin, dass ISO 17799 ein Standard ist, der gemäss Best

Practice Ansätzen entstanden und auf andere Unternehmen übertragbar ist und somit die Prüfung

teilweise standardisiert ist. SAS 70 ist demgegenüber keine best practice Lösung und die

Prüfungen müssen an die einzelnen Kunden laufend angepasst werden.

Obwohl ISO 17799 keine Alternative zu SAS 70 darstellt, kann ein ISO 17799 Zertifikat eine

gute Grundlage für die SAS 70 Prüfung darstellen. Da der ISO 17799 Standard dokumentiert ist,

kann eine richtige Implementierung des Standards im Unternehmen eine gute Grundlage für eine

SAS 70 Prüfung im IT-Security Bereich darstellen. Durch die Prozessdokumentationen können

auch die Kontrollen durch die externen Prüfer schneller gefunden und beschrieben werden und

somit ist eine SAS 70 Prüfung effizienter zu bewerkstelligen.195

5.8 Zusammenfassung

Mit SAS 70 wurde eine Prüfmethode vorgestellt, die die IC des Service Anbieters durch einen

externen Prüfer begutachten lässt und danach einen Report für die verschiedenen Outsourcer zur

Verfügung stellt. Durch dieses Vorgehen wurden einige Vorteile, insbesondere bei der

Einsparung von personellen und finanziellen Ressourcen, vorgestellt. In diesem Kapitel wurde

auf die Gründe des vermehrten Einsatz des SAS 70 Bezug genommen und in diesem

Zusammenhang wurde der SOX vorgestellt. Dieses amerikanische Gesetz, das die Investoren vor

falschen finanzieller Berichterstattung durch die Unternehmen schützen soll, akzeptiert das SAS

70 als Möglichkeit die IC des Service Anbieters beschreiben und testen zu lassen. SOX und auch

SAS 70 betrifft zur Zeit nur die in der amerikanischen Börse kotierten Unternehmen. Trotzdem

existieren neben dem SAS 70 international ähnliche Reports, wie z.B. das schweizerische PS

195 Vgl. Anhang Interview Dambacher.

5. SAS 70 87

402, die einen ähnlichen Aufbau wie der SAS 70 besitzen und in diesem Kapitel eingehen

beschrieben wurden. Im letzten Teil dieser Arbeit wurde SAS 70 mit den Trust Services und den

ISO-Standards verglichen und dabei wurde deutlich, dass sich SAS 70 insbesondere durch das

Offenlegen des Kontrollwesens des Service Anbieters von den anderen Zertifizierungen bzw.

Standards unterscheidet.

In diesem Kapitel wurden auch die Schwächen des SAS 70 eingehend besprochen. Eines dieser

Schwächen beinhaltet die nicht weiter vorgegebene Prüfttiefe und -umfang. Dieses Kapitel gab

eine theoretische Einführung in die SAS 70-Thematik. Mit dem nachfolgenden Kapitel wird der

Schwäche des erhöhten Freiheitsgrads Abhilfe geleistet, indem ein möglicher SAS 70

Prüfprozess vorgestellt wird.

6. SAS 70 Prüfprozessansatz mit Fokus auf die IT-Security 88

6 SAS 70 Prüfprozessansatz mit Fokus auf die IT-Security

Nachfolgend wird ein mögliches Prüfkonzept für eine Prüfung gemäss SAS 70 vorgestellt. Bevor

das Prüfkonzept beschrieben wird, wird ein allgemeiner Überblick über die Thematik des

Prüfprozesses gegeben. Danach werden die Besonderheiten einer IT-Prüfung vorgestellt. Da

SAS 70 von den Unternehmen oftmals wegen der SOX-Anerkennung gewählt wird, wird in

Abschnitt 6.3 auf die Besonderheiten des Prüfprozesses gemäss den SOX-Vorschriften

eingegangen. Mit diesen technischen Informationen der Prüfung kann das Prüfkonzept

vorgestellt werden. Dabei wird das SAS 70 Prüfkonzept so aufgebaut, dass der Fokus auf der

Thematik der IT-Security gelegt wird.

6.1 Überblick Prüfprozess

Gemäss dem Handbuch der Wirtschaftsprüfung (HWP) hat ein Prüfer (Revisor)196, der

unabhängig d.h. keine Weisungsbefugnisse gegenüber der geprüften Gesellschaft haben darf, die

Aufgabe, betriebswirtschaftliche Prüfungen, inbesondere Abschlussprüfungen, von Unternehmen

und anderen wirtschaftlichen Einheiten durchzuführen und darüber Bericht zu erstatten.197 Um

sich ein Urteil über das Unternehmen bilden zu können, wird eine Prüfung durchgeführt. Dabei

zielt die Prüfung inbesondere auf die Überprüfung der IC ab. Das HWP beschreibt die Prüfung

als:

„(..) eine Tätigkeit der Informationsgewinnung und Urteilsbildung. Kern dieser Tätigkeit ist ein

Vergleich, nämlich der Vergleich des Ist-Zusandes mit einer Norm, dem Soll-Zustand.“198

Weiter sei festgehalten, dass ein Prüfungsbericht das Endergebnis eines vorgängigen

Prüfungsprozesses ist.199 Wenn man also von der "Prüfung" spricht, impliziert man oft einen

Prüfungsprozess. Eine Prüfung ist demnach ein Prozess, den man, wie Abbildung 20 zeigt, in

vier Phasen einteilen kann.

196 Als Synonym zu Prüfer bzw. Revisor kann Wirtschaftsprüfer verwendet werden Vgl. Treuhandkammer (1998), S. 4. 197 Vgl. Treuhandkammer (1998), S.4. 198 Treuhandkammer (1998), S. 4. 199 Vgl. Marten / Quick / Ruhnke (2003), S. 238-242.


Abbildung 20: Die vier Phasen eines Prüfprozesses200

Phase I: 201

Die Prüfungsvorbereitung umfasst als wesentlichste Aufgaben die Definition des Prüfauftrages

und die Beschaffung von Informationen über das zu prüfende Unternehmen.

Phase II:202

Bei der Prüfungsplanung handelt es sich nicht um eine einmalige Beschreibung der

Prüfungshandlung, sondern sie stellt einen Prozess dar, welcher laufend an die sich ändernden

Umstände angepasst werden muss. Die Prüfungsplanung basiert auf der in Phase I formulierten

Prüfauftragsdefinition und den zu beschaffenen Informationen. Aufgrund der gewonnen

Eindrücke wird mittels einer Risikobeurteilung die Definition der Schlüsselprüffelder

vorgenommen. Sind diese identifiziert, kann die Detailplanung stattfinden, bei der die

Festlegung der einzelnen Prüfmethoden und –programme, die Zusammensetzung des Prüfteams

sowie der Zeitpunkt und die Dauer der Prüfung im Vordergrund stehen.

200 In Anlehnung an Treuhandkammer (1998), S. 111. 201 Vgl. Treuhandkammer (1998), S. 112 - 117. 202 Vgl. Treuhandkammer (1998), S. 118 – 143.

Phase I Prüfungsvorbereitung

Phase II

Phase III

Phase IV

Prüfungsplanung

Prüfungsdurchführung

Abschluss der Prüfung


Phase III:203

Bei dieser Phase wird der Prüfplan umgesetzt. Aktivitäten, die hier anfallen sind z.B. die Prüfung

der internen Kontrollen, Prüfung der Informatik, Inventur oder Durchsicht von Arbeitspapieren

anderer Prüfer.

Phase IV:

Nach Beendigung der Prüfungsdurchführung werden die Prüfungsdokumentationen

durchgeschaut und offene Punkte behandelt. Mittels dem Prüfbericht, welcher dem geprüften

Unternehmen bzw. der Generalversammlung als Auftragsgeber geliefert wird, wird der

Prüfauftrag abgeschlossen.204

6.2 Überblick IT-Prüfung

Durch den im vorangegangenen Abschnitt vorgestellten Prüfprozess wurde ein allgemein

gültiges Vorgehen beschrieben, wie eine Prüfung aussehen kann. Dieser Abschnitt geht nun

spezifisch auf die Besonderheiten der Prüfung von IT-Systemen ein.

Im Unterschied zur normalen Wirtschaftsprüfung geht es in der IT-Prüfung weniger um

buchhalterische Korrektheit, sondern um die Überprüfung, ob die Informationen, die durch ein

IT-System verarbeitet werden, korrekt und komplett bearbeitet werden.205 Um die richtige

Verarbeitung zu gewährleisten, werden verschiedene Kontrollen in den Prozessen implementiert,

die diese Sicherheit gewährleisten sollen. Man unterscheidet grob zwei Arten von Kontrollen:

Generelle Kontrollen und Applikationskontrollen.

Generelle Kontrollen betreffen alle Aspekte der IT. Die Rolle, die sie inne haben, ist das

Sicherstellen, dass die eingesetzten Applikationen fehlerfrei laufen können. Unter Generelle

Kontrollen lassen sich drei Unterkontrollen definieren:206

Entwicklungskontrollen: Diese sollen sicherstellen, dass die Applikationen mit den

richtigen Funktionsweisen implementiert und die Daten durch die Applikation richtig

verarbeitet werden.

203 Vgl. Treuhandkammer (1998), S. 144 – 153. 204 Vgl. Treuhandkammer (1998), S. 154 – 161. 205 Vgl. Gray / Manson (2000), S. 244. 206 Vgl. Gray / Manson (2000), S. 246 – 256.


Organisatorische Kontrollen: Sie dienen zur physischen und auch organisatorischen

Sicherung der Applikationen. Erreicht wird dies durch richtiges Aufbewahren und

Einsetzen der Applikationen. Ein Beispiel für eine Organisatorische Kontrolle ist die

Funktionstrennung von Programmierung und Bedienung.

Sicherheitskontrollen: Die Sicherheitskontrollen beziehen sich auf die Hard- und

Software. Hierbei geht es vorwiegend um physischen Schutz der Bestandteile und vor

Zugriffsschutz vor unauthorisierten Verwendung einer Applikation.

Im Unterschied dazu sind Applikationskontrollen spezifisch für jede einzelne Applikation

implementiert und sollen eine vernünftige Sicherheit bieten, dass die Eingabe, Verarbeitung und

Ausgabe von Daten richtig ausgeführt werden.207

Abbildung 21 illustriert die Beziehung zwischen Generellen Kontrollen und Applikations-

kontrollen.

Applikation # 1

Eingabe-kontrolle

Prozess-kontrolle

Ausgabe-kontrolle

Applikation # 2

Eingabe-kontrolle

Prozess-kontrolle

Ausgabe-kontrolle

APPLIKATIONSKONTROLLEN

GENERELLE KONTROLLEN

Entwicklungskontrollen Organisatorische Kontrollen Sicherheitskontrollen

Kontrollaktivitäten

Abbildung 21: Beziehung Generellen Kontrollen zu Applikationskontrollen

207 Vgl. Committee of Sponsoring Organizations of the Treadway Commission (1994), S. 54.


Abbildung 21 zeigt auf, dass den Generellen Kontrollen eine wichtige Position eingeräumt wird.

Sie stellen die Basis für die Applikationskontrollen dar. Funktionieren die Generellen Kontrollen

nicht in dem Masse wie sie sollten, so offenbaren diese Schwächen in den Applikations-

kontrollen.

Beide Kontrollarten beziehen sich rein auf die IT und sind Bestandteil der allgemeinen

Steuerungs- und Kontrollaktivitäten eines Unternehmens, um eine angemessene Sicherheit der

Unternehmenszielerreichung gewährleisten zu können. In dieser Arbeit wurden die allgemeinen

Steuerungs- und Kontrollaktivitäten als Bestandteil des COSO-Framework erläutert.208

6.3 Prüfungsvorgehen zur Erfüllung der Sarbanes-Oxley Act Anforderungen

SOX zielt auf die Richtigkeit der finanziellen Berichterstattung ab.209 Aus diesem Grund stehen

dabei alle Prozesse im Prüffokus, die direkt oder indirekt einen Einfluss auf die finanzielle

Berichterstattung haben. Dabei geht es wie bei einer „normalen” Prüfung, um die Überprüfung

der IC. Abbildung 22 zeigt ein Beispiel eines Warenverkaufsprozesses auf, der einen Einfluss

auf die finanzielle Berichterstattung hat.

208 Vgl. Abschnitt 3.1.2. 209 Vgl. Abschnitt 5.5.1.


Warenverkaufsprozess

Verbuchung im Buchhaltungssystem

durch Buchhalter

Prüfung der Buchung durch

Finanzchef

Ausbuchung der Ware aus dem

Warenlager und Buchung des

Ertrags

Lieferung der Ware

Bes

tellu

ng d

es K

unde

n

• Debitorensystem verbucht nach Einstandpreis

• Falsche Verknüpfung des Warenlagersystems mit dem Buchhaltungssystem

• Akzeptieren der falschen Buchung

• Falsche Verbuchung durch den Buchhalter (absichtlich/unabsichtlich)• Unkorrekte Verbuchung durch das System

Mögliche Risiken

DebitorensystemWarenlagersystem

BuchhaltungssytemWarenlagersystem

BuchhaltungssytemBuchhaltungssytemInvolvierte IT-Sytsteme

• Kontrolle durch Debitorenbuchhalter anhand des Eintrags im Buchhaltungssystem.

• Systemmeldung, wenn Verkaufspreis des Warenlagersystems ungleich dem Buchungsverkaufswert ist

• Prüfung der Buchung mit dem Originalbeleg• Visierung (mit Unterschrift zu bestätigen)

• Keine definitive Buchung möglich. Sie muss zuerst durch Finanzchef visiert werden.

Mögliche Kontrollen

Abbildung 22: Verbuchung eines Warenverkaufs inkl. möglicher Risiken und Kontrollen

Damit der in Abbildung 22 gezeigte Warenverkaufsprozess richtig in der Jahresrechnung

erscheint, werden für jeden Prozessschritt mögliche Kontrollen definiert, die die auftretenden

Risiken zu minimieren versuchen. Der Prüfer muss nun diese Kontrollen auf deren Effektivität

hin überprüfen. SOX bzw. das PCAOB gibt dabei vor, welche Prüfschritte unternommen werden

müssen, um diese Kontrollen zu überprüfen: 210

1. Prüfplanung

2. Evaluierung der Vorgehensweise des Managements

3. Verstehen der IC

4. Testen und Evaluierung der Design-Effektivität der IC

5. Testen und Evaluierung der Funktionsweise der IC

6. Meinungsbildung über die IC.

210 Vgl. Public Company Accounting Oversight Board (2005), S. 155.


Mit der folgenden Ausführung im PCAOB Auditing Standard No. 2 wird hervorgehoben, dass

die IT-Kontrollen einen wichtigen Teil des Prüffokus ausmachen und dabei stehen insbesondere

die Generellen Kontrollen im Fokus:

„The auditor must obtain an understanding of, and evaluate, management's process for assessing

the effectiveness of the company's internal control over financial reporting. When obtaining the

understanding, the auditor should determine whether management has addressed the following

elements:

Determining which controls should be tested, including controls over all relevant

assertions related to all significant accounts and disclosures in the financial statements.

Generally, such controls include:

- (..)

- Controls including information technology general controls, on which other controls are

dependent.”211 212

Dieser Abschnitt diente zur Veranschaulichung wie gemäss SOX geprüft werden muss, damit die

SOX-Konformität erreicht werden kann. Der nachfolgendene SAS 70 Prüfprozess beschränkt

sich jedoch nicht nur allein auf die finanziellen Aspekte, sondern es wird eine allgemeine

Aussage über die IC gemacht. Im nachfolgenden Prüfprozess werden aber die fünf Prüfschritte,

wie auch der Prüffokus der Generellen Kontrollen berücksichtigt.

211 Herv. d. Verf. 212 Public Company Accounting Oversight Board (2005), S. 158 – 159.


6.4 Der SAS 70 IT-Security-Prüfprozess

Eine SAS 70 Prüfung ist keine standardisierte Prüfung. Aus diesem Grund wird nachfolgend ein

Vorschlag ausgearbeitet, wie eine SAS 70 Prüfung im Bereich der IT-Security aussehen könnte.

Die Ausführungen entstammen aus den geführten Experteninterviews und der in dieser Arbeit

bearbeiteten Theorie.

Abbildung 23 zeigt einen Überblick über das Grobkonzept. Wie in Kapitel 5 gezeigt, existieren

zwei Typen des SAS 70 Report. Das vorliegende Grobkonzept integriert beide Typen.


Abbildung 23: Konzeptüberblick SAS 70 Prüfprozess

Vorbereitung und Ziel

Risikobeurteilung und

Prüffungsplanung

Identifizierung

signifikanter

Kontrollen

Identifizierung der

Mängel

Dokumentation der

Kontrollen

Planung der

Evaluation der

Kontrollen

Durchführung der

Tests

Identifizierung der

Mängel

Dokumentation

SAS 70 T

yp I

SAS 70 T

yp II


6.4.1 Vorbemerkungen

Die Vorgehensweise bei der Prüfung orientiert sich am vorgeschlagenen Prüfprozess der

Treuhandkammer.213 Ausserdem werden die in Abschnitt 6.3 beschriebenen SOX-Prüfschritte

berücksichtigt.

Eine Schwierigkeit der SAS 70 Prüfung besteht darin, dass keine Angaben über die Prüftiefe

gemacht wird.214 Für den folgenden Prozess gilt, dass das Vorhandensein von Konzepten im

Prüffokus liegt und keine tiefen technischen Prüfungen vorgenommen werden, wie es

normalerweise bei IT-Security-Prüfungen der Fall ist. Bei der Konzeptprüfung spielt das „was“,

d.h. welche Kontrollen wurden implementiert, als das „wie“ eine Rolle. Das „wie“ wird dabei

bei der SAS 70 Typ II Prüfung, bei der die Effektivität der Kontrollen getestet wird,

stichprobenartig betrachtet.

Die folgendene IT-Security-Prüfung orientiert sich an der IT-Security-Definition, wie sie in

Abschnitt 3.3.1 gegeben wurde. Das bedeutet, dass die IT-Security hier nicht nur aus dem

technischen Blickwinkel aus betrachtet wird, sondern dass aufgrund der Konzeptprüfung werden

auch betriebliche bzw. organisatorische Begebenheiten im Prüffokus liegen.

Die Basis für eine erfolgreiche SAS 70 Prüfung besteht darin, dass die Kontrollziele und

Kontrollen beim geprüften Unternehmen - im folgenden Prüfprozess ist dies der Service

Anbieter - schriftlich dokumentiert sind.215 Ist keine Dokumentation vorhanden, so muss zuerst

durch den Service Anbieter eine Dokumentation der eigenen Kontrollen vorgenommen werden.

Erst wenn dies vorgenommen wurde, kann mit der Prüfung begonnen werden.

213 Vgl. Abschnitt 6.1. 214 Vgl. Abschnitt 5.3.2. 215 Vgl. Anforderungen Section 302 und 404 des SOX in Abschnitt 5.5.1.


6.4.2 Vorbereitung

I. Vorbereitung und Ziel

Unter-Prozesse:

1. Prüfauftragsdefinition: Zielbereiche definieren

Aufgrund der Aufgabenstellung ist der Bereich definiert: IT-Security

2. Informationsbeschaffung über Service Anbieter

3. Prüfungsvorbereitung

o Unterlagen bzgl. Risikobeurteilung, Prüfung IC, Reglemente

o Interviewpartner reservieren

Beschreibung:

Die externe Prüfgesellschaft wird durch den Service Anbieter beauftragt eine SAS 70 Prüfung

durchzuführen. Dieser Wunsch kann durch die verschiedenen Kunden des Service Anbieters

geäussert werden oder der Service Anbieter möchte seinen Kunden respektive den potentiellen

Kunden diese zusätzliche Leistung bieten. Zuallererst muss zwischen dem Service Anbieter und

der externen Prüfgesellschaft der Bereich bzw. die Bereiche, die im Prüfumfang liegen sollen,

vertraglich fixiert werden. Oftmals werden nicht einzelne Bereiche einer SAS 70 Prüfung

unterzogen, sondern es werden vielmehr mehrere gleichzeitig überprüft. Dieser Prüfprozess

Ziel: Vereinbarung der Prüfziele bzw. Prüfbereiche mit dem Service Anbieter (Kunde) und

die notwendigen Informationen über den Kunden zur Prüfdurchführung sind beisammen.

Involvierte Parteien:

Prüfgesellschaft

Service Anbieter

Outsourcing-Kunden des Service Anbieters


beschränkt sich auf die Thematik der IT-Security und demnach wird nur ein Bereich im

Prüffokus liegen.

Nachdem der Prüfauftrag und die Bereiche klar definiert wurden, liegt es an der Prüfgesellschaft

sich genügend Informationen über den Service Anbieter zu beschaffen. Es geht in diesem

Zeitpunkt weniger um Detailinformationen über den Service Anbieter. Die Informationen sollen

der Prüfgesellschaft einen Überblick geben, damit eine „sach- und fachgerechte Prüfung“216

plan- und durchführbar ist. Es geht in dieser Phase darum, dass die Prüfgesellschaft die

Geschäftstätigkeit des Service Anbieters verinnerlichen kann („Understanding the business“).

Das HWP unterscheidet zwischen externen und internen Informationen. Externe Informationen

sind jene über die volkswirtschaftlichen und politischen Rahmenbedingungen, die das

Unternehmen tangieren können. Diese Faktoren beeinflussen durch ihre laufende Veränderung,

dass die Geschäftstätigkeit des Service Anbieter einer ständigen Wandlung untersteht. Zu den

relevanten externen Informationen können unter anderem folgenden Aspekte von Bedeutung

sein:

Berichte über neue Technologien und Anwendungstechniken

Technische Fortschritte

Standort des Unternehmens

Politische Rahmenbedingungen

Zu den internen Informationen zählen Informationen betreffend der Geschäftstätigkeit und die

interne Organisation des Unternehmens, damit der Prüfer Risiken frühzeitig zu erkennen und bei

seiner Prüftätigkeit angemessen zu berücksichtigen weiss. Folgende Aspekte sind zu beachten:

217

Kurzbeschreibung des Unternehmens

Umsatz

Leistungen und Produkte

Informatikumfeld

Ablauforganisation und Interne Kontrolle

SLA

216 Vgl. Treuhandkammer (1998), S. 112. 217 Vgl. Treuhandkammer (1998), S. 114.


Führungsinformationen

Jahresabschlüsse, Geschäfts- und Prüfungsberichte der Vergangenheit.

Durch die gesammelten Informationen, die aus externen Quellen und direkt vom Service

Anbieter stammen, kann als nächster Schritt die Prüfungsvorbereitung folgen. Bei der

Prüfungsvorbereitung wird im Unterschied zur Informationssammlung spezifischer auf den

Prüfauftrag eingegangen. Es werden Unterlagen zusammengetragen, die für die weitere SAS 70

Prüfung der IT-Security von Bedeutung sind: 218

Dokumentationen über IC des Service Anbieters

Für die Prüfung der IC notwendigen Unterlagen, wie z.B. Organisations- und Ablauf-

pläne

Liste aller IT-Systeme inklusive Zuordnung zu den verschiedenen Kunden

Stellenbeschreibungen der IT-Fachpersonen, die in diesen Finanzprozessen involviert

sind

IT-Security-Weisungen

Sicherheitskonzepte mit den einzelnen Kunden

SLA mit den verschiedenen Kunden für den IT-Security Bereich

Die vom Service Anbieter selbst verwendeten Kontrollunterlagen einschliesslich der

Kontrollanweisungen.

Für eine effizientere Bearbeitung der Dokumentationen ist es von Vorteil, wenn zusätzlich

Interviewpartner seitens des Service Anbieters gesucht werden, die während der Prüfungsdauer

zur Verfügung stehen. Deshalb müssen, so weit es geht, Termine mit folgenden Personen fixiert

werden:

218 In Anlehnung an Treuhandkammer (1998), S. 115 mit Ergänzungen in Bezug auf die IT-Security.


Person Grund

Management des Service Anbieters Steht für alle Fragestellungen zur Verfügung.

Insbesondere Management-Fragestellungen wie z.B.

organisatorische Fragen. Kann bei detaillierten

Fragen die nachfolgenden Personen zu Hilfe ziehen.

IT-Security-Verantwortlicher und

Systemadministrator

Für technische Fragestellungen.

Prozess-Verantwortlicher219:

IT-Security Management

Steht für Fragen rund um den Prozess zu Verfügung.

Kundenverantwortlicher Steht für Fragen zur Verfügung, die speziell auf einen

Kunden zugeschnitten und weniger technisch sind.

Gebäude-Verantwortlicher Steht für Fragestellungen rund um die physische

Sicherheit zur Verfügung.

Rechenzentrumsleiter der im Fokus

stehenden Lokationen

Wird bei Fragestellungen rund um die physische

Sicherheit der Rechenzentren gebraucht.

Abbildung 24: Auswahl Interviewpartner für SAS 70 Prüfung

219 Gemäss ITIL haben alle Prozesse eines Unternehmens einen Verantwortlichen (sog. Owner). Falls der Service Anbieter ITIL nicht anwendet, so wird anstelle des Prozessverantwortlichen das Management des Service Anbieters befragt.


6.4.3 Planung

II. Risikobeurteilung und Prüfungsplanung

Unter-Prozesse:

1. Risikoidentifizierung auf Basis der ISO 17799 Themen

o Risikenidentifizierung durch Service Anbieter

Self Risk Assessment

o Risikenidentifizierung durch Prüfgesellschaft

Risiken aufgrund Unterlagen und Beobachtung

2. Risikoklassifizierung

3. Prüfplanung

Beschreibung:

Für die Prüfungsplanung müssen zuerst die Risiken im IT-Security Bereich beim Service

Anbieter identifiziert und bewertet werden, die die Zielerreichung, d.h. die Bewahrung der

Integrität, Vertraulichkeit und Vollständigkeit der Daten und Systeme, beeinträchtigen können.

Die Risikoidentifizierung kann als Kernaktivität des ganzen Prüfprozesses betrachtet werden.

Für die Identifizierung der IT-Security-Risiken nimmt man die in Abschnitt 3.3.4 vorgestellten

ISO 17799 Themen zur Hilfe. Aufgrund der weiten Verbreitung des ISO-Standards kann davon

ausgegangen werden, dass mit den ISO-Themen alle wichtigen Aspekte betreffend der IT-

Security abgedeckt sind.

Ziel: Ermittlung der wichtigsten Risiken und Klassifizierung betreffend der Wichtigkeit.

Aufgrund der Risikoanalyse kann der detaillierte Prüfplan aufgestellt werden.


Prüfgesellschaft

Service Anbieter: Management, Interne Revision und IT-Security-Leiter


Aufgrund der Ausdehung der IT-Security-Definition kommen alle ISO 17799 Gebiete für den

Prüffokus in Frage. Diese Themen werden nun dazu verwendet, den zu bearbeitenden

Risikokatalog systematisch zu gliedern. Zu jedem der zehn Themen von ISO 17799 werden

Risiken identifiziert. Der externe Prüfer kann die Risiken anhand Beobachtungen und den in der

vorherigen Phase gewonnen Informationen identifizieren. Um eine zusätzliche Sicht bezüglich

den Risiken zu erhalten, kann auch der Service Anbieter ein sogenanntes Self Risk

Assessment220 (SRA) durchführen. Der Service Anbieter wird damit selber in die Verantwortung

genommen, Risiken zu identifizieren, die die Zielerreichung der IT-Security beinträchtigen

können. Mit dieser Vorgehensweise erhält die externe Prüfgesellschaft eine ganzheitliche Sicht

über die potentiellen Risiken. Abbildung 25 zeigt einen möglichen Prozess auf, wie der Ablauf

der Risikoidentifizierung vorgehen könnte. Dabei wird die Struktur der ISO 17799 verwendet

und zu jedem Thema werden die Risiken identifiziert, die auftreten können. Insgesamt werden

vier Phasen durchlaufen, indem jeweils zweimal der Service Anbieter und die Prüfgesellschaft

separat die Risiken identifizieren bzw. bewerten. Die Bewertung basiert auf der subjektiven

Vergabe je einer Note für die Eintrittswahrscheinlichkeit und der Auswirkung eines Risikos. Die

Benotung erfolgt nach dem Masstab von 1 (niedrig) bis 5 (hoch). Die Bewertungen werden

zusammengetragen und dabei wird der Schnitt dieser Bewertungen für jedes einzelne Risiko mit

der Bewertung der Gegenpartei addiert und durch zwei dividiert. Somit erhält man eine

Gesamtdurchschnittsbewertung. Diese gibt nun Auskunft darüber, ob das vorliegende Risiko

weiter betrachtet werden muss, d.h. als wesentlich221 betrachtet wird, und dabei im Prüffokus

liegt oder ob es vernachlässigt werden kann. Die Risiken, die im roten Bereich sind, d.h. die eine

Gesamtdurchnittsbewertung von mindestens „4“ besitzen, gehören weiterhin zum Prüffokus.

Trotz dieser kollaborativen Vorgehensweise kann der Prüfer zusätzliche Risiken, die nach

seinem Ermessen weiterhin im Prüffokus liegen sollten, aufnehmen. Der Prüfer muss

schlussendlich seine Beurteilung über den Service Anbieter bzw. über dessen IC abgeben, was

ihn ermächtigt selber Risiken zu bestimmen. Mittels der Zusammenarbeit in der

Risikoidentifizierung kann sich der externe Prüfer auch davor schützen, dass interne und damit

Service Anbieter-spezifsche Risiken, an die man nicht gedacht hat, nicht vergessen gehen.

220 Self Risk Assessment ist kein aus der Literatur entstammender Begriff. Der Gedanke basiert auf der Idee des Control Self Assessment (CSA). CSA ist eine Methode, welche ermöglicht, dass das Management bzw. die Mitarbeiter eines Unternehmens sich selber Gedanken über wichtige Geschäftsziele, Risiken und IC-Design machen. Vgl. The Institute of Internal Auditors (o.J.), S.3. 221 Das Wesentlichkeitsprinzip besagt, dass nur die Sachverhalte betrachtet werden, die aufgrund ihrer Grössenordnung einen Einfluss auf die Geschäftstätigkeit haben. Das Weglassen von wesentlichen Elementen kann zu einer fehlerhaften Darstellung führen und damit fehlerhafte Entscheidungen hervorrufen. Vgl. Treuhandkammer (1998), S. 207.


Service Anbieter Prüfgesellschaft

I: Separate Risiko-identifizierung. Die Gliederung erfolgt gemäss den zehn ISO 17799 Themen

Risikoidentifizierung Service Anbieter nach ISO 17799

Themen

Risikoidentifizierung Prüfgesellschaftnach ISO 17799

Themen

Sammlung der Risiken

II: Sammlung aller gefundenen Risiken geordnet nach den ISO 17799 Themen

Bewertung der Risiken durch

Service Anbieter

Bewertung der Risiken durch

Prüfgesellschaft

III: Bewertung der einzelnen Risiken nach Eintritts-wahrscheinlichkeit und Auswirkung (Skala: 1 (niedrig) – 5 (hoch) )

IV: Die Durch-schnittsnoten der vorherigen Phase werden nun gesammelt und es wird nochmals der Durchschnitt genommen, um einen Gesamtschnitt zu erhalten. Erreicht ein Risiko einen Gesamtschnitt von mind. 4, so gehört es zum weiteren Prüffokus. Die restlichen Risiken, die unter einer 4 haben, werden nicht weiter untersucht.

Abbildung 25: Vorschlag für den Prozess zur Risikoidentifizierung


Die Identifizierung der wesentlichsten Risiken ergeben die Schlüsselprüffelder, die den

Schwerpunkt der Prüftätigkeiten des Prüfers bilden. Somit kann er sich ein Bild über den

Prüfumfang machen. Aufgrund dessen kann die Prüfplanung mit der zeitlichen und personellen

Planung erfolgen. Weiter muss auch die Prüfmethode festgelegt werden. Üblicherweise werden

verfahrensorientierte Prüfungen vorgenommen, um die IC zu überprüfen.222 Dabei sind in der

Planung insbesondere folgende Phasen zu berücksichten:223

Aufnahme der IC (Ist-Aufnahme) Phase III

Beurteilung der IC (Sind genügend Kontrollen vorgesehen?) Phase IV

Prüfung der Einhaltung (Soll-Ist-Vergleich) Phase VII

6.4.4 Durchführung

III. Identifikation signifikanter Kontrollen

Unter-Prozesse:

1. Durchsicht Kontrollendokumentation des Service Anbieters

o IT-Generelle Kontrollen

2. Schlüsselkontrollen des Service Anbieters

3. Schlüsselkontrollen der Prüfgesellschaft

222 Vgl. Treuhandkammer (1998), S. 169 – 182. 223 Vgl. Treuhandkammer (1998), S. 130 wobei der Begriff des „Systems“ durch ISK ersetzt wurde.

Ziel: Identifikation der signifikaten IT-Generellen Kontrollen im Bereich der IT-Security.


Prüfgesellschaft

Service Anbieter


Beschreibung:

Gemäss SOX Section 302 bzw. 404 müssen vom Service Anbieter die verschiedenen Kontrollen

und Kontrollzielen schriftlich festgehalten sein. Diese Dokumentationen der Kontrollen wurden

dem Prüfer in Phase I zur Verfügung gestellt. Aus diesen Dokumentationen werden die

Kontrollen betrachtet, die sich speziel an die in der Phase II identifizierten Risiken richten.

Aufgrund der Konzeptprüfung werden nur die IT-Generellen Kontrollen betrachtet, da diese

nicht nur die technische Seite hervorheben, wie es die Applikationskontrollen tun. Dabei sind

insbesondere die Schlüsselkontrollen224, die vom Service Anbieter bzw. dessen Management

definiert wurden, für den Prüfer von Interesse. Eine Schlüsselkontrolle im IT-Security Bereich

entscheidet darüber, ob die Integrität, Vertraulichkeit und Vollständigkeit der Daten und Systeme

gewährleistet werden kann. Die Definition der Schlüsselkontrollen ist eine rein subjektive

Einschätzung, weswegen ihnen eine kritische Haltung durch den Prüfer entgegengebracht

werden muss.

Neben den Schlüsselkontrollen des Management identifiziert der Prüfer selber aufgrund eigener

Erfahrung (Professional Judgement) und mit der Hilfe von COBIT die Kontrollen und zusätzlich

die Schlüsselkontrollen, die beim Service Anbieter implementiert werden sollten, damit die

Risiken richtig adressiert sind. Beim COBIT stehen bei der IT-Security-Prüfung insbesondere

die in Abschnitt 3.3.3 aufgezeigten IT-Prozesse im Vordergrund. Neben COBIT können dem

Prüfer ausserdem ITIL225 und ISO 17799 behilflich sein die Prüftiefe zu erweitert.

IV. Identifizierung der Mängel

224 In der Literatur wird der Begriff der Schlüsselkontrollen oft verwendet, jedoch wird keine Definition dieses Begriffes geliefert. Schlüsselkontrollen können als Oberkontrollen angesehen werden, die als Basis für weitere Kontrollen dienen. Diese Schlüsselkontrollen werden nach eigenem Ermessen definiert. 225 ITIL besitzt mit dem Werk: „Security Management“ ein Buch, dass sich ausschliesslich um die Security-Aspekte dreht.

Ziel: Mängel an den identifizierten Kontrollen sind bestimmt.


Prüfgesellschaft


Unter-Prozess:

1. Beurteilung des „Management-Testing“

2. Vergleich identifizierte Kontrollen mit gewünschten SOLL-Kontrollen

a. COBIT

b. Erfahrung des Prüfers (Professional Judgement)

3. Dokumentation der Mängel

Beschreibung:

Gemäss Section 404 des SOX muss das Management die eigene IC jährlich testen.226 Dieses

„Management-Testing“ muss schriftlich dokumentiert werden. In dieser Phase beurteilt die

externe Prüfgesellschaft unter anderem das „Management-Testing“ des Service Anbieters. Dabei

kann von einem Mangel gesprochen werden, wenn einer der folgenden Punkte auftritt:

Stichprobenanzahl ist nicht repräsentativ

Tests sind für den Prüfer nicht nachvollziehbar

Fehlende Beweise, dass Tests auch wirklich durchgeführt werden

Tests führen gemäss Einschätzung nicht zum dokumentierten Kontrollziel.

Weitere Mängel können auftreten, wenn die Kontrollen, die der Prüfer in der vorherigen Phase

identifiziert hat (Soll-Kontrollen), nicht mit den aktuellen Kontrollen des Service Anbieters (Ist-

Kontrollen) übereinstimmen. Dabei werden insbesondere die Schlüsselkontrollen miteinander

verglichen. Sind einzelne Schlüsselkontrollen nach Einschätzung des Prüfers nicht implemen-

tiert, so wird dies schriftlich festgehalten.

Aufgrund der beim Service Anbieter implementierten Kontrollen und die Kontrollen, die nach

Meinung des externen Prüfers vorhanden sein müssten, kann ein Bericht über die Mängel

angefertigt werden. Es sei hier nochmals hervorgehoben, dass es einzig um das Vorhandensein

von Kontrollen und um eine Beurteilung des Management-Testing geht, das an dieser Stelle

226 Vgl. Sarbanes-Oxley Act, Section 404 Abs. A Ziff. 2.


betrachtet wird. Über die Effektivität der Kontrollen, welches durch selber durchgeführte Tests

durch den Prüfers beurteilt wird, wird in dieser Phase noch keine Beanstandung vorgenommen.

V. Dokumentation der Kontrollen

Unter-Prozess:

1. Beschreibung der Kontrollen

o SAS 70 Typ I Bestätigung

2. Reporting für das Management (nur bei SAS 70 Typ I Bestätigung)

Beschreibung

Die in Phase III identifizierten Kontrollen werden beschrieben. Dabei muss darauf geachtet

werden, dass die vom externen Prüfer klassifizierten Schlüsselkontrollen eingehend beschrieben

werden. Für die Beschreibung kann dabei die in Abbildung 26 dargestellte Aufstellung

verwendet werden. Dabei werden die Kontrollen wiederum nach der ISO 17799 Gliederung

dargestellt.

Ziel: Berichterstattung über die Kontrollen

Für SAS 70 Typ I Prüfung: Beendigung der Prüfung und Anfertigung eines

Bericht zu Handen des Management des Service Anbieters.


Prüfgesellschaft


Abbildung 26: Beschreibung der Kontrollen

In dieser Phase endet die SAS 70 Typ I Prüfung. Wie in Abschnitt 5.2 erläutert wurde, wird

dabei eine Kontrollenbeschreibung, wie bei Abbildung 26 illustriert, und ein Bericht mit einer

Einschätzung der externen Prüfgesellschaft über das Kontrollwesen des Service Anbieters dem

Kunden bzw. den verschiedenen Outsourcern zur Verfügung gestellt. Teil dieses Berichtes sind

die in der vorhergehenden Phase identifizierten Mängel. Wobei nicht explizit auf die einzelnen

Mängel eingegangen wird, sondern eine allgemeine Einschätzung der externen Prüfgesellschaft

über das Kontrollwesen des Service Anbieters abgegeben wird.

Als weiterer Schritt kann die externe Prüfgesellschaft dem Management des Service Anbieters

einen separaten Bericht zukommen lassen. Dieser Bericht besteht aus der Dokumentation der

Mängel der vorhergehenden Phase. Dabei wird dem Service Anbieter kommuniziert, aus

welchem Grund Mängel beanstandet wurden. Es werden aber keine Vorschläge für mögliche

Kontrollen unterbreitet. Der Grund hierfür sind die SOX-Bestimmungen, die Vorschreiben, dass

mit der Prüftätigkeit keine beratende Tätigkeiten durchgefürt werden dürfen.

Die bisher beschriebenen Unterphasen gelten nur, wenn eine SAS 70 Typ I Prüfung durchgeführt

wird. Wird keine SAS 70 Typ I Prüfung durchgeführt, sondern eine Typ II Prüfung, so ist für die

weitere Bearbeitung nur die Beschreibung der Kontrollen notwendig. Der Bericht der externen

Prüfgesellschaft mit einer Einschätzung des Kontrollwesens wird in dieser Phase noch nicht

angefertigt.


VI. Planung der Evaluation der Kontrollen

Beschreibung:

Unter-Phasen:

1. Stichprobenplanung

o Lokalitäten (inkl. Rechenzentren und den Systemen)

o Kunden

Beschreibung

In dieser Phase geht es darum, die Planung für die in Phase VII bevorstehende Überprüfung der

Kontrollen vorzubereiten. Um die Prüfung in zeitlich angemessenen Rahmen vollziehen zu

können, wird die Planung so ausgelegt, dass der Prüffokus auf die Schlüsselkontrollen, die in

Phase III identifiziert wurden, gelegt wird. Das Testen der Kontrollen muss zu einer allgemeinen

Einschätzung der IC führen. Da nicht alle Kunden, Standorte und Systeme geprüft werden

können, wird eine Stichprobenwahl getroffen. Dabei bedient man sich der in Phase I gewonnen

Informationen über die verschiedenen Rechenzentren, Systemen und der Kunden des Service

Anbieters. Dabei stehen die Rechenzentren im Vordergrund, die von ihrer Grösse am

bedeutesten für den Service Anbieter sind. Weiterhin ist darauf zu achten, welche

Kundensysteme bzw. -daten in den entsprechenden Rechenzentren verarbeitet werden. Umso

grösser der Kunde respektive das Auftragsvolumen, umso eher wird die Lokalität in den

Prüffokus gelangen.

Wurden die verschiedenen Rechenzentren für den Prüffokus ausgewählt, muss für jedes

Rechenzentrum bestimmt werden, welche Kunden im genaueren Prüffokus liegen. Dieser SAS

70 Prüfprozess hat zum Ziel eine allgemeine Aussage über die Befindlichkeit zu geben und nicht

Ziel: Gesamtplanung der Kontrollenüberprüfung.


Prüfgesellschaft


auf einzelne Kunden bezogen zu sein. Durch die Stichprobenwahl der Kunden können jedoch die

IT-Sicherheitskonzepte dieser Outsourcer, die sie mit dem Service Anbieter unterhalten,

betrachtet werden. Deshalb muss der Prüfer in dieser Phase die einzelnen Kunden pro

Rechenzentrum auswählen.227

Nachdem die Rechenzentren und Kunden gewählt und die IT-Sicherheitskonzepte betrachtet

wurden, kann mit der Organisation der Prüfung begonnen werden. Dabei wird die zeitlich und

personelle Planung der Prüfung vogenommen. Bei der Planung müssen wiederum die Termin

mit den Interviewpartnern aus Phase I fixiert werden, damit diese Personen bei Unklarheiten

oder spezifischen Fragen zu einzelne Themen behilflich sein können.

VII. Durchführung der Tests

Beschreibung:

Unter-Phasen:

1. Management-Testing wiederholen

2. Prüfung der Schlüsselkontrollen, die durch Prüfgesellschaft identifiziert wurden

3. Kundenspezifische Stichprobenprüfungen

Beschreibung

227 Über die Anzahl der Kunden des Service Anbieters , die ausgewählt werden sollten, wie auch über die Anzahl der Rechenzentren, die im Fokus stehen, kann an dieser Stelle keine Angaben gemacht werden. Es liegt im Ermessen der Prüfgesellschaft.

Ziel: Die Kontrollen werden stichprobenartig auf deren Effektivität hin getestet.


Prüfgesellschaft

Service Anbieter: Involvierte Personen gemäss Abbildung 24


Im Gegensatz zu Phase III und IV, werden in dieser Phase eigene Tests durch den Prüfer

durchgeführt. Das Ziel dabei ist, dass der Prüfer eine Aussage über die Effektivität der IC erhält.

Aus diesem Grund werden drei Prüfungsarten vorgenommen:

1. Die in Phase IV betrachteten Management-Testing der Schlüsselkontrollen werden

stichprobenartig nochmals getestet. Dabei werden insbesondere die in der IV. Phase

bemängelten Test genauer betrachtet.

2. In einem zweiten Schritt werden die Kontrollen stichprobenartig getestet, die dem Prüfer

als wichtig erscheinen und noch nicht Teil des Management-Testing waren.

3. Im letzten Schritt werden die IT-Sicherheitskonzepte der im Prüffokus stehenden Kunden

des Service Anbieters näher betrachtet. Dabei werden auch nach Stichproben einzelne

Themen des IT-Sicherheitskonzepts genommen. Im Fokus stehen dabei

kundenspezifische Fragestellungen bezüglich der IT-Security. Als Beispiel dient

folgender Sachverhalt:

Logische Sicherheit – Kunde ABC

Kontrollaktivität Frage (Prüfgesellschaft) Antwort (Service Anbieter)

1.1 Alle Systeme des Kunden

ABC werden wie im IT-

Sicherheitskonzept

angegeben, laufend auf ihren

Zustand hin überprüft.

Werden laufend

Zustandsprüfungen an den

Systemen des Kunden ABC

vorgenommen, wie es laut

Sicherheitskonzept definiert

wurde?

(Beurteilungsunterlagen:

Aussage Systemadministrator

und die Log-Files der letzten

sechs Monate)

Siehe Log-File der letzten

sechs Monate

Abbildung 27: Beispielfrage der Logischen Sicherheit für Kunde ABC

Wie Abbildung 27 zeigt, können die Kontrollen mittels Interviews und den entsprechenden

Fragekatalogen geprüft werden. Dabei ist wichtig, dass nach schriftlichen Unterlagen gefragt


wird, die die letzten sechs Monate einwandfrei abdecken. Der Grund hierfür ist, dass der SAS 70

Typ II eine minimale Prüfperiode von sechs Monaten vorgibt.228 Alle Person, die in Abbildung

24 aufgelistet sind, können dabei befragt werden.

Eine weitere Möglichkeit für den Prüfer, sich selber von den Kontrollen zu überzeugen, besteht

darin, selber technische Prüfungen, wie z.B. das in Abschnitt 3.3.5 beschriebene Penetrationstest,

anzuwenden. Jedoch wie auch die Experten meinen, gehören solche technischen Prüfungen eher

nicht zum Prüfvorgang einer SAS 70 Prüfung.229

VIII. Identifizierung der Mängel

Beschreibung:

Aufgrund der durchgeführten Tests in der vorhergehenden Phase lassen sich Mängel betreffend

den Kontrollen identifizieren. Als Mängel können z.B. folgende Punkte beanstandet werden:

Die nachgeprüften Management-Testings führen nicht zu den beschrieben Resultaten.

Die durchgeführten Tests zeigen auf, dass die Kontrollen keinen zufriedenstellenden

Schutz bieten.

Die beim IT-Sicherheitskonzept definierten Punkte mit einem Kunden werden nicht

eingehalten.

228 Vgl. Abschnitt 5.2. 229 vgl. Anhang Interview Dambacher und Mühlenbrock / Hammer.

Ziel: Identifizierung der Mängel aus den durchgeführten Tests.


Prüfgesellschaft


6.4.5 Abschlussarbeiten

IX. Dokumentation

Beschreibung:

Inhalt des SAS 70 Report:

Beschreibung:

Zum Abschluss der Prüfung wird der SAS 70 Report Typ II erstellt. Die Bestandteile des Report

wurden im Abschnitt 5.2 näher erläutert. Ein möglicher Aufbau eines Report kann

folgendermassen aussehen:

I. Erklärung des Ziels und Zweck des SAS 70 Report

II. Bericht der unabhängigen Prüfgesellschaft mit Einschätzung der IC und Angaben über die

Prüfperiode

III. Beschreibung der Kontrollen der IT-Security230

IV. Beschreibung der von der externen Prüfgesellschaft durchgeführten Tests, um die

Effektivität zu testen und die Resultate aus diesen Tests

V. Weitere Informationen wie z.B. ein Glossar, Organigramm des Service Anbieters,

Prozessablaufplan im IT-Security Bereich

Dieser Report geht zu Handen des Management des Service Anbieters. Dem Service Anbieter

steht es frei, den Report an seine Kunden oder potentiellen Neukunden zu verteilen.

230 Die Gliederung kann wiederum auf den zehn ISO 17799 Themen basieren.

Ziel: Berichterstattung über die Kontrollen mit Informationen bezüglich deren

Effektivität.


Prüfgesellschaft


6.4.6 Schlussbemerkungen zum Prüfprozess

Im Unterschied zu einer gewöhnlichen IT-Security-Prüfung ist eine IT-Security Prüfung nach

SAS70 eine Konzeptprüfung, weswegen die gewöhnlichen technischen Prüfungen nicht in dem

Umfang vorgenommen werden, wie es bei einer norhmalen IT-Security-Prüfung der Fall ist. Ein

weiterer Unterschied zeigt sich beim Resultat der Prüfung: dem SAS 70 Report. Wird bei einer

gewöhnlichen IT-Security-Prüfung nur das Resultat mit der Einschätzung kommuniziert, werden

bei einem SAS 70 Report alle Informationen, wie z.B. Prüfverfahren und Resultate der Prüfung

veröffentlicht. Ein SAS 70 Typ II Report kann demnach auch schon mehrere hundert Seiten

umfassend sein.

Das beschrieben Prüfkonzept ist generell gehalten, so dass eine generelle Aussage über den

Service Anbieter gemacht werden kann. Eine SAS 70 Prüfung kann auf Wunsch auch nur auf

einen Outsourcer zugeschnitten sein. Beim Prüfkonzept hätte dies keinen grossen Einfluss. Nur

der Prüffokus wäre reduziert auf Risiken, Kontrollen und Sicherheitskonzept von diesem

Kunden.

6.5 Zusammenfassung

Im fünften Kapitel wurde der SAS 70 Report eingehend vorgestellt. Durch die nicht-

standardisierte Prüfung hatte dieses Kapitel zum Ziel, einen SAS 70 Prüfprozess im Bereich der

IT-Security vorzustellen. Bevor auf diesen spezifischen Prüfprozess eingegangen wurde, wurde

auf die Ausführungen der Treuhandkammer eingegangen, die einen vierphasigen

Standardprüfprozess beschrieben hat. Nachdem der allgemeine Prüfprozess erläutert wurde, sind

in einem nächsten Schritt die Besonderheiten der IT-Prüfung beschrieben worden. Dabei wurde

die Unterscheidung der Generellen Kontrollen und Applikationskontrollen vorgenommen.

Insbesondere die Generellen Kontrollen, die sich nicht nur auf technische Belangen beziehen,

sondern auch bertriebliche und organisatorische Aspekte berücksichtigen, spielen für den SAS

70 Prüfprozess eine wichtige Rolle. Durch diese Angaben betreffend dem Prüfvorgehen und

einem Einschub mit den Anforderungen, die durch SOX an ein Prüfprozess gestellt wurden,

konnte der SAS 70 Prüfprozess vorgestellt werden. Dabei wurden der Prüfprozess nach dem

standardisierten Prüfprozess der Treuhandkammer aufgebaut unter Berücksichtigung der SOX-

Anforderungen.

7. Schlussbetrachtung 116

7 Schlussbetrachtung

7.1 Zusammenfassung

Mit den ersten beiden Kapiteln wurde die benötige Theorie für die vorliegende Arbeit

aufbereitet. Dabei wurde zu Beginn eine Einführung in die Thematik des Outsourcing gegeben.

Neben der Definition, den Gründen und den rechtlichen Aspekten des Outsourcing wurde

inbesondere das IT-Outsourcing als eine Outsourcing-Variante vorgestellt. Im darauffolgenden

Kapitel wurde auf die Thematik der Internal Control eingegangen. Dabei wurde mit dem COSO

Framework eine Konkretisierung und Implementiertungsmöglichkeit der IC im Unternehmen

vorgestellt. Neben COSO wurde mit COBIT eine Framework vorgestellt, das die IT in den

Vordergrund stellt. Nach den Ausführungen bezüglich der IC wurde der Fokus auf den IT-

Bereich gelegt und dabei das Themengebiet der IT-Security aufgegriffen.

Das vierte Kapitel verknüpfte die zwei vorangegangenen Kapitel, indem auf den Einfluss des

Outsourcing auf die verschiedenen Parteien einer Outsourcing-Beziehung eingegangen wurde.

Dabei wurden im allgemeinen Teil die Aufgabenänderungen der Internen und Externen Revision

vor und im Outsourcing-Verhältnis genauer betrachtet. Im zweiten Teil des Kapitels wurde die

Thematik der IT-Security im Outsourcing betrachtet. Dabei wurde das IT-Sicherheitskonzept,

was durch den Service Anbieter und Outsourcer gemeinsam erarbeitet wird, eingehend

vorgestellt. Den Schluss des Kapitels behandelte die Thematik der Überprüfbarkeit der IT-

Security beim Service Anbieter. In diesem Zusammenhang wurden Möglichkeiten wie

Penetrationstests oder direkte Prüfungen vorgestellt.

Mit dem SAS 70 Report wurde im fünften Kapitel eine Möglichkeit aufgezeigt, wie der

Outsourcer, ohne direkte Prüfungen beim Service Anbieter vornehmen zu müssen, trotzdem die

Sicherheit erhält, dass seine ausgelagerten Bereiche mit der notwendigen Sorgfalt weitergeführt

werden. Neben der gründlichen Vorstellung des SAS 70 Reports wurde auf den Sarbanes-Oxley

Act eingegangen, der mit eines der Gründe ist, wieso sich SAS 70 immer mehr verbreitet.

Abschliessend wurde aufgrund der nicht standardisierten SAS 70 Prüfung im sechsten Kapitel

ein Vorgehen vorgestellt, wie eine SAS 70 Prüfung im Bereich der IT-Security aussehen kann.


7.2 Schlussfolgerungen

Mit dem SAS 70 Report wird eine Möglichkeit geboten, die Berichterstattung der Outsourcer

vergleichbarer werden zu lassen. Obwohl betreffend dem Prüfumfang und der Prüftiefe keine

Angaben festgelegt wurden, sind die Berichte, egal ob nach Typ I oder Typ II, ähnlich aufgebaut.

Doch nicht nur die Vergleichbarkeit fällt positiv aus. Durch den SAS 70 Report wird auch die

Interne Revision des Outsourcer entlastet. Wie in der vorliegenden Arbeit beschrieben, besitzt

die Interne Revision keinen Standard, welcher das Outsourcing-Verhältnis regelt. Dies im

Gegensatz zur Externen Revision, die den PS 402 besitzt. Doch durch den SAS 70 Report wird

die bis anhin schwache Stellung der Internen Revision im Outsourcing-Verhältnis gestärkt. Die

Interne Revision muss dabei nicht um das Revisionsrecht beim Service Anbieter „kämpfen“,

sondern kann sich auf die Durchsicht des Reports beschränken.

Wie in Abschnitt 5.7 beschrieben wurde, existieren bis anhin keine direkten Alternativen zum

SAS 70. Aus diesem Grund wird sich dieser Report in der Zukunft aufgrund der SOX-

Konformität immer mehr durchsetzen.

SAS 70 muss dabei nicht nur aufgrund der SOX-Konformität eingesetzt werden. Da der SAS 70

Report einen Outsourcer quasi „zwingt“ die Kontrollen zu dokumentieren, kann eine SAS 70

Prüfung auch eine Möglichkeit sein, Mängel in der Organisationsstruktur zu identifizieren.

Problematisch bei einer SAS 70 Prüfung sind neben den finanziellen Aspekten sicherlich auch

die fehlenden Leitlinien bei der Prüfung. Kapitel 6 zeigt einen möglichen Prüfprozess, jedoch

wird durch die Hilfenahme des SAS 70 Standards keine Möglichkeit geboten, um den

Prüfprozess mit einem Standard-SAS 70 Prozess zu vergleichen.

7.3 Ausblick

In der Schweiz werden zur Zeit nur vereinzelt SAS 70 Prüfungen durchgeführt. Die Tendenz ist

steigend und viele Service Anbieter planen bereits, sich einer SAS 70 Prüfung zu unterziehen.

Dabei spielt der Gedanke mit, dass SOX früher oder später auch in die nationalen Vorschriften

übergehen wird. Mit dem PS 402 ist dies in der Schweiz im weitesten Sinne schon geschehen.

Wünschenswert bei der möglichen Weiterentwicklung des SAS 70 wäre, dass Angaben über die

Prüftiefe und den Prüfumfang durch das AICPA veröffentlicht werden. Somit wäre die Arbeit

für die externe Prüfgesellschaft bei der Erstellung des Prüfprozesses schnell zu bewältigen und

andererseits weiss auch der Outsourcer, was ihn bei der Prüfung erwartet.


Um SAS 70 in der Schweiz noch präsenter werden zu lassen, wäre eine stärkere

Auseinandersetzung der externen Prüfer mit dem SAS 70 wichtig. Im aktuellen Zeitpunkt

verfügen nur wenige Prüfgesellschaften Erfahrungen mit dem SAS 70. Mit dem PS 402 wird

sich dies aber wahrscheinlich ändern, da der PS 402 in manchen Punkten dem SAS 70 sehr

ähnlich ist.231

231 Z.B. die 2-Typen-Berichterstattung.

8. Literaturverzeichnis 119

8 Literaturverzeichnis

Australian Accounting Research Foundation (Hrsg.) (1999): „Superannuation Funds –

Auditor Reports on Externally Managed Assets”, in:

„http://www.auasb.gov.au/docs/AGS1026_2-99.pdf”, abgerufen: 20.07.2005.

American Institute of Certified Public Accountants (Hrsg.) (2005): „SysTrust: Presentation

for CPAs”, in: „http://www.aicpa.org/assurance/systrust/power.htm”, abgerufen:

28.07.2005.

American Institute of Certified Public Accountants (Hrsg.) (2003): „Suitable Trust Services

Criteria and Illustrations – Suitable Trust Services Criteria and Illustrations for Security,

Availability, Processing Integrity, Online Privacy, and Confidentiality (Including

WebTrust and SysTrust)“, in: „http://www.cpawebtrust.org/download/final-Trust-

Services.pdf”, abgerufen: 27.05.2005

Applegate, Lynda / Austin, Rober/McFarlan, Warren (2003): „Corporate Information

Strategy and Management”, New York 2003.

Bauknecht, Kurt (2003): „Outsourcing“, Skript zur Vorlesung „Informationsmanagement” der

Universität Zürich, Zürich 2003, in:

„http://www.ifi.unizh.ch/ikm/Vorlesungen/IM3/WS0203/IM3_files/4-outsourcing.pdf”,

abgerufen: 12.09.2005.

Billeter, Thomas (1995): „IT-Outsourcing: marktwirtschaftliche Ansätze zur Bereitstellung der

IT-Infrastruktr in Unternehmungen”, Zürich 1995.

BITKOM (Hrsg.) (2003): „Sicherheit für Systeme und Netze in Unternehmen”, in:

„http://www.bitkom.org/files/documents/ACF897.pdf”, abgerufen: 16.06.2005.

BITKOM (Hrsg.) (2005): „Kompass der IT-Sicherheitsstandards – ein Leitfaden für

mittelständische Unternehmen”, in:

„http://www.bitkom.org/files/documents/BITKOM_Broschuere_Sicherheitsstandard_V1.0

1f.pdf”, abgerufen: 17.06.2005.

Boritz, Efrim / Mackler, Erin / McPhie, Doug (1999): „Reporting on Systems Reliability”, in:

„Journal of Accountancy”, November 1999, New York, S. 75 – 87.


Bundesamt für Sicherheit in der Informationstecknik (Hrsg.) (2004): „IT-

Grundschutzhandbuch”, in: „http://www.bsi.de/gshb/index.htm”, abgerufen: 24.06.2005.

Champlain, Jack (2003): „Auditing Information Systems”, New Jersey 2003.

Canadian Institute of Chartered Accountants (Hrsg.) (o.J): „Service Organizations”, in:

„http://www.cica.ca/index.cfm?la_id=1&ci_id=19365&highlight_keywords=section%2059

00”, abgerufen: 11.08.2005.

Committee of Sponsoring Organizations of the Treadway Commission (Hrsg.) (1994):

„Internal Control – Integrated Framework”, Jersey City 1994.

Czurda, Henrik (2002): „Die Problematik der Umsetzbarkeit von Sicherheitsmassnahmen in

Informations- und Kommunikationssystemen”, Zürich 2002.

Dammbacher, Mark / Hug, Markus (2005): „Informatikrevision von ausgelagerten IT-

Umgebungen bei Banken”, in PWC (Hrsg.) (2005): „Flash – Finanzdienstleistungen”, Juli

2005, in:

„http://www.pwc.com/ch/ger/ins-sol/publ/bank/download/pwc_flashfinanz_0705_d.pdf”,


DCA-Consulting (Hrsg.) (2005): „Sarbanes-Oxley Act”, in: „http://www.dca-

consulting.de/sarbanesoxleyact/index.php”, abgerufen: 10.08.2005.

Deutsche Bank Research (Hrsg.) (2004): „IT-Outsourcing: Zwischen Hungerkur und Nouvelle

Cuisine”,in: „http://www.dbresearch.de/PROD/DBR_INTERNET_DE-

PROD/PROD0000000000073793.pdf”, abgerufen: 21.04.2005.

Dittrich, Jörg / Braun, Marc (2004): „Business Process Outsourcing”, Stuttgart 2004.

Economiesuisse (Hrsg.) (2002): „Swiss Code of Best Practice for Corporate Governance”, in:

„http://www.economiesuisse.ch/d/content.cfm?upid=4B42201A-1850-4309-

A49B90A37CA04F7B&type=pdf&filetype=pdf”, abgerufen: 13.09.2005.

Eidgenössische Bankenkommission (Hrsg.) (1999): „Rundschreiben der Eidgenössischen

Bankenkommission: Auslagerung von Geschäftsbereichen (Outsourcing)”, in:

„http://www.ebk.ch/d/regulier/rundsch/pdf/99-2.pdf”, abgerufen: 13.09.2005.

Gossels, Jonathan G. (2001): „SAS 70: The Emperor Has No Clothes”, in:

„http://www.systemexperts.com/tutors/sas70.pdf”, abgerufen: 03.08.2005.


Gray, Iain / Manson, Stuard (2000): „The Audit Process – Principle, Practice & Cases”,

London 2000.

Gurovits Kohli, Andras (2003): „Service Level Agreements in der Outsourcing Praxis”, in:

Weber, Rolf H. / Berger, Mathis / Auf der Mauer, Rolf (Hrsg.): „IT-Outsourcing”, Zürich,

Basel, Genf 2003, S. 97-115.

Hässig, Kurt (2000): „Prozessoptimierung – Erfolgreich durch effiziente Strukturen”, Zürich

2000.

Heinrich, Lutz J. (2002): „Informationsmanagement”, Oldenburg, München, Wien 2002.

Heinrich, Lutz J. / Riedl, René (2004): „ASP-Qualität – Entwicklung eines Messmodells”, in

„Praxis der Wirtschaftsinformatik”, Nr. 237, Heidelberg 2004, S. 80 – 89.

Honsell, Heinrich (2001): „Schweizerisches Obligationenrecht – Besonderer Teil”, Bern 2001.

Huissoud (2002): „IT-Outsourcing und Revision”, in „Newsletter ISACA”, Nr. 60, Zürich 2002,

S. 11 – 17.

Internal Auditor (Hrsg.) (2005): „The COSO Model”, in „Internal Auditor”, April 2005, S. 53.

IT Governance Institute (Hrsg.) (2000a): „COBIT 3rd Edition – Executive Summary”, in:

„http://www.isaca.ch/files/CobitExecutiveSummary.pdf, abgerufen: 13.09.2005.

IT Governance Institute (Hrsg.) (2000b): „COBIT 3rd Edition – Control Objectives”, in:

„http://www.isaca.ch/files/CobitControlObjectives.pdf”, abgerufen: 12.09.2005.

IT Governance Institute (Hrsg.) (2004a): „COBIT Mapping”, in:

„http://www.isaca.ch/files/COBIT_Mapping.pdf”, abgerufen: 13.09.2005.

IT Governance Institute (Hrsg.) (2004b): „COBIT Security Baseline”, in:

„http://www.isaca.org/TemplateRedirect.cfm?template=/MembersOnly.cfm&ContentID=1

7078m”, abgerufen: 12.09.2005.

IT Governance Institute (Hrsg.) (2004c): „IT Control Objectives for Sarbanes-Oxley”, in:

„http://www.isaca.org/Content/ContentGroups/Research1/Deliverables/IT_Control_Objecti

ves_for_Sarbanes-Oxley_7july04.pdf”, abgerufen: 12.09.2005.

ITIL.org (Hrsg.) (2005): „What ist ITIL?”, in: „http://www.itil.org/itil_e/itil_e_030.html”,


Krcmar, Helmut (2003): „Informationsmanagement”, Berlin, Heidelberg, New York 2003.


Marten, Kai – Uwe / Quick, Reiner / Ruhnke, Klaus (2003): „Wirtschaftsprüfung”, Stuttgart

2003.

Messier, William F. Jr. (2003): „Auditing & Assurance Services – A System Approach”, New

York 2003.

Meyer, Ulf (2004): „E-Business und Wirtschaftsprüfung”, Köln 2004.

Neuenschwander, Peter K. (2003): „Vertragsgestaltung für Outsourcing Projekte”, in: Weber,

Rolf H. / Berger, Mathis / Auf der Mauer, Rolf (Hrsg): „IT-Outsourcing”, Zürich, Basel,

Genf 2003, S. 63-83.

Plate, Angelika (2005): „Der neue ISO/IEC 17799:2005”, in: „IT-Security”, Nr. 2 Mai 05,

Forch 2005, S. 51-52.

PricewaterhouseCoopers (Hrsg.) (o.J.): „Control Reports – Aufnahme und Beurteilung von

Prozessen, Kontrollen und Schnittstellen”, PricewaterhouseCoopers, internes Dokument.

Public Company Accounting Oversight Board (Hrsg.) (2002): „AU Section 319”, in:

http://www.pcaobus.org/standards/interim_standards/auditing_standards/au_319.html,


Public Company Accounting Oversight Board (Hrsg.) (2005): „Auditing Standard No. 2 – An

Audit of Internal Control Over Financial Reporting Performed in Conjuction with an

Auduit of Financial Statements”, in:

„http://www.pcaobus.org/Rules/Rules_of_the_Board/Auditing_Standard_2.pdf”,


Ricchiute, David N. (2003): „Auditing and Aussurance Services”, Ohio 2003.

Riedl, René (2003): „Begriffliche Grundlagen des Business Process Outsourcing”, in:

„Information Mangemement & Consulting“, Nr. 18, Saarbrücken 2003, S. 6 – 10.

Robertson, Jack / Louwers, Timothy (2002): „Auditing & Assurance Services”, New York

2002.

Ruud, Flemming T. / Jenal, Ladina (2004): „Internal Control”, in: „Der Schweizer

Treuhänder”, Nr. 12/04, Zürich 2004, S. 1045 – 1050.

Ruud, Flemming T. / Pfister, Jan (2005): „Das interen Kontrollsystem soll man ernst nehmen”,

in: „Neue Zürcher Zeitung”, 26.05.2005, S. 29.


SAS 70 (Hrsg.) (2005a): „Service Auditor’s Report”, in: „http://www.sas70.com/about.htm”,


SAS 70 (Hrsg.) (2005b): „Differences between SAS 70 and ISO 9000”, in:

„http://www.sas70.com/faq/faq1.htm”, abgerufen: 28.07.2005.

SAS 70 Solutions (Hrsg.) (2005a): „Differences between SAS 70 audits and Trust Services

Reviews”, in: „http://www.sas70solutions.com/SAS70-FAQ.html#Question_13”,


SAS 70 Solutions (Hrsg.) (2005b): „What is the value proposition of a SAS 70 audit?”, in:

„http://www.sas70solutions.com/SAS70-FAQ.html#Question_2”, abgerufen: 05.08.2005.

Schaarschmidt, Ralf (2003): „Business Transformation Outsourcing: Der Weg in die on-

demand-Welt”, in: „Information Management & Consulting”, Nr. 18, Saarbrücken 2003, S.

46 – 50.

Schweizerische Normen-Vereinigung (Hrsg.) (2001): „Information technology – Code of

practice for information security management”, Genf 2001.

SOX-Online.com (Hrsg.) (2005): „COSO Framework – Original Cube”, in: „http://www.sox-

online.com/coso_cobit_coso_cube-old.html”, abgerufen: 12.09.2005.

The Institute of Chartered Accountants in England and Wales (Hrsg.) (1997): „FRAG 21/94

(Revised) – Reports on Internal Controls of Investment Custodians made available to Third

Parties”, in: „http://www.icaew.co.uk/viewer/index.cfm?AUB=TB2I_2114”, abgerufen:

19.07.2005.

The Institute of Chartered Accountants in England and Wales (Hrsg.) (1999): „Internal

Control – Guidance for Directors on the Combined Code”, in:

http://www.icaew.co.uk/viewer/index.cfm?AUB=TB2I_6342&tb5=1&CFID=4510314&C

FTOKEN=57960492, abgerufen: 12.09.2005.

The Institute of Internal Auditors (Hrsg.) (o.J.): „Professonal Practices Pamphlet – A

Perspective on Control Self-Assessment”, in: „http://www.ucop.edu/ctlacct/csa/prof-

pract/csa-1.pdf”, abgerufen: 02.09.2005.

The Institute of Internal Auditors (Hrsg.) (2002): „Practice-Advisory 2050-2”, in:

„http://www.blindtiger.co.uk/IIA/uploads/-38c9a362-ed71ce5fa5--

739d/PracticeAdvisory2050.doc”, abgerufen: 13.09.2005.


Treuhandkammer (Hrsg.) (1998): „Schweizer Handbuch der Wirtschaftsprüfung – Band 2”,

Zürich 1998.

Treuhandkammer (Hrsg.) (2004): „Schweizer Prüfungsstandards (PS)”, Zürich 2004.

Weber, Rolf (2003): „Haftungsgrundlagen beim IT-Outsourcing”, in: Weber, Rolf H. / Berger,

Mathis / Auf der Mauer, Rolf (Hrsg.): „IT-Outsourcing”, Zürich, Basel, Genf 2003, S. 117-

138.

Zimmermann, René (2005): „Serviceorientierung wird zertifizierbar“ in: „Infoweek”, Nr.

11/2005, Thalwil 2005, S. 39 – 41.

9. Anhang 125

9 Anhang

9.1 Experteninterviews

Bei den Interviews handelt es sich um offene Gespräche zu verschiedenen Themen der

Diplomarbeit. Die Interviews wurden auf Band aufgenommen und sinngemäss transkripiert. Die

Veröffentlichung des Transkripts erfolgt aufgrund der Durchsicht und Genehmigung der

transkripierten Version durch die interviewten Personen.

Folgende Personen haben sich für ein Interview zur Verfügung gestellt:

Wolfgang Pfister (Unisys, Thalwil)

Patrick Allenspach (Luzerner Kantonalbank, Luzern)

Jürg Illi (Credit Suisse Group, Zürich)

Michel Huissoud (Eidgenössische Finanzkontrolle, Bern)

Frank Mühlenbrock (IBM Deutschland, Ehningen)

Frank Hammer (IBM Deutschland, Stuttgart)

Mark Dambacher (PricewaterhouseCoopers, Zürich)

9. Anhang 126

Wolfgang Pfister, Senior Consultant Unisys

Themen:

Outsourcing aus der Service Anbieter Sicht

IT-Security

Zertifizierungen im IT-Security Bereich

Aus Sicht des Outsourcer gibt es viele Gründe, in ein Outsourcing einzutreten (z.B.

Kosteneinsparungen, Technologie etc.). Welche Gründe bestehen nun aber für den Service

Anbieter, in ein Outsourcing einzusteigen?

Man muss hier unterscheiden zwischen Outsourcing, also ein komplettes Outsourcing, wie es die

grossen Firmen wie EDS oder IBM anbieten und andererseits das Outtasking, auf das wir uns

spezialisiert haben. Wir übernehmen dementsprechend nicht die ganze Informatik, sondern Teile

der Informatik. Für Unisys ist das Ziel möglichst langfristige Verträge mit dem Kunden zu

haben. Durch die Langfristigkeit können wir unsere Ressourcen optimal planen und einsetzen.

Aus der Businesssicht ist ein Outsourcing durch die Verträge viel besser planbar. Anders als bei

einem Projekt-Business, ist es im Outsourcing möglich, die Kosten und Umsätze für mehrere

Jahre voraus zu kennen bzw. abzuschätzen, da Mindestleistungen in den Verträgen abgemacht

wurden. Für den Service Anbieter ist es lukrativer, seinen Umsatz und seine Kosten z.B. über 3

Jahre unter Kontrolle zu haben, anstatt der Unberechenbarkeit des Projekt-Business ausgesetzt

zu sein.

Wie sehen Sie die Entwicklung des Outsourcing von früher, als vorwiegend IT-Outsourcing

betrieben wurde, während heute Begriffe wie Business Process Outsourcing immer mehr in

den Vordergrund rücken?

Früher hat man Outsourcing betrieben, um Probleme loszuwerden. Vielfach wurde dann aber

ersichtlich, dass die Probleme weiter bestanden. Etwas outsourcen heisst nicht, etwas abzugeben

und dann keine Verantwortung mehr zu tragen. Es lässt sich erst etwas outsourcen, wenn ich

wirklich verstehe, um was es geht. Erst dann kann man Anforderungen formulieren und erst

dann bekommt man von einem Service Anbieter das, was gefordert wurde. Wenn nicht bekannt

9. Anhang 127

ist, was gebraucht wird, kann dies auch nicht formuliert werden und man bekommt als

Konsequenz viel zu viel an Leistungen, das zu teuer bezahlt wird oder man erhält zu wenig und

hat dann das Problem, dass es nicht den gestellten Anforderungen entspricht. Firmen gehen

immer weiter in den Überlegungen. Früher lautete die Strategie möglichst zu diversifizieren,

heute strebt man zurück zu den Kernkompetenzen. Die Backoffice Prozesse gehören für viele

Firmen nicht mehr zu den Kernkompetenzen. Hier kommt das Business Process Outsourcing

zum tragen. Die Unisys betreibt bereits das Business Process Outsourcing für Firmen. Das

Business Process Outsourcing, also das Auslagern von Backoffice Prozessen, um weitere Kosten

einzusparen und weitere Kernkompetenzfokussierung anzustreben, ist ganz klar der Trend. Für

uns ist dies sehr interessant. Die Bindung zum Kunden wird intensiviert und verstärkt. Wenn nur

PCs bereitgestellt werden, so sind wir schneller auswechselbar. Im Business Process

Outsourcing, das eine Ebene höher ist, ist die Auswechselbarkeit weniger schnell gegeben.

Werden die Outsourcing-Verträge dementsprechend langfristiger gestaltet, als sie bisher

waren?

Standardmässig werden Outsourcing-Verträge zwischen drei bis fünf Jahren abgeschlossen.

Heutzutage werden die Outsourcing-Verträge oftmals vor dem Ablauf wieder neu verhandelt.

Z.B. werden Verträge nach zweieinhalb Jahren wieder bereits neu verhandelt, da sich die

Anforderungen insbesondere in der IT sehr schnell verändern. Die Kunden wünschen flexiblere

Verträge, damit der rasanten Entwicklung Schritt gehalten werden kann. Dies ist ein

Widerspruch zum Outsourcing, denn die Outsourcing Anbieter müssen eine Plansicherheit

haben. Es ist schwer kalkulierbar, wenn z.B. ein Support für 20'000 PCs für die nächsten fünf

Jahre garantiert wird und ein Jahr später tätigt die outsourcende Firma eine Akquisition und

schon sind es 35'000 PCs zum betreuen. Was bedeutet nun das für die Outsourcing Anbieter?

Deshalb müssen Outsourcing-Verträge flexibel gestaltet werden, damit die nötige Sicherheit

bezüglich der Infrastruktur gewährleistet werden kann. Das wird vom Kunden eingesehen.

Wo sehen Sie die Grenzen des Outsourcing?

Es gibt ganz verschiedene Grenzen. Einerseits die gesetzlichen Grenzen, die man akzeptieren

muss. Andererseits setzt sich die Unternehmung mit der eigenen Strategie selbst Grenzen. Die

Hauptgrenze, die ich sehe, ist dort, wo ein Unternehmen etwas auslagern will, das sie selber

nicht versteht. Es muss etwas outgesourct werden, das man versteht, klar messbar ist und klar

9. Anhang 128

definierten Parameter aufweist. Ansonsten kann man fast alles auslagern: Reception,

Buchhaltung, Personalwesen, IT etc.

Wieso denken Sie, dass ein potentieller Outsourcer Unisys als Service wählen sollte?

Bei uns existiert ein ganz klarer Fokus. Outsourcer und Service Anbieter müssen

zusammenpassen, d.h. eine kleinere Unternehmung wird seine IT nicht an einen grossen

Outsourcing Anbieter auslagern und umgekehrt wird einen grosse Unternehmung seine IT nicht

an einen kleinen Outsourcing Anbieter auslagern. Die Unisys ist insbesondere im Infrastructure

Managed Services stark. Kunden die international tätig sind, wählen die Unisys, da wir in über

hundert Ländern eine Niederlassung haben, damit auch vor Ort die Leistungen erbracht werden

können.

Die Unisys eignet sich gut für mittelgrosse und grosse Firmen. Ganz grosse Firmen, die ein

ganzes Datacenter oder Hostsysteme outsourcen wollen, sind für uns nicht möglich, da wir

physisch keine so grossen Lokalitäten zur Verfügung haben.

Sie haben nun primär über die Grösse argumentiert. Kann der Ruf der Unisys oder

irgendeines anderen Anbieters bezüglich der Sicherheit ein Kriterium zur Wahl sein?

Sicherheit ist immer eine besondere Sache. Oftmals ist bei den Firmen gar nicht bekannt, was die

IT für die Unternehmung bringt. Die Diskrepanz zwischen dem Business und der IT ist stets sehr

gross. Teilweise ist es so, dass die IT-Abteilung dem Business vorschreibt, was sie liefern

werden und es ist nicht so, dass das Business die IT-Abteilung beauftragt, was sie liefern

müssen. Dies wird sich aber immer mehr durch die bessere bzw. IT-spezifischere Ausbildung der

Personen, insbesondere der Studienabgänger, ändern. Bereits dieser Prozess ist für die

Sensibilisierung wichtig. Dies wiederum definiert die Anforderungen an die Sicherheit:

Verfügbarkeit, Vertraulichkeit und Integrität. Wichtig ist zudem, dass die Sicherheit im

Outsourcing gewährleistet ist. Andererseits gibt es auch die Möglichkeit, dass Sicherheit selber

outgesourct wird. Die Firma schätzt sich dabei so ein, dass sie nicht mehr in der Lage ist, das

ganze Firewall-Management, Antivirus-Management etc. aufrechtzuerhalten. Die Unisys bietet

ein solches Sicherheits-Outsourcing an. Das Sicherheitskriterium ist mit Bestimmtheit ein

Auswahlkriterium für die potentiellen Outsourcer.

9. Anhang 129

Wie würden Sie einem Kunden den Begriff IT-Security definieren?

Die Unisys hat eine Implementationsmethodik für Sicherheit entwickelt. Oftmals wird Sicherheit

nur aus dem technischen Blickwinkel betrachet. Wir denken, dass Sicherheit ein Schritt

weitergeht. Wir haben ein vier-Layer-Konzept erarbeitet mit dem Namen „Zero-Gap-Security-

Governance“. Das heisst natürlich nicht, dass Unisys dem Kunden eine vollkommene Sicherheit

versprechen kann. Dem Kunden wird eine Methodik angeboten, die alle Sicherheitsthemen

umfasst. So kann er sicher sein, dass Sicherheitslücken bewusst eingegangen werden und nicht

aus Unwissenheit. Das vier-Layer-Konzept baut auf vier Säulen auf: Erste Säule ist das

Etablieren von Sicherheit: Policies, Sicherheitsstruktur, Prozesse, Technologien definieren etc.

Die zweite Säule wird von den Firmen weniger eingehalten: Kontrollieren und Messen von

Sicherheit. Mit jeder Firewall, Ausbildung oder jedem Projekt wird ein Erfolg antizipiert. Die

Firmen messen dies jedoch nicht. Unisys hat deswegen ein Tool geschaffen, das „Benchmark-

Assessment Tool“ heisst, welches sich dem ISO Standard 17799 anlehnt und den Reifegrad der

Unternehmung aufzeigt. Natürlich ist der Sicherheitsstandard von Branche zu Branche

verschieden. Deswegen werden im dritten Layer die verschiedenen Risiken aus Businesssicht

evaluiert. Ein Risiko kann je nach Unternehmung eine andere Bedeutung für die Sicherheit des

Unternehmens haben. Der Layer vier beinhaltet eine unabhängige Kontrolle durch die Interne

oder Externe Revision.

Bei einer Sicherheitsberatung nehmen wir unser Tool als Hilfe für die Unternehmen, um ihren

Fortschritt bezüglich ihrer Sicherheit darzustellen. Wird festgestellt, dass ein Teilgebiet noch

nicht bearbeitet wurde, so obliegt es dem Kunden, wie er damit umgehen will. Bezüglich

Sicherheit bzw. Risiken gibt es vier Möglichkeiten: Risiken ignorieren, reduzieren, auslagern

(was aber ein Kontrollieren beim Outsourcing Anbieter auch proaktiv voraussetzt) und Risiken

akzeptieren. Wir als Service Anbieter können dem Kunden die zehn schwerwiegendsten Risiken

aufzeigen und natürlich auch einen Lösungsvorschlag mit der entsprechenden Offerte

unterbreiten.

All dies ist ein interner Prozess der Unisys. Wir bieten im Rahmen des Outsourcing-Vertrages

solche Möglichkeiten der laufenden Risikoidentifizierung und – behebung an.

9. Anhang 130

Sie überlassen primär den Kunden die Verantwortung, dass er sich mit den Security Aspekten

befasst?

Teilweise. Wir können den Kunden zeigen, wie wir z.B. ihre PCs unterhalten, welche Prozesse

dahinter stecken und wie die SLA aussehen. Doch was nützt es uns, wenn wir alle Security

Standards einhalten, wenn beim Kunden selber zu ungenau mit der Thematik umgegangen wird?

Es muss dem Kunden bewusst sein, dass es ein gesamtheitlicher Sicherheitsapproach geschaffen

werden muss und da machen die Service Anbieter ein Teilbereich davon aus. Die Sicherheits-

organisation vom Kunden kann ihm nicht abnommen werden und die Gesetzkonformität ist in

seinem Interesse. Es bestehen zwei Möglichkeiten: Dem Kunden durch Beratung zu einer

geeigneten Struktur verhelfen oder ihm garantieren, dass der Teil, der von uns erbracht wird,

gemäss Bestpractice ISO 17799 geleistet wird. Durch die Zertifizierung unserer Zentren wird

unsere Sicherheit gewährleistet. Daher muss der Kunde nicht extra eine Kontrolle bei uns

durchführen. Natürlich kann er, insbesondere dessen Sicherheitsexperte, bei uns nachfragen, wie

wir die Sicherheitsmassnahmen implementiert , worauf unser Nachweis erfolgt.

Der Kunde hat also jederzeit das Recht bei Ihnen zu einem bestimmten Gebiet die Kontrollen

nachzuprüfen?

Ja, aber der Kunde darf nicht an beliebigen Zeitpunkten in unsere Zentren erscheinen. Einerseits

sind wir zertifiziert und andererseits sind wir immer bereit einen entsprechenden Fragekatalog

vom Kunden zu beantworten. Dies muss als Sicherheit für den Kunden genügen.

Wenn nun aber alle Kunden bei Ihnen vorbeikommen und eine Sicherheitsanfragen mache,

ist der Aufwand wahrscheinlich sehr hoch. Wie gehen Sie damit um?

Natürlich kosten die Prüfungen etwas. Wenn nun ein Kunde eine Prüfung von einem Externen

verlangt, dann kann er dies ruhig tun und wir werden uns einer Prüfung unterziehen. Jedoch geht

dies voll zu Lasten des Kunden.

Wer sind ganz konkret die involvierten Parteien für die Erstellung eines Sicherheitskonzeptes

und was sind ganz relevante Themen daraus?

Wir lehnen uns an ISO 17799 an. Die Firmen wollen sich auch danach richten, weswegen wir

eine Vorlage erarbeitet haben, die die nicht sehr konkreten ISO Forderungen ausformulieren. Ein

9. Anhang 131

Beispiel wäre die Passwortvergabe: Wir geben vor, dass das Passwort alle 30 Tage geändert

werden muss, 8 Zeichen (Gross/Kein, Nummerisch/Alphanummerisch, Spezialzeichen)

beinhalten muss. Wir können so sehr schnell eine akzeptables Sicherheitskonzept für den

jeweiligen Kunden entwickeln. Involviert in diesem ganzen Prozess sind folgende Parteien: IT-

Abteilung, idealerweise die Personalabteilung und die Rechtsabteilung. Das sind die drei

Hauptparteien. Zudem wird angestrebt, dass das Business auch von Anfang an im Boot ist.

Oftmals kommt das Business erst wenn das Sicherheitskonzept steht und hat dann einiges zu

bemängeln. Schlussendlich ist es die Geschäftsleitung, die das Sicherheitskonzept verabschiedet

und die entsprechenden Schritte tätigt, um die Massnahmen einzuführen.

Können Sie sich über die Themen eines Sicherheitskonzeptes äussern?

Die Themen richten sich ganz klar nach ISO 17799. Also: Security Policy, IT-Security

Organisation, Anlagenklassifizierung und Kontrolle, Personensicherheit, physische Sicherheit,

Kommunikations- und Operationsmanagement, Zugriffsrechtvergabe, Systementwicklung und

Unterhalt, Sicherstellung der Geschäftstätigkeit und schlussendlich noch die Compliance, also

die gesetzliche Konformität und internen Richtlinien.

Bei der Überprüfung der Security haben Sie erwähnt, dass der Kunde das Recht hat,

Kontrollen zu verlangen. Wie stellen Sie nun intern sicher, dass Sie „compliant“ mit den

internen Richtlinien sind?

Einerseits kann dies durch unser „Benchmark-Assessment-Tool“ bewerkstelligt werden. Dies

geschieht intern mittels Selbstkontrolle, welche durch ein Self-Assessment stattfindet. Es werden

Stichproben gemacht, um zu überprüfen, ob die Selbsteinschätzung gerechtfertigt sind. Intern

existiert eine Sicherheitsmanagementstelle, die uns überprüft. Als letzte Instanz gibt es die

externen Prüfungen.

9. Anhang 132

Das Thema IT-Security ist in den Medien sehr präsent. Meinen Sie, dass es einfach ein

Modewort wurde und Firmen dies zu Marketingzwecken verwenden oder ist die IT-Security

ein Thema, dem nicht genug Beachtung geschenkt werden kann? Wie sehen Sie die

Entwicklung?

Das Umfeld hat sich grundsätzlich verändert. Früher existierten reine Hostsysteme mit

Bildschirmen und Tastaturen. Sicherheitsthemen waren früher einerseits, dass der Raum mit den

Hostsystemen abgesichert wurden und andererseits, dass keine unbefugten Personen die Systeme

bedienten. In den letzten Jahren fand immer eine weitere Öffnung statt. Client-Server Systeme

entstanden, die mittels Firewall abgeriegelt wurden. Einzig was intern war, war

vertrauenswürdig. Damit machte man es sich zu einfach. Insbesondere das Business hatte das

Begehren, auch von auswärts Zugriff auf die Unternehmung zu erhalten, damit vom Kunden aus

weitergearbeitet werden konnte. Dadurch wurden weitere „Löcher“ in die Firewall gebohrt und

manche Dinge auch falsch konfiguriert. Der Technologiegrad hat sich eindeutig verändert.

Eine weitere Veränderung sind die Gesetze. Insbesondere durch die Finanzskandale und dem

daraus entstandenen Sarbanes-Oxley Act, wurde der Fokus vermehrt auch auf die Security

gesetzt. Die Finanzzahlen mussten stimmen, was bedeutete, dass auch dass die Systeme

einwandfrei laufen mussten. Dementsprechend wurden die Prüfgesellschaften sensibler

bezüglich der Security Thematik. Ein weiterer Punkt ist, dass Vergehen bezüglich der Security

kein Kavaliersdelikt mehr darstellt, sondern drastisch bestraft wird. All diese Tatsachen,

insbesondere mit der Bestrafung in Form von Geldbussen oder Gefängnisstrafen, haben bewirkt,

dass Security heute ein Thema ist und auch in Zukunft ein Thema bleiben wird.

Ist bei Ihnen COBIT oder ITIL ein Thema?

Es hängt alles zusammen. COBIT ist ein Framework für den Auditor in Form einer Checkliste.

ITIL hat einen anderen Ansatz. ITIL ist dazu da, um eine IT-Umgebung operationell optimal zu

betreiben. Optimale Betreibung heisst nicht nur Sicherheit, sondern auch Effizienz und

Effektivität. Wir setzten ITIL z.B. bei unserem Helpdesk, also Incident Management, ein. Es

geht bei ITIL also darum, einen Betrieb aufzubauen und zu betreiben, der funktioniert,

nachvollziehbar und kontrollierbar ist, dann ist es für den Auditor mittels COBIT auch einfach

zu prüfen. Im Vergleich dazu beschreibt der ISO 17799 Standard nur den Standard von einem

Informationssicherheitssystem. ITIL beinhaltet Sicherheit, jedoch auch ganz andere Dinge. Diese

Frameworks konkurrieren und überschneiden sich gleichzeitig.

9. Anhang 133

Sie haben einige Male von der ISO 17799 Zertifizierung gesprochen. Wieso wenden Sie bei

Unisys keinen SAS 70 Report an?

Ich kenne den Standard nicht detailliert, jedoch ist SAS 70 grundsätzlich eine Zertifizierung für

eine Service Organisation. Bei uns laufen Prozesse auf globaler Ebene ab, die nicht nur für die

Service Organisation gelten. Eine Zertifizierung sagt aus, was gemacht wurde, jedoch ist für eine

Zertifizierung wichtig, was zertifiziert wurde. SAS 70 befasst sich nur mit Dienstleistungen,

Unisys ist aber auch ein Produktionsbetrieb. Wir orientieren uns daher an den ISO 9000

Standard, denn da sind die Prozesse generell beschrieben und nicht nur für den Service Betrieb.

Uns nützt es nichts, wenn der Service Betrieb SAS 70 zertifiziert ist, jedoch die Produktion

schlecht ist. Man kann jeden einzelnen Prozess mit einer spezifischen Zertifizierung zertifizieren

lassen oder man nimmt den ISO 9000 Standard und lässt die gesamte Supply Chain zertifizieren.

Damit hat man dann die Gewissheit, dass die Prozesse ineinander greifen.

Zusammenfassend kann man sagen, dass Sie bei der Unisys primär die ISO 9000 und BS

7799-2 besitzen, die sie den Kunden kommunizieren?

Ja. Zusätzlich kann auch ein Kunde kommen und ein SAS 70 verlangen. Dann wird er es aber

auch bezahlen müssen. Wir orienteren uns danach, dass wir primär globale Zertifizierungen, wie

ISO 9000, vornehmen und die speziellen Zertifizierungen dann vornehmen, wenn es der Markt

fordert.

Gibt es andere IT-Security Zertifizierungen, die Sie benützen?

Es gibt die Common Criteria Zertifizierung, welche für die Produkte sind. Wir sind im

Firewallmanagementbereich TrueSecure zertifziert. Nebenbei gibt es auch persönliche

Zertifizierungen, wie das CISSP – Certified Information Security System Professional, CISA etc.

Vielen Dank für das aufschlussreiche und interessante Gespräch.

9. Anhang 134

Patrik Allenspach, Leiter IT-Revision Luzerner Kantonalbank

Themen:

Outsourcing aus der Outsourcer-Sicht

Rolle der Internen Revision im Outsourcing

IT-Security

Wie kamen Sie zur Entscheidung bei der Luzerner Kantonalbank (LUKB) ein Outsourcing zu

betreiben und welche Vorteile sehen Sie darin?

Über die spezifischen Entscheidungsgrundlagen für ein Outsourcing der LUKB IT kann ich

keine Aussage machen, da ich bei der Entscheidung (vor 1996) noch nicht bei der LUKB war.

Der Gedanke, dass Kosten eingespart und Synergien genutzt werden können, waren wohl die

primären Faktoren. Sekundär spielten wohl auch organisatorische Überlegungen eine Rolle, wie

z.B. die Möglichkeiten, gewisse Bereiche der Abwicklung zusammenzulegen oder auszulagern.

Von einem Outsourcing verspricht man sich immer eine Reduktion von Kosten durch Skalen-

und Synergieeffekte.

Es wurde damals die AGI-Kooperation232 gegründet, bei welcher acht Kantonalbanken

zusammen ein Outsourcing betrieben, mit dem Ziel, teure Hardware, Lizenzen, Infrastruktur und

IT gemeinsam zu nutzen, um durch die dadurch entstehenden Masseneffekte Kosten zu sparen.

Wie wird überwacht, ob die Outsourcing-Verträge bzw. die Leistungensvereinbarungen

eingehalten werden?

Bei der LUKB verfügen wir einerseits über ein IT-Controlling, welches vor allem die Finanzen

überwacht. Daneben finden auch regelmässige Meetings (sog. Betriebsmeetings) mit dem

Service Anbieter statt, im Rahmen welcher betriebliche Belange und die Einhaltung der SLA's

auf operativer Ebene besprochen werden. In der Praxis kommt es leider zu häufig vor, dass SLA

definiert werden, jedoch niemand deren Einhaltung überwacht. Darum ist dies aus Sicht des IT-

Revisors auch ein wichtiges Anliegen.

232 Die AGI-Kooperation ist ein Zusammenschluss der acht Kantonalbanken von: Appenzell-Innerrhoden, Fribourg, Glarus, Luzern, Nidwalden, Obwalden, St. Gallen und Thurgau.

9. Anhang 135

Wo sehen Sie die Gefahren beim Outsourcing?

Viele Firmen haben eingesehen, dass durch ein Outsourcing die Möglichkeit geschaffen wurde,

Kosten zu sparen, jedoch zulasten der Flexibilität. Konkret mussten wir bei der LUKB

feststellen, dass die Entscheidungswege länger wurden und es gegenüber den Zeiten, zu denen

man die IT mehrheitlich eigenständig betrieb, deutlich länger dauerte, bis Änderungen

implementiert waren. Es stellte sich heraus, dass nicht jeder Kooperationspartner Anforderungen

an Änderungen gleich stark gewichtete, was es schwierig machte, einen Konsens resp.

Kompromiss zu finden. Dies verspürte man deutlich als einen Mangel an Flexibilität.

Anforderungen, die früher innert sehr kurzer Zeit innerhalb der Bank identifiziert, beantragt,

bewilligt und umgesetzt wurden, dauern nun deutlich länger bis zur Umsetzung.

Die Basis für ein Outsourcing bildet ein Vertrag mit einer Drittpartei. Ein solcher Vertrag besteht

normalerweise aus einer grundsätzlichen Vereinbarung, die z.B. Service-Level und andere

grundlegende Basisdienstleistungen umfasst. Zusätzliche Leistungen, wie z.B. die Umsetzung

neuer fachlicher Anforderungen, müssen oft situativ vereinbart werden und kosten zusätzlich.

Dies stellt auch besondere Anforderungen an die Ressourcenplanung seitens des Outsourcers. Es

führt dazu, dass die Prozesse formeller ablaufen als früher, mehr Stufen als früher durchlaufen

werden und dadurch die Implementationszeiten ("Time to Market") zunehmen. Dies kann zu

einem empfindlichen Kostenfaktor werden.

Outsourcing bedeutet auch ein Verlust an Kontrolle. Die internen Prozesse des Service Anbieters

sind für uns nicht transparent und wir können unsere Qualitätsansprüche meist nur noch über die

Service Level Vereinbarungen steuern. Insofern müssen wir dem Service Anbieter vertrauen,

dass er seine Prozesse gut kontrolliert, weil wir durch das Outsourcing keine direkte

Qualitätskontrolle mehr durchführen können.

Eine weitere Gefahr ist das sog. „Double-Outsourcing“. Beim "Double-Outsourcing" lagert der

Service Anbieter Dienstleistungen an Dritte aus. In diesem Fall besteht eine Informationspflicht

des Service Anbieters uns gegenüber. Ohne Zustimmung unsererseits kann der Service Anbieter

kein Double Outsourcing vornehmen.

Wie können Sie als Interne Revision Einfluss auf Outsourcing-Entscheide nehmen? Werden

Sie bezüglich Vertragreview oder in anderen Phasen integriert?

Im Moment findet eine Evaluation für ein neues Outsourcing statt, in welche wir von der

internen Revision nicht aktiv eingebunden sind. Wir sind jedoch dabei, dies zu ändern, indem

9. Anhang 136

wir revisionstechnische Anforderungen an weitere Phasen zusammenstellen und diese dem

Evaluationsteam übergeben.

Ist es so, dass Sie sich anbieten müssen oder werden Sie aktiv von der Geschäftsleitung

beigezogen?

Im Moment sind wir nicht direkt integriert. Wir arbeiten daran, uns direkter einbringen zu

können.

Welche Kritierien sind für Sie entscheidend bei der Wahl eines Service Anbieters?

Aus der Revisionssicht steht das Revisionsrecht im Vordergrund, also die Möglichkeit, selbst

eine Prüfung beim Service Anbieter vorzunehmen. Ohne dieses Revisionsrecht kann die

Revision wegen der erhöhten Risiken ein Outsourcing nicht gutheissen. Gemäss EBK RS 99/2

stehen die Banken auch im Fall eines Outsourcing in der Verantwortung für die Daten,

Datensicherheit und den Betrieb. Deswegen müssen Prüfungen vorgenommen werden können

bzw. der Service Anbieter muss entsprechende Prüfberichte aushändigen können, die für uns

relevante Prüfthematiken umfassen.

Achten Sie bei der Auwahl der Service Anbieter auch darauf, welche Zertifikate vorhanden

sind? Oder sogar, ob ein SAS 70 Report vorhanden ist?

Den SAS 70 Report kenne ich nicht ausführlich. Er ist für uns "auf dem Radarschirm", wir

fühlen uns jedoch noch nicht direkt betroffen.

Prinzipiell bin ich der Auffassung, dass die Revision eines outsourcenden Kunden ein

Einsichtsrecht beim Service Anbieter haben muss. Die Mindestanforderung ist, dass der Kunde

bei der Revisionsplanung des Service Anbieters involviert ist und die Schwerpunktthemen aus

seiner Sicht einbringen kann. Ein Standardreporting wäre aus meiner Sicht nur akzeptierbar,

wenn es zu denjenigen Gebieten eine angemessene Aussage enthält, die in unserer eigenen

Risikoanalyse vorhanden sind.

Nach meinen Informationen ist der SAS 70 ein mehr oder weniger standardisierter Bericht, der

die gesammte Dienstleistungspalette des Service Anbieters abdeckt; insofern erachte ich das

Erstellen eines SAS 70 Berichts als sehr aufwändig. Die Herausforderung bei der Erstellung des

SAS 70 Berichts ist es, mit nur einem Bericht relevante Aussagen sowohl für die externen

9. Anhang 137

Prüfgesellschaften als auch für die internen Revisionen der Outsourcing-Kunden darzulegen. Ich

gehe davon aus, dass ein standardisierter SAS 70 Bericht unseren Anforderung an

Detaillierungsgrad vorerst nicht genügt und deshalb weiterhin die Möglichkeit bestehen muss,

gewisse Themen beim Outsourcer zusätzlich vertieft zu prüfen. Welche andere Zertifizierungen

bei der Auswahl behilflich sind, kann ich im Moment nicht beurteilen. Im Bankenumfeld sind

die Vorschriften durch das EBK RS 99/2 klar definiert. Ein Service Anbieter muss diese

Regelung auch verinnerlichen, obwohl die Verantwortung zur Einhaltung gemäss EBK RS 99/2

beim Outsourcer liegt.

Welche Auswirkungen hat das EBK RS 99/2 auf die Prüftätigkeit oder Organisation gehabt?

Das EBK RS 99/2 hat einzig auf das Bewusstsein der Revisoren eine Auswirkung gehabt. Das

Rundschreiben beschreibt eigentlich nichts neues, jedoch wurden Verantwortlichkeiten, die

bisher in dieser formellen Form nicht dokumentiert waren, in diesem Rundschreiben für Banken

verbindlich gemacht. Von der Prüftätigkeit hat sich ausser dieser Verbindlichkeit nichts

geändert. Es ist auch so, dass z.B. Finanzdienstleister, die nicht dem EBK RS 99/2 unterliegen,

ebenfalls auf ein Revisionsrecht bei den Service Anbieter bestehen.

Können Sie die Zusammenarbeit zwischen Ihnen als Interne Revision und dem Service

Anbieter beschreiben? Wie nehmen Sie die direkten Prüfungen vor und welche anderen

Formen der Zusammenarbeit bestehen?

Es wurde ein Fachausschuss Revision gebildet, der sich aus der Internen Revision der grossen

Banken innerhalb der AGI-Kooperation und zusätzlich den Mitgliedern der Internen Revision

des Service Anbieters zusammensetzt. In der Jahresplanung werden Prüffelder mit Schwerpunkt

auf das Bankenumfeld identifiziert. Diese Planungsinformation fliesst dann in den

übergeordneten Prüfplan des Service Anbieters ein. So soll gewährleistet sein, dass unsere

Bedürfnisse in die Revisionsplanung des Service Anbieters einfliessen und wir die

entsprechenden für uns relevanten Aussagen erhalten. Wir nehmen auch direkt beim Service

Anbieter Prüfungen vor, wenn es sich um Prüfungen handelt, die spezifisch die Leistungen an

unsere Banken betreffen. Es kommt damit zu einer Aufgabenteilung: Unser Schwerpunkt liegt

auf der Überprüfung der bankenspezifischen Belange. Die Interne Revision des Service

Anbieters bzw. deren externe Prüfgesellschaft übernimmt Prüfungen bei Themen, die für alle

Outsourcing-Kunden relevant sind.

9. Anhang 138

Nach welchen Kriterien werden die Themen für die Prüfung definiert?

Neben einer systematischen Risikoanalyse spielen auch Gebiete eine Rolle, die aus Erfahrung

problematisch sind. Es handelt sich dabei beispielsweise um neu eingeführte Applikationen oder

Teile des IT-Betriebs, welche wiederholt nicht funktionierten.

Haben Sie das Gefühl, dass durch das Outsourcing ein Mehraufwand für Sie entstanden ist?

Der Revisionsaufwand ist aus meiner Sicht gleich geblieben. Wir sind vier grosse

Kantonalbanken, die in einem speziell zu diesen Zwecken gebildeten Ausschuss beim Service

Anbieter IT-Prüfungen durchführen. Da die vom Anbieter bezogenen Dienstleistungen für alle

vier Banken mehrheitlich identisch sind, kann der Revisor einer Bank im Auftrag dieses

Ausschusses Aspekte prüfen, die für alle vier angeschlossenen Banken relevant sind. So können

Synergieeffekte genutzt werden. Dies ermöglicht einen effizienten Ressourceneinsatz. Wenn z.B.

ein Monitoring Audit gemacht wird, so muss dies nicht für jede Kantonalbank separat gemacht

werden, sondern es wird eine Prüfung mit den Wünschen aller Kantonalbanken vorgenommen

und die Resultate allen vier Banken zur Verfügung gestellt. Das Outsourcing erzeugt jedoch

einen deutlich spürbaren Mehraufwand bezüglich Koordinationsaufgaben, da der Zugriff auf

Ansprechpartner beim Service Anbieter formeller abläuft als bei bankeigenen Ressourcen. Auch

die Koordination der Prüfungstätigkeit unter den vier beteiligten Banken erzeugt einen

Mehraufwand. Die Erfahrung hat gezeigt, dass eine Prüfung beim Outsourcer bei

gleichbleibender Prüftiefe merklich mehr Aufwand benötigt als eine Prüfung mit analoger

Prüftiefe bei einer internen IT.

In den Theoriebüchern, wie auch beim EBK RS 99/2, steht geschrieben, dass der Service

Anbieter mit dem Outsourcer gemeinsam ein Sicherheitskonzept erarbeiten soll. Geschieht das

bei Ihnen und was sind die relevantesten Themen?

Ja, eine gemeinsame Erarbeitung des Sicherheitskonzeptes wird vorgenommen. Wir haben

Einsitz in den Sicherheitsgremien der Service Anbieter. Beim Sicherheitskonzept haben die

verschiedenen AGI-Kooperationsbanken aktiv mitgearbeitet. Themen, die in einem

Sicherheitskonzept vorkommen, sind z.B. Verschlüsselung und Sicherheit von Daten,

Aktualisierung von Virenschutz der Systeme, Vertraulichkeit oder Zugriffsrechte,

Grundschutzanforderungen etc.

9. Anhang 139

Welche Parteien sind bei der IT-Security Konzepterstellung integriert?

Bei unserem Outsourcing nannte sich dies bis vor kurzem „IT-Security Board“. Dieses Board

besteht aus den IT-Security-Verantwortlichen der Kantonalbanken und des Service Anbieters.

Dieses Gremium tagt ca. alle zwei Monate und widmet sich aktuellen sicherheitsrelevanten

Themen.

Wer trägt die Verantwortung wenn z.B. die Systeme nicht funktionieren? Schlussendlich

erleidet Ihr Ruf einen Schaden.

In den SLA ist unter anderem festgelegt, welche Anforderungen an Verfügbarkeit und Stabilität

der Betrieb der Systeme genügen muss. Es ist üblich, dass ein Service Anbieter für kritische

Systeme, wie z.B. ein Netzwerk, eine Verfügbarkeit von über 99% garantieren muss. Wird ein in

den SLA vereinbarter Wert unterschritten, ist es üblich, dass der Anbieter sog. "Service Credits",

also einen Teil der Outsourcing-Kosten, welcher aus der Dauer des Ausfalls abgeleitet wird,

zurückestattet. Für einen aus Ausfällen entstandenen Geschäftsverlust ist der Service Anbieter in

der Regel nicht verantwortlich. Entsprechende Haftungsausschlüsse sind vertraglich

festgehalten. Der Service Anbieter wird an der Einhaltung und Qualität der vereinbarten

Dienstleistung gemessen. Die Vereinbarung von SLA stellt eine wichtige Grundlage dafür dar.

Wie schätzen Sie die Thematik der IT-Security ein? Ist IT-Security ein Modewort und

Marketinginstrument oder wird der Thematik zu Recht so viel Beachtung geschenkt?

Aus meiner Sicht ist die Beachtung gerechtfertigt. Die IT ist schnelllebig, jedoch die Security

noch schnelllebiger. Die Bedrohungslage ist sehr breit und erweitert sich jeden Tag. Es ist

meiner Meinung nach sehr wichtig, dass die richtigen Anstrengungen bezüglich der Sicherheit

gemacht werden. Der Reputationsschaden, der entstehen würde, wenn Daten unbefugt

entnommen und publiziert würden, wäre nicht wieder gut zu machen. Es ist leider ein immer

noch weit verbreitetes Problem, dass der wirtschaftliche Nutzen von IT-Security schlecht

nachgewiesen werden kann. Deshalb ist dies ein Bereich, der lange unter (zu) kleinen Budgets

gelitten hat. IT-Security kann als eine präventive Versicherung angesehen werden.

9. Anhang 140

Um auf das Thema Prüftätigkeit im IT-Security Bereich zu sprechen zu kommen: Wie gehen

Sie konkret bei einer IT-Security Prüfung vor?

Zuerst wird in einer initialen Risikoanalyse z.B. anhand einer Jahresplanung ein Prüfgebiet

identifziert.

Die Prüfung beginnt dann mit der Planungsphase. In dieser Planungsphase ist es wichtig, sich

einen Überblick über das zu prüfende Gebiet zu verschaffen und das zu prüfende Gebiet zu

verstehen. Dabei folgt eine systematische Risikoanalyse, welche die Schwerpunkte der Prüfung

definiert, woraus dann ein detaillierter Prüfplan abgeleitet werden kann Es muss sichergestellt

sein, dass das zu prüfende Gebiet vollständig d.h. mit allen Systemen, Prozessen und

eingesetzten technischen Mitteln erfasst wird.

Nach dieser wichtigen Planungsphase werden die Prüfungshandlungen mit Hilfe der

identifizierten Ansprechpartner durchgeführt.

Eine gute Referenz für die Planung von solchen Prüfungen im Bereich IT-Security ist das

COBIT. COBIT stellt im Punkt „DS5-Ensure Systems Security“ sehr umfassend die

Anforderungen an die IT-Security dar. Es fokussiert dabei auf Vollständigkeit der Abdeckung

und weniger auf Detaillierungsgrad. So kann bei der Planung einer Prüfung identifiziert werden,

welche Gebiete abgedeckt werden müssen. Viele Prüfer verwenden COBIT als Prüfraster. Ich

persönlich bevorzuge es, mir vorgängig selber Gedanken zu machen, was ich prüfen will, um

danach im COBIT zu kontrollieren, ob meine Überlegungen vollständig sind. COBIT dient mir

dabei als Qualitätssicherung.

Sie haben erwähnt, dass zuerst die Risiken identifiziert werden. Welche Risiken bestehen bei

der IT-Security?

Die Risiken im IT-Security Bereich sind vor allem: Vertraulichkeitsproblem, Zugriffsproblem,

Problem der offenen Systeme, Datensicherheit oder Personal.

Heisst das, dass Sie bei der Rekrutierung des Personals beim Service Anbieter integriert sind?

Von Interesse ist, wie der Rekrutierungsprozess beim Service Anbieter aussieht, denn es sind

Leute, die mit unseren Bankdaten zu tun haben. Wir verlangen, dass eine

Vertraulichkeitserklärung unterschrieben wird und die Mitarbeiter laufend geschult werden. Uns

ist wichtig, wie die Prozesse bei der Rekrutierung ablaufen und wie die Personen überprüft

9. Anhang 141

werden. Schlussendlich rekrutiert der Service Anbieter die Personen selber, hat jedoch unsere

Restriktionen zu berücksichtigen.

Welchen Schwierigkeiten sind Sie bei der IT-Security Prüfung ausgesetzt?

Die Herausforderungen bei IT-Security-Püfung liegen besonders in der Komplexität der Materie.

Als Beispiel sei hier die Netzwerksicherheit genannt. Für eine Prüfung in diesem Bereich muss

man fast immer Spezialisten beiziehen, da nur solche Leute die entsprechenden

Sicherheitsmechanismen in genügender Tiefe verstehen. Aus meiner Erfahrung muss man bei

IT-Security-Prüfung sehr methodisch vorgehen, da grosse Datenmengen anfallen, die

ausgewertet werden müssen. Es handelt sich oft um Einhalteprüfung oder eine Analyse von

komplexen Konfigurationsdaten.

Eine weitere Herausforderung der IT-Security, die nicht prüfungsspezifisch ist, aber in

Unternehmen immer vorkommt, sind die zwei existierenden Fronten: Business und IT. Das

Business will die Systeme möglichst offen halten, damit die Geschäfte möglichst effizient

abgewickelt werden können. Die IT-Security will die Systeme jedoch möglichst sicher machen.

Deshalb müssen bei der Einführung von neuen Systemen oft Kompromisse von beiden Seiten

eingegangen werden. Wenn Sicherheitslücken offen gelassen werden, dann hat dies nach einer

vertieften Risikoanalyse bezogen auf diese Lücken zu geschehen, unter Zustimmung von IT-

Security mit gegebenenfalls nachfolgender erhöhter Überwachung und unter Akzeptanz der

dadurch entstehenden Risiken durch das Business.

COBIT wurde vorgängig häufig erwähnt. Können Sie mir sagen, welche Stellung COBIT und

ITIL bei Ihnen besitzen? Verlangen Sie vom Service Anbieter, dass er sich gemäss diesen

Standards orientiert?

COBIT ist neben ITIL ein relevanter Standard, der international anerkannt ist. Wenn eine

Prüfung vorgenommen wird, so stützen wir uns einerseits auf das Revisionswissen bzw. auf die

Revisionserfahrung und andererseits wird COBIT konsultiert, um sicherzustellen, dass die

relevanten Fragestellungen in einem Prüffeld betrachtet werden. Unter Verwendung von COBIT

kann ich sicherstellen, dass ich ein Prüffeld vollständig in der Breite prüfe und den wichtigen

Aspekten Rechnung trage. Vom Service Anbieter wird nicht verlangt, dass seine IT exakt

gemäss COBIT ausgerichtet ist, jedoch wäre dies aus Revisionssicht natürlich wünschenswert.

9. Anhang 142

ITIL wird, im Gegensatz zu COBIT, welches von den Revisoren verwendet wird, bevorzugt vom

IT Management verwendet. Während COBIT darauf fokussiert, welche Kontrollen in einem

Prüffeld existieren müssen (was muss gemacht werden?), geht ITIL vertieft darauf ein, wie die

Abläufe aufgebaut werden können (wie muss es gemacht werden?). Insofern besteht eine

Beziehung zwischen ITIL und COBIT. Es gibt Darstellungen, die aufzeigen, dass ITIL und

COBIT inhaltlich grösstenteils deckungsgleich sind, also dieselben Themenbereiche

dokumentieren; der Unterschied liegt dabei darin, wie dies in COBIT und ITIL dokumentiert ist.

Wenn nun ein Unternehmen ITIL konsequent anwendet, indem es zum Beispiel seine IT-Abläufe

nach ITIL ausgerichtet hat, so kann man davon ausgehen, dass die relevanten Anforderungen

auch aus aus Sicht von COBIT erfüllt sind.

Wie gesagt, schreiben wir dem Service Anbieter nicht vor, wonach er sich zu orientieren hat. Es

muss aber gewährleistet sein, dass der Service Anbieter die von uns gestellten Anforderungen

erfüllt. Wie er das macht, ob mit ITIL, COBIT oder einer anderen Methodik, ist ihm überlassen.

Aus Sicht der Revision ist COBIT die bevorzugte Referenz zur Planung und Durchführung von

Prüfungen.


9. Anhang 143

Jürg Illi, Interne Revision, Credit Suisse Group

Themen:

Outsourcing aus der Sicht des Outsourcer

Prüfung von outgesourcten Leistungen

IT-Security Prüfung

In welchem Umfang wird in der Credit Suisse Group ein Outsourcing betrieben? Welche

Chancen und Gefahren sehen Sie in Ihrem Outsourcing?

Wir betreiben kein vollumfängliches IT-Outsourcing. Nur ein gewisser, relativ kleiner Teil

unserer IT wird von Service Anbietern betrieben. Was bei uns aber häufiger vorkommt ist das

Offshoring. Insbesondere Programmieraufträge aus ausgewählten Projekten werden z.B. nach

Indien abgegeben. Wir erhoffen uns durch unser Outsourcing bzw. Offshoring, dass Kosten

eingespart werden und die Qualität durch die spezialisierten Firmen verbessert wird. Als grosse

Gefahr sehen wir den Verlust der Kontrolle über die abgegebenen Bereiche. Damit dieses Risiko

reduziert werden kann, müssen die Outsourcing-Verträge entsprechend aufgesetzt werden.

Welche Inhalte sprechen Sie an?

Damit wir als Interne Revision unserer Hauptaufgabe, nämlich die Überprüfung des Internen

Kontrollsystems wahrnehmen können, sollte der Vertrag mit dem Service Anbieter, das

sogenannte Revisionsrecht beinhalten; d.h. wir sollten das Recht haben beim Service Anbieter zu

revidieren. Weiterhin muss der Service Anbieter unsere Sicherheitsanforderungen und

Weisungen beachten. Auch dies ist vertraglich festzulegen.

Inwiefern können Sie, als die Interne Revision, Einfluss auf Outsourcing-Entscheide

nehmen?

Unsere Aufgabe ist die Prüfung des internen Kontrollsystems. Bei einem Entscheid bezüglich

Outsourcing müssen wir nicht zwingend beigezogen werden. Im Moment ist es bei uns so, dass

wir bisher nicht aktiv in die Wahl des Service Anbieters oder den Entscheid eines Outsourcing-

Vorhabens involviert waren. Solche strategischen Entscheide werden vom Top-Management

9. Anhang 144

gefällt. Was wir machen, ist uns in Form von beratenden Tätigkeiten einzubringen. Die

Entscheidungskompetenz, ein Outsourcing zu vollziehen liegt nicht bei uns.

Teile der IT wurden ausgelagert. Heisst das nun für Sie, dass diese Bereiche nicht mehr

vollständig in Ihrem Prüffokus liegen?

Das EBK 99/2 Rundschreiben entbindet den Outsourcer nicht von der Kontrolle der

outgesourcten Bereiche. Da bei uns im IT-Bereich nur in relativ geringem Mass ausgelagert

wird, sind wir ziemlich gut über die ausgelagerten Bereiche informiert. Bei gewissen,

wesentlichen Service Anbietern besitzen wir zusätzlich das Recht, einmal im Jahr direkt eine

Prüfung bei ihm vor Ort durchführen zu können.

Sie haben das EBK RS 99/2 angesprochen. Welchen Einfluss hatte dieses Rundschreiben auf

die Credit Suisse Group?

Aufbauend auf dieses EBK Rundschreiben hat die Credit Suisse Group eine separate Weisung

erlassen, welche zur Aufgabe hat, dieses Rundschreiben zu konkretisieren und auf unsere

Verhältnisse zu adaptieren. Diese Weisung muss bei jedem getätigten Geschäft eingehalten

werden und unsere Aufgabe dabei ist, die Einhaltung zu überprüfen. Das EBK Rundschreiben

selbst ist eher allgemein gehalten, es schränkt die Outsourcing-Tätigkeit der Credit Suisse kaum

ein. Das Rundschreiben und die entsprechende Weisung sind bei jedem Outsourcing-Vorhaben

zu konsultierten und einzuhalten.

Das Rundschreiben enthält wenig Neues. Es hat jedoch dazu beigetragen, dass wesentliche

Outsourcing-Aspekte wieder in die Erinnerung gerufen und die Verantwortlichkeiten klar

festgehalten wurden.

Um nochmals zur Thematik Outsourcing und deren Kontrolle zurückzukommen. Was machen

Sie mit Outsourcing Partnern, die wiederum ein Outsourcing betreiben? Stichwort: Double-

Outsourcing – wie haben Sie dies unter Kontrolle?

Diesbezüglich müssten die Verträge konsultiert werden. Ich weiss nicht, ob in den Verträgen

vorgesehen ist, dass wir vom Service Anbieter informiert werden müssen. Mir sind Fälle aus

dem Bereich Liegenschaftsverwaltung bekannt, bei denen der damalige Betreiber gewisse Teile

im Subcontracting-Verfahren weitergegeben hat. Im IT-Bereich stellen wir an unseren Service

9. Anhang 145

Anbieter gewisse Anforderungen, die dieser erfüllen muss. Ob diese Anforderungen nun dem

Subcontractor weitergegeben werden, ist für uns schwierig zu kontrollieren. Solche

Punkte/Vorgaben sind in den Vertragsverhandlungen anzusprechen und entsprechende

Vereinbarungen mit dem Service Anbieter sollten getroffen werden.

Meiner Meinung nach stellt das Double-Outsourcing ein zusätzliches Risiko des Outsourcing

dar, das man in Betracht ziehen muss, aber möglicherweise als Outsourcer nur beschränkt

beeinflussen bzw. reduzieren kann.

Gerne würde ich den Fokus nun auf die IT-Security und deren Prüfung legen. In der

Literatur wird oftmals von einer gemeinsamen Ausarbeitung des IT-Sicherheitskonzepts

zwischen dem Service Anbieter und dem Outsourcer gesprochen. Besteht bei Ihrem

Outsourcing auch ein gemeinsam erarbeitetes Sicherheitskonzept?

In unserem Fall ist es so, dass die Stelle, die sich bei uns mit der IT-Security beschäftigt, die

Sicherheitskonzepte in einem solchen Projekt beurteilen muss oder für die Erstellung eines

solchen beigezogen wird. Dies im Unterschied zur Internen Revision, die nicht in solche

Entscheide einbezogen wird. Die IT-Security Verantwortlichen kennen unsere Weisungen,

Standards und Rundschreiben und bringen sie in die Verhandlungen ein und sorgen dafür, dass

diese auch wirklich eingehalten werden.

Die gemeinsame Ausarbeitung des Sicherheitskonzepts kann ich nicht für jeden Fall bestätigen.

Hingegen ist es bei uns so, dass die interne IT-Security Abteilung die Sicherheitsanforderungen

einbringt.

Könnten Sie einige relevante Themen des Sicherheitskonzepts nennen? Zusätzlich würde ich

gerne wissen, ob Sie sich zur Erstellung des Sicherheitskonzepts auf eine Referenz wie ISO

17799 oder IT-GSHB stützen?

Es gibt in der gesamten Credit Suisse Group für jede Business Unit Weisungen, die IT

Sicherheitsgrundsätze festlegen. Diese Weisungen orientieren sich am ISO 17799 Standard. Zu

den wesentlichen Aspekten dieses Standard gibt es entsprechende Weisungen. Hier ist z.B. die

Netzwerksicherheit, Zugriffsschutz oder Authentisierung zu nennen. Diese Weisungen sind recht

umfassend. Unsere Aufgaben ist die Umsetzung und Einhaltung der Weisungen zu überprüfen.

Dieses Vorgehen reicht in den meisten Fällen aus, um die wesentlichen Risiken abzudecken.

9. Anhang 146

Das IT-GSHB wird bei uns wenig berücksichtigt, der Fokus liegt eindeutig beim ISO 17799

Standard.

Diese Weisungen bestanden also schon vorgängig bei der Credit Suisse Group und diese

Weisungen machen Sie für Ihren Service Anbieter auch verbindlich?

Ja, wir kommunizieren diese Anforderungen an den Service Anbieter. Ziel ist dabei, dass durch

ein Outsourcing unsere Sicherheitsanforderungen nicht beeinträchtigt werden.

Die Einhaltung wird bei unserem Audit beim Service Anbieter stichprobenweise überprüft.

Hierzu sei angemerkt, dass eine Überprüfung beim Service Anbieter deutlich schwieriger zu

bewerkstelligen ist, als das Durchführen einer internen Prüfung. Falls Feststellungen gemacht

werden, die Anträge zu Verbesserungen vorsehen, besteht für uns nicht ohne weiteres die

Möglichkeit, unseren Service Anbieter direkt zu adressieren. Der Service Anbieter „akzeptiert“

uns nicht als Interne Revision. Unser Antrag muss zuerst an den Bereich innerhalb der Credit

Suisse gestellt werden, der für das Outsourcing verantwortlich ist und entsprechend eine

Beziehung zum Service Anbieter unterhält. Diese Stelle leitet unsere Anträge dann weiter. D.h.,

dass es für uns als Interne Revision der Credit Suisse Group oft nicht möglich ist, einen Antrag

direkt beim Service Anbieter zu platzieren.

Um nochmals auf das Sicherheitskonzept zu sprechen zu kommen. Können Sie noch ein Wort

über die Verantwortlichkeitsverteilung im Sicherheitskonzept verlieren?

Projektgremien gemäss unserem Projektvorgehen sehen Vertreter aus dem „Business“ und aus

der „IT“ in jedem Projekt vor. Jedes Projekt muss auch ein Sicherheitskonzept erstellen. Die

Verantwortlichen für IT-Security genehmigen das Sicherheitskonzept. Bei Outsourcing-

Vorhaben sind zusätzlich Vertreter der Rechtsabteilung involviert. Es finden regelmässige

Sitzungen in diesem Projektgremium statt, wobei vermutlich IT-Security Aspekte selten im

Vordergrund stehen.

9. Anhang 147

Mit den nächsten Fragen würde ich gerne spezifisch auf die IT-Security Prüfung eingehen.

Spielt es für die IT-Security Prüfung eine Rolle, ob outgesourcte oder nicht-outgesourcte

Bestandteile geprüft werden?

Es gibt keinen inhaltlichen Unterschied betreffend der Themen, die geprüft werden. Die

Einhaltung unserer Weisungen wird geprüft, egal ob die Leistungen intern oder extern erbracht

werden. Zur Zeit führen wir IT-Security Prüfungen mehrheitlich von intern erbrachten

Leistungen durch. Geprüft werden die von uns identifizierten Risiken, unabhängig davon ob es

sich um einen outgesourcten Bereich handelt oder nicht.

Wie geschieht bei Ihnen die Risikoidentifizierung? Wer bestimmt die Risiken?

Die Risiken werden hauptsächlich während der Jahresplanung eruiert. Jeder Geschäftsbereich bei

uns hat seine eigenen Risiken, die definiert werden bzw. wurden. Die Risiken werden mittels

einem Tool (Risks Assessment Model) durch erfahrene Interne Revisoren unter Einbezug von

erfahrenen Vertretern der Geschäfts- und IT-Bereiche identifiziert. Diese Risikoanalyse wird mit

der Wesentlichkeit ergänzt. Die Kombination von Risiko und Wesentlichkeit ergibt die

Häufigkeit der Prüfungen, die wir im entsprechenden Geschäftsbereich durchzuführen haben,

d.h. ob sie jährlich oder bis maximal fünfjährig geprüft werden müssen. Bei der Planung einer

konkreten Revision untersucht man die verschiedenen Geschäftsbereiche und Systeme der zu

prüfenden Einheit nochmals auf Risiken und Wichtigkeit. Zu diesem Zeitpunkt dient das

COBIT-Framework als Basis für die Prüfung. Wir entscheiden im konkreten Einzelfall, welche

Aspekte (Control Objectives) nun spezifisch angeschaut werden müssen.

Welche Gebiete müssen aus Ihrer Sicht in einer IT-Security Prüfung unbedingt geprüft

werden? Stützen Sie sich bei der Themenwahl auf ISO 17799?

Insbesondere bei den Banken ist der sichere Umgang mit Kundendaten ein wichtiges Thema.

Weitere Themen sind Zugriffsverwaltung oder Vertraulichkeitsfragen. Bei der Themenwahl

stützen wir uns dabei auf ISO 17799.

Sie haben vorher COBIT angesprochen. Welche Rolle nimmt COBIT bei Ihnen ein?

ISO 17799 ist unser Referenzstandard, dem das ganze Weisungswesen zu Grunde liegt. COBIT

stellt für uns der Ausgangspunkt für das Prüfprogramm und die „Anleitung“ für die

9. Anhang 148

entsprechende Prüfung dar. Wir nehmen die Kontrollobjekte des COBIT und wählen dann

spezifisch für die Prüfung daraus aus, was im konkreten Fall wesentlich ist.

COBIT stellt für uns nicht nur eine Vollständigkeitsreferenz dar, sondern wir leiten unsere

Prüfprogramme aus COBIT her. COBIT ist sehr umfassend und gewährleistet eine gewisse

Vollständigkeitskontrolle. Mit COBIT haben wir in der Internen Revision überwiegend gute

Erfahrungen gemacht.

Für die IT-Security Prüfung definiert COBIT mit dem DS5 eine Richtline. Wir benutzen diesen

COBIT IT-Prozess für unsere Prüfung. Primäres Prüfziel bleibt aber die Einhaltung unserer

Weisungen und der zusätzlichen Standards, die wesentlich weiter gehen als COBIT.

Wie gehen Sie konkret bei der Prüfung der IT-Security vor? Führen Sie z.B. Penetrations-

tests oder ähnliche Dinge durch oder gehört dies nicht zum Prüfvorgang?

Penetrationstests gehören nicht zu unserem Prüfumfang. Wir prüfen auf konzeptioneller Ebene,

d.h. prüfen ob ein Konzept vorhanden ist, das Fragen beantwortet, wie das Testing gemacht wird,

wie häufig es durchgeführt wird, wer die Tests durchführt und welches die Resultate aus

früheren Tests sind. Wir prüfen auch betriebsorganisatorische Aspekte im Zusammenhang mit

der Firewall-Administration. Grundsätzlich betrachten wir solche Arten von Tests nicht als

unsere Kernkompetenz, sondern konzentrieren uns darauf, die Kontrollen zu beurteilen und dafür

zu sorgen, dass den Test-Resultaten aktiv nachgegangen wird.

Falls ein Penetrationstest durchgeführt werden sollte, dann muss dies mit mehreren internen

Fachpersonen abgesprochen werden. Ein Penetrationstest darf den normalen Betrieb möglichst

wenig beeinträchtigen und muss deshalb mit allen involvierten Stellen besprochen und genau

geplant werden.

Was sind die weiteren Schritte bei Ihrer Prüfung, wenn Sie eine Beanstandung, sog. Findings,

entdeckt haben?

Das Resultat einer Prüfung ist ein Revisionsbericht mit detaillierten Anträgen unsererseits. Zu all

diesen Anträgen verlangen wir eine Stellungnahme der geprüften Stelle und zusätzlich ein

Umsetzungsdatum, welches angibt bis wann die Beanstandungen behoben sind. Wir haben also

nicht nur ein Finding, eine Feststellung, sondern gehen noch weiter und geben Empfehlungen ab

und zusätzlich verlangen wir von der geprüften Stellen, die Anträge innerhalb einer Frist

9. Anhang 149

umzusetzen. Wir benutzen ein Pendenzenverwaltungssytem der Credit Suisse, das alle

Pendenzen festhält und zur Kontrolle für die Umsetzung und Bearbeitung der Pendenzen dient.

Wird ein Finding bearbeitet, bzw. entsprechende Massnahmen implementiert, so muss die

betroffene Stelle dies im Pendenzenverwaltungssystem rapportieren. Quartalsweise prüfen wir

auf Stichprobenbasis das Pendenzen-verwaltungssystem und überprüfen, ob Massnahmen, die

als umgesetzt dokumentiert wurden, auch wirklich implementiert sind.

Wer sind die Adressaten des Revisionsberichts?

Der Revisionsbericht geht an das Top-Management und an den Verwaltungsrat. Die einzelnen

Anträge werden direkt an die geprüften Personen und deren Vorgesetzte weitergeleitet, damit

diese umgehend bearbeitet werden können.

Welchen Schwierigkeiten sind Sie bei der IT-Security Prüfungsdurchführung ausgesetzt?

In der Prüfungsdurchführung begegnen wir eigentlich keinen grösseren Schwierigkeiten.

Schwierigkeiten bereiten uns eher die Durchsetzung der verschiedenen Anträge. Häufig wird von

der geprüfte Stellen argumentiert, dass Kosten und Aufwand den Nutzen übersteigen. Es liegt

aber in unserer Verantwortung, die vorhandenen Risiken aufzuzeigen und Anträge zu deren

Reduktion bzw. Minimierung zu stellen. Über solche Risiken und unsere Anträge wird mit der

geprüften Stelle mitunter intensiv diskutiert und argumentiert.

Welchen Einfluss auf die Jahresplanung haben aktuelle Ereignisse der IT-Security? Vor rund

einem Monat gab es bei der Credit Suisse eine sog. Phishing-Attacke. Hatte dies einen

Einfluss auf die Planung?

Auf die Jahresplanung hat es insofern einen Einfluss, als ein solches Ereignis nun als neues bzw.

als zusätzliches Risiko betrachtet wird. Zu überlegen ist dann, ob diese Risiken nächstes Jahr

abgedeckt werden sollen. Zuerst werden interne Abklärungen gemacht, ob bereits Massnahmen

bestehen, die zweckmässig sind, die neuen Risiken zu minimieren. Es wird geprüft, welche

Mittel vorhanden sind und welche Vorkehrungen getroffen wurden, um solche Risiken in

Zukunft abzuwenden. Bei der Credit Suisse wurde im Zusammenhang mit der Phishing-Attacke

eine bestehende IT-Security Awarness-Kampagne ergänzt und intensiviert. Ausserdem besteht

bei der Credit Suisse ein Incidence Response Team. Dass bei uns eine Phishing-Attacke

9. Anhang 150

stattgefunden hat, lässt vermuten, dass wir in diesem Bereich noch zu wenig Vorkehrungen

getroffen haben.

Unmittelbar nach der Attacke galt es, als erstes die Leute zu informieren. Die Aufgabe der

Internen Revision besteht nicht darin, bereits bekannt Risiken verstärkt zu adressieren. Dafür

gibt es meist genügend Stellen und Gremien, die entsprechende Massnahmen einleiten. Unsere

Aufgabe besteht idealerweise darin, auf Risiken aufmerksam zu machen, die noch nicht entdeckt

wurden. Bei der Phishing-Attacke handelte es sich um ein Risiko, das schon länger bekannt war.

Dadurch, dass unsere Gegenmassnahmen noch nicht besonders ausgereift waren, konnte eine

solche Attacke gewisse Erfolge zeitigen.

Wie sehen Sie die Entwicklung der IT-Security? Wird IT-Security mehrheitlich als Modewort

wie z.B. IT-Outsourcing verwendet und dabei von Firmen nur zu Marketing-zwecken

angepriesen oder wird der IT-Security zu Recht einen derart wichtigen Stellenwert

eingeräumt?

IT-Security wird oft als Schlagwort verwendet. Eine genaue Begriffsumschreibung oder

Definition fehlt meist. Meiner Meinung nach steht IT-Security zu recht im Fokus. Die Bedeutung

wird in meinen Augen über die Jahre Bestand haben, natürlich nicht immer mit den gleichen

Themen, dem gleichen Fokus. In der Vergangenheit beispielsweise standen Hostsyteme als

kaum vernetzte Systeme mit spezifischen Sicherheitsrisiken im Zentrum. Heute basieren

praktisch alle Benutzerarbeitsplätze auf dezentralen Systemen mit Internetanbindung, was zu

einem ganz anderen Risikoprofil führt und andere Sicherheits-massnahmen erfordert. Weitere

aktuelle oder zukünftig wichtige Themen wie z.B. Outsourcing oder Wireless-Networking

rechtfertigen die mediale Präsenz der IT-Security.


9. Anhang 151

Michel Huissoud233, Vize-Direktor Eidgenössische Finanzkontrolle

Themen:

Revision im Outsourcing aus Sicht der Internen und Externen Revision

Allgemeine Besonderheiten der Revision im Outsourcing

In welchem Stadium des Outsourcing-Prozesses sollte aus Ihrer Sicht die Interne Revision des

Outsourcer miteinbezogen werden?

Die Interne Revision soll meiner Meinung nach so früh wie möglich integriert werden.

Wünschenswert wäre, dass sie sich sogar bei der Entscheidung eine Outsourcing-Möglichkeit zu

verfolgen oder nicht, einbringen könnte. Eine Frage, die durch die Interne Revision zu behandeln

wäre, ist die Beurteilung der strategischen Bedeutung der zum Outsourcing vorgeschlagenen

Prozesse.

Die weiteren Phasen, bei der die Interne Revision integriert werden müsste, wären z.B. bei der

Erstellung eines Pflichtenhefts oder bei der Wahl des Service Anbieters. Geht man ein paar

Schritte weiter, so zählt die Vertragsgestaltung sicherlich zu den wichtigsten Aufgaben. Hier

müsste die Interne Revision z.B. darauf achten, dass messbare Ziele definiert und vertraglich

niedergeschrieben werden.

Wie Sie vorhin erwähnt haben, haben Sie auch in Ihrem Artikel erwähnt, dass Dinge wie

Pflichtenhefterstellung oder Vertragsreview zu den Aufgaben der Internen Revision gehören

sollten. Wie haben Sie das in der Praxis erlebt? Wird die Interne Revision gemäss Ihren

Vorstellungen eingesetzt?

Innerhalb der Bundesverwaltung besitzen wir die Stellung, dass wir bei einem Outsourcing die

Verträge vor dem Outsourcing geprüft haben. Es gab nun aber seit dem Jahre 2000/2001 eine

Reorganisation innerhalb der Bundesverwaltung. Dabei wurden die Leistungserbringer und

Leistungsbezüger voneinander getrennt. Früher hatten verschiedene Verwaltungen ihre eigenen

Rechenzentren und alles war dezentralisiert. Heute gibt es für jedes Departement einen

233 Herr Huissoud ist der Verfasser des in dieser Arbeit zitierten Artikels: „IT-Outsourcing und Revision“. Vgl. Huissoud (2002).

9. Anhang 152

Leistungserbringer. Für das Eidgenössische Finanzdepartament ist dies z. B. das Bundesamt für

Informatik, welche Leistungen für die verschiedenen Verwaltungen erbringt. Somit betreiben wir

intern ein Outsourcing. Auch mit dem Bundesamt für Informatik wurden SLA definiert. Unsere

Aufgabe ist dabei, die SLA und die erbrachten Leistungen nach Qualität zu überprüfen. Hier ist

unsere Aufgabe klar definiert.

Beim Fremd-Outsourcing hingegen, also Outsourcing mit einem Drittunternehmen ausserhalb

der Bundesverwaltung, liegt unser Prüffokus anders. Dabei führen wir Beschaffungs-prüfungen

durch. D.h wir behandeln dabei unter anderem Fragestellungen, wie: Wie wurden die

Ausschreibung und die Wahl der Leistungen, die man auslagern will, dokumentiert? Wie ist man

zum Lieferant gelangt? Fand eine öffentliche Ausschreibung statt?

In Ihrem Artikel und in Ihren vorhergehenden Ausführungen beschreiben Sie, dass ein

aktiver Einbezug der Internen Revision bei der Outsourcing-Entscheidung wichtig ist. In

meinen bisherigen Interviews wurde mir seitens der Internen Revision beschrieben, dass kein

aktiver Einbezug seitens der Geschäftleitung vorgenommen wird. Die Interne Revision steht

eigentlich vermehrt nur beratend zur Seite. Jedoch wurde der Wunsch gehegt sich, in Zukunft

vermehrt in Outsourcing-Entscheide einbringen zu wollen. Wie würden Sie gegenüber der

Geschäftsleitung argumentieren, dass ein Einbezug von der Internen Revision in den

Outsourcing-Prozess Sinn machen würde?

Die Problematik in der Geschäftsleitung ist, ihre Tendenz dazu, Problem seitens IT zu schnell zu

behandeln. Meines Erachtens besteht eine Gefahr, dass die IT zu schnell outgesourct wird. Somit

wird die Outsourcing-Entscheidung entweder nur auf die Meinung einer IT-Fachperson gestützt

oder rein politisch getroffen, ohne dass eine gründliche Analyse stattfand. Ein Outsourcing kann

zu vielen Risiken führen, wie z.B. Abhängigkeiten oder Probleme, die ausgelagerten Bereiche

wieder zurückzuholen. Deshalb ist es aus meiner Sicht wichtig, eine zweite Meinung im eigenen

Unternehmen einzuholen, die die Outsourcing-Möglichkeit abwägt und analysiert. Eine solche

Aufgabe kann die Interne Revision am besten wahrnehmen, da die Interne Revision das eigene

Unternehmen kennt. Sie besitzt deutlich mehr Wissen als eine externe Instanz.

9. Anhang 153

Es gibt aber keinen Standard, welcher z.B. durch das Institute of Internal Auditors erlassen

wurde, welches die Outsourcing-Beziehung aus Sicht der Internen Revision regelt oder

unterstützt?

Nein, meines Wissens besteht zur Zeit kein solcher Standard. Das Revisionsrecht, also die

Möglichkeit direkt beim Service Anbieter eine Prüfung vorzunehmen, gilt häufig alleine für die

Externe Revision. Aus meiner Sicht wurde dabei für die Interne Revision zu wenig getan, was

bedauernswert ist.

Anders ausgedrückt, ist ein Service Anbieter zu vielem bereit, um ein Outsourcing-Geschäft

abzuschliessen. Somit ist er, um ins Geschäft zu kommen, zu vielen Kompromissen bereit. Es

wäre also aus Sicht des Outsourcer kein Problem, das Revisionsrecht für die eigene Interne

Revision beim Service Anbieter als Vertragsbestandteil aufzunehmen.

Zusammenfassend kann demnach festgehalten werden, dass es im Moment keinen Standard

gibt, an den sich die Interne Revision halten kann, und die Rolle der Internen Revision im

Outsourcing vom aktiven Einbezug der Geschäftsleitung abhängig ist, und dies was Ihrer

Meinung nach so früh wie möglich erfolgen sollte?

Ja, diese Zusammenfassung entspricht meiner Meinung. Wie gesagt, halte ich es für sinnvoll, die

Interne Revision ganz früh, also schon bei der Analyse einer Outsourcing-Möglichkeit,

miteinzubeziehen und anschliessend bei der Wahl des Service Anbieters zu konsultieren.

Was sind denn aus Revisionssicht die entscheidenden Kriterien bei der Wahl des Service

Anbieters?

Ich würde hier nicht aus der Revisionssicht argumentieren. Ein Service Anbieter darf keine

Leistungen übernehmen, die für den Outsourcer von strategischer Bedeutung ist. Wäre dies der

Fall, würde es zu einer erhöhten Abhängigkeit kommen. Aus Outsoucer-Sicht darf keine eigene

Kompetenz abgegeben werden.

Ansonsten sind bei der Wahl Dinge wie Professionalität, Ruf oder Referenzen von anderen

Kunden entscheidend. Meiner Meinung nach müsste man noch einen Schritt weitergehen und

vor einem Outsourcing-Vorhaben Prüfungen beim Service Anbieter durchführen.

9. Anhang 154

Sie meinen also, dass vor der eigentlichen Entscheidung für einen Service Anbieter direkte

Tests bei diesem durchgeführt werden müssen?

Ja, um nachzuprüfen, ob die gemachten Versprechungen auch wirklich eingehalten werden

können. Es ist also kein Revisionsrecht, sondern eine Bedingung, welche man im Rahmen der

Verhandlungen vom potentiellen Service Anbieter verlangen sollte, um volle Einsicht in die

Unterlagen des Service Anbieters zu erhalten. Meiner Ansicht nach wird heutzutage viel zu

blauäugig mit dieser Thematik umgegangen.

Bei der Wahl des Service Anbieters haben andere Interviewpartner erwähnt, dass für sie das

Revisionsrecht ein Bestandteil des Outsourcing-Vertrages sein muss. Ohne diese Zustimmung

kann aus Revisionssicht einem Outsourcing nicht zugestimmt werden. Wie ist Ihre Meinung

diesbezüglich?

Dem stimme ich zu. Betrachtet man z.B. den Bankenbereich, so ist dieses Revisionsrecht im

EBK RS 99/2 vorgeschrieben. Man könnte deshalb sogar argumentieren, dass dieses Recht auch

ohne explizit Erwähnung in einem Outsourcing-Vertrag besteht. In Bereichen ausserhalb des

Bankenbereichs muss das Revisionsrecht unbedingt Bestandteil des Vertrages sein.

Nun will ich gerne die Perspektive wechseln und zur externen Prüfgesellschaft des Outsourcer

kommen. Sie haben vorher einige Male die Rolle der externen Prüfgesellschaft vor dem

eigentlichen Outsourcing angesprochen. Können Sie dies konkretisieren? Fällt der externen

Prüfgesellschaft im Outsourcing-Prozess eine bestimmte Rolle zu?

Für den externen Prüfer ist es wichtig, dass das Revisionsrecht beim Service Anbieter im Vertrag

festgehalten wurde. Danach ist der nächste Schritt die Revisionsplanung mit dem Service

Anbieter, wobei hier die externe Prüfgesellschaft abklären muss, wie wesentlich und

risikobehaftet die ausgelagerten Bereiche für die Prüfung sind. Kommt sie zum Schluss, dass

diesbezüglich keine Wichtigkeit besteht, so fällt das Outsourcing-Geschäft aus dem Fokus der

externen Prüfgesellschaft. Je nach dem wie die Risikoanalyse ausgefallen ist, erhöht sich die

Tätigkeit der externen Prüfgesellschaft.

Grundsätzlich kann aber gesagt werden, dass der externen Prüfgesellschaft im Outsourcing-

Prozess bzw. bei der Entscheidung keine besondere Rolle zugewiesen wird, da diese strategische

Entscheidung alleine vom Unternehmen gefällt wird.

9. Anhang 155

Fällt aus der Service Anbieter Sicht der Internen Revision des Service Anbieters eine

entscheidende Rolle vor dem Outsourcing-Geschäft zu?

Es ist relativ selten, dass ein Service Anbieter eine Interne Revision besitzt. Vielleicht haben

grosse Gesellschaften wie z.B. IBM oder HP eine Interne Revision. Es ist denkbar, dass diese

unterstützend für das Management des Service Anbieters und dem Outsourcer wirken kann,

jedoch bin ich darüber zu wenig informiert.

Nun will ich einen Schritt weitergehen und die Situation während eines Outsourcing

betrachten. Welche Rolle nimmt die Interne Revision des Outsourcer in dieser Periode ein?

Zum Aufgabengebiet der Internen Revision gehören sicherlich die Ordnungsmässigkeits-

prüfungen. Dies bedeutet, die Prozesse und Kontrollen beim Service Anbieter sind zu

überprüfen, um sicherzustellen, dass die Leistungen ordnungsgemäss erbracht werden. Die

Frage, die sich hier stellt, ist sicherlich, wie man die Einhaltung der Kontrollen überprüft. Hierzu

könnte ein SAS 70 Report eine gute und hinreichende Grundlage sein. In der Schweiz ist dieser

Report meines Wissens nicht verbreitet, jedoch ist in der Schweiz mit dem GzA 18 bzw. neu mit

dem PS 402 das Outsourcing-Verhältnis geregelt.

Klar ins Aufgabengebiet der Internen Revision gehören aber auch Prüfungen der

Wirtschaftlichkeit und Geschäftsführung. Hier geht es um die Einhaltung von vertraglichen

Bestimmungen, d.h. den SLA und um die korrekte Verrechnung der erbrachten Leistungen. Es

geht also um eine inhaltliche Prüfung der Leistungserbringung.

Diesbezüglich gibt es auch keinen Standard, der das Aufgabengebiet der Internen Revision im

Outsourcing regelt? Ausser dem EBK RS 99/2 für den Bankenbereich, ist für die anderen

Bereiche nichts geregelt?

Die Messung und die Leistungsverrechnung sind auch in EBK RS 99/2 nicht vorgesehen. D.h.

wenn Leistungen zu teuer verrechnet werden, so bietet das EBK RS 99/2 keinen Schutz.

Auch in diesem Stadium des Outsourcing-Geschäfts gibt es aus meiner Sicht keinen Standard,

der die Pflichten und Aufgaben für die Interne Revision festhält.

9. Anhang 156

Wie sieht es mit dem Revisionsrecht der Internen Revision während eines Outsourcing aus?

Meiner Meinung nach braucht die Interne Revision nicht zwingend ein Revisionsrecht sondern

kann sich für die Prüfung der erbrachteten Leistungen auf die Kontrolle der Einhaltung des

Outsourcing-Vertrags stützen. Hierzu nehme ich am besten ein Beispiel: Wenn von einem

Service Anbieter eine Netzverfügbarkeit von 99.6% gewährleistet wird, so gibt es bei Verstoss

gegen diese vertragliche Bestimmung Abzug beim Outsourcing-Honorar. Der Interne Revisor

des Outsourcer muss sich mit Fragestellung befassen, wie z.B: Ist die Netzverfügbarkeit

gemessen worden? Gibt es Statistik dazu? Wurde die Leistung gemessen und geprüft, bevor die

Rechnung bezahlt wurde? Falls nun bemerkt wird, dass keine Instanz die Leistung gemessen und

überprüft hat und die Verfügbarkeit der Netze liegen auch nicht in dem vorgegebenen Rahmen

liegen, so benötigt man kein Revisionsrecht, um dies festzustellen und die notwendigen

Massnahmen zu ergreifen.

Im Gegensatz zur Internen Revision, bei der kein Standard definiert wurde, um die Rechten

und Pflichten im Outsourcing festzulegen, besitzt die Externe Revision mit dem PS 402 einen

Standard, der das Outsourcing-Geschäft regelt. Wie ist Ihre Meinung bezüglich dem PS 402

und was sind aus Ihrer Sicht die wichtigsten Bestandteile daraus?

Das PS 402 ist aus meiner Sicht ein vollständiger Standard, ganz im Gegensatz zum GzA 18, der

zu viele Lücken aufwies. Das einzige Problem, mit dem man sich konfrontiert findet, ist die

Einschätzung, wann eine Wesentlichkeit vorliegt. Beim EBK RS 99/2 ist eine Beilage

vorhanden, die genauer beschreibt, wann von einem wesentlichen Outsourcing gesprochen wird

und wann nicht. Beim PS 402 gibt es dies nicht, womit ein grosser Ermessensspielraum

vorhanden ist.

Um den Kunden direkte Prüfungen beim Service Anbieter zu ersparen und selber Ressourcen

einzusparen, hat der Service Anbieter die Möglichkeit, sich nach SAS 70 prüfen zu lassen und

den Kunden jeweils einen Report zukommen zu lassen. Sie haben im Interview das SAS 70 als

gute Grundlage für die Kontrollübersicht beim Service Anbieter betrachtet. Haben Sie schon

einmal einen SAS 70 Report gebrauchen müssen? Was ist Ihre Meinung bezüglich SAS 70?

Diese Art von Report ist mir bekannt und wird uns auch häufig ausgehändigt, jedoch bisher nicht

unter dem Namen SAS 70. Wir haben einen typischen Fall mit dem Outsourcing bei der

Sparkasse des Bundespersonals. Bei unseren Reports war es bis anhin so, dass wir zwei Personen

9. Anhang 157

von uns in die Prüfequipe delegieren konnten, die unter der Leitung der externen

Prüfgesellschaft die Prüfungen durchführten und wir dabei unsere Meinungen einbringen

konnten.

Allgemein stehe ich dem SAS 70 positiv gegenüber, auch wenn ich nie direkt damit konfrontiert

war. Aus meiner Sicht schafft der SAS 70 Report eine gute Vertrauensbasis zwischen dem

Service Anbieter und dem Outsourcer. Wichtig ist einfach, dass die Bereiche, die nach SAS 70

geprüft werden, den Wünschen der Kunden entsprechen. Diese Wünsche sollten zu Jahresbeginn

in einem Koordinationsmeeting eingebracht werden, so dass eine SAS 70 Prüfung zu diesen

Bereichen durchgeführt werden kann.

SAS 70 ist in der Schweiz noch nicht verbreitet. Sehen Sie eine Schwierigkeit, wieso sich SAS

70 in der Schweiz nicht durchsetzten sollte?

Ich sehe keine direkten Schwierigkeiten. Was allenfalls eine grosse Hürde darstellen könnte,

wären die damit anfallenden Kosten, wobei Überlegungen vielleicht mittelfristiger bzw.

langfristiger ausgelegt werden müssen. Obwohl die Prüfung heute kostet, könnte es mir in

Zukunft vielleicht einiges an Nutzen wieder zurückzahlen.


9. Anhang 158

Frank Mühlenbrock234, IT Architect, IBM Deutschland

Frank Hammer235, Manager Business Compliance & Risk Management pan IOT

Themen:

Outsourcing aus Sicht des Service Anbieters IT-Security Erfahrungen aus der SAS 70 Prüfung

Welche Vorteile für den Service Anbieter sehen Sie, in ein Outsourcing einzutreten? Welche

Vorteile entstehen Ihres erachtens, falls ein Service Anbieter in ein Outsourcing einsteigt?

Frank Mühlenbrock: Aus meiner Sicht bedeutet es ein Vorteil, wenn einheitliche Prozesse auf

mehrere Kunden angewendet werden können. Das führt unsererseits zu einer

Ressourceneinsparung und zu einer Vereinheitlichung.

Welche Risiken im Outsourcing-Geschäft sehen Sie für den Service Anbieter?

Frank Mühlenbrock: Innerhalb eines Outsourcing wird eine grosse Anzahl an Personen vom

Kunden übernommen. Dies führt einerseits zu einem sehr schwierigen Integrationsprozess dieser

Personen in die IBM und andererseits entsteht auf unserer Seite ein grosser Kostenblock, der von

uns getragen werden muss. Wir als Service Anbieter müssen schauen, wie und wo man diese

Personen im Betrieb integriert. Dies erfordert einen erhöhten Schulungsaufwand, um die neuen

Mitarbeiter z.B. mit den Standardprozessen oder Tools vertraut werden.

Sie sehen also die personellen Fragestellungen als grosses Risiko an?

Frank Mühlenbrock: Ja, dieses Risiko ist im Moment auch innerhalb der IBM sehr aktuell.

234 Herr Mühlenbrock leitete die letzten zwei SAS 70 Prüfungen für die IBM der Länder Deutschland und Schweiz. Diese SAS 70 Prüfungen wurden vor zwei Jahren erstmals ausserhalb der IBM USA durchgeführt. Das Interview fand in Form eines Telefoninterviews statt. 235 Herr Hammer beantwortet die Fragen rund um SAS 70 bei der IBM, die im zweiten Teil des Interviews zu finden sind. Das Interview fand in Form eines Telefoninterviews statt.

9. Anhang 159

Gerne will ich nun zu der Thematik der IT-Security kommen. Ist die IT-Security eine

Fragestellung, mit der sich die IBM alleine zu beschäftigen hat oder wird der Kunde auch

teilweise miteinbezogen und dementsprechend in die Verantwortung genommen?

Frank Mühlenbrock: Das hängt davon ab, wie der Vertrag ausgehandelt wurde. Es gibt Kunden,

die wünschen, dass die IBM die alleinige Verantwortung betreffend der IT-Security übernimmt.

Andererseits gibt es Kunden, die selber mitbestimmen wollen.

Es existieren Outsourcing-Geschäfte, bei denen die Kundendaten im Rechenzentrum auf Servern

der IBM gespeichert sind und dementsprechend besitzt die IBM die Verantwortung über deren

Sicherheit nicht zuletzt, da sich die Daten auf IBM-Gelände befinden. Umgekehrt gibt es den

Fall, dass die Server beim Kunden verbleiben und die IBM die Wartung der Server beim Kunden

vornehmen muss, da liegt ein Teil der Verantwortung beim Kunden.

Ist es aus Ihrer Sicht besser, wenn der Kunde mitbestimmen kann oder bevorzugen Sie die

alleinige Verantwortung?

Frank Mühlenbrock: Meiner Meinung nach stellt die alleinige Verantwortung die bessere

Lösung für einen Service Anbieter dar. Damit ist gewährleistet, dass, salopp ausgedrückt,

niemand mit „reinpfuscht“. Somit kann der Service Anbieter nachvollziehen, was mit den

Systemen und Daten passiert ist, wenn ein Hacking-Versuch stattgefunden hat.

Dann trägt der Service Anbieter die alleinige Verantwortung, wenn es nun zum Schadensfall

kommt. Kann die Verantwortung nicht mehr teilweise oder ganz dem Kunden zugeschoben

werden?

Frank Mühlenbrock: Es kommt drauf an, in welchem Masse der Kunde Zugriff auf seine Daten

hat. Natürlich hat der Kunde immer Zugriff auf seine Daten, jedoch kann er auch

Administratorenrechte besitzen. Falls dies der Fall ist, kann das Verschulden auch in der

Verantwortung des Kunden liegen.

9. Anhang 160

Sie haben erwähnt, dass bezüglich der IT-Security die Vertraggestaltung wichtig sei. Teil des

Vertrages ist das IT-Sicherheitskonzept. Wird bei Ihnen für jeden Kunden ein eigenes IT-

Sicherheitskonzept erstellt?

Frank Mühlenbrock: Ja, dies ist für jeden einzelnen Kunden der Fall. Das IT-Sicherheitskonzept

trägt in der IBM den Namen GSD331. IBM-Intern gibt es auch eine ähnliche Richtlinie, die aber

im Unterschied zum GSD331 nicht verhandelbar ist. Die IBM gibt dabei intern vor, wie die

Sicherheits-einstellungen aussehen müssen. Im Gegensatz dazu kann der Kunde beim GSD331

die Sicherheitseinstellungen mitgestalten. Als Beispiel sei die Passwortlänge genannt. Intern gibt

die IBM die Richtlinie vor, acht Zeichen zu verwenden. Diese Richtlinie muss nun nicht

zwangsläufig in die GSD331 des Kunden übernommen werden, falls er die Passwortlänge als zu

lang empfindet. Somit kann er die eigene Passwortlänge festlegen und diese wird dann in die

GSD331 Richtlinie übernommen.

Unsere Empfehlungen für die Verhandlungen der GSD331 Richtlinie basieren auf unseren

internen Richtlinien und best practices, die aber vom Kunden wie gesagt nicht akzeptiert werden

müssen.

Stellt es für die IBM nicht einen sehr grossen Aufwand dar, wenn für jeden Kunden ein

individuelles Sicherheits-konzept erstellt werden muss?

Frank Mühlenbrock: Es gibt einen Referenzprozess, wie die GSD331 Richtlinie erstellt werden

muss. Der IBM-Kundenberater tritt mit dem Kunden betreffend dieses Prozesses in die

Verhandlungen. Wir können jedoch nicht jedem Kunden die gleichen Sicherheitsrichtlinien

aufdrängen. Teilweise ist es der Fall, dass Teile der Sicherheitsfragen nicht verhandelbar,

sondern verbindlich sind und wir diese vorschreiben. Dies ist z.B. im Shared Service Bereich der

Fall, bei dem Netzwerke zwischen verschiedenen Kunden geteilt werden. Besitzt jedoch der

Kunde seinen eigenen Netzwerkbereich, muss dem Kunden etwas Eigenes angeboten werden. Es

stellt ein hoher Aufwand unsererseits dar, jedoch muss dies für die Zufriedenstellung des

Kunden so gehandhabt werden. Ausserdem wird dabei gewährleistet, dass der Kunde genau die

Sicherheit erhält und bezahlt, die von ihm auch gewünscht wird.

9. Anhang 161

Was sind die Grundlagen des bei Ihnen eingesetzten IT-Sicherheitskonzepts? Spielen dabei

ISO 17799 oder das IT-Grundschutzhandbuch eine Rolle?

Frank Mühlenbrock: Diese Frage wird von den Kunden oft gestellt. Unsere Antwort darauf

lautet, dass das Sicherheitskonzept sich so nah wie möglich an den ISO 17799 Standard

orientiert, jedoch wird sich die IBM nicht nach ISO 17799 zertifizieren lassen. Dies aus dem

Grund, weil das Sicherheitskonzept, welches die IBM anbietet, wesentlich umfangreicher ist als

der ISO 17799 Standard.

In welcher Form umfangreicher?

Frank Mühlenbrock: Das IBM Sicherheitskonzept integriert wesentlich mehr best practices. Die

IBM hält sich nicht strikt an die zehn Punkte bzw. Domänen des ISO 17799 Standard.

Sie haben vorhin schon einige Ausführungen bezüglich den Verantwortlichkeiten der

Sicherheitskonzepterstellung gemacht. Können Sie diese konkretisieren?

Frank Mühlenbrock: Es gibt unsererseits den „Kundenberater“, DPE genannt, und bei grossen

Kunden noch einen Security DPE. Diese nehmen die GSD331 Vorlage zum Kunden mit und

verhandeln mit der Gegenpartei. Beim Kunden ist dies meistens der Security Officer. Zusammen

werden dabei die GSD331 Richtlinien definiert und mit den jeweiligen Security-Administratoren

besprochen.

Sind auch die Internen Revisionsstellen beider Parteien involviert?

Frank Mühlenbrock: Nein, unsere Interne Revision, bei uns Corporate Audit genannt, tritt von

Zeit zu Zeit auf und prüft, ob die verhandelten und abgemachten GSD331-Massnahmen auch

tatsächlich eingehalten werden. Darüber hinaus kann der Kunde bei uns auch direkte Prüfungen

vornehmen, jedoch nicht zu einem beliebigen Zeitpunkt, sondern unter Absprache mit der IBM.

Die Prüfungen müssen unsererseits vorbereitet und begleitet werden. Dafür müssen Personen

abgestellt werden, ohne dass dabei unsere Geschäftstätigkeit behindert wird.

9. Anhang 162

Sie haben das Revisionsrecht des Kunden angesprochen. Für die IBM stellt es wahrscheinlich

einen sehr hohen Aufwand dar, wenn alle Kunden von ihrem Revisionsrecht Gebrauch

machen wollen. Wie gehen Sie damit um?

Frank Mühlenbrock: Dem Kunden wird kommuniziert, dass ein Revisionsrecht ihrerseits nicht

von Nöten ist. Jedoch kommt man bei Grosskunden nicht darum herum, ihnen das

Revisionsrecht zu ermöglichen. Das Revisionsrecht besteht teilweise auch aus regulatorischen

Anforderungen. Besteht ein Regulatorium, so muss das Revisionsrecht gewährt werden.

Um nochmals auf die Thematik der IT-Security zurückzukommen: Wie überprüfen Sie diese

innerhalb der IBM?

Frank Mühlenbrock: Innerhalb der IBM gibt es die Abteilung „Security Operation Competencies

Segment“ (SOCS). Diese Abteilung führt im Jahr ca. 20 System Process Reviews (SPR) durch.

Diese Reviews werden vier Wochen vor der Prüfung an der jeweiligen Lokation angekündigt.

Das Team, das je nach Grösse des Kunden zwischen drei bis fünf Personen umfasst, prüft dann

eine Woche lang die Einhaltung sämtlicher GSD331 Prozessen. Darüber hinaus werden auch

technische Stichproben auf den Servern durchgeführt. Fragestellungen bei den technischen

Stichproben sind z.B. die Einhaltung der Passwortregeln, richtige Durchführung der Health-

Checks und das Überprüfen, ob Fehleinstellungen vorherrschen, die korrigiert werden müssen.

Danach wird ein SPR-Report erstellt, welcher der Geschäftsleitung übergeben wird. Aus diesem

Report leitet sich ein Aktionsplan her, der die gefundenen Fehler auflistet. Diese Fehler müssen

dann innerhalb von 90 Tagen behoben werden. Spätestens nach einem Jahr überprüft die SOCS-

Abteilung, ob die Umsetzung stattgefunden hat.

Die GSD331 Prozesse werden nicht stichprobenartig kontrolliert, sondern es werden jeweils

alle Prozesse überprüft?

Frank Mühlenbrock: Ja, es werden alle Prozesse überprüft, jedoch nicht alle Systeme. Dort

findet eine Stichprobenprüfung statt.

Werden die Resultate des Review auch dem Kunden kommuniziert?

Frank Mühlenbrock: Wenn ein SPR vom Kunden gefortdert wird, so liefern wir die Ergebnisse.

Ansonsten werden die SPR-Report intern gehalten.

9. Anhang 163

Meines Wissens hat sich die IBM einer SAS 70 Prüfung unterzogen. Können Sie mir sagen,

wieso sich die IBM für ein SAS 70 Report entschieden hat?

Frank Mühlenbrock: Das Sarbanes-Oxley Act (SOX) verpflichtet alle an der US-Börse kotierten

Unternehmen bis zum 31.12.2006 eine SOX-Zertifizierung zu erlangen. Weiter muss dafür

gesorgt werden, dass auch deren Service Anbieter SOX-konform sind. Die IBM als Service

Anbieter betreut viele Kunden die an der US-Börse kotiert sind. Die IBM hätte keine SAS 70

Prüfung durchführen müssen, doch dann hätte dies zur Folge gehabt, dass unsere Kunden

laufend Einzelreviews verlangt hätten, was uns und den Knuden erhebliche Ressourcenaufwände

für die Vorbereitung und Durchführung dieser Reviews gekostet hätte. Der Kunde erhält nach

Wunsch einen SAS 70 Report Typ II, kann diesen für seine SOX-Zertifizierung verwenden und

muss dann keine direkten Reviews mehr bei uns durchführen.

Demnach war es die Intention der IBM, sich einer SAS 70 Prüfung zu unterziehen und nicht

der Wunsch der Kunden?

Frank Mühlenbrock: Ja, es war die IBM, die das forciert hat und nicht die Kunden.

Kann ein Kunde einen SAS 70 Report verlangen, der nur auf sein Unternehmen

zugeschnitten ist?

Frank Hammer: Ja, dies ist möglich. Insbesondere für Grosskunden werden solche SAS 70

Reports angeboten. Die Grosskunden, deren Daten oftmals in eigenen Datenzentren gehalten

werden, wünschen diesen speziell auf sie zugeschnittenen SAS 70 Report. Diese Kunden sind

aufgrund der SOX-Konformität bereit die Kosten einer eigenen, auf den Kunden zugeschnittene

SAS 70 Prüfung zu bezahlen.

Die SAS 70 Prüfung wird vom Kunden bezahlt?

Frank Hammer: Die Aufwände für die SAS 70 Prüfung sind beachtlich und werden auf die

Kunden umgelegt. Dies wurde den Kunden kommuniziert und viele verstehen dies, da sie froh

sind, dass wir uns einer SAS 70 Prüfung unterziehen und kein eigenen Assessment stattfinden

muss. Theoretisch ist die IBM nicht verpflichtet sich einer SAS 70 Prüfung zu unterziehen. Dies

hätte wie vorhergehend erwähnt zur Folge, dass die Kunden direkte Prüfungen bei uns

9. Anhang 164

durchführen müssten, was auch mit sehr hohen Aufwänden verbunden ist und zu unserem und

dem Nachteil unserer Kunden wäre.

Eine SAS 70 Prüfung muss jährlich durchgeführt werden. Lohnt sich aus Ihrer Sicht der

Aufwand einer SAS 70 Prüfung gegenüber dem Nutzen des Reports?

Frank Mühlenbrock: Ja, es lohnt sich für die IBM. Die Situation in EMEA sieht

folgendermassen aus: Unsere externe Prüfgesellschaft prüft jedes Jahr 10 – 12 IBM Lokationen,

wobei die grossen „shared“ Lokationen immer dabei sind. Aus diesen Reviews, die etwa drei

Wochen andauern, wird der EMEA SAS 70 Typ II Report erstellt. Die externe Prüfgesellschaft

ist schlussendlich 12 mal drei Wochen hier. Der Aufwand ist für uns trotzdem viel kleiner, als

wenn jeder Kunde drei bis vier Wochen bei uns direkte Prüfungen durchführen würde zumal

unser externe Prüfer die Prozesse der IBM kennt und somit das Review wesentlich gezielter

durchführbar ist.

Frank Hammer: Wenn die IBM keinen SAS 70 Report aufweisen könnte, so müsste jeder

Kunde, der dem SOX untersteht, Prüfungen bei uns durchführen. Insofern spüren wir deutlich

eine Verringerung der direkten Prüfungen bei uns. Es gibt Kunden, die führen zusätzliche

Prüfungen durch, wobei dies sich in Grenzen hält.

Es gibt wiederum Kunden, die nicht dem SOX unterstehen, die jedoch trotzdem einen SAS 70

Report fordern. Diese Kunden versprechen sich daraus, dass sie eine Dokumentation der

Sicherheit bezüglich der Prozesseinhaltung unsererseits erhalten.

Ein SAS 70 Report ist generell gehalten und nicht kundenspezifisch. Im SAS 70 Report sind

zwar – falls vorhanden – Issues dokumentiert, allerding weder konkret auf ein Datacenter oder

einen Kunden bezogen.

Sie sehen den Nutzen des SAS 70 Report darin, dass Ressourcen ihrerseits eingespart werden

können?

Frank Mühlenbrock: Ja, so ist es. Wie Frank Hammer bereits erwähnt hat, attestiert eine SAS 70

Prüfung, dass die IBM Prozess-konform arbeitet. Das wiederum bringt uns einen

Wettbewerbsvorteil gegenüber Mitbewerbern, die dies erst noch bestätigen lassen müssen.

9. Anhang 165

Eine SAS 70 Prüfung kann über verschiedene Bereiche durchgeführt werden. Diese Bereiche

werden von der IBM mit der externen Prüfgesellschaft definiert. Aufgrund welcher

Entscheidungen werden die Bereiche für die SAS 70 Prüfung definiert?

Frank Mühlenbrock: Diese Entscheidung fällt auf der Führungsetage. Da ich nicht Miglied der

Geschäftsleitung bin, kann ich nur spekulieren. Jedoch kann ich mir vorstellen, dass versucht

wurde, möglichst viele Dinge, die für die SOX-Zertifizierung wichtig sind, abzudecken. Man hat

sicherlich versucht, die Hauptkapitel der GSD331 einfliessen zu lassen. Die externe

Prüfgesellschaft versucht andererseits ihre Vorschläge zu unterbreiten, die eventuell auf ISO

17799 basieren.

Frank Hammer: Der Prüfkatalog des SAS 70 basiert im Grunde genommen auf COBIT. Dieses

Prüfvorgehen wir mit Einschränkungen von allen Prüfgesellschaften für SAS 70 genutzt.

Zusätzlich werden die Prüfungen den Kundenverträgen angepasst. Konkret bedeutet dies bei uns,

dass unsere externe Prüfgesellschaft die vereinbarten GSD331 Richtlinien prüft und diese

zusätzlich in deren Prüfung miteinbezieht. Dieses Vorgehen ist insbesondere bei den „Shared

Services“ der Fall. Bei speziellen SAS 70, die für einzelne Kunden gemacht werden, werden

zusätzlich Kundenwünsche (des Kunden und seines Prüfers) für Prüfbereiche miteinbezogen.

Hier können nur Bereiche in den Prüffokus unserer externen Prüfgesellschaft fallen, die auch

effektiv von uns erbracht werden. Wünscht der Kunde eine SAS 70 Prüfung für einen nicht von

uns erbrachten Bereich, der in seiner Verantwortlichkeit liegt, so kann unsere Prüfgesellschaft

keine SAS 70 Prüfung durchführen.

Hat die IBM den Typ II aufgrund der SOX-Konformität gewählt? Kam dabei der Typ I gar nie

in Frage?

Frank Mühlenbrock: Das war auch eine Management-Entscheidung, jedoch glaube ich nicht,

dass eine Typ I Prüfung bei uns in Frage gekommen wäre. Ich denke nicht, dass ein Typ I Report

für die SOX-Zertifizierung ausreichend ist.

9. Anhang 166

Sie haben vorhin die Vorteile eines SAS 70 Report für die IBM erläutert. Welches sind aus

Ihrer Sicht die Vorteile für den Kunden? Durch den SAS 70 Report wird den Kunden quasi

das Revisionsrecht genommen.

Frank Mühlenbrock: Die Kunden haben die Sicherheit, dass die Prüfung durch eine unabhängige

Prüfgesellschaft durchgeführt wurde. Durch den unabhängigen Prüfer ist gewährleistet, dass eine

SOX-konforme Prüfung stattfindet und der Report ohne Reibungsverluste in die SOX-

Zertifizierung einfliessen kann.

Der Kunde spart seinerseits Ressourcen ein. Will er bei der IBM eine dedizierte SAS 70 Prüfung

vornehmen und diese in eine SOX-konforme Form bringen, so kostet es dem Kunden viel Geld

und personelle Ressourcen. Mit dem von der IBM zur Verfügung gestellten SAS 70 Report

entfällt für den Kunden dieser Aufwand.

Hat der Kunde trotz des SAS 70 Report die Möglichkeit, bei der IBM direkte Prüfung

vorzunehmen?

Frank Mühlenbrock: Ja, der Kunde hat diese Möglichkeit. Mir ist bis jetzt kein Fall bekannt, bei

dem von diesem Recht nach einem SAS 70 Report Gebrauch gemacht wurde, jedoch ist dies

möglich. Eine Prüfung des Kunden ist dann aber wesentlich weniger aufwendig, da weniger

Reviews nötig sind und auf die Ergebnisse des SAS 70 Reviews zurückgegriffen werden kann.

Frank Hammer: Ein SAS 70 Report wird für bestimmte Bereiche definiert, die der SOX-

Konformität dienen. Nun kann aber ein Kunde zusätzliche Prüfungen vornehmen, obwohl ein

SAS 70 Report vorliegt. Dies ist dann der Fall, wenn kundenspezifische Bereiche genauer

geprüft werden sollen. Wir versuchen natürlich diese direkten Prüfungen so gut es geht zu

vermeiden, jedoch obliegt es dem Kunden darüber zu entscheiden. Kommt es zu einer

zusätzlichen Prüfung, so fallen diese aufgrund des vorliegenden SAS 70 Report wesentlich

kürzer und umfangärmer aus. Oftmals sind dies Reviews, die nicht länger als einen Tag dauern.

9. Anhang 167

Haben Sie ein unterschiedliches Prüfverfahren ihrer externen Prüfgesellschaft während der

SAS 70 Prüfung wahrgenommen, als es bei einer „normalen“ Prüfung der Fall wäre, oder

sah die Prüfung gleich aus?

Frank Mühlenbrock: Auf alle Fälle gab es Unterschiede. Wenn unsere Internen Revisoren eine

Prüfung an einer Lokalität vornehmen, so sind diese vier Wochen beschäftigt und die Prüfungen

werden sehr tief vorgenommen, da die IBM-Internen Richtlinien geprüft werden. Sie führen

technische Prüfungen auf den verschiedenen Systemen durch. Das SPR-Team wiederum

betrachtet mehrheitlich die Prozesse und führt gelegentlich technische Stichproben durch. Diese

internen Prüfungen sind sehr umfangreich. Die internen Prüfpersonen kennen das Unternehmen

und wissen, was und wo sie fragen müssen. Anders sieht es bei der SAS 70 Prüfung aus, die von

externen Personen durchgeführt wird. Den externen Prüfern muss zuerst geholfen werden, damit

diese die internen Prozesse verstehen, damit sie dann die richtigen Fragen stellen können. Ich

hatte bei der SAS 70 Prüfung, die bei uns durchgeführt wurde, letzlich das Gefühl, dass diese

externen Prüfer teilweise die internen Prozesse nicht vollumfänglich verstanden haben. Es

wurden sogenannten „Exceptions“ durch die externen Prüfer beschrieben, die aus unserer Sicht

keine „Exceptions“ darstellen. Unserer Einschätzung nach wurde gemäss unseren internen

Richtlinien richtig verfahren. Die externe Prüfgesellschaft hat eine anderen Sichtweise und

bewertet deswegen anders.

Sie haben die „Exceptions“ angesprochen. Können Sie sagen, was diese „Exceptions“

beinhalten?

Frank Mühlenbrock: Diese Exception beinhalten die Meinungen der Prüfgesellschaft, wie

bestimmte Dinge gehen müssten oder sollten. Das heisst nicht, dass wirklich ein Fehler vorliegt.

Es kann nach IBM-Richtlinien und Richtlinien, die man mit dem Kunden abgemacht hat, richtig

sein. Der externe Prüfer sieht aber vielleicht Verbesserungspotential, weswegen er diese

„Expection“ erlässt, die im Report erwähnt werden. Inwieweit dies Einfluss auf eine Nicht-SOX-

Zertifizierung hat, kann ich nicht sagen, jedoch denke ich mir, dass darauf geachtet wird, wie

schwerwiegend die Exception ist.

Hat der SAS 70 Report bis jetzt einen spürbaren Vorteil für die IBM gebracht?

Frank Hammer: Da muss ich mit einem Jein antworten. Ja, deshalb, da der fertiggestellte SAS

70 Report an ca. 200 Kunden verteilt wurde. Wenn kein SAS 70 Report vorliegen würde, so

9. Anhang 168

würde eventuell jeder einzelne dieser 200 Kunden bei uns direkte Prüfungen vornehmen, was

unsererseits bedeutet, dass jedem Kunden mindestens eine Betreuungsperson und mehrere

Interviewpartner zur Verfügung gestellt werden müssen. Durch diese Einsparung an Aufwand

bringt uns der SAS 70 Report einen ganz grossen Nutzen.

Ob das ganze Thema für uns von Bedeutung ist hängt stark damit zusammen, was man von SOX

und dessen Aufbau / Umsetzung insbesondere in IT-Bereichen hält. Dies ist ein ganz andere

Frage, weswegen ich vorgängig mit Jein geantwortet habe.

Welche Gebiete der IT-Security waren bei der IBM Bestandteil der SAS 70 Prüfung?

Frank Mühlenbrock: SAS 70 bzw. SOX-Zertifizierung zielt auf die finanzielle Berichterstattung

ab. Deswegen lagen nicht nur die IT-Security Aspekte im Prüffokus, sondern eher Bereiche wie

das Change- oder Problemmanagement. D.h also, dass man die Service-Mangement Prozesse

fokussiert. Die Prüfung war ein gesunder Mix zwischen IT-Security und Service Management

Fragestellungen.

Frank Hammer: Der Zweck des SAS 70 Reports ist, zu überprüfen, ob die Leistungen, die vom

Service Anbieter erbracht wird, den vertraglichen Verpflichtungen entspricht. Anders

ausgedrückt muss der Kunde sicher sein, dass die Leistungen des Service Anbieters keinen

negativen Einfluss auf die finanzielle Integrität des Kunden hat. IT-Security spielt insofern eine

Rolle, da sichergestellt werden muss, dass die IT-Security-Richtlinien eingehalten werden. Eine

SAS 70 Prüfung ist eher eine Konzeptprüfung, weswegen die technische Prüfung eine

nachgelagerte Bedeutung hat. Im IT-Security Bereich wird mittels COBIT, welches für die

Prüfung angewandt wird, Bereiche wie „Logical Acces“ oder „Physical Access“ geprüft. Bei uns

ist es jedoch nicht der Fall, dass die IT-Security im SAS 70 als eigenständiges Thema geprüft

wurde, sondern eher Thema in einem Prüfkontext war.

9. Anhang 169

Gerne würde ich die Thematik der IT-Security-Prüfung beim SAS 70 diskutieren. Mir wurde

in vorhergehenden Interviews gesagt, dass eine SAS 70 Prüfung keine Einschränkung in der

Prüftiefe oder im Prüfumfang definiert. Dies wird auch als Schwäche des SAS 70 betrachtet.

Wie würden Sie die Prüfung vornehmen. Eher auf konzeptioneller Basis oder würden sie

tiefer gehen und auch technische Details prüfen?

Frank Mühlenbrock: Ich persönlich bevorzuge eher die Prozessprüfung mit einer gesunden

Anzahl an Stichprobenprüfungen bei den Systemen, wobei die technische Tiefe von System zu

System anders sein sollte. Es sollte nicht die Aufgabe sein, bei jedem System die Firewall-

Regeln zu prüfen. Dies erledigt die Interne Revision. Bei der SAS 70 Prüfung ist mir aufgefallen,

dass die Prüfung nur oberflächlich erfolgte. In manchen Bereichen hätte ich mir in den

Interviews gewünscht, dass sie weitergehen. Vielleicht war der Grund dafür, dass entweder das

technische Wissen gefehlt hat oder die Zeitknappheit ein Faktor war. Es war sicherlich nicht

einfach für die externen Prüfer, tiefer in die Materien zu gehen, da sie nur drei Wochen in

Deutschland waren, den Bericht geschrieben haben und weiter in ein anderes Land gingen.

Frank Hammer: Grundsätzlich muss eine SAS 70 Prüfung konzeptionell sein. Es muss

sichergestellt werden, dass die Konzepte, die vom Service Anbieter angewandt werden, korrekt

sind. Die technischen Prüfungen werde verwendet, um Gewissheit zu erlangen, dass diese

Konzepte auch tatsächlich genutzt werden. Bei der IBM ist es durch das GSD331 für den SAS

70 Prüfer einfach technische Prüfungen durchzuführen, da die Bestimmungen im GSD331

festgehalten sind. Meiner Meinung nach ist eine zu tiefe technische Prüfung nicht sinnvoll. Z.B.

Fragestellungen rund um die Passwortlänge sind aus meiner Sicht reine akademische

Diskussionen, die aber für eine SAS 70 Prüfung, als Konzeptprüfung, zu weit gehen bzw.

irrelevant sind. Ausserdem würde eine zu tiefe Prüfung erhebliche Kosten für die Kunden

bedeuten, was auch nicht in deren Sinn ist.

An diesem Beispiel sieht man, dass der Prüfungstiefe durch die SAS 70 Bestimmungen keine

Grenzen gesetzt sind, jedoch muss die Tiefe immer mit den Kosten zusammen betrachtet

werden. Zusammenfassend kann man sagen, dass technische Prüfungen für eine SAS 70 Prüfung

sinnvoll sind, um herauszufinden, ob die Konzepte auch tatsächlich stimmen. Die technischen

Prüfungen sollen aber nicht dazu verwendet werden, um Konzeptverbesserungen nachzuweisen.

Weiterhin ist über Stichprobenauswahl und –umfang sichergestellt, dass das Prüfnugsergebnis

aussagekräftig ist.

9. Anhang 170

Ist also der grosse Unterschied, den Sie während der SAS 70 Prüfung beobachtet haben, dass

während einer SAS 70 Prüfung im Unterschied zu einer „normalen“ IT-Security Prüfung

eher oberflächlich geprüft wurde?

Frank Mühlenbrock: Aus meiner Sicht ist die oberflächliche Prüfung der grosse Unterschied.

Wurde die Oberflächlichkeit oder etwas anderes am SAS 70 Report von Kundenseite

beanstandet?

Frank Mühlenbrock: Nein, die Kunden hatten überhaupt keine Wünsche oder Beanstandungen.

Ich glaube auch, dass die Kunden sehr glücklich damit waren, dass sich die IBM einer SAS 70

Prüfung unterzogen hat und die SAS 70 Reports zur Verfügung stellt. So mussten die Kunden

keine Leute für die Prüfung abstellen.

Vielen Dank für das aufschlussreiche und interessante Gespräch!

9. Anhang 171

Mark Dambacher, Senior Manager, PricewaterhouseCoopers

Themen:

Revision im Outsourcing aus Sicht der Externen Revision

SAS 70

Welche Rolle spielt das Outsourcing für die externe Revision und deren Prüfvorgehen?

Im Outsourcing ergeben sich gewisse Unterschiede. Ich beziehe mich nun spezifischer auf den

Bankenbereich. Im Bankenbereich muss der externe Prüfer gegenüber der Eidgenössischen

Bankenkommission (EBK) das Outsourcing gemäss RS 99/2 bestätigen. Wenn wir, als die

externe Revision, eine Bank prüfen, so müssen die neun EBK RS 99/2 Grundsätze nach deren

Einhaltung überprüft werden. Konkret bedeutet dies, dass wir das Recht haben, direkt beim

Service Anbieter Prüfungen durchzuführen, um die Einhaltung der EBK RS 99/2 Grundsätze zu

überprüfen. Das EBK RS 99/2 gibt uns das Recht bzw. verpflichtet uns, direkt beim Service

Anbieter Prüfungen durchzuführen.

Das Problem für den Service Anbieter ist, dass schlussendlich Prüfer von allen Kunden,

insbesondere Banken, beim Service Anbieter Prüfungen durchführen wollen. Damit der Service

Anbieter eine solche Situation vermeiden kann, lässt er sich von einer externen und damit

unabhängigen Prüfgesellschaft nach EBK RS 99/2 Einhaltung prüfen und gibt den Bericht an die

Kunden weiter. Dieser Prüfbericht reicht oftmals schon aus. Es kann jedoch vorkommen, dass

andere Prüfer, die diesen Bericht erhalten, zu Themen, die z.B. nicht im Prüffokus lagen, noch

eine zusätzliche Prüfung durchführen wollen.

Meinen Sie also damit, dass ein uneingeschränktes Revisionsrecht bestehen bleibt? Sie dürfen

beim Service Anbieter so oft Prüfungen durchführen, wie Sie wollen?

Jein, rein theoretisch haben wir das Recht, gemäss EBK RS 99/2 zu jeder Zeit eine

unangemeldete Prüfung bei der Bank durchzuführen. Die Bankenkommission schreibt uns vor,

dass wir unangekündigte Prüfungen durchführen müssen. D.h. nicht, dass der Zeitpunkt

unangekündigt ist, sondern, dass die Themen nicht angekündigt werden müssen. Beim Service

Anbieter sieht es anders aus. Da besteht kein uneingeschränktes Revisionsrecht. Es ist wichtig,

dass das Revisionsrecht vertraglich fixiert wird, damit Prüfungen durchgeführt werden können.

9. Anhang 172

Ihr Revisionsrecht stützen Sie auf das EBK RS 99/2. Welche Möglichkeit besteht für ein

Unternehmen, welches nicht an EBK RS 99/2 gebunden ist? Besteht auch da ein

uneingeschränktes Revisionsrecht?

Da wird es schwieriger. Ausserhalb des Bankenbereiches gibt es diesbezüglich keine

Regelungen. Das Revisionsrecht muss mit dem Service Anbieter vertraglich fixiert werden.

Sie haben in Ihren vorherigen Ausführungen erwähnt, dass der Service Anbieter die

Möglichkeit hat, sich von einer externen Prüfgesellschaft überprüfen und die Berichte den

Kunden bzw. deren Prüfgesellschaften zukommen zu lassen. Eine Prüfmöglichkeit

diesbezüglich wäre eine SAS 70 Prüfung. Können Sie über SAS 70 einige Worte verlieren?

Wieso hat sich SAS 70 in der Schweiz im Gegensatz zum Ausland noch nicht etabliert?

SAS 70 wird in Europa in den Niederlanden und insbesondere in Grossbritannien durchgeführt.

In Grossbritannien wird zur Zeit noch vermehrt auf das FRAG 21/94 gesetzt. In der Schweiz

wurden SAS 70 Prüfungen bis anhin nicht, bzw. kaum durchgeführt. Dies liegt im Wesentlichen

daran, dass sich viele nur nach den nationalen Richtlinien wie z.B. EBK RS 99/2 prüfen lassen

und nicht das internationale Umfeld betrachten. SAS 70 wird insbesondere in den USA

angewendet, da SAS 70 eine hinreichende Dokumentation der internen Kontrollen gemäss

Sarbanes-Oxley beschreibt. Dies bedeutet, dass alle Unternehmen, die in den USA an der Börse

kotiert sind und dementsprechend dem Sarbanes-Oxley unterstehen, sich einer SAS 70 Prüfung

unterziehen. In der Schweiz gibt es nur wenige Firmen, die auch in den USA kotiert sind und

entsprechend dem Sarbanes-Oxley unterliegen. Diesbezüglich muss gesagt werden, dass viele

internationale Vorschriften immer mehr in nationale Vorschriften übergehen. Es ist geplant, dass

es einen Euro-Sarbanes-Oxley geben soll und die Sarbanes-Oxley Richtlinen werden früher oder

später auch in das schweizerische Recht übergehen. Das bedeutet, dass in naher Zukunft SAS 70

auch zwangsläufig ein Thema in der Schweiz sein wird. Einige der Service Anbieter in der

Schweiz haben dies bemerkt und lassen sich deswegen nach SAS 70 prüfen. Die grossen Service

Anbieter, die dem Sarbanes-Oxley unterliegen, sind von sich aus auf die externen

Prüfgesellschaften zugekommen und haben eine SAS 70 Prüfung verlangt. Die kleineren Service

Anbieter sehen diesbezüglich noch keinen Handlungsbedarf. Jedoch sind seit dem 01.01.2005

die neuen Prüfungsstandards (PS) in Kraft. Darin wird mit dem PS 402 die Outsourcing-

Beziehung geregelt und ist somit für uns bindend. Bei der Durchsicht des PS 402 stellt man fest,

dass die Ausführungen dem SAS 70 Standard sehr ähnlich sind. PS 402 unterscheidet wie das

9. Anhang 173

SAS 70 zwei Typen der Berichterstattung: Typ A und Typ B. Typ A gibt Auskunft über das

Kontrollwesen und Typ B beschreibt zusätzlich deren Wirksamkeit.

Ich persönlich bin davon überzeugt, dass es in diese Richtung der Berichterstattung geht und es

ist sinnvoll, unsere Kunden davon zu überzeugen, sich so prüfen zu lassen. Ich bin mir nicht

sicher, ob eine EBK RS 99/2 Prüfung dem PS 402 gerecht wird. Deswegen ist es auch in

unserem Sinne, wenn eine Umstellung erfolgt.

Um nochmals auf die Beziehung SAS 70 und Sarbanes-Oxley zurückzukommen: Können Sie

noch genauer auf die Beziehung eingehen?

Sarbanes-Oxley verweist an einer Stelle beim Section 404 auf das SAS 70. Es erklärt darin, dass

SAS 70 für eine Sarbanes-Oxley Konformität ausreichend ist. Betrachtet man die IT respektive

die Umsetzung der IT, so verweist der SAS 70 für die Umsetzung des Kontrollwesens auf das

Sarbanes-Oxley. Hingegen verweist das Sarbanes-Oxley für die Umsetzung wie das Reporting

beim Service Anbieter aufzubauen ist auf das SAS 70. So hat man also eine doppelte Beziehung.

Sie haben vorgängig Argumente geliefert, wieso eine SAS 70 Prüfung für jedes Unternehmen

sinnvoll ist, auch wenn es nicht dem Sarbanes-Oxley untersteht. Können Sie dies noch

konkretisieren? Wieso soll sich Ihrer Meinung nach ein Unternehmen nach SAS 70 prüfen

lassen?

Spricht man von SAS 70, so spricht man von Control Reporting. Wenn ein Unternehmen einem

Service Anbieter etwas auslagert, so interessiert sich das Unternehmen für das Kontrollsystem

des Service Anbieters. Also reicht deren Kontrollsystem, um die geforderten Dienstleistungen

korrekt durchführen zu können. Für diese Information wird das Kontroll-system des Service

Anbieters benötigt. Ein SAS 70 ermöglicht nun, dass die Kontrollsysteme offen gelegt und

kommuniziert werden können. Ein SAS 70 liegt im Interesse des Outsourcers, damit er genügend

Informationen über das Kontrollsystem des Service Anbieters erhält, und andererseits spart es für

den Service Anbieter den Aufwand ein, sich laufend Prüfungen von den Kunden unterziehen zu

müssen.

9. Anhang 174

Bedeutet dies nun, dass wenn eine SAS 70 Prüfung vollzogen wurde keine zusätzlichen

Prüfungen der verschiedenen Kunden beim Service Anbieter mehr nötig sind?

Theoretisch ist dies richtig. Dies gilt jedoch nur, wenn eine SAS 70 Prüfung für alle Bereiche

durchgeführt wurde. Kunden können nachträglich eine Prüfung in einem speziellen Gebiet

wünschen. War dieses Gebiet jedoch schon Gegenstand der durchgeführten SAS 70 Prüfung, so

wird dies vom Service Anbieter wahrscheinlich nicht sehr gerne gesehen.

Eine SAS 70 Prüfung ist eine sehr aufwendige und kostenintensive Angelegenheit. Würde

eine ISO 17799 Zertifizierung nicht reichen, um Sarbanes-Oxley konform zu sein? Was ist der

Unterschied zwischen SAS 70 und ISO 17799?

Eine ISO 17799 ist eine gute Grundlage für SAS 70. Jedoch reicht sie nicht, um den Sarbanes-

Oxley-Anforderungen zu genügen. ISO 17799 zeigt das Kontrollwesen nicht auf. ISO 17799 ist

ein Grundlagen-Standard für IT-best practices mit Fokus auf die IT-Security. Es definiert jedoch

kein Kontrollwesen, wie dies bei SAS 70 der Fall ist. Ein SAS 70 soll die Kontrollen innerhalb

des Unternehmens aufzeigen. Der ISO-Standard hingegen zeigt nicht die Kontrollen auf, sondern

beschreibt die Prozesse, die für die Umsetzung der Bereiche in der Informatik notwendig sind.

Oftmals werden Prozess- und Kontrolldokumentationen von den Unternehmen nicht

unterschieden. Dies ist jedoch der wesentliche Punkt für die SAS 70 bzw. Sarbanes-Oxley-

Konformität, die eine Kontrolldokumentation verlangt.

Wenn eine ISO 17799 Zertifizierung vorhanden ist, so ist dies, wie vorher erwähnt, eine gute

Grundlage. Bei einer SAS 70 Prüfung kann auf die Zertifizierung zurückgegriffen werden.

Unternehmen mit einer ISO 17799 Zertifizierung sind demnach einige Schritte weiter als

Unternehmen ohne die Zertifizierung. Wenn der Standard komplett implementiert wurde, so sind

die Prozesse auch dokumentiert und gemäss best practice umgesetzt. Sind die Prozesse

dokumentiert, so ist eine SAS 70 Prüfung schneller durchführbar. Sind die Prozesse nicht

dokumentiert, so können auch keine Kontrollen dokumentiert werden. Muss diese

Dokumentation noch nachgeholt werden, so wird eine SAS 70 Prüfung tatsächlich zu einer sehr

aufwendigen und kostenintensive Angelegenheit.

9. Anhang 175

Zusammenfassend kann demnach festgehalten werden, dass die ISO 17799 Zertifizierung eine

gute Grundlage für ein SAS 70 Prüfung bietet, da ISO 17799 gewährleistet, dass die Prozesse

in ihrem Bereich gut implementiert sind und SAS 70 ist dazu da, um die Kontrollen und deren

Effektivität aufzuzeigen?

Ja, diese Ausführung stimmt. Hinzuzufügen ist, dass ISO 17799 sich nicht mit IT-Prozessen

generell beschäftigt, sondern den Fokus auf die IT-Sicherheit legt. ISO 17799 unterscheidet

keine Prozesse von den Kontrollen. Der Standard beschreibt Kontrollen, diese jedoch nicht

explizit.

SAS 70 unterscheidet zwei verschiedene Prüfungs- bzw. Berichterstattungstypen. Können Sie

noch Näheres dazu sagen?

SAS 70 kennt den Typ I und Typ II. Typ I beschreibt die Kontrollen und Typ II ist eine

Erweiterung. Beim Typ II werden neben der Kontrollbeschreibung zusätzlich Einhalteprüfungen

durchgeführt und somit die Effektivität der Kontrollen getestet. Dazu kann die Abnahme des

Change Management durch die Fachabteilung als Beispiel dienen. Bei der Abnahme muss die

Fachabteilung die Dokumentation zum Change anschauen und unterschreiben. Wird das Change-

Protokoll von einer Fachabteilung unterschrieben, so ist der Change bewilligt. Die Abnahme

durch die Fachabteilung definiert somit eine Kontrolle und diese wird durch das

Abnahmeprotokoll beschrieben. Beim Typ II wird nun diese Kontrolle getestet. Man betrachtet

die Anzahl Changes, die es insgesamt gab und wieviele davon durch die Fachabteilung inklusive

Protokoll abgenommen wurden, d.h. wo es Dokumentationen und Unterschriften zum

entsprechenden Change existieren. Gab es z.B. 120 Changes, aber es existieren nur 30 Protokolle

und der Rest wurde ohne Kontrolle abgenommen, so kann daraus geschlossen werden, dass die

Kontrolle nicht effektiv ist.

Ein SAS 70 kann über verschiedene Bereiche durchgeführt werden. Sei es IT oder Back-

office Prozesse – überall kann nach SAS 70 geprüft werden. In meinen Recherchen habe ich

keine Mindestanforderungen an Bereiche, die bei einer SAS 70 Prüfung abgedeckt werden

müssen, gefunden. Sind die Bereiche im SAS 70 nicht vorgegeben?

Wenn man den SAS 70 Standard durchschaut, so wird ersichtlich, das keine Angaben darüber

gemacht werden, welche Kontrollen durch das SAS 70 beschrieben werden müssen. Das

Unternehmen kann selber definieren, welche Bereiche nach SAS 70 geprüft werden sollen.

9. Anhang 176

Somit kann eine SAS 70 Prüfung z.B. nur über das Change Management erfolgen. Dies wird im

Bericht dementsprechend gekennzeichnet. SAS 70 beschreibt alleine, dass die Kontrollen

aufgenommen werden müssen, jedoch nicht welche Kontrollen bzw. welche Bereiche beachtet

werden müssen. Weiter sagt SAS 70 auch nichts über die Tiefe der Prüfung aus. Ein Kontrollziel

kann sehr oberflächlich definiert werden, wie z.B. Netzwerksicherheit mit dem

Unterkontrollziel, dass das Netzwerk einmal im Jahr durch ein externes Unternehmen mittels

Penetrationstest auf Sicherheit hin überprüft wird. Im Gegensatz dazu kann die Prüfung auch viel

tiefer gehen, z.B. dass im Netzwerk die Firewallregeln entsprechend den verschiedenen

Standards laufend erneuert werden.

Man sieht dabei eine Schwäche des SAS 70. Die Unternehmen besitzen einen sehr hohen

Freiheitsgrad, in welchen Bereichen sie geprüft werden sollen. Für die externen Prüfer wiederum

besteht auch keine Richtlinie, wie tief sie in ihrer Prüfung gehen sollen.

Gibt es für Unternehmen, die sich keiner SAS 70 Prüfung unterziehen wollen, Alternativen zu

einer SAS 70 Prüfung?

Eine direkte Alternative zu SAS 70 kommt mir jetzt nicht in den Sinn. Die mir bekannten

Prüfungsarten zeigen keine Kontrollen auf, sondern geben ein Testat für den Zustand ab. Wenn

ein Unternehmen nach COBIT geprüft wurde, so könnte dies eine Annäherung zu SAS 70 sein,

weil COBIT auch das Kontrollwesen zum Inhalt hat.

Stellt COBIT für Sie auch eine Hilfe bei einer SAS 70 Prüfung beim Kunden dar?

Da wir bis anhin in der Schweiz noch keine direkte SAS 70 Prüfung im Bankenbereich

durchgeführt haben, kann ich dazu noch keine genauen Angaben machen. Wir stecken mitten in

den Vorbereitungen.

Sie haben vorhin erwähnt, dass COBIT in Richtung einer SAS 70 Prüfung zielt. Da COBIT

Kontrollziele definiert, könnte man diese nicht gleich für die SAS 70 Prüfung benutzen?

Die Idee, die mir vorschwebt, geht in die gleiche Richtung. Wobei hier gewisse

Einschränkungen gemacht werden müssen, da COBIT nicht ganz in die Tiefe geht. Z.B. wird die

Netzwerksicherheit in COBIT nicht in die Tiefe behandelt. Da ist COBIT zu grob definiert. Eine

Möglichkeit wäre ITIL zur Hilfe zu nehmen, um eine genügende Prüftiefe zu erhalten.


9. Anhang 177

9.2 IT-Sicherheitsstandards

Abbildung 28: IT-Sicherheitsstandards236

236 BITKOM (2005), S. 9.

9. Anhang 178

Erklärung

Ich bestätige, dass die vorliegende Arbeit ohne fremde Hilfe und ohne Benützung anderer als der

angegebenen Hilfsmittel verfasst habe.

Zürich, 16.09.2005 ……………………………...

Bimal Mathews

Documents

Prüfung outgesourcter Informatikleistungen ... · Der Sarbanas-Oxley Act ist ein Gesetz, welches im Jahre 2002 in den USA erlassen wurde, mit dem Ziel die Investoren vor falscher