e-Informatica Software Engineering Journal Instytucjonalizacja i standaryzacja audytu systemów informatycznych

Instytucjonalizacja i standaryzacja audytu systemów informatycznych

Krzysztof Sacha,  Rafał Cegieła,  Andrzej Zalewski
Wydział Elektroniki i Technik Informacyjnych, Instytut Automatyki i Informatyki Stosowanej,  Politechnika Warszawska
{k.sacha, r.cegiela, a.zalewski}@ia.pw.edu.pl

Audyt: Niezależna ocena zgodności ze specyfikacją, standardami, umową lub innymi kryteriami.

–IEEE Computer Dictionary
Streszczenie

Rozdział prezentuje bieżący stan zorganizowania oraz standaryzacji aktualnej i szybko rozwijającej się dziedziny audytu systemów informatycznych. Zaprezentowane zostały standardy prowadzenia prac audytowych, klasyczny przebieg prac audytora oraz referencyjny model procesów organizacyjnych.

1. Geneza i instytucjonalizacja audytu systemów informatycznych#

Historycznie najwcześniejszą dziedziną, w której audyt – czyli niezależna weryfikacja prowadzonych prac i ich wyników – została włączona w tryb rutynowych działań, jest badanie sprawozdań finansowych przedsiębiorstw. Audyt księgowy został zinstytucjonalizowany poprzez powstanie organizacji takich jak międzynarodowe Stowarzyszenie Certyfikowanych Księgowych (ang. Association of Chartered Certified Accountants – ACCA) [ACCA], sięgające swoją historią roku 1904, oraz polska Krajowa Izba Biegłych Rewidentów [KIBR]. Organizacje te m.in. potwierdzają kompetencje audytora ksiąg rachunkowych nadając certyfikaty odpowiednio: certyfikowanego księgowego (ang. Chartered Certified Accountant – CCA) oraz biegłego rewidenta.Następny etap w rozwoju audytu stanowiło upowszechnienie tzw. audytu wewnętrznego, dotyczącego uniwersalnych zasad racjonalnego i efektywnego prowadzenia przedsiębiorstwa. Organizacją ustanawiającą standardy w dziedzinie audytu wewnętrznego jest m.in. powstały w 1941 roku Instytut Audytorów Wewnętrznych (ang. Institute of Internal Auditors – IAA) [IAA]. W Polsce instytucją promującą wiedzę z dziedziny audytu wewnętrznego jest Polski Instytut Kontroli Wewnętrznej [PIKW]. Kompetencje zawodowe audytora wewnętrznego są potwierdzane międzynarodowym certyfikatem audytora wewnętrznego (ang. Certified Internal Auditor – CIA). W Polsce, w związku z wprowadzeniem przez Ministerstwo Finansów RP obowiązku prowadzenia audytu wewnętrznego w jednostkach administracji publicznej, istnieje możliwość potwierdzenia kompetencji w dziedzinie audytu wewnętrznego przez złożenie egzaminu przed komisją egzaminacyjną Ministerstwa.

Funkcjonowanie systemów informatycznych w przedsiębiorstwach stało się przedmiotem systematycznego audytu w latach 60. Międzynarodowe Stowarzyszenie Audytorów Systemów Informatycznych (ang. Information Systems Audit and Control Association & Foundation) [ISACA] powstało w roku 1969. Kompetencje audytora systemów informatycznych są potwierdzane nadawanym przez to stowarzyszenie certyfikatem audytora systemów informatycznych (ang. Certified Information Systems Auditor – CISA).

