Der Sarbanes-Oxley Act und seine Auswirkungen auf die Gestaltung von Informationssystemen

Transkript

1 Institut für Wirtschaftsinformatik der Universität Bern Arbeitsbericht Nr. 179 Der Sarbanes-Oxley Act und seine Auswirkungen auf die Gestaltung von Informationssystemen Gerhard Knolmayer, Thomas Wermelinger Januar 2006 Die Arbeitsberichte des Institutes für Wirtschaftsinformatik stellen Teilergebnisse aus laufenden Forschungsarbeiten dar; sie besitzen Charakter von Werkstattberichten, Preprints, u. Ä. und dienen der wissenschaftlichen Diskussion; Kritik zum Inhalt ist daher erwünscht und jederzeit willkommen. Alle Rechte liegen bei den Autoren. Institutsadresse: Engehaldenstrasse 8, 3012 Bern, Schweiz Tel.: ++41 (0) Fax: ++41 (0)

2 Inhaltsverzeichnis 1 PROBLEMSTELLUNG UND GANG DER UNTERSUCHUNG DER SARBANES-OXLEY ACT FORDERUNGEN AN DIE IT DURCH DEN SARBANES-OXLEY ACT VORNAHME VON KONTROLLEN Risiko-Management, Prozessgestaltung und Datenqualität Zielgerichtete Kontrollen durch Verwendung von Frameworks Die Frameworks COSO und COBIT Kontrollen bei Beschaffung, Entwicklung und Wartung der IT-Systeme Kontrollen des Betriebs der IT-Systeme ZEITNAHE OFFENLEGUNG DOKUMENTENAUFBEWAHRUNGSPFLICHT FOLGEN DES SARBANES-OXLEY ACT ZUSAMMENFASSUNG UND AUSBLICK LITERATUR... 17

3 - 1-1 Problemstellung und Gang der Untersuchung Gesamtwirtschaftlich und insbesondere aus Aktionärsperspektive unerfreuliche Entwicklungen haben dazu geführt, dass in den letzten Jahren die Corporate Governance zu einem Schwerpunktthema der Unternehmensführung wurde. Gesetzgeber, Aufsichtsbehörden und Fachgremien verschiedener Staaten versuchen, die Corporate Governance zu verbessern. In diesem Beitrag konzentrieren wir uns auf die Verschärfung der US-Gesetzgebung, die der Sarbanes-Oxley Act (SOA; häufig auch als SOX abgekürzt) 1 mit sich gebracht hat. Dieses Gesetz ändert und ergänzt bestehende Vorschriften mit dem Ziel, Aktionärsinteressen stärker als bisher zu schützen. Der SOA gilt für alle Unternehmen, deren Wertpapiere an einer der SEC unterstehenden Börse gehandelt werden. Er ist daher auch für Unternehmungen ausserhalb der USA relevant, wenn ihre Wertpapiere (auch) an einer US-Börse notiert sind oder sie wesentliche Tochtergesellschaften ("significant subsidiary") einer an amerikanischen Börsen gehandelten Gesellschaft sind. Dabei können Konflikte mit nationalen Rechtsordnungen auftreten. 2 Indirekt können die durch den SOA geforderten Vorgehensweisen auch darüber hinaus relevant werden, wenn z.b. Unternehmen mit an US-Börsen notierten Gesellschaften in starker Konkurrenz stehen und daher freiwillig am SOA orientierte Vorgehensweisen (strikt oder als "SOA light") umsetzen oder Gerichte Fragen nach "Best Practices" stellen und diese von Experten mit Verweis auf den SOA beantwortet werden. Seit Jahren steht die prozessorientierte Gestaltung von Unternehmen im Mittelpunkt betriebswirtschaftlichen Denkens. Geschäftsprozesse sollen in einer klar definierten Weise unter Berücksichtigung von Geschäftsregeln ("Business Rules") 3 ablaufen. Die Versorgung der Geschäftsprozesse mit den notwendigen Informationen hat zur Entwicklung komplexer Informationssysteme (IT-Systeme) geführt, die zu Nervenzentren der Unternehmen geworden sind. Die bei Ausführung der Geschäftsprozesse erzeugten und durch IT-Systeme verwalteten Daten bilden die Grundlage der Rechnungslegung. Daher besteht eine enge Verflechtung zwischen Geschäftsprozessen, den zugehörigen IT-Prozessen und der Rechnungslegung. Dies wird durch den SOA stärker als bisher berücksichtigt. Wegen der hohen Dynamik in der Entwicklung der IT ist es nicht einfach, die Qualität der im IT-Bereich erbrachten Leistungen zu beurteilen. Die Qualität der IT- Prozesse soll u.a. durch Beschreibung von "Best Practices" und Reifegradmodellen greifbar gemacht werden. Ein bekanntes Reifegradmodell ist das (mittlerweile in verschiedenen Varianten weiter entwickelte) Capability Maturity Model (CMM) des Software Engineering Instituts der Carnegie Mellon University, nach dem IT-Prozesse eines Unternehmens einer der Stufen 1 bis 5 (benannt als Initial, Repeatable, 1 Der Gesetzestext ist u.a. auf zu finden. Seine Bedeutung lässt sich daran ermessen, dass die Suchmaschine Google im November 2005 rund zugehörige Seiten fand. 2 Vgl. Sarbanes Oxley Group (2004), S. 99 f. 3 Vgl. etwa Knolmayer / Herbst (1993); Herbst / Knolmayer (1995); Klaus (2005).

4 - 2 - Defined, Managed und Optimizing) zugeordnet werden. 4 Weniger als 10% der beurteilten Unternehmen erreichen die Stufen 4 oder 5. 5 Viele IT-Prozesse laufen also offenbar nicht perfekt ab. Später wurden Reifegradmodelle z.b. auch generell im Hinblick auf die prozessorientierte Gestaltung von Unternehmen formuliert. 6 Der SOA verlangt, dass ein Unternehmen seiner Prüfungsgesellschaft darlegt, durch welche Kontrollen die Qualität der Rechungslegung gewährleistet wird. Dazu muss sich das interne Kontrollsystem (IKS) an einem geeigneten "Framework" orientieren. Mehrere Frameworks befassen sich mit der Sicherstellung der Qualität der Rechnungslegung und dem Management der Informationssysteme. Letztere Gesichtspunkte kommen in der Diskussion um die Qualität der Rechnungslegung und Überwachung zu kurz 7 und bilden daher den Schwerpunkt der folgenden Ausführungen. In seiner Darstellung der Systemprüfung hat Rückle Elemente einer Prüfung, welche heute durch den SOA gesetzlich gefordert sind, bereits 1978 beschrieben. 8 Durch Regelungen wie jene des SOA erhält die "EDV-Revision" einen deutlich höheren Stellenwert als bisher. 9 Abschnitt 2 gibt einen knappen Überblick über die für diesen Beitrag relevanten Vorschriften des SOA. In Abschnitt 3 werden zunächst die den Regulierungen zugrunde liegenden Problemkreise analysiert und anschliessend zwei im SOA-Umfeld zentrale Frameworks skizziert. Abschnitt 4 befasst sich mit wirtschaftlichen Konsequenzen des SOA. Abschliessend wird erörtert, ob der SOA als Grundlage international einheitlicher Standards dienen sollte. 4 Carnegie Mellon Software Engineering Institute (2005). 5 Vgl. SAIC (2003). 6 Vgl. etwa Rosemann / de Bruin (2005) und die dort angeführte Literatur. 7 So lässt der Arbeitskreis 'Externe und Interne Überwachung der Unternehmung' der Schmalenbach- Gesellschaft für Betriebswirtschaft (2004) derartige Aspekte unberücksichtigt. Vgl. auch Cunningham (2005): "So far, the early stages of SOX have only impacted financial analysts, auditors and accountants in companies, the paradigm is shifting to IT departments and will serve as a cornerstone to making SOX compliance a reality" sowie die Sarbanes Oxley Group (2004), S. 20: Sarbanes-Oxley will require radical changes to the manner and speed of information flow within the corporation: IT and its value position will change forever. 8 Vgl. Rückle (1978), S Vgl. auch Protiviti (2005), S. 8.

