Uticaj informacione tehnologije na internu reviziju u bankama · institucije zavise od pravilnog funkcionisanja njihovih informacionih sistema. U ovom radu biće razmatrani problemi

Originalni naučni članak∗∗∗∗ UDK: 004.4:336.717.16

Danica Leko ∗∗

Uticaj informacione tehnologije na internu reviziju u bankama

Rezime: U ovom radu razmotreni su problemi suštine revizorske kontrole za aktivnosti informacionih tehnologija (IT) sa poslovnog i operativnog stanovišta. Takoñe je razmatran uticaj informacionih tehnologija na internu reviziju i tehnologiju interne revizije u upravljanju rizikom banke.

Ključne reči: interna kontrola, informacione tehnologije, upravljanje rizikom banke.

Summary: This issue deals with management information support to the internal audit proces on banks, in connection with bank risk managemnet

Keywords: intenal audit, informations technology, bank risk mamangement

1. UVOD

aktivnostima interne revizije, koje se vezuju za poslovne procese banke, pojedina pitanja treba posebno da se razmatraju zbog toga što:

− transakcije koje izvršavaju banke su vezane za rizike posebne prirode;

− značajna izloženost riziku, koja proizilazi iz oblika bankarskog poslovanja, može nastati u kratkom vremenskom periodu;

− visoka zavisnost od informatičke tehnologije postoji kod obrade transakcija;

− postoje uticaji regulative u različitim pravnim sistemima u kojima banke posluju;

∗ Rad je primljen 28. januar 2008. godine i bio je jednom na reviziji kod autora

∗∗ Société Générale Bank, Varna, Bugarska, [email protected]

U

DD .. LL ee kk oo UU tt ii cc aa jj ii nn ff oo rr mm aa cc ii oo nn ee tt ee hh nn oo ll oo gg ii jj ee nn aa ii nn tt ee rr nn uu rr ee vv ii zz ii jj uu uu bb aa nn kk aamm aa

2

− može nastati neusklañenost izmeñu neprestalnog razvoja novih usluga i bankarske prakse i tekućeg razvoja računovodstvenih principa ili internih kontrola (revizije, naročito).

Uspostavljanje dobrog funkcionisanja interne revizije u bankama zahteva (pored usvojenih poslovnih procesa sâme interne revizije), permanentno sticanje saznanja o poslovanju banke, što znači da interna revizija treba da razume, na primer, strukturu korporativnog upravljanja banaka; ekonomsko i zakonsko okruženje u zemljama u kojima banka posluje; tržišne uslove u svakom od sektora u kojima banka posluje, itd. Interna revizija treba da stekne i očuva dobro saznanje o proizvodima i uslugama koje banka nudi. Revizija stiče razumevanje prirode usluga kroz instrumente, kao što su: akreditivi, akcepti, terminske kamatne stope, SVOP aranžmani ili drugi slični instrumenti, kako bi shvatila inherentne rizike revizije i implikacije tih rizika.

Banke, u današnje vreme, sve više koriste automatizovane sisteme bazirane na informacionoj tehnologiji, kako bi procesirale podatke i dobile informacije koje omogućavaju efikasno obavljanje njihove misije. Banke i ostale finansijske institucije zavise od pravilnog funkcionisanja njihovih informacionih sistema.

U ovom radu biće razmatrani problemi suštine revizorske kontrole za aktivnosti informacionih tehnologija (IT) sa poslovnog i operativnog stanovišta. Takoñe će se razmatrati i uticaj informacione tehnologije na internu reviziju. U vezi sa navedenom problematikom biće obuhvaćen sistem upravljanja bazom podataka sa stanovišta vršenja interne revizije. Poseban osvrt u radu je dat na informacionu tehnologiju i tehnologiju interne revizije u upravljanju rizikom banke.

2. INTERNA REVIZIJA I INFORMACIONI SISTEM

Osnovu za efikasnu i efektivnu revizorsku kontrolu aktivnosti informacionih tehnologija daje britanski Pravilnik za upravljanje informacionom bezbednošću koji je (objavio britanski Institut Standarda kao BS7799 [30]) namenjen za formiranje osnove za razvoj, implementaciju i merenje upravljanja bezbednosti informacija; kao i da obezbedi poverenje da su podaci sigurni za vreme meñubankarskog elektronskog trgovanja. On pruža uputstvo i preporuke za up-ravljanje bezbednošću informacija kroz tri komponente:

� poverljivost – zaštitu osetljivih informacija od neovlašćenog otkrivanja;

� integritet – čuvanje tačnosti i potpunosti informacija;

� dostupnost – obezbeñenje dostupnosti informacija i vitalnih usluga korisnicima.

Navedeni Pravilnik sadrži čitav niz posebnih kontrola, od kojih je 10 ključnih i obaveznih kontrola koje se odnose na sledeće: politiku obezbeñenja; organizaciju obezbeñenja; klasifikaciju i kontrolu sredstava; obezbeñenje zaposlenih; fizičko obezbeñenje i obezbeñenje okruženja; upravljanje kompjuterima i mrežom; kontrolu pristupa sistemu; razvoj i održavanje sistema;

II nn dd uu ss tt rr ii jj aa 22 // 22 00 00 88 ..

3

planiranje kontinuiteta posla; usaglašavanje ovde navodimo najkraći sadržaj najznačajnijih:

� Dokumenat politike informacionog obezbeñenja – dokumenat pisane politike dostupan svim zaposlenima odgovornim za bezbednost informacija, koji potvrñuje smer upravljanja i podršku bezbednosti informacija; on sadrži definiciju, nameru, objašnjenje, odgovornost i proces prijavljivanja sumnjivih incidenata;

� Dodela odgovornosti za obezbeñenje informacija – odgovornosti za zaštitu pojedinačnih sredstava i vršenje posebnih bezbednosnih procesa treba da budu eksplicitno definisane;

� Obrazovanje i obuka za obezbeñenje informacija – korisnicima treba obezbediti adekvatno obrazovanje i tehničku obuku, što znači obuku iz organizacionih politika i procedura, uključujući zahteve za obezbeñenje i druge poslovne kontrole i obuku iz korektne upotrebe IT kapaciteta;

� Izveštavanje o incidentima u vezi sa bezbednošću – incidente u vezi sa bezbednošću treba prijaviti preko kanala upravljanja što je brže moguće; formalno prijavljivanje treba da bude uspostavljeno i praćeno zajedno sa procedurama odgovora na incident, planiranje aktivnosti koja se preduzima po prijemu izveštaja o incidentu;

� Kontrola virusa – otkrivanje virusa i preventivne mere i procedure za odgovarajuću svestnost korisnika treba da budu implementirani;

� Proces planiranja kontinuiteta posla – treba da postoji proces kojim se upravlja, da bi se plan nastavka posla razvio i održao kroz organizaciju;

� Kontrola kopiranja vlasničkog softvera – pažnju treba obratiti na zakonska ograničenja upotrebe materijala autorskih prava;

� Čuvanje organizacionih podataka – važni podaci organizacije treba da budu zaštićeni od gubitka, uništenja i krivotvorenja;

� Usaglašenost sa regulativom o zaštiti podataka – aplikacije koje sadrže lične podatke o pojedincima treba da budu u skladu sa regulativom i principima o zaštiti podataka. Principi zaštite podataka su: podaci o licima treba da budu pribavljeni i pravilno obrañeni, treba da budu čuvani samo za posebne i zakonske svrhe, ne treba da budu korišćeni i otkrivani ni na koji drugi način, lični podaci treba da budu adekvatni, relevantni, ali ne preterani, treba da budu tačni i ažurirani, treba da postoji odreñenje za lica koja krše neko od ovih principa zaštite po-dataka, lice o kome se vode podaci treba da ima pristup tim podacima u odreñenim intervalima i bez neopravdanih odlaganja ili troškova, treba da postoji obezbeñenje od neovlašćenog pristupa, upotrebe ili slučajnog gubitka ličnih informacija;

� Usaglašenost sa politikom obezbeñenja – sve oblasti unutar organizacije treba da se razmatraju radi redovnih pregleda u cilju obezbeñivanja usaglašenosti sa bezbednosnim politikama i


4

standardima; uključujući IT sisteme i provajdere sistema, informacije i vlasnike podataka, korisnike i menadžment.

Ključni faktori koji utiču na funkcionisanje informacione tehnologije su sledeći: optimalna organizaciona struktura; nadležnosti za IT funkcije; ugovori o nivoima usluga; definicije uloga i zaduženja; zahtevani operativni i tehnički standardi.

U tom smislu osnovni ciljevi kontrole (interne revizije) bili bi:

� da obezbedi uspostavljanje odgovarajuće i efikasne organizacione strukture za funkciju IT;

� da obezbedi definisanje, ugovaranje i dodelu zaduženja i odgovornosti;

� da omogući obezbeñivanje adekvatnih i odgovarajućih IT kapaciteta i veština u cilju poslovne podrške;

� da obezbedi tačnost i bezbednost sistema i podataka korisničke aplikacije;

� da obezbedi uspostavljanje, poštovanje, održavanje i ažuriranje odgovarajućeg okvira poslovnih standarda, procedura i politika;

� da obezbedi uspostavljanje, ugovaranje i mogućnost opserviranja traženih nivoa i standarda IT servisa;

� da obezbedi odgovarajuću segregaciju ključnih zaduženja u cilju zaštite integriteta operacija, sistema i podataka;

� da obezbedi mogućnost održavanja kontinuiteta operacija u slučaju nezgode ili greške;

� da obezbedi identifikovanje zahteva za stručnošću i njihovo zadovoljavanje preko stalnih obuka i razvoja zaposlenih;

� da obezbedi uspostavljanje efektivnih kanala komunikacije i svest zaposlenih o željenim performansama, kvalitetu i ciljevima usluga.

Lako su ciljevi kontrole interne revizije jasno definisani, ipak se postavlja pitanje rizika i kontrole, sa stanovišta podrške menadžmentu banke. Kao na primer:

� da li je menadžment adekvatno definisao organizacionu strukturu i zaduženja IT funkcije;

� kako je menadžment siguran da je organizaciona struktura IT funkcije najbolje primenjena da podrži obavljanje i ciljeve posla;

� da li su organizaciona struktura i posebna zaduženja zvanično ugovoreni i autorizovani;

� koji mehanizmi obezbeñuju da se dogovorene odgovornosti i zaduženja tačno i efektivno prenose zaposlenima u IT;

� kako menadžment obezbeñuje dovoljne nivoe IT kapaciteta;

� koje korake menadžment preduzima da bi obezbedio da veštine zaposlenih u IT odeljenju ostanu relevantne i ažurirane;


5

� da li je okvir autorizovanih i dokumentovanih operativnih standarda, procedura i politika postavljen i implementiran;

� kako menadžment obezbeñuje efektivno poštovanje uspostavljenih standarda, procedura i politika;

� kako menadžment prati odgovarajuću isporuku željenih i potrebnih nivoa pružanja IT usluga;

� kako menadžment sprečava mogućnost prevara od strane zaposlenih ili zloupotrebe da bi zaštitio integritet sistema i podataka;

