Prüfung outgesourcter Informatikleistungen

Transcrição

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
(PricewaterhouseCoopers),
Allenspach
Frank
(Luzerner
Hammer
(IBM
Kantonalbank),
Mark
Deutschland),
Michel
Dambacher
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
2
Einleitung ................................................................................................................................ 1
1.1
Problemstellung .............................................................................................................. 1
1.2
Zielsetzung...................................................................................................................... 2
1.3
Vorgehensweise und Aufbau .......................................................................................... 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
3
Zusammenfassung ........................................................................................................ 24
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
3.2
IV
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 ITSecurity ............................................................................................................. 42
3.3.5 Kontrollverfahren.............................................................................................. 46
3.4
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
5
4.5
Überprüfbarkeit der IT-Security im Outsourcing ......................................................... 63
4.6
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
5.5
V
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
5.8
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
7
8
Zusammenfassung ...................................................................................................... 115
Schlussbetrachtung ............................................................................................................ 116
7.1
Zusammenfassung ...................................................................................................... 116
7.2
Schlussfolgerungen..................................................................................................... 117
7.3
Ausblick ...................................................................................................................... 117
Literaturverzeichnis........................................................................................................... 119
Inhaltsverzeichnis
9
VI
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
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
VIII
1. Einleitung
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
IX
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 ITSecurity erarbeitet.
2. Grundlagen des Outsourcing
2
4
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.
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.
2
5
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 Softwareapplikationen 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.
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.
8
6
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.
7
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 OutsourcingEntscheidung erläutert. Dies geschieht unter der Berücksichtigung der verschiedenen
Perspektiven: Outsourcer-, Markt- und Service Anbietersicht.
14
Vgl. Deutsche Bank Research (2004), S. 4.
8
Outsourcer
Markt
Service Anbieter
TechnologieÄnderungen
Kostendruck
(Outsourcer)
Outsourcing
Beziehung
Revenue-Zwang
(Service Anbieter)
Regulatorische
Änderungen
(Outsourcer)
Änderung der
Marktbedingungen
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
16
Vgl. Applegate /Austin / McFarlan (2003), S.566.
Vgl. Anhang Interview Allenspach.
9
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 Knowhow 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 ITInfrastruktur 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.
10
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 beschriebenen 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.
Vgl. Anhang Interview Pfister.
20
Vgl. Anhang Interview Mühlenbrock / Hammer.
21
19
11
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 OutsourcingVarianten 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 ITSystemen 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.
12
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.
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.
24
13
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 BackupInfrastrukturen 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
14
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-manyapproach). Wie beim Application Hosting werden die Softwarepakete in einem ServiceRechenzentrum 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.
15
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
31
Vgl. Riedl (2003), S. 7.
Vgl. Schaarschmidt (2003), S. 46 – 50.
16
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.
17
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
35
Vgl. Bauknecht (2003), S. 13.
Vgl. Krcmar (2003), S. 296.
18
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.
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.
37
19
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 Partnerschaft. 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.
Vgl. Weber (2003), S. 124.
40
41
Vgl. Neuenschwander (2003), S. 72.
39
20
Eine Möglichkeit, die sich zur Flexibilisierung bietet, ist die Ausgestaltung des OutsourcingVertrages 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.
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.
43
21
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.
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
47
22
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
23
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
Personal

Risiken der vertraglichen Preisfixierung

Nichteintreffen erwarteter Kostensenkungen

Personalpolitische und arbeitsrechtliche Probleme hervorgerufen
durch mögliche Kündigungen oder Vertragsänderungen, die beim
Wechsel zum Service Anbieter vorgenommen werden müssen
Technologie
Know-how

Verlust von Schlüsselpersonen und deren Know-how

Starre Bindung an die Technologie des Service Anbieter

Gefahr einer zu grossen Standardisierung

Transfer von Know-how und damit verbundenen Wettbewerbsvorteilen an Konkurrenten

Zunehmende Auslagerungsaktivitäten ziehen einen Verlust von ITKompetenzen 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
24
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
25
Mischform zwischen verschiedenen Vertragstypen enthalten. Als Kern des OutsourcingVertrages 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
3
26
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:
58

Effektivität und Effizienz der Tätigkeiten

