audyt systemów informatycznych

23 listopada
2009

AUDYT SYSTEMÓW INFORMATYCZNYCH

Mariusz Zarzycki, mariusz_zarzycki@wsinf.edu.pl

Proces audytu systemów informatycznych

Zarządzanie złożonością problemu

Prowadzenie audytu systemów informatycznych jest procesem bardzo złożonym.

Poczynając od planowania badania, poprzez zebranie wystarczających dowodów, tworzenie

bieżąco dokumentacji audytowej, a kończąc na przekazaniu rekomendacji w raporcie

końcowym, audytor podejmuje profesjonalne osądy. Aby podejmowane przez niego decyzje

były trafne, konieczne jest zrozumienie kompleksowości badanego systemu, poziomu

istotności z punktu widzenia celów audytowych oraz uwzględnienia odpowiednich typów

ryzyka.

Pierwszym krokiem w zrozumieniu kompleksowości systemu

jest jego podział na

podsystemy(moduły). Podsystem należy rozumieć jako logiczny komponent głównego

systemu, który wykonuje określone funkcje na rzecz systemu głównego. Proces

dekompozycji systemu w podsystemy nazywany jest faktoryzacją(ang. factoring).

Faktoryzacja jest procesem, który kończy się w momencie uzyskania podsystemów

wystarczająco szczegółowych tak, aby mogły odrębnie zostać poddane badaniu. Istnieje wiele

metod wykorzystywanych podczas faktoryzacji systemu poddawanego badaniu. W ujęciu

ogólnym podział dokonywany jest w oparciu o strukturę organizacyjną przedsiębiorstwa(ang.

managerial functions). Poszczególne podsystemy uzyskiwane w wyniku dekompozycji,

korespondują z hierarchią organizacji wykorzystywaną podczas zarządzania technologią

informatyczną(tabela 1).

W ujęciu szczegółowym uwzględnia się elementy systemu poddawanego badaniu,

klasyfikując je ze względu na realizowane przez niego funkcje. Można zatem wyróżnić

podsystemy poprzez elementy brzegowe, wejściowe, komunikacyjne, przetwarzające itd.

Charakterystykę poszczególnych podsystemów w ujęciu szczegółowym prezentuje tabela 2.

Szczególnie w przypadku zintegrowanych systemów informatycznych.

23 listopada
2009

AUDYT SYSTEMÓW INFORMATYCZNYCH

Mariusz Zarzycki, mariusz_zarzycki@wsinf.edu.pl

Tabela 1. Główne rodzaje podsystemów w oparciu o strukturę organizacyjną

Podsystem zarządzania.

Charakterystyka podsystemu.

Zarząd

(ang. Top Management)

Zarząd musi zapewnić, aby systemy informacyjne były poprawnie

zarządzane. Jest on odpowiedzialny przede wszystkim za

długoterminowe decyzje dotyczące tego, jak systemy informacyjne

będą wykorzystane w organizacji.

Zarządzanie systemami

informacyjnymi

(ang. Information systems

management)

Rozumiane jako ogólna odpowiedzialność za planowanie i kontrolę

wszelkich czynności wykonywanych przez system informacyjny. W

praktyce przekłada się na dekompozycję długofalowych planów

zarządu na krótkoterminowe cele do realizacji.

Zarządzanie rozwojem

systemów

(ang. Systems development

management)

Rozumiane jako odpowiedzialność za projektowanie, implementację i

utrzymanie systemów informatycznych.

Zarządzanie programowaniem

(ang. Programming

management)

Rozumiane jako odpowiedzialność za programowanie nowych

systemów, utrzymanie starych oraz ogólne wsparcie programowe.

Administrowanie danymi

(ang. Data administration)

Planowanie i kontrola aspektów związanych z kontrolą danych.

Zarządzanie zapewnieniem

jakości

(ang. Quality assurance

management)

Zapewnienie odpowiednio wysokich standardów w stosunku do

rozwoju, implementacji, przetwarzania i utrzymania systemów.

Zarządzanie bezpieczeństwem

(ang. Security administration)

Kontrola dostępu i fizyczne bezpieczeństwo związane z informacyjną

funkcją systemu.

Zarządzanie operacjami

(ang. Operations management)

Rozumiane jako odpowiedzialność za planowanie i kontrolę

codziennych operacji zachodzących w systemach.

Źródło: Opracowanie własne na podstawie Weber R., Information Systems Control and Audit, Prentice Hall, NJ
1999, s. 39.

W następnej kolejności, audytor zmuszony jest zidentyfikować wszystkie zdarzenia

zachodzące w danym podsystemie. Szczególną uwagę należy zwrócić na zdarzenia

niecelowe, którym podczas badania należy dokładnie się przyjrzeć. W celu identyfikacji tych

zdarzeń, należy w przypadku:



ujęcia ogólnego – podjąć decyzję co do określonych funkcji, jakie powinny być

realizowane w ramach danego podsystemu;



ujęcia szczegółowego – dokładnie zapoznać się z przebiegiem transakcji; często

wykorzystywane są tutaj „walk-through techniques”, które identyfikują elementarne

składniki podsystemu, biorące udział w przetwarzaniu transakcji z jednoczesnym,

dogłębnym zrozumieniem procesów zachodzących w danym elemencie podsystemu.

Po dokonaniu wystarczająco szczegółowej faktoryzacji, audytor musi dokonać oceny

istotności

. Sprowadza się to do ustalenia, co z punktu widzenia celów audytowych jest

istotne, a co nie. Ocena istotności umożliwia określenie priorytetów prac i zwiększenie

efektywności audytu. Obejmuje ona rozważenie wywieranego na organizację wpływu

Różnica w określania istotności w zależności od rodzaju audytu została zasygnalizowana w rozdziale drugim.

23 listopada
2009

AUDYT SYSTEMÓW INFORMATYCZNYCH

Mariusz Zarzycki, mariusz_zarzycki@wsinf.edu.pl

błędów, zaniedbań, nieprawidłowości lub czynów niedozwolonych, które mogą wyniknąć ze

słabości kontroli w audytowanym obszarze

Tabela 2. Elementy, wedle których identyfikuje się podsystemy w ujęciu szczegółowym

Rodzaj elementu.

Charakterystyka podsystemu.

Elementy brzegowe(ang. Boundary)

Podsystem zawierający komponenty, które stanowią interfejs

pomiędzy użytkownikiem a systemem.

Elementy wejściowe(ang. Input)

Podsystem zawierający komponenty, które biorą udział w

przygotowywaniu, wprowadzaniu komend i danych do systemu.

Elementy komunikacyjne(ang.

Communications)

Podsystem zawierający komponenty, które transmitują dane

pomiędzy podsystemem a systemem głównym.

Elementy przetwarzające(ang.

Processing)

Podsystem zawierający komponenty wykorzystywane do
podejmowania decyzji, obliczeń, klasyfikacji, zamówień,

podsumowań danych w systemie.

Baza danych(ang. Database)

Podsystem zawierający komponenty, które definiują, dodają,

udzielają dostępu, modyfikują i kasują dane z systemu.

Elementy wyjściowe(ang. Output)

Podsystem zawierający komponenty, które odbierają oraz

prezentują dane użytkownikom systemu.

Źródło: Opracowanie własne na podstawie Weber R., Information Systems Control and Audit, Prentice Hall, NJ
1999, s. 39-40.

Podczas oceny istotności należy rozważyć



możliwy do zaakceptowania przez kierownictwo, audytora i odpowiednie organy

nadzorcze poziom błędów,



zdolność do kumulowania się małych błędów i słabości(tworzenie tzw. efektu

kumulatywnego).

Planując prace audytowe należy określić cele kontrolne i opierając się na istotności

ustalić, które mechanizmy kontrolne powinny być poddane badaniu.

W przypadku audytu informatycznego(choć nie tylko) mamy do czynienia z dwoma

rodzajami ryzyka. Pierwsze z nich(ryzyko w ujęciu ogólnym) skojarzone jest z audytowanym

obszarem i zostało omówione wcześniej. Drugi rodzaj ryzyka skojarzony jest z możliwością

fałszywego wyciągnięcia wniosków na skutek subiektywnego osądu, jakiego w badaniu

dokonuje audytor. Ten drugi rodzaj ryzyka nazywany jest ryzykiem audytu, na który składają

się elementy zaprezentowane na poniższym rysunku.

Forystek M., op.cit., s. 192.

23 listopada
2009

AUDYT SYSTEMÓW INFORMATYCZNYCH

Mariusz Zarzycki, mariusz_zarzycki@wsinf.edu.pl

Rysunek 1. Elementy wchodzące w skład modelu ryzyka audytu.

Ryzyko

audytu

(ang.
audit

risk)