� koji koraci se preduzimaju da bi se omogućila sposobnost operativnih IT kapaciteta za promptno i efektivno vraćanje u funkciju u slučaju nezgode ili velike greške;

� koje mere se preduzimaju da bi se obezbedili bezbednost operativnih sistema i pravilno vršenje posla;

3. INFORMACIONA TEHNOLOGIJA I NJEN UTICAJ NA INTERNU REVIZIJU

Informaciona tehnologija (IT – Information Technology) može da utiče na internu reviziju preko proučavanja i evaluacije internih računovodstvenih kontrola i mogućnosti da se koristi kompjuterom potpomognuta revizorska tehnika (CAAT – Computer Audit Assist Technique). Interni revizor mora da paralelno posmatra IT komponente i manuelne komponente sistema. Integracija IT i manuelnih kontrola omogućava revizoru da proceni sistem kao jedinicu i da kreira testove IT i manuelne kontrole da bi postigao revizorske ciljeve.

Svaka banka mora da razmotri svoju sposobnost IT revizije kada dodeljuje zaduženja IT revizije. Zadaci moraju da se zasnivaju na IT obuci internog revizora i kompleksnosti IT sistema, uključujući hardver, sistemski softver i aplikativni softver. Kompleksnost hardvera može da se proceni prvenstveno po tipu procesora, kapacitetima memorije i brojem terminala. Sistemski softver, kao što je sistem upravljanja bazom podataka ili telekomunikacioni softver mogu dodatno da doprinesu kompleksnosti sistema. Kompleksnost aplikacije se ocenjuje po funkcijama koje vrši softver i broju i sofisticiranosti podsistema i meñuspojeva (interface). On–line programi u telekomunikacionom okruženju dalje doprinose kompleksnosti obrade.

Mnogi kursevi se nude kao pomoć revizorima da steknu obuku i osnovno znanje u korišćenju kompjuterskih sistema i programa. Odeljenje interne revizije Udruženja finansijskih menadžera, Institut internih revizora, Asocijacija revizora informacionih sistema i kontrole (ISACA - Asociation Auditors IS and Control - Asocijacija revizora informacionih sistema i kontrole), lokalni fakulteti i privatne kompanije sponzorišu ovakve kurseve. Neke firme pružaju kompjuterski softver za reviziju i potrebnu obuku za interne revizore. Osim toga, izvestan broj knjiga i publikacija posvećeno je ovoj temi.


6

Banke i druge finansijske institucije pretežno koriste spoljne servisne centre. "In–house IT" pitanja su jednako primenljiva na spoljne servisne centre za obradu podataka. IT koju vrše finansijske institucije uključuje nekoliko posebnih tipova obrade. Sistem jedne institucije obično se sastoji od radnih stanica na nekoliko lokacija koje komuniciraju on–line sa centralnim kompjuterom. Institucija ili spoljni servisni centar može da poseduje centralni kompjuter. Telekomunikaciona mreža može da se sastoji od prodajnog mesta, terminala i bankomata (ATM ). On–line obrada obično se vrši tokom nekog dela dvadesetčetvoročasovnog operativnog ciklusa. Za vreme on–line obrade, blagaj-nici podnose transakcije centralnom kompjuteru, čiji "memo" knjiži transakcije na salda klijenata. Memo knjiženje pokazuje transakciju na saldu klijenata bez ažuriranja stanja. Transakcija se ne prosleñuje na račun klijenta do noćne obrade partija.

Naknadne transakcije mogu da se unesu na on–line sistem preko radnih stanica ili bankomata. Druge transakcije takoñe mogu biti unete na on–line delu sistema. Pored memo knjiženja u podacima stanja računa, razna odeljenja koriste on–line porciju sistema da bi uneli depozite i promene kamatne stope za kredite, ime klijenta i promenu adrese, nove strukture računa itd. Svake noći, kompjuterske operacije svode on–line sisteme da bi izvršili obradu partija za vreme kojih se sve transakcije od tog dana grupišu, sumiraju i koriste za ažuriranje glavnih dosijea. Dnevnici transakcija pokazuju obrañene i odbačene stavke, one se kasnije koriste u saldiranju da bi se obezbedilo pravilno kompletiranje obrade. Izveštaji koje koriste druga odeljenja u okviru institucije se takoñe produciraju tokom noćne obrade; oni sadrže zakasnele kreditne izveštaje, razne izveštaje glavne knjige, kreditne i depozitne probne bilanse, izjave klijenata, itd. Iako je obrada partija odgovarajuća za izveštaje koji moraju da se vode po utvrñenom rasporedu, neki izveštaji su potrebni samo na ad hoc bazi kao jednokratni zahte-vi. Korisnici u većini institucija veoma zavise od ličnih/personalnih kompjutera (PC) i on–line funkcija upita baze podataka, kao što je SQL (strukturisani jezik upita), za ove vrste izveštaja.

U većini institucija, revizor je prvenstveno zainteresovan za sledeće oblasti:

� menadžment i reviziju;

� razvoj i akviziciju;

� podršku i isporuku – fizičku bezbednost;

� podršku i isporuku – kompjuterske operacije;

� podršku i isporuku – integritet podataka (ulazni podaci/izlazni podaci);

� podršku i isporuku – bezbednost podataka/kontrole mreže;

� podršku i isporuku – PC, LAN, WAN, klijenta/servera;

� elektronske bankarske sisteme;

� Internet obezbeñenje i operacije.


7

Banke i ostale finansijske institucije zavise od pravilnog funkcionisanja njihovih informacionih sistema. Greške u obradi finansijskih transakcija mogu da rezultiraju velikim gubicima po instituciju, zakonskim akcijama i nezadovoljstvom klijenta. Operativni problemi koji rezultiraju zastojem u radu sistema mogu da utiče na blagovremenu obradu transakcija. Blagovremena obrada je kritična ne samo za ispunjavanje zakonskih zahteva koji se tiču dostupnosti sredstava i vremenskih ograničenja za povratne stavke, nego takoñe i za očekivanja klijenata u vezi sa telegramskim transferom i uslugama upravljanja gotovinom.

Iako je organizacija i adminstracija IT odeljenja važna u davanju ocene internog revizora o kontrolnom okruženju, okruženje unutar koga IT odeljenje radi može konačno da odredi uspeh ili grešku kontrolnog okruženja. Mnogim IT odeljenjima su data konfliktna nareñenja od strane višeg menadžmenta: smanjiti troškove i povećati aktivnosti. U većim bankama ovo može da dovede do konsolidacije IT centra i smanjenja broja zaposlenih. U manjim, nadogradnja hardvera i softvera može da se odloži, a od zaposlenih bi moglo da se očekuje da će izvršiti mnoge različite funkcije koje nisu konzistentne sa odgovarajućom segregacijom zaduženja. Izmeštanje (Outsourcing) IT funkcije je postalo popularano poslednjih godina, čak meñu većim institucijama koje su tvrdile da je in–house IT elemenat njihove "konkurentske prednosti". Ovi pritisci mogu da rezultiraju agresivnim razvojem sistema i promenom rasporeda. Da bi se ispoštovali rokovi, IT odeljenje možda ne provodi adekvatno vreme u kreiranju i testiranju sistema, što može da rezultira greškama u obradi, preteranom zastojem u radu sistema ili korisničkom neefikasnošću. Stoga, revizor mora da oceni ovlašćenje IT menadžmenta u ukupnom IT strateškom planiranju. Osim toga, revizor treba da pregleda sastav upravnog odbora IT da bi se uverio da su viši menadžment, IT menadžment i glavne korisničke grupe adekvatno predstavljeni.

Planirano vreme IT revizije je kritično za garantovanje da interni revizor razume okruženje u kome pregled treba da se izvrši. Okruženje se sastoji od mnogih pitanja za razmatranje uključujući sledeće: konfiguraciju hardvera; softver operativnog sistema; kompleksnost obrade; adekvatnost sistemske dokumentacije; organizacionu strukturu. Interni revizor treba takoñe da pregleda svaki prethodni radni papir koji se odnosi na tekući sistem i razmotri svaki raniji zaključak. Prethodno korišćene CAAT treba pregledati da bi se utvrdila njihova trenutna primenljivost.

Pošto interni revizor dobro upozna sistem, treba da se pripremi plan interne revizije. Plan može biti ograničen ili opsežan, zavisno od obima revizije, i treba da sadrži sledeće elemente:

� obim i vremenski redosled posla koji treba izvršiti;

� odreñivanje zaposlenih u internoj reviziji i njihov nivo revizorske ekspertize IT;

� planirane opšte kontrolne procedure;

� planirane procedure pregleda aplikacije;

� planirane revizorske procedure pomognute korišćenjem kompjutera.


8

Ovaj plan treba da se integriše sa drugim planiranjem interne revizije. On treba da se fokusira na rizik, zato što postoji mala potreba za ponovljenim revizorskim sistemima aplikacija čija priroda i operacije se nisu promenile. Ovakvim sistemima se obično dodeljuje niži faktor rizika i imaju širi revizorski interval nego razvojni/promenljivi sistemi ili oblasti institucije sa visokim prometom zaposlenih.

Svrha pregledanja opštih IT operativnih kontrola je da se identifikuje slabost koja mora da se razmotri u pregledima aplikacija i u kreiranju procedura interne revi-zije. Postojanje efektivne opšte IT operativne kontrole ne garantuje postojanje IT ili manuelne kontrole aplikacija. Meñutim, slabosti u opštim IT operativnim kontrolama mogu da utiču na validnost kontrola aplikacija, i interni revizor treba da poznaje ove efekte. Dokumentacija koja nastaje iz pregleda opšte IT operativne kontrole obično sadrži naraciju koja opisuje glavne oblasti u ovom odeljku. Interni revizor treba da pripremi kratak pregled slabosti i njihovog potencijalnog uticaja na reviziju. Revizor treba da uzme u obzir ove slabosti kada kreira testove interne revizije. Pregled opštih kontrola može da se podeli u pet glavnih oblasti:

� Menadžment i reviziju – revizorske procedure IT za ovo vreme revizije sadrže pregled upravnog odbora i uključenosti menadžmenta u IT, dokumentaciju, zabrinutost u vezi sa servisiranjem, osiguranjem i drugim srodnim oblastima;

� Razvoj i akviziciju – revizorske procedure IT za ovaj segment sadrže pregled izbora softvera za dobavljača, sistemske promene dobavljača i in–house sistemske promene, kontrole nad bibliotekama i programiranje funkcije gde je to odgovarajuće, promene dosijea aplikativnog parametra, sisteme izveštavanja o krajnjem korisniku i druge srodne oblasti;

� Podršku i isporuku – IT revizorska procedura za ovaj obim revizije uključuje ukupnu fizičku bezbednost, planove u slučaju nužde, planove u slučaju nepredviñenih okolnosti, skladištenje podataka i njihovo zadržavanje; kompjuterske operacije; instalirani hardver i softver, izveštavanje o problemima, procedure ulaznih podataka i kontrole montaže; usaglašavanje izveštaja o izlaznim podacima i procedure za vršenje pregleda i separaciju zaduženja. Osim toga, ova porcija uključu-je pregled bezbednosti podataka, sisteme zasnovane na PC (uključujući LAN i WAN) klijent/server sisteme, kopiranje softvera i druge povezane oblasti;