Verlässlichkeit der finanziellen Berichterstattung

Gesetzes- und Normenkonformität.“ 58
Vgl. Committee of Sponsoring Organizations of the Treadway Commission (1994), S. 3.
27
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.
Internal Control (IC)
Prozessabhängige Control
Prozessunabhängige Control
= Interne Steuerung und Kontrolle (ISK)
= Interne Prüfung
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
60
Vgl. Ruud / Jenal (2005), S. 456.
Ruud / Jenal (2005), S. 456.
28
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.
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.
62
29
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.
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.
67
30
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 Unternehmensleitung 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 Managementkontrolle ü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.
Vgl. Internal Auditor (2005), S. 53.
75
Vgl. Ricchiute (2003), S. 202.
74
31
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 Unternehmensziele 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
77
Oftmals auch Kontrollprozeduren genannt.
Vgl. Robertson / Louwers (2002), S.150-155.
32
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

78
Möglichkeit grosse Transaktionsvolumen oder Datenmengen zu verarbeiten
Vgl. Internal Auditor (2005), S. 53.
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.
79

33
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.
34
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 ITKomponente 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-Dienstleistungen, 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.
35
UNTERNEHMENSZIELE / PROZESSE
COBIT
Information
• Effektivität
• Effizienz
• Vertraulichkeit
• Integrität
• Verfügbarkeit
• Gesetzesmässigkeit
(4 IT-Prozesse)
• Zuverlässigkeit
Überwachung
Planung &
Organisation
(11 IT-Prozesse)
IT-Ressourcen
• Personal
• Applikationen
• Technologie
Auslieferung &
Unterstützung
• Anlagen
• Daten
Akquisition &
Implementation
(10 IT-Prozesse)
(13 IT-Prozesse)
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 ITLebenszyklus 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.
36
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 ITOrganisation 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.
37
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.
Vgl. Zimmermann (2005), S. 39.
89
Vgl. IT Governance Institute (2004a), 16-22.
88
38
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. Informationssicherheit 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
Geschäftsprozesse
Informationssicherheit
IT-Security
IT-Applikationen
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.
39
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
92
Vgl. Czurda (2002), S. 55 – 58 und Anhang Interview Pfister.
40
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
41
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 ITProzess „DS5: Ensure Systems Security“ explizit einen Leitfaden bzw. Kontrollziele zur
Verfügung, die einem Unternehmen verhelfen sollen die Systeme gemäss der IT-SecurityDefinition aufrecht zu erhalten. DS5 definiert insgesamt 21 Unterprozesse, die verhelfen sollen
94
IT Governance Institute (2004b), S. 11.
42
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 InformationssicherheitsManagementsystems (ISMS). Für diesen Zweck enthält ISO 17799 einen Katalog mit 110
95
IT Governance Institute (2000b), S. 100.
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.
96
43
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
1. Informations-Sicherheitspolitik:
Massnahmen
Schriftlich festgehaltenen Direktiven des
Managements
2. Sicherheitsorganisation:
Sicherheitsausschuss, Verantwortlichkeiten,
Verträge mit Externen, Koordination
3. Klassifizierung und Steuerung der
Klassifizierungsrichtlinien
Vermögenswerte:
4. Personelle Sicherheit:
Stellenbeschreibung, Rekrutierung,
Vertraulichkeitsvereinbarungen, Schulung
5. Physische und umgebungsbezogene
Sicherheit:
6. Management der Kommunikation des
Betriebs:
7. Zugangssteuerung (Zutritt, Zugriff,
Zulassung):
8. Systementwicklung und – wartung:
Zutrittsregelungen, Lieferanten, „Clean
Desk“-Politik, Sicherheit der Räumlichkeiten
Dokumentation von Abläufen,
Funktionentrennung, Datenaustausch
Berechtigungsadministration, Sicherheit von
Netzwerk- und Rechnerzugriff
Festlegung von Sicherheitsanforderungen,
Entwicklungsstandards
9. Management des kontinuierlichen
Notfall-Organisation, Notfallkonzept
Geschäftsbetriebs:
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.
44
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 ITSicherheitshandbuch. 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.
45
Common Criteria102
Wie Abbildung 13 aufzeigt, sind die Common Criteria (CC) aufgrund der Standardisierungswü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
46
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 Hacker104Angriffen 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.
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.
104
47
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 Sicherheitsbeauftragten.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.
48
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
4
49
Outsourcing und der Einfluss auf den Outsourcer und
Service Anbieter
In den vorhergehenden Kapiteln wurde eine Einführung in das Outsourcing und in die ICThematik 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 OutsourcingGeschä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.
Externe
Prüfer des
Outsourcer
50
Externe
Prüfer des
Service
Anbieters
PS 402 Zif. 11 ff.
PS 402
Outsourcer
Service Anbieter
Outsourcing - Vertrag
Interne Revision
Interne Revision
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.
51
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.