Traktując kompleksowo rozwój dziedziny audytu można zauważyć, że po początkowej ścisłej specjalizacji w dziedzinie ksiąg rachunkowych nastąpiło rozszerzenie na całość procesów zachodzących w przedsiębiorstwie. Rozszerzenie to wymagało usystematyzo-wania zasad funkcjonowania przedsiębiorstwa oraz zasad prowadzenia audytu w zakresie, w którym nie zależą one od rodzaju działalności i gałęzi przemysłu. Po usystematyzowaniu ogólnych zasad nastąpiła ponowna specjalizacja w dziedzinach rządzących się niezależnymi od podstawowej działalności przedsiębiorstwa, lecz złożonymi prawami, w tym również w dziedzinie systemów informatycznych.

2. Standardy prowadzenia audytu#

Celem tego podrozdziału jest przedstawienie zwięzłego przeglądu standardów określających zasady prowadzenia audytu. Przegląd obejmie standardy sformułowane przez Stowarzyszenie Audytorów Systemów Informatycznych ISACA, standard określony przez Instytut Audytorów Wewnętrznych IIA oraz standardy ustalone przez IEEE/ANSI.Wymienione standardy, wydane przez różne organizacje i mające różne obszary zastosowań, zawierają rekomendacje sformułowane w nieco odmienny sposób. Ich wspólną cechą jest nacisk położony na najważniejszą cechę odróżniającą działania określane mianem audytu od innych mechanizmów kontroli wykorzystywanych przez przedsiębiorstwa, jaką jest niezależność i obiektywizm formułowanych ocen i wniosków. Stąd wszystkie standardy formułowane przez organizacje związane z audytem są w znacznym stopniu niezależne od obszaru, którego dotyczy audyt i koncentrują się wokół:

  • niezależności audytora,
  • staranności prowadzenia audytu,
  • kompetencji audytora,
  • zasad zarządzania procesem audytu,
  • zasad komunikowania wyników audytu.

2.1. Standardy ISACA#

Standardy audytu sformułowane przez Stowarzyszenie Audytorów Systemów Informa-tycznych (ISACA) są podzielone na osiem kategorii:

  • 010 Prawa i powinności audytu (ang. Audit Charter),
  • 020 Niezależność (ang. Independence),
  • 030 Standardy i etyka zawodowa (ang. Professional Ethics and Standards),
  • 040 Kompetencje (ang. Competence),
  • 050 Planowanie (ang. Planning),
  • 060 Wykonywanie prac audytowych (ang. Performance of Audit Work),
  • 070 Raportowanie (ang. Reporting),
  • 080 Dalszy tok działań (ang. Follow-Up Activities).

Każda z kategorii zawiera standardy sformułowane w postaci krótkich zaleceń, np. kategoria „020 Niezależność” zawiera standard „.010 Niezależność zawodowa” (ang. Professional Independence) sformułowany następująco:

„We wszystkich sprawach związanych z audytem, audytor systemów informatycznych musi być niezależny od poddawanych audytowi, zarówno co do stanowiska jak i postępowania”.

Dla każdego tak sformułowanego standardu dostępne są wytyczne uszczegóławiające sformułowane w standardzie zalecenia, w kontekście poszczególnych etapów pracy audytora.

Ważnym elementem systemu standardów ISACA jest model referencyjny opisujący procesy organizacyjne związane z funkcjonowaniem systemu informatycznego w przedsiębiorstwie. Jednym z kryteriów oceny formułowanej w wyniku przeprowadzonego audytu jest zgodność realnie istniejącej organizacji z modelem referencyjnym.

2.2. Standardy IIA#

Standardy audytu, którymi posługuje się Instytut Audytorów Wewnętrznych (IIA) zostały podzielone na dwie grupy – standardy określające cechy procesu audytu (ang. Attribute standards) oraz standardy dotyczące poszczególnych czynności wykonywanych w trakcie audytu (ang. Performance standards).Standardy cech (ang. Attribute standards):

  • 1000 Cel, uprawnienia i odpowiedzialność

(ang. Purpose, Authority and Responsibility),

  • 1100 Niezależność i obiektywność

(ang. Independence and Objectivity),

  • 1200 Biegłość i należyta staranność