� Elektronske bankarske sisteme – IT revizorske procedure za predviñeno vreme revizije uključuju pregled kontrola tehnologije ACH, ATM telegrafskih sistema za transfer (uključujući Fedline strukturu obezbeñenja), automatizovane sisteme za upravljanje gotovinom, sisteme odgovora, PC/kućni/Internet bankarske sisteme i druge srodne oblasti;


9

� Obezbeñenje Interneta i operacija – IT revizorske procedure za ovu reviziju uključuju pregled kontrola nad pristupom Internetu od strane zaposlenih, firewall konfiguraciju i kontrolu, održavanje i ažuriranje Bančinog websajta i drugih pitanja u vezi sa Internetom.

Svrha pregleda aplikacije je: − da obezbedi nivo razumevanja aplikacije, − da identifikuje greške koje mogu da se jave u aplikaciji, − da identifikuje kontrole u okviru aplikacije i − da preliminarno utvrdi da li su identifikovane kontrole dovoljno efektivne da spreče ili otkriju greške. Da bi se ovo postiglo, interni revizor treba da razume protok transakcija i podataka kroz sistem, kontrolne elemente u okviru sistema i programe koji sadrže kontrole. Pregled aplikacije obično sadrži sledeću dokumentaciju:

� tok tabelu aplikacije koja pokazuje protok transakcija i značajne funkcije obrade i kontrolne tačke;

� organizaciju opcija u kontrolnom dosijeu aplikacije;

� karakteristike obezbeñenja aplikacije;

� meñuveze (interfaces) i kontrole da bi se obezbedilo tačno prosleñivanje podataka;

� screen walk–throughs za kritične on–line funkcije.

Identifikacija kontrolnih tačaka treba da bude dokumentovana na formularima analize kontrole koji daju kratak prikaz opservirane kontrole za manuelni i mehanizovani plan pregleda interne revizije. Da bi se izvršio pregled aplikacije, interni revizor treba prvo da pregleda svu raspoloživu dokumentaciju iz centra podataka. Ova dokumentacija može da sadrži sistemske tok tabele, narativne opise programa, raspored podataka, izvorna dokumenta i korisničke pravilnike. Interni revizor zatim intervjuiše zaposlene iznad operativnog nivoa i na operativnom nivou i analitičare i programere centra za podatke. Interni revizor treba da pojasni koliko intervjuisano lice razume sistem koji se pregleda i kontrole uključene u sistem. Pregled sistema koji vrši interni revizor je sažeto opisan u radnim papirima i fokusiran na glavne funkcije i kontrolne tačke sistema i identifikaciju kontrola. Pregled treba da ispuni ciljeve postavljene na početku revizije.

Iz ekonomskih razloga, mnoge institucije biraju da obrañuju svoje podatke u spoljnim servisnim centrima. Ciljevi internog revizora u pregledanju opštih kontrola u servisnom centru treba da budu isti kao i za IT koji vrši institucija. Prvi korak koji interni revizor treba da napravi je da odredi važnost spoljnog servisnog centra za sistem interne kontrole koji se pregleda. Ako su aktivnosti spoljnog servisnog centra značajne, interni revizor treba da pribavi informacije iz servisnog centra o njegovim kontrolnim procedurama. Revizor treba da otkrije da li je nezavisni revizor prethodno izdao izveštaj o pregledu trećeg lica u vezi sa servisnim centrom. Opšte prihvaćeni revizorski standardi obezbeñuju uputstvo o pribavljanju informacija iz spoljnog servisnog centra i pregleda trećih lica.


10

Interni revizor možda napiše dve vrste izveštaja o spoljnom servisnom centru: izveštaj o politikama i procedurama stavljenim u operaciju; i izveštaj o politikama i procedurama stavljenim u operaciju i testovima poslovne efektivnosti:

� Izveštaj o politikama i procedurama stavljenim u operaciju sadrži opis politika i procedura servisne organizacije, koje mogu biti relevantne za strukturu interne kontrole organizacije i mišljenje da li su ove politike i procedure adekvatno napravljene da bi se postigli posebni ciljevi kontrole. Ako su kontrole u servisnoj organizaciji kreirane uz pretpostavku da će izvesne procedure interne kontrole biti izvršene od strane organizacije koja je korisnik, te procedure su prikazane u opisu politika i procedura. Iako je ovaj izveštaj informativan i koristan za internu reviziju u razumevanju kontrolnog okruženja servisera, izveštaj ne nudi zaključke o efektivnosti internih kontrola zato što ih servisni revizor ne testira. Ako interni revizori nameravaju da se oslone na ove kontrole, oni će morati da vrše testove u servisnom centru;

� Izveštaj o politikama i procedurama stavljenim u operaciju i testovima poslovne efektivnosti sadrži sve što se nalazi u prvom izveštaju kao i mišljenje o efektivnom funkcionisanju testiranih politika i procedura opisanih u izveštaju. Izveštaj obezbeñuje internom revizoru pouzdanu bazu. Drugi izveštaj je poželjniji od prvog, ali revizor treba pažljivo da pregleda odeljak koji opisuje izvršene testove i rezultate testa zbog potencijalnog uticaja na instituciju. Ponekad servisni centar ne angažuje nezavisnog revizora da pripremi izveštaj o kontroli trećeg lica. U tom slučaju, revizor može biti u stanju da pribavi kopiju kontrolnih ispitivanja o servisnom centru kontaktirajući njegov ili njen primarni nadzorni organ. Interni revizor mora tada da utvrdi da li je pregled potreban, na osnovu zanačaja obrañenih računa i postojanja manuelnih kontrola po kojima institucija može da verifikuje podatke. Ako interni revizor odluči da izvrši pregled, obim treba da se zasniva istim kriterijumima koji se primenjuju na centar interne usluge. Treba sprovesti istrage slične onima za opštu i aplikacionu kontrolu. Interni revizor može takoñe da poželi da izvrši revizorske procedure uz pomoć kompjutera.

Interni revizor koji vrši pregled spoljnog servisnog centra treba da obrati pažnju na neke dodatne faktore: reputaciju servisnog centra; ugovorni odnos izmeñu institucije i servisnog centra; skladištenje rezervnih podataka; protok dokumenata izmeñu institucije i servisnog centra.

Pravni savetnik institucije treba da pregleda sve ugovore pre njihovog izvršenja. Osim toga, finansijsko stanje servisnog centra treba da se proceni bar jednom godišnje. Ako serviser odbija da sarañuje, institucija treba da razmotri promenu servisera. Dok ispitivači obično ne zahtevaju da institucije raskinu postojeće ugovore, obnavljanje ugovora bez revizije servisnog centra bilo bi uzrok za obaranje rejtinga.

Poslednjih godina, personalni kompjuteri (PC) su postali sastavni deo poslovnih operacija mnogih finansijskih institucija. Informaciona obrada se razvijala od


11

tradicionalno centralizovanog kompjuterskog okruženja do decentralizovanih operacija. Ovaj trend je doneo mnogo koristi u smislu produktivnosti i efikasnosti, ali je kritično da se kontrolne procedure centralizovanih kompjuterskih operacija prošire i primenjuju na nivou krajnjeg korisnika.

Lični računari (PC – personalni kompjuteri) se generalno koriste kao procesori reči, kao komunikacioni terminali u vezi sa drugim kompjuterima ili kao kompjuteri koji stoje zasebno. Ove tri funkcije zahtevaju različite ciljeve kontrole. Svaka funkcija zahteva odreñene operacionalne kontrole, kao što je fizičko obezbeñenje, logičko obezbeñenje i kopiranje fajlova za rezervu. Korišćenje ličnog računara kao zasebnog kompjutera može da sadrži znatan rizik po banku i može da zahteva pravilno implementirani, uniforman sistem kontrola sličan onima korišćenim na glavnom sistemu.

Nedostatak kontrole ostavlja banku otvorenu za sledeće rizike: netačne odluke menadžmenta; neodgovarajuće otkrivanje; prevaru; finansijski gubitak; zakonske ili nadzorne probleme.

Osnovne kontrole korišćenja PC računara koje treba razmotriti pripadaju trima opštim kategorijama kontrola: (1) organizaciji i administraciji, (2) operacijama i (3) razvoju i održavanju sistema.

(1) Organizacija i administracija obuhvata sledeće:

� Politike i procedure – menadžment mora da se bavi kontrolnim zahtevima upotrebe ličnih računara u svojim internim politikama i procedurama, koje treba da budu u pisanoj formi i odobrene od strane upravnog odbora. Upravni odbor nje odgovoran za uspostavljanje odgovarajućih korporativnih politika za kontrole, obezbeñenje podataka, kopiranje fajlova za rezervu, planova za nepredviñene dogañaje, revizorsku odgovornost i obuku za sve informacione sisteme. Interni re-vizor može takoñe da razmotri da li institucija ima:

− zvaničan IT odbor (ako ima, kakav je njegov sastav i efektivnosti?);

− zvaničan plan za upotrebu PC u kratkom roku (ovakvo planiranje je od vitalne važnosti za efektivnost i efikasnost sa kojom IT odgovara na promenljivu poslovnu klimu i učestvuje u njoj);

− pravi nivo osiguranja za svoje lične računare (upravni odbor treba da proveri i odobri tu politiku bar na godišnjem nivou);

� Dokumentacija – adekvatan nivo dokumentacije je suštinski u sistemima koji se zasnivaju na ličnim računarima. Softver kreiran za kupca gde je samo jedno lice uključeno u kreiranje, implementaciju i rad odreñenog programa ostavlja banku previše oslonjenu na to lice. Štaviše, uobičajeno je naći zajedničke programe i gratis programe u upotrebi na bankarskom računaru. Standardi za dokumentaciju, koji definišu odgovarajući program, operaciju ili korisničku dokumentaciju za sve PC aplikacije, bez obzira na izvor programa, treba da se uspostave;


12

� Segregacija zaduženja – zavisno od osetljivosti (ili direktnog monetarnog uticaja) informacije obrañene pomoću PC aplikacije, institucija može da zaželi da razdvoji zaduženja unosa informacija i kontrole izlaznih podataka ili vršenja zvaničnih usaglašavanja ulaznih podataka sa izlaznim. Korišćenje PC od strane autsajdera treba da bude zabeleženo i pristup kritičnim programima ili datotekama mora da bude ograničen;

� Planiranje nepredviñenih dogañaja i kopiranje za rezervu – adekvatni planovi treba da se naprave i mere predostrožnosti treba da se preduzmu da bi korisnici mogli da povrate svaki podatak izgubljen u toku oštećenja hardvera ili softvera. Svi sistemi treba da budu bezbedni i da imaju daljinsku memoriju za skladištenje kopija datoteka i programa. Interni revizor treba da razmotri da li su sledeće mere predostrožnosti preduzete: odobreni i testirani plan za nepredviñene dogañaje postoji, off–site memorija se čuva na otpornoj na vatru, kontrolisanoj lokaciji, materijalni skladišteni off–site se redovno rotira;