52
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 OutsourcingVertrag ist.
114
115
Vgl. Eidgenössische Bankenkommission (1999), Grundsatz 3 Ziffer 26 und Ziffer 27.
Vgl. Eidgenössische Bankenkommission (1999), Grundsatz 2 Ziffer 24.
4.2.2
53
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ässigkeitsprü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.
118
119
120
Vgl. Anhang Interview Huissoud.
117
54
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
122
Weitere Informationen unter: http://www.ifac.org.
Vgl. Treuhandkammer (2004), PS 402 Ziff. 5.
55
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 OutsourcingVorhaben
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.
Vgl. Treuhandkammer (2004), PS 402 Ziff. 8 und 9.
125
Vgl. Anhang Interview Dambacher.
124
56
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 ITSicherheitskonzept 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 ITSicherheitskonzepts“.
127
4.4.1
57
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 Sicherheitskonzepts 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:1Beziehung 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
Outsourcer
Service Anbieter
IT-Security-
IT-Security-
Verantwortlicher
Rechtsabteilung
Verantwortlicher
Sicherheitskonzept
Kundenverantwortlicher
„Business“
Rechtsabteilung
Personalabteilung
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
130
Die Abbildung und die Ausführungen entstammen den Erkenntnissen aus den Experteninterviews. Vgl. dazu
Anhang Interviews Allenspach, Illi, Pfister und Mühlenbrock / Hammer.
129
58
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
59
die Massnahmen betreffend den Schulungen der Mitarbeiter von Interesse. Um solche
Restriktionen einbrinigen zu können, nimmt die Personalabteilung an den Verhandlungen teil.132
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 ITSicherheitsstrategie bzw. –richtlinie. Das Management des Outsourcer und des Service Anbieters
wird beauftragt, eine schriftliche Verankerung der gemeinsamen IT-Sicherheitsstrategie zu
132
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“.
133
60
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 ITSecurity.

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:
135

Verantwortlichkeiten inkl. Verantwortlichkeitstrennungen

Betriebsmittelverwaltung

Reaktionen auf Verletzung der Sicherheitspolitik resp. –richtlinen