(ang. Proficiency and Due Professional Care),

  • 1300 Program zapewniania i poprawy jakości

(ang. Quality Assurance and Improvement Program).

Standardy wykonania (ang. Performance standards):

  • 2000 Zarządzanie audytem wewnętrznym

(ang. Managing the Internal Audit Activity),

  • 2100 Charakterystyka zadań (ang. Nature of Work),
  • 2200 Planowanie prac (ang. Engagement Planning),
  • 2300 Wykonanie prac (ang. Performing the Engagement),
  • 2400 Komunikowanie wyników (ang. Communicating Results),
  • 2500 Moniotorowanie postępów (ang. Monitoring Progress),
  • 2600 Akceptacja ryzyka przez zarząd (ang. Management’s Acceptance of Risks).

Poszczególne standardy mają postać zwięzłych, kilkuzdaniowych wytycznych określających osobę lub jednostkę odpowiedzialną za przestrzeganie standardu oraz uszczegóławiających zagadnienie określone w nazwie standardu, np. standard „1000 Cel, uprawnienia i odpowiedzialność” został sformułowany następująco:

„Cel, uprawnienia i odpowiedzialność jednostki audytu wewnętrznego powinna zostać formalnie określona w statucie, który powinien być zgodny ze Standardami i który powinien zostać zatwierdzony przez zarząd.”

Treść niektórych standardów jest uszczegółowiona przez dodatkowe wytyczne (standardy) sformułowane w podobny sposób. Z każdym standardem związane są wytyczne dotyczące jego wdrożenia (ang. implementation standards), np. z zacytowanym powyżej standardem związane są dwie wytyczne, z których pierwsza jest następującej treści:

„Rodzaj usług zapewniających świadczonych organizacji powinna zostać zdefiniowana w statucie audytu. Jeżeli zapewniające mają być świadczone jednostkom spoza organizacji, to rodzaj tych usług powinien także zostać zdefiniowany w statucie.”

2.3. Standardy IEEE/ANSI#

Klasyczne pojęcie audytu księgowego wiąże się ściśle z działaniami kontrolnymi, zmierzającymi do wyeliminowania lub wykrycia ewentualnych nadużyć. Podobny charakter może mieć również audyt oprogramowania, którego finalnym celem jest zweryfikowanie rzetelności wykonawcy systemu informatycznego. Z drugiej jednak strony badanie zgodności projektu ze specyfikacją, normami itp., można traktować jako jedną z metod zapewnienia jakości oprogramowania (ang. software quality assurance). W takim kontekście sytuuje pojęcie audytu standard IEEE/ANSI Std. 1028 [IEEE1988], określający (łącznie) zasady prowadzenia przeglądów (ocena wewnętrzna) i audytów (ocena zewnętrzna). Przedmiotem tego standardu jest ocena sposobu prowadzenia projektów programistycznych.Cykl opracowania oprogramowania można umownie podzielić na szereg etapów, w których powstają kolejne elementy dokumentacji projektowej, moduły programu i ostatecznie gotowy system. Osiągnięcie wysokiej jakości oprogramowania wymaga odpowiedniego zorganizowania pracy zespołów projektowych oraz systematycznej kontroli uzyskiwanych rezultatów. Metody prowadzenia kontroli zależą od etapu projektu oraz od postawionego celu kontroli. Zestawienie podstawowych metod kontroli jakości projektu programistycznego jest przedstawione w tabeli 1.

Testowanie jest podstawową metodą oceny działania wykonalnego kodu programu i najważniejszym narzędziem jego weryfikacji i walidacji. Inspekcje pełnią podobną rolę, mogą być jednak stosowane nie tylko w odniesieniu do kodu, lecz także do dokumentów projektowych, takich jak np. specyfikacja wymagań i projekt szczegółowy.