� Revizija – funkcija revizije treba da služi kao nezavisna kontrola korišćenja PC u celoj instituciji. Revizorske procedure i radni programi u testiranju glavnog IT sistema treba da se proširi da bi obezbedio pokriće PC sistema. Interni revizori koji koriste PC kao alatku za skupljanje informacija ili za obradu podataka treba takoñe da imaju na umu potrebu da se primeni kontrola na njihove PC operacije,

� Obezbeñenje – svi lični računari sa pristupom podacima institucije treba da imaju, u najmanju ruku, instaliran screen–saver zaštićen lozinkom. Svaki PC koji ima pristup glavnom sistemu treba da bude zaštićen lozinkom sa jedinstvenim identifikacionim (ID – Identification) karakteristikama koje omogućavaju organizaciji da utvrdi ko je započeo svaku specifičnu transakciju;

� Obuka – potrebe korisnika PC za obukom moraju da se tretiraju da bi se obezbedilo efektivno korišćenje ove moćne poslovne alatke u svakodnevnim aktivnostima.

(2) Operacije obuhvataju sledeće:

� Kontrole fizičkog pristupa – tipična lokacija za PC van fizički bezbednog centra podataka mogla bi da omogući neovlašćenim licima da dobiju pristup programima i datotekama. Ako se osetljivi podaci ili vlasnički programi odlažu na PC, restrikcije u pogledu fizičkog pristupa treba da pokriju bezbedno skladištenje komponenata PC sistema;

� Ograničenja logičkog pristupa – banke može da ima ograničenja logičkog pristupa koja identifikuju lica sa ovlašćenjem da pristupe kapacitetima PC sistema. Obično, korisničke šifre i lozinke potvrñuju da su korisnici ovlašćeni. Interni revizor može takoñe da razmotri da li se: lozinke periodično menjaju (na primer, svakih 90 dana); otkriva kršenje bezbednosnih mera sistemom i da li ih odgovarajući menadžment istražuje. U ovom pogledu, institucija treba da uspostavi radnu definiciju


13

"sumnjivih aktivnosti"; funkcije kojima razna lica imaju prava da pristupe drugačije rangiraju. Ovo može da varira od istraživačke sposobnosti do prekoračenja i sposobnosti za ispravljanjem.

(3) Razvoj i održavanje sistema obuhvata sledeće:

� Razvoj i testiranje programa – cilj razvoja sistema je da proizvode sistem ili program koji neko drugi, a ne originalni autor programa, može lako da modifikuje i održava. Da bi se obezbedila produkcija validnih i pouzdanih rezultata, institucija treba da podvrgne ceo sistem ili program istom nivou rigoroznog testa kome bi podvrgla centralizovani glavni sistem.

− Programske promene – poput glavnih sistema, PC sistemi moraju da se adaptiraju da bi odgovarali promenljivim zahtevima i okolnostima. Institucija treba da podvrgne modifikovane programe mnogim istim kontrolama kojima podvrgava nanovo razvijene programe. Modifikovani programi treba da budu potpuno testirani, a programska dokumentacija treba da opiše promenu, razlog za nastanak promene i lica odgovorna za promenu;

− Montiranje (štampanje, izdavanje) podataka – u razvoju ili kupovini PC sistema, institucija treba da obrati adekvatnu pažnju na potrebe rutinskog montiranja podataka. Kontrola je važna kako bi pokazala da li se podaci ručno unose u PC ili se preuzimaju iz drugog sistema. Ova kontrola pomaže da uneseni podaci budu bez greške i da ne doñe do pogrešnih izlaznih podataka.

Lokalne oblasne mreže. Do sada je bilo reči o zasebnom PC, tj. PC koji nije fizički povezan sa bilo kojim drugim kompjuterom. Glavno povećanje snage PC dolazi u formi lokalne oblasne mreže. U najjednostavnijoj lokalnoj oblasnoj mreži, jedna od funkcija PC je fajl–server, on je povezan sa hard disk drajvom visokog kapaciteta i laserskim štampačem. Njegov posao je da koordiniše deljenje hard diska i štampača od strane drugih ličnih računara na LAN–u (LAN – Local Area Network).

Kad LAN naraste na više od nekoliko korisnika, ona zahteva administraciju sličnu glavnom sistemu. Moraju da se kreiraju korisnički ID (Identification Code), dodeljuju lozinke, vrše kopiranja za rezervu, privremeni fajlovi čiste i završavaju drugu zadaci održavanja. Mnoge LAN pate od loše administracije mreže i stvaraju dodatne kontrolne probleme. Na primer, pošto su mnoge LAN počele kao male grupe ličnih računara, posao administratora mreže je obično vršen na privremenoj osnovi od strane jednog od korisnika PC. U stvari, nekolicini korisnika mreže su možda bile poverene privilegije administracije da bi podelili teret. Još jedna potencijalna oblast rizika je korišćenje modema sa sposobnošću "samo–odgovora" koja povećava izloženost LAN–a. Svaki pojedinačni PC sa ovakvim modemom može da se ostavi da radi noću, a udaljeni PC može da bude korišćen da se uključi u njega. Jednom kad udaljeni korisnik uspostavi


14

vezu sa PC, okretanjem njegovog telefonskog broja, korisnik može da se priklju-či na mrežu i pristupi svim njenim funkcijama. Ako je prolaz instaliran, ovo može čak i da omogući daljinski pristup preko LAN–a do glavnog sistema ili nazad do široke oblasne mreže podataka. Lokalne oblasne mreže obično ne sadrže procedure da spreče ili čak zabeleže ovaj daljinski pristup, u čemu se sastoji potencijal za gubitak ili kvarenje vrednih podataka. Dodatni firewall može da zaštiti glavni sistem od ovakvih "crvenih modema". Prvi korak da se spreči gubitak ili kvarenje podataka leži u vršenju sistematskih kopiranja za rezervu. Većina modernih mreža ima sposobnost da automatski odražava i vrši svoja sopstvena kopiranja svakodnevno. Meñutim, u nekim institucijama, pojedinci su odgovorno za svoje sopstvene kopije. Cartridge tape drives i programi za kopiranje na flopi disku su dostupni da smanje vreme potrebno za kopiranje za rezervu. Ako su podaci u riziku kritični, treba uspostaviti i pratiti strožije politike. Planovi za nepredviñene dogañaje su isto tako važni za PC kao i za glavne sisteme, pa ipak često se previde.

Banke i finansijske institucije se konektuju na Internet iz raznih razloga. Internet pristup može da bude podeljen u segmente ili ograničen na razne kategorije: E–mail (elektronska pošta), World Wide Web (svetska mreža), File Transfer Protocol (FTP – protokol transfera dosijea) i druge usluge.

Zaposleni u IT ne treba da budu odgovorni za odobravanje privilegija korisnicima za pristup Internet podacima ili informacijama koje se razmenjuju na Internetu. Umesto toga, lica koja nisu zaposlena u IT treba da preuzmu vlasništvo nad ovim sredstvima. Menadžment treba da bude odgovoran za razvoj zvaničnog procesa za odobravanje i odbacivanje svake informacije koja se nalazi na Web stranici i svih podataka i informacija koji se razmenjuju na Internetu. IT treba da bude odgovoran za pitanja obezbeñenja Interneta i administraciju korisničkog pristupa.

4. SISTEM UPRAVLJANJA BAZOM PODATAKA I INTERNA REVIZIJA

Sistemi upravljanja bazom podataka (DBMS – Databese Management System) preovlañuju u velikim bankama i finansijskim institucijama i postaju sve češće korišćeni i u srednjim i malim institucijama. Prisustvo DBMS u instituciji znači da celo okruženje obrade podataka može da se razlikuje od onog u institucijama koje ne koriste DBMS. Stoga, pre početka aplikacija, opštih kontrola ili operativne revizije IT organizacije kao celine, revizor treba da stekne razumevanje načina na koji se DBMS koristi od strane institucije. Revizor će otkriti da se u nekim institucijama koristi malo karakteristika sistema, što dovodi do revizorskog plana IT koji je veoma sličan planu za institucije bez DBMS. U veoma složenim okruženjima, revizor možda treba da vrši pregled opštih kon-trola DBMS pored ukupnog pregleda opštih kontrola IT i da planira preglede apli-kacija tako da se posebno osvrne na pitanja DBMS.

Baza podataka je zbirka logički povezanih podataka. Sistem upravljanja bazom podataka je sistemski softverski program koji deluje kao posrednik izmeñu


15

aplikacionih programa koji zahtevaju podatke i podataka u memoriji. Ona skladišti podatke prema šemi, analizira zahteve za podatke iz programa, utvrñuje gde se podaci memorišu, povlači željeni podatak i isporučuje ga aplikaciji. DBMS takoñe memoriše podatke koje aplikacija doda ili promeni.

Baze podataka se obično prave da bi se upravljalo lancima povezanih kompjuterskih aplikacija. U obradi bez baze podataka, svaka aplikacija ima svoj dosije. DBMS omogućava svim aplikacijama u lancu da imaju jednu grupu podataka. Na primer, pod DBMS, svaka depozitna aplikacija (tj. Depoziti i povlačenja, ACH, telegramski transferi, kamata, promene u uslugama) mogu da ažuriraju istu depozitnu bazu podataka. Opis karakteristika sistema baze podataka dajemo u nastavku:

Pristup podacima – Podaci su nezavisni od programa. Stoga, programeri ne treba da definišu formate podataka u okviru svake aplikacije. U okruženjima bez baze podataka, dodavanje podataka u jednom programu može da dovede do promena u definicijama podataka u stotinama drugih aplikacija. Ovo nije pitanje DBMS okruženja, zato što DBMS programi ne uključuju formate podataka. Meñutim, dostupnost podataka u DBMS rezultira povećanim sigurnosnim zahtevima.

Višak podataka – U okruženju u kome nema DBMS, jedan jedini podatak može da se ponavlja u brojnim fajlovima. Što se više ponavlja, postoji veća mogućnost da svi fajlovi neće biti ažurirani, što dovodi do nevažećih podataka i neslaganja u izveštajima. Okruženje baze podataka smanjuje višak podataka, što za uzvrat smanjuje potencijal za neslaganje podataka. Okruženje baze podataka sadrži mnoge elemente koji se razlikuju od okruženja bez DBMS. Dodatni softver, zaposleni i politike su neophodni da podrže kompleksnost ovog tipa sistema.

Karakteristike DBMS uključuju sledeće:

� DBMS softver – DBMS organizuje i održava podatke, što je komponenta sistemskog softvera. Mnoge funkcije integriteta fajlova, koje su prethodno izvršene na aplikacijama, sada vrši DBMS, uključujući verifikaciju, priključivanje, povratak u funkciju i organizaciju;