Unabhängige IT-Security-Kontrollinstanzen.
Vgl. Schweizerische Normen-Vereinigung (2001), S. 2.
Vgl. Schweizerische Normen-Vereinigung (2001), S. 2 – 8 und Bundesamt für Sicherheit in der
Informationstecknik (2004), Kapitel 3.1: „Organisation“.
136
61
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 geschä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 Rechenzentrum 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 Telekommunikationsverkabelung oder Anlagenwartung.
Logische Zugriffskontrollen140
Logische Zugriffskontrollen behandeln die Zugriffe auf Grossrechner, sogenannten HostSysteme, oder LAN-Systeme141.
137
Vgl. Schweizerische Normen-Vereinigung (2001), S. 13 – 19.
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².
138
62
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 ausgesucht 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.
Vgl. Schweizerische Normen-Vereinigung (2001), S. 10 – 13 und Bundesamt für Sicherheit in der
Informationstecknik (2004), Kapitel 3.2: „Personal“.
143
63
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.
Vgl. Vgl. Schweizerische Normen-Vereinigung (2001), S. 56 – 60 und Bundesamt für Sicherheit in der
Informationstecknik (2004), Kapitel 3.3: „Notfallvorsorge-Konzept“.
145
64
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 ISONorm 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 ITSecurity 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-SecurityMassnahmen 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 OutsourcingBeziehung 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
147
65
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 ITSicherheitskonzepts 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
5
66
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 ITSecurity 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
Unabhängiger Bericht der externen
Prüfgesellschaft (The Auditors opinion
Typ I Report
Typ II Report
D
D
D
D
Nicht enthalten
D
Optional
Optional
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
Andere Informationen z.B. Glossar
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
154
Vgl. Dambacher / Hug (2005), S. 22.
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 Zutrittskontrollen, 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 Ausfü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
156
In Anlehung an PricewaterhouseCoopers (o.J.), S. 8.
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
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
Der Sarbanes-Oxley Act
SOX
wurde
durch
die
Urheber
Senator
Paul
Sarbanes
und
Mitglied
des
Repräsentantenhauses Micheal Oxley als Investorenschutzgesetz erschaffen. Mit der Unterzeichnung am 30. Juli 2002 durch den Präsidenten der Vereinigten Staaten von Amerika trat
161
162
Vgl. SAS 70 (2005a), o.S.
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.
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.
164
5. SAS 70
5.5.2
75
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 COSOFramework 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
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
5.6.3
78
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.
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.
177
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.
182
Vgl. dazu Abschnitt 5.4.
181
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.
Vgl. Meyer (2004), S. 212.
185
Vgl. American Institute of Certified Public Accountants (2003), S. 4 Fussnote 2.
184
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.
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.
187
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ügbarkeit 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
Unterstützt den externen
Sichert zu, dass das Unter-
Prüfer mit Informationen über
nehmen eines oder mehrere
die Kontrollen des Service
Trust Service Prinzipien und
Anbieters.
die Kriterien erfüllt.
Gegenstand der Bericht-
Kontrollen des Service An-
Interne Kontrolle bzw. IC die
erstattung
bieters, die einen Einfluss auf
mit finanziellen oder nicht
die Jahresrechung des Out-
finanziellen Systemen in Be-
sourcer haben können.
ziehung stehen.
Liefert eine Beschreibung der
Sichert zu, dass die
Kontrollen, die Angemessen-
Kontrollen des Unterneh-
heit der Kontrollen und eine
mens über ein definiertes
Aussage über die Effektivität
System die Trust Service
der Kontrollen
Kriterien befriedigen und die
Zweck des Report
Eigenschaft des Report
Prinzipien untersucht wurden.
Adressate des Report
Service Anbieter, Kunden des
Beliebige Anteilshaber des
Service Anbieters und deren
Unternehmen, wie z.B.
externe Prüfgesellschaften,
Management, Kunden und
potentielle Kunden, Ge-
Business Partner.
schäftspartner und Behörden.
Spezifische
Kontrollziele Kontrollziele und –aktivitäten
und –aktivitäten
sind in SAS 70 nicht definiert,
Prinzipien und Kriterien sind
durch das AICPA definiert.
da SAS 70 keine Best Practice Diese sind für das Bestehen
Prüfung ist.
Abbildung 18: Unterschiede zwischen SAS 70 und Trust Services191
191
In Anlehnung an SAS 70 Solutions (2005a), o.S.
der Prüfung unerlässlich.
5. SAS 70
85
Unterschiede von SAS 70 zu ISO 9000192 bzw. ISO 17799
5.7.3
Im Zusammenhang einer SAS 70 Prüfung kann angenommen werden, dass die ISO-Zertifizierungen 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ü-
Durch ein Certified Public Jegliches Unternehmen, das
fungen
Accounting Unternehmen.
durch ISO authorisiert wurde
Zertifizierungen
durchzuführen.
Resultat der Prüfung
Detaillierter Report.
ISO-Zertifizierung.
Was steht im Fokus der Die ganze interne Kontrolle Qualitätsmangementprozesse.
Prüfung?
bzw. IC.
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
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
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
6
88
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.
Phase I
Prüfungsvorbereitung
Phase II
Prüfungsplanung
Phase III
Prüfungsdurchführung
Phase IV
89
Abschluss der Prüfung
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.
Vgl. Treuhandkammer (1998), S. 112 - 117.
202
Vgl. Treuhandkammer (1998), S. 118 – 143.
201
90
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
205
Vgl. Gray / Manson (2000), S. 244.
206
Vgl. Gray / Manson (2000), S. 246 – 256.
204

91
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 Applikationskontrollen.
Kontrollaktivitäten
Applikation # 1
Eingabekontrolle
Prozesskontrolle
Ausgabekontrolle
Applikation # 2
Eingabekontrolle
Prozesskontrolle
Ausgabekontrolle
APPLIKATIONSKONTROLLEN
GENERELLE KONTROLLEN
Entwicklungskontrollen
Organisatorische Kontrollen
Sicherheitskontrollen
Abbildung 21: Beziehung Generellen Kontrollen zu Applikationskontrollen
207
Vgl. Committee of Sponsoring Organizations of the Treadway Commission (1994), S. 54.
92
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 Applikationskontrollen.
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
209
93
Bestellung des Kunden
Warenverkaufsprozess
Verbuchung im
Buchhaltungssystem
durch Buchhalter
Prüfung der
Buchung durch
Finanzchef
Mögliche
Kontrollen
Lieferung der
Ware
Buchhaltungssytem
Buchhaltungssytem
Buchhaltungssytem
Warenlagersystem
Debitorensystem
Warenlagersystem
• Falsche Verbuchung
durch den Buchhalter
(absichtlich/unabsichtlich)
• Unkorrekte Verbuchung
durch das System
• Akzeptieren der falschen
Buchung
• Falsche Verknüpfung des
Warenlagersystems mit
dem Buchhaltungssystem
• Debitorensystem
verbucht nach
Einstandpreis
• Keine definitive
Buchung möglich. Sie
muss zuerst durch
Finanzchef visiert
werden.
• Prüfung der Buchung mit
dem Originalbeleg
• Visierung (mit
Unterschrift zu bestätigen)
• Systemmeldung, wenn
Verkaufspreis des
Warenlagersystems
ungleich dem
Buchungsverkaufswert ist
• Kontrolle durch
Debitorenbuchhalter
anhand des Eintrags im
Buchhaltungssystem.
Involvierte
ITSytsteme
Mögliche
Risiken
Ausbuchung der
Ware aus dem
Warenlager und
Buchung des
Ertrags
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.
94
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
212
Herv. d. Verf.
Public Company Accounting Oversight Board (2005), S. 158 – 159.
95
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.
Vorbereitung und Ziel
Risikobeurteilung und
SAS 70 Typ I
Prüffungsplanung
Identifizierung
signifikanter
Kontrollen
Identifizierung der
SAS 70 Typ II
Mängel
Dokumentation der
Kontrollen
Planung der
Evaluation der
Kontrollen
Durchführung der
Tests
Identifizierung der
Mängel
Dokumentation
Abbildung 23: Konzeptüberblick SAS 70 Prüfprozess
96
6.4.1
97
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.
215
Vgl. Anforderungen Section 302 und 404 des SOX in Abschnitt 5.5.1.
214
6.4.2
98
Vorbereitung
I. Vorbereitung und Ziel
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
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
99
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
216
217

Kurzbeschreibung des Unternehmens

Umsatz

Leistungen und Produkte

Informatikumfeld

Ablauforganisation und Interne Kontrolle

SLA
Vgl. Treuhandkammer (1998), S. 112.
Vgl. Treuhandkammer (1998), S. 114.

Führungsinformationen

Jahresabschlüsse, Geschäfts- und Prüfungsberichte der Vergangenheit.
100
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 Ablaufplä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
Management des Service Anbieters
101
Grund
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
Für technische Fragestellungen.
Systemadministrator
Prozess-Verantwortlicher219:

Steht für Fragen rund um den Prozess zu Verfügung.
IT-Security Management
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 Wird bei Fragestellungen rund um die physische
stehenden Lokationen
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
102
Planung
II. Risikobeurteilung und Prüfungsplanung
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
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 ITSecurity abgedeckt sind.
103
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.
I: Separate Risikoidentifizierung. Die
Gliederung erfolgt
gemäss den zehn ISO
17799 Themen
Service Anbieter
Prüfgesellschaft
Risikoidentifizierung
Service Anbieter
nach ISO 17799
Themen
Risikoidentifizierung
Prüfgesellschaft
nach ISO 17799
Themen
II: Sammlung aller
gefundenen Risiken
geordnet nach den
ISO 17799 Themen
III: Bewertung der
einzelnen Risiken
nach Eintrittswahrscheinlichkeit und
Auswirkung (Skala: 1
(niedrig) – 5 (hoch) )
104
Sammlung der
Risiken
Bewertung der
Risiken durch
Service Anbieter
IV: Die Durchschnittsnoten 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
Bewertung der
Risiken durch
Prüfgesellschaft
105
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
Ziel: Identifikation der signifikaten IT-Generellen Kontrollen im Bereich der IT-Security.

Prüfgesellschaft

Service Anbieter
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
223
Vgl. Treuhandkammer (1998), S. 130 wobei der Begriff des „Systems“ durch ISK ersetzt wurde.
106
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
Ziel: Mängel an den identifizierten Kontrollen sind bestimmt.

224
Prüfgesellschaft
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.
107
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 (IstKontrollen) übereinstimmen. Dabei werden insbesondere die Schlüsselkontrollen miteinander
verglichen. Sind einzelne Schlüsselkontrollen nach Einschätzung des Prüfers nicht implementiert, 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.
108
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
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
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.
109
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.
110
VI. Planung der Evaluation der Kontrollen
Ziel: Gesamtplanung der Kontrollenüberprüfung.

Prüfgesellschaft
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
111
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
Ziel: Die Kontrollen werden stichprobenartig auf deren Effektivität hin getestet.
Beschreibung:

Prüfgesellschaft

Service Anbieter: Involvierte Personen gemäss Abbildung 24
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.
112
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
Werden laufend
Siehe Log-File der letzten
ABC werden wie im IT-
Zustandsprüfungen an den
sechs Monate
Sicherheitskonzept
Systemen des Kunden ABC
angegeben, laufend auf ihren
vorgenommen, wie es laut
Zustand hin überprüft.
Sicherheitskonzept definiert
wurde?
(Beurteilungsunterlagen:
Aussage Systemadministrator
und die Log-Files 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
113
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
Ziel: Identifizierung der Mängel aus den durchgeführten Tests.

Prüfgesellschaft
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
229
Vgl. Abschnitt 5.2.
vgl. Anhang Interview Dambacher und Mühlenbrock / Hammer.
6.4.5
114
Abschlussarbeiten
IX. Dokumentation
Ziel: Berichterstattung über die Kontrollen mit Informationen bezüglich deren
Effektivität.
Beschreibung:
Prüfgesellschaft
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.
6.4.6
115
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 nichtstandardisierte 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 SOXAnforderungen.
7. Schlussbetrachtung
7
116
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 ITBereich 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 ITSecurity 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.
117
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 SOXKonformitä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.
118
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
8
119
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
120
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 ITUmgebungen 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_DEPROD/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-4309A49B90A37CA04F7B&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
„http://www.systemexperts.com/tutors/sas70.pdf”, abgerufen: 03.08.2005.
Clothes”,
in:
121
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.
122
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.
123
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 ondemand-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.soxonline.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/profpract/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.
124
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. 117138.
Zimmermann, René (2005): „Serviceorientierung wird zertifizierbar“ in: „Infoweek”, Nr.
11/2005, Thalwil 2005, S. 39 – 41.
9. Anhang
9
125
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-SecurityGovernance“. 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 „BenchmarkAssessment 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 Sicherheitsorganisation 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: ITAbteilung, 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 Skalenund 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 ITRevisors 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
Grundschutzanforderungen etc.
der
Systeme,
Vertraulichkeit
oder
Zugriffsrechte,
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 ITSecurity 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 OutsourcingVorhabens 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: DoubleOutsourcing – 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 OutsourcingVorhaben 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. Penetrationstests 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 OutsourcingProzess 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ässigkeitsprü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 ITSicherheitskonzept 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 HealthChecks 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 SOCSAbteilung, 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 SOXZertifizierung 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 SOXKonformitä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-SOXZertifizierung 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 FirewallRegeln 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 OutsourcingBeziehung 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 SarbanesOxley-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-OxleyKonformitä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 ChangeProtokoll 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 Backoffice 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
9.2 IT-Sicherheitsstandards
Abbildung 28: IT-Sicherheitsstandards236
236
BITKOM (2005), S. 9.
177
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