Ryzyko

nieodłączne(wewnętrzne)

(ang. inherent risk)

Prawdopodobieństwo

wystąpienia strat

materialnych lub oszustw

wewnątrz środowiska

organizacji.

Ryzyko kontroli

(ang. control risk)

Prawdopodobieństwo, że

system kontroli

wewnętrznej nie wykryje

na czas błędów.

Ryzyko niewykrycia,

(przeoczenia)

(ang. detection risk)

Prawdopodobieństwo, że

zastosowane procedury

audytowe nie ujawnią

błędu, który może mieć

istotny wpływ na

analizowany obszar.

Źródło: Opracowanie własne na podstawie Hunton J.E., Bryant S.M., Bagranoff N.A., Core Concepts of
Information Technology Auditing, Wiley, 2004, s. 49.

M. Forystek

przedstawia definicję ryzyka nieodłącznego, stwierdzając, iż jest to podatność

na wystąpienie istotnego błędu, który sam lub w połączeniu z innymi błędami będzie miał

istotny wpływ na analizowany obszar, przy braku mechanizmów kontrolnych. Podczas

rozważania ryzyka nieodłącznego należy wziąć, według autora, pod uwagę następujące

kwestie:



wyniki oraz daty poprzednich audytów w danym obszarze,



poziom skomplikowania systemów,



podatność na utratę lub sprzeniewierzenie aktywów kontrolowanych przez system,



sytuacje, różniące się od codziennych działań, związanych z przetwarzaniem

danych(np. użycie systemów operacyjnych do wprowadzania zmian do danych).

Oceniając ryzyko nieodłączne, audytorzy biorą pod uwagę czynniki widoczne w najbliższym

otoczeniu danej organizacji, tj. branży, rodzaju zarządzania. Dla poszczególnych segmentów

uwzględniane mogą być analizy systemów rachunkowości, systemów strategicznych,

systemów, w których zachodzą krytyczne operacje czy najbardziej zaawansowanych

technologicznie systemów

Oceniając ryzyko kontroli związane z danym segmentem audytu, poddaje się pod

rozwagę wiarygodność oraz skuteczność mechanizmów kontrolnych występujących zarówno

po stronie systemów zarządzania, jak i programów komputerowych

. Dopóki odpowiednie

mechanizmy kontrolne nie zostaną jednoznacznie zidentyfikowane jako efektywne, ryzyko

kontroli należy traktować jako wysokie. Wysoki poziom ryzyka wewnętrznego oraz ryzyka

kontroli narzuca audytorowi konieczność zgromadzenia odpowiedniej ilości dowodów

audytowych.

Forystek M., op.cit., s. 194.

Porównaj tabela – Weber R., Information Systems Control and Audit, Prentice Hall, NJ 1999, s. 44.

Analogia do przeprowadzanej wcześniej faktoryzacji.

23 listopada
2009

AUDYT SYSTEMÓW INFORMATYCZNYCH

Mariusz Zarzycki, mariusz_zarzycki@wsinf.edu.pl

Ryzyko niewykrycia jest odwrotnie proporcjonalne do wypadkowej ryzyka

nieodłącznego i ryzyka kontroli. Na przykład, jeżeli poziom ryzyka nieodłącznego i ryzyka

kontroli jest wysoki, to aby ograniczyć ryzyko badania do akceptowalnego, niskiego

poziomu, poziom akceptowalnego ryzyka przeoczenia powinien być niski.

Etapy procesu audytowego

W literaturze przedmiotu można spotkać się z wieloma podejściami dotyczącymi

stricte procesu audytowego. Stowarzyszenie do Spraw Audytu i Kontroli Systemów

Informatycznych ISACA

proponuje uwzględnić w procesie audytu informatycznego cztery

główne kroki, w skład których wchodzą między innymi następujące zadania do wykonania:



szacowanie ryzyka i wstępne planowanie audytu,



zapoznanie się z audytowanym obszarem(zrozumienie natury procesów i ryzyka

poprzez wywiady i pozyskanie odpowiednich dokumentów),



szczegółowe planowanie audytu,



przeprowadzenie szczegółowych prac audytowych,



ocena zaplanowanych, przewidzianych mechanizmów kontrolnych pod kątem ich

adekwatności w stosunku do potrzeb,



ocena zgodności zastanej praktyki z planami i przewidywaniami,



przygotowanie i prezentacja raportu.

J.E Hunton, S.M. Bryant, N.A. Bagranoff

wymieniają w procesie audytowym takie

kroki, jak: planowanie, szacowanie ryzyka, przygotowanie programu audytowego, zbieranie

dowodów, formułowanie konkluzji oraz dostarczanie opinii poaudytowej. Weber R.

analogicznie, traktuje, proces audytowy jako sekwencję konkretnych kroków do

wykonania(patrz schemat blokowy przedstawiony na rysunku 2)

ISACA Audit Guidelines [cit. 2005-12-10], http://www.isaca.org.

Hunton J.E, Bryant S.M., Bagranoff N.A., op.cit., s. 209.

Weber.R., op.cit., s. 48.

Niektóre z elementów dotycząc stricte audytu finansowego, np. ograniczone testy dowodowe.

23 listopada
2009

AUDYT SYSTEMÓW INFORMATYCZNYCH

Mariusz Zarzycki, mariusz_zarzycki@wsinf.edu.pl

Rysunek 2. Schemat blokowy reprezentujący proces audytowy według Webera

Źródło: Opracowanie własne na podstawie Weber R., Information Systems Control and Audit, Prentice
Hall, NJ 1999, s. 48.

W ogólnym uproszczeniu audyt można traktować jako proces składający się z poniższych

etapów:



przygotowania do badania, które uwzględnia w sobie m.in. planowanie badania oraz

opracowanie programu audytowego,



przeprowadzanie badania, uwzględniającego m.in. wszelkiego rodzaju testy

mechanizmów kontrolnych,



przedstawienie raportu końcowego z wykonanej pracy.

23 listopada
2009

AUDYT SYSTEMÓW INFORMATYCZNYCH

Mariusz Zarzycki, mariusz_zarzycki@wsinf.edu.pl

2.1. Przygotowanie do badania

Standardy audytowania systemów informatycznych ISACA

, opisane wcześniej,

stanowią, iż audytor systemów informatycznych ma za zadanie opracować plan pracy audytu

systemów informatycznych w sposób zapewniający realizację celów audytu przy zachowaniu

zgodności z ogólnie panującymi standardami audytowania. W standardzie 050.010.020

dokładnie precyzuje się fazę planowania jako zadanie składające się z :



ustanowienia zakresu i celów badania z punktu widzenia pracy audytora,



wykonania wstępnego oszacowania mechanizmów kontrolnych pod kątem

zastosowania w procesach poddawanych audytowi,



zrozumienia organizacji, tj, zgromadzenia wiedzy na temat środowiska operacyjnego,

w tym finansowego organizacji, wszelkich rodzajów ryzyka wewnętrznego,

specyficznego dla danej branży,



zidentyfikowania zakresu zależności badanej organizacji od usług realizowanych

przez firmy zewnętrzne,



opracowania programu audytowego zawierającego wykaz specyficznych procedur,

które audytor będzie stosował w trakcie przeprowadzania badania,



opracowania i przedstawienia planu audytu wraz z wszelkimi niezbędnymi

materiałami wykorzystywanymi do ich opracowania.

Ze względu na fakt, iż w większości przypadków podczas rozpoczynania audytu

wiedza na temat poddawanego badaniu obszaru jest niepełna, zgromadzenie odpowiednich

informacji o organizacji, procedurach, regulaminach, ustawach, rozporządzeniach, procesach

oraz pracownikach, wykonujących określone zadania, jest niezbędna

. Główne źródła

pozyskiwania informacji można podzielić na



źródła pochodzące z audytowanego obszaru, tj. prezentacje własne jednostek,

schematy procesów, systemy samooceny, przegląd katalogów istniejących

ISACA Audit Guidelines, http://www.isaca.org. Standard 050.010„Planowanie Audytu”. Porównaj również

J.E Hunton, S.M. Bryant, N.A. Bagranoff, op.cit., s. 208.

Rodzaj oraz ilość zdobywanej wiedzy o organizacji uzależniony jest również od faktu, czy badanie

wykonywane jest przez audytorów zewnętrznych czy wewnętrznych. Różnice opisane są szczegółowo przez
Webera – Weber R., op.cit., s. 47. Porównaj również z National State Auditors Association and the U. S. General
Accounting Office A Joint Initiative, Management Planning Guide for Information Systems Security Auditing,
Grudzień 2001.

Nisbet A., Metodologia przeprowadzania audytu Citigroup, Materiały konferencyjne „IIA/ISACA