Tabela 1. Metody zapewnienia i oceny jakości (źródło: [IEEE1988])
Cel kontroli Metoda
Ocena Przegląd zarządzania
Przegląd techniczny
Weryfikacja Inspekcje projektu i kodu
Testowanie
Walidacja Testowanie
Potwierdzenie zgodności Audyt

Rola przeglądów (ang. review) i audytu (ang. audit) jest nieco inna i ma na celu skonfrontowanie rzeczywistych działań projektowych z przyjętymi założeniami, planami i standardami. O ile jednak przegląd jest wykonywany wewnętrznie przez organizację realizującą projekt, o tyle audyt jest zewnętrzną oceną, dokonywaną przez odrębny zespół niezależny od organizacji realizującej oceniany projekt. Zasadnicza różnica między tymi działaniami dotyczy więc nie metod, lecz celu działania: celem przeglądu jest poprawa sposobu prowadzenia projektu i jakości jego produktów; celem audytu jest finalna ocena zmierzająca do decyzji o akceptacji produktu lub do ustalenia przyczyn niepowodzenia.Standard IEEE/ANSI 1028 wyróżnia w procesie audytu sześć istotnych elementów, zbliżonych pojęciowo do kategorii standardów ISACA:

  • Odpowiedzialność – organizator audytu dostarcza zasoby niezbędne do przeprowadzenia audytu, organizacja podlegająca audytowi dostarcza wszelkie materiały wymagane przez audytorów.
  • Dane wejściowe – przed rozpoczęciem audytu należy określić jego cel, zakres (produkty lub procesy podlegające ocenie) i kryteria oceny oraz zebrać wstępne informacje dotyczące organizacji podlegającej audytowi.
  • Warunki rozpoczęcia – audyt rozpoczyna się po osiągnięciu zaplanowanego punktu projektu, na żądanie zleceniodawcy lub na żądanie kierownictwa projektu (w razie trudności w kontynuacji projektu).
  • Procedury
    • planowanie: plan audytu określa cel, zakres i harmonogram działań, niezbędne narzędzia, raporty opracowane w wyniku audytu oraz schemat ich dystrybucji, potrzebne zasoby i sposób postępowania;
    • przygotowanie: audytorzy powinni poznać strukturę ocenianej organizacji oraz oceniane produkty i procesy, zrozumieć cel audytu i przygotować schematy raportów;
    • badanie: metodyka pracy polega na przeglądzie organizacji pracy wykonawcy, stosowanych procedur i instrukcji, rozmowach z wykonawcami, analizie dokumentacji i testowaniu implementacji;
    • raportowanie: w pierwszej fazie audytorzy przygotowują raport wstępny, który jest udostępniany organizacji podlegającej audytowi; wszelkie uwagi tej organizacji oraz inne poprawki są uwzględniane w raporcie końcowym.
  • Warunki zakończenia – audyt uznaje się za zakończony po ocenieniu wszystkich produktów i procesów leżących w zakresie audytu, opracowaniu i udostępnieniu raportu końcowego oraz sformułowaniu zaleceń.
  • Dane początkowe – zarówno raport wstępny, jak końcowy powinny zawierać: dane audytorów, sformułowanie celu i zakresu audytu, listę ocenionych elementów wraz z wynikami oceny, podsumowanie wykrytych niezgodności. Zalecenia dalszego postępowania powinny być dostarczone organizacji podlegającej audytowi w postaci odrębnego dokumentu.

3. Model referencyjny standardu COBIT#

Opracowany przez związany z ISACA IT Governance Institute standard COBIT (ang. Control Objectives for Information and related Technology) [COBIT] definiuje referencyjny model procesów organizacyjnych związanych z funkcjonowaniem systemu informatycznego w przedsiębiorstwie.Procesy (ang. processes) zdefiniowane w ramach COBIT zostały zgrupowane w czterech dziedzinach (ang. domains):

Planowanie i organizacja