5 Der Sarbanes-Oxley Act Nach grossen Unternehmenszusammenbrüchen, bei denen die veröffentlichten und testierten Jahresabschlüsse die wirtschaftliche Situation dieser Unternehmen (sehr vorsichtig formuliert) wenig präzise abbildeten, 10 verloren viele Kapitalanleger ihr Vertrauen in die Rechnungslegung. Daher wurden die US-amerikanischen Rechnungslegungsvorschriften in einem von Paul Sarbanes und Michael G. Oxley initiierten Gesetzestext für in den USA börsennotierte Gesellschaften im Jahr 2002 teilweise massiv verschärft. Auf dieser Basis hat die Securities and Exchange Commission (SEC) eine Reihe von Durchführungsverordnungen erlassen. 11 Der SOA fordert die Gründung eines Aufsichtsgremiums über Prüfungsgesellschaften, was zur Gründung des Public Company Accounting Oversight Boards (PCAOB) 12 geführt hat. Prüfungsgesellschaften werden in regelmässigen Abständen durch das PCAOB geprüft. Dies soll eine Antwort auf die oft aufgeworfene Frage "Wer prüft die Prüfer" geben. Eine Prüfungsgesellschaft darf einem von ihr geprüften Unternehmen nicht uneingeschränkt andere Dienstleistungen anbieten. Unter anderem ist eine Mitwirkung bei Entwurf und Implementierung von Informationssystemen verboten. 13 Der SOA verpflichtet Unternehmen offen zu legen, mit welchen Prozessen die Jahresrechnung erstellt wird und wie zuverlässig diese arbeiten. Es soll sichergestellt werden, dass die Geschäftsprozesse regelkonform abgewickelt und korrekt im Rechnungswesen abgebildet werden. Die Prozesse sollen so gestaltet werden, dass Fehler bei der Rechnungslegung erkannt werden. Hierfür sind Kontrollen zu definieren, auf ihre Wirksamkeit zu testen und zu dokumentieren. Durch den SOA werden somit interne Kontrollsysteme (IKS) aufgewertet. Section 302 des SOA verlangt vom CEO und CFO, die Wahrheit und Vollständigkeit der veröffentlichten Geschäftsberichte zu bestätigen. Damit sie dies gewährleisten können, sollen ein "Disclosure Committee" eingerichtet und "Disclosure Controls and Procedures" implementiert werden, welche dem Management für die Rechnungslegung relevante Informationen umgehend zugänglich machen. Der Informationsfluss für die Rechnungslegung muss klar definiert und die Zuverlässigkeit des Systems durch Kontrollen sichergestellt und getestet werden. 14 Section 404 des SOA verlangt, dass Unternehmen Rechnungslegungskontrollen (Internal control over financial reporting) implementieren. Ihr Vorhandensein muss bei Veröffentlichung des Jahresabschlusses vom Management bestätigt werden. Über Unregelmässigkeiten oder Schwachstellen in der Berichterstattung sind sowohl der Prüfungsausschuss als auch die Prüfungsgesellschaft zu informieren. Die Prüfungsgesellschaft hat Stellung zu nehmen, ob der Bericht des Managements zur Qualität der Kontrollen der Realität entspricht. 10 Die zuweilen unscharfen Grenzen zwischen Bilanzkosmetik und Betrug werden unter dem Begriff Earnings Management erörtert; vgl. z.b. Lev (2003). 11 Vgl. etwa Warncke (2005), S PCAOB (2005). 13 Vgl. etwa von der Crone / Roth (2003), S. 136; Hunton / Bryant / Bagranoff (2004), S Vgl. Spitters (2004).

6 - 4-4 Von den 276 material weaknesses, die der SEC bis April 2005 gemeldet wurden, wären viele durch geeigneten IT-Einsatz vermeidbar gewesen. 15 Unter anderem werden die in Standardsoftware-Systemen vorgesehenen, aber nicht notwendigerweise aktivierten Kontrollen zu wenig genutzt. 16 Realistischerweise kann keine völlige Fehlerfreiheit von Informationssystemen und damit auch der Rechnungslegung erwartet werden; Unternehmen sollten aber Massnahmen zur kontinuierlichen Qualitätsverbesserung implementieren. 17 Zudem wird auch bezüglich der Erfüllung der Anforderungen des SOA eine Abstufung in mehrere Reifegrade vorgeschlagen Bace / Rozwell / Caldwell (2005). 16 Vgl. etwa Monn (2005), S Vgl. Lahti / Peterson (2005), S Vgl. Butler / Richardson (2005), S. 20.