Konferencja 2000” http://www.isaca.org.pl, Grudzień 2000.

23 listopada
2009

AUDYT SYSTEMÓW INFORMATYCZNYCH

Mariusz Zarzycki, mariusz_zarzycki@wsinf.edu.pl

problemów, wskaźniki jakości i wydajności, kluczowe trendy operacyjne i finansowe,

protokoły ze spotkań kierownictwa,



źródła pochodzące z działalności audytowej, tj. wyniki śledzenia procesu, notatki z

monitorowania działalności, problemy znajdujące się pod ścisłą obserwacją członków

zarządu, raporty dotyczące odstępstw od standardów, śledzenie wykonywanych

działań korekcyjnych, materiały robocze z poprzednich audytów, wyniki innych

audytów,



źródła zewnętrzne, tj. sprawozdania władz nadrzędnych, biuletyny informacyjne,

czasopisma.

Rysunek 3 przedstawia sekwencję zdarzeń, jaką ISACA zaleca, określając ogólne podejście

do procesu audytowego(etapu planowania).

Rysunek 3. Sekwencje zdarzeń podczas planowania audytu

Źródło: Opracowanie własne na podstawie ISACA Audit Guidelines, http://www.isaca.org [cit. 2005-10-
20] , s. 219.

Audytor gromadząc potrzebną wiedzę na temat organizacji, w celu opracowania planu

i programu audytu, poza zidentyfikowaniem podstawowego ryzyka oraz mechanizmów

kontrolnych, określa procesy i zasoby informatyczne podlegające audytowi. Kwestia

zdobywanej wiedzy uzależniona jest od charakterystyki badanej organizacji, jednakże przy

założeniu badania ZSI musi ona być bardzo obszerna i szczegółowa. Kompleksowość ZSI

wymaga od audytora zrozumienia wszelkich zdarzeń, operacji, transakcji zachodzących w

systemie i mogących mieć wpływ na przedmiot audytu. Jak widać na rysunku 3, w celu

zaobserwowania ustalonych procedur w organizacji stosuje się między innymi wstępne

wywiady mające na celu ustalenie osób kontaktowych, pomocnych podczas zbierania

23 listopada
2009

AUDYT SYSTEMÓW INFORMATYCZNYCH

Mariusz Zarzycki, mariusz_zarzycki@wsinf.edu.pl

dowodów audytowych. Gromadzenie dowodów może się również odbywać przy

zastosowaniu wszelkiego rodzaju kontrolnych kwestionariuszy, tzw. list kontrolnych

Dokumentami wyjściowymi, powstałymi w procesie planowania oraz będącymi

odpowiedzią na zlecenie audytu, są



zawiadomienie o audycie – przed rozpoczęciem audytu należy przygotować stosowne

pismo do osób odpowiedzialnych za obszary, które mają być poddane audytowi;

pismo powinno zawierać powołanie się na regulację umocowującą audyt, cel audytu,

zakres audytu, badany okres czasu, dane o personelu audytowym, daty rozpoczęcia i

zakończenia audytu, szczególne wymagania dotyczące prowadzenia audytu; w ramach

szczegółowych wymagań zawrzeć można prośbę o przesłanie lub wskazanie miejsca

przechowywania aktualnych wersji regulacji obejmujących badany obszar(schemat

organizacyjny, regulaminy, procedury),



szczegółowy plan audytu – w formie papierowej lub elektronicznej, zawiera listę prac

do wykonania, listę osób i innych zasobów wymaganych do wykonania prac,

harmonogram pracy i budżet,



formularze realizacji audytu,



program audytowy – określa krok po kroku zadania do wykonania, niezbędne dla

osiągnięcia celów audytu; powinien posiadać formę, która pozwala na określenie

pracy już wykonanej oraz pozostałej do wykonania(np. arkusz Microsoft Project) i

najczęściej występuje w postaci tabeli zawierającej numer referencyjny, zagrożenia,

cele/mechanizmy kontrolne, sposoby testowania, uwagi; program audytowy należy

modyfikować zgodnie z postępem w wykonywanych pracach audytowych,



wypełnione kwestionariusze,

Na podstawie Hunton J.E., Bryant S.M., Bagranoff N.A., op.cit., s. 63 oraz ISACA Audit Guidelines,

http://www.isaca.org  [cit.2005-09-12],  s.  219.  Narzędzie  w  postaci  kwestionariusza  umożliwia  audytorowi
zadawanie pytań dotyczących wewnętrznych mechanizmów kontrolnych stosownych do eliminowania zagrożeń
w aplikacjach, procesach oraz pytań ułatwiających identyfikację ryzyka związanego z dokonywaniem zmian w
organizacji  oraz  chociażby,  z  logicznym  dostępem  do  danych.  Przykładami  pytań  spotykanych  w
kwestionariuszach są: 1) Czy, aby dokonać zmiany w organizacji, potrzebna jest odpowiednia autoryzacja? 2)
Kto wykonuje zadania objęte danym celem kontrolnym? 3) Gdzie i kiedy wykonywane są określone operacje? 4)
Na  podstawie  jakich  danych  wejściowych    wykonywane  są  zadania?  5)  Jakie  są  rezultaty  działań?  6)  Czy  są
ustalone  określone  procedury  dotyczące  wykonywania  danej  operacji?.  Do  głównych  zalet  kwestionariuszy
można zaliczyć:



uwzględnienie konkretnych mechanizmów kontrolnych podczas określania ryzyka,



możliwość uzyskania pełniejszej informacji, poprzez porównanie różnych wersji udzielonych
odpowiedzi.

Kwestionariusze są również często stosowane podczas opracowywania diagramów odzwierciedlających
zachodzące operacje w badanej organizacji.

Na podstawie Forystek M., op.cit., s. 200-202, ISACA Audit Guidelines [cit.2005-10-23]

http://www.isaca.org, s. 219-220 oraz Hunton J.E., Bryant S.M., Bagranoff N.A., op.cit., s. 208-210.

23 listopada
2009

AUDYT SYSTEMÓW INFORMATYCZNYCH

Mariusz Zarzycki, mariusz_zarzycki@wsinf.edu.pl



dokumentacja badanego obszaru(regulaminy, procedury, schematy przepływów).

W chwili osiągnięcia przez audytora wystarczającej wiedzy związanej z występującym w

organizacji czy w ZSI ryzykiem oraz mechanizmami kontrolnymi, następuje przejście do

drugiej fazy procesu audytowego. Etap ten – przeprowadzanie audytu - przedstawia się jako

ocenę wykrytych podczas planowania regulacji, kryteriów, ich efektywności oraz

skuteczności. Ocenie poddaje się również spójność stosowanej struktury kontrolni

wewnętrznej.

2.2. Przeprowadzanie badania

Standardowa procedura przeprowadzania badania składa się z czterech etapów: oceny

mechanizmów kontrolnych, oceny zgodności, dowodzenia ryzyka oraz określania osiągania

celów. Celem pierwszego etapu, tj. oceny mechanizmów kontrolnych, jest oszacowanie

mechanizmów kontrolnych pod kątem ich skuteczności i sprawności

. Oceny dokonuje się

poprzez weryfikację i analizę określonych regulaminów oraz procedur skorelowanych z

wymaganiami uznanymi powszechnie za wzorcowe. Ocena mechanizmów kontrolnych

przedstawiona jest na rysunku 46. Oceniając skuteczność mechanizmów kontrolnych należy

przyjąć za kryterium ich adekwatność do potrzeb i warunków, w jakich działa organizacja.

W zależności od skuteczności stosowanych przez organizację procedur kontrolnych,

następnym krokiem podczas przeprowadzania badania jest ocena zgodności(ang. compliance

testing), przedstawiona na rysunku 5, bądź wykonanie wzmocnionych, dodatkowych testów

dowodowych(ang. significant substantive testing).

Fragmenty rozdziału opracowano w znacznym stopniu na podstawie: ISACA Audit Guidelines [cit. 2005-11-

04], http://www.isaca.org, s. 219-221 oraz Forystek M. op.cit., s. 202-207.

Skuteczne i sprawne mechanizmy kontrolne to takie, które są efektywne kosztowo i dostarczają racjonalnego

zapewnienia, że cele kontrolne będą zrealizowane.

23 listopada
2009

AUDYT SYSTEMÓW INFORMATYCZNYCH

Mariusz Zarzycki, mariusz_zarzycki@wsinf.edu.pl

Rysunek 4. Sekwencje zdarzeń podczas oceny mechanizmów kontrolnych

Źródło: Opracowanie własne na podstawie ISACA Audit Guidelines [cit. 205-10-25],
http://www.isaca.org, s. 220.

Celem pierwszej z możliwości jest ustalenie, czy zachodzi zgodność pomiędzy