� arhitektura – baze podataka mogu da se organizuju pomoću jedne od tri strukture: hijerarhijske, mrežne ili odnosne. Arhitektura odreñuje način na koji DBMS locira i povlači podatke. U hijerarhijskoj strukturi, pristup podacima počinje na vrhu i kreće se prema dole. Mrežne strukture omogućavaju pristup podacima i na gore i na dole. Najfleksibilnija je odnosna (relaciona) struktura, u kojoj su podaci poreñeni u redovima i kolonama, i koja omogućava direktan pristup podacima. Iako su odnosne strukture više "naklonjene korisnicima" i često se koriste za ad hoc izveštavanje od strane korisnika, one zahtevaju više kompjuterskih sredstava i manje su poželjne za aplikacije sa većim obimom transakcija;

� rečnik podataka – iz razloga što podaci nisu dokumentovani i definisani u aplikacijama pod DBMS, sadržaj baze podataka treba da se dokumentuje


16

korišćenjem standardne metode u rečniku podataka. Mnogi dobavljači nude softver da bi obezbedili ovu funkciju;

� administracija baze podataka (DBA) – zahvaljujući kompleksnosti baza podataka i dodatnom održavanju sistemskog softvera, IT organizacija treba da uključi administratora baze podataka koji je odgovoran za odreñivanje podataka, dizajn baze podataka, rad i obezbeñenje baze podataka.

Pristup revizije – Primarna svrha u pregledanju sistema DBMS je da se identifikuju kontrole koje treba imati na umu u finansijskim i operativnim revizijama i kreiranju revizorskih procedura. Sistem upravljanja bazom podataka može da utiče na internu reviziju na sledeći način:

� opšte i aplikacione kontrole i procedure mogu da utiču na obradu podataka, delujući na taj način na tačnost podataka i izveštaja;

� baza podataka može da uvede jedinstvena razmatranja koja se prethodno nisu uzimala u obzir za obezbeñenje i obradu. Revizor treba da bude zainteresoan za potencijalni efekat DBMS slabosti esencijalnih elemenata računovodstvene kontrole i krajnje pouzdanosti računovodstvenih podataka koji utiču na finansijske izveštaje institucije. Interni revizor treba da razume tehnologiju DBMS pre nego što proceni njen uticaj na finansijski značajne aplikacije. Stoga, revizor treba da dobije opšte razumevanje DBMS u upotrebi preko literature, kurseva ili prethodnog iskustva. U kompleksnom DBMS okruženju, konsultacija sa IT revizorom ili sa konsultantom koji ima iskustva u DBMS tehnologiji može da bude potrebna. Kad jedna institucija koristi DBMS u jednoj ili više značajnih računovodstvenih aplikacija, interni revizor treba da izvrši reviziju DBMS. Ciljevi revizije za DBMS zavise od prirode i kompleksnosti DBMS. Revizor može da izvrši dve vrste pregleda: (1) pregled opštih kontrola DBMS fokusira se na organizaciji i administraciji, operacijama i razvoju i održavanju sistema. (2) pregled aplikacionih kontrola DBMS fokusira se na kontrolama unosa podataka, obrade, obezbeñenja i izlaznih podataka.

(1) Pregled opštih kontrola – Radna dokumentacija koja nastaje iz pregleda opštih kontrola DBMS obično sadrži narativne opise svake od oblasti navedenih u ovom uputstvu i pregled slabosti koje treba razmotriti u pregledanju i procenjivanju efektivnosti aplikacionih kontrola i kreiranju procedura interne revizije. Interni revizor treba da pribavi kopije pomoćne dokumentacije koja ilustruje značajne procedure i kontrolne funkcije. Za vreme pregleda, revizor treba da uzme u razmatranje sledeće oblasti: organizaciju i administraciju; operacije; održavanje i razvoj sistema.

Svrhe pregleda administrativnih procedura DBMS su da se utvrdi da li postoji adekvatna segregacija zaduženja u centralizaciji funkcija u okviru funkcije obrade podataka i da se utvrdi da li postoje odgovarajuće kontrole nepredviñenih dogañaja. Razvoj i implementacija sistema upravljanja bazom podataka može da rezultira promenama u organizacionoj strukturi, kao što je


17

uspostavljanje administratora baze podataka (DBA) i promena u tradicionalnim odgovornostima.

Adekvatna segregacija zaduženja unutar IT odeljenja koje koristi DBMS obično uključuje sledeće:

� kompjuterskim operaterima se zabranjuje da iniciraju i kontrolišu usluge DBMS (osim kopiranja, povratka u funkciju i reorganizacije), uključujući: odreñivanje fizičke baze podataka, definisanje logičke baze podataka, programe istraživačkog tipa;

� zaposleni koji su odgovorni za definicije struktura baze podataka, softverske i pomoćne biblioteke nemaju pravo da rade na kompjuteru bez nadzora i kontrole;

� ako više korisnika deli podatke, kontrola nad zajedničkim podacima u bazi podataka je van IT odeljenja ili, ako je u okviru IT, vrše je zaposleni koji nisu odgovorni za kompjuterske operacije, programiranje ili definiciju baze podataka.

Tamo gde nekoliko aplikacija deli nekoliko baza podataka ili jednu bazu podataka, funkcija administratora baze podataka može biti odgovarajuća. Funkcija DBA (DBA – Data Base Administration) može da bude centralizovana u zasebnoj grupi ili distribuirana meñu pojedincima koji su povezani sa svakom bazom podataka. Uspostavljanje funkcije DBA može da poveća segregaciju zaduženja u okviru IT, što inače može da bude briga kontrole. Neke od karakteristika funkcije DBA koje treba razmotriti uključuju:

� zabranu DBA iz programiranja aplikacija kompjuterske operacije, funkcije kontrole aplikacija i pristup podacima produkcije;

� angažovanje DBA u sledećim funkcijama DBMS:

− razvoju standarda baze podataka,

− nadzoru nad bezbednošću i privatnošću podataka,

− razvoju održavanja dokumentacije,

− razvoju definicija fizičke i logičke baze podataka,

− razvoju i implementaciji procedura rezervnih kopija, oporavka i reorganizacije,

− praćenju internih funkcija i tačnosti baze podataka.

Zbog kontrole nepredviñenih dogañaja, interni revizor treba da identifikuje procedure koje su u primeni da bi obezbedio tačno i blagovremeno kopiranje podataka za rezervu i ponovno uspostavljanje baze podataka. Neki od elemenata koji se obično sadrže u kontrolama nepredviñenih okolnosti baze podataka su sledeći:

� kopije baze podataka;


18

� Log fajl (fajl za beleženje) koji sadrži "pre–i–posle" slike ažuriranih elemenata;

� transakcije dostupne za rekonstrukciju baze podataka iz ranijih kopija;

� kopije definicija baze podataka, aplikacione programe, strukture logičkih podataka i DBMS softver;

� procedure za otkrivanje i ponovno uspostavljanje baze podataka posle grešaka (na primer, problemi sa DBMS softverom, bend aplikacionog programa, greške na disku, problemi operativnog softvera i hardvera);

� kopije izvora i izvršivih biblioteka za programe koji pristupaju bazi podataka;

� procedure za utvrñivanje uspešnog ponovnog uspostavljanja funkcije.

Osim toga, interni revizor treba da odredi procedure za nastavak voñenja evidencije i proizvodnih operacija bez dostupnosti baze podataka zbog privremene ili duže havarije.

Svrha pregledanja kompjuterskih operacija je da se utvrdi da li postoje dovoljne kontrole da bi se obezbedilo razumno uverenje o tačnosti i kompletnosti operativnih rezultata. Operativne kontrole treba da budu planirane tako da postižu tri osnovna cilja:

� da spreče ili otkriju slučajne greške koje se javljaju za vreme obrade u IT odeljenju;

� da spreče ili otkriju nepravilnosti ili neovlašćenu manipulaciju podataka za vreme obrade od strane IT odeljenja;

� da obezbede potreno obezbeñenje protiv slučajnog ili namernog uništenja podataka, programa ili opreme da bi se obezbedio kontinuirani rad.

Operativne kontrole i procedure se koriste u pravljenju rasporeda, procesnim procedurama i pristupu podacima.

Razvoj i održavanje efektivnog sistema obrade podataka zahteva primenu odreñenih kontrola i procedura. Ciljevi i funkcije obrade treba da se eksplicitno definišu i odobre pre nego što se potrebni programi napišu i implementiraju. Napor za održavanje i razvoj sistema u DBMS okruženju može da uključi višestruke aplikacije koje dele podatke u bazi podataka. Ova karakteristika će često zahtevati prelazak preko tradicionalne obrade podataka i organizacionih granica korisnika, čineći tako razvoj i održavanje kompleksnijim. Posledično, kontrole, procedure i standardi primenljivi na funkcije razvoja i održavanja preuzimaju čak veću važnost u DBMS okruženju.

Adekvatna kontrola produkcionih programa uključuje procedure koje omogućavaju korišćenje zasebnih programskih biblioteka za programe u fazama razvoja i produkcije. Kontrole nad promenama u DBMS koje su slične kontrolama koje se vrše za normalne produkcijske programe. Ove kontrole treba da se odnose na sledeće: definiciju baze podataka; specifikaciju logičkih


19

podataka za svaki aplikacioni program; biblioteke podrške DBMS; deljenje zahteva za promene kao garanciju da su efekti svake promene na svim aplikacijama koje koriste bazu podataka uzeti u obzir.

(2) Cilj pregleda aplikacionih kontrola je da obezbedi dovoljno razumevanje protoka transakcija u svakoj značajnoj aplikaciji u računovodstvenom sistemu institucije, da bi se revizoru omogućilo da: ▪ precizira greške ili neobične uslove koji mogu nastati u svakoj aplikaciji koja ima važnost za revizore, ▪ identifikuje da li su esencijalni elementi računovodstvene kontrole propisani u ovim aplikacijama i ▪ napravi preliminarnu procenu moguće efektivnosti ovih elemenata u sprečavanju i otkrivanju posebnih grešaka ili neobičnih uslova.

Pregled aplikacije treba da se vrši kad planiranje pokazuje da je baza podataka instalirana i da mogu da je koriste značajne finansijske aplikacije. Opšte revizorske implikacije baze podataka treba obično da se uzmu u razmatranje pre započinjanja pregleda aplikacija, tako da bi revizor mogao da koristi rezultate za vreme svakog pregleda. Obim pregleda aplikacije će zavisiti od kompleksnosti i zančaja revizije baze podataka. On treba da sadrži one procedure koje omogućavaju revizoru da razume strukturu i sadržaj baze podataka i da razume protok transakcija kroz aplikacione sisteme i uticaj baze podataka na aplikaciju.

Radna dokumentacija u vezi sa DBMS koja rezultiraju iz ovog odeljka pregleda aplikacije će obično uključivati memorandum koji identifikuje značaj baze podataka svake aplikacije i dijagrama ili narativnih delova koji opisuju strukturu svake baze podataka, finansijski značajne podatke unutar strukture baze podataka i aplikacija koje ažuriraju podatke.