7 - 5-3 Forderungen an die IT durch den Sarbanes-Oxley Act 3.1 Vornahme von Kontrollen Risiko-Management, Prozessgestaltung und Datenqualität Durch ein systematisch ausgerichtetes IKS sollen die für ein Unternehmen bestehenden Risiken reduziert werden. Als Beispiel eines Gefahrenpotenzials für die Rechnungslegung beschreibt das PCAOB folgenden Sachverhalt: 19 "The company has a standard sales contract, but sales personnel frequently modify the terms of the contract. Sales personnel frequently grant unauthorized and unrecorded sales discounts to customers without the knowledge of the accounting department. These amounts are deducted by customers in paying their invoices and are recorded as outstanding balances on the accounts receivable aging. Although these amounts are individually insignificant, they are material in the aggregate and have occurred consistently over the past few years." Zur Sicherstellung der Qualität der relevanten Daten 20 müssen zunächst jene Geschäftsfälle bestimmt werden, die signifikanten Einfluss auf das Ergebnis der Rechnungslegung besitzen. Danach sind Kontrollen zu definieren und durchzuführen, welche eine zeitnahe und korrekte Abbildung dieser Geschäftsvorfälle in der Rechnungslegung sicherstellen. So muss das IKS z.b. für den oben beschriebenen Sachverhalt Kontrollen bereitstellen, welche die Vertragsdetails der Verkäufe mit den eingegangenen Zahlungen vergleichen. Um zielgerichtete Kontrollen einzurichten, müssen die zugrunde liegenden Geschäftsprozesse bekannt sein und reproduzierbar ausgeführt werden. Daher ist es sinnvoll, "end-to-end-geschäftsprozesse" zu definieren, diese in einzelne Prozessschritte zu unterteilen und entsprechende Verantwortlichkeiten eindeutig zuzuordnen. Aus Prozessbeschreibungen müssen beispielsweise folgende für die Prozessdurchführung relevante Eigenschaften ersichtlich sein: 21 Wer initiiert einen Geschäftsfall auf welche Weise? Wie, wann und wer autorisiert einen Geschäftsfall? Wie wird der Datensatz zum Geschäftsfall erstellt und verwendet? Prozessbeschreibungen geben jedoch zuweilen nicht den Ist-Zustand wieder, sondern beschreiben eher Soll-Vorstellungen. Kontrollen bei einzelnen Prozessschritten können nur dann erfolgen, wenn die Prozessbeschreibungen die Ist-Abläufe korrekt wiedergeben. Auf Abweichungen zwischen Prozessdokumenten und Ist-Prozessen werden Prüfungsgesellschaften hinweisen. 19 PCAOB (2004), S Zu Früherkennung, Ursachen, Prüfungen und möglichen Abhilfen bei schlechter Datenqualität vgl. etwa Strong / Lee / Whang (1997); Krishnan et al. (2005). 21 Vgl. PCAOB (2004), S. 158; KPMG (2004), S. 4.

8 - 6 - Erste Erfahrungen mit dem SOA zeigen, dass eine sehr grosse Zahl von Kontrollen erforderlich ist und deren Dokumentation und Verbesserung erheblichen Aufwand verursacht. 22 Durchschnittlich haben die Unternehmen Arbeitsstunden aufgewendet, um die SOA-Nachweise zu erfüllen. 23 Zuweilen wurden umfangreiche Selbst-Zertifikationen vorgenommen; so liess etwa die UBS AG im 1. Quartal 2005 von rund Mitarbeitenden mehr als Fragen beantworten Zielgerichtete Kontrollen durch Verwendung von Frameworks Das IT Governance Institute beschreibt Unternehmen durch Geschäftsprozesse, das IT-System und das Management; 25 jedes dieser Elemente könne die Rechnungslegung des Unternehmens gefährden. Im Folgenden werden diese Elemente kurz beschrieben und mögliche Gefahren und Kontrollen aufgezeigt. Geschäftsprozesse sind mit den für ihren Ablauf notwendigen Informationen zu versorgen und die bei ihrer Ausführung erzeugten Daten müssen nachfolgenden Prozessen zur Verfügung stehen. Unterschiedliche Kontrollen sollen die Qualität der bereitgestellten und verarbeiteten Informationen gewährleisten. Sie können beispielsweise sicherstellen, dass Geschäftsfälle nur durch autorisierte Mitarbeitende durchgeführt werden, das Vieraugenprinzip eingehalten wird, in Eingabemasken bestimme Datenfelder zwingend ausgefüllt werden, die Konsistenz und Aktualität der Daten überprüft wird und Buchungen nur in der laufenden Periode möglich sind. Bei der erstmaligen Durchführung SOA-basierter Prüfungen wurden viele Kontrollschritte manuell oder mit Hilfe von Endbenutzerwerkzeugen (insbes. Spreadsheets) durchgeführt. 26 Mit diesem Vorgehen entstehen jedoch zusätzliche Gefahren. 27 Daher und wegen der damit verbundenen Kosten ist eine Automatisierung vieler Kontrollschritte anzustreben. 28 Generell sollten SOA-Nachweise nicht als Projekt, sondern als Prozess organisiert werden. 29 IT-Systeme speichern die Buchungen zu den Geschäftsfällen und fassen diese zur Jahresrechnung zusammen. Somit sind klar definierte und umgesetzte IT-Prozesse für die Sicherstellung der Qualität der Rechnungslegung relevant. Der Einsatz von Software, welche die Geschäftsprozesse unterstützt, benötigt zentrale Dienstleistungen einer IT-Abteilung und/oder (bei Outsourcing) eines Dienstleisters. Diese sollen für einen sicheren Betrieb der IT-Infrastruktur sorgen. Die Einhaltung der 22 In einem von der SEC organisierten Roundtable-Gespräch wurde für ein Unternehmen die Existenz von internen Kontrollschritten genannt. Ein anderes Unternehmen berichtet, Prozesskontrollen und allgemeine IT-Kontrollen dokumentiert und dafür Arbeitsstunden aufgewendet zu haben. Eine Prüfungsgesellschaft habe bei 225 Klienten rund unbefriedigende Kontrollschritte festgestellt. Vgl. SEC (2005). 23 SEC (2005). 24 Friesenecker (2005), Folie Vgl. zum Folgenden ITGI (2004), S Vgl. Siebel (2005), S Vgl. etwa Kugel (2005); "Managing Spreadsheets in the light of Sarbanes-Oxley" war Gegenstand der Jahreskonferenz der European Spreadsheet Risks Interest Group EuSpRIG (2005). 28 Vgl. CFO Research Services (2005); Tims (2005); Worthen (2005). 29 Vgl. etwa Hoffman (2003); Wakem (2005).

9 - 7 - hierfür erforderlichen Massnahmen soll durch Kontrollen in den Prozessen der Softwareentwicklung und -wartung sowie beim laufenden Betrieb der Systeme sichergestellt werden. Gefahren können unter anderem darin bestehen, dass Daten durch Unbefugte verändert werden, Programme die Daten nicht korrekt verarbeiten, gespeicherte Daten durch Verlust gefährdet sind oder die benötigte IT-Infrastruktur nicht mit ausreichend sicher betrieben wird. Das Management richtet die Geschäftsprozesse nach strategischen Gesichtspunkten aus und erlässt Richtlinien, welche Kontrollen ermöglichen und zielorientiert gestalten. Diese müssen anschliessend implementiert werden, was ausreichende Ressourcen erfordert. Kostensenkungsprogramme und Personalfluktuationen können dazu führen, dass in bestimmten Prozessen vorgesehene Kontrollschritte (z.b. Vieraugenprinzip) zumindest vorübergehend nicht eingehalten werden, oder das Unternehmen zumindest temporär nicht über das für die Durchführung der Kontrollen notwendige Wissen verfügt. Auf der skizzierten Struktur basieren Frameworks, durch deren Verwendung die Kontrollprozesse so ausgerichtet werden sollen, dass Gefahren für die Rechnungslegung eliminiert oder wenigstens gemindert werden. Der SOA verlangt, dass sich das IKS nach einem passenden, von Experten anerkannten "Control Framework" richten müsse. Dafür kommen mehrere Frameworks in Betracht. 30 Da in den USA das vom Committee of Sponsoring Organizations of the Threadway Commission (COSO) 1992 veröffentlichte Framework besonders bekannt ist, verwendet das PCAOB Definitionen von COSO. Zwar verlangen der SOA und das PCAOB nicht, dass COSO zur Erfüllung der Vorschriften der Section 404 herangezogen werden muss; 31 angesichts der bei vielen Unternehmen und ihren Prüfungsgesellschaften bestehenden Unsicherheiten scheint sich aber das (in Mitteleuropa zuvor wenig beachtete) COSO-Framework als Quasi-Standard zu etablieren. Trotz der Verweise auf Frameworks bleibt ein weiter Ermessensspielraum hinsichtlich SOA-kompatibler Vorgehensweisen. Die dem SOA unterliegenden Unternehmen müssen sich der Akzeptanz bestimmter Vorgehensweisen durch ihre Prüfer schon vor Erstellung des Jahresabschlusses sicher sein. Prüfungsgesellschaften sollen (auch vor dem Hintergrund der Unsicherheit der bei ihnen von der PCAOB angelegten Prüfkriterien) rigide Anforderungen erhoben haben. 32 Zudem wäre es verwunderlich, wenn sie nicht versuchten, möglichst umfassende und prüfungsintensive Prozeduren durchzusetzen und im Gegenzug ihre Auftraggeber solche Maximalforderungen als unnötig abwenden wollten. In der Tat führen die neuen Regelungen zu erhöhten Stundensätzen der Prüfungsgesellschaften und deutlich vergrösserten Arbeitsvolumina Vgl. z.b. Hunton / Bryant / Bagranoff (2004), S. 55 f; Warncke (2005), S Vgl. PCAOB (2004), S In diesem Zusammenhang wird ein lack of balance beklagt; vgl. SEC (2005). 33 Vgl. etwa Schmitz (2005), Teil 2 und 3; Tucci (2005).