ustalonymi mechanizmami kontrolnymi, a faktycznymi działaniami wynikającymi z procedur

formalnych i nieformalnych. W trakcie ustaleń sprawdza się, czy rzeczywiste procedury i

kompensacyjne mechanizmy kontrolne są skorelowane z procedurami ustalonymi w

pierwszym etapie audytu

oraz czy działania w nich określone wykonywane są w

usystematyzowany i ścisły sposób. Testowanie zgodności przedstawiono na rysunku 5.

Rysunek 5. Sekwencje zdarzeń podczas testowania zgodności

Źródło: Opracowanie własne na podstawie ISACA Audit Guidelines [cit. 2006-12-10,]
http://www.isaca.org , s. 220.

Przykładem próby dokonania oceny mechanizmów kontrolnych podczas audytu bezpieczeństwa sieci

teleinformatycznej  jest  weryfikacja,  czy  istnieje  wykaz  odpowiednich  reguł  dotyczących  ruchu  sieciowego,
uwzględniającego  filtrowanie  odpowiednich  portów,  aplikacji,  protokołów  itd.  Przykładem  firewall’a
realizującego  wszystkie  wymienione  aspekty  jest  Microsoft  ISA  Server  2004.  Weryfikacja  ta  musi  określić
również osoby mogące dokonywać modyfikacji w konfiguracji ściany ogniowej.

Jest to bardzo istotny element, że badanie przeprowadza się w stosunku do ustanowionych mechanizmów

kontrolnych. Nie uwzględnia się mechanizmów kontrolnych, które powinny istnieć, a nie są stosowane w
organizacji.

23 listopada
2009

AUDYT SYSTEMÓW INFORMATYCZNYCH

Mariusz Zarzycki, mariusz_zarzycki@wsinf.edu.pl

Konkluzję testowania zgodności stanowi dokumentacja, ustosunkowująca się do

poprawności i konsekwencji w stosowaniu ustalonych procedur mechanizmów kontrolnych

przez badaną organizację. Bazując na ustalonym poziomie istotności audytor określa poziom

stosownych, dodatkowych testów dowodowych, niezbędnych do uzyskania zapewnienia, że

proces kontroli jest adekwatny do potrzeb organizacji.

Celem wykonywania dodatkowych testów jest dostarczenie ostatecznego zapewnienia,

że mechanizmy kontrolne wspierają lub nie osiąganie celów gospodarczych

. Aby uzyskać

potrzebne dowody należy zastosować odpowiednie metody analityczne umożliwiające

między innymi selekcję materiałów źródłowych w poszukiwaniu dowodów wzrostu ryzyka

spowodowanego niewłaściwym funkcjonowaniem systemu kontroli

. Dodatkowe testy

przeprowadza się, gdy:



wykryto całkowity brak odpowiednich mechanizmów kontrolnych,



istniejące mechanizmy kontrolne uznane zostały za niewystarczające,



testy zgodności pokazują, iż mechanizmy kontrolne nie zostały odpowiednio

wdrożone.

Schemat blokowy przedstawiony na rysunku 6 prezentuje poszczególne kroki podczas

udowadniania ryzyka.

Udowadnianie ryzyka jest ostatnią fazą operacyjną w ramach etapu przeprowadzania

badania. Po jej zakończenia audytor analizuje zebrane dowody w celu przedstawienia

wniosków na temat skuteczności i efektywności istniejącego w organizacji systemu kontroli.

Forystek M., op.cit., s. 205. W wielu przypadkach pierwsze etapy audytu wykazują, że badany system kontroli

ma  słabości,  tzn.  że  stosowane  mechanizmy  kontrolne  są  niewystarczające  lub,  że  ustanowione  mechanizmy
kontrolne  w  praktyce  nie  działają  lub  że  działają  wadliwie.  Pierwsza  wada  systemu  kontroli  powinna  zostać
wykryta  w  trakcie  I  etapu  badania  –  oceny  mechanizmów  kontrolnych,  drugi  z  mankamentów  powinien  być
wykryty w trakcie II etapu badania – oceny zgodności.

Konieczne jest wykazanie relacji pomiędzy słabościami systemu kontroli a nie osiąganiem celów.

Faza, w której dokonuje się selekcji materiałów źródłowych w poszukiwaniu dowodów wzrostu ryzyka

spowodowanego niewłaściwym funkcjonowaniem systemu kontroli nosi nazwę fazy udowadniania ryzyka.

23 listopada
2009

AUDYT SYSTEMÓW INFORMATYCZNYCH

Mariusz Zarzycki, mariusz_zarzycki@wsinf.edu.pl

Rysunek 6. Sekwencje zdarzeń podczas udowadniania ryzyka

Źródło: Opracowanie własne na podstawie ISACA Audit Guidelines [cit. 2006-12-10]
http://www.isaca.org, s. 221.

W celu określenia prawdopodobieństwa osiągnięcia zaplanowanych celów, audytor

ustosunkowuje się do



błędów struktury – na ile budowa systemu kontroli jest zgodna z uznanymi za

wzorcowe dobrymi praktykami i zapewnia efektywne i skuteczne działanie,



błędów realizacji – na ile prowadzone działania są niezgodne z wymaganiami

ustanowionego środowiska kontrolnego oraz



dowodów potwierdzających, że istniejące błędy wpływają na osiąganie przez proces

założonych celów.

2.3. Przygotowywanie raportu

Uwieńczeniem całego procesu audytowego jest przedstawienie przez audytora raportu

z wykonanej pracy. Podobnie jak w przypadku braku jednoznacznych standardów

określających, jak przygotowywać program audytowy, tak i w stosunku do procesu

raportowania nie ma dokładnych wytycznych określających, jak ma on wyglądać.

Sposób przygotowania raportu uzależniony jest ściśle od badanej jednostki oraz od

rodzaju audytu. W przypadku audytu wewnętrznego sposób ten powinien być jednoznacznie

opisany w regulaminach organizacyjnych dotyczących audytu. W przypadku audytu

zewnętrznego, regulacje dotyczące nie tylko procesu raportowania, ale i całego procesu

audytowego powinny zawierać się w umowie audytowej. Raport jest formalnym dokumentem

Forystek M., op.cit., s. 206.

Fragmenty rozdziału opracowano w znacznym stopniu na podstawie: ISACA Audit Guidelines

http://www.isaca.org, s. 219-221, Forystek M., op.cit., s. 202-207 oraz Huston J.E, Bryant S.M., Bagranoff N.A.,
op.cit., s. 212.

23 listopada
2009

AUDYT SYSTEMÓW INFORMATYCZNYCH

Mariusz Zarzycki, mariusz_zarzycki@wsinf.edu.pl

przedstawiającym cele audytowe, wykonane prace, wnioski oraz rekomendacje. Stanowi on

główny produkt prac audytowych, poprzez który oceniani są audytorzy przeprowadzający

badanie

. Rysunek 7 przedstawia propozycje dotyczące struktury procesu raportowania

audytowego.

Rysunek 7. Proces przygotowywania raportu audytowego

Wybranie

spostrzeżeń.

Spotkanie

podsumowujące

Formułowanie

rekomendacji

Formułowanie

oceny

Raport wstępny

Uwarunkowania
Oszustwa
Zdarzenia
późniejsze
Ograniczenia

Spotkanie

końcowe

Opinia

kierownictwa

Raport końcowy

Źródło: Opracowanie własne na podstawie Forystek M, Audyt informatyczny, InfoAudit, Warszawa 2005,
s. 208.

Proces przygotowywania raportu rozpoczyna się od dokonania selekcji informacji,

uzyskanych o badanym obszarze, w celu wybrania spostrzeżeń mających znaleźć się w

raporcie. Wybrane spostrzeżenia powinny



być istotne z punktu widzenia przedmiotu audytu,



wynikać z wykrytych w czasie badania błędów i ich potencjalnej ważności w stosunku

do zaobserwowanych słabości w istniejących w organizacji mechanizmach

kontrolnych.

Zgodnie z zasadami zachowania jakości audytu

wybrane spostrzeżenia audytowe powinny

być bieżąco omawiane z kierownictwem jednostki audytowanej. Spotkanie podsumowujące

na zakończenie prac audytowych pomiędzy przeprowadzającym audyt a zarządzającym

jednostką audytowaną ma na celu



przekazanie kierownictwu badanego obszaru wyników przeprowadzanego audytu,



poddanie wstępnej dyskusji spostrzeżeń audytowych,



wstępne wyjaśnienie nasuwających się wątpliwości dotyczących badanego obszaru,

Konieczne jest zachowanie odpowiedniej formy raportu, sformułowań w nich używanych, tak, aby był on