Da bi se postigli ciljevi pregleda aplikacije, interni revizor može da ispita zaposlene u administraciji i sistemskom programiranju, korisničko osoblje operativnog odeljenja i zaposlene u IT koji bi inače bili kontaktirani za vreme konvencionalnog pregleda aplikacije. Posebno, interni revizor treba da izvrši sledeće zadatke:

Intervjuiše zaposlene na nivou koji je iznad operativnog nivoa da bi postigao sledeće:

– razumeo ciljeve aplikacije, korisničku organizaciju osnovanu da zadovolji ove ciljeve i odgovornosti zaposlenih u odeljenju;

– utvrdi ko inicira i/ili autorizuje modifikacije na aplikaciji i politike zadržavanja podataka za glavne i ključne fajlove sa transakcijama;

– identifikuje računovodstvene odluke koje se obično donose unutar ovog dela organizacije, svaku računovodstvenu politiku na koju se vrši uticaj i prirodu svih knjiženja izvršenih u glavnoj knjizi;

– identifikuje izveštaje o izlaznim podacima, koji se odnose na dokumenta o izvoru ulaznih podataka i razne obrañene tipove transakcija;

– identifikuje kontrolu i izvršene procedure saldiranja, procedure ustanovljene za kontrolu korekcije i ponovno podnošenje odbačenih podataka i procedure za pregled i odobrenje drugih neobičnih stavki identifikovanih za vreme obrade;


20

– identifikuje kontrole izvršene nad osetljivim i prenosivim formularima i dokumentima.

� Intervjuiše zaposlene na operativnom nivou da bi utvrdio sledeće informacije:

− vrste obrañenih transakcija i kontrolne procedure koje garantuju da su odnosni izvorni podaci autorizovani, potpuni, validni i objašnjeni;

− prirodu i stepen šifriranja i vrednovanje izvršenih funkcija;

− procedure za akumulaciju, grupisanje i voñenje kontrolnih dnevnika za unos podataka (ako se koriste terminali, razmotri kontrole transmisije podataka, koje su na snazi);

− prirodu i vremenski raspored izlaznih podataka dobijenih iz IT, izvršene procedure saldiranja, voñene dosijee i izvršena računovodstvena knjiženja;

− kriterijume za identifikaciju pogrešnih podataka i važećih procedura za korekciju, kontrolu i ponovno podnošenje;

− kriterijume koji se koriste za identifikovanje neuobičajenih stavki i izvršene procedure za pregled i odobrenja;

− izvršene procedure za voñenje i kontrolu informacija iz glavnog dosijea.

� Intervjuiše zaposlene u grupi za kontrolu ulaznih/izlaznih podataka (bilo u IT organizaciji ili nezavisnoj korisničkoj oblasti) da bi odredio sledeće:

– procedure i podatke održavane za dobijanje, priključivanje i kontrolisanje unosa podataka dobijenih od korisničkih odeljenja;

– procedure za konverziju podataka i kontrolu obrade, izvršene od strane operativne grupe IT za ovu aplikaciju;

– izveštaje o izlaznim podacima i fajlove sa drugim podacima (ako je grupa za ulazne / izlazne podatke u interakciji sa IT bibliotekarom) dobijene od IT operacija i drugih srodnih kontrola, izvršene procedure saldiranja i distribucije.

� Intervjuiše sistem analitičare i programere IT odgovorne za ovu aplikaciju, da bi verifikovao da oni razumeju procedure koje rezultiraju iz prethodnih intervjua i istraživanja dokumentacije. Sledeće oblasti su značajne za razmatranje:

− kriterijumi za identifikaciju pogrešnih podataka i neuobičajenih stavki (na pr. kriterijumi za reviziju i ažuriranje) i sledstvene procedure ispravki;

− privremene i kontrolne procedure za odbijene ili suspendovane podatke;

− Run–to–run procedure saldiranja (usaglašavanja);


21

− napravljeni izveštaji o izlaznim podacima i odnosna distribucija;

− sadržaj podataka glavnog fajla i fajla prime transakcije sa objašnjenjima značajnih podataka i strukturom kodiranja koji nisu jasni sami po sebi;

− automatski transfer podataka u druge aplikacije i iz njih, uključujući konzistentnost interpretacije podataka izmeñu aplikacija i razmatranje pravog trenutka (privremeni ili presek);

− računovodstveni podaci generisani iz kompjutera i šifre;

− značajni obračuni i formule;

− priroda i stepen modifikacije u značajnim programima za vreme revizorskog perioda i važeće kontrolne procedure za modifikaciju.

� Intervjuiše lica odgovorna za svaku bazu podataka i pregleda dokumentaciju da bi se postiglo sledeće:

− utvrñivanje finansijski značajnih elemenata u svakoj bazi podataka;

− pribavljanje ili priprema dijagrama ili narativnog prikaza svake baze podataka koji sadrže finansijski značajne podatke. Ovo treba da uključi: aplikacije koje koriste svaku bazu podataka, strukturu baze podataka, finansijski značajne podatke u okviru strukture baze podataka i aplikacije koje ažuriraju podatke.

Dokumentacija koja može da bude dostupna uključuje sledeće:

� dijagrame koji prikazuju fizičke i logičke strukture baze podataka;

� listinge koji pokazuju elemente podataka sadržane u bazi podataka;

� rečnik podataka koji za svaki elemenat podataka obezbeñuje: narativne opise elemenata podataka, fizičku bazu podataka gde može da se pronañe elemenat podataka, kriterijume za izdavanje, primenljive za elemente podataka.

Deljenje podataka izmeñu aplikacija je primarni elemenat koji prouzrokuje uticaj baze podataka na aplikaciju sa stanovišta revizije. Ako bazu podataka koristi samo jedna aplikacija, može doći do malog, ako uopšte i doñe do bilo kakvog, uticaja na pristup revizije. Ako se baza podataka, koja sadrži finansijski značajne podatke, deli izmeñu aplikacija, interni revizor treba da razmotri uticaj deljenja u sledećim pregledima aplikacija. Neki od efekata mogu da sadrže sledeće:

� kompromis tradicionalne segregacije zaduženja po postojanju deljenih podataka u bazi podataka;

� moguću izvodljivost tradicionalne kontrole ulaznih/izlaznih podataka kada korisnici dele podatke: svaka korisnička grupa može da bude odgovorna samo za svoje transakcije, nijedan pojedinačni korisnik ne može da kontroliše celokupnu bazu podataka;


22

� sažeti finansijski podaci na bazi podataka ne mogu da se usaglase sa pojedinačnom kontrolom pojedinačnih korisnika;

� zajednički podaci i meñuodnosi izmeñu deljenih podataka mogu da dovedu do toga da su odreñene aplikacije finansijski značajne, koje inače ne bi bile smatrane finansijski značajnim. (Na primer, zaseban sistem ljudskih resursa možda nije značajan, ali on može da postane takav kada se modifikuje tako da dozvoljava brojnim odeljenjima da unesu informaciju u vremenski karton, obračun plate i pohrani isplatnu listu plata i podatke računovodstva troškova direktno u mehanizovanu glavnu knjigu.)

Revizor razmatra slabosti primećene u opštim kontrolama IT baze podataka u procenjivanju uticaja baze podataka na aplikacije. Na primer, ako opšti pregled pokaže da se dosijea priključivanja ne koriste, snaga pravljenja obračuna treba da se pokaže (transakcije unosa podataka se grupišu i zadržavaju za dva ciklusa obrade, a zatim su raspoložive za ponovno knjiženje).

Procena interne kontrole je u stvari deo funkcije planiranja interne revizije. Za vreme ove faze, interni revizor treba da pribavi inicijalno upoznavanje sa organizacijom odeljenja i računovodstvenim informacionim sistemom i utvrdi da li IT aplikacije imaju značaja za reviziju i stepen do koga se koristi sistem upravljanja bazom podataka u ovim aplikacijama. Kada postoji DBMS, revizor treba da pribavi upitnik interne kontrole iz centra za podatke. koji treba da sadrže Applications Schedule User Schematic - Šemu rasporeda korisničke aplikacije) Ova informacija treba da bude integrisana sa drugom aplikacionom dokumentacijom na koju utiče DBMS. Na osnovu pregledanja upitnika interne kontrole i intervjua sa odgovarajućim zaposlenima u IT menadžmentu, interni re-vizor može da napravi preliminarnu odluku o prirodi i jačini baze podataka. Ko-rišćenje tehnologije baze podataka jedne institucije može da varira od zamene jednostavnog fajla kompleksnom strukturom. Dok nijedna karakteristika ne može da izolovano donese ovu odluku, neki od faktora za razmatranje uključuju sledeće:

� u mnogim slučajevima, baza podataka će biti zamena jednostavnog fajla, koja ima malo ili nimalo uticaja na revizorske procedure ili sposobnost revizora da vrši pregled aplikacije. Karakteristike koje mogu da pokažu bazi podataka da se radi o jednostavnoj zameni fajla uključuju: zamenu postojećeg fajla, ograničenu na jednu aplikaciju, ažuriranje kontrolisano od strane jednog korisnika, jednostavnu strukturu baze podataka;

� revizor treba da konsultuje revizora iskusnijeg u tehnologijama DBMS kad je baza podataka kompleksnija nego konvencionalna zamena fajla.

Možemo zaključiti da sledeće kontrole treba da postoje u svim sistemima:

� politika i procedure obezbeñenja za odobrenje zahteva za pristup DBMS;

� procedure za kopiranje za rezervu i povratak u funkciju;


23

� kontrole obrade, kao što je provera izdavanja, testovi validnosti itd.;

� DBA funkcija koja je odgovorna za definiciju baze podataka, kreiranje, operacije i obezbeñenje;

� rečnik podataka i dobro definisane procedure da bi se obezbedila njegova aktuelnost;

� dnevnici revizije koji sadrže dnevnike obezbeñenja, dnevnike transakcija, itd.;

� odobrenje DBA za programske promene koje utiču na DBMS.

5 . INFORMACIONA TEHNOLOGIJA I INTERNA REVIZIJA U UPRAVLJANJU RIZIKOM BANKE

U digitalnom dobu, u kome se danas nalazimo, banke koriste automatizovane sisteme bazirane na informacionoj tehnologiji da bi procesirale podatke i dobile informacije koje omogućavaju efikasno obavljanje njihove misije. Upravljanje rizikom igra kritičnu ulogu u zaštiti informacionih resursa banke, te prema tome i njene misije od specifičnih rizika vezanih za korišćenje informacione tehnologije. Efektivni proces upravljanja rizikom je važna komponenta bezbednosti savremenih informacionih sistema. Upravljanje rizikom u domenu informacionih sistema ne sme se tretirati primarno kao tehnička funkcija kojom se bave eksperti informacionih tehnologija (koji inače upravljaju funkcijama informacionog sistema), već kao esencijalna funkcija menadžmenta banke.

Upravljanje rizikom u okviru IT obuhvata sledeća tri osnovna procesa:

� identifikaciju rizika, koja se sastoji od: utvrñivanja i ocene mogućih rizičnih dogañaja u funkcionisanju informacionih sistema, odnosno informacione tehnologije na kojoj su oni zasnovani; utvrñivanja posledica rizičnih dogañaja; i utvrñivanja mera i preporuka za smanjenje verovatnoće pojave rizičnog dogañaja;