10 Die Frameworks COSO und COBIT COSO soll Vergleiche zwischen dem existierenden IKS eines Unternehmens und einem Standard ermöglichen. 34 Das Framework unterscheidet fünf Aktivitätsbereiche: 35 Control Environment (CE) Dieser Bereich bildet die Grundlage für die vier anderen Bereiche und beschäftigt sich mit Fragen der Integrität, Ethik und fachlicher Kompetenz. Geprüft werden u.a. der Führungsstil, die Unternehmenskultur, die Überwachungstätigkeit der Aufsichtsgremien, die Organisationsstruktur, die Zuordnung von Aufgaben, Kompetenzen und Verantwortung oder auch die Grundsätze der Personalpolitik. Risk Assessment (RA) Das IKS soll sicherzustellen, dass Ziele definiert und Risiken erkannt werden. Daher müssen die für die Erreichung der Ziele bestehenden Risiken identifiziert, ihre Eintrittswahrscheinlichkeiten bestimmt und das mit den Risiken verbundene Schadenspotenzial quantifiziert werden. Control Activities (CA) Control Activities setzen Strategien zur Risikovermeidung entweder durch Mitarbeitende oder durch IT-Systeme in Kontrollen um. Information and Communication (IC) Zur Durchführung von Kontrollen werden die dafür benötigten Informationen zur richtigen Zeit an der richtigen Stelle benötigt. Dieser Bereich von COSO soll sicherstellen, dass die definierten Kontrollprozesse mit den erforderlichen Daten versorgt werden. Mitarbeitende sollen die Möglichkeit besitzen, sich bei Versagen der Berichtswege direkt an das Management oder die Aufsichtsgremien zu wenden. Monitoring (M) Die definierten Kontrollen müssen in regelmässigen Abständen auf ihre Wirksamkeit und Zielgerichtetheit überprüft werden. Sie können z.b. durch Änderungen der Umweltbedingungen ihre Wirksamkeit verlieren oder bestimmte Gefahren können nicht mehr relevant sein. Veränderte Rahmenbedingungen können Anpassungen im IKS erfordern. Auch andere Prüfungsstandards (z.b. jener der International Federation of Accountants) orientieren sich am COSO-Modell. 36 COSO betont zwar die Wichtigkeit der IT-Prozesse, ist aber auf einen Umgang mit allgemeinen Risiken ausgerichtet. Um konkrete Anforderungen an IT-Prozesse besser berücksichtigen zu können, benötigt die IT-Abteilung spezifischere Ausführungen. Im Umfeld des SOA wird hierfür insbesondere auf das bereits 1994 veröffentlichte IT-Framework COBIT (Control Objectives for Information and Related Technology) 37 verwiesen; Ende 2005 wurde COBIT-Version 4.0 freigegeben Vgl. Butler / Richardson (2005), S Vgl. zum Folgenden Ramos (2004), S ; Menzies (2005), S In COSO (2004) wird eine etwas erweiterte Systematik verwendet, die z.b. auch eine "Event Identification" umfasst. 36 Menzies (2004), S Vgl. etwa ITGI (2004), S ISACA (2005).

11 - 9 - In COBIT werden 34 kritische Prozesse für die Erstellung und den Betrieb der IT- Systeme sowie die dafür notwendigen Ressourcen definiert. Tabelle 1 zeigt, wie das Information Technology Governance Institute (ITGI) 39 diese 34 IT-Prozesse den 5 Bereichen von COSO zuordnet. 40 Einige IT-Prozesse sind keinen COSO-Bereichen zugeordnet, werden aber der Vollständigkeit halber in der Tabelle aufgeführt. COSO Component COBIT Area CE RA CA IC M Plan and Organize (IT Environment) IT strategic planning X X X X Information architecture X X Determine technological direction IT organization and relationships X X Manage the IT investment Communication of management aims and direction X X X Management of human resources X X Compliance with external requirements X X Assessment of risks X Manage projects Management of quality X X X X Acquire and Implement (Program Development and Program Change) Identify automated solutions Acquire or develop application software X Acquire technology infrastructure X Develop and maintain policies and procedures X X Install and test application software technology infrastructure X Manage changes X X Deliver and Support (Computer Operations and Access to Programs and Data) Define and manage service levels X X X Manage third-party services X X X X Manage performance and capacity X X Ensure continuous service Ensure systems security X X X Identify and allocate costs Educate and train users X X Assist and advise customers Manage the configuration X X Manage problems and incidents X X X Manage data X X Manage facilities X Manage operations X X Monitor and Evaluate (IT Environment) Monitoring X X Adequacy of internal controls X Independent assurance X X Internal audit X Tabelle 1: Beziehungen zwischen COSO und COBIT 39 ITGI (2004), S In der Literatur finden sich auch davon abweichende Zuordnungen, vgl. etwa Butler / Richardson (2005), S. 8.