zrozumiały  dla  kierownictwa  badanej  organizacji.  Standard  070.010  ISACA  (Forma  i  zawartość  raportu)
stwierdza:  „Zadaniem  Audytora  Systemów  Informatycznych  (Audytora  SI)  jest  dostarczenie  określonym
odbiorcom odpowiednio sformułowanego raportu dotyczącego wykonanych prac audytowych. Raport z audytu
ma przedstawiać obszar, cele, okres oraz rodzaj i zakres wykonanej pracy audytorskiej.  Ma wskazywać badaną
organizację,  odbiorcę  raportu  oraz  wszelkie  zastrzeżenia  co  do  jego  obiegu.  Dodatkowo  ma  przedstawiać
wyniki, wnioski i rekomendacje oraz wszelkie opinie audytora wobec badanego obszaru.”

Forystek M., op.cit., s. 209.

Patrz COBIT Audit Guidelines [cit.205-12-10], http://www.isaca.org

Forystek M., op.cit., s. 209.

23 listopada
2009

AUDYT SYSTEMÓW INFORMATYCZNYCH

Mariusz Zarzycki, mariusz_zarzycki@wsinf.edu.pl



umożliwienie przedstawienia nowych faktów mających wpływ na ustalenia audytu,



uzgodnienie realizacji najpilniejszych rekomendacji,



przyspieszenie procesu tworzenia planu realizacji rekomendacji,



wcześniejsze przygotowanie do realizacji zaleceń,



uniknięcie późniejszych wątpliwości i wadliwej interpretacji wyników audytu.

Na podstawie ustaleń wynikających z rozmów z kierownictwem jednostki badanej, audytor

formułuje rekomendacje, w których sugeruje się korekcyjne rozwiązania w stosunku do źle

działających mechanizmów kontrolnych. Podczas przygotowywania rekomendacji audytorzy

opierają się na analizach kosztów i korzyści zastosowania mechanizmów kontrolnych, ,

analizy SWOT, priorytetach działań oraz ewentualnych harmonogramach prac do wykonania

w ramach rekomendacji. Przypisywanie priorytetów prac uwzględnionych w rekomendacjach

przeprowadzane jest ściśle z uwzględnieniem takich kryteriów, jak oczekiwane korzyści i

łatwość wdrożenia proponowanych rozwiązań. Formułowanie przez audytora określonych

rekomendacji w stosunku do zastanego w badanej organizacji stanu mechanizmów

kontrolnych może mieć znaczący wpływ na wprowadzane przez organizację inicjatywy czy

projekty.

Reasumując, sformułowane rekomendacje muszą spełniać kilka warunków



muszą być opłacalne – koszt proponowanych mechanizmów kontrolnych w żadnym

wypadku nie może przekraczać wartości ewentualnych strat, co więcej – koszt nie

powinien przekraczać różnicy pomiędzy ryzykiem istniejącym a akceptowanym,



muszą być realizowalne – audytor nie może rozpatrywać badanego obszaru w

oderwaniu od wszelkich powiązań, współzależności itp.,



muszą być skuteczne – zalecenia muszą skutecznie zmniejszać ryzyko, a ich

wdrożenie nie może zmniejszać ryzyka w jednym obszarze, podwyższając go w

innym.

Jednym z elementów prezentowanych zarówno we wstępnym, jak i w końcowym

raporcie jest opinia audytowa. Międzynarodowe standardy przyjmują trzy główne rodzaje

opinii, podczas opracowania których bierze się pod uwagę między innymi takie czynniki, jak:

charakter analizowanych mechanizmów kontrolnych oraz ograniczenia systemu kontroli.

Pierwsza z nich to opinia bez zastrzeżeń(satysfakcjonująca)(ang. unqualified opinion),

występująca w przypadku braku jakichkolwiek zastrzeżeń odnośnie do zgodności

stosowanych mechanizmów kontrolnych z akceptowalnymi praktykami kontrolnymi.

Forystek M., op.cit., s. 209.

23 listopada
2009

AUDYT SYSTEMÓW INFORMATYCZNYCH

Mariusz Zarzycki, mariusz_zarzycki@wsinf.edu.pl

Oznacza to, że według opinii audytora brak jest istotnych słabości, które mogłyby udaremnić

realizację celów kontrolnych. Kolejnym rodzajem opinii jest opinia z zastrzeżeniem(ang.

qualified opinion). Jak można przypuszczać, w tym wypadku analiza mechanizmów

kontrolnych wykryła pojedyncze luki(słabości) w istniejącym systemie kontroli, które wedle

audytora mogą stanowić zagrożenie, uniemożliwiające realizację celów kontrolnych. Trzecim

rodzajem opinii audytowej jest opinia negatywna, niesatysfakcjonująca(ang. adverse

opinion), wydawana w sytuacji, gdy analiza systemu kontroli wykryła słabości istotne z

punktu widzenia celów kontroli. Rodzą one wysokie prawdopodobieństwo wystąpienia

zagrożeń, które uniemożliwić mogą spełnienie celów kontrolnych. W praktyce spotyka się

również przypadki odmowy wyrażenia opinii(ang. disclaimer of opinion). Możliwe jest to

wtedy, gdy na podstawie przeprowadzonej pracy audytor nie jest w stanie wydać

jakiejkolwiek opinii(na przykład w przypadku braku możliwości zebrania odpowiednich

dowodów audytowych).

Kolejnym etapem procesu przygotowywania raportu audytowego jest przygotowanie

raportu wstępnego. Wytyczne ISACA 070.010.010 określają, co powinien zawierać, w

minimalnym zakresie, raport wstępny. Generalnie, powinien on jasno określać audytowaną

jednostkę, odbiorców raportu oraz wszelkie zastrzeżenia co do jego obiegu(klauzule

zastrzeżone, tajne). Do obowiązkowych elementów zalicza się

 nazwę badanej organizacji,

 tytuł, podpis oraz datę generowania raportu,

 określenie celów kontrolnych oraz stwierdzenie, że audytor wykonał zadanie, by

wyrazić opinię na temat ich skuteczności,

 stwierdzenie, że audyt nie jest przeznaczony do wykrywania wszystkich słabości w

procedurach kontrolnych w sposób ciągły w danym przedziale czasu, a testy

wykonane na procedurach kontrolnych oparte są na próbach,

 osoby upoważnione do zapoznawania się z raportem oraz zastrzeżenie

odpowiedzialności za wykorzystanie go do jakichkolwiek innych celów lub przez

jakąkolwiek inną osobę,

 zakres audytu z uwzględnieniem badanego obszaru, okresu czasowego, systemów

informatycznych itp.,

 wszelkie standardy użyte przez audytora podczas formułowania opinii,

ISACA Guidelines [cit.2005-12-15], http://www.isaca.org oraz Hunton J.E., Bryant S.M., Bagranoff N.A,

op.cit., s. 212 oraz Forystek M., op.cit., s. 211.

23 listopada
2009

AUDYT SYSTEMÓW INFORMATYCZNYCH

Mariusz Zarzycki, mariusz_zarzycki@wsinf.edu.pl

 stwierdzenie, że utrzymanie skutecznej kontroli wewnętrznej jest obowiązkiem

kierownictwa,

 wyjaśnienia na temat czynników wpływających na dostarczone zapewnienie oraz, w

razie potrzeby, inne informacje,

 paragraf określający zastrzeżenia do wydanej opinii,

 opinię uwzględniającą wszelkie istotne aspekty, budowę i działania procedur

kontrolnych, ich skuteczność, w odniesieniu do obszaru badanej działalności,

 adnotację mówiącą, że ze względu na wbudowane ograniczenia

każdego systemu

kontroli, zawsze mogą wystąpić niewykryte nieprawidłowości.

Forma samego raportu wstępnego i końcowego jest dowolna, jednakże należy pamiętać, iż ma

ona być czytelna dla ostatecznego odbiorcy, którym jest kierownictwo badanej organizacji.

Proces przygotowywania raportu kończy się zaprezentowaniem raportu końcowego,

który posiada identyczną co do elementów treści formę, jak raport wstępny. Różnice

pomiędzy wstępną a końcową wersją polegają jedynie na tym, że:

 raport końcowy nie może ulec zmianie, w przeciwieństwie do raportu wstępnego

wzbogacanego o sugestie ze strony właściwych odbiorców,

 raport końcowy zawiera odpowiedzi kierownictwa jednostki badanej na spostrzeżenia

i rekomendacje audytowe.

Ważnym elementem procesu tworzenia raportów jest zachowanie odpowiednio

wysokiego poziomu bezpieczeństwa uwzględniającego obieg tak newralgicznego z punktu

widzenia organizacji dokumentu, jakim jest raport z przeprowadzonego badania. Szczególny