� postupak smanjenja pojave rizičnih dogañaja, što podrazumeva definisanje prioriteta, implementaciju i održavanje preporučenih mera;

� postupak evaluacije i praćenja, što podrazumeva kontinualni proces evaluacije primene mera i ključnih faktora rizika.

Upravljanje rizikom je proces koji omogućava menadžerima informacionih sistema (IS) da uravnoteže operativne i ekonomske troškove preduzetih mera i ostvare visok nivo zaštite informacionog sistema i podataka koji su bitni za misiju banke. Neophodan je visok stepen sigurnosti informacionog sistema ukoliko banka želi da se efikasno brani od uticaja rizičnih dogañaja u njenom poslovanju, što je uvek vezano i za značajna ulaganja. Dobro strukturiran sistem upravljanja rizikom pomaže menadžmentu da identifikuje odgovarajuće kontrolne mehanizme da bi se ostvario zahtevani stepen sigurnosti rada informacionog sistema pod ograničenjem raspoloživih sredstava. Sigurnost


24

informacionog sistema i upravljanje rizikom se može pogodno strukturirati u ne-koliko nivoa koji su prikazani na sledećoj slici.

Slika 1. - Piramida sigurnosti

U osnovi piramide sigurnosti je nivo fizičke sigurnosti informacionog sistema koji se obično integriše u sistem opšteg fizičkog obezbeñenja. Sledeći nivo je nivo si-gurnosti operativnog sistema koji je u principu omogućen u svim modernim operativnim sistemima (Linux, Unix, Windows) i zadatak je sistemskih inženjera da korektno implementiraju i održavaju opcije sigurnosti koje dati operativni sistem podržava. Zbog nedovoljnog stepena zaštite na nivou operativnog sistema neophodno je koristiti i nivo tzv. "security" softvera, koji omogućava visoki stepen sofistikacije sistema zaštite. Od posebnog značaja za funkcionisanje banke je nivo sigurnosti njenih baza podataka koji se ostvaruje brižljivom implementacijom opcija koje u tom smislu pružaju savremeni sistemi za upravljanje bazama podataka (Oracle, DB2, Microsoft SQL Server, Informix). Na vrhu piramide se nalazi nivo sigurnosti ERP (Enterprise Resource Planning – planiranje resursa firme) sistema kao što su (SAP, Oracle Financials, Peoplesoft) koji se danas standardno koriste kao osnovni softver za realizaciju informacionog sistema u modernim bankama.

Efektivno upravljanje rizikom se mora totalno integrisati u životni ciklus razvoja informacionog sistema i to kao iterativni proces tokom svake faze životnog ciklusa: inicijacija, razvoj ili akvizicija, imlementacija, rad i održavanje i prestanak rada.


25

U bankarskom poslovanju transakcioni rizik zauzima visoko mesto po veličini i značaju posledica na poslovanje banke. Pod transakcionim rizikom podrazumevamo tekući i budući rizik koji utiče na zarade i kapital banke a nastaje pod uticajem zlupotreba, prevara, grešaka i nemogućnosti da se plasiraju proizvodi i usluge, održi konkurentna pozicija i zaštite podaci. Transakcioni rizik je vezan za svaki proizvod i uslugu koje nudi banka. On obuhvata sve sisteme i procese kao što su razvoj proizvoda i njihov plasman, bazu informacionog sistema koja se bavi primarnim procesiranjem poslovnih transakcija, razvoj sistema, računarske sisteme i mehanizme interne kontrole.

Visoki kvantitativni nivo transakcionog rizika za dati obim transakcija, kompleksnost proizvoda i usluga i stanje razvoja bankarskih sistema je posledica visoke izloženosti riziku od zloupotreba, prevara, grešaka ili prekida procesa obrade podataka.

Kvalitet upravljanja transakcionim rizikom je nizak ukoliko:

� menadžment ne preduzima pravovremene i odgovarajuće akcije u odnosu na promene promena u funkcijama sistema, razvoj novih sistema i uvoñenje novih tehnologija;

� postoji značajna slabost u operativnim procesima, internoj kontroli informacionog sistema ili obimu i kvalitetu interne revizije transakcionog informacionog sistema;

� menadžment ne prepoznaje slabosti u sistemu obrade transakcija i ne preduzima korektivne mere;

� upravljački informacioni sistem nije dobro povezan sa transakcionim informacionim sistemom ili je nedovoljno razvijen;

� menadment nije obezbedio kontinualni i pouzdan servis spoljnih provajdera informacionih usluga;

� procesi i kontrole upravljanja i zaštite podataka imaju ozbiljne nedostatke ili uopšte ne postoje;

� neadekvatno planiranje ili nebriga izlažu banku značajnom riziku pri uvoñenju novih proizvoda i usluga, strateških inicijativa ili akvizicija; i

� menadžment ne razume ili zanemaruje ključne aspekte transakcionog rizika.

U sistemu upravljanja rizikom potrebno je:

� identifikovati rizik po funkcionalnim oblastima; u tom smislu banka mora da prepozna postojeće rizike kao i rizike koji mogu da nastanu u novim poslovnim inicijativama, tako da je to kontinualni proces sa razumevanjem rizika kako na nivou portfelja tak i na nivou transakcija;

� kategorisati rizik po profilu rizika:

− kreditni rizik (tekući i budući rizik vezan za prestanak ispunjavanja ugovornih obaveza izmeñu dužnika i banke i nastaje kadgod se


26

sredstva banke investiraju ili na bilo koji način izlažu riziku putem stvarnog ili impliciranog ugovora koji se pojavljuje u ili van bilansa stanja);

− kamatni rizik (vrlo diferenciran tekući i budući rizik koji nastaje zbog promene kamatnih stopa, zbog razlike u tajmingu promene kamatnih stopa i timinga novčanih tokova i ostalih uzroka vezanih za hartije od vrednosti);

− rizik likvidnosti (tekući i budući rizik koji nastaje ukoliko banka ne ispunjava svoje obaveze jer bi to dovelo do značajnih troškova ili se banka sučava sa neplaniranim promenama u izvorima sredstava ili nemogućnosti da učini sredstva likvidnim brzo i sa minimalnim gubitkom vrednosti);

− transakcioni rizik (tekući ili budući rizik koji utiče na zarade i kapital banke a nastaje pod uticajem zlupotreba, prevara, grešaka i nemogućnosti da se plasiraju proizvodi i usluge, održi konkurentna pozicija i zaštite podaci);

− strateški rizik (tekući i budući rizik koji nastaje zbog loših poslovnih odluka, neodgovarajućeg sprovoñenja odluka ili na nedostatak odziva na promene u bankarskom sektoru. Ovaj rizik je u vezi sa kompatibilnošću strateških ciljeva banke, poslovnih strategija razvijenih za ostvarenje tih ciljeva, resursa – direktnih i indirektnih alociranih za ostvarenje ciljeva i kvaliteta implementacije);

− rizik reputacije (rizik pojave negativnog javnog mnjenja);

� utvrditi mere za rizik kako za pojedinačni rizik (transakcioni nivo) tako i agregisani (nivo portfelja) – obično nizak, umereni i visok;

� predvideti trend rizika u sledećih godinu dana – opadajući, stabilan i rastući;

� razviti sisteme za nadzor rizika i definisati učestanost nadzora;

� definisati politiku, standarde i procedure upravljanja rizikom koje definišu odgovornosti i ovlašćenja.

U procesu interne revizije standardno se koriste sledećih pet analitičkih postupa-ka: ▪ poreñenje podataka banke sa podacima iz bankarskog sektora; ▪ poreñenje podataka banke u datom periodu sa sličnim podacima iz prethodnog perioda; ▪ poreñenje stvarnih podataka banke sa očekivanim vrednostima menadžmenta; ▪ poreñenje stvarnih podataka banke sa očekivanim vrednostima revizora; ▪ poreñenje nefinansijskih rezultata banke sa očekivanim.

Termin integrisana revizija ima poreklo iz IS terminologije (integrisani podaci i sistemi), što je i dovelo do koncepta ERP sistema (ERP – Enterprise Resource Planning – planiranje resursa firme). ERP sistem ima zadatak da podrži auto-matizaciju poslovnih procesa koristeći integrisani skup softverskih modula name-njenih automatizaciji pojedinačnih poslovnih procesa i jedinstveni korisnički interfejs i jedinstvenu bazu podataka. Prema tome, od interesa je da i proces


27

interne revizije bude potpuno integrisan u ERP. Osnovna karakteristika integrisanih sistema je integracija podataka. Svi podaci koji se tiču jednog poslovnog entiteta se čuvaju na jednom mestu, te se i ažuriranje podataka vrši samo na jednom mestu čime se obezbeñuje integritet podataka. Integrisani sistemi povezuju u jedinstenu celinu sisteme koji su tradicionalno bili razdvojeni i na taj način ruše granice i izolovanost organizacionih jedinica banke. Integralnost ERP sistema pruža značajne koristi, smanjivanjem grešaka u poda-cima, povećanom brzinom funkcionisanja poslovnih procesa putem celovitog pri-stupa informacijama. Efikasniji pristup informacijama omogućava menadžerima i zaposlenim da bolje razumeju šta se dogaña u banci i da donose bolje poslovne odluke.

Pojava ERP sistema je omogućila pojavu integrisane revizije i jedinstveni sistem kontrole poslovanja. Implementacija ERP sistema je složen poduhvat zato što uključuje masivni reinženjering poslovnih procesa sa stanovišta sigurnosti, obezbeñenja kvaliteta i obuke svih zaposlenih za rad u okruženju ERP sistema. Osnovni ciljevi revizije kontrolnih mehanizama ostaje isti u okruženju ERP sistema sa posebnom analizom relevantnosti operativne interne kontrole u odnosu na kontrole koje nudi informaciona tehnologija. U tom kontekstu posebno su važne kontrole koje se koriste u okviru savremenih SUBP (Sistem Upravljanja Bazama Podataka). Tu je posebno važna uloga Administratora baze podataka (DBA – Data Base Administrator) koji putem Rečnika podataka (Data Dictionary) obezbeñuje osnovne mehanizme kontrole za rigoroznu proveru operacija editovanja i validacije ulaznih podataka. Pošto veći broj programa ko-risti isti ulazni podatak jedna greška može da proizvede višestruke posledice. Ovo se naziva "kaskadnom" ili "kumulativnom" greškom. Većina savremenih SUBP uključuje automatske procedure restarta i oporavka stanja baze podataka da bi sprečili gubitak transakcija.

Tehnologija interne revizije je stigla do tačke razvoja u kojoj je svaki aspekt procesa interne revizije podržan nekim softverskim proizvodom. Analiza podataka, upravljanje rizikom, istraživanje zloupotreba, upravljanje dokumentima i analiza interne kontrole su, na primer, procesi koji se danas obavljaju uz pomoć aplikacija informacionog sistema. Softverske aplikacije u visokom stepenu unapreñuju efikasnost i efektivnost poslova interne revizije i proširuju obim poslova interne revizije.