12 COBIT stellt eine Vielzahl konkreter Fragen bereit, welche die Beurteilung der Kontrollen über IT-Systeme unterstützen sollen. Beispielsweise sollen für "IT Organization and Relationships" folgende Fragen geprüft werden: 41 Do IT managers have adequate knowledge and experience to fulfill their responsibilities? Have key systems and data been inventoried and their owners identified? Are roles and responsibilities of the IT organization defined, documented and understood? Do IT personnel have sufficient authority to exercise the role and responsibility assigned to them? Do IT staff understand and accept their responsibility regarding internal control? Have data integrity ownership and responsibilities been communicated to appropriate data/business owners and have they accepted these responsibilities? Is the IT organizational structure sufficient to provide for necessary information flow to manage its activities? Has IT management implemented a division of roles and responsibilities (segregation of duties) that reasonably prevents a single individual from subverting a critical process? Are IT staff evaluations performed regularly (e.g., to ensure that the IT function has a sufficient number of competent IT staff necessary to achieve objectives)? Are contracted staff and other contract personnel subject to policies and procedures created to control their activities by the IT function, and to assure the protection of the organization s information assets? Are significant IT events or failures, e.g., security breaches, major system failures or regulatory failures, reported to senior management or the board? COBIT ist ein Rahmenwerk, das in seiner Breite und Tiefe kaum vollständig umgesetzt werden kann. 42 Die Unternehmen werden daher die auszuführenden Kontrollen im Hinblick auf ihre individuelle Situation und in Absprache mit den Prüfungsgesellschaften filtern müssen. 43 Unangemessen ist es, wenn Prüfungsgesellschaften aus den COBIT-Materialien Checklisten ableiten und die Erfüllung aller Anforderungen verlangen Kontrollen bei Beschaffung, Entwicklung und Wartung der IT-Systeme Änderungen einzelner Elemente des IT-Systems können die Zuverlässigkeit des Gesamtsystems gefährden. Beschaffung, Entwicklung und Unterhalt der IT-Systeme sollten daher nach klar definierten Prozessen mit präzise definierten Zuständigkeiten erfolgen. Die IT-Abteilung muss vor Einführung neuer oder veränderter Systeme durch systematische Tests ihre Zuverlässigkeit sicherstellen. Problematisch sind insbesondere Schnittstellen zwischen einzelnen Applikationen. Während in vielen Unternehmen Applikationsverantwortliche definiert sind, werden Schnittstellen-Verantwortliche viel seltener benannt. Insgesamt wächst durch den SOA die Bedeutung 41 ITGI (2004), S. 51 f. 42 Vgl. auch ISACA (2001), Vorwort. 43 Lathi / Peterson (2005), S Vgl. SEC (2005).

13 systematischen und wiederkehrenden Testens; die Automatisierung und Nachvollziehbarkeit der Testprozesse gewinnt an Bedeutung Kontrollen des Betriebs der IT-Systeme Zuverlässigkeit und Sicherheit sind wichtige Ziele beim Betrieb von IT-Systemen. Zu ihrer Erreichung bieten Richtlinien und Standards (wie etwa das IT Grundschutzhandbuch des BSI oder BS ISO/IEC 17799:2005) 46 Hilfestellung. Für das Management des Betriebs von IT-Systemen ist zu berücksichtigen, dass sich in Europa mit ITIL 47 ein im SOA-Umfeld wenig beachtetes Modell weitgehend durchgesetzt hat. Unternehmen sollten Mitarbeitenden nur jene Rechte zuteilen, die für die Erfüllung ihrer Aufgaben nötig sind. Diese Informationen muss die IT-Abteilung durch ein Berechtigungsmanagement in den IT-Systemen abbilden. Ein klar definierter Prozess für Sperre und Löschung nicht mehr benötigter Benutzerkonten ist erforderlich. Sicherheit steht vielfach im Konflikt mit Benutzerfreundlichkeit: Eine restriktive Vergabe von Benutzerrechten kann eine flexible Arbeit der Mitarbeitenden behindern, wenn ausnahmsweise in der Stellenbeschreibung nicht vorgesehene Arbeiten durchzuführen sind. Sollten die IT-Systeme nicht wie gefordert arbeiten, muss die Fähigkeit vorhanden sein, Fehlermeldungen und Log-Daten zeitnah zu analysieren. Dies erfordert, dass Prozesse definiert sind, mit welchen die teilweise extrem grossen Datenmengen gezielt zur Fehlersuche ausgewertet werden können. 48 Um den physischen Schutz der IT-Systeme sicherzustellen, müssen diese in geeigneten Räumen beispielsweise vor unautorisierten Manipulationen, Feuer, Wasser oder Stromausfällen geschützt werden. 3.2 Zeitnahe Offenlegung Section 409 des SOA verlangt, dass Unternehmen relevante Informationen über ihre Finanzlage zeitnah an die interessierte Öffentlichkeit weiterleiten. Zunächst forderte die SEC, dass Unternehmen über bestimmte Ereignisse 49 rascher als bisher informieren müssen. Weitere Regelungen werden vermutlich folgen. Damit den Informationspflichten entsprochen werden kann, müssen Informationen zeitgerecht gewonnen, beurteilt und gegebenenfalls veröffentlicht werden. Ein erster Schritt dazu ist, dass das Management selbst diese Informationen besitzt. Daher ist es erforderlich, Signale über relevante Änderungen der Unternehmenssituation frühzeitig wahrzunehmen. Anzustreben wäre, dass IT-Systeme die von der SEC definierten Ereignisse automatisch erkennen und an die zur Beurteilung zuständigen Stellen weiterleiten. 45 Vgl. etwa Hunton / Bryant / Bagranoff (2004), S. 82; Ramos (2004), S Bundesamt für Sicherheit in der Informationstechnik (2004); British Standards Online (2005). 47 Vgl. etwa Köhler (2005) und die über das Office of Government Commerce (2005) beschaffbaren Originaldokumente. 48 Vgl. ITGI (2004), S SEC (2004).