nacisk należy położyć na zapewnienie odpowiedniego dostępu do raportu jedynie osobom

zainteresowanym problemem. Dostęp powinien uwzględniać przypadki, w których zarówno

audytorzy, jak i reprezentanci jednostki badanej mają wgląd jedynie do elementów raportu im

Patrz Forystek M., op.cit., s. 213. Często w trakcie badania mogą wystąpić ograniczenia uniemożliwiające

audytorowi zebranie wystarczających dowodów. Fakt ten, wpływający na wzrost ryzyka, należy koniecznie
odnotować w raporcie. Prezentując informacje związane z ograniczeniami należy uwzględnić takie aspekty, jak:



istotę, harmonogram i przyczyny osłabienia niezależności i obiektywizmu,



kroki podjęte w celu zapewnienia, że obiektywizm nie został istotnie osłabiony w ciągu prac
audytowych i przygotowywania raportu,



fakt, że informacja o potencjalnym osłabieniu niezależności została przekazana komisji rewizyjnej lub
ekwiwalentnemu ciału.

Jeżeli  podczas  badania  okaże  się,  że  prawdopodobnie  źle  funkcjonują  ogólne  mechanizmy  kontrolne(czyli
szwankuje  organizacja  podstawowych  procesów  zarządczych),  wówczas  audytor  powinien  przedstawić  taką
opinię,  nawet,  jeśli  tego  typu  zagadnienia  nie  były  wyraźnie  określone  w  uzgodnionym  zakresie  prac
audytowych.

23 listopada
2009

AUDYT SYSTEMÓW INFORMATYCZNYCH

Mariusz Zarzycki, mariusz_zarzycki@wsinf.edu.pl

przeznaczonych

. Zabezpieczenie raportu przed niekontrolowanym dostępem oraz

jakimikolwiek zmianami jest szczególnie istotne w początkowej fazie jego tworzenia

Podczas przeprowadzania badania często mają miejsce zdarzenia, do których audytor

nie ma obowiązku odnosić się w swojej pracy. Forystek

zalicza do nich: zdarzenia

późniejsze(wynikłe) oraz oszustwa. Zdarzenia późniejsze to wszelkie zdarzenia mające

poważny wpływ na przedmiot badania, wynikłe później w stosunku do czasu lub okresu

badania, ale powstałe przed datą wydania raportu

. Oszustwo w ogólnym rozumieniu

zdefiniować można jako akt bezprawny mający na celu wprowadzanie w błąd

, udawanie

kogoś innego, manipulację, zafałszowanie lub zmianę danych lub dokumentów, tworzenie

pozorów bądź aranżowanie fałszywych instytucji, sytuacji. Wytyczne ISACA

, ujęte w

standardzie 030.010.010( Nieprawidłowości i akty bezprawne) jasno precyzują:

 co należy rozumieć pod pojęciem nieprawidłowości oraz działań niedozwolonych,

 jak planować badanie, aby wykrywać akty bezprawne,

 odpowiedzialność kierownictwa i audytora SI,

 procedury reagowania na wystąpienie nieprawidłowości lub aktów nielegalnych,

 sposób uwzględniania w raporcie informacji o nieprawidłowościach oraz działaniach

bezprawnych.

Uogólniając, audytor nie ponosi explicite odpowiedzialności za zapobieganie oraz

wykrywanie aktów bezprawnych. Niemniej jednak powinien projektować procedury do ich

wykrywania opierając się na oszacowanym poziomie ryzyka i możliwości ich wystąpienia.

Odkrycie takich działań wymaga szczególnie ostrożnego zachowania i podjęcia stosownych

kroków. Audytor systemów informatycznych powinien zawrzeć w raporcie opis zdarzeń i

okoliczności towarzyszących nieprawidłowości lub aktowi bezprawnemu. Spostrzeżenia

powinny być przedstawione odpowiedniemu kierownictwu, wyższemu niż to, które jest

uwikłane w sytuację uznaną za podejrzaną. Jeżeli uwikłane są wszystkie poziomy

Forystek M., op.cit., s. 213. Dostęp do raportu powinna mieć wyłącznie kadra kierownicza, audytorzy, którzy

są za niego odpowiedzialni, oraz wyznaczeni pracownicy.

Wykorzystywanie narzędzi elektronicznego przekazu rodzi niebezpieczeństwo niekontrolowanego dostępu.

Forystek M., op.cit., s. 212.

Tamże. Przed wydaniem raportu audytor powinien zasięgnąć u kierownictwa badanego obszaru informacji,

czy są świadomi jakichkolwiek zdarzeń powstałych po zakończeniu prac audytowych, które mogłyby mieć
poważny wpływ na przedmiot badania. Zgodnie ze standardami audytor nie ma obowiązku wykrywania tych
zdarzeń, niemniej jednak, zawsze powinien rozważyć zawarcie wzmianki o tego typu przypadkach w raporcie.

W odróżnieniu od oszustwa błąd oznacza niezamierzoną pomyłkę.

Standardy, wytyczne i procedury audytowania i kontrolowania systemów informatycznych [cit.2005-12-20],

http://www.isaca.org.pl , s. 20.

23 listopada
2009

AUDYT SYSTEMÓW INFORMATYCZNYCH

Mariusz Zarzycki, mariusz_zarzycki@wsinf.edu.pl

kierownictwa, wówczas spostrzeżenia powinny być przedstawione organizacyjnym ciałom

regulującym, takim jak zarząd czy rada nadzorcza

Analizując oszustwa należy również uwzględnić ich ewentualne przyczyny, tj.

niezadowolenie pracowników, potencjalne ograniczenia zatrudnienia, outsourcing,

restrukturyzację, istnienie majątku łatwo podatnego na zmianę przeznaczenia, słabą

wydajność finansową/operacyjną organizacji, postawę kierownictwa, nieprawidłowości lub

akty bezprawne charakterystyczne dla konkretnej branży albo pojawiające się w podobnych

organizacjach. Akty bezprawne, masowo występujące w ostatnich czasach spowodowały, iż

temat oszustw, również, a może i przede wszystkim tych z użyciem komputerów stanowi

obiekt zainteresowań audytorów oraz innych instytucji. Zdarzenia mające miejsce w ostatnich

latach wpłynęły na rozszerzenie odpowiedzialności audytora co do detekcji oszustw podczas

badania

Szczególnym przypadkiem przeprowadzania audytu jest audyt śledczy mający na celu

wykrycie przestępstw związanych z funkcjonowaniem i użytkowaniem systemów

informatycznych. Audytor w tym miejscu występuje jako organ wykonawczy, działający na

zlecenie np. prokuratury.

Komputerowe techniki wspomagania audytu

Istnieją dwa podejścia do prowadzenia badania w środowisku informatycznym:

audytowanie obok komputera(ang. auditing around the computer) oraz audyt z użyciem

komputera(ang. auditing with computer). Zarówno pierwsza, jak i druga metoda ma na celu

ciągłe zwiększanie efektywności oraz podnoszenie jakości badań.

Audyt obok komputera(ang. auditing around the computer) dotyczy przypadków, w

których audytor bada informacje wejściowe i wyjściowe systemu informatycznego, ale nie

Standardy, wytyczne i procedury audytowania i kontrolowania systemów informatycznych [cit. 2005-12-29],

http://www.isaca.org.pl,  s.  23.  Audytor  powinien  używać  profesjonalnego  osądu,  kiedy  informuje  o  zajściu
nieprawidłowości lub aktu bezprawnego. Audytor SI powinien przedyskutować spostrzeżenia oraz naturę, czas i
obszar jakichkolwiek dalszych procedur z  kierownictwem  odpowiedniego poziomu.  Szczególnie  ważnym jest,
aby audytor SI zachował niezależność. Określając odpowiednie osoby, którym raportować nieprawidłowość lub
działania  bezprawne,  audytor  SI  powinien  uwzględnić  prawdopodobieństwo  uwikłania  także  najwyższego
kierownictwa.  W  sytuacjach,  gdy  od  audytora  SI  jest  wymagane  ujawnienie  potencjalnych  lub
zidentyfikowanych nieprawidłowości lub aktów bezprawnych, powinna być najpierw zaciągnięta opinia prawna.

Chodzi o afery w takich instytucjach jak Enron, Global Crossing, Adelphia, WorldCom, Tyco(patrz w dalszej

części  pracy  Ustawa  Sarbanes-Oxley).  Patrz  Champlain  J.J.,  op.cit.,  s.  268-274.  Autor  przedstawia  metody
detekcji  oszustw  zaistniałych  z  użyciem  komputerów.  Na  podstawie  przeprowadzonych  badań  zarówno
praktycznych,  jak  i  literaturowych  postuluje  on  13  kroków  mających  na  celu  wykrycie  oszustw
komputerowych(ang. e-crime, cybercrime, etc).