Najviše zastupljena u poslovima intene revizije su softverske aplikacije namenjene ekstrakciji i analizi podataka iz poslovnih transakcija banke. Od poznatijih specijalizovanih aplikacija ove vrste navodimo ACL, IDEA, SAS i FOCUS mada je i obim korišćenja "spreadsheet" aplikacija tipa Microsoft Excel i baza podataka tip Microsoft Access veoma veliki, zbog značajno manjih troškova nabavke softvera i obuke kadrova za njegovo korišćenje.

Takoñe, u poslovima interne revizije koriste se softverske aplikacije za detekciju finansijskih zloupotreba i njihovu prevenciju. I u ovoj klasi poslova se najčešće koriste softverske aplikacije ACL, IDEA i DATAS, ali i korišćenje aplikasija "spreadsheet" tipa i baza podataka. Tipično, finansijske zloupotrebe se dešavaju korišćenjem slabosti u kontroli transakcija izmeñu departmana banke i najčešće


28

na interfejsu dve ili više softverskih aplikacija ili sistema. To se dešava zbog odsustva ili nedovoljnog kvaliteta kontrole transakcija izmeñu softverskih aplikacija raznih departmana banke, najčešće zbog nekompatibilnosti formata podataka koji se razmenjuju. Kompleksnost ovih meñuveza raste geometrijski sa bojem softverskih sistema koji razmenjuju podatke.

Metode analize podataka i odgovarajući softver omogućavaju internim revizorima brzo razumevanje struktura podataka banke i pristup specifičnim oblastima od interesa za analizu zloupotreba. Praksa analize transakcija je najmoćnija i najefikasnija metoda otkrivanja finansijskih zloupotreba. Ona se sastoji od niza testova koji su tako projektovani da otkrivaju indikatore različitih zlopotreba tako:

� što omogućavaju poreñenje podataka i transakcija iz različitih delova informacionog sistema,

� uzimaju u obzir standardne šema zloupotreba kao i specifične, vezane za pojedine funkcije banke,

� analiziraju sve transakcije unutar date oblasti i testiraju ih u odnosu na parametre koji služe kao indikatori finansijskih zloupotreba,

� sve analize obavljaju u realnom vremenu odvijanja transakcija, idealno pre finalizacije transakcije,

� kontinualno nadgledaju operativne podatke i transakcije omogućavajući rano otkrivanje zloupotreba i smanjenje finansijskuh gubitaka.

Uvoñenje ovakve metodologije otkrivanja i prevencije finansijskih zloupotreba zahteva značajne vremenske i novčane resurse, kao i visoku tehničku ekspertizu internih revizora banke. Posebno je važno, posedovati informacije o različitim tipovima mogućih finansijskih zloupotreba i stalno pratiti nova dogañanje u toj sferi. Savremeni softverski paketi koji podržavaju internu reviziju u bankama, recimo ACL (ACL – Auditing Control Language), koriste niz različitih statističkih metoda za otkrivanje zloupotreba, kao što su:

� izračunavanje karakterističnih statističkih parametara, kao što su: srednja vrednost, standardna devijacija, najveća i najmanja vrednost da bi se utvdile moguće statističke anomalije koje su prvi indikator postojanja finansijskih zloupotreba;

� klasifikacija podataka da bi se ustanovili uzorci i asocijacije izmeñu podataka;

� stratifikacija numeričkih podataka da bi se ustanovile neuobičajene vrednosti koje mogu da budu indikatori zloupotreba;

� digitalna analiza, koristeći Benford–ov zakon da bi se utvrdile statistički neverovatne vrednosti;

� spajanje i poreñenje podataka iz različitih sistema;

� testiranje duplikata da bi se identifikovali prosti i složeni duplikati;


29

� testiranje praznina u sekvencijalnim listama podataka;

� izračunavanje suma i totala da bi se proverili kontrolni totali koji mogu biti falsifikovani;

� grafičko prikazivanje podataka radi vizuelne identifikacije anomalnih transakcija.

Poznavanje činjenica o mogućim tipovima zloupotreba je kritično za izgradnju efikasnog sistema i sledeći primeri ilustruju moguće tipove zloupotreba: fiktivni dobavljači, modifikovane fakture, moguća korupcija u izboru dobavljača, duplikati faktura, duplikati plaćanja, dupli serijski brojevi.

Pojavom i sve većim korišćenjem elektronskog bankarstva javlja se i zahtev za odgovarajućim softverom za sigurnost bankarskih mreža. U ovoj klasi softvera najčešće se koriste ISS Internet Scaner, Kane Security Analyst i NetRecon. Korišćenje softverskih aplikacija za generisanje i kominikaciju dokumenata u elektronskom obliku je najraširenija softverska aplikacija u bankama. Pored standardnog integrisanog paketa za automatizaciju kancelarijskog poslovanja Microsoft Office u automatizaciji tokova dokumenata se koriste i druge aplikacije tipa IBM Lotus Domino kao i specijalizovani softver AuditSystem/2, AutoAudit, TeamMate i CARDmap.

6. ZAKLJUČNA RAZMATRANJA

Na osnovu iznetog, može se zaključiti da interna revizija banke ima značajnu ulogu u poslovima razvoja informacionog sistema. Ona je obavezna da obezbedi menadžmentu banke neophodne ulazne podatke i preporuke u poslovima: nabavke novog softvera, automatizacije poslovnih procesa, kontrole pristupa korisnika, razvoja i testiranja sistema i aplikacija, obezbeñenja softvera i hardvera od zloupotreba, implementacije novih kontrolnih procedura.

Procedura interne revizije informacionog sistema sadrži odreñene postupke koji treba da se odvijaju u sledećim iteracijama:

� Definisanje obima i ciljeva revizije;

� Utvñivanje kvalitetnog nadzora funkcionisanja informacionog sistema i angažovanja upravljačke strukture banke;

� Utvrñivanje činjenice da li upravljačka struktura banke periodično identifikuje moguće rizike u funkcionisanju informacionog sistema, da li analitički kvantifikuje ove rizike i u tom smislu ustanovljava odgovarajuće interne kontrole;

� Analiza postojećeg načina funkcionisanja informacionog sistema i njegovih resursa: računarski hardver, mrežni ureñaji, softver;

� Utvrñivanje da li postoje odgovarajući mehanizmi za kontrolu rizika vezanog za funkcionisanje informacionog sistema;


30

� Analiza postojećih medija za čuvanje podataka, načina njihove replikacije (back–up) kao i moguće geografske dislokacije rezervnih memorijskih medija;

� Utvrñivanje fizičke sigurnosti informacionog sistema i sredstava obezbeñenja;

� Utvrñivanje strategije i kontrolnih mehanizama telekomunikacionih usluga;

� Analiza kontrole produkcije i distribucije izveštaja i ostalih dokumenata;

� Utvrñivanje da li postoji odgovarajući menadžment program za slučajeve realizacije rizičnih dogañaja i mogućih problema u funkcionisanju informacionog sistema;

� Izveštavanje menadžmenta o nalazima revizije;

� Utvrñivanje kvaliteta administracije prava pristupa informacionim resursima;

� Evaluacija načina utvrñivanja autentičnosti korisnika;

� Evaluacija sigurnosti telekomunikacionih resursa;

� Evaluacija sigurnosti centralnog računarskog sistema;

� Evaluacija sigurnosti računarske opreme korisnika – radne stanice, laptop računari i ostala portabilna oprema;

� Evaluacija sigurnosti radnika informacionog sistema;

� Evaluacija sigurnosti aplikativnih sistema;

� Evaluacija sigurnosti razvoja novih softverskih sistema;

� Analiza sigurnosti sistema šifarske zaštite podataka;

� Analiza sistema nadzora sigurnosti i zaštite;

� Analiza sigurnosti usluga spoljnih provajdera (Internet i slično);

� Evaluacija kvalifikacija menadžmenta za upravljanje informacionim sistemom;

� Evaluacija kvaliteta kadrova informacionog sistema;

� Evaluacija sistema obuke kadrova.

Takoñe se može zaključiti da se primenom odreñenih softverskih alata značajno povećava efikasnost rada samih internih revizora. Naročito korišćenjem raspoloživih softverskih paketa za implementaciju kvantitativnih modela i njihovu integraciju u informacioni sistem banke. Značajno se povećavaju efikasnost i efektivnost interne revizije banke.


31

LITERATURA

1. Basle Committee on Banking Supervision "Framework for the Evolution of Internal Control Systems", 1998.

2. Basle Committee on Banking Supervision "Internal Audit in Banks and the Supervisor's Relationship with Auditors", 2001.

3. Bayuk, J.: Stepping through the IS Audit. What to Expect. How to Prepare, Information System Audit and Control Association, 1999.

4. British Standards Institute, Code of Practice for Information Security Management – BS7799, BSI, 1995.

5. Chambers, A. D., G V Rand, Auditing the IT Environment, Pitman, London, 1994

6. Chambers, A. D., G V Rand, IT–Based Risk Analysis, ICAEW, 1995

7. COBIT Control Objectives for Information and related Technology 3rd ed. Information Systems Audit and Control Foundation, 2000

8. Coderre, D.: Fraud Detection: Using Data Analysis Techniques to Detect Fraud. Global Audit Publications, 1999

9. Devargas, M.: Local Area Networks, 2nd Edition, NCC Blackwell, 1992.

10. Devargas, M.: Network Security, NCC Blackwell, 1993.

11. Doswell, R., Simons, G.L.: Fraud and Abuse of IT Systems, NCC Blackwell, 1986.

12. Drayton, D.: Information Technology Audit Handbook. Prentice Hall, 1997.

13. Gallegos, Manson, Allen–Senft. Information Technology Control and Audit. Auerbach Publications, 1999

14. Institute of Internal Auditors: Professional Standards – International Standards for the Professional Practice of Internal Auditors

15. Krist, M.: A Standard for Auditing Computer Applications. Auerbach Publications.

16. Mair, W.C., Wood, D.R. and Davis, K.W.: Computer Control and Audit, Revised Edition, Institute of Internal Auditors Inc. 1978.

17. Metodologija i procedure interne revizije, Societe Generale Bank, 2005.

18. Nugus, S., Harris, S.: PC Data Recovery and Disaster Prevention, NCC Blackwell, 1992.

19. O’Shea, G.: Security in Computer Operating Systems, NCC Blackwell, 1991.

20. Polić, S.: Potrebna znanja i način rada internog revizora u digitalnom poslovnom okruženju, "Revizor", Beograd, 2005.

21. Standards and Guidelines for Information Systems Audit and Control Professionals. Information Systems Audit and Control Association, 2000.

22. Vallabheneni, S. Rao. Auditing Computer Security – A Manual with Case Studies. John Wiley & Sons, 1989.

23. Webber, Ron. Information Systems Control and Audit. Prentice Hall, 1999.

Documents

Uticaj informacione tehnologije na internu reviziju u bankama · institucije zavise od pravilnog funkcionisanja njihovih informacionih sistema. U ovom radu biće razmatrani problemi