14 Auch andere Ereignisse können die finanzielle Situation und damit den Aktienkurs beeinflussen. 50 Die (Wirtschafts-)Informatik hat mit Data Mining und Text Mining 51 Methoden entwickelt, um aus grossen Datenmengen automatisch zusätzliche, nicht offensichtliche Informationen zu gewinnen. Dadurch lassen sich möglicherweise Sachverhalte erkennen, die offenlegungspflichtig sind. Derartige Verfahren der künstlichen Intelligenz sind heute bei fortschrittlichen IT-Anwendern in Erprobung. Es erscheint denkbar, dass von den Unternehmen zukünftig gefordert wird, solche fortgeschrittenen Methoden der Informationsgewinnung einzusetzen. Die Informationen müssen von den Verantwortlichen auf ihre Relevanz für die Öffentlichkeit beurteilt werden. Die Frage, welcher Zeitraum für diese Beurteilung angemessen ist, stellt sich vor allem dann, wenn eine längere Prüfung von schwachen Signalen zu besseren Prognosewahrscheinlichkeiten führen kann. Der SOA verlangt die Offenlegung von material events innerhalb von 2 Tagen. Gegebenenfalls muss ein Unternehmen in der Lage sein, als relevant beurteilte Informationen in geeigneter Weise zu kommunizieren. Verschiedene Dienstleister (in den USA vor allem Businesswire und Newswire, in Grossbritannien der Regulatory News Service) unterstützen die Unternehmen bei der Weiterleitung solcher Informationen insbesondere über das Internet. Die Forderung nach einer schnellen und zeitnahen Offenlegung kann auch so verstanden werden, dass die bereit gestellten Informationen schneller verarbeitbar und vergleichbar sind. Eine Möglichkeit dazu bietet die auf XML basierende extensible Business Reporting Language XBRL Dokumentenaufbewahrungspflicht Der SOA verlangt, dass die für die Geschäftstätigkeit relevanten Daten (unterschiedlich lange) aufbewahrt werden. 53 Dazu gehören auch s 54 und (nach Ansicht einiger Fachvertreter) sogar Instant-Messenger-Nachrichten 55. Durch die gespeicherten Daten soll nachvollziehbar sein, welche Mitarbeiter zu welchem Zeitpunkt über welche Informationen verfügten. Derartige Anforderungen sind in Verbindung mit "Prüfungen höherer Ordnung" bereits früh erörtert worden. 56 Zuweilen wird die Meinung vertreten, Daten sollten (deutlich) länger als gesetzlich gefordert gespeichert werden. 57 Ein Schaden durch Nichtverfügbarkeit von Daten könne grösser sein als die Kosten für eine permanente (elektronische) Speicherung. Neben der Aufbewahrung von Daten muss aber auch sichergestellt sein, dass im Bedarfsfall rasch auf diese Daten zugegriffen werden kann. 50 Vgl. etwa Cunningham (2005). 51 Vgl. etwa Sullivan (2001). 52 Vgl. etwa Nutz / Strauß (2002); Moeller (2004), S ; Stone (2005). 53 Vgl. Miller / Pashkoff (2002). 54 Vgl etwa Iosub (2003); Weiss (2005). Unterschiedliche Aufbewahrungspolitiken diskutiert Goulet (2005). 55 Vgl. etwa Shapiro (2004); NN (2005); Williams (2005). 56 Vgl. etwa Loitlsberger (1966), S. 29; Knolmayer (1981), S So z.b. Sanchez (2005).

15 Um die Forderungen des SOA zur Datenspeicherung zu erfüllen, müssen Regeln zum Umgang mit Dokumenten geschaffen werden: Der permanente Zugriff auf Daten muss sichergestellt sein. Dabei ist zu bedenken, dass durch die Hardwareentwicklung früher verwendete Datenträger möglicherweise nicht mehr lesbar sind. 58 Daten müssen so abgelegt werden, dass sie zeitnah auffindbar sind. Zahlreiche Hersteller bieten Dokumenten-Management-Systeme an. Fortgeschrittene Techniken zum Information Retrieval vereinfachen das Wiederauffinden von Daten. s stellen heute ein zentrales Kommunikationsmedium zwischen den Mitarbeitenden und mit Externen dar. Daher sind folgende Fragen zu klären: Welche Daten dürfen überhaupt per versandt werden? In welchen Fällen sind die Nachrichten verschlüsselt zu übertragen? Sind gegebenenfalls die verschlüsselten oder die entschlüsselten Daten zu speichern? Sollen die s in den Archivierungssystemen verschlüsselt werden, um unberechtigten Zugriff zu erschweren? 59 Werden alle s archiviert? Falls dies nicht zutrifft: Wie können die für die Rechnungslegung relevanten Mails mit hinreichender Genauigkeit von der grossen Zahl anderer Mails gefiltert werden? Sind auch die (teilweise umfangreichen) Attachments zu speichern? Genügt es, nur die eigentliche Nachricht zu speichern oder müssen auch die Daten des Mail-Headers gespeichert werden, aus denen z.b. der sendende Computer ersichtlich wird? Für die effiziente Archivierung von s werden spezialisierte Archivierungssysteme angeboten. Eine Produktbeschreibung formuliert: "Essential for compliance and legal admissibility, the system automatically audits and actions taken with files, including document storage in archive, document access and recovery, categorisation, policy creation or modification, document destruction and any change to access rights. The audit trail provides demonstratable integrity; by tracking every action and providing 'after the fact' forensics capability, even auditors are audited." 60 Zur Unterstützung allfälliger interner oder externer Untersuchungen muss das Unternehmen auf computerforensisches Wissen 61 zugreifen können, um verdächtige Vorgänge durch Erfassung, Analyse und Auswertung digitaler Spuren in IT-Systemen untersuchen zu können. 58 Vgl. etwa Chan / Lepeak (2004). 59 Vgl. etwa Tebo (2005). 60 Fortuna Power Systems (2005). 61 Vgl. etwa Vacca (2002).

16 Folgen des Sarbanes-Oxley Act Die zur Erfüllung des SOA durchzuführenden Massnahmen erhöhen die Kosten. 62 Für 2006 werden die durch den SOA ausgelösten Kosten (ohne die zusätzlichen Kosten der Wirtschaftsprüfung) auf über 6 Milliarden USD geschätzt. 63 Manche Unternehmen verzichten wegen der hohen Kosten, die mit der Erfüllung der Vorschriften verbunden sind, auf eine Börsennotierung; einige erwägen, ihre Aktien vom Handel zurückzuziehen. 64 Damit wird der Zugang zum Kapitalmarkt erschwert und für Investoren wird es schwieriger, Aktien zu handeln. Auch Mergers & Acquisitions werden durch den zusätzlich notwendigen Koordinationsbedarf bei den internen Kontrollsystemen erschwert. 65 Die vom SOA vorgesehenen Kontrollen dürften zukünftig in stärkerem Masse als bei der erstmaligen Erfüllung der Vorschriften automatisiert werden. Spezielle Tools sollen den Nachweis der SOA-Compliance unterstützen. 66 Bei Entwicklung von neuen IT-Systemen wird vermehrt eine flexible Prozessunterstützung durch IT-Systeme an die sich rasch ändernden Organisationsabläufe erforderlich. Dies kann dazu führen, dass IT-Systeme in stärkerem Ausmass regelbasiert entwickelt werden und Werkzeuge wie "Rules Engines" 67 an Bedeutung gewinnen. Somit wird die Informationstechnologie als Folge von SOA weiter an Bedeutung und Komplexität gewinnen. Die durch den SOA geforderte erhöhte Datenqualität kann zu einer Zentralisierung bisher dezentral gelöster Aufgaben führen. Beispielsweise kann die Berechtigung für Änderungen in Lieferantenstammsätzen als Konsequenz kontrollsicherer Prozesse auf wenige Mitarbeitende konzentriert werden.68 Durch diesen Schritt können sich Verzögerungen in den Arbeitsabläufen ergeben, weil die Mitarbeitenden auf die Anlage oder Anpassung der Datensätze durch eine Zentralinstanz warten müssen. Die erhöhten Anforderungen an die Zuverlässigkeit der IT-Systeme können für Unternehmen, die dem SOA unterstehen, einen Anreiz darstellen, ihre IT-Systeme an spezialisierte und mit dem SOA erfahrene Dienstleister auszulagern. 69 Unter den nach dem CMM mit Bestnote 5 beurteilten Dienstleistern befinden sich überproportional viele indische Unternehmen. 70 Der SOA kann somit zu verstärktem Offshoring führen. 71 Handkehrum können Probleme mit Nachweisen der SOA-Anforderungen an ausländischen Standorten ein Backsourcing von IT-Systemen 72 bewirken. 62 Vgl. z.b. Jones (2003); Ostler (2005). 63 Hagerty / Scott (2005). 64 Vgl. z.b. Jones (2003); Sarbanes Oxley Group (2004), S. 99; Wayman (2005). 65 Vgl. Kvida (2005). 66 Zu einer Bewertung des Einsatzes von Tools zur Gewährleistung der SOA-Compliance vgl. Ramos (2004), S Mehr als 100 einschlägige Software-Werkzeuge beschreiben Brooks / Goldman / Lanza (2005). 67 Vgl. für eine Übersicht etwa Owen (2004); Sinur (2005). 68 Vgl. Zaugg (2004), Folie Vgl. Sarbanes Oxley Group (2004), S. 98 f. 70 Vgl. Deutsche Bank Research (2005), S. 6: Von 80 Software-Unternehmen, die 2003 weltweit mit CMM Level 5 bewertet wurden, stammten 60 aus Indien. 71 Hoch (2005). 72 Vgl. etwa Kaplan (2005).