ISACA 060.020.070 “Use of Computer assisted Audit Techniques”, [cit. 2006-10-28], http://www.isaca.org

oraz Forystek M., op.cit., s. 214-239, Hunton J.E., Bryant S.M., Bagranoff N.A., op.cit., s. 177-207.

23 listopada
2009

AUDYT SYSTEMÓW INFORMATYCZNYCH

Mariusz Zarzycki, mariusz_zarzycki@wsinf.edu.pl

testuje bezpośrednio procesu przetwarzania. Oznacza to, że audytor prowadzi badanie tak,

jakby w badanej jednostce nie były wykorzystywane systemy informatyczne. Jeśli badane

elementy są przechowywane wyłącznie w systemie informatycznym, audytowanie wokół

komputera wymaga, aby były drukowane różnorodne dokumenty, dzienniki, księgi i

sprawozdania. Może to być kosztowne i czasochłonne. Ponadto, audytowanie wokół

komputera można stosować, jeśli audytor ma pewność, że przygotowane wydruki

odzwierciedlają rzeczywiste dokumenty

Pod pojęciem audytowania z komputerem, które jest często nazywane w praktyce

komputerowymi technikami i narzędziami wspomagania audytu(ang. computer assisted audit

tools and techniques(CAATs)) rozumie się wszelkiego rodzaju programy, techniki bądź

narzędzia komputerowe, które wykorzystywane są przez audytora podczas procedur

audytowych do przetwarzania danych przechowywanych w systemach informatycznych

badanej jednostki. Narzędzia CAATs mogą być wykorzystywane do przeprowadzania wielu

rodzajów procedur audytowych, chociażby



testowania szczegółów transakcji i sald – dla ponownego przeliczania zysków lub do

wybrania z zapisów komputerowych faktur z określoną wartością,



procedur analitycznych – dla identyfikacji niespójności przetwarzania,



próbkowania,



testowania mechanizmów kontroli ogólnej – dla testowania konfiguracji systemu

operacyjnego lub procedur dostępu do funkcji, kodu lub danych, weryfikacji

poprawności sumowania lub kontroli sensowności danych,



testowania mechanizmów kontroli w systemach informatycznych.

Generalnie, komputerowe narzędzia wspomagania audytu można podzielić na dwa

rodzaje



narzędzia zwiększające wydajność w codziennych pracach audytorskich, do których

zalicza się wszelkiego rodzaju elektroniczną korespondencję/dokumentację

narzędzia zarządzania dokumentami

, narzędzia pracy grupowej

, branżowe

Porównaj Weber. R., op.cit., s. 56. Forystek M., op.cit., s. 219. Autor prezentuje przypadki, w których

stosować można audytowanie wokół komputera. Wymienia między innymi niski poziom ryzyka wewnętrznego,
wsadowe przetwarzanie transakcji i inne.

Forystek M., op.cit., s. 221 za Międzynarodowymi Standardami Rewizji Finansowej.

Załącznik 2 prezentuje przykłady narzędzi wykorzystywanych do zautomatyzowania poszczególnych etapów

prac audytowych.

Porównaj możliwości J.E.Hunton, S.M.Bryant, N.A. Bagranoff, op.cit., s. 181-182.

Wszelkie oprogramowanie umożliwiające w trybie on-line zarządzanie dokumentami z uwzględnieniem

chociażby kontrolowanego dostępu do tych dokumentów, śledzenia zmian i różnic.

23 listopada
2009

AUDYT SYSTEMÓW INFORMATYCZNYCH

Mariusz Zarzycki, mariusz_zarzycki@wsinf.edu.pl

biblioteki danych z informacjami na temat danych branż, technologii, organizacyjnych

procedur etc.,



uniwersalne narzędzia audytowe, jak ACL

, systemy eksperckie, narzędzia

statystyczne

, oprogramowanie użytkowe.

W przypadku komputerowych technik wspomagania audytu, wyróżnić można również dwa

podzbiory, tj:

 CAATs potwierdzające integralność programów komputerowych – tj. testy

integralności, symulacje równoległe

, test decks

 CATTs weryfikujące integralność danych - wszelkiego rodzaju techniki

umożliwiające ekstrakcję i analizę danych, wykrywanie oszustw komputerowych czy

techniki audytowania ciągłego

Mówiąc o narzędziach sprawdzających integralność programów komputerowych, audytorzy

weryfikują przede wszystkim poprawność działania funkcji oraz procedur zawartych w

programach komputerowych. Weryfikacja polega na ustaleniu, czy programy umożliwiają

wykonanie nieprawidłowych operacji w sposób zamierzony bądź przypadkowy przez

użytkownika. Najpopularniejsze techniki wykorzystywane w tym zakresie to testowanie

przez

dane

oraz

wspomniane

przetwarzanie równoległe. Ważnym rodzajem