Dziedzina planowania i organizacji (ang. Planning and Organisation) obejmuje działania stanowiące najwyższy poziom i zarazem początek cyklu życia komponentów systemu informatycznego organizacji. Obejmuje ona następujące procesy:

  • PO1 Definiowanie planu strategicznego dla IT,
  • PO2 Wyznaczanie architektury informatycznej,
  • PO3 Ustalanie kierunku technologicznego,
  • PO4 Określanie organizacji i stosunków w IT,
  • PO5 Zarządzanie inwestycjami IT,
  • PO6 Przedstawianie kierownictwu celów i kierunków,
  • PO7 Zarządzanie zasobami ludzkimi,
  • PO8 Zapewnianie zgodności z wymogami zewnętrznymi,
  • PO9 Szacowanie ryzyka,
  • PO10 Zarządzanie projektami,
  • PO11 Zarządzanie jakością.

Pozyskiwanie i wdrożenie

Do dziedziny pozyskiwania i wdrożenia (ang. Acquisition and Implementation) należą działania zmierzające do zakupu lub wytworzenia rozwiązań informatycznych. Procesy składowe wchodzące w jej skład to:

  • AI1 Identyfikowanie rozwiązań,
  • AI2 Nabywanie i utrzymywanie oprogramowania aplikacyjnego,
  • AI3 Nabywanie i utrzymywanie architektury technologicznej,
  • AI4 Rozwijanie i utrzymywanie procedur IT,
  • AI5 Instalowanie i akredytowanie systemów,
  • AI6 Zarządzanie zmianami.

Udostępnianie i wsparcie

Działania należące do dziedziny udostępniania i wsparcia (ang. Delivery and Support) dotyczą udostępnienia użytkownikom oraz utrzymania pozyskanych systemów informatycznych. Procesy składowe to:

  • DS1 Określanie poziomów serwisowych,
  • DS2 Zarządzanie obcymi serwisami,
  • DS3 Zarządzanie wydajnością i pojemnością,
  • DS4 Zapewnianie ciągłości serwisów,
  • DS5 Zapewnianie bezpieczeństwa systemów,
  • DS6 Identyfikowanie i rozliczanie kosztów,
  • DS7 Edukowanie i szkolenie użytkowników,
  • DS8 Wspomaganie i doradzanie klientom IT,
  • DS9 Zarządzanie konfiguracją,
  • DS10 Zarządzanie problemami i incydentami,
  • DS11 Zarządzanie danymi,
  • DS12 Zarządzanie urządzeniami,
  • DS13 Zarządzanie operacjami.

Monitorowanie

Dziedzina monitorowania (ang. monitoring) grupuje procesy związane z nadzorem nad przebiegiem procesów należących do pozostałych dziedzin. Przynależne procesy to:

  • M1 Monitorowanie procesów,
  • M2 Ocenianie adekwatności kontroli wewnętrznej,
  • M3 Uzyskiwanie niezależnego zapewnienia,
  • M4 Otrzymywanie niezależnego audytu.

Definicja procesu

Dla każdego z procesów określone zostały:

  • cel biznesowy,
  • kryteria oceny systemu zależne od realizacji procesu, wybrane z następującego zbioru: efektywność (ang. effectiveness), wydajność (ang. efficiency), poufność (ang. confidentiality), wiarygodność (ang. integrity), dostępność (ang.availability), zgodność (ang. compliance), niezawodność (ang. reliability);
  • kluczowe wskaźniki celu – definiujące miary umożliwiające ustalenie w jakim stopniu zrealizowany został postawiony cel biznesowy,
  • kluczowe wskaźniki wydajności – definiujące miary umożliwiające ustalenie jak intensywne są działania prowadzące do osiągnięcia celu biznesowego,
  • krytyczne czynniki sukcesu – lista warunków, których spełnienie jest konieczne dla osiągnięcia celu biznesowego,
  • zasoby konieczne do realizacji procesu – wybrane z następującego zbioru: ludzie (ang. people), oprogramowanie (ang. applications), technologie (ang.technology), urządzenia (ang. facilities), dane (ang. data),
  • 6-stopniowy model dojrzałości – każdy stopień modelu jest zdefiniowany w kategoriach właściwych dla danego procesu organizacyjnego,
  • kluczowe mechanizmy kontrolne – zdefiniowane w postaci haseł,
  • szczegółowe mechanizmy kontrolne – wytyczne dotyczące przebiegu procesu, związanych z nim mechanizmów kontrolnych, wskazujące osoby lub jednostki organizacyjne odpowiedzialne za ich realizację,
  • wytyczne dotyczące poszczególnych procesu audytowego (por. p. 3).