17 Der CEO von Sun Microsystems wird mit der Aussage zitiert, der SOA führe auf ein disaster, mit dem buckets of sand into the gears of the market economy geworfen würden. 73 Sicherlich können zusätzliche Kontrollaktivitäten organisatorische Schwachstellen unterschiedlicher Bedeutung aufzeigen. Durch Beseitigung mancher so diagnostizierter Schwachstellen können Vorteile z.b. im Risikomanagement, im Wissensmanagement, in der Wettbewerbsfähigkeit und bei den Finanzergebnissen resultieren. 74 Dieses Argument kann allerdings für viele unternehmerische Tätigkeiten belastende Auflagen vorgebracht werden: Das im Alltagsgeschäft übermässig beanspruchte Unternehmen brauche den Anstoss von aussen, um bestehende Rationalisierungschancen aufzugreifen. Mit der Theorie rationalen Handelns ist diese Sichtweise unvereinbar, weil danach Unternehmen betriebswirtschaftlich vorteilhafte Änderungen ihrer Geschäfts- und IT-Prozesse (und damit auch ihrer Kontroll- und Berichtsprozesse) von sich aus aufgreifen sollten. Vorstellbar ist auch, dass wirtschaftlich nötige Anpassungen nicht vollzogen werden können, da der SOA finanzielle Mittel und Management-Kapazitäten bindet und weniger Ressourcen für die Erfüllung strategischer, innovativ bedeutsamer Aufgaben verbleiben. 75 IT- Abteilungen können sich nicht die Wettbewerbsposition stärkenden Systemen widmen, sondern müssen Prozesse kontrollsicher machen. Erste empirische Befunde kommen zu dem Schluss, dass die betroffenen Unternehmen nicht von der ausgebauten Regulierung profitieren, sondern dadurch Nachteile erleiden. 76 Eine (kühne) Berechnung schätzt die durch den SOA verursachte Vernichtung an Marktkapitalisierung auf 75 Milliarden USD Jones (2003). 74 Vgl. etwa Grivolas (2005); Sanchez (2005). 75 Vgl. auch Börsig (2005), S. 27; Butler / Richardson (2005), S. 9; Wayman (2005). 76 Vgl. Zhang (2005), S Vgl. Moe (2004).

18 Zusammenfassung und Ausblick Der SOA ist eines der Gesetze, welches Beziehungen zwischen Aktionären und Management regelt. In anderen Regionen sind ähnliche Entwicklungen zu beobachten. So arbeitet die EU ebenfalls an Regelungen zur Verbesserung der Corporate Governance. 78 Vorteile des SOA sollen in einer klar definierten Beziehung zwischen dem Management und den Aktionären sowie in einer genaueren Finanzberichterstattung bestehen. Um die Handlungen des Managements auf Aktionärsinteressen auszurichten, seien detaillierte Kontrollen vorzusehen. Diese erhöhen die Wahrscheinlichkeit des Auf deckens von Fehlverhalten etwas, können es aber nicht mit Sicherheit vermeiden. In einer Umfrage gaben 65% der Antwortenden an, der SOA sei ein wirksames Instrument, um Finanzbetrug aufzudecken. 79 Die geforderten Kontrollprozesse verursachen Kosten, die den Unternehmenswert reduzieren und somit letztlich die Aktionäre belasten. Manche (eher risikoscheue) Aktionäre werden extensive Kontrollen begrüssen, weil ihnen die zusätzlich gewonnene Wahrscheinlichkeit für eine aussagefähige Rechnungslegung mehr Nutzen bringt als die damit verbundenen Kosten; andere (eher risikobereite) Aktionäre werden solche Regelungen ablehnen. Von Entscheidungsmodellen zur Bestimmung des optimalen Ausmasses einer Corporate Governance ist die Wirtschaftstheorie weit entfernt. 80 Zudem differieren die subjektiven Vorstellungen über Optimalität weit, sodass sich die Suche nach einer für alle Beteiligten besten Lösung erübrigt. Einerseits wären für multinational operierende Gesellschaften vereinheitliche Regeln wünschenswert, um Parallelarbeit zu vermeiden. Andererseits kann es sinnvoll sein, unterschiedliche, miteinander konkurrierende Governance-Modelle anzubieten 81 ; im Idealfall besitzt auch ein in einem bestimmten Staat domiziliertes Unternehmen Wahlmöglichkeiten. 82 Den zuständigen Unternehmensorganen steht es frei, sich über gesetzliche Vorschriften hinaus an strengeren Governance-Modellen auszurichten und dies zu kommunizieren, wenn es diese Vorgehensweise für die Erreichung seiner Ziele als vorteilhaft ansieht. Der Markt lässt diese Entscheidungen in seine Bewertung des Unternehmens einfliessen. Wägt man diese Argumente gegeneinander ab, so kann auf Grund der vorliegenden Erfahrungen kaum empfohlen werden, die in den USA mit dem SOX geschaffenen Bestimmungen in andere Wirtschaftsräume zu übernehmen Die Europäische Kommission (2005). 79 Vgl. SmartPros (2005). 80 Brockhoff (2005), S Vgl. etwa Witt (2003). 82 Brockhoff (2005), S Vgl. auch Thumann (2005), S. 21.