Patrz narzędzia czołowych firm jak: IBM(http://www.ibm.com), Microsoft(http://www.microsoft.com),

Oracle(http://www.oracle.com), Citrix(http://www.citrix.com).

ACL Service LTD, http://www.acl.com, http://www.skg.pl/acl , ACL™ to preferowane narzędzie audytorów i

osób  zawodowo  związanych  z  zarządzaniem  finansami.  Wykorzystywane  jest  we  wszystkich  rodzajach
audytów: finansowym, operacyjnym i informatycznym. Oprogramowanie stosowane jest do pobierania danych,
ich  analizy,  wykrywania  oszustw  oraz  ciągłego  monitorowania.  W  ACL  możliwe  są:  1.    Szybka  i  wydajna
analiza danych, niezależna od działów IT. 2. Analiza danych transakcyjnych, zapisanych w plikach o dowolnych
rozmiarach,  celem  zapewnienia  kompatybilności  danych  i  wysokiej  jakości  wyników.  3.  Tworzenie
przejrzystych  raportów  –  projektowanie,  podgląd  i  modyfikacja  wyników  na  ekranie  z  wykorzystaniem
formatowania  typu  „przeciągnij  i  upuść”.    4.  Identyfikacja  trendów,  wykrywanie  wyjątków  i  wybór
potencjalnych  obszarów  zainteresowania.  5.  Lokalizacja  błędów  i  możliwych  nadużyć  poprzez  porównanie  i
analizę plików zgodnie z zadanymi kryteriami.  6. Identyfikacja obszarów kontroli i zapewnienie zgodności ze
standardami. Programy uniwersalne, jak ACL, umożliwiają stosowanie funkcji ułatwiających wykonanie: testów
kompletności i sensowności, testów luk i dublujących się wartości, analizy regresji, analizy statystyk, kojarzenia
transakcji(patrz załącznik 3).

Wszelkiego rodzaju narzędzia typu GASP(ang.Generalised Audit Software Programs), które umożliwiają

wykonywanie statystycznych analiz na danych jednostki badanej. Przykładem najczęściej spotykanych narzędzi
może być Microsoft Excel wchodzący w skład pakietu Microsoft Office, Statistica czy wspominany wcześniej
ACL.

Technika stosowana w trakcie wdrażania nowego systemu(modułu), który ma zastąpić dotychczas używane

rozwiązanie. Audytor symuluje we własnym systemie oraz systemie badanym proces przetwarzania pewnego
zbioru danych. Następnie porównuje wyniki obu systemów. Ich identyczność oznacza poprawność
przetwarzania.

http://www.indiainfoline.com/bisc/acct.html [cit. 2005-07-20], w kontekście audytowym, zbiór symulowanych

transakcji, które audytor inicjuje w systemie informatycznym w celu sprawdzenia poprawności przetwarzania.

Definicja podana w dalszej części pracy.

Porównaj tę i inne narzędzia w Forystek M., op.cit., s. 214-239.

23 listopada
2009

AUDYT SYSTEMÓW INFORMATYCZNYCH

Mariusz Zarzycki, mariusz_zarzycki@wsinf.edu.pl

oprogramowania wspomagającego audyt są aplikacje do śledzenia i mapowania

. Posługując

się oprogramowaniem do śledzenia i mapowania audytor SI powinien uzyskać potwierdzenie,

że oceniany kod źródłowy posłużył do wygenerowania oprogramowania, które w chwili

obecnej jest używane.

Ważną kategorią narzędzi wspomagających audyt informatyczny są narzędzia

wykorzystywane do testowania infrastruktury teleinformatycznej, będącej de facto podstawą

wszystkich rozwiązań teleinformatycznych, w tym ERP. Do narzędzi wykorzystywanych

podczas testowania infrastruktury teleinformatycznej zaliczyć można wszelkiego rodzaju

skanery bezpieczeństwa, analizatory sieci, eksploratory oraz monitory sieci. Skanery

bezpieczeństwa mają na celu wyszukiwanie określonych luk(nieprawidłowości) w badanym

środowisku poprzez porównanie wewnętrznie wbudowanej, wzorcowej polityki z aktualnym

stanem panującym w testowanym środowisku

. Spotyka się skanery zewnętrzne oraz

wewnętrzne, gdzie testujący odpowiednio bada daną infrastrukturę z zewnątrz bądź od

wewnątrz. Analizatory sieci służą przede wszystkim do analizowania ruchu w sieci,

szczególnie pod kątem przesyłu poufnych informacji „jawnym tekstem”. Eksploratory sieci

przedstawiają topologię sieci, tj, połączenia pomiędzy wszystkimi, głównymi elementami

sieci teleinformatycznej. Monitory sieci są złożonymi programami komputerowymi, które

obecnie posiadają funkcjonalność zarówno skanera, analizatora, jak i eksploratora.

Wszystkie narzędzia wykorzystywane do testowania infrastruktury sieci

teleinformatycznej podzielić można na narzędzia hackerskie oraz administracyjne. Pierwsze z

nich nie wymagają autoryzowanego dostępu do badanej infrastruktury, a ich użycie musi

zostać zaakceptowane przez najwyższe kierownictwo badanej organizacji. Drugie z kolei,

wykorzystywane są nie tylko przez audytorów, ale i również przez administratorów

infrastruktury. Do ich poprawnego użycia potrzebne są przywileje administratora i najczęściej

wykorzystywane są one do testowania wewnątrz badanej organizacji.

Korzystanie z komputerowego wspomagania audytu powinno być uzależnione od

wielu czynników. Forystek wymienia między innymi

 biegłość i doświadczenie w zakresie stosowania narzędzi komputerowych,

 dostępność odpowiednich narzędzi informatycznych oraz odpowiednich urządzeń i

danych komputerowych,

http://www.isaca.org.pl [cit. 2005-07-25], Standardy, wytyczne i procedury audytowania i kontrolowania

systemów informatycznych, s. 58.

Skanowanie może dotyczyć systemów operacyjnych, baz danych, systemów ochrony antywirusowej,

elementów sieciowych.

Forystek M., op.cit., s. 235.

23 listopada
2009

AUDYT SYSTEMÓW INFORMATYCZNYCH

Mariusz Zarzycki, mariusz_zarzycki@wsinf.edu.pl

 przewagę w skuteczności stosowania ewentualnych CAATs nad technikami

manualnymi,

 ograniczenia czasowe,

 zgodność własnych rozwiązań z badanym środowiskiem komputerowym,

 poziom ryzyka, związanego ze stosowaniem tych narzędzi.

Wykorzystanie narzędzi CAATs podczas badania powinno być realizowane wedle określonej

procedury, analogicznej do wdrożenia innych systemów IT. Rysunek 50 przedstawia dziesięć

kroków, które mogą stanowić jej trzon.

Ponieważ zbiory danych, z których korzysta audytor podczas badania, stanowią w

większości przypadków wewnętrzną tajemnicę jednostki badanej, korzystanie z narzędzi

CAATs wymaga od audytora uzgodnienia z audytowanymi wszelkich szczegółów

dotyczących ich wykorzystania. Ustalenia dotyczyć mogą formatów danych wejściowych,

personelu, zasad dostępu do funkcjonujących w organizacji narzędzi IT, okresu

przechowywania przez audytora danych. Jeżeli korzystanie przez audytora z narzędzi

wspomagających audyt może wpłynąć negatywnie na czynności operacyjne danej organizacji,

należy ten fakt bezwzględnie ustalić z odpowiednim wyprzedzeniem. Ważnym aspektem

korzystania z narzędzi CAATs jest kwestia bezpieczeństwa przetwarzanych w nich danych.

Audytor decydując się na komputerowe wsparcie audytu, zmuszony jest zachować

odpowiednio wysoki poziom bezpieczeństwa, integralności i poufności danych

Powinno się uwzględnić poziom bezpieczeństwa narzucony przez właściciela danych, czyli badaną

organizację, określony w polityce bezpieczeństwa informacji oraz w innych regulacjach prawnych, np. ustawa o
ochronie danych osobowych.

23 listopada
2009

AUDYT SYSTEMÓW INFORMATYCZNYCH

Mariusz Zarzycki, mariusz_zarzycki@wsinf.edu.pl

Rysunek 8. Procedura wykorzystania narzędzi CAATs

Krok 1.

Ustanowienie celów audytowych podczas planowania

audytu oraz szacowania ryzyka.

Krok 2.

Zindetyfikowanie narzędzi CAATs, które mogą być

przydatne w osiągnięciu celów audytowych.

Krok 3.

Określenie zbiorów danych, plików bądź innych

elementów potrzebnych ze strony jednostki badanej.

Krok 10. Dokumentowanie badania (

z uwzględnieniem

wykorzystania narzędzi CAATs).

Krok 9.

Zgromadzenie potrzebnych dowodów audytowych.

Krok 8. Przeprowadzenie zaplanowanych analiz przy pomocy

wybranych narzędzi CAATs

Krok 7.

Sprawdzenie integralności danych po procesie importu

do narzędzia CAATs

Krok 6. Zaimportowanie danych do systemu(

narzędzia)

analizującego typu CAATs.

Krok 5.

Uzyskanie potrzebnych danych w określonym formacie

ze strony jednostki badanej.

Krok 4.

Określenie formatu/ów potrzebnych danych.

Źródło: Opracowanie własne na podstawie Hunton J.E., Bryant S.M., Bagranoff N.A., Core concepts of
information technology auditing, John Wiley & Sons, 2004, s. 185.

Należy mieć świadomość, iż w wyniku korzystania z narzędzi CAATs ilość dowodów

audytowych może być znacząca. Audytor decydujący się na ich wykorzystanie powinien

dokonywać ich przeglądu pod kątem np. realności danych wyjściowych oraz logiki i

parametryzacji związanej z przetwarzaniem. Standard ISACA 060.020.070 stanowi, że opis

zawarty w raporcie końcowym nie powinien być nadmiernie szczegółowy, lecz ma umożliwić

rozpoznanie użytych w badaniu narzędzi CAATs. Opis użytych narzędzi CAATs powinien

być również umieszczony w części raportu dotyczącej konkretnych przypadków ich użycia.

Techniki i narzędzia komputerowego wspomagania audytu dają szerokie możliwości

usystematyzowania i automatyzacji prac audytowych. Efektem tej automatyzacji jest

opracowanie metody, która umożliwia audytorom dostarczanie pisemnej opinii na dany

temat(dotyczący celu audytowego), używając określonego zbioru raportów, dzienników

audytowych tworzonych ad hoc. Literatura przedmiotu nazywa tę metodę audytowaniem

23 listopada
2009

AUDYT SYSTEMÓW INFORMATYCZNYCH

Mariusz Zarzycki, mariusz_zarzycki@wsinf.edu.pl

ciągłym(ang. continuous auditing)

. Audytowanie ciągłe oznacza w praktyce zbudowanie

określonego systemu monitorowania zdarzeń, opartego o profesjonalne narzędzia CAATs,

reagującego w momencie zajścia zdarzenia dotyczącego danego celu audytowego

Zanim audytowanie ciągłe stanie się powszechne, konieczne jest sformułowanie

odpowiedzi na następujące pytania



jak zautomatyzowane procedury audytowe mogą odpowiednio i szybko określić

naturę, terminowość i zakres procedur dowodowych?



czy procedury dowodowe będą wymagane, jeśli ryzyko kontroli będzie oceniane

nisko?



jak natura przedmiotu audytu i potrzeba ciągłego audytowania wpłyną na sposób

ustalania ważności rekomendacji i pożądanego poziomu ryzyka audytowego?



jak audytorzy mogą skutecznie korzystać z narzędzi audytowych i technik, które nie są

używane zbyt często w tradycyjnych audytach sprawozdań finansowych?



czy obiektywizm audytorów zewnętrznych może być znacząco osłabiony, gdy do

systemów audytowanej jednostki będą wbudowane automatyczne narzędzia

audytowe?



jak wiedza, umiejętności i praca audytorów wewnętrznych mogą być bardziej

efektywnie wykorzystywane do automatyzowania procesów audytowych?

Patrz Institute of Internal Auditors Research Foundation, Continuous Auditing: Potential for Internal

Auditors, http://www.theiia.org , 2003.

W przypadku systemów ERP można często korzystać z wbudowanych mechanizmów stanowiących

poszczególne elementy systemu zintegrowanego w celi ewidencji zdarzeń, automatycznego powiadamiania
audytora i administratora danego systemu.

Forystek M., op.cit., s. 239.