Navigator im Compliance‐Dickicht
Die Kosten und der personelle Aufwand zur Erfüllung von Compliance‐Anforderungen sind
sig...
der sich die vielfältigen Fragen der Revisoren («Wie ist sichergestellt, dass…») ergeben. Konzeptionell bedingt dies
neben...
SOX 404: US‐amerikanisches Regelwerk zur Sicherstellung von adäquaten internen Kontrollsystemen für das
Finanzreporting vo...
Nächste SlideShare
Wird geladen in …5
×

Navigator im Compliance-Dickicht - computerworld.ch - Matthias Leisi

158 Aufrufe

Veröffentlicht am

0 Kommentare
0 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
158
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
14
Aktionen
Geteilt
0
Downloads
2
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Navigator im Compliance-Dickicht - computerworld.ch - Matthias Leisi

  1. 1. Navigator im Compliance‐Dickicht Die Kosten und der personelle Aufwand zur Erfüllung von Compliance‐Anforderungen sind signifikant. Erst die Integration in den regulären Betrieb macht Compliance‐Prozesse wirtschaftlich. » Von Matthias Leisi*, 09.01.2012 06:45. Es gibt heute nur noch wenige Branchen, die sich der Compliance, also von aussen vorgeschriebenen Regeln für den Aufbau und Betrieb der IT‐Infrastruktur, entziehen können. Unternehmen mit staatlicher Regulierung im Finanz‐ oder Pharmasektor sind davon besonders betroffen, aber auch private vertragliche Bestimmungen sehen zunehmend dedizierte Anforderungen an die Compliance vor, etwa zwischen Lieferanten und Zulieferern. Mit einem integrierten Ansatz kann der extern vorgegebene Compliance‐Aufwand gleichzeitig zur Verbesserung der operativen Prozesse genutzt werden. Je besser die Implementierung der Konzepte aufeinander abgestimmt ist, desto profitabler wird das Verhältnis von Nutzen und Ertrag sein. Denn die Messdaten aus dem operativen Betrieb dienen auch zur Verbesserung der Prozesse und gleichzeitig als Nachweis zur Erfüllung von Revisionsauflagen. Dieses Konzept, das immer auch an die jeweilige Situation angepasst werden muss, hat sich bereits in konkreten Kundenprojekten bewährt. Integrierter Ansatz Ein integrierter Ansatz berücksichtigt operative Prozesse (nach ITIL), die IT‐Sicherheit (häufig ein Information‐Security‐ Management System, ISMS nach ISO27001), die IT‐Audit‐Sicht (nach COBIT) wie auch externe Compliance‐Anforderungen (z.B. FINMA‐Outsourcing‐Richtlinie, PCI/DSS, SOX IT General Controls etc.). Zudem muss man der Beziehung zwischen Kunde und Outsourcing‐Dienstleister Rechnung tragen – und zwar von der Definition der Rahmenbedingungen über die Transformation der Dienste bis zu einem prozessorientierten IT‐Service‐ Management einschliesslich des Service‐Managements zwischen Kunde und Dienstleister. Zum Beispiel stellen die FINMA‐ Outsourcing‐Richtlinie 2008/7 und PCI/DSS formale und inhaltliche Anforderungen an die Ausgestaltung der Beziehung zwischen Kunde und Dienstleister, etwa die Schriftform von vertraglichen Abmachungen, die Gewährleistung von Revisionspflichten und Ähnliches. Um sich im Dschungel der internen und externen Regulierungen, Prozesse und Standards nicht zu verlieren, sollte man intern und im Verhältnis zwischen Kunde und Dienstleister auf eine vereinfachte Darstellung der Prozesse und ein eingängiges Konzept setzen. Standardisierte Dokumente helfen bei der internen Kommunikation und bei der Diskussion zwischen verschiedenen Partnern. Auf der nächsten Seite: So funktioniert der Dreistufenplan. Dreistufenplan Der integrierte Ansatz geht von drei Voraussetzungen aus: dem IT Risiko‐Management, einem Control‐ und Management‐ Framework (d.h. eine IT‐Sicherheitsarchitektur und ein System zur Betriebsführung) sowie ITIL‐ und ISO27001‐basierende Standardprozesse. Risk Analysis: Das IT‐Risiko‐Management sollte aus Sicht des integrierten Ansatzes so einfach wie möglich gestaltet werden. Falls es keine internen oder externen Vorgaben gibt, reicht oft ein einfacher Fragebogen aus, strukturiert nach den Domänen von ISO 27001 (physische Sicherheit, Zugriffskontrollen etc.). Ein solcher Fragebogen mit geeignet gewählten Metriken kann im IT‐Betrieb qualitativ wie quantitativ für Transparenz sorgen und bei regelmässiger Wiederholung die Veränderungen sichtbar machen. Control‐ und Management‐Framework: Zwar ist eine manuelle Umsetzung der Prozesslandschaft nach ITIL und ISO 27001 prinzipiell denkbar, aber dieser «IT‐zu‐Fuss»‐Ansatz skaliert nicht über eine triviale Anzahl Systeme hinaus und ist aus Sicht der Revisionsfähigkeit schwierig umzusetzen. Die technische Umsetzung in einem Control‐ und Management‐Framework ermöglicht dagegen ein hohes Mass an Automatisierung und damit an Transparenz und Prozesstreue. Dieses Framework muss auch die Handlungen von hoch privilegierten Administratoren überprüfbar machen, um in einer IT‐Revision bestehen zu können. «Wer hat wann was gemacht?», ist die zentrale Frage, aus
  2. 2. der sich die vielfältigen Fragen der Revisoren («Wie ist sichergestellt, dass…») ergeben. Konzeptionell bedingt dies neben dem System zur Betriebsführung eine zusätzliche Kontrollebene, die sowohl die produktiven Systeme als auch das System zur Betriebsführung selbst überwacht. Standardprozesse: Der dritte Pfeiler des integrierten Ansatzes ist ein konsistenter Satz an Prozessen. Die meisten Prozesse werden von ITIL vorgegeben, und normalerweise gibt es keinen Grund, von diesen Prozessen abzuweichen. Lediglich die Ausführung der einzelnen Arbeitsschritte (Service Tasks) und die konkreten Inputs und Outputs der Prozesse müssen individuell definiert werden. In der Regel sind verschiedene Anbieter auf Netzwerk‐, System‐ und Applikationsebene sowie interne Leistungserbringer in dieser Prozessdefinition zu berücksichtigen. Compliance als Führungsaufgabe Die drei Voraussetzungen – Risikoanalyse, Control‐ und Management‐Framework, Definition der Service Tasks – sind kein Selbstzweck. Durch eine Transformationsphase gelangt man zu einer reifen, hoch automatisierten und effizienten Prozessumgebung. Die Transformation ist einerseits eine technische Aufgabe: Die gewählten Systeme sind in das Control‐ und Management‐Framework zu integrieren und es sind allenfalls zusätzliche Sicherheitsmassnahmen einzuführen. Vor allem aber ist diese Transformation eine Führungsaufgabe: Die eigene Organisation muss in eine veränderte Prozesswelt geführt werden – dies umso mehr, wenn zusätzlich neue Outsourcing‐Partner hinzukommen. Der Lohn der Mühen wird in der Service‐Management‐Phase sichtbar. Kern eines Control‐ und Management‐Frameworks ist die Sammlung von Daten, insbesondere in einer CMDB (Configuration Management Database). Da es wenig sinnvoll ist, eine CMDB manuell auf dem aktuellen Stand zu halten, muss diese durch regelmässige Scans automatisch aktualisiert werden. Als Nebeneffekt dieser und weiterer Datensammlungen fällt eine Unmenge von Daten an, die für das Reporting über die Dienste – und letztlich zu deren Verbesserung – verwendet werden können. Weiter geht es auf der nächsten Seite. Für eine effiziente Steuerung des Betriebs und aus Revisionsgründen ist es unerlässlich, das Berichtswesen schriftlich festzuhalten. Dazu zählt die Informationsquelle (Welche Werte kommen woher?), Zweck und Empfänger der Berichte sowie deren Häufigkeit. Ausserdem sind Key‐Performance‐Indikatoren zu bestimmen und vor allem zuverlässige Grenzwerte zu definieren, etwa für das Service Level Management. Idealerweise sollten solche Berichte jederzeit für die berechtigten Empfänger abrufbar sein. Im Umkehrschluss heisst das, dass diese Berichte automatisch bereitgestellt werden müssen. Einfaches, transparentes Modell Ein integriertes, eingängiges und transparentes Modell, kombiniert mit standardisierten Werkzeugen, reduziert den Aufwand für (IT‐)Compliance und optimiert gleichzeitig den IT‐Betrieb. Unter den richtigen Vorzeichen lässt sich durch den Einfluss von Compliance, IT‐Governance und IT‐Audit ein effizienterer und schliesslich kostengünstigerer IT‐Betrieb realisieren. Das bedingt eine Investition in die richtigen Werkzeuge. Diese unterliegen Skaleneffekten: Es braucht einerseits eine gewisse minimale Grösse, um sie sinnvoll einzusetzen. Andererseits lässt sich das Wachstum eines IT‐ Betriebs mit solchen Werkzeugen – richtig eingesetzt – wesentlich einfacher bewältigen. *Matthias Leisi ist Senior Consultant im Bereich Risk & Compliance bei Colt (http://www.colt.ch/) . Einordnung der Compliance‐Systeme Basel II/III: Operatives (IT‐) Risiko‐Management im Bankenumfeld. Ein ISMS nach ISO 27001 oder die Erfüllung von PCI/DSS‐Kriterien können Teil des operativen Risiko‐Managements sein. ISO 2700x: Zertifizierbares Information‐Security‐Management‐System (ISMS). ISO 27002 ist der Standard, ISO 27001 de‐ finiert die Anforderungen. ITIL/ISO 20000: Ursprünglich eine Sammlung von «Best Practices» zur Umsetzung eines IT‐Service‐Managements. ISO 20000 basiert auf ITIL, mit Ergänzungen. Einzelpersonen können verschiedene ITIL‐Zertifizierungen erwerben, Organisationen nach ISO 20000 zertifiziert werden. COBIT: Integriert die IT‐ in die Corporate Governance und wird häufig von IT‐Auditoren verwendet. COBIT ist an das Corporate Governance Framework COSO angelehnt und soll die Lücke zwischen COSO und den IT‐Modellen ISO 27001 sowie ITIL schliessen. PCI/DSS: Anforderungen der Kreditkartenindustrie an die IT‐Sicherheit angeschlossener Händler und Dienstleister. Der Fragenkatalog ist technischer und detaillierter als z.B. ein ISO 27001 «Statement of Applicability»; die meisten Kapitel aus dem Fragenkatalog können auch in anderen Umgebungen sinnvoll eingesetzt werden. Händler (und andere, die Kreditkartendaten verarbeiten) müssen nach PCI/DSS zertifiziert sein, bei Androhung des Ausschlusses aus dem Kreditkartensystem.
  3. 3. SOX 404: US‐amerikanisches Regelwerk zur Sicherstellung von adäquaten internen Kontrollsystemen für das Finanzreporting von börsenkotierten Firmen, auch im Hinblick auf IT‐Prozesse (IT General Controls, ITGC). COBIT ist eine sinnvolle Basis zur Ausgestaltung der ITGC. Mit der sinkenden Zahl von europäischen Firmen, die an US‐ amerikanischen Aktienmärkten gelistet sind, sinkt auch die Bedeutung der SOX 404 ITGC in Europa. FINMA: Eine FINMA‐Zertifizierung gibt es nicht. Es gibt aber Institute (Banken, Effektenhändler etc.), die der Auf‐sicht der FINMA und damit den entsprechenden aufsichtsrechtlichen Revisionspflichten unterstehen. Dies bedeutet aber keine eigenständige Zertifizierung. © 1985 ‐ 2015 IDG Communications AG ‐ Alle Rechte vorbehalten. Vervielfältigung oder Weiterverarbeitung in Teilen oder als Ganzes nur mit Zustimmung der Redaktion erlaubt. IDG Communications AG, Redaktion Computerworld, Witikonerstrasse 15, CH‐8032 Zürich, SWITZERLAND Phone: +41 44 387 44 44, Fax: +41 44 387 45 80

×