19 Literatur Arbeitskreis 'Externe und Interne Überwachung der Unternehmung' der Schmalenbach-Gesellschaft für Betriebswirtschaft (2004): Auswirkung des Sarbanes-Oxley Act auf die Interne und Externe Unternehmensüberwachung; in: Betriebs-Berater, 59. Jg. (2004), S Bace, John / Rozwell, Carol / Caldwell, French (2005): Examine Sarbanes-Oxley Section 404 Weaknesses and Use IT as Your Solution; Gartner Note G ( ); [Abruf: ] Börsig, Clemens (2005): Künftige Herausforderungen der Corporate Governance bei der Deutschen Bank, Interview; in: Corporate Governance; Hrsg. Ernst & Young; Stuttgart 2005, S British Standards Online (2005): Standard Number: BS ISO/IEC 17799:2005; Information technology. Security techniques. Code of practice for information security management; [Abruf: ]. Brockhoff, Klaus (2005): Technologie, Innovation und Corporate Governance; in: Journal für Betriebswirtschaft, 55. Jg. (2005), S Brooks, Dean / Goldman, Mort / Lanza, Richard (2005): 2005 Buyer's Guide to Audit, Anti-Fraud, and Assurance Software; Vancouver Bundesamt für Sicherheit in der Informationstechnik (2004): IT-Grundschutzhandbuch; [Abruf: ]. Butler, Charles W. / Richardson, Gary L. (2005): The Implications of Sarbanes-Oxley for the IT Community; in: Enterprise Risk Management and Governance Advisory Service, Executive Report; Vol. 2 (2005), No. 3. Carnegie Mellon Software Engineering Institute (2005): What is CMMI?; [Abruf: ]. CFO Research Services (2005): Compliance and Technology: A Special Report on Process Improvement and Automation in the Age of Sarbanes-Oxley; $file/finalvirsa pdf [Abruf: ]. Chan, Sally / Lepeak, Stan (2004): IT and Sarbanes-Oxley; in: Management, Vol. 78 (2004), Issue 4, S ; [Abruf: ]. COSO (2004): Enterprise Risk Management Integrated Framework: Executive Summary Framework; Jersey City Cunningham, Michael (2005): Meeting Sarbanes-Oxley Section 409 Requirements; in: Sarbanes-Oxley Compliance Journal ( ); [Abruf: ]. Deutsche Bank Research (2005): Outsourcing nach Indien: der Tiger auf dem Sprung; Frankfurt ( ); PROD pdf [Abruf: ]. Die Europäische Kommission (2005): Richtlinien und andere offizielle Verlautbarungen; [Abruf: ]. EuSpRIG (2005): Annual Conference 2005: Managing Spreadsheets in the light of Sarbanes-Oxley; London 2005; [Abruf: ]. Friesenecker, Stefan (2005): IT Governance in einer Grossbank; Vortrag auf der 8. Berner Tagung für Informationssicherheit 2005: IT Governance - wirkungsvolles Instrument oder Alibi?; Bern ( ); [Abruf: ] Fortuna Power Systems (2005): archiving; [Abruf: ]. Goulet, Bernie (2005): The Best Defense is Being Proactive About Retention; in: Sarbanes-Oxley Compliance Journal ( ); [Abruf: ]. Grivolas, Nerys (2005): Turning Sarbanes-Oxley into a strategic Advantage; in: IT Observer ( ); [Abruf: ]. Hagerty, John / Scott, Fenella (2005): SOX Spending for 2006 To Exceed $6B; AMR Research ( ); [Abruf: ]. Herbst, Holger / Knolmayer, Gerhard (1995): Ansätze zur Klassifikation von Geschäftsregeln; in: Wirtschaftsinformatik, 37. Jg. (1995), S Hoch, Detlev J. (2005): Gefahr Offshoring?; in: Informatik-Spektrum, Band 28 (2005),

20 Hoffman, Thomas (2003): Users struggle to pinpoint IT costs of Sarbanes-Oxley compliance; in: Computerworld ( ); [Abruf: ]. Hunton, James E. / Bryant, Stephanie M. / Bagranoff, Nancy A. (2004): Core Concepts of Information Technology Auditing; Hoboken Iosub, John C. (2003): What the Sarbanes-Oxley Act means for IT managers; in: TechRepublic ( ); [Abruf: ]. ISACA (2001): COBIT, 3 rd ed.: Der international anerkannte Standard für IT-Governance; Zürich ( ); [Abruf: ]. ISACA (2005): COBIT 4.0 Frequently Asked Questions; ContentManagement/ContentDisplay.cfm&ContentID=22097 [Abruf: ]. ITGI (2004): IT Control Objectives for Sarbanes-Oxley: The Importance of IT in the Design, Implementation and Sustainability of Internal Control over Disclosure and Financial Reporting; IT_Control_Objectives_for_Sarbanes-Oxley_7july04.pdf [Abruf: ]. Jones, Del (2003): Sarbanes-Oxley: Dragon or white knight?; in: USA TODAY ( ); [Abruf: ]. Kaplan, Jeff (2005): Backsourcing: Why, When, and How to Do It; in: Cutter Executive Report; Vol. 6 (2005), No. 1. Klaus, Oliver (2005): Geschäftsregeln zur Unterstützung des Supply Chain Managements; Lohmar / Köln Knolmayer, Gerhard (1981): Die Beurteilung von Leistungen des dispositiven Faktors durch Prüfungen höherer Ordnung; in: Management und Kontrolle; Festgabe für Erich Loitlsberger; Hrsg. Gerhard Seicht; Berlin 1981; S Knolmayer, Gerhard / Herbst, Holger (1993): Business Rules; in: Wirtschaftsinformatik, 35. Jg. (1993), S Köhler, Peter: ITIL; Berlin KPMG (2004): Sarbanes-Oxley Section 404 An Overview Of The PCAOB's Requirements; [Abruf: ]. Krishnan, Ramayya / Peters, James / Padman, Rema / Kaplan, David (2005): On Data Reliability Assessment in Accounting Information Systems; in: Information Systems Research, Vol. 16 (2005), S Kugel, Robert D. (2005): The Silver Lining In SOX; in: Compliance Pipeline ( ); [Abruf: ]. Kvica, Ceryl (2005): Compliance Strategies That Work, in: BusinessWeek; [Abruf: ] Lahti, Christian B. / Peterson, Roderick (2005): Sarbanes-Oxley: IT Compliance Using COBIT and Open Source Tools; Rockland Lev, Baruch (2003): Corporate Earnings: Facts and Fiction; in: Journal of Economic Perspectives, Vol. 17 (2003), S [Abruf: ]. Loitlsberger, Erich (1966): Treuhand- und Revisionswesen; 2. Aufl.; Stuttgart 1967 Menzies, Christof (2004) (Hrsg.): Sarbanes-Oxley Act: Professionelles Management interner Kontrollen; Stuttgart Miller, Richard I. / Pashkoff, Paul H. (2002): Regulations Under the Sarbanes-Oxley Act; in: Journal of Accountancy, Vol. 194 (2002), S [Abruf: ]. Moe, Michael (2004): Sox Sucks; in: AlwaysOn ( ); [Abruf: ]. Moeller, Robert (2004): Sarbanes-Oxley and the New Internal Auditing Rules; Hoboken Monn, Lucas (2005): IT-Compliance für Sarbanes-Oxley; Ringvorlesung Informationsmanagement; Zürich ( ); [Abruf: ]. Nutz, Andreas / Strauß, Markus (2002): extensible Business Reporting Language (XBRL) - Konzept und praktischer Einsatz; in: Wirtschaftsinformatik, 44. Jg. (2002), S NN (2005): SOX: retention is 'a legal Chernobyl' ( ); in: silicon.com ( ); [Abruf: ].