W chwili obecnej trwają prace nad uzupełnieniem standardu COBIT o wytyczne dotyczące zastosowania konkretnych, praktycznych mechanizmów kontrolnych w ramach poszczególnych procesów (ang. control practices).

4. Proces audytu oparty na analizie ryzyka#

Opisane w poprzednich punktach standardy określają pożądane cechy procesu audytu oraz zasady jego prowadzenia, ale nie narzucają szczegółowego przebiegu prac audytowych. Zalecany w literaturze ([CISA2002]), uznany za „dobrą praktykę”, przebieg procesu audytowego jest oparty na analizie ryzyka.Definicje poszczególnych kategorii ryzyka poddawanych analizie w trakcie audytu wykorzystują pojęcie mechanizmu kontrolnego. Mechanizmami kontrolnymi (ang. controls) nazywane są dodatkowe mechanizmy techniczne i organizacyjne zmierzające do ograniczenia wpływu niedoskonałości zastosowanych w przedsiębiorstwie, podstawowych rozwiązań technicznych i organizacyjnych. Mechanizmy kontrolne są klasyfikowane jako:

  • zabezpieczające (ang. preventive) – redukujące liczbę powstających błędów, np. mechanizm organizacyjny: zatrudnianie tylko wykwalifikowanego personelu, mechanizm techniczny: zastosowanie mechanizmów umożliwiających dostęp do systemu informatycznego tylko osobom upoważnionym,
  • wykrywające (ang. detective) – wykrywające błędy, np. mechanizm organizacyjny: raporty opóźnionych płatności, mechanizm techniczny: sumy kontrolne,
  • korygujące (ang. corrective) – eliminujące lub minimalizujące efekty powstałych błędów, np. mechanizm organizacyjny: plany awaryjne, mechanizm techniczny: kopia bezpieczeństwa.

Ryzyko związane z rozwiązaniami technicznymi i organizacyjnymi oraz procesem audytowym jest klasyfikowane następująco:

  • ryzyko pierwotne (ang. inherent risk) – ryzyko wystąpienia istotnego błędu związane z zastosowanym w poddanym audytowi obszarze określonego rozwiązania technicznego lub organizacyjnego,
  • ryzyko kontroli (ang. control risk) – ryzyko wynikające z niedoskonałości zastosowanego w poddanym audytowi obszarze określonego mechanimu kontrolnego, którego zadaniem jest wykrywanie lub eliminacja błędów powstałych jako realizacja ryzyka pierwotnego,
  • ryzyko wykrycia (ang. detection risk) – ryzyko związane z niedoskonałością metod zastosowanych przez audytora, zmierzających do wykrycia słabości mechanizmów kontrolnych oraz popełnionych istotnych błędów,
  • ryzyko całkowite lub rezydualne (ang. overall/residual risk) – ryzyko związane z poddanym audytowi obszarem po przeprowadzeniu audytu, będące wypadkową wymienionych wcześniej kategorii ryzyka.

Klasyczny proces audytowy obejmuje 5 faz, które zostały szczegółowo opisane poniżej.

Zbieranie informacji i planowanie

