Vorgehensmodell Anwendungsprüfung - Bitterli Consulting AG
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Vorgehensmodell
Anwendungsprüfung
Oktober 2010
sse
oze
tspr
chäf
Ges
en
ung
nw end
IT-A
e
stem
sissy
IT-Ba
tur
truk
fras
IT-In
©
ITA
CS
Tr
ain
in
g© Copyright ISACA Switzerland Chapter, 2010. Autoren: Peter R. Bitterli Jürg Brun Thomas Bucher Brigitte Christ Bernhard Hamberger Michel Huissoud Daniel Küng Andreas Toggwyler Daniel Wyniger Grafiken und Layout: ITACS Training AG
VORGEHENSMODELL ANWENDUNGSPRÜFUNG
Inhaltsverzeichnis
Inhaltsverzeichnis 1
Übersicht und Einführung 2
Analyse von Bilanz und Erfolgsrechnung 4
Identifikation der Geschäftsprozesse und Datenflüsse 7
Identifikation der Kernanwendungen und der wichtigsten IT-relevanten Schnittstellen 11
Identifikation der Risiken und Schlüsselkontrollen 16
Walk-through 20
Beurteilung des Kontroll-Designs 22
Beurteilung der Umsetzung der Kontrollen 26
Gesamtbetrachtung und Ergebnisfindung 30
Anhang 1 – Anwendungsabhängige Kontrollen 32
Anhang 2 – Glossar 36
1Übersicht und Einführung
Zweck des Vorgehensmodells Ein integrierter Prüfansatz von Prüfer und IT-Prüfer stellt sicher, dass bei anwen
dungsabhängigen verfahrensorientierten Prüfungen alle wichtigen Gebiete aus-
reichend abgedeckt werden und “gleichzeitig” diejenigen IT-spezifische Gebiete
geprüft werden, die ebenfalls einen primären Einfluss auf das Prüfziel des Prüfers
haben. Ohne ein aufeinander angestimmtes Vorgehen von Prüfer und IT-Prüfer
besteht hier ein erhöhtes Prüfungsrisiko.
Um diesem Prüfungsrisiko zu entgegnen, werden mit dem vorliegenden Papier
ein standardisiertes Vorgehen und ein integrierter Ansatz für die geschäftspro-
zessorientierten Anwendungsprüfungen aufgezeigt.
Umfang und Abgrenzung Das aufgezeigte Vorgehensmodell beschränkt sich auf das Vorgehen bei einer
Prüfung von Anwendungen innerhalb eines Geschäftsprozesses. Verwandte
Bereiche werden angesprochen, sofern sie Schnittstellen zum Vorgehensmodell
haben; sie werden aber nicht im Detail behandelt. Dies bezieht sich beispiels-
weise auf Themen wie Stichprobenprüfungen, erforderliche Qualifikationen der
Prüfer und ”generelle IT-Kontrollen” (anwendungsunabhängige IT-Kontrollen).
Die Anwendung des Vorgehensmodells ist nicht beschränkt auf die Prüfung der
Ordnungsmässigkeitskriterien; vielmehr wurde das Vorgehen bewusst generisch
gehalten und kann somit auch für andere Prüfungen (z.B. Compliance-Prüfungen)
herangezogen werden.
Anwenderkreis Die Beispiele und Vorgehensbeschreibung im Dokument sind auf die Abschluss
prüfung ausgerichtet. Aufgrund seines generischen Charakters ist das Vorge-
hensmodell sowohl vom Abschlussprüfer als auch vom IT-Prüfer anwendbar.
Die Prüfung der finanziellen Rechnung eines Unternehmens stellt den Abschlussprüfer vor zunehmend grosse Herausforde-
rungen; auf der einen Seite die Entwicklung der Rechnungslegungsstandards mit hoher Kadenz, auf der anderen Seite die
zunehmend automatisierte ”Produktion” der Finanzzahlen durch immer komplexere Informationssysteme. Diesem zweiten
Aspekt widmet sich die folgende Schrift.
Die Qualität der Finanzzahlen hängt wesentlich mit der Qualität der Geschäftsprozesse bzw. der damit zusammenhängen-
den Datenflüsse zusammen. Es ist daher nahe liegend, dass sich der Prüfer auf das Kontrollumfeld dieser Geschäftsprozesse
fokussiert und die Prüfung der entsprechenden Anwendungen in seinen Prüfungsansatz integriert.
Der im Folgenden aufgezeigte Ansatz soll den Abschlussprüfer in der Entwicklung eines integrierten Prüfungsansatzes
unterstützen und durch den Einbezug der Prüfung der relevanten Geschäftsprozesse und entsprechenden Anwendungen
zu einem effizienten und besser auf die Risiken ausgerichteten Prüfungsvorgehen führen. Der Ansatz beginnt deshalb mit
der Analyse der finanziellen Rechnung des Unternehmens und resultiert in der Betrachtung der Auswirkungen der erlang-
ten Prüfungsergebnisse auf diese Rechnung.
2VORGEHENSMODELL ANWENDUNGSPRÜFUNG
Die 8 Schritte des Vorgehensmodells::
Um die Prüfungshandlungen im Bereich der Geschäfts
prozesse und entsprechender Anwendungen konsequent
z
Bilan auf die Testierung der finanziellen Rechnung eines Unter
s e von nung
l y h
Ana folgsrec nehmens und die damit zusammenhängenden Prüfungs
Er
und
1 esse risiken ausrichten zu können, ist es sinnvoll, die finanzielle
sp roz
häft Rechnung einer Analyse zu unterziehen. In dieser Analy-
e r Gesc se
n d enflüs
atio se erfolgt eine Zuordnung der wesentlichen Rechnungs
tifik und Dat
Iden der
2 und positionen zu den relevanten Geschäftsprozessen oder
u n gen len
d l
wen hnittste konkreter: Aus welchen Datenflüssen werden die wesentli-
rnan c
d e r Ke anten S
n v chen Rechnungspositionen ”produziert” und welche Kern-
katio n IT-rele
ntifi e
3 Ide ichtigst Anwendungen verwalten diese Datenflüsse?
w en
Risik
i o n der l l e n
t ro
e n t ifika selkont Bei den identifizierten Kernanwendungen interessiert sich
Id üs
Schl
4 und der Prüfer in der Folge für die Qualität des Kontrollsystems.
gh Dabei beurteilt er zuerst, ob die Konzeption des Kontroll
-t hrou
Walk systems eine angemessene Antwort auf die bestehende
5 Risikosituation der Geschäftsprozesse darstellt und danach,
ns
esig
oll-D ob die vorgesehenen Kontrollen implementiert und wirk-
sK ontr
de
te ilung sam sind.
Beur
6
ollen
rK ontr
g de Mit der Beurteilung des Kontrollsystems der im Prüfungs
se tzun
r Um umfang berücksichtigten Geschäftsprozesse erlangt der
ilung de
te
7 Beur g Prüfer Hinweise, in wie weit er auf die Verfahren, aus wel-
dun
bn isfin
Erge chen die wesentlichen Rechnungspositionen entstehen, ab-
und
ach tung stützen kann, und in welchem Masse er allenfalls ergebnis-
mt betr
8 Gesa orientierte Prüfungshandlungen zusätzlich durchführt.
Im vorliegenden Vorgehensmodell explizit nicht abgedeckt sind die ”generellen IT-Kontrollen”. Der Prüfer muss allenfalls
die generellen IT-Kontrollen beurteilen und testen, um eine geeignete Prüfstrategie für die Anwendungskontrollen ableiten
zu können. Die generellen IT-Kontrollen sind massgeblich bestimmend, ob eine Anwendungskontrolle, welche vom Design
her als effektiv eingestuft wurde, über die gesamte Prüfperiode hinweg als wirksam angenommen werden darf, oder ob
der Prüfer dies z.B. explizit durch direkte Tests (z.B. Einzelfallprüfungen) beurteilen muss.
Das Vorgehensmodell basiert auf dem umstehend skizzierten vierstufigen Schichtenmodell, welches die wesentlichen
Zusammenhänge vereinfacht und generisch darstellt. In der Realität können die Zusammenhänge wesentlich komplexer
sein, doch ist diese Abstraktion für das Verständnis des Vorgehensmodells zweckdienlich.
3Abgrenzung des Vorgehensmodells
Im Vorgehensmodell
IT-Anwendungskontrollen
abgedeckt
• Vollständigkeit
sse • Genauigkeit
oze
tspr
chäf • Gültigkeit
Ges
• Berechtigung
• Rollentrennung
n
nge
ndu
nwe
IT-A
Generelle IT-Kontrollen
Im Vorgehensmodel
• Kontrollumgebung
nicht abgedeckt
(Richtlinien, Direktiven) e
stem
• Softwareentwicklung sissy
IT-Ba
• IT-Änderungen
• IT-Betrieb
• Zugriffskontrolle r
uktu
• Systemsicherheit fr astr
IT-In
• Datensicherheit
• Überwachung
Die obige Abbildung zeigt vereinfacht das in diesem Vorgehensmodell verwendete Schichtenmodell. Jede der vier Schichten
steht für eine Art von Prozessen und Ressourcen:
• In der obersten (blauen) Schicht finden wir alle wesentlichen (manuellen) Geschäftsprozesse – typischerweise aufgeteilt
nach verantwortlichen Fachbereichen und in Sub-Prozesse und einzelne Aktivitäten.
• In der zweiten (roten) Schicht finden wir die automatisierten Teile der Geschäftsprozesse, die eigentlichen (IT-) Anwendungen.
Mit Ausnahme der wirklich kleinen KMU wird bei praktisch allen Unternehmen der grösste Teil der Geschäftsfälle mit
Hilfe solcher Anwendungen verarbeitet.
• In der dritten (gelben) Schicht finden wir die IT-Basissysteme. Dieser Begriff umfasst eine grosse Vielfalt möglicher Platt-
formen, auf denen die eigentlichen Anwendungen der zweiten Schicht laufen. Beispiele sind eigentliche Datenbank-
Verwaltungssysteme (z.B. Oracle, DB2), die Basiskomponenten integrierter Anwendungen (z.B. SAP-Basis, Avaloq, …)
oder auch eher technische Verarbeitungssysteme (z.B. Middleware).
• In der untersten (grünen) Schicht finden wir die Informatik-Infrastruktur. Im Wesentlichen umfasst diese die eigentliche
Hardware (Grossrechner, Midrange-Systeme, Server) wie auch die zugehörigen Netzwerk-Komponenten und technischen
Überwachungssysteme.
Das in diesem Dokument vorgestellte Vorgehensmodell beschäftigt sich primär mit den oberen beiden Schichten (mit dem
grünen Pfeil angedeutet), also den anwendungsabhängigen Kontrollen in den Geschäftsprozessen und den sie unter
stützenden Anwendungen. Die unter beiden Schichten, also die IT-Infrastruktur mit den sie unterstützenden IT-Prozessen
(mit dem roten Pfeil angedeutet), können aus Prüfersicht sehr wohl auch wesentlich sein, werden aber im vorgestellten
Vorgehensmodell nicht weiter behandelt.
4VORGEHENSMODELL ANWENDUNGSPRÜFUNG
1 Analyse von Bilanz und Erfolgsrechnung
Übersicht
Inhalt und Wir gehen davon aus, dass das Prüfungsziel die Ordnungsmässigkeit der Buchführung ist. Das Vorgehen
Zielsetzung ist dann wie folgt:
• Festlegen der Bilanz- und Erfolgsrechnungspositionen, welche für die Prüfung relevant sind
• Identifikation der Transaktionen (Geschäftsvorfälle) bzw. Transaktionsklassen1, welche diese
Positionen generieren.
Hintergrund Die Analyse2 der Bilanz und Erfolgsrechnung ist zentral für eine risikoorientierte und zielgerichtete
Prüfung und dient der Identifikation derjenigen Bilanz- und Erfolgsrechnungspositionen, welche für
die Prüfung relevant d.h. wesentlich sind. Diese Analyse liefert dem Prüfer wichtige Informationen zur
Risikoermittlung und zur Feststellung von aktuellen Entwicklungen mit Einfluss auf die Jahresrechnung.
Gleichzeitig dient sie als Planungsinstrument bei der Festlegung der Prüfungsschwerpunkte und der
zum Einsatz gelangenden Prüfungsmethoden.2
Vorgehen
Wesentliche Konten
z.B. Debitoren
RISIKO Aussagen
im Abschluss, z.B.:
RISIKO
Echtheit
Bewertung
RISIKO
Vollständigkeit
e s RISIKO
cess
s Pro
ines Rechte und
Bus
s)
Verpflichtungen
esse
Proc
ted
toma
(Au
cat ions
ppli
IT A
, …)
acle ing
S, Or ACS
Train © ITACS Trainin
, IM © IT
g. SAP
rm s (e. )
latfo rk, …
IT P Ne two
ions
icat
om mun
e, C
d war
(Har
ructure
f rast
IT In
ng
1 Eine Transaktionsklasse ist eine Menge von Transaktionen resp. Geschäftsvorfällen innerhalb eines Prozesses, welche auf ähnlichen Sachverhalten beruhen
und im Wesentlichen gleich verbucht werden.
2 Schweizer Handbuch der Wirtschaftsprüfung, 1998, Kapitel 3.2424 Analyse der Jahresrechnung
5Identifikation der relevanten Konten bzw. Kontengruppen
Der Prüfer führt eine Risikobeurteilung durch und identifiziert die Risken, die einen Einfluss auf die zu prüfende Jahres-
rechnung haben können, um seine Prüfungstätigkeiten darauf ausrichten zu können. Hierbei spielt auch die Definition der
Wesentlichkeit eine wichtige Rolle.
Es werden die Konten resp. Kontengruppen identifiziert, welche die Wesentlichkeitsgrenze3 überschreiten und somit in den
Umfang (Scope) der Prüfungstätigkeiten fallen.
Auch werden diejenigen Konten resp. Kontengruppen identifiziert, deren Bestand und/oder Veränderung spezifischen
Risiken unterworfen ist oder auf spezifische Risiken hinweist, beispielsweise durch unerwartete Veränderungen in Kenn-
zahlen.
Identifikation der relevanten Transaktionen bzw. Transaktionsklassen
Sind die Konten-Positionen identifiziert, kann der Prüfer in einem zweiten Schritt analysieren, durch welche Transaktionen
resp. Transaktionsklassen deren Bestände massgeblich beeinflusst werden. Hierzu kann es sinnvoll sein, mittels einer Daten-
analyse zu untersuchen, welche Buchungen auf bestimmten Konten vorgenommen wurden. Daraus kann abgeleitet wer-
den, aus welchen Geschäftsvorfällen die Transaktionen erzeugt wurden. Dies kann in einem ERP-Umfeld erfolgen, indem
man die elektronischen Buchungen auf den relevanten Konten nach Bewegungsarten gliedert.
Der Prüfer arbeitet sich somit von den wesentlichen Konten und Kontengruppen über die wesentlichen Transaktionen
zurück zu den Geschäftsvorfällen, die diese Transaktionen erzeugt haben.
Der Vorteil dieses rückwärts gewandten Ansatzes besteht darin, unwesentliche Transaktionsklassen, welche aus den Ver
ästelungen und Verzweigungen der Prozesse entstehen, auf Anhieb ausschliessen zu können. Kennt der Prüfer die wesent-
lichen Transaktionsklassen und die Geschäftsvorfälle, die diese erzeugen, kann er wie im nächsten Schritt beschrieben die
Analyse der Risiken in den einzelnen Prozessschritten vornehmen.
Besonderheiten
Im Rahmen der Anwendungsprüfung fokussiert der Prüfer im Allgemeinen auf Routine-Transaktionen, da diese weit
gehend durch die Anwendung gesteuert werden und sich hier die meisten automatisierten und IT-abhängigen Kontrollen
finden, während bei den Nicht-Routine-Transaktionen, speziell bei den Schätzprozessen, häufig ein überwiegend manuelles
Kontrollsystem vorherrscht.
Der Prüfer sollte in diesem Stadium seiner Arbeit auch die wesentlichen Ereignisse in der Unternehmung
berücksichtigen,
welche allenfalls Einfluss auf die ausgewählten Konten oder Klassen von Geschäftsvorfällen genommen haben. z.B.:
• Einführung einer neuen Anwendung
• Migration oder Zusammenführen von Anwendungen oder Anwendungsdaten
3 Schweizer Handbuch der Wirtschaftsprüfung, 1998, Kapitel 3.114: «Wesentlich sind alle Sachverhalte, welche die Bewertung und die Darstellung des
Einzelabschlusses und der Konzernrechnung oder einzelner ihrer Posten beeinflussen, sofern dadurch die Aussage so verändert wird, dass die Adressaten
des Einzelabschlusses oder der Konzernrechnung in ihren Entscheidungen gegenüber der Gesellschaft beeinflusst werden können.»
6VORGEHENSMODELL ANWENDUNGSPRÜFUNG
2 Identifikation der Geschäftsprozesse und Datenflüsse
Übersicht
Inhalt und Identifikation der relevanten Geschäftsprozesse, die zu den vorher identifizierten Transaktionen und
Zielsetzung Transaktionsklassen führen. Unter ”relevanten Geschäftsprozessen” sind die wesentlichen Prozesse
zu verstehen, die unmittelbare Auswirkungen auf den Finanzfluss haben. Dies beinhaltet den Buch
führungsprozess als solchen, komplexere Geschäftsprozesse wie die Fakturierung, Supportprozesse z.B.
im Personalbereich. IT-Prozesse, wie sie beispielsweise in CobiT definiert sind, sind jedoch nicht betroffen4.
Hintergrund Die Rechnungslegung ist ein Schlussbild von mehreren Tätigkeiten, die man zu Prozessen gruppieren
kann, die sehr unterschiedlich sein können (zeitlich begrenzte, komplexe Prozesse; Prozesse, die mehre-
re Transaktionen beeinflussen etc.). Schwachstellen in diesen Prozessen können aber potentiell die Aus-
sagekraft der finanziellen Berichterstattung in Frage stellen. Deswegen ist eine sorgfältige Identifikation
der Geschäftsprozesse und Datenflüsse unabdingbar, um anschliessend die Risiken in jedem Prozess
beurteilen zu können.
Vorgehen
Identifikation der relevanten Prozesse
Ausgehend von den identifizierten Transaktionen identifiziert der Prüfer nun die Prozesse, die diese Positionen beeinflus-
sen. Das Spektrum reicht z.B. vom zeitlich begrenzten Jahresabschluss-Prozess (mit direkten Einfluss auf die Höhe einer
Rückstellung) bis zu einem komplexen Verkaufs- und Fakturierungsprozess, der den Waren- und Finanzfluss beeinflusst. Im
letzten Fall werden mehrere Bilanz- und Erfolgsposition den gleichen Prozess als ”Quelle” haben.
Die Prozesse können sinnvollerweise tabellarisch oder graphisch in der Form einer Prozesslandkarte dargestellt werden.
Beide Darstellungsformen bringen Vorteile – und bei komplexen Prozess-Zusammenhängen kann es von Vorteil sein, sie
miteinander zu kombinieren.
Verwendung bestehender Dokumentation
Falls vorhanden, sollte sich der Prüfer auf bereits bestehende Prozessdokumentation stützen. Sie konzentriert sich üblicher-
weise auf Tätigkeiten und präzisiert für jeden Prozessschritt die Eingabe, Verarbeitung, Ausgabe sowie die Rollen der ver-
schiedenen Beteiligten. Solche Dokumentationen enthalten aber selten die Prozessrisiken oder die Schlüsselkontrollen, die-
se sind daher durch den Prüfer in einer späteren Phase der Anwendungsprüfung zu identifizieren und zu dokumentieren.
Erstellen neuer Dokumentation - Darstellungsformen
Der Prüfer verschafft sich ein ausreichendes Detailverständnis über die selektierten Prozesse. Dabei ist zu unterscheiden zwi-
schen den Routine-Geschäftsprozessen (z.B. Verkaufsprozess) und den Nicht-Routine-Finanzprozessen (z.B. Konsolidierung
der Quartalszahlen einer Niederlassung oder Berechnung der jährlichen Amortisation einer Anlage). Beide Arten enthalten
Risiken, die sich in der Jahresrechnung materiell widerspiegeln können.
4 Ein Prozess kann definiert werden als «eine Verkettung von manuellen, halb-automatischen oder automatischen Aufgaben, die der Erstellung oder der
Verarbeitung von Informationen, Produkten oder Dienstleistungen dienen. Beispiele: Verkauf, Mahnwesen, Produktion, Inventur, Buchführung usw.».
7Tabellarische Form – geeignet für einfache Tatbestände und Zusammenhänge
Bilanz- oder Erfolgs- Betrag in T CHF Output Prozess Input
rechnungsposition
Umsatz 675’123 Rechnungen Verkauf Verträge,
erbrachte
Leistungen
Aufwand 422’234 Zahlungen Einkauf Bestellungen
Lager 57’000
Einrichtungen 121’000
Kreditoren 45’000
Personalaufwand 121’111 Zahlungen HR Management Verträge,
Sozialversicherung 13’000 Leistungen
Etc…
Anlagen 121’000 Amortisation Abschluss Wert
Verschiedene Konsolidierte Konsolidierung Positionen einer
Positionen Niederlassung
Graphische Darstellung (Prozessmodell-Form) – geeignet für komplexe Zusammenhänge
Beispiel A
es
Sal
ic
teg
ials Strasales
ter e-
Maanag t
n m men
ctio d
Pro
du g
ishe n tive
Eng
ine
erin
Fin ductio era
Op sales
rk pro
ials Woduling
ter e-
e
sch P
Maanag t MR
- m men
cha
Pursing r
Rawrials
Job ation me
gic par sto
Cu
te
Stra hasin
g
te pre
purc ma ppin
g
MR
P Sho
e
ous
reh
ting g Wa
era in
Op rchas
pu
ng
Billi
tion
duc
Pro ory g
ent
Inv ountin
se acc
re hou
Wa
l ts
rna g oun le
Inte untin Acc eivab
o
ods acc rec
Go cept
re
ory g
or ent
d Inv ountin
Ven acc
e
ng
nti
oic n
Inv catio
ver
tifi
ou
GL nting Acc g
n
olli
ou
acc
ntr
Co
t
ets g cos t
Ass untin ad
rhe eme
n
acc
o Ove anag
m
ts
oun
Accayable
p
8VORGEHENSMODELL ANWENDUNGSPRÜFUNG
Beispiel B
Führungsprozesse
Corporate Governance Zielsetzungsprozesse Controlling
Strategie Unternehmens-Organisation Personalführung
Category Management (CM)
Beschaffungsmarkt
Beschaffungsmarkt
Beschaffung (Einkauf/Disposition)
Logistik
Verkauf
Unterstützungsprozesse
Finanzen/Services Informatik Personal/Ausbildung
Kommunikation Qualitätsmanagement Immobilienmanagement
Standortmanagement Interne Dienstleistungen Produktion
Graphische Darstellung (Datenfluss-Form) – geeignet für die effektive Analyse komplexer Zusammenhänge
Human Resources Management Lohnverwaltung Produktionsmanagement
• Personalmanagement Personal- • Lohnverwaltung kumulierte
• Ausbildungsmanagement daten (T) Arbeits- Produkteverwaltung Budgetprozesse
• Arbeitszeitmanagement stunden (M)
• Kompetenzmanagement Überwachung Produkte Industriebuchhaltung
Sozialbilanz und und Produktivität
Lohnabrechnungen (M)
Lagerverwaltung Zeiterfassung
Überweisungsdaten Löhne
und Spesenrechnungen
eff. Kosten (M) Management Produktionsverfahren
Finanzverwaltung Buchführung
• Finanzverwaltung Überwei-
• Überweisungen sungsdaten Allgemeine Buchhaltung Betriebsbuchhaltung
• Gehälter
Schnittstellen mit Eingang (T) Lieferung u. Eingang
Finanzbewegungen der Produkte (T)
Immobilien- Bilanzstand der Kunden
Immobilienverzeichnis erwerb (T) und Ergebnis
und Abschreibungen (M) Zentralisierung
Umsatz (V)
Immobilienverwaltung Konsolidierung Kfm. Geschäftsführung
• Verwaltung des Anlagevermögens • Konsolidierung
• Abschreibungen • Reporting Kundenbetreuung Budget
Verkaufsstatistiken Warenlager
Spanne Bruttomarge
automatische Schnittstellen und eff. Kosten (V)
Rechnung (T)
halbautomatische Schnittstellen Bestellg./Lieferg./Rechng. Akquisition
manuelle Schnittstellen
Kundenbuchhaltung Kreditver. Kunden
PC (M) monatlich
NT-Server (T) täglich
Alpha-VSM (V) vierteljährlich
Rechnungen Bestellungen
Basiert auf deutscher Fassung des “Collection guide d‘application“
Lieferanten EDI
© CNCC Edition – Avril 2003, V2.0
9Besonderheiten
Detaillierungsgrad
Eine zu allgemeine Beschreibung erschwert die Identifizierung der Risiken, und ein zu hoher Detaillierungsgrad kann die
Analyse und Lesbarkeit behindern. Je nach Komplexität eines Prozesses kann es nützlich sein, ihn in mehrere Unterprozesse
aufzuteilen.
Beispiele
• Der Einkaufsprozess besteht aus den Unterprozessen Lieferantenstammdaten-Verwaltung, Lieferantenrechnungs
stellung, Verbuchung der Einkäufe.
• Der Verkaufsprozess besteht aus den Unterprozessen Kundenstammdaten-Verwaltung, Kundenrechnungsstellung,
Verbuchung der Verkäufe.
• Der Lohnprozess besteht aus den Unterprozessen Personaldatenverwaltung, Vorbereitung der Lohnabrechnung, Lohn-
festsetzung und Lohnabrechnung, Lohnverbuchung.
Parameter- und Stammdatenverwaltung
Bei gewissen Geschäftsprozessen empfiehlt es sich, die Verwaltung (erste Erfassung, Mutationen und Löschung) von Para-
metern und Stammdaten als zwei separate Unterprozesse zu betrachten:
• Die Parameter einer IT-Anwendung sind die konstanten Werte, welche bei gleichen Transaktionsarten zur Anwendung
kommen (zum Beispiel Abzugsätze für die Pensionskasse bei einer Lohnanwendung).
• Die Stammdaten sind permanente Attribute eines Objektes, z.B. Kreditorstammdaten, Kundenstammdaten, Material-
stammdaten.
Manuelle Schnittstellen
Ziel dieses Schrittes ist zu verstehen, wie relevante Informationen und Daten fliessen. Dabei geht es nicht nur um elektro
nische Daten; eine ausreichende Analyse berücksichtigt auch Dokumentenflüsse (zum Beispiel Bericht über Lagerbewertung)
und manuelle Schnittstellen.
10VORGEHENSMODELL ANWENDUNGSPRÜFUNG
3 Identifikation der Kernanwendungen und
der wichtigsten IT-relevanten Schnittstellen
Übersicht
Inhalt und Identifikation der beteiligten IT-Anwendungen und deren Schnittstellen.
Zielsetzung
e
zess
äft spro
Gesch
en
ung
nw end
IT-A
e
stem
sissy
IT-Ba
tur
truk
fras
IT-In
©
ITA
CS
Tr
ai
ni
ng
Hintergrund Viele Kontrollen sind automatisiert und in den IT-Anwendungen integriert. Zudem bringt die Automa-
tisierung von Prozessschritten zusätzliche inhärente Risiken. Darunter fallen z.B. die Schwierigkeit eine
adäquate Funktionstrennung zu implementieren aber auch das weitgehende Fehlen menschlicher Ein-
flussnahme aufgrund der hohen Integration, der Echtzeitverarbeitung resp. des “single point of entry”
Prinzips wodurch erfasste Transaktionen automatisch abgewickelt und auch gleich verbucht werden. Es
ist deswegen hilfreich, frühzeitig die beteiligten Anwendungen, ihre Merkmale und Schnittstellen zu
identifizieren. Diese Erkenntnisse erlauben es, eine detaillierte Definition des Prüfungsumfangs bzw. ein
Prüfprogramm zu erstellen.
11Vorgehen
Erstellen der Landkarte der Kernanwendungen
Die Darstellung der beteiligten Anwendung ist nicht immer sequentiell und synchron zur Datenflussübersicht. Besonders
bei stark integrierten Anwendungen (z.B. Enterprise Resource Planning Systems, ERP), werden mehrere Geschäftsprozesse
von einund derselben Anwendung unterstützt (z.B. automatische Verknüpfung eines Einkaufsprozesses mit dem Verkaufs-
prozess).
Beispiel
Human Resources Management Lohnverwaltung
ng Produktionsmanagement
• Personalmanagement Personal- • Lohnverwaltung kumulierte
• Ausbildungsmanagement daten (T) Arbeits- Produkteverwaltung Budgetprozesse
• Arbeitszeitmanagement stunden (M)
• Kompetenzmanagement Überwachung Produkte Industriebuchhaltung
Sozialbilanz
nz und
d und Produktivität
Lohnabrechnungen (M)
Lohnabrechn
Lagerverwaltung Zeiterfassung
Überweisungsdaten Löhne
und Spesenrechnungen
eff. Kosten (M) Management Produktionsverfahren
Finanzverwaltung Buchführung
• Finanzverwaltung
• Überweisungen
Überwei-
sungsdatenn Allgemeine Buchhaltung Betriebsbuchhaltung
FIBU
• Gehälter
Schnittstellen mit Eingang (T) Lieferung u. Eingang
Finanzbewegungen der Produkte (T)
Immobilien- Bilanzstand der Kunden
Immobilienverzeichnis erwerb (T) und Ergebnis
und Abschreibungen (M) Zentralisierung
Umsatz (V)
Immobilienverwaltung Konsolidierung Kfm. Geschäftsführung
• Verwaltung des Anlagevermögens • Konsolidierung
•AAbschreibungen • Reporting Kundenbetreuung Budget
Verkaufsstatistiken Warenlager
automatische Schnittstellen EXCEL ma
Spanne Bruttomarge
en (V)
und eff. Kosten
Rechnung (T)
halbautomatische Schnittstellen Bestellg./Lieferg./Rechng. Ak
Akquisition
manuelle Schnittstellen
Kundenbuchhaltung Kreditver.
dit Kunden
PC (M) monatlich
NT-Server
Alpha-VSM
(T) täglich
(V) vierteljährlich FAKTURA Rechnungen Bestellungen
este
Basiert auf deutscher Fassung des “Collection guide d‘application“
Lieferanten
nten EDI
ED
© CNCC Edition – Avril 2003, V2.0
Inventarisierung und Kategorisierung der finanzrelevanten Anwendungen
Wir unterscheiden die anschliessend aufgeführten Typen von Anwendungen. Da diese stark unterschiedliche Risikoprofile
aufweisen, ist der Programmtyp ein für die Prüfungsplanung und -durchführung wichtiges Merkmal und ist deshalb zu
dokumentieren:
• Standardanwendung
• stark angepasste Standardanwendung
• Eigenentwicklung
12VORGEHENSMODELL ANWENDUNGSPRÜFUNG
Standardanwendungen
Standardanwendungen, welche über eine gewisse Maturität verfügen, weisen i.d.R. eine Vielzahl an relevanten einge-
bauten Kontrollen auf. Die untenstehende Tabelle zeigt als Beispiel einige grundlegende Kontrollen zur Absicherung der
Integrität der verarbeiteten Transaktionen:
Eine Standard-Buchhaltungsan- Diese Funktionalitäten beinhalten (oder setzen voraus)
wendung sollte folgende Funk- folgende Kontrollen
tionalitäten enthalten (keine
abschliessende Auflistung)
Operationen und Transaktionen Zugriffschutz des Systemdatums
automatisch mit dem Systemdatum
datieren
Mehrere Benutzeridentifikationen Einwegverschlüsselung des Passworts
mit Authentisierungsmechanismen
anbieten Syntaxkontrolle des Passworts
Gültigkeitskontrolle des Passworts
Journalisierung von fehlerhaften Anmeldeversuchens
Parametrisierbare Autorisierungen Zugriffschutz durch Profile oder zugewiesene Einzelberechtigungen
Mutationsspur bei Parameter- und Automatische Speicherung der alten Werte in einer History-Datei (mit gültig
Stammdatenänderungen (Sicherheits- von/bis Datum, Mutationsdatum und Identifikation des Benutzers, der die Än-
parameter, Kontenplan, Kreditoren- derung durchgeführt hat)
und Debitorenstammdaten, usw.)
Zugriffsschutz auf Parameter und die History-Datei
Löschverbot Das Programm soll keine Löschungsfunktion enthalten
Von grosser Wichtigkeit sind darüber hinaus aber auch die nachfolgend aufgeführten Kontrollen zur:
• Validierung von Eingaben (z.B. Auswahllisen, Validierungsformeln etc.),
• Steuerung der Verarbeitung (Job-Control, Reihenfolge von Tages-, Monats-, Jahresendverarbeitung, etc.)
• Abwicklung der Transaktionen (z.B. Workflowsteuerung, Limitenkontrollen, Vier-Augen-Prinzip und elektronisches Visum,
Prüfung auf Übereinstimmmung von Bestellung-Lieferung-Rechnung)
• Steuerung der Ausgaben (Verfügbarkeit von Reports, etc.).
Bei der Beurteilung von Standardanwendungen gilt es, z.B. folgende Fragen zu beantworten:
• Welche Art von Standardanwendung setzt die Firma ein?
• Ist diese Standanwendung branchenüblich?
• Ist diese Standanwendung zertifiziert?
• Handelt es sich um ein etabliertes, bekanntes Programmpaket oder eine Neuheit?
• Gibt es Informationsquellen über die Anwendung und eventuell bekannte Sicherheits- oder Prozessschwachstellen (An-
merkung: Auch Standardanwendungen beinhalten manchmal Fehler, und der Prüfer muss ausreichende Kenntnis über
bekannte Fehlerquellen erlangen).
• Verfügt der Prüfer über eigene Kenntnisse und Erfahrungen mit der Anwendung?
13Die Antworten dienen gemäss PS 310 Ziffer 10 der “Identifikation von Bereichen, die besondere Aufmerksamkeit oder
Kenntnisse erfordern” und verschaffen dem Prüfer ein Bild über die inhärenten Risiken aus dem Einsatz der verwendeten
Software.
Kommt der Prüfer zum Schluss, dass für die Standardanwendung in den für ihn relevanten Bereichen keine Schwachstellen
bekannt sind, wird er seinen Aufwand zur Identifikation der Risiken und Beurteilung der relevanten Kontrollen in den fol-
genden Schritten des Vorgehensmodells tief halten können. Im Minimum sollte er sicherstellen, dass:
• die von ihm erwarteten Kontrollen existieren und zur Anwendung kommen, und
• falls es sich um Anwendungsparameter handelt, diese während der relevanten Prüfperiode aktiv waren.
Stark angepasste Standardanwendungen
Unter stark angepassten Standardanwendungen verstehen wir Programmpakete, welche primär Grundfunktionalitäten
und Bausteine zum Aufbau von Prozessen und Workflows bereitstellen, und die durch Customizing und individuelle Zusatz
programmierung eine stark kundenspezifische Ausprägung erhalten können. Hier stellt sich dem Prüfer eine grössere
Herausforderung, indem er zwar bei Systemem mit einer grossen Maturität Informationen über die allgemeine Verlässlich-
keit der Komponenten hat, nicht jedoch über das Zusammenspiel dieser Komponenten und über allfällige Konfigurationen
und Zusatzprogrammierungen in einer kundenindividuellen Umgebung. In solchen Situationen wird der Prüfer mit einem
erhöhten Aufwand zur Identifikation der Risiken und zur Beurteilung der relevanten Kontrollen rechnen müssen. Je stärker
eine Standardanwendung an die unternehmensspezifischen Anforderungen angepasst wurde, desto wichtiger wird die
Analyse der Parameter, der Workflowsteuerung und der programmtechnischer Anpassungen.
Eigenentwicklungen
Bei Eigenentwicklungen trifft der Prüfer auf eine Situation, in der er am wenigsten allgemein bekannte Informationen
und Erfahrungen mit einer Anwendung verwenden kann und er daher sein Prüfvorgehen individuell auf die vorhandene
Anwendung anpassen muss. Eigenentwickelte Anwendungen verursachen in der Regel einen hohen Prüfungsaufwand. In
solchen Situationen ist die Zusammenarbeit zwischen Prüfer, Anwendungsverantwortlichen und allenfalls den Entwicklern
der Anwendung von grosser Bedeutung.
Sowohl bei stark angepassten Standardanwendungen als auch bei Eigenentwicklungen wird sich der Prüfer aus Effizienz
gründen soweit als möglich auf dokumentierte Tests im Unternehmen abstützen. Falls die entsprechenden Tests nicht vor-
handen sind oder keine Aussagekraft haben (mangelhaftes Testkonzept oder Testdokumentation, nicht bereinigte Fehler
nach den Tests, fehlende formale Abnahme durch die Benutzer, usw.), sollte er selber die für seine Prüfung notwendigen
Tests durchführen.
Betrieb der Anwendung bei Dritten oder im Unternehmen
Die Auslagerung von Unternehmensteilen oder -prozessen bringt aufgrund der verteilten Verantwortlichkeiten zusätzliche
inhärente und Kontrollrisiken. Besonders relevant ist dabei die Frage der Organisation einer Prüfung beim Dienstleister.
PS 402 “Unternehmen, die Dienstleistungsorganisationen in Anspruch nehmen – Auswirkung auf die Abschlussprüfung”
(oder SAS 70) sollte dabei berücksichtigt werden.
14VORGEHENSMODELL ANWENDUNGSPRÜFUNG
Zentraler oder dezentraler Einsatz der Anwendung
Ebenfalls aufgrund der verteilten Verantwortlichkeiten aber auch aufgrund einer oftmals erheblich grösseren technischen
Komplexität (z.B. hinsichtlich Datenintegrität aus redundanter Datenhaltung oder Einhaltung von Verarbeitungsabfolgen
über verschiedene Zeit- und Datumszonen) bringt der dezentrale Einsatz einer Anwendung zusätzliche inhärente und
Kontrollrisiken und erhöht die Komplexität innerhalb des Prüfungsgebietes.
Darstellung der Informationen
Tabellarische Darstellung
Bilanzpo- Betrag in Prozess Eingesetzte Kommentar / Vorsysteme Type Internal/ Einsatz
sition TCHF Anwendung external
Umsatz 675’123 Fakturierung SAP FI Schnittstellen von FACTURA Standard Int. Zentral
und LIEFER
Löhne 59’123 Personalver- SAP HR ASP extern Standard Out. Zentral
waltung
Inventar der wichtigsten Schnittstellen
Schnittstellen von und zu einer finanzrelevanten Anwendung sind als Risikoquelle
einzustufen. Es ist wichtig, sie zu identifizieren
und zu überprüfen.
Name der Typ Anwendungen Art der Frequenz Fehler-Listen Risiko-
Schnittstellee vor-/nachgelagert Datenflüsse einschätzung
154 Identifikation der Risiken und Schlüsselkontrollen
Übersicht
Inhalt und Im diesem Schritt wird das “Kontroll-Universum” abgesteckt, das in den Folgeschritten beurteilt und
Zielsetzung geprüft wird. Dazu wird für jedes relevante Risiko (Schadensszenarien) festgehalten, durch welche
wesentlichen Kontrollen dieses mitigiert, also der mögliche Schaden und/oder die Eintrittswahrschein
lichkeit reduziert wird. Ausserdem wird der Einfluss auf die Aussagen im Abschluss (Assertions) analysiert
(z.B. Vollständigkeit, Echtheit, Bewertung, Periodengerechtigkeit, Darstellung in der Jahresrechnung).
sse
oze
äf tspr
Gesch
gen
dun
n wen
IT-A
e
tem
sissys
IT-Ba
tur
truk = Risiko
fras
IT-In
= Kontrolle
©
ITA
CS
Tr
ain
in
g
Hintergrund Aufgrund der Komplexität von Prozessen und Anwendungen ist es wichtig, sich bei der Prüfung auf das
Wesentliche zu konzentrieren. Durch die Identifikation der Risiken und zugehöriger erwarteter Schlüssel
kontrollen erhält man die Grundlage für eine effiziente Prüfung.
Die vom Prüfer erwarteten Schlüsselkontrollen werden in der Folge den effektiv implementierten
Kontrollen gegenübergestellt und die Risikoabdeckung beurteilt.
16VORGEHENSMODELL ANWENDUNGSPRÜFUNG
Vorgehen
Risiken, Kontrollziele und Kontrollen
Innerhalb der wesentlichen Prozesse und der beteiligten Systeme werden Risiken identifiziert, die zu einer wesentlichen
falschen Angabe in der Jahresrechnung führen können. Als Ergebnis erhält man eine Übersicht derjenigen Risiken, welche
die Zielerreichung des Prozesses verhindern können. Durch diese Risikobetrachtung wird auch der Umfang der Prüfungstä-
tigkeiten festgelegt.
Aus den Risiken lassen sich die Kontrollziele ableiten. Ein Kontrollziel ist definiert als eine Aussage zum gewünschten Resultat
(Zweck), das mit der Implementierung von Kontrollen erreicht werde soll. Kontrollziele sind somit häufig “umgekehrte”
Risiken, also die Verminderung eines bestimmten Risikos.
In der Folge bildet der Prüfer im Sinne einer Arbeitshilfe für die identifizierten Risiken eine Erwartungshaltung hinsichtlich
der typischen und erwarteten Kontrollen. Man muss diese Kontrollen weiter einteilen in “Schlüsselkontrollen” und andere
Kontrollen. Schlüsselkontrollen, entweder einzeln oder im Zusammenspiel, sind unentbehrlich zur angemessenen Vermin-
derung der Risiken. Sie sind somit Garant für die Verlässlichkeit des Prozessergebnisses und der Finanzdaten. Die Schlüssel
kontrollen stellen das “Rückgrat” des Kontrollsystems dar und sind somit wesentlicher Prüfgegenstand. Die anderen Kon-
trollen sind für den Prüfer von untergeordneter Relevanz.
Die vom Prüfer erwarteten Schlüsselkontrollen werden in der Folge den effektiv implementierten Kontrollen gegenüber
gestellt und die Risikoabdeckung durch die vorhandenen Schlüsselkontrollen im betreffenden Prozess beurteilt.
Standard-Frameworks
Für diverse Prozesse und Anwendungen existieren generische Übersichten der typischen Risiken, Kontrollziele und Kontroll-
Praktiken. Ein bekannter Vertreter aus dem IT-Bereich ist zum Beispiel das CobiT-Framework. Ein weiteres Beispiel für generi-
sche Anwendungskontrollen ist in Anhang 1 ersichtlich. Diese Hilfsmittel können bei der konkreten Prüfung nützliche
Unterstützung liefern, ersetzen aber nicht die professionelle Beurteilung des individuellen Prozesses durch den Prüfer.
Kontrollarten
Folgende Fragestellungen sind für den weiteren Prüfungsverlauf relevant und sind deshalb zu dokumentieren:
• Präventive versus detektive Kontrollen: Verhindert eine Schlüsselkontrolle das Eintreten eines möglichen Schadens-
ereignisses oder deckt sie es auf?
• Automatische versus manuelle Kontrollen: Wird eine Kontrolle manuell durchgeführt oder ist sie in einer Anwendung
automatisiert?
17Darstellung der Informationen
Als geeignete Darstellungsform empfiehlt sich eine Risiko/Kontroll-Matrix, die in der linken Hälfte aufzeigt, wie die identifi-
zierten Risiken durch Kontrollen abgedeckt werden5:
Risiken Kontrollen Tätig- Aussagen im Abschluss (Assertions) Wir- Wirksamkeit der Kontrollen
keit kung
Was Was wird Design der Umsetzung Wirksam-
könnte wann, wie Kontrollen der keit
schief durch wen Rechte & Verpflichtungen Kontrollen
gehen kontrol-
Periodengerechtigkeit
liert
Ist die Werden ja / nein /
Aufbewahrung
Berechtigung Kontrolle die n.a.
Belegprinzip
Verbuchung
Kontierung
geeignet, Kontrollen
Bewertung
Prüfbarkeit
präventiv
Kontrolle
Operativ
die Krite- durchge-
Echtheit
Echtheit
detektiv
rien zu führt?
erfüllen?
Als zusätzliches Element in der Mitte der Risiko/Kontroll-Matrix wird definiert, welche Aussage im Abschluss6 durch die
jeweilige Schlüsselkontrolle adressiert wird. Somit wird sichergestellt, dass alle Anforderungen durch entsprechende Kon-
trollen abgedeckt werden. Die rechte Hälfte der Risiko/Kontroll-Matrix schliesslich kann in den folgenden Schritten des
Vorgehensmodells dazu verwendet werden, die Beurteilung des Kontroll-Designs und die Beurteilung der Umsetzung der
Kontrollen zu dokumentieren.
Besonderheiten
Vollständigkeit der Risiken und Kontrollen
Die Identifikation der Transaktionskontrollen ist für sich alleine nicht ausreichend; Risiken sowie Kontrollen über Parameter
und Stammdaten sind ebenfalls zu berücksichtigen. Typische Kontrollen sind hier Zugriffskontrolle und Autorisierung.
Es sollten alle wesentlichen anwendungsabhängigen Kontrollen berücksichtigt werden, d.h. manuelle oder automatische
Kontrollen, die einen direkten Einfluss auf das Prozessergebnis haben. Die Qualität der Kontrollen mit indirektem Einfluss
(z.B. generelle IT-Kontrollen) ist beim Gesamturteil der Prüfung zu beurteilen, wird aber hier nicht weiter erläutert.
Konzentration auf Schlüsselkontrollen
Beschränkt sich der Prüfer nicht auf die zentralen Schlüsselkontrollen, kann dies zu einer breiten und tendenziell ineffizien-
ten Prüfung führen. Weiter sollte auf eine zu detaillierte Beschreibung der erwarteten Kontrollen verzichtet werden, da dies
zu einem erhöhten Folgeaufwand ohne relevanten Zusatznutzen führt.
5 Die Wirksamkeit der Kontrollen wird in den im Kapitel 7 aufgeführten Schritten überprüft.
6 Zu den Aussagen im Abschluss (Assertions) gibt es ebenfalls unterschiedliche Referenzmodelle, z.B. die des Schweizer Handbuchs der Wirtschaftsprüfung,
1998.
18VORGEHENSMODELL ANWENDUNGSPRÜFUNG
Dokumentation von Anwendungskontrollen
Für das Verständnis der Anwendungskontrollen und insbesondere für die spätere Beurteilung des Kontroll-Designs ist eine
angemessene Dokumentation der Kontrollen von grundlegender Bedeutung. Die Dokumentation sollte es dem Prüfer er-
lauben, zu verstehen, welche Business Rules die Kontrolle sicherstellen soll. Darüber hinaus sollte ersichtlich sein, welche
Design-Entscheide im Hinblick auf die Implementierung der Kontrolle zu treffen waren. Letztlich muss nachvollziehbar
sein, welche Parameter oder Customizing-Einstellungen relevant waren, damit die Kontrolle so funktionieren kann, wie die
Business Rule vorschreibt.
Die nachfolgende Tabelle zeigt hierzu zwei Beispiele:
Beschreibung 3-Way Match Funktionentrennung
Business Rule Es werden keine Rechnung bezahlt, Funktionentrennung zwischen Debitoren-
ohne dass Bestellung, Lieferschein und und Kreditorenbuchhaltern. Niemand der
Rechnung in einer wertmässigen Toleranz Rechnungen zahlt, darf neue Lieferanten
von 10% übereinstimmen aufsetzen
Design Referenz auf die 3-way-Match Separate Rollen für Debitoren- und
Funktionalität des ERP Kreditorenbuchhalter und für Stammdaten-
unterhalt.
Dokumentation einer Funktionstrennungs-
Matrix
195 Walk-through
Übersicht
Inhalt und Beim Walk-through werden manuelle oder automatische Schritte des Prozesses resp. der Transaktions
Zielsetzung klasse anhand einer exemplarischen Transaktion durchlaufen und dokumentiert. Er dient der Überprüfung
des erworbenen Verständnisses über den betreffenden Prozess, die enthaltenen Risiken und Kontrollen
und somit auch der Bestätigung der vorhergehenden Analyse.
Die Tiefe resp. der Detaillierungsgrad, mit dem ein Walk-through vorgenommen wird, ist abhängig
davon, ob der Prüfer beabsichtigt, auf das vorhandene Kontrollsystem abzustützen oder nicht.
• Falls der Prüfer beabsichtigt, auf die Kontrollen abzustützen, wird er während dem Walk-through die
einzelne Kontrolle im Hinblick auf ihre Funktionsweise im Detail noch einmal dahingehend analysieren,
ob sie die vorhandenen Risken effektiv abdeckt oder nicht.
• Falls der Prüfer nicht beabsichtigt, auf die Wirksamkeit der Kontrollen abzustellen, wird er sich mit
einem weniger detaillierten Walk-through begnügen. Dieser soll sicherstellen, dass der Prüfer alle
wesentlichen (finanziellen) Risiken versteht, die aus dem Prozess resultieren können. Aufgrund der
identifizierten Risiken wird er in diesem Fall seine ergebnisorientierten Prüfungshandlungen ableiten.
Hintergrund Mit dem Walk-through werden systematisch
• das Verständnis der Abläufe und der Verarbeitung,
• die Konsistenz und die Aussagekraft der vorhandenen Dokumentation und Flussdiagramme,
• die Korrektheit und Vollständigkeit der Informationen über die relevanten Kontrollen und
• das Vorhandensein der relevanten Kontrollen im Tagesablauf verifiziert.
Vorgehen
Bewegungsdaten (Transaktionen)
Pro Transaktionsklasse wird eine Transaktion selektiert. Deren Verarbeitung verfolgt man nun über den gesamten Prozess;
angefangen bei der Initiierung der Transaktion zu ihrer Autorisierung, Aufzeichnung, Verarbeitung und letztendlich zu ihrer
Verbuchung.
Der Prozess / die Transaktionsklasse soll anhand der echten Belege und Schritte in der Anwendung verfolgt werden. Beim
Durchlaufen des Prozesses werden vorhandene Kontrollen verifiziert und die Auswahl der Schlüsselkontrollen hinterfragt.
Das Personal soll beim Walk-through auf sein Verständnis der vorhandenen Arbeitsbeschreibungen und Kontrollvorgaben
befragt werden, insbesondere hinsichtlich Ausnahmen im Prozess oder Fehlerbehebungen.
Fragen, die beim Durchlaufen des Prozesses berücksichtigt werden:
• Wen braucht man zur Erklärung von Details, z.B. aus dem Geschäftsbereich?
• Von wem / woher stammen die vorhandenen Dokumente, Berichte, Flussdiagramme, Screenshots etc.?
• Welche Kontrollaktivität findet zu den jeweiligen Aktivitäten statt?
• Wird die Kontrolle durchgeführt, um einen Fehler zu verhindern oder aufzudecken?
• Wie wird die Kontrolle durchgeführt (automatisiert oder manuell), und wie häufig?
• Ist die automatisierte Kontrolle wirklich implementiert?
• Welche Prüfspur hinterlässt die Kontrolle?
20VORGEHENSMODELL ANWENDUNGSPRÜFUNG
Darstellung der Informationen
Die Dokumentation des Walk-through, bei dem manuelle oder automatische Schritte des Prozesses resp. der Transaktions-
klasse anhand einer exemplarischen Transaktion durchlaufen werden, erfolgt normalerweise anhand von Beschreibungen,
Screenshots, Belegen, Flussdiagrammen etc.
Besonderheiten
In der Praxis wird während dem Walk-through häufig gleichzeitig auch die Beurteilung des Kontroll-Designs und im Falle
von automatischen Kontrollen auch die Beurteilung der Umsetzung der Kontrollen durchgeführt. Diese beiden logisch auf
den Walk-through folgenden Schritte werden im vorliegenden Vorgehensmodell in den beiden folgenden Kapiteln separat
behandelt.
Walk-throughs werden oft in mehrere Teile aufgebrochen. Beim Durchlaufen der Teilprozesse oder einzelnen Anwendungen
gehen daher die Schnittstellen dazwischen häufig vergessen.
216 Beurteilung des Kontroll-Designs
Übersicht
Inhalt und In den vorhergehenden Schritten wurden die wesentlichen Risiken und Schlüsselkontrollen identifiziert
Zielsetzung sowie ein grundlegendes Verständnis des Prozesses erarbeitet und durch den Walk-through verifiziert.
Dabei wurden die Kontrollen einzeln bereits ein erstes Mal auf ihre Eignung untersucht. In der hier
folgenden Beurteilung des Kontroll-Designs (Design Effectiveness) wird das integrale Interne Kontroll
system unter Einbezug der Gesamtheit der wesentlichen Geschäftsprozesse auf seine Eignung
(Abdeckung der Risiken, Vollständigkeit, Aktualität) und Wirtschaftlichkeit (Redundanzen, Überlap-
pungen) untersucht. Das Design der Kontrollen, insbesondere ihre Platzierung im Geschäftsprozess, ist
darauf zu prüfen,
• ob die identifizierten Risiken vollständig erfasst werden,
• ob die festgelegten Kontrollziele mit den Kontrollen tatsächlich erreicht werden können,
• ob mit den Kontrollen die Risiken von Fehlern und Missbräuchen wirksam verringert werden können,
und ob die Risikoabdeckung wirtschaftlich effizient erfolgt,
• oder ob allenfalls eine andere Kontrolle oder Kombination von Kontrollen, insbesondere von überge-
ordneten unternehmensweiten Kontrollen, effizienter zum gleichen Kontrollziel führen.
Ziel muss sein, mit der tiefstmöglichen Zahl von Kontrollen eine adäquate Kontrollqualität zu errei-
chen.
Erst ein vertieftes Verständnis des Kontroll-Designs erlaubt es, eine geeignete Prüfstrategie als Grundlage
für die Beurteilung der Umsetzung der Kontrollen festzulegen.
Hintergrund Eine sorgfältige Analyse der Design Effectiveness bewirkt, dass:
• Lücken, Überschneidungen und Doppelspurigkeiten von Kontrollen entdeckt werden;
• das aufwändige Durchführen der Kontrollen durch die Fachabteilung sowie allenfalls das Testen der
Wirksamkeit (Operating Effectiveness) der Kontrollen durch den Prüfer bei ungeeigneten Kontrollen
vermieden werden kann;
• berücksichtigt wird, dass dasselbe oder gar ein besseres Ergebnis mit der Verwendung oder Adaption
von anderen, beispielsweise bereits etablierten Kontrollen erzielt werden könnte.
Vorgehen
Beurteilung des Kontroll-Designs
Das Interne Kontrollsystem ist dann als wirksam zu beurteilen, wenn die Einhaltung der Kontrollen eine angemessene
Sicherheit erzeugt, dass Fehler oder Missbräuche nicht zu einer wesentlichen Beeinträchtigung des Finanzergebnisses
führen. Um Prüfungsnachweise zu erhalten, dass das Kontrolldesign wesentliche Fehler verhindern bzw. aufdecken und
korrigieren hilft, sind verfahrensorientierte Prüfungshandlungen geeignet. Erst im nächsten Schritt, der ”Beurteilung der
Umsetzung der Kontrollen”, soll dann der Nachweis erbracht werden, dass das Kontroll-Design über die nowendige Prüf-
periode wirksam war.7.
7 PS 400 “Risikobeurteilung und interne Kontrolle” RZ 27.
22VORGEHENSMODELL ANWENDUNGSPRÜFUNG
Prüfungshandlungen
Prüfungshandlungen zur Beurteilung des Kontroll-Designs umfassen Befragungen, Beobachtungen, Walk-throughs, Einsicht
in die wesentliche Dokumentation und die Beurteilung von spezifischen Kontrollen auf ihre Eignung. Der Prüfer bildet sich
ein Urteil über das Kontrolldesign, indem er:
• Befragungen von Mitgliedern der Unternehmensleitung sowie von Mitarbeitern mit Überwachungsaufgaben vornimmt;
• Einsicht in Belege über Transaktionen und weitere wichtige Dokumente der Unternehmung nimmt;
• die Ausübung spezifischer Tätigkeiten und Kontrollen beobachtet;
• vereinzelt Transaktionen durch das Informationssystem verfolgt (Walk-through).
Die Prüfungshandlungen zur Beurteilung der Design Effectiveness sind gemäss den gültigen Prüfungsstandards durch Nach-
weise zu dokumentieren.
Fragestellungen zur Beurteilung des Kontroll-Designs
Durch die Beantwortung einiger typischer Fragen lassen sich gemeinsam mit dem geprüften Bereich, teilweise auch in Form
eines iterativen Prozesses, wesentliche Mängel am Kontrolldesign aufdecken8.
• Sind die Prozessschritte und die zugehörigen Kontrollen in einer logisch sinnvollen Reihenfolge gegliedert?
• Ist die Verantwortung für die Durchführung der Kontrollen eindeutig festgelegt?
• Können die Kontrollen korrekt und sinnvoll durchgeführt werden?
• Werden wo möglich automatische Kontrollen anstelle von hybriden oder rein manuellen Kontrollen eingesetzt?
• Werden wo möglich vorgelagerte, d.h. präventive, Kontrollen anstatt von nachgelagerten, d.h. detektiven, Kontrollen
eingesetzt?
• Stimmen die Kontrollen mit Anforderungen aus Richtlinien und Verfahrensanweisungen überein?
• Stehen die notwendigen Inputs für die Durchführung der Kontrolle zur Verfügung?
• Ermöglicht der Ablauf des Prozesses bzw. der Kontrolle das Erstellen eines nachvollziehbaren Kontrollbelegs?
• Werden die Kontrollen durch einen geeigneten, qualifizierten und instruierten Bearbeiter ausgeführt?
• Werden die Kontrollen innerhalb einer zweckmässigen Frist und mit einer geeigneten Häufigkeit ausgeführt?
• Kann das Kontroll-Design innerhalb der organisatorischen und finanziellen Restriktionen überhaupt umgesetzt werden?
• Zur Beurteilung der einzelnen Kontrollen kann ein Portfolioansatz angewendet werden, indem die Kontrollen bezüglich
Automatisierungsgrad (manuell, halbautomatisch, automatisch), Wirkungsrichtung (präventiv, detektiv), Kontrollfrequenz
und Risikoabdeckung beurteilt werden.
• Bezüglich Automatisierungsgrad sind automatische Kontrollen erfassungsgemäss gegenüber manuellen Kontrollen effizi-
enter, obwohl damit ein einmaliger Implementierungsaufwand verbunden ist. Zudem bleibt die Wirksamkeit stabil, sofern
keine wesentlichen Änderungen vorgenommen werden.
• Gemäss verbreiteter Auffassung sind präventive Kontrollen hinsichtlich der Sicherstellung des Kontrollziels wirksamer als
die nachgelagerte Fehleraufdeckung durch eine detektive Kontrolle.
• Eine höhere Kontrollfrequenz führt bei manuellen und halbautomatischen Kontrollen in der Regel zu höheren Kosten und
einem hohen Zeitaufwand verglichen mit automatischen Kontrollen, bei denen die Frequenz der Kontrolldurchführung
kaum Einfluss auf die betrieblichen Kosten hat. Eine geringe Kontrollfrequenz hingegen kann die Wirksamkeit einer
manuellen oder halbautomatischen Kontrolle beeinträchtigen.
• Eine Kontrolle, welche mehrere Kontrollziele bzw. verschiedene Risiken abdeckt, wird grundsätzlich als wirksamer und
sicherer sowie auch als wirtschaftlicher beurteilt als eine Kontrolle, welche lediglich auf ein einziges Risiko abzielt.
8 Menzies 2006, S. 271f.
23Technische Fragestellungen zur Beurteilung des Kontroll-Designs
Zur Beurteilung des Kontroll-Designs von Anwendungskontrollen wird der Prüfer auch vertieft die technischen Vorausset-
zungen abklären, die gegeben sein müssen, damit die Kontrolle wie gewünscht funktionieren kann. Der Prüfer wird sich
unter anderem die folgenden Fragen stellen:
• Kann die Kontrolle umgangen oder übersteuert werden (Quernavigation, Super-User)?
• Wie hängt die Kontrolle vom Customizing, also der spezifischen Anpassung der Anwendung an das Unternehmen, ab?
• Wie hängt die Kontrolle von der konkreten Implementierung des Zugriffsschutzsystems ab?
• Welche Kombination von Berechtigungen würde eine Umgehung der Kontrolle ermöglichen?
• Welche Stammdaten und Parameter sind relevant, damit die Kontrollen im gewünschten Sinn funktioniert?
• Wer verifiziert die Stammdaten?
• Kann das Funktionieren der Kontrolle zwecks späterer Überprüfung aufgezeichnet werden (logging)?
Besonderheiten
Optimierungspotential
Zur Wahrung der Wirtschaftlichkeit des Kontrollsystems muss die Frage beantwortet werden, ob die definierten Kontrollen
tatsächlich notwendig sind und ob sie nicht mit anderen Prozesskontrollen oder Entity-Level Kontrollen überlappen oder gar
redundant ausgelegt sind. Erhebliches Sparpotenzial verbunden mit hoher Urteilssicherheit bieten einerseits vorgelagerte,
d.h. präventive, und andererseits automatisierte Kontrollen.
Zur Identifikation des Verbesserungspotentials des Kontrolldesigns sollten vor allem das Wissen und die vorhandenen
Erkenntnisse aus dem jeweiligen Unternehmensbereich sowie die Einschätzung von Management und Mitarbeitenden
genutzt werden. Neben bereits bekannten Schwachstellen bietet vor allem die Analyse von unternehmensweiten Kontrollen
(Entity Level Controls9) einen wirksamen Hebel zur Verbesserung des Kontroll-Designs. Aufgrund ihrer prozessübergreifen-
den Wirkung bieten diese das Potential, einzelne Kontrollen im Prozess zu unterstützen, zu ergänzen oder gar zu ersetzen.
Häufig werden unter dem massiven Zeitdruck beim Aufbau von internen Kontrollsystemen Kontrollziele redundant sowohl
durch Prozesskontrollen und durch Entity Level-Kontrollen erreicht. Zu prüfen ist allerdings, ob die Entity-Level-Kontrollen
vergleichbar zeitnah ausgelöst werden und nicht allenfalls entscheidende Zeit verloren geht. Weitere Redundanzen und
Überlappungen können beim Abgleichen der Kontroll-Designs von Unterstützungs- und von Kernprozessen aufgedeckt
werden.
Unwirksame Schlüsselkontrollen
Stösst der Prüfer bei seiner Beurteilung des Kontroll-Designs auf Schlüsselkontrollen, die er als unwirksam einstuft, entsteht
eine Lücke im detailliert zu prüfenden Kontrollsystem. Um diese zu schliessen, muss er andere Schlüsselkontrollen resp.
kompensierenden Kontrollen identifizieren und hinsichtlich deren Wirksamkeit beurteilen. Hierbei sollte der Prüfer aber
immer die gesamte Auswahl an Schlüsselkontrollen im Blick behalten, um zu verhindern, dass kostspielige Redundanzen
entstehen.
9 Entity Level Controls wie die Generellen IT-Kontrollen sind Kontrollen mit unternehmens- oder konzernweiter Wirkung und sind üblicherweise in den COSO
Dimensionen Kontrollumfeld, Risikobeurteilung, Informations- und Kommunikationssystem sowie Überwachung angesiedelt. Dabei handelt es sich um
unternehmensweite Richtlinien und Verfahrensanweisungen mit erheblicher Wirkung auf die Ordnungsmässigkeit der Geschäftstätigkeit bezüglich Strate-
gie, Ziele oder Kulturaspekte. Im Gegensatz zu Prozesskontrollen haben Entity Level Controls (in der Regel) eine abstrakte, dafür breit angelegte Wirkung.
[Menzies 2006, S. 21].
24Sie können auch lesen