W fazie planowania wykonywane są następujące czynności:

  • określenie obszaru poddawanego audytowi, np. np. działu lub procesu
  • sprecyzowanie celu audytu, np. ocena zarządzania lub rozwiązań technicznych,
  • sprecyzowanie zakresu audytu, np. uwzględnienie określonego przedziału czasu lub podsystemu technicznego,
  • określenie potrzebnych zasobów i umiejętności,
  • określenie źródeł informacji,
  • harmonogramowanie prac.

Analiza mechanizmów kontrolnych

Na analizę mechanizmów kontrolnych składają się następujące czynności:

  • identyfikacja mechanizmów kontrolnych w poddanym audytowi obszarze i zakresie,
  • ocena adekwatności istniejących mechanizmów kontrolnych,
  • ustalenie poziomu ryzyka w poszczególnych kategoriach.

Testowanie zgodności

Testowanie zgodności zmierza do potwierdzenia, że zidentyfikowane w trakcie analizy mechanizmy kontrolne funkcjonują zgodnie z techniczną specyfikacją systemów oraz obowiązującymi procedurami organizacyjnymi.

Testowanie dowodowe

Testowanie dowodowe ma na celu weryfikację rzeczywistej skuteczności mechanizmów kontrolnych. Jest ono stosowane przede wszystkim w odniesieniu do obszarów, w których negatywne wyniki dała ocena adekwatności lub testy zgodności mechanizmów kontrolnych.

Wykorzystanie wyników

Sposób wykorzystania wyników analiz i testów decyduje o efektywności przeprowadzonego audytu. Jedną z istotnych zasad dystrybucji wyników, warunkującą obiektywizm wniosków, jest udostępnienie wyników zarówno zarządowi firmy jak i osobom bezpośrednio odpowiedzialnym za poddany audytowi obszar.

Integralny element procesu audytu stanowi także opiniowanie procesu wdrożenia pierwotnych zaleceń audytora.

5. Podsumowanie#

Systemy informatyczne obejmują swym zasięgiem coraz szersze obszary życia. Stają się przy tym coraz większe, bardziej skomplikowane, a proces ich opracowania jest coraz kosztowniejszy. Tym samym coraz większego znaczenia nabiera problem oceny nie tylko jakości samych systemów, ale także prawidłowości procesu ich opracowania i wdrażania. Opracowanie obiektywnej oceny jest przedmiotem audytu. Sposoby przeprowadzenia audytu nie są jeszcze w pełni ujednolicone, choć istnieje już w tej dziedzinie kilka uznanych standardów. Porównanie najważniejszych standardów, przedstawione w treści tego artykułu, wskazuje na koherencję, prezentowanych przez różne organizacje, podejść do problematyki audytu oraz zgodność zalecanych praktyk i procedur. Do chwili obecnej nieustandaryzowana, pozostaje natomiast metodyka prowadzenia prac i dochodzenia do finalnych ocen audytu – w tym zakresie punktem odniesienia pozostają jedynie „dobre praktyki”.

Bibliografia#

[ACCA] strona internetowa ACCA, www.accaglobal.com.
[CISA2002] CISA Review Manual, Information Systems Audit and Control Association, 2002.
[COBIT] COBIT 3rd Edition, IT Governance Institute, 2002.
[IEEE1988] IEEE Std 1028, Standard for Software Reviews and Audits, IEEE, ANSI, 1988.
[IEEE1990] IEEE Std 610, Standard Computer Dictionary, IEEE, 1990.
[IIA] strona internetowa IIA, www.theiia.com.
[ISACA] strona internetowa ISACA, www.isaca.org.
[KIBR] strona internetowa KIBR, www.kibr.org.pl.
[PIKW] strona internetowa IKW, www.pikw.pl.

[#1] Praca finansowana z funduszu działalności statutowej PW 504/036, 2003

©2015 e-Informatyka.pl, All rights reserved.

Built on WordPress Theme: Mediaphase Lite by ThemeFurnace.