Smjernice Za Upravljanje Informacijskim Sustavom

SMJERNICE ZA UPRAVLJANJE
INFORMACIJSKIM SUSTAVOM U CILJU

SMANJENJA OPERATIVNOG RIZIKA
OUJAK 2006.
Hrvatska narodna banka
Smjernice za upravljanje informacijskim sustavom u cilju smanjenja operativnog rizika
Sadraj
1. Uvod ....................................................................................................................................... 4
1.1. Temeljna naela informacijskog sustava......................................................................... 6
1.2. Ciljevi, strategije i ostali interni akti ............................................................................... 7
1.3. Sigurnost informacijskog sustava.................................................................................... 8
1.4. Elementi upravljanja rizikom .......................................................................................... 9
2. Upravljanje informacijskim sustavom.................................................................................. 13
2.1. Uprava banke................................................................................................................. 16
2.2. Voditelj organizacijske jedinice za informacijsku tehnologiju ..................................... 17
2.3. Voditelj sigurnosti informacijskog sustava ................................................................... 18
2.4. Odbor za upravljanje informacijskim sustavom............................................................ 19
2.5. Upravljanje projektima.................................................................................................. 21
3. Upravljanje rizikom informacijskog sustava........................................................................ 23
3.1. Procjena rizika ............................................................................................................... 24
3.2. Smanjivanje rizika ......................................................................................................... 30
3.3. Kontrole......................................................................................................................... 33
3.4. Klasifikacija informacija ............................................................................................... 35
4. Unutarnja revizija ................................................................................................................. 36
5. Sigurnost informacijskog sustava......................................................................................... 38
5.1. Politika sigurnosti informacijskog sustava.................................................................... 39
5.2. Upravljanje kontrolama pristupa ................................................................................... 40
5.3. Kriptografija .................................................................................................................. 47
5.4. Fizika sigurnost............................................................................................................ 48
5.5. Upravljanje operativnim i sistemskim zapisima............................................................ 49
5.6. Zatita od malicioznog koda.......................................................................................... 51
6. Odravanje informacijskog sustava...................................................................................... 53
6.1. Upravljanje imovinom informacijskog sustava............................................................. 53
6.2. Upravljanje promjenama ............................................................................................... 55
6.3. Upravljanje konfiguracijama ......................................................................................... 57
6.4. Dokumentacija............................................................................................................... 58
6.5. Izobrazba ....................................................................................................................... 59
7. Planiranje kontinuiteta poslovanja ....................................................................................... 61
7.1. Analiza utjecaja na poslovanje ...................................................................................... 63
7.2. Plan kontinuiteta poslovanja.......................................................................................... 65
7.3. Plan oporavka ................................................................................................................ 66
7.4. Upravljanje incidentima ................................................................................................ 67
7.5. Upravljanje priuvnom pohranom................................................................................. 70
8. Razvoj sustava i eksternalizacija .......................................................................................... 72
8.1. Razvoj informacijskih sustava unutar banke................................................................. 72
8.2. Eksternalizacija (dijela) informacijskog sustava ........................................................... 76
9. E-bankarstvo......................................................................................................................... 82
9.1. Uvod .............................................................................................................................. 82
9.2. Rizici povezani s e-bankarstvom................................................................................... 84
9.3. Upravljanje rizikom e-bankarstva ................................................................................. 85
10. Zakljuci i preporuke.......................................................................................................... 92
1. Uvod
Osnovna naela u poslovanju banaka jesu naelo likvidnosti i naelo solventnosti. Kako bi
osigurale poslovanje u skladu sa spomenutim naelima, banke su dune kontinuirano obavljati
mjerenje, procjenu i upravljanje svim rizicima kojima su u svom poslovanju izloene. Rizici
kojima su banke izloene u svom poslovanju i za koje minimalno moraju biti propisani
postupci mjerenja, procjene i upravljanja ukljuuju i rizik koji proizlazi iz neadekvatnog
upravljanja informacijskim i pridruenim tehnologijama. Hrvatska narodna banka uoila je
potrebu da se bankama radi osiguranja sigurnosti i stabilnosti bankarskog poslovanja u
Republici Hrvatskoj skrene pozornost na pitanja vezana uz rizik koji proizlazi iz
neadekvatnog upravljanja informacijskim i pridruenim tehnologijama.
Banke u svom poslovanju ovise o koritenju informacija. Pravodobne, tone i potpune
informacije, s obzirom na njihov utjecaj na poslovanje i odluivanje, kljune su za
ostvarivanje poslovnih ciljeva.
Informacijska tehnologija omoguuje koritenje i upravljanje informacijama odnosno
podrava i unapreuje poslovne procese kako bi se to djelotvornije ostvarivali poslovni
ciljevi i postigla konkurentska prednost. Meudjelovanje informacijske tehnologije, podataka
i postupaka za procesiranje podataka te ljudi koji prikupljaju i koriste navedene podatke ini
informacijski sustav. Drugim rijeima, informacijski je sustav sveobuhvatnost infrastrukture,
organizacije, ljudi i postupaka za prikupljanje, obradu, generiranje, pohranu, prijenos, prikaz,
distribuciju informacija i raspolaganje njima.
S obzirom na ubrzani razvoj i sveprisutnost informacijske tehnologije u poslovnom
okruenju, uporaba informacijskih sustava:
jest jedan od kljunih imbenika u poslovanju banke;
poveava meudjelovanje raznih sustava, jer se informacijski sustavi banke povezuju s
klijentima, pruateljima usluga te ostalim subjektima preko javno dostupnih i
privatnih telekomunikacijskih mrea;
postavlja temelj za razvoj novih proizvoda i usluga te utjee na oblikovanje
konkurentskih prednosti;
pokree reinenjering strateki vanih poslovnih procesa;
poveava potrebu za novim ulaganjima u resurse informacijskog sustava;
zahtijeva usvajanje i primjenu novih strunih znanja.
Iz navedenog proizlazi da je koritenje informacijske tehnologije u svim aspektima
bankarskog poslovanja stvorilo veliku ovisnost o informacijskoj tehnologiji pa je prema tome
potrebno posvetiti veliku pozornost upravljanju informacijskim sustavom kao sastavnom
dijelu upravljanja bankom u cjelini. Nadalje, u sklopu upravljanja informacijskim sustavom
posebnu pozornost potrebno je obratiti upravljanju rizikom koji proizlazi iz koritenja
informacijskog sustava, kako bi se osiguralo pouzdano, sigurno i kontinuirano poslovanje
banke.
Rizici se procjenjuju s aspekta uinka koji bi mogao biti uzrokovan naruavanjem
funkcionalnosti i sigurnosti informacijskog sustava, odnosno naruavanjem temeljnih naela
informacijskog sustava (objanjava se u nastavku dokumenta). Upravljanje rizikom
informacijskog sustava, za potrebe ovog dokumenta, obuhvaa postupke procjene rizika te
poduzimanja radnja za smanjenje rizika na prihvatljivu razinu i odravanje prihvatljive razine
rizika. Poveani rizik informacijskog sustava proizlazi iz neprimjerenog koritenja i

upravljanja resursima informacijskog sustava, te moe poveati financijski, strateki,
operativni, reputacijski i pravni rizik.
1.1. Temeljna naela informacijskog sustava

Funkcionalan i siguran informacijski sustav mora se zasnivati na sljedeim temeljnim
naelima:
1. povjerljivosti: svojstvu da informacije ne budu dostupne ili otkrivene neovlatenim
subjektima;
2. integritetu: svojstvu da informacije i procesi nisu neovlateno ili nepredvieno
mijenjani;
3. raspoloivosti: svojstvu koje omoguuje pristup i upotrebljivost na zahtjev ovlatenog
subjekta;
4. neporecivosti: svojstvu koje osigurava nemogunost poricanja izvrene aktivnosti ili
primitka informacije;
5. dokazivosti: svojstvu koje osigurava da aktivnosti subjekta mogu biti praene
jedinstveno do samog subjekta;
6. autentinosti: svojstvu koje osigurava da je identitet subjekta zaista onaj za koji se
tvrdi da jest;
7. pouzdanosti: svojstvu dosljednog, oekivanog ponaanja i rezultata.
Neporecivost, dokazivost, autentinost i pouzdanost mogu se promatrati i kao kombinacija
naela povjerljivosti, integriteta i raspoloivosti.
Posljedice naruavanja temeljnih naela informacijskog sustava jesu:
Gubitak integriteta. Integritet sustava i podataka odnosi se na potrebu da informacije
budu zatiene od neovlatenih ili neispravnih izmjena. Neovlatene ili neispravne
izmjene dovode do gubitka integriteta. Ako integritet sustava ili podataka nije ponovo
uspostavljen, nastavak koritenja takvim sustavom ili podacima moe dovesti do
netonosti, prijevara ili pogrenih odluka. Isto tako, povreda integriteta moe biti prvi
korak u naruavanju raspoloivosti ili povjerljivosti sustava. Zbog tih razloga gubitak
integriteta smanjuje povjerenje u informacijski sustav.
Gubitak raspoloivosti. Neraspoloivost informacijskog sustava potrebnog za
obavljanje zadatka moe negativno utjecati na ciljeve banke i kontinuitet poslovanja te
onemoguiti odvijanje vitalnih poslovnih procesa. Gubitak funkcionalnosti sustava i
operativne djelotvornosti (uinkovitosti) moe, primjerice, dovesti do naruavanja
reputacije banke, rezultirati gubitkom produktivnog vremena te onemoguiti krajnjeg
korisnika u izvravanju radnih zadataka.
Gubitak povjerljivosti. Neovlateno, neoekivano ili nenamjerno otkrivanje ili
objavljivanje podataka moe rezultirati gubitkom povjerljivosti sustava i podataka.
Gubitak povjerljivosti moe dovesti do tekih povreda vaeih propisa te utjecati na
gubitak povjerenja javnosti i naruavanje reputacije banke, a moe prouzroiti i
pokretanje sudskog postupka protiv banke.
Pojam "temeljna naela informacijskog sustava" u nastavku dokumenta, ovisno o kontekstu,
podrazumijeva jedno naelo ili kombinaciju naela povjerljivosti, integriteta, raspoloivosti,
neporecivosti, dokazivosti, autentinosti i pouzdanosti.
1.2. Ciljevi, strategije i ostali interni akti

Ciljevi, strategije i ostali interni akti banke trebaju biti definirani tako da budu temelj za
djelotvorno upravljanje informacijskim sustavom te da podravaju poslovne procese i
temeljna naela informacijskog sustava. Ciljevi odreuju to treba ostvariti, dok strategije
odreuju kako ostvariti postavljene ciljeve. Ciljevi, strategije i ostali interni akti trebaju se
razvijati hijerarhijski od upravljake prema operativnoj razini te trebaju:
odraavati potrebe organizacijskih jedinica unutar banke
uzeti u obzir organizacijska i druga ogranienja
osigurati dosljednost na svim razinama.
Strategije i ostale interne akte potrebno je odravati i aurirati u skladu s promjenama
poslovnih ciljeva i rezultatima periodinih provjera (primjerice procjenama rizika, revizijama
informacijskog sustava) te u skladu s promjenama u okruenju.
1.3. Sigurnost informacijskog sustava

Banke pri obavljanju svojih poslovnih aktivnosti uvelike ovise o obradi i upotrebi
informacija. Naruavanje temeljnih naela informacijskog sustava moe imati negativne
posljedice za banku. Stoga je potrebno primjereno zatititi informacije i upravljati sigurnou
informacijskog sustava banke. Potreba za zatitom informacija i upravljanjem sigurnou
posebice je vana u dananjem okruenju jer su informacijski sustavi banaka povezani s
drugim informacijskim sustavima.
Upravljanje sigurnou informacijskog sustava jest, izmeu ostalog, sveobuhvatan, detaljan i
sustavan proces identificiranja potreba (radi ostvarivanja zadovoljavajue razine sigurnosti) te
postizanja i odravanja zadovoljavajue razine sigurnosti informacijskog sustava.
1.4. Elementi upravljanja rizikom

1.4.1. Resursi informacijskog sustava
Pravilno upravljanje resursima informacijskog sustava kljuno je za uspjeh banke i za njega
su odgovorne sve upravljake razine. Resursi, uz ostalo, ukljuuju:
1. opipljivu imovinu (primjerice hardver, komunikacijsku opremu, graevine)
2. informacije/podatke (primjerice dokumente, podatke u bazama podataka)
3. softver
4. sposobnost proizvodnje nekog proizvoda ili pruanja neke usluge (engl. know-how)
5. osobe koje odravaju i koriste informacijski sustav
6. neopipljivu imovinu (primjerice zatitni znak, reputaciju).
Banka bi trebala identificirati i klasificirati resurse prema njihovoj vanosti i vrijednosti te
odrediti i implementirati potreban stupanj zatite tih resursa.
Proces identificiranja resursa i utvrivanja njihove vanosti i vrijednosti moe biti obavljen na
najvioj razini i ne mora ukljuivati skupe, detaljne i vremenski zahtjevne analize. Detaljnost
analize utvruje se na temelju postavljenih funkcionalnih i sigurnosnih ciljeva te bi se morala
mjeriti u kontekstu utroenog vremena i nastalih trokova u odnosu na vanost i vrijednost
resursa. Obiljeja resursa koja pritom treba uzeti u obzir jesu njihova vrijednost i osjetljivost,
te eventualna inherentna zatita. Funkcionalne i sigurnosne potrebe resursa ovise o njihovoj
ranjivosti u prisutnosti odreene prijetnje.
1.4.2. Prijetnje
Resursi su izloeni raznim vrstama prijetnja. Prijetnja moe prouzroiti neeljenu situaciju
ija posljedica moe biti nanoenje tete resursima banke. Drugim rijeima, teta moe nastati
kao posljedica ostvarenja prijetnje (primjerice neovlatenog unitavanja, razotkrivanja,
promjene te unoenja promjena koje uzrokuju pogreno zapisivanje, nedostupnost ili gubitak
informacija). Prijetnja mora iskoristiti postojeu ranjivost resursa da bi se realizirala i
rezultirala tetom. Prijetnje mogu biti prirodne ili uzrokovane ljudskim djelovanjem (sluajne
ili namjerne). Stoga je potrebno tono utvrditi prijetnje kao i njihovu razinu i vjerojatnost.
Primjeri prijetnja prikazani su u tablici br. 1:
Tablica br. 1 Primjeri prijetnja
Ljudske
Namjerne
prislukivanje
modifikacija informacija
"hakiranje"
maliciozni kod
kraa
Sluajne
pogreke i propusti
nenamjerno brisanje datoteka,
podataka i sl.
pogreno preusmjeravanje
nenamjerno fiziko unitenje
Prirodne
potres
udar groma
poplava
poar
Dostupni su statistiki podaci o mnogim vrstama prijetnja koje bi banka trebala pribaviti i
iskoristiti prilikom procesa procjene ranjivosti u svezi s odreenom prijetnjom. Prijetnja se
moe pojaviti unutar banke (primjerice u obliku sabotae nekog od zaposlenika) ili izvan nje,
(primjerice u obliku zlonamjernih "hakera" ili industrijske pijunae). teta koju nanose takvi
neeljeni dogaaji moe biti prolazne prirode ili trajna (u sluaju potpunog unitenja resursa).
Opseg tete uzrokovane prijetnjom moe se razlikovati prema neeljenom dogaaju. Virus,
kao primjer malicioznog koda, moe uzrokovati razliitu razinu tete ovisno o svom
djelovanju.
Prijetnje je esto mogue kvantificirati i/ili kvalificirati kako bi se ocijenila njihova razorna
mo (primjerice virus se moe opisati kao destruktivan ili nedestruktivan, a jaina potresa
moe se opisati na temelju Richterove ljestvice).
Neke prijetnje mogu utjecati na vie od jednog resursa te mogu imati razliit uinak ovisno o
kojem se resursu radi (primjerice virus na osobnom raunalu moe imati ograniene ili
lokalne posljedice, dok uinak istog virusa na mrenom posluitelju moe biti puno iri).
Svaka prijetnja ima obiljeja koja pruaju korisne informacije o samoj prijetnji. Primjeri
takvih korisnih informacija ukljuuju:
1. izvor (primjerice je li rije o unutranjoj ili vanjskoj prijetnji)
2. motiv (primjerice ostvarivanje financijske dobiti, ostvarivanje konkurentske prednosti)
3. uestalost pojavljivanja
4. razornu mo.
Prijetnje je mogue okarakterizirati prema razini i vjerojatnosti pojedine prijetnje (primjerice
kao velike, srednje i male).
1.4.3. Ranjivost
Ranjivost je slabost koju je mogue sluajno aktivirati ili namjerno iskoristiti, a posljedica
toga moe biti nanoenje tete informacijskom sustavu i poslovnim ciljevima. Ranjivosti koje
se povezuju s resursima ukljuuju, izmeu ostalog, slabosti fizike sigurnosti, organizacije,
internih akata, zaposlenika, upravljake strukture, hardvera, softvera i informacija.
Ranjivost sama po sebi ne nanosi tetu, nego ranjivost moemo definirati kao stanje ili skup
stanja koji moe omoguiti nekoj prijetnji da utjee na resurse (primjerice nedostatak
mehanizama kontrole pristupa jest ranjivost koja bi mogla omoguiti ostvarenje prijetnje
neovlatenog pristupa, to moe dovesti do gubitka ili oteenja resursa). Budui da se
okruenje moe brzo promijeniti, potrebno je pratiti sve oblike ranjivosti kako bi se
identificirale one koje su postale izloene starim i novim prijetnjama. Analiza ranjivosti je
procjena slabosti koje identificirane prijetnje mogu iskoristiti. Ta bi analiza trebala uzeti u
obzir okruenje i postojee zatitne mjere i kontrole. Ranjivost u odnosu na neku prijetnju
pokazatelj je lakoe kojom je mogue natetiti sustavu ili resursima.
Ranjivost se moe okarakterizirati ovisno o ishodu analize ranjivosti (primjerice kao velika,
srednja i mala).
10
1.4.4. Uinak
Uinak je posljedica nekoga neeljenog dogaaja, izazvanog namjerno ili sluajno, koji utjee
na resurse. Posljedice mogu biti unitenje nekog resursa, nanoenje tete informacijskom
sustavu te gubitak temeljnih naela informacijskog sustava ega rezultat moe biti (to moe
prouzroiti) financijski gubitak i gubitak trinog udjela ili reputacije banke.
Uestalost pojave neeljenog dogaaja takoer treba uzeti u obzir, posebice kada je razina
tete poinjene svakim dogaajem niska, ali ukupan uinak veeg broja dogaaja s vremenom
moe biti znatan. Analiza uinka vaan je element procjene rizika i odabira zatitnih mjera.
Kvantitativna i kvalitativna mjerenja uinka mogu biti provedena na razliite naine, kao to
su:
utvrivanje trokova
pridruivanje neke empirijske skale za njegovo mjerenje (npr. od 1 do 10)
upotreba unaprijed odreenog naina stupnjevanja (npr. mali, srednji i veliki).
1.4.5. Rizik
Rizik je funkcija vjerojatnosti da e identificirani izvor prijetnje iskoristiti odreenu ranjivost
i uinka koji taj neeljeni dogaaj moe imati na banku. Drugim rijeima, rizik obiljeava
kombinacija dvaju faktora, a to su vjerojatnost da e se neeljeni dogaaj dogoditi te njegov
uinak. Svaka promjena resursa, prijetnja, ranjivosti ili zatitnih mjera moe znatno utjecati na
rizik. Rano otkrivanje te prepoznavanje promjena koje su nastale u okruenju ili sustavu
poveava mogunost pravodobnog poduzimanja koraka potrebnih za smanjivanje rizika.
1.4.6. Mjere
Mjere ukljuuju sve postupke, procedure i mehanizme kojima se:
tite resursi informacijskog sustava od prijetnja;
smanjuju ranjivosti informacijskog sustava;
ograniava uinak neeljenih dogaaja;
otkrivaju neeljeni dogaaji;
pospjeuje oporavak.
Budui da mjere smanjuju izloenost banke riziku, moemo ih smatrati i zatitnim mjerama.
Zatitne se mjere odnose na upravljaku, logiku i fiziku razinu. Djelotvorno upravljanje
informacijskim sustavom obino zahtijeva kombiniranje razliitih zatitnih mjera kako bi se
osigurala slojevita zatita resursa informacijskog sustava.
Zatitne mjere imaju jednu od sljedeih uloga ili vie njih:
1. prevencije
2. odvraanja
3. otkrivanja
4. ograniavanja
11
5.
6.
7.
8.
korigiranja
oporavka
nadzora
osvjeivanja.
Zatitne se mjere provode uvoenjem novih ili izmjenom postojeih kontrola. Podizanje
razine znanja i svijesti zaposlenika vezanih uz sigurnost i funkcionalnost informacijskog
sustava vana je zatitna mjera.
1.4.7. Preostali rizici

U veini sluajeva provedba zatitnih mjera ne uklanja u potpunosti rizike, to upuuje na
postojanje preostalih (rezidualnih) rizika.
Upravljake strukture trebaju biti svjesne svih preostalih rizika sa stajalita njihova mogueg
uinka i vjerojatnosti pojave negativnog dogaaja, te donijeti odluku o prihvaanju preostalih
rizika kojima je izloen informacijski sustav.
1.4.8. Ogranienja
Pri odabiru i provedbi mjera potrebno je uzeti u obzir ogranienja kao to su:
1. organizacijska ogranienja
2. financijska ogranienja
3. ogranienja odreenog okruenja
4. ogranienja vezana uz ljudske resurse
5. vremenska ogranienja
6. pravna ogranienja
7. tehnika ogranienja
8. kulturoloka i drutvena ogranienja.
Veinu navedenih ogranienja obino postavljaju upravljake strukture banke, te na njih
utjee okruenje u kojem banka posluje. Isto tako, potrebno je periodino revidirati
ogranienja kako bi se identificirala nova ogranienja i uoile promjene ve poznatih
ogranienja.
12
2. Upravljanje informacijskim sustavom

Cilj upravljanja informacijskim sustavom jest podravanje poslovnih ciljeva i strategije banke
uz efikasno koritenje resursa informacijskog sustava te primjereno upravljanje rizicima koji
proizlaze iz koritenja informacijske tehnologije. Uspjeno upravljanje informacijskim
sustavom rezultira postizanjem optimalnog uinka informacijske tehnologije, te naposljetku
daje dodatnu vrijednost poslovanju. Nadalje, upravljanje informacijskim sustavom odnosi se
na sve osobe, sustave i procese koji svojim aktivnostima vezanim uz informacijski sustav
pridonose ispunjavaju poslovnih ciljeva i strategije banke, te postizanju i odravanju
temeljnih naela informacijskog sustava.
Primjereno upravljanje informacijskim sustavom ukljuuje, meu ostalim, i uspostavu:
adekvatne organizacijske strukture (primjerice organizacijske jedinice za
informacijsku tehnologiju, organizacijske jedinice za upravljanje rizikom)
odgovarajuih funkcija i odbora (kao to su voditelj organizacijske jedinice za
informacijsku tehnologiju, voditelj sigurnosti informacijskog sustava, odbor za
upravljanje informacijskim sustavom)
procesa upravljanja rizikom informacijskog sustava (procjene rizika, poduzimanje
radnja za smanjenje rizika na prihvatljivu razinu i odravanje prihvatljive razine
rizika) i nadzora nad tim procesom.
Nadalje, upravljanje informacijskim sustavom treba obuhvatiti sljedea podruja:
sigurnost informacijskog sustava
planiranje kontinuiteta poslovanja
razvoj sustava i eksternalizaciju
odravanje informacijskog sustava.
Banka bi trebala uspostaviti organizacijsku jedinicu za informacijsku tehnologiju koja bi
trebala pruati adekvatnu informatiku podrku ostalim organizacijskim jedinicama. Pri
odreivanju organizacijske strukture i definiranju funkcija organizacijske jedinice za
informacijsku tehnologiju potrebno je osigurati adekvatnu podjelu zadataka i ovlasti.
Navedeno je potrebno kako bi se osiguralo prikladno rasporeivanje resursa za sve funkcije
organizacijske jedinice za informacijsku tehnologiju i adekvatno razdvajanje (segregiranje)
dunosti.
Upravljanje informacijskim sustavom banke trebalo bi biti predmetom nadzora unutarnje
revizije kako bi se neovisno i objektivno provjerila adekvatnost upravljanja tim sustavom.
Strategija i planiranje
Banka bi trebala donijeti strategiju informacijskog sustava koja treba biti usklaena s
poslovnom strategijom banke. Strategija informacijskog sustava trebala bi obuhvatiti
dugorone i kratkorone inicijative povezane s informacijskim sustavom, pri emu valja uzeti
u obzir barem sljedee:
nove poslovne inicijative
organizacijske promjene
tehnoloki razvoj
13
regulatorne zahtjeve
potrebe za resursima i nadzorom
ogranienja.
Nadalje, strategija informacijskog sustava trebala bi biti formalno dokumentirana, odobrena

od strane uprave banke te aurirana i revidirana na godinjoj razini. Strategiju informacijskog
sustava potrebno je razraditi donoenjem stratekih i operativnih planova.
Strateko planiranje vezano uz informacijski sustav usredotoeno je na srednji rok te pomae
osigurati dosljednost primjene i usklaenost tehnolokih planova s poslovnim ciljevima
banke. Uspjeno strateko planiranje treba osigurati informatiku podrku kojom bi se odrala
ravnotea trokova i djelotvornosti te istodobno omoguilo poslovnim organizacijskim
jedinicama da adekvatno odgovore na zahtjeve trita. Isto tako, potrebno je procijeniti
potrebna financijska sredstva.
Prilikom planiranja informacijskih sustava potrebno je razmotriti barem sljedee imbenike:
poslovne ciljeve i planove banke
uvjete na tritu
planirani rast banke
tehnoloke standarde
vaee propise
kontrolu trokova
unapreenje procesa i porast djelotvornosti
kvalitetu usluga pruenih klijentima banke
usporedbu eksternalizacije procesa i provoenja procesa unutar banke
optimalnu infrastrukturu
sposobnost usvajanja i uvoenja novih tehnologija
ogranienja.
Operativno planiranje proizlazi iz stratekog planiranja, usredotoeno je na kratkorone
aktivnosti te ukljuuje i donoenje financijskog plana. S obzirom na prije navedeno
operativno bi planiranje trebalo biti usredotoeno na neposredna pitanja kao to su postojanje
adekvatnih resursa informacijskog sustava, dostatnost financijskih sredstava, adekvatno
upravljanje rizikom te uinak moguih promjena na poslovne procese, kako bi se zadovoljile
operativne potrebe.
Strateke i operativne planove potrebno je meusobno prilagoavati, ovisno o promjenama
poslovnih ciljeva.
Interni akti
Donoenje i primjena internih akata vezanih uz informacijski sustav osnova su za
uspostavljanje i odravanje upravljakih kontrola koje bi trebale biti slojevite i hijerarhijski
uspostavljene od najvie (strateke) razine prema najnioj (operativnoj) razini. Banka bi
trebala donijeti, dokumentirati, provoditi i odravati interne akte kako bi adekvatno upravljala
rizicima koji proizlaze iz koritenja informacijske tehnologije te naposljetku kako bi
djelotvorno upravljala informacijskim sustavom u cjelini. Internim aktima smatraju se odluke,
politike, standardi, smjernice, procedure, upute i ostali dokumenti za ije je donoenje
14
odgovorna uprava banke. Interne akte potrebno je integrirati u procese informacijskog sustava
i svakodnevne aktivnosti zaposlenika. Nadalje, interni bi akti trebali biti usklaeni s
propisima, standardima i pravilima struke.
Interni akti na najvioj konceptualnoj ili hijerarhijskoj razini (primjerice politike) trebali bi
obuhvatiti sva podruja i aspekte informacijskog sustava banke ukljuujui osobe, sustave i
procese. Banka bi trebala procijeniti i odrediti koja je podruja i aspekte informacijskog
sustava potrebno razraditi detaljnijim internim aktima nie razine (primjerice smjernicama,
uputama i procedurama) te definirati razinu detaljnosti razrade. Razina detaljnosti i obuhvat
pojedinog internog akta ovise o njegovoj svrsi, namjeni, vrsti te o kompleksnosti
informacijskog sustava.
15
2.1. Uprava banke

Upravljanje informacijskim sustavom vrlo je vano u procesu donoenja poslovnih odluka.
Kako bi banka primjereno upravljala informacijskim sustavom, uprava bi banke, izmeu
ostalog, trebala:
biti upoznata s konceptima i aktivnostima vezanim uz informacijski sustav
odrediti lana uprave koji e biti nadlean za nadzor i kontrolu procesa upravljanja
informacijskim sustavom
uspostaviti adekvatnu organizacijsku strukturu, pripadajue funkcije i odbore koji
upravljaju informacijskim sustavom banke
delegirati ovlasti prema uspostavljenoj organizacijskoj i funkcionalnoj strukturi
definirati kriterije, naine i postupke izvjeivanja uprave
usvojiti strategiju informacijskog sustava te nadzirati njezino provoenje
donijeti interne akte kojima se ureuje upravljanje informacijskim sustavom
uspostaviti proces upravljanja rizikom informacijskog sustava.
16
2.2. Voditelj organizacijske jedinice za informacijsku tehnologiju

Uprava banke trebala bi imenovati voditelja organizacijske jedinice za informacijsku
tehnologiju (engl. Chief Information Officer) te definirati njegove ovlasti, odgovornosti kao i
djelokrug rada. Voditelj organizacijske jedinice informacijske tehnologije trebao bi
prvenstveno biti usmjeren na strateka pitanja vezana uz informacijski sustav, upravljanje,
nadzor i koordinaciju rada organizacijske jedinice informacijske tehnologije te na
funkcionalnost i djelotvornost informacijskog sustava u cjelini. Nadalje, voditelj
organizacijske jedinice informacijske tehnologije trebao bi imati prikladno struno
obrazovanje i znanje te odgovarajue iskustvo na podruju informacijske tehnologije i
upravljanja njome.
Dobre prakse nalau da djelokrug rada voditelja organizacijske jedinice za informacijsku
tehnologiju obuhvaa sljedee:
razvoj i odravanje informacijskog sustava
pruanje podrke korisnicima informacijskog sustava
sudjelovanje u izradi strategije i stratekog plana informacijskog sustava
planiranje, organizaciju, koordinaciju i nadzor aktivnosti organizacijske jedinice za
informacijsku tehnologiju
pokretanje inicijativa (npr. unapreivanje postojeih funkcionalnosti informacijskog
sustava, uvoenje novih tehnolokih rjeenja, unapreenje sigurnosti informacijskog
sustava i slino)
provedbu svih prihvaenih inicijativa koje banka poduzima u svezi s informacijskim
sustavom
koordiniranje aktivnosti vezanih uz sigurnost informacijskog sustava s voditeljem
sigurnosti informacijskog sustava
koordiniranje aktivnosti glede informacijskog sustava s ostalim organizacijskim
jedinicama i tijelima banke
planiranje ulaganja u informacijski sustav
sudjelovanje u procesu odabira i nabave informatike opreme
sudjelovanje u planiranju, provedbi i nadzoru eksternalizacije (dijela) informacijskog
sustava
sudjelovanje u izradi internih akata povezanih s informacijskim sustavom (politika,
standarda, procedura, smjernica, uputa, planova)
planiranje izobrazbe
upravljanje imovinom informacijskog sustava
upravljanje odnosom s dobavljaima
izvjetavanje uprave banke
ostalo (ovisno o procjeni i odluci uprave banke).
17
2.3. Voditelj sigurnosti informacijskog sustava

Banka bi trebala uspostaviti neovisnu funkciju voditelja sigurnosti informacijskog sustava
(engl. Chief Information Systems Security Officer CISSO). Voditelj sigurnosti
informacijskog sustava ne bi trebao istodobno biti angairan na drugim funkcijama koje mogu
stvoriti sukob interesa (kao to su rukovoditelj ili zaposlenik organizacijske jedinice za
informacijsku tehnologiju i unutarnji revizor informacijskog sustava). Voditelj sigurnosti
trebao bi biti odgovoran upravi banke te svoja izvjea dostavljati izravno upravi, a ukoliko
procijeni da je potrebno, i nadzornom odboru banke. Nadalje, jednom godinje voditelj
sigurnosti informacijskog sustava trebao bi za upravu i nadzorni odbor izraditi izvjee o
stanju sigurnosti informacijskog sustava u proteklih godinu dana. Voditelj organizacijske
jedinice za informacijsku tehnologiju i unutarnji revizor trebali bi biti upoznati s navedenim
izvjeima.
Voditelj sigurnosti informacijskog sustava trebao bi:
nadzirati i koordinirati aktivnosti vezane uz sigurnost informacijskog sustava
inicirati primjenu dobrih praksi i prihvaenih standarda vezanih uz sigurnost
informacijskog sustava
imati savjetodavnu ulogu u svezi sa sigurnosti informacijskog sustava.
Zadaci voditelja sigurnosti trebali bi, izmeu ostalog, ukljuivati sljedee:
18
odreivanje sigurnosnih ciljeva u skladu sa strategijom informacijskog sustava banke

razvoj politike sigurnosti informacijskog sustava, standarda, smjernica i ostalih
internih akata s ciljem postizanja i odravanja zadovoljavajue razine sigurnosti
razvoj i primjenu strategije sigurnosti i sigurnosne arhitekture informacijskog sustava
nadziranje istrage u sluajevima naruavanja sigurnosti informacijskog sustava
suradnju s vanjskim suradnicima prilikom obavljanja neovisnih revizija i testiranja
sigurnosti informacijskog sustava
analiziranje sigurnosnih potreba te u skladu s njima predlaganje planiranja,
implementacije, testiranja i nadziranja aktivnosti za poboljanje sigurnosti
planiranje i koordiniranje analize isplativosti preporuenih i postojeih sigurnosnih
rjeenja
upozoravanje na potrebu za izobrazbom i davanje smjernica za izobrazbu svih osoba
koje se koriste informacijskim sustavom banke, a u svezi sa sigurnosti informacijskog
sustava
dostavljanje izvjea upravi i nadzornom odboru banke
procjenu rizika sigurnosti informacijskog sustava
kontroliranje provoenja politike sigurnosti informacijskog sustava i ostalih internih
akata koji se odnose na sve aspekte sigurnosti informacijskog sustava
koordiniranje aktivnosti s organizacijskom jedinicom informacijske tehnologije i
unutarnjom revizijom
sudjelovanje u znaajnijim fazama u ivotnom ciklusu informacijskog sustava s
aspekta sigurnosti
sudjelovanje u planiranju kontinuiteta poslovanja.
2.4. Odbor za upravljanje informacijskim sustavom

Uprava banke trebala bi imenovati odbor za upravljanje informacijskim sustavom ija je
uloga praenje i nadziranje informacijskog sustava i njegovih aktivnosti u smislu usklaenosti
s poslovnim ciljevima i stratekim planom banke. Isto tako, uloga odbora za upravljanje
informacijskim sustavom jest koordinacija inicijativa vezanih uz informacijski sustav na
upravljakoj razini, omoguavanje optimizacije trokova i boljeg upravljanja informacijskim
sustavom te smanjivanje rizika informacijskog sustava. Opseg djelovanja, ovlasti i ciljevi
odbora za upravljanje informacijskim sustavom moraju biti jasno definirani.
Aktivnosti odbora za upravljanje informacijskim sustavom trebale bi ukljuiti barem sljedee:
koordiniranje i nadzor razvoja i primjenu strategije i stratekog plana informacijskog
sustava
ocjenjivanje i prihvaanje politike sigurnosti informacijskog sustava kako bi se
osiguralo da politika sigurnosti odgovara poslovnim zahtjevima i ne ograniava
poslovne aktivnosti
odobravanje i kontrolu vanijih projekata vezanih uz informacijski sustav, kao i
sredstava potrebnih za njihovu realizaciju
postavljanje prioriteta vanih aktivnosti vezanih uz informacijski sustav
predlaganje novih te ocjenjivanje postojeih internih akata koji se odnose na
informacijski sustav
nadziranje funkcionalnosti i sigurnosti informacijskog sustava u cjelini
ovisno o potrebi, predlaganje ulaganja u informacijski sustav koja odstupaju od
planiranih trokova
arbitriranje u sluaju nesuglasica i spornih pitanja povezanih s informacijskim
sustavom
procjenjivanje i odobravanje eksternalizacije (dijela) poslovnih procesa te
koordiniranje aktivnosti vezanih uz eksternalizaciju
koordiniranje, nadzor i potvrivanje klasifikacije informacija
podnoenje izvjea upravi banke o svom radu
davanje miljenja o imenovanju voditelja sigurnosti informacijskog sustava.
Odbor za upravljanje informacijskim sustavom trebao bi dobivati potrebne informacije od
organizacijske jedinice za informacijsku tehnologiju i ostalih organizacijskih jedinica te
unutarnje i vanjske revizije kako bi mogli djelotvorno koordinirati i kontrolirati resurse
informacijskog sustava. Odbor za upravljanje informacijskim sustavom trebao bi se redovito
sastajati te sastavljati zabiljeke radi dokumentiranja svojih aktivnosti i odluka.
Dobre prakse nalau da lanovi odbora za upravljanje informacijskim sustavom budu:
lan uprave banke
rukovoditelj organizacijske jedinice za informacijsku tehnologiju
voditelj sigurnosti informacijskog sustava
osoba koja obavlja unutarnju reviziju informacijskog sustava (djelovanje te osobe u
odboru ne bi smjelo stvoriti sukob interesa utjecanjem na proces donoenja odluka)
predstavnici ostalih organizacijskih jedinica banke, odnosno barem onih
organizacijskih jedinica koje su izrazito ovisne o informacijskom sustavu.
19
Sve navedene aktivnosti odbora za upravljanje informacijskim sustavom mogu provoditi i

drugi odbori u skladu s potrebama i odlukom uprave banke.
20
2.5. Upravljanje projektima

Dobre prakse nalau primjenu projektnog pristupa za postizanje specifinih ciljeva u okviru
upravljanja informacijskim sustavom banke. Upravljanje projektima je primjena znanja,
vjetina, alata i jasno definiranih te provjerenih tehnika na razliite aktivnosti za potrebe
projekata. Upravljanje projektima podrazumijeva uspostavu procesa planiranja, organizacije,
provedbe i kontrole osoba, sustava i procesa radi postizanja postavljenih ciljeva.
Detaljni projektni planovi, jasno postavljeni zahtjevi i oekivanja, iskustvo voditelja
projekata, realan budet i djelotvorna komunikacija uvelike pridonose uspjenom upravljanju
projektima. Neprimjereno voenje projekata moe rezultirati, primjerice, kanjenjem projekta,
prekoraenjem budeta projekta ili smanjenom kvalitetom proizvoda ili usluge. Smanjena
kvaliteta proizvoda ili usluge moe se oitovati u problemima s pouzdanou, djelotvornou
ili sigurnou, a svaka naknadna promjena koja unapreuje sigurnost, funkcionalnost i sustav
kontrola u cjelini moe zahtijevati dodatne resurse (primjerice novac, ljude, vrijeme).
Adekvatno upravljanje projektima omoguava banci razvoj novih proizvoda i usluga te irenje
poslovanja u skladu sa stvarnim potrebama, pravodobno i u okviru planiranih financijskih i
ljudskih resursa. Drugim rijeima, primjereno upravljanje projektima poveava sposobnost
banke prilagoavanju promjenama u poslovanju i okruenju te omoguuje ostvarivanje
postavljenih stratekih ciljeva.
Uzimajui u obzir sloenost i posebnost projekata i poslovnih procesa, banka bi trebala
definirati i formalno propisati proces upravljanja projektima. Metodologija upravljanja
projektima (strukturirane tehnike voenja projekata koje ukljuuju naela, prakse i procedure)
unapreuje kontrolu nad projektima dijelei sloene zadatke u manje cjeline kojima je lake
upravljati.
Metodologija upravljanja projektima trebala bi segmentirati projekte u projektne faze ovisno o
odabiru metodologije (primjerice faza inicijacije projekta, planiranja, dizajniranja, razvoja,
testiranja, implementacije i odravanja) kao i potrebne aktivnosti unutar projektnih faza. Isto
tako, metodologija upravljanja projektima trebala bi se moi prilagoditi karakteristikama
pojedinih projekata.
Metodologija upravljanja projektima trebala bi definirati kriterije, naine i postupke
upravljanja projektima odnosno osigurati postojanje adekvatnih:
projektnih planova
definicija zahtjeva i oekivanja od projekta
standarda voenja projekta i procedura
standarda kontrole kvalitete i upravljanja rizikom projekta
definicija projektnih uloga i odgovornosti
financijskih, vremenskih i ljudskih resursa
kontrolnih toaka
kanala i naina komunikacije.
21
Dobre prakse nalau primjenu projektnog pristupa prilikom:

nabave, eksternalizacije i razvoja (dijela) informacijskog sustava
ostalih aktivnosti kao to su migracija sustava i podataka, unapreivanje proizvoda,
usluga i infrastrukture.
Radi primjerenog upravljanja projektima vrlo je vano jasno definirati uloge i odgovornosti
svih osoba i tijela ukljuenih u realizaciju projekata kao to su uprava banke, odbor za
upravljanje informacijskim sustavom, voditelj projekta, sponzor projekta, organizacijska
jedinica za informacijsku tehnologiju, kontrola kvalitete, zaposlenici iz poslovnih sektora,
sistemski analitiari i tehnolozi poslovnih procesa, unutarnja revizija te voditelj sigurnosti
informacijskog sustava. Ovisno o veliini i sloenosti projekta i samih poslovnih procesa
uloge se mogu preklapati pri emu treba uzeti u obzir potrebu za primjerenom segregacijom
dunosti.
U svim projektnim fazama potrebno je obratiti pozornost na sigurnosne aspekte projekta te na
zahtjeve koji proizlaze iz potrebe za odravanjem kontinuiteta poslovanja.
22
3. Upravljanje rizikom informacijskog sustava

Upravljanje rizikom je proces procjene rizika, poduzimanja radnja za smanjenje rizika na
prihvatljivu razinu i odravanja prihvatljive razine rizika. Drugim rijeima, upravljanje
rizikom kontinuirani je proces usporedbe procijenjenih rizika s prednostima i trokovima
predloenih mjera te uvoenja odabranih mjera u skladu s poslovnim ciljevima i temeljnim
naelima informacijskog sustava.
Upravljanje rizikom treba obuhvatiti cjelokupni informacijski sustav banke. Za nove sustave i
sustave koji su u fazi planiranja (ukljuujui i planiranje znaajnih promjena u
informacijskom sustavu), upravljanje rizikom treba biti sastavni dio razvojnog procesa, dok se
kod postojeih sustava treba uvesti u to kraem vremenu.
Zatitne mjere se odabiru ovisno o rizicima odnosno o vjerojatnosti pojave neeljenog
dogaaja i o njegovu uinku na informacijski sustav. Takoer je vano napomenuti da
provoenje zatitnih mjera moe stvoriti nove ranjivosti i tako rezultirati novim rizicima.
Stoga je potrebno pomno izabrati odgovarajue zatitne mjere, ne samo radi smanjivanja
rizika ve i zato da bi se izbjeglo izlaganja novim rizicima. Isto tako, potrebno je razmotriti
razliite vrste zatitnih mjera i provesti analizu isplativosti te uzeti u obzir prihvatljivu razinu
rizika preostalih nakon provoenja odabranih mjera odnosno uvoenja kontrola.
Rizici se procjenjuju s aspekta mogueg uinka kao posljedice naruavanja funkcionalnosti i
sigurnosti informacijskog sustava, odnosno naruavanja temeljnih naela informacijskog
sustava. Veina prijetnja i ranjivosti neposredno se odnosi na sigurnost informacijskog
sustava stoga je u nastavku ovog dokumenta poseban naglasak stavljen na procjenu i
smanjenje rizika s aspekta sigurnosti.
Kako bi se postigla zadovoljavajua razina sigurnosti, banka bi trebala utvrditi sigurnosni
potencijal kojim treba raspolagati informacijski sustav te planirati sredstva za njegovo
ostvarenje. Upravljanje rizikom omoguuje uravnoteivanje operativnih trokova i koristi od
zatitnih mjera da bi se adekvatno zatitio informacijski sustav.
Upravljanje rizikom je kontinuirani proces koji ukljuuje:
procjenu rizika
smanjivanje rizika
odravanje prihvatljive razine rizika.
Dobre prakse nalau da se upravljanje rizikom integrira u ivotni ciklus informacijskog
sustava kako bi procijenjeni rizik odgovarao stvarnom stanju sustava te kako bi se podrali
poslovni ciljevi banke.
U sljedea dva poglavlja ukratko su opisane radnje koje bi banka, prema dobrim praksama,
trebala poduzimati u sklopu upravljanja rizicima. Spomenute su radnje samo jedan od naina
provoenja procjene i smanjenja rizika.
23
3.1. Procjena rizika

Banka bi trebala pri procjeni rizika utvrditi razinu rizika kojem je izloen informacijski sustav
te predloiti zatitne mjere kako bi se rizik smanjio na prihvatljivu razinu. Rizici se
procjenjuju s aspekta mogueg uinka uzrokovanog naruavanjem funkcionalnosti i/ili
sigurnosti informacijskog sustava. Kako bi se utvrdila vjerojatnost pojave nekog tetnog
dogaaja, potrebno je analizirati prijetnje informacijskom sustavu zajedno s ranjivostima te
kontrolama koje su primijenjene u informacijskom sustavu. Uinak se odnosi na opseg i
veliinu tete koju prijetnja moe uzrokovati ako iskoristi odreenu ranjivost.
Procjena rizika trebala bi ukljuivati sljedee radnje:
1. odreivanje obiljeja sustava
2. identifikaciju prijetnja
3. identifikaciju ranjivosti
4. analizu sustava kontrola
5. odreivanje vjerojatnosti
6. analizu uinka
7. utvrivanje rizika
8. predlaganje mjera
9. dokumentiranje rezultata u obliku formalnog izvjea.
3.1.1. Odreivanje obiljeja sustava

Odreivanje obiljeja informacijskog sustava definira opseg procesa procjene rizika te daje
informacije kljune za definiranje rizika. Utvrivanje rizika kojem je izloen informacijski
sustav zahtijeva razumijevanje njegova okruenja. Stoga je potrebno prikupiti informacije o
informacijskom sustavu koje ukljuuju:
hardver
softver
sistemska suelja (npr. interna i eksterna sposobnost povezivanja)
poslovne informacije i ostale informacije koje rabi informacijski sustav (informacije je
potrebno klasificirati u razliite grupe prema stupnju njihove osjetljivosti, to je
detaljnije opisano u poglavlju "Klasifikacija informacija")
osobe koje odravaju i koriste informacijski sustav
svrhu sustava (npr. procesi koje obavlja informacijski sustav)
vanost i osjetljivost sustava i podataka (npr. vrijednost sustava ili kolika je njegova
vanost za banku)
ostalo.
Nadalje, potrebno je prikupiti i dodatne informacije povezane s operativnim okruenjem
informacijskog sustava koje ukljuuju sljedee (ali nisu ograniene na to):
funkcionalne potrebe
interne akte koji se odnose na informacijski sustav
arhitekturu sigurnosti sustava
topologiju mree (npr. dijagram mree)
24
tok informacija koje se odnose na informacijski sustav (npr. sistemska suelja,

dijagram toka ulaznih i izlaznih podataka sustava)
identifikaciju upravljakih, logikih i fizikih kontrola
fiziku sigurnost (npr. sigurnost prostorija, politike pristupa sistemskoj prostoriji)
sigurnost okoline u kojoj je informacijski sustav (npr. kontrola vlanosti, vode,
napajanja, oneienja, temperature i kontrola prisutnosti kemikalija).
Rezultat: izvjee o obiljejima informacijskog sustava s cjelovitim prikazom okruenja

3.1.2. Identifikacija prijetnja

Prijetnja je potencijal odreenog izvora prijetnja da uspjeno iskoristi odreenu ranjivost.
Izvor prijetnje ne utjee na rizik ako ne moe iskoristiti ranjivost.
Cilj identifikacije prijetnja jest otkriti prijetnje koje se odnose na informacijski sustav koji se
procjenjuje, identificirati izvore prijetnja (ako je to mogue) te sastaviti popis identificiranih
prijetnja i izvora.
Prijetnja je:
namjera ili radnja usmjerena k namjernom iskoritavanju ranjivosti sustava ili
situacija ili radnja koja moe sluajno aktivirati ranjivost.
Izvor prijetnje moe nanijeti tetu informacijskom sustavu. Uobiajeni izvori prijetnja mogu
biti prirodni, ljudski ili iz okruenja. Stoga je potrebno identificirati sve prijetnje i izvore
prijetnja koji bi mogli natetiti informacijskom sustavu banke i njegovu okruenju.
Rezultat: izvjee s popisom prijetnja koje bi mogle iskoristiti ranjivosti informacijskog
sustava banke i njihovih izvora
3.1.3. Identifikacija ranjivosti

Ranjivost je slabost koju je mogue sluajno aktivirati ili namjerno iskoristiti. Sa stanovita
sigurnosti informacijskog sustava ranjivost je mana ili slabost u sigurnosnim procedurama
sustava, njegovu dizajnu, implementaciji ili unutarnjim kontrolama, koja moe biti iskoritena
te rezultirati povredom sigurnosti. Cilj identifikacije ranjivosti jest utvrivanje ranjivosti
informacijskog sustava koje bi mogli iskoristiti izvori prijetnja.
Ranjivosti informacijskog sustava mogu biti otkrivene pomou razliitih metoda prikupljanja
informacija. Pri analizi ranjivosti potrebno je, izmeu ostalog, uzeti u obzir sljedee:
dokumentaciju o prethodnoj procjeni rizika informacijskog sustava
izvjea unutarnje i vanjske revizije informacijskog sustava
izvjea o nepravilnostima u sustavu
izvjea o sigurnosti
izvjea o testiranju informacijskog sustava
25
popise ranjivosti
strune publikacije vezane uz informacijske sustave
preporuke dobavljaa i proizvoaa
izvjea o rezultatima testiranja informacijskog sustava pomou proaktivnih metoda
testiranja (primjerice alata za automatsko otkrivanje ranjivosti, testiranje mogunosti
prodora u sustav i slino).
Kao metoda u otkrivanju ranjivosti moe posluiti i izrada kontrolne liste zahtjeva koja sadri
osnovne funkcionalne i sigurnosne kriterije koje je potrebno provjeriti kako bi se utvrdile
ranjivosti resursa informacijskog sustava.
Pri otkrivanju ranjivosti mogu se primijeniti kriteriji u sljedeim sigurnosnim segmentima:
upravljakom (primjerice dodjela ovlasti i odgovornosti, procjena rizika)
logikom (primjerice kontrole pristupa, komunikacija, operativni i sistemski zapisi)
fizikom (primjerice kontrola i zatita okoline, fiziki pristup i raspolaganje medijima
s podacima).
Rezultat: izvjee s popisom identificiranih ranjivosti informacijskog sustava koje prijetnje
mogu iskoristiti
3.1.4. Analiza sustava kontrola

Cilj ove radnje jest analizirati sustav kontrola koje je banka uvela ili planira uvesti radi
smanjenja ili otklanjanja vjerojatnosti (ili mogunosti) da neka prijetnja iskoristi ranjivost
informacijskog sustava. Analiza sustava kontrola ukljuuje ispitivanje djelotvornosti kontrola
koje su ve primijenjene u informacijskom sustavu. Sastavljanje kontrolne liste zahtjeva i/ili
upotreba dostupne kontrolne liste moe biti od velike pomoi pri djelotvornom i
sistematinom analiziranju sustava kontrola.
Rezultat: izvjee s popisom kontrola i ocjenom njihove djelotvornosti
3.1.5. Utvrivanje vjerojatnosti

Kako bi banka mogla utvrditi vjerojatnost da identificirana ranjivost bude iskoritena u
okruenju izloenom prijetnji, potrebno je uzeti u obzir barem sljedee imbenike:
motivaciju i sposobnost izvora prijetnje
znaajke odreene ranjivosti
postojanje i djelotvornost postojeih kontrola.
Vjerojatnost da izvor prijetnje iskoristi ranjivost moe se iskazati pridruivanjem neke
empirijske skale za mjerenje vjerojatnosti (npr. od 0 do 1) ili upotrebom unaprijed odreenog
naina stupnjevanja kao npr. mala, srednja i velika vjerojatnost.
Rezultat: ocjena vjerojatnosti
26
3.1.6. Analiza uinka

Analiza uinka je procjenjivanje negativnog uinka koji bi mogao nastati ukoliko prijetnja
uspjeno iskoristi ranjivost. Osnovne informacije potrebne za analizu uinka ukljuuju barem
sljedee:
svrhu sustava (primjerice procesa koje obavlja informacijski sustav)
vanost sustava i podataka za poslovanje banke
osjetljivost podataka i sustava.
Navedene informacije mogue je dobiti iz analize utjecaja na poslovanje, klasifikacije
informacija te prikupljanjem informacija od zaposlenika i ostalih izvora.
Na temelju dobivenih informacija potrebno je procijeniti negativan uinak nekog neeljenog
dogaaja. Negativan uinak dogaaja mogue je opisati kao naruavanje funkcionalnosti ili
gubitak odnosno kompromitiranje bilo kojeg temeljnog naela informacijskog sustava ili
kombinacije tih naela.
Pojedine uinke mogue je mjeriti kvantitativno, u obliku izgubljenog prihoda, trokova
popravka sustava ili vremena koje je potrebno uloiti kako bi se rijeili problemi nastali
izvrenjem prijetnje. Drugi uinci (npr. gubitak povjerenja javnosti, gubitak kredibiliteta, teta
nainjena interesima banke) ne mogu se mjeriti odreenim mjernim jedinicama, ali ih je
mogue odrediti ili opisati kvalitativno (npr. kao male, srednje i velike uinke).
Rezultat: izvjee o procijenjenoj razini uinka
3.1.7. Utvrivanje rizika

Svrha ove radnje jest procijeniti razinu rizika kojem je izloen informacijski sustav banke.
Utvrivanje rizika izloenosti odreenoj kombinaciji prijetnje i ranjivosti moe se izraziti kao
funkcija:
vjerojatnosti da e identificirani izvor prijetnje iskoristiti odreenu ranjivost
jaine (razine) uinka ako izvor prijetnje uspjeno iskoristi ranjivost.
Prilikom utvrivanja razine rizika potrebno je uzeti u obzir i prikladnost planiranih ili
postojeih kontrola za smanjivanje ili uklanjanje rizika te uestalost pojave neeljenih
dogaaja.
Jedan od naina mjerenja rizika jest izrada matrice razine rizika i ljestvice rizika.
Matrica razine rizika
Razina rizika utvruje se mnoenjem ocjene koja je dodijeljena vjerojatnosti da izvor prijetnje
iskoristi ranjivost s ocjenom uinka neeljenog dogaaja, pri emu se uzima u obzir
prikladnost planiranih ili postojeih kontrola. Tablica br. 2 daje jednostavan primjer kako se
mogu odrediti rizici na temelju podataka o vjerojatnosti da izvor prijetnje iskoristi ranjivost i
o uinku.
27
Primjer u tablici br. 2 jest matrica vjerojatnosti da izvor prijetnje iskoristi ranjivost (velika,
srednja i mala) i uinka (velikog, srednjeg i malog), koja prikazuje kako se rauna ukupna
razina rizika. Na primjer:
ocjena vjerojatnosti da izvor prijetnje iskoristi ranjivost koja se pripisuje svakoj razini
vjerojatnosti prijetnje jest 1,0 za veliku, 0,5 za srednju i 0,1 za malu;
ocjena uinka koja se dodjeljuje svakoj razini jaine uinka jest 100 za veliku, 50 za
srednju i 10 za malu.
Ovisno o potrebama i detaljnosti procjene rizika moe se koristiti matrica proizvoljnih
dimenzija.
Tablica br. 2 Matrica razine rizika (engl. Risk-Level Matrix)
Vjerojatnost da izvor
prijetnje iskoristi ranjivost
Velika (1,0)
Srednja (0,5)
Mala (0,1)
Mali (10)
10 x 1,0 = 10
10 x 0,5 = 5
10 x 0,1 = 1
Uinak
Srednji (50)
50 x 1,0 = 50
50 x 0,5 = 25
50 x 0,1 = 5
Veliki (100)
100 x 0,5 = 50
100 x 0,1 = 10
Ljestvica rizika
Tablica br. 3 opisuje razine rizika prikazane u tablici br. 2. Ljestvica rizika s pripadajuim
ocjenama predstavlja stupanj ili razinu rizika kojem su izloeni resursi informacijskog sustava
ako je iskoritena odreena ranjivost. Stupanj ili razina rizika odreuje aktivnosti koje bi se
trebale poduzeti.
Tablica br. 3 Primjer ljestvice rizika i aktivnosti koje je potrebno poduzeti
Razina rizika
Opis rizika i aktivnosti koje je potrebno poduzeti
Velik rizik
(vei od 51)
Ako je rizik procijenjen kao velik, nuno je hitno provoenje mjera za

smanjenje rizika. Postojei sustav moe nastaviti raditi, ali nuno je u to
kraem roku sastaviti plan provoenja mjera te odrediti prioritete i
rokove.
Srednji rizik
(11 do 50)
Ako je rizik procijenjen kao srednji, nuno je provoenje mjera za

smanjenje rizika. Potrebno je sastaviti plan provoenja mjera kako bi se
one provele u razumnom vremenu.
Malen rizik
(1 do 10)
Ako je rizik procijenjen kao malen, potrebno je utvrditi je li nuno

provoenje mjera za smanjenje rizika ili se rizik moe prihvatiti.
Ako je razina nekih elemenata (vjerojatnosti, uinka ili rizika) tako mala da se moe
okarakterizirati kao ''zanemariva'' ili nevana (primjerice vrijednost je < 1 na ljestvici od 0 do
100), potrebno ju je posebno zabiljeiti. Time se osigurava da isti elementi budu ukljueni u
sljedeu procjenu. Navedeno je posebno vano jer ''zanemarivi'' rizici mogu s vremenom
prerasti u rizike zbog kojih je potrebno poduzeti odreene aktivnosti.
28
Rezultat:
matrica razine rizika
ljestvica rizika i aktivnosti koje je potrebno poduzeti
3.1.8. Predlaganje mjera

Predloene mjere jedan su od rezultata procesa procjene rizika. Cilj predloenih mjera jest
smanjiti razinu rizika kojem je izloen informacijski sustav na prihvatljivu razinu. Prilikom
predlaganja mjera za smanjenje ili otklanjanje utvrenih rizika treba uzeti u obzir, izmeu
ostalog, sljedee imbenike:
djelotvornost predloenih mjera
vaee propise
interne akte banke
utjecaj na poslovne procese
utjecaj na temeljna naela informacijskog sustava.
U procesu smanjenja rizika odabiru se najprikladnije predloene mjere te se slijedom toga
provode uvoenjem novih ili izmjenom postojeih kontrola.
Rezultat: izvjee o predloenim mjerama za smanjivanje rizika
3.1.9. Izvjee o procjeni rizika

Nakon zavretka procjene rizika (odreena su obiljeja sustava, identificirane prijetnje i
ranjivosti, procijenjeni rizici te predloene mjere) potrebno je dokumentirati rezultate u obliku
formalnog izvjea. Izvjee o procjeni rizika pomae upravi banke i drugim odgovornim
osobama da donesu odluke o promjenama internih akata i prorauna te odluke o operativnim i
upravljakim promjenama. Izvjee o procjeni rizika trebalo bi biti sastavljeno na
sistematian, analitian i afirmativan nain koji e upravi banke omoguiti prepoznavanje
rizika i promovirati potrebu alociranja sredstva kako bi utvreni rizici bili smanjeni na
prihvatljivu razinu, a potencijalni gubici izbjegnuti.
Rezultat: izvjee o procjeni rizika
29
3.2. Smanjivanje rizika

Smanjivanje rizika ukljuuje odreivanje prioriteta, procjenu, odabir i provoenje adekvatnih
zatitnih mjera za smanjivanje rizika (predloenih u sklopu procesa procjene rizika) s obzirom
na uestalost pojave neeljenih dogaaja i njihov uinak. Budui da je uklanjanje svih rizika
kojima je izloen informacijski sustav gotovo nemogue, banka bi trebala poduzeti sve
potrebne radnje kako bi smanjila rizik informacijskog sustava na prihvatljivu razinu
provoenjem adekvatnih zatitnih mjera. Prilikom provoenja mjera potrebno je posebnu
pozornost posvetiti smanjenju najznaajnijih rizika (kombinacija prijetnja i ranjivosti koje
mogu potencijalno uzrokovati znaajan negativan uinak) na prihvatljivu razinu uz najmanji
mogui utjecaj na ostale poslovne procese. Smanjivanje rizika identificiranih u procesu
procjene rizika moe se postii na sljedee naine:
Izbjegavanjem rizika. Izbjegavanje rizika uklanjanjem uzroka rizika i/ili posljedica
(npr. odriui se odreenih funkcija sustava ili prestankom koritenja sustava kad su
rizici otkriveni).
Ograniavanjem rizika. Ograniavanje rizika provoenjem mjera (npr. primjenom
preventivnih i detekcijskih kontrola) kojima se smanjuju potencijalni negativni uinci
na prihvatljivu razinu.
Prenoenjem rizika. Prenoenje rizika pomou drugih naina naknade pretrpljene
tete (npr. ugovaranjem osiguranja).
Pri odabiru bilo koje od ovih mogunosti smanjenja rizika potrebno je uzeti u obzir poslovne
ciljeve i zadatke banke te potrebu za ouvanjem temeljnih naela informacijskog sustava.
Ukoliko banka u procesu procjene rizika utvrdi da je rizik prihvatljiv, odnosno da nije
potrebno njegovo daljnje smanjivanje, navedeni je rizik mogue prihvatiti donoenjem odluke
o prihvaanju preostalih rizika.
Smanjivanje rizika trebalo bi obuhvatiti sljedee radnje:
1. odreivanje prioriteta aktivnosti
2. procjenu predloenih mjera za smanjivanje rizika
3. provoenje analize isplativosti
4. odabir mjera za smanjivanje rizika
5. dodjeljivanje odgovornosti
6. izradu plana provoenja odabranih mjera
7. utvrivanje preostalih rizika.
3.2.1. Odreivanje prioriteta aktivnosti

Prioriteti provoenja aktivnosti odreuju se na temelju utvrenih razina rizika sadranih u
ljestvici rizika i u izvjeu o procjeni rizika. Viim razinama rizika dodijelit e se vii
prioriteti (primjerice aktivnosti povezane s rizikom kojem je dodijeljena ocjena rizika vrlo
visok ili visok, imat e najvii prioritet). U skladu s dodijeljenim prioritetima potrebno je
provesti mjere kako bi se smanjili rizici kojima je izloen informacijski sustav i zatitili
poslovni ciljevi.
Rezultat: popis aktivnosti ocijenjenih prema prioritetima
30
3.2.2. Procjena predloenih mjera za smanjivanje rizika

Pri procjenjivanju predloenih mjera potrebno je analizirati njihovu izvedivost (npr.
kompatibilnost, prihvaanje od strane korisnika) i djelotvornost (npr. stupanj zatite i razinu
smanjivanja rizika) zato to neke od predloenih mjera nisu uvijek i najprikladnija ili
najisplativija rjeenja za banku i informacijski sustav. Cilj je ove radnje odabrati
najprikladniju mjeru kako bi se rizik smanjio na prihvatljivu razinu.
Rezultat: popis prikladnih mjera
3.2.3. Provoenje analize isplativosti

Analiza isplativosti prikladnih mjera provodi se kako bi se olakalo donoenje odluka i
utvrdila isplativost provoenja navedenih mjera. Rezultati analize mogu se iskazati
kvalitativno ili kvantitativno. Svrha takve analize jest utvrivanje mjera iji e trokovi
provoenja biti opravdani smanjenjem razine rizika na prihvatljivu razinu.
Rezultat: izvjee o analizi isplativosti koja opisuje trokove i prednosti provoenja mjera ili
razloge zbog kojih mjere nisu isplative
3.2.4. Odabir mjera za smanjivanje rizika

Svrha ove radnje jest odabrati najdjelotvornije mjere za smanjivanje rizika. Odabrane mjere
trebale bi kombinirati upravljake, logike i fizike elemente.
Rezultat: popis odabranih mjera za smanjivanje rizika
3.2.5. Dodjeljivanje odgovornosti

Svrha ove radnje jest odabir osoba (zaposlenika banke ili vanjskih suradnika) koje raspolau
adekvatnim znanjem i vjetinama potrebnim za provoenje odabranih mjera te dodjeljivanje
odgovornosti za provoenje mjera.
Rezultat: popis dodijeljenih odgovornosti
3.2.6. Izrada plana provoenja odabranih mjera

Svrha ove radnje jest izrada plana prema kojem e se provoditi odabrane mjere za smanjenje
rizika. Provoenje odabranih mjera ostvaruje se uvoenjem novih ili izmjenom postojeih
kontrola. Plan provoenja odabranih mjera treba sadravati barem sljedee:
rizike (kombinacije ranjivosti i prijetnja) i pripadajue razine rizika (rezultate izvjea
o procjeni rizika)
31
predloene mjere (rezultat izvjea o predloenim mjerama za smanjivanje rizika)

ocjenu prioriteta (u skladu s razinama rizika)
odabrane mjere (na temelju popisa odabranih mjera za smanjivanje rizika)
resurse potrebne za provoenje odabranih zatitnih mjera
popise odgovornih osoba
datume poetka i zavretka provedbe odabranih zatitnih mjera.
Rezultat: plan provoenja odabranih mjera
3.2.7. Utvrivanje preostalih rizika

U veini sluajeva provedene mjere za smanjivanje rizika rezultiraju smanjenjem, ali ne i
potpunim otklanjanjem rizika, to upuuje na postojanje preostalih (rezidualnih) rizika. Nakon
provoenja odabranih mjera potrebno je utvrditi preostale rizike te donijeti odluku o
prihvaanju preostalih rizika ili poduzimanju radnja za daljnje smanjenje rizika.
Rezultat: popis preostalih (rezidualnih) rizika
32
3.3. Kontrole
Provoenje odabranih mjera za smanjivanje rizika ostvaruje se uvoenjem novih ili izmjenom
postojeih kontrola. Kontrole je mogue podijeliti na sljedee tri kategorije: upravljake,
logike (tehnike) i fizike. Budui da je informacijski sustav siguran onoliko koliko je
siguran njegov najranjiviji dio, nuan je slojevit pristup u izgradnji sigurnosne infrastrukture,
koji ukljuuje razliite kombinacije upravljakih, logikih i fizikih kontrola. Koritenjem
navedenih kategorija kontrola znaajno se smanjuje rizik od naruavanja temeljnih naela
Pravilnim provoenjem kontrola mogue je sprijeiti ili ograniiti tetu koju izvor prijetnje
moe nanijeti banci, odnosno smanjiti rizik informacijskog sustava.
Kontrole (slino kao i zatitne mjere) dijele se i prema njihovim ulogama na kontrole:
1. prevencije
2. odvraanja
3. otkrivanja
4. ograniavanja
5. korigiranja
6. oporavka
7. nadzora
8. osvjeivanja.
3.3.1. Upravljake kontrole

Upravljake se kontrole provode donoenjem i primjenom internih akata radi osiguranja
funkcionalnosti i sigurnosti te ouvanja temeljnih naela informacijskog sustava banke.
Primjeri upravljakih kontrola jesu:
dodjeljivanje odgovornosti
razvijanje i odravanje politike sigurnosti informacijskog sustava te ostalih internih
akata vezanih uz informacijski sustav
uvoenje sigurnosne kontrole zaposlenika (primjerice razdvajanje dunosti, princip
dodjeljivanja prava koritenja informacijskog sustava samo do razine koja je nuno
potrebna za izvravanje radnih zadataka, dodjeljivanje posebnih dozvola, rotacija
dunosti te dodjeljivanje i ukidanje prava pristupa informacijskom sustavu)
kontrole vezane uz radnje koje je potrebno provoditi prilikom zapoljavanja, prekida
radnog odnosa, premjetaja u drugu organizacijsku jedinicu i promaknua
provoenje izobrazbe te podizanje razine svijesti o rizicima informacijskog sustava
kako bi se osiguralo da krajnji korisnici i ostali korisnici sustava budu upoznati s
njima te s pravilima ponaanja i odgovornostima
provoenje periodinih nadzora i provjera djelotvornosti kontrola
provoenje periodine revizije informacijskog sustava
uspostava kontinuiranog procesa upravljanja rizikom radi procjene i smanjenja rizika
uspostava procesa planiranja kontinuiteta poslovanja
provoenje testiranja.
33
3.3.2. Logike kontrole

Kontrole na softverskim i hardverskim komponentama informacijskog sustava nazivamo
logikim kontrolama. Primjeri logikih kontrola jesu:
softverske i hardverske kontrole za utvrivanje autentinosti, autorizaciju, provoenje
obavezne kontrole pristupa te osiguranje neporecivosti radnja, zatienosti
komunikacijskih kanala i povjerljivosti transakcija
kontrole pristupa informacijskom sustavu kao to su: kombinacija korisnikoidentifikacijske oznake i zaporke, PKI infrastruktura, biometrijske kontrole,
autentifikacija pomou "pametne kartice" (engl. smart card) i slino
upotreba kriptografskih metoda u svrhu zatite informacija u postupku njihovog
prijenosa kroz telekomunikacijsku mreu, te za vrijeme pohrane
upotreba sistemskih i operativnih zapisa kako bi se biljeile aktivnosti koje su uinjene
unutar telekomunikacijske mree, na mrenom ureaju ili na pojedinom raunalu
upotreba usmjernika, preklopnika, vatrozida i ostalih mrenih komponenata u svrhu
kontrole pristupa mrenim resursima te izdvajanja i zatite pojedinih segmenata unutar
mree
upotreba metoda za otkrivanje neovlatenog pristupa i radnja na informacijskom
sustavu
upotreba metoda za otkrivanje pogreaka u podacima i naruavanja njihova integriteta
metode otkrivanja, sprjeavanja irenja i unitavanja malicioznog koda.
3.3.3. Fizike kontrole

Fizike kontrole tite i osiguravaju resurse informacijskog sustava od neovlatenog fizikog
pristupa, krae, fizikog oteenja ili unitenja. Fizike kontrole trebaju pruiti potporu
upravljakim i logikim kontrolama i zajedniki djelovati kako bi se rizik informacijskog
sustava sveo na prihvatljivu razinu. Primjeri fizikih kontrola jesu:
metode fizike zatite opipljive imovine (osobnih raunala, posluitelja, mrenih
ureaja, kabela, medija, graevina i slino) od neovlatenog pristupa
mehanizmi nadzora okoline (videonadzor prostorija banke, osvjetljivanje okoline,
detektori pokreta, senzori, alarmi i slino)
biometrijske kontrole pristupa informacijskim resursima
kontrola vlage, temperature, dima i slino
fiziko odvajanje dijelova telekomunikacijske mree
mehanizmi osiguravanja priuvnog izvora napajanja elektrinom energijom (npr.
sustav za neprekinuto napajanje elektrinom energijom, generatori).
34
3.4. Klasifikacija informacija

Banka mora uvati povjerljive podatke u skladu s vaeim propisima. Informacije je potrebno
klasificirati u razliite grupe prema stupnju njihove osjetljivosti (npr. jako osjetljive, osjetljive
i neosjetljive) s obzirom na mogue posljedice naruavanja temeljnih naela informacijskog
sustava. Osjetljiva informacija je bilo koja informacija ije razotkrivanje, privremeni ili trajni
gubitak, zlouporaba ili neovlatena modifikacija mogu negativno utjecati na interese banke i
klijenata te na usklaenost s vaeim propisima.
Banka bi trebala odrediti grupe u koje e se informacije klasificirati, te odrediti smjernice i
pravila za svrstavanje u pojedinu grupu. Na temelju toga svaku informaciju potrebno je
klasificirati (svrstati u neku od definiranih grupa). Cilj klasifikacije informacija jest postizanje
odgovarajueg stupnja zatite informacija pri emu treba uzeti u obzir njihovu osjetljivost.
Banka bi trebala donijeti i interne akte kojima bi se definirali kriteriji i postupci te
odgovornosti za provoenje klasifikacije informacija. Banka takoer mora osigurati da
informacije pohranjene na razliitim medijima budu adekvatno zatiene te uspostaviti
siguran proces odlaganja i unitavanja tih medija.
35
4. Unutarnja revizija
U skladu s odredbama Zakona o bankama ("Narodne novine", broj 84/2002., u nastavku
teksta: ZOB), banka mora organizirati unutarnju reviziju koja e neovisno i objektivno
obavljati svoje poslove te koja e svojim savjetima i preporukama pridonositi unapreivanju
poslovanja banke. Jedan od zadataka unutarnje revizije jest obavljanje stalnog nadzora nad
cjelokupnim poslovanjem banke kako bi se provjerilo upravlja li banka sustavno rizicima koji
proizlaze iz poslovnih aktivnosti banke u skladu s naelima stabilnog poslovanja, to
ukljuuje upravljanje resursima informacijske i pridruenih tehnologija.
Unutarnja revizija treba obavljati i poslove revizije informacijskog sustava, iz ega proizlazi
da unutarnja revizija treba biti organizirana tako da se osigura sustavno obavljanje revizije
informacijskog sustava. Obavljanje revizije informacijskog sustava banke, za potrebe ovog
dokumenta, nazivamo unutarnjom revizijom informacijskog sustava.
Kako bi se unutarnja revizija informacijskog sustava banke provela na zadovoljavajui i
djelotvoran nain, osobe koje obavljaju unutarnju reviziju informacijskog sustava trebale bi:
posjedovati struna znanja i vjetine, iskustvo te razinu kvalifikacija u skladu s
veliinom i sloenou informacijskog sustava banke
koristiti se metodologijom za provoenje revizije informacijskog sustava temeljenom
na procjeni rizika koja bi detaljno definirala kriterije, nain i postupke provoenja
revizije informacijskog sustava te osigurala dosljednost i sveobuhvatnost revizije
razmotriti dobre prakse upotrebe softverskih alata za provoenje revizije i kontrolu
evidentirati, prikupiti i arhivirati dokumentaciju na temelju koje je sastavljeno izvjee
o provedenoj reviziji imajui u vidu potrebu za adekvatnom zatitom osjetljivih
informacija.
Banka bi trebala kontinuirano obavljati unutarnju reviziju informacijskog sustava i definirati
razdoblje (ciklus) unutar kojeg e obaviti unutarnju reviziju cjelokupnoga informacijskog
sustava.
Prilikom sastavljanja godinjeg programa rada te odreivanja predmeta, obuhvata i uestalosti
revizije pojedinih podruja informacijskog sustava potrebno je uzeti u obzir i rukovoditi se
sljedeim:
obavljenom procjenom rizika informacijskog sustava banke
iskustvom te dobrim praksama u reviziji informacijskih sustava
raspoloivim resursima
novim saznanjima o informacijskom sustavu.
Na temelju godinjeg programa rada unutarnje revizije potrebno je donijeti i operativne
planove rada za unutarnju reviziju informacijskog sustava. Operativni planovi rada za
unutarnju reviziju informacijskog sustava trebali bi sadravati barem sljedee:
ciljeve i opseg revizija
popis podruja koja e biti predmetom revizija
popis predmeta revizije unutar svakog podruja
vremenski raspored revizija koje e se obaviti u razdoblju obuhvaenom planom
36
trajanje revizija.
Na temelju provedene revizije informacijskog sustava unutarnja revizija informacijskog

sustava trebala bi sastaviti pisano izvjee o obavljenoj reviziji informacijskog sustava koje bi
trebalo sadravati barem sljedee:
popis revidiranih podruja
popis osoba koje su sudjelovale u reviziji
cilj i opseg revizije
ocjenu revidiranih podruja
nedostatke i slabosti revidiranih podruja
nezakonitosti i nepravilnosti, ako su utvrene tijekom obavljanja revizije
prijedloge, preporuke i rokove za otklanjanje utvrenih nezakonitosti, nepravilnosti,
nedostataka i slabosti.
Unutarnja revizija trebala bi sastaviti izvjea o radu u skladu s rokovima utvrenima
operativnim planom rada. Izvjea o radu trebala bi sadravati i izvjea o obavljenim
revizijama informacijskog sustava.
Dobre prakse nalau da unutarnja revizija informacijskog sustava bude ukljuena u
revidiranje projekata i/ili njihovih faza (primjerice razvoj aplikacija, nabava, migracija
sustava, integracije sustava), kao i ostalih aktivnosti vezanih uz informacijski sustav
(primjerice upravljanje informacijskim sustavom, planiranje kontinuiteta poslovanja,
eksternalizacija (dijela) informacijskog sustava) koje mogu imati znatan utjecaj na
funkcionalnost i sigurnost informacijskog sustava.
37
5. Sigurnost informacijskog sustava

Sigurnost je odgovornost svih upravljakih razina banke te je vrlo vana u svim fazama
ivotnog ciklusa informacijskog sustava. Sigurnost informacijskog sustava obuhvaa sve
aspekte povezane s definiranjem, ostvarivanjem i odravanjem temeljnih naela
Kako bi se postigla i odrala adekvatna razina sigurnosti informacijskog sustava, dobre prakse
nalau rukovoenje sljedeim naelima:
1. naelom zabrane svih radnja koje nisu eksplicitno doputene na temelju dodijeljenih
ovlasti
2. naelom dodjele najmanjih moguih ovlasti resursima informacijskog sustava
(ukljuujui osobe, sustave i procese) koje omoguuju djelotvorno poslovanje.
38
5.1. Politika sigurnosti informacijskog sustava

Politika sigurnosti informacijskog sustava temeljni je okvir za upravljanje sigurnou
informacijskog sustava banke i trebala bi odraavati opeprihvaena naela sigurnosti.
Politika sigurnosti informacijskog sustava trebala bi sadravati naela i principe upravljanja
sigurnou resursa informacijskog sustava te odgovornosti koje se odnose na sigurnost
Banka bi trebala donijeti politiku sigurnosti informacijskog sustava, upoznati korisnike
informacijskog sustava s njom te imenovati osobu odgovornu za praenje provoenja te
politike. Cilj donoenja politike sigurnosti informacijskog sustava jest osiguranje adekvatne
razine sigurnosti informacijskog sustava. Politika sigurnosti informacijskog sustava trebala bi
obuhvatiti podruja upravljake, logike i fizike zatite resursa informacijskog sustava u
skladu s veliinom, obuhvatom i kompleksnosti informacijskog sustava. Na temelju politike
sigurnosti informacijskog sustava banka bi trebala propisati i primijeniti detaljne interne akte
koji se odnose na sve aspekte sigurnosti informacijskog sustava. Politiku sigurnosti
informacijskog sustava potrebno je usklaivati s promjenama u informacijskom sustavu i u
njegovoj okolini, u sluajevima naruavanja sigurnosti informacijskog sustava, te ovisno o
rezultatima procjene rizika. Politika sigurnosti informacijskog sustava treba sadravati barem
sljedee:
cilj i opseg politike sigurnosti informacijskog sustava
naela upravljanja sigurnou informacijskih resursa
ope i posebne odgovornosti koje se odnose na sigurnost informacijskog sustava.
Naela upravljanja sigurnou resursa informacijskog sustava trebala bi obuhvatiti barem
sljedea podruja:
upravljanje rizikom informacijskog sustava
klasifikaciju informacija
upravljanje sigurnou komunikacijskih i distribucijskih kanala
osiguravanje kontinuiteta poslovanja banke
upravljanje incidentima
oporavak informacijskog sustava
upravljanje priuvnom pohranom
razvoj informacijskih sustava unutar banke
upravljanje odnosima s pruateljima usluga i dobavljaima opreme
upravljanje kontrolama pristupa resursima informacijskog sustava
fiziku sigurnost
upravljanje operativnim i sistemskim zapisima
zatitu od malicioznog koda
upravljanje imovinom informacijskog sustava
upravljanje promjenama
upravljanje konfiguracijama
upravljanje dokumentacijom
izobrazbu korisnika informacijskog sustava.
Politika sigurnosti informacijskog sustava treba biti djelotvorna i primjenjiva kako bi se
omoguilo ostvarivanje poslovnih ciljeva banke.
39
5.2. Upravljanje kontrolama pristupa

Kontrole pristupa omoguuju provoenje radnja nad resursima informacijskog sustava
(primjerice koritenje, mijenjanje, pregled) u skladu s dodijeljenim ovlastima. Pristup se moe
definirati kao svojstvo koje omoguuje obavljanje razliitih radnja na informacijskom
sustavu. Kontrolama pristupa eksplicitno se omoguava, ograniava ili zabranjuje pristup
resursima informacijskog sustava, i to koritenjem pojedine kontrole ili kombinacijom
upravljakih, logikih i fizikih kontrola. Proces kontrole pristupa obuhvaa uvoenje niza
pojedinanih kontrola pristupa. Cilj uvoenja kontrola pristupa jest sprjeavanje neovlatenog
pristupa resursima informacijskog sustava. Pri implementaciji kontrola pristupa potrebno je
uzeti u obzir sigurnosne zahtjeve, zahtjeve poslovnih procesa i jednostavnost koritenja za
korisnike.
5.2.1. Kriteriji pristupa resursima

Banka bi trebala kontrolirati pristup resursima informacijskog sustava primjenjujui, prema
potrebi, neke od sljedeih kriterija:
Identitet korisnika. Identitet korisnika mora biti jedinstven kako bi se mogle utvrditi
ovlasti i odgovornosti svakog korisnika.
Funkcija. Pristup informacijama mora biti kontroliran na temelju dodijeljenih poslova
i dunosti u skladu s naelima podjele poslova i segregacije dunosti. Navedeno
ukljuuje odreivanje radnja koje se mogu obavljati nad resursima informacijskog
sustava (primjerice pravo itanja, pisanja, izvravanja i brisanja).
Lokacija. Identifikacija i autentifikacija mogu ovisiti i o fizikoj i logikoj lokaciji
osobe, procesa ili sustava koji zahtijevaju pristup (primjerice kada korisnici pristupaju
s lokacije koja se nalazi unutar banke, mogu im se dopustiti vee ovlasti nego kada
pristupaju putem javno dostupnih telekomunikacijskih mrea).
Vrijeme. Ogranienje kojim se onemoguuje pristup u odreenom razdoblju tijekom
dana ili odreenih dana u tjednu odnosno u mjesecu (primjerice koritenje nekih
resursa moe biti doputeno samo tijekom radnog vremena).
Transakcija. Pristup resursima informacijskog sustava moe biti ogranien ovisno o
tijeku poslovnog procesa (primjerice isplatu s rauna nije mogue obaviti dok se
provodi neka druga isplata ili uplata na taj raun).
5.2.2. Upravljanje korisnikim pravima

Svakom resursu informacijskog sustava moe se pristupati od strane nekog drugog resursa
(koji moe, ali i ne mora biti dio informacijskog sustava banke), ukljuujui i osobe. Prava
pristupa koja su vea od onih koja su minimalno potrebna za obavljanje poslova, izlau
informacijski sustav banke riziku naruavanja temeljnih naela informacijskog sustava. Prema
tome, cilj upravljanja pravima pristupa jest identificirati pristup i ograniiti pristup pojedinom
resursu na minimalnu razinu dovoljnu za djelotvorno obavljanje radnih zadataka.
40
Upravljanje korisnikim pravima (pri tome se misli na osobe, sustave i procese) sastoji se od
etiriju procesa:
Evidentiranje. Podrazumijeva dodavanje novih korisnika informacijskog sustava.
Ovim procesom utvruje se identitet korisnika te odreuju informacije i sustavi
potrebni za obavljanje radnih zadataka u skladu s opisom radnoga mjesta.
Autorizacija. Podrazumijeva dodjelu prava pristupa korisnika informacijskom
sustavu banke. Navedeno obuhvaa dodavanje, brisanje ili modificiranje dodijeljenih
prava pristupa operativnim sustavima, aplikacijama i specifinim vrstama informacija.
Postupak dodjele prava pristupa treba biti formaliziran te sva prava trebaju odobriti
ovlatene osobe.
Identifikacija i autentifikacija. Podrazumijeva identifikaciju korisnika i potvrdu
njegova identiteta prilikom prijave i tijekom provoenja radnja na informacijskom
sustavu.
Nadzor. Obuhvaa praenje, izmjenu i revidiranje prava pristupa korisnika
Banka bi trebala uspostaviti djelotvoran proces upravljanja korisnikim pravima pristupa.
Navedeni proces trebao bi ukljuiti sljedee kontrole:
dodjeljivanje korisnicima prava pristupa koja su strogo ograniena na one kontrole
koje su potrebne za obavljanje redovnih poslovnih zadataka
auriranje prava pristupa (primjerice na temelju kadrovskih promjena, promjena na
informacijskom sustavu i njegovu okruenju)
periodino pregledavanje korisnikih prava pristupa (uestalost pregledavanja trebala
bi se temeljiti na procjeni rizika).
5.2.3. Identifikacija i autentifikacija

Identifikacija i autentifikacija kljune su komponente u izgradnji sigurnosti informacijskog
sustava jer su osnova za mnoge vrste kontrola pristupa i utvrivanja odgovornosti korisnika
(dokazivost). Utvrivanje odgovornosti korisnika zahtijeva povezivanje aktivnosti na
informacijskom sustavu s tono odreenim osobama, procesima ili sustavima te je u tu svrhu
potrebno da ih informacijski sustav identificira i autentificira.
5.2.3.1. Identifikacija
Identifikacija je proces kojim korisnik predoava informacijskom sustavu zahtijevani
identitet. Identifikacija na informacijskim sustavima najee se provodi pomou jedinstvene
korisniko-identifikacijske oznake (engl. User ID). Pri upotrebi navedene oznake potrebno je
obratiti posebnu pozornost na sljedee:
Jedinstvenu identifikaciju. Potrebno je osigurati jedinstvenu identifikaciju svakom
korisniku informacijskog sustava. U odreenim sluajevima moe se dopustiti
upotreba grupnog identiteta, no to je poeljno izbjegavati jer onemoguuje dokazivost.
Upravljanje jedinstvenim korisniko-identifikacijskim oznakama. Ovlasti za rad
na sustavu potrebno je pratiti i aurirati. Kako bi se omoguilo praenje povijesnih
aktivnosti korisnika, potrebno je procijeniti potrebu za uvanjem korisnikoidentifikacijske oznake i nakon ukidanja korisnikovih ovlasti.
41
Neaktivne jedinstvene korisniko-identifikacijske oznake. Korisnike koji su u

odreenom razdoblju neaktivni na pojedinom resursu informacijskog sustava, treba
analizirati i prema procjeni dezaktivirati njihove oznake i ukinuti ovlasti.
Uzajamnu povezanost aktivnosti i korisnika. Informacijski sustav treba osigurati
praenje identiteta svih korisnika i biti sposoban povezati aktivnosti s tono
odreenim korisnicima.
5.2.3.2. Autentifikacija
Autentifikacija je proces kojim se potvruje korisniki identitet koji zahtijeva pristup
informacijskom sustavu. Postoje tri naina utvrivanja neospornosti korisnikog identiteta
koji se mogu primjenjivati samostalno ili u kombinaciji:
neto to samo korisnik zna (primjerice zaporka, PIN, kriptografski klju)
neto to samo korisnik posjeduje (primjerice "token", magnetska kartica, "pametna
kartica")
neto to korisnik jest (primjerice biometrijske metode kao to su otisak prsta,
skeniranje ronice, prepoznavanje glasa i slino).
Banka bi trebala osigurati barem sljedee:
Autentificiranje korisnika. Banka bi trebala zahtijevati od korisnika da potvrdi svoj
identitet na informacijskom sustavu. Isto tako, banka bi u skladu s procjenom rizika
trebala razmotriti i mogunost autentifikacije korisnika pomou metode samo jedne
prijave (engl. single sign-on) kojom se pristupa razliitim resursima informacijskog
sustava.
Ogranien pristup autentifikacijskim oznakama. Autentifikacijske oznake trebaju
biti adekvatno zatiene (primjerice primjenom rigoroznih kontrola pristupa i
jednosmjernim kriptiranjem) kako bi se sprijeilo da neovlateni korisnici dou u
posjed navedenih oznaka.
Siguran prijenos autentifikacijskih oznaka. Banka bi trebala adekvatno zatititi
autentifikacijske oznake prilikom njihova prijenosa javno dostupnim ili privatnim
telekomunikacijskim mreama.
Ograniiti broj pokuaja pristupa. Banka bi trebala ograniiti broj neuspjelih
pokuaja pristupa, odnosno onemoguiti upotrebu korisniko-identifikacijske oznake
nakon odreenog broja neuspjelih pokuaja pristupa resursima informacijskog sustava.
Zatita autentifikacijskih oznaka prilikom unoenja. Banka bi trebala adekvatno
zatititi autentifikacijske oznake od kompromitiranja prilikom unosa u informacijski
sustav (primjerice skrivanje zaporka pri unosu).
Upravljanje autentifikacijskim oznakama. Banka bi trebala adekvatno upravljati
autentifikacijskim oznakama (primjerice definirati postupke za aktivaciju
autentifikacijskih oznaka i dezaktivaciju izgubljenih i ukradenih oznaka).
42
5.2.4. Upravljanje zaporkama

Zaporke su najee upotrebljavan mehanizam autentifikacije korisnika. Meutim, zbog
neprimjerenih navika korisnika informacijskog sustava (primjerice dijeljenja zaporka i
njihove neadekvatne pohrane te upotrebe neprimjerenih zaporka) one su i jedan od najslabijih
mehanizama autentifikacije. Primjereno upravljanje zaporkama (koje ukljuuje uklanjanje
poznatih ranjivosti i prevenciju uobiajenih napada) moe uvelike unaprijediti sigurnost
Napadi na zaporke odnosno pokuaji njihova otkrivanja ili zaobilaenja jedna su od najeih
vrsta napada na informacijske sustave. Neke od najeih podvrsta napada na zaporke jesu:
pokuaj pogaanja zaporka isprobavanjem svih kombinacija doputenih simbola (engl.
dictionary attack)
pokuaj pogaanja zaporka pomou specifinih informacija o osobi koja rabi tu
zaporku (primjerice ime suprunika, imena djece, ime kunog ljubimca i slino)
pokuaj neautorizirane autentifikacije pomou standardnih zaporka koje inicijalno
definiraju proizvoai hardvera, softvera i telekomunikacijske opreme
pokuaj neautorizirane autentifikacije pomou zaporka ija je povjerljivost naruena
zbog neadekvatne pohrane.
Ovisno o procjeni rizika, odnosno riziku razotkrivanja zaporka i negativnom uinku koji moe
nastati kao posljedica tog razotkrivanja, banka bi trebala postii adekvatnu razinu zatite
zaporka pomou upravljakih, logikih i fizikih kontrola. Zbog mnogobrojnih ranjivosti koje
proizlaze iz neadekvatnog koritenja zaporki, te velikog broja prijetnja koje pokuavaju
iskoristiti te ranjivosti, banka bi trebala propisati restriktivne postupke upravljanja zaporkama,
kako bi se osjetljivost na tu vrstu napada svela na najmanju moguu mjeru.
Pri upravljanju zaporkama banka bi trebala uzeti u obzir barem sljedee:
sve zaporke moraju biti povjerljive;
zaporke ne smiju biti pohranjene ni prikazane u itljivom (nekriptiranom) obliku izvan
adekvatno osigurane okoline (primjerice u sefu);
zaporke ne smije dijeliti vie korisnika kako bi se osigurala dokazivost;
potrebno je definirati razdoblje nakon kojega se zaporka mora izmijeniti te
onemoguiti viekratnu upotrebu iste zaporke;
zaporke je potrebno izmijeniti ukoliko se pojavi i najmanja sumnja da su njihova
povjerljivost ili integritet narueni;
potrebno je propisati standarde kreiranja zaporka koji e biti u skladu s dobrim
praksama i ogranienjima sustava za autentifikaciju te ukljuivati propisivanje:
najmanje doputene duljine zaporka
obavezne uporabe to ireg znakovnog skupa
nemogunosti upotrebe tri ili vie uzastopnih identinih simbola u zaporci;
pri prvoj upotrebi potrebno je izmijeniti prvobitne (inicijalne) i standardne zaporke,
kao i ostale zaporke koje su zadali proizvoai i dobavljai informacijske opreme ili
pruatelji usluga, a pomou kojih se pristupa resursima banke;
mogunost autentifikacije pomou odreene zaporke potrebno je sprijeiti ako
korisnik vie puta uzastopno pogrijei pri unosu te zaporke.
43
5.2.5. Mehanizmi kontrole pristupa

Prilikom implementiranja kontrola pristupa banka bi trebala razmotriti upotrebu, primjerice
sljedeih mehanizama:
Pristupne liste (engl. Access Control Lists). Pristupne liste su evidencije korisnika
(ukljuujui i grupe, sustave i procese) kojima su dane ovlasti za koritenje pojedinih
resursa informacijskog sustava i poduzimanje radnja u vezi s njima.
Ogranieno korisniko suelje. Pristup pojedinim resursima i funkcijama
informacijskog sustava ogranien je na radnje za koje je korisnik ovlaten, primjerice
upotrebom dinamikih izbornika, upotrebom prikaza podataka iz tablica baze
podataka (engl. database view), upotrebom fizikog ogranienja korisnikog suelja
na bankomatima i slino.
Kriptografija. Kriptografske metode omoguuju primjenu sigurnijih kontrola
pristupa. Da bi te metode bile djelotvorne, potrebno je uspostaviti rigorozan sustav
upravljanja kriptografskim kljuevima.
Vatrozidi i ostala suelja izmeu telekomunikacijskih mrea. Navedeni ureaji
filtriraju promet izmeu povezanih telekomunikacijskih mrea i doputaju lokalnim
korisnicima povezivanje s vanjskim mreama, dok u isto vrijeme tite informacijski
sustav banke od naruavanja temeljnih naela informacijskog sustava.
5.2.6. Pristup telekomunikacijskim mreama banke

Mrena sigurnost zahtijeva djelotvornu primjenu razliitih vrsta kontrola kako bi se adekvatno
zatitio pristup resursima informacijskog sustava. Prema sloenosti njezine
telekomunikacijske mree banka bi trebala ocijeniti i na odgovarajui nain primijeniti
upravljake, logike i fizike kontrole. Dobre prakse nalau uvoenje sljedeeg:
grupiranje mrenih posluitelja, aplikacija, korisnika te ostalih resursa informacijskog
sustava u sigurnosne zone, primjerice podjelu u zonu nad kojom banka nema potpunu
kontrolu (npr. internet), zonu vanjskih pruatelja usluga i zone razliitih grupa internih
korisnika
uspostavu odgovarajuih pravila pristupa unutar pojedine sigurnosne zone ili izmeu
vie razliitih zona
primjenu odgovarajuih upravljakih, logikih i fizikih kontrola kako bi se dosljedno
udovoljilo prethodno navedenim pristupnim zahtjevima.
5.2.7. Pristup sistemskom softveru

Sistemski softver obuhvaa operativne sustave i sistemske uslune programe. Banka bi trebala
primjereno zatititi pristup sistemskom softveru uzimajui u obzir sljedee:
ograniavanje pristupa sistemskim uslunim programima
ograniavanje upotrebe i nadzor povlatenog pristupa
evidentiranje i nadzor pristupa osjetljivim resursima od strane osoba, procesa ili
sustava
nadograivanje operativnih sustava sigurnosnim programskim ispravkama (engl.
security patch)
44
zatitu pristupnih toaka (ukljuujui i ogranienje broja pristupnih toaka), putem

kojih se moe pristupiti operativnom sustavu, primjenom logikih i fizikih kontrola.
5.2.8. Pristup aplikacijama

U skladu s procjenom rizika u aplikacije je potrebno ugraditi mehanizme kontrole pristupa
kojima se ograniava pristup osobama, procesima i sustavima. Za ostvarivanje djelotvorne
kontrole pristupa aplikaciji nuna je suradnja osoba zaduenih za sigurnost, zaposlenika koji
sudjeluju u razvoju i odravanju aplikacije (ukljuujui dobavljae aplikacija i pruatelje
usluga odravanja) te osoba odgovornih za poslovne procese. Banka bi trebala kontrolirati
pristup aplikacijama koristei, primjerice, sljedee:
mehanizme autentifikacije i autorizacije koji odgovaraju procjeni rizika pojedine
aplikacije
nadzor prava pristupa kako bi se osiguralo da su prava korisnika na razini minimalno
potrebnih za obavljanje poslovnih zadataka
pristup aplikaciji samo u odreenom razdoblju (primjerice samo u radno vrijeme)
evidentiranje pristupa i sigurnosnih dogaaja (primjerice praenjem sistemskih i
operativnih zapisa)
softver koji omoguava brzu analizu aktivnosti korisnika.
5.2.9. Udaljeni pristup

Banka bi trebala biti svjesna mogunosti koje prua udaljeni pristup sustavu i ranjivosti koje
iz toga proizlaze, te bi prema tome trebala definirati naine primjene i ogranienja udaljenog
pristupa. Svrha je navedenog svoenje na najmanju moguu razinu izloenosti banke teti
koja moe proizii iz neovlatenog koritenja informacijskih resursa banke. Banka bi trebala
zatititi pristup svojim sustavima s udaljene lokacije uzimajui u obzir sljedee:
internim je aktima potrebno onemoguiti udaljeni pristup osim ako za to postoje
opravdane poslovne potrebe
potrebno je strogo kontrolirati pristup pomou formalnog sustava odobrenja i revizije
dodijeljenih prava za udaljeni pristup;
potrebno je uvesti rigorozne kontrole nad konfiguracijama resursa informacijskog
sustava koji omoguuju udaljeni pristup kako bi se banka zatitila od mogue
zloupotrebe udaljenog pristupa (primjer takve kontrole je automatski povratni poziv);
primjenu evidentiranja i nadzora svih radnja provedenih koritenjem udaljenog
pristupa (primjerice praenjem sistemskih i operativnih zapisa); navedeno ukljuuje
podatke kao to su datum, vrijeme, korisnik, lokacija korisnika, trajanje i svrha svih
udaljenih pristupa;
u svrhu zatite komunikacija potrebno je primijeniti "jaku" autentifikaciju (primjerice
kombinaciju dvaju naina utvrivanja neospornosti korisnikog identiteta) i enkripciju
(primjerice VPN).
45
5.2.10. Povlateni pristup

Povlateni pristup omoguuje zaobilaenje sistemskih i aplikativnih kontrola informacijskog
sustava. Stoga je posebnu pozornost potrebno posvetiti kontroli osoba, procesa i sustava s
pravom povlatenog pristupa komponentama informacijskoga sustava banke (primjerice
korisnika s administratorskim ovlastima na operativnim sustavima, aplikacijama, bazama
podataka i mrenim resursima). Dobre prakse kontrole povlatenog pristupa ukljuuju:
identificiranje svih osoba, procesa i sustava s povlatenim pravima pristupa
koritenje povlatenim pristupom iskljuivo za radnje koje se ne mogu obaviti pomou
pristupa s manjim pravima
uspostavu formalnog sustava dodjele prava povlatenog pristupa
periodino revidiranje postupka dodjeljivanja te dodijeljenih prava povlatenog
pristupa
evidentiranje i revidiranje aktivnosti koje se provode putem povlatenog pristupa
(primjerice pregledom sistemskih i operativnih zapisa)
rigoroznu zatitu identifikacijskih i autentifikacijskih oznaka koje se rabe za
povlateni pristup na informacijskom sustavu
definiranje postupaka koji e u izvanrednim situacijama ovlatenim osobama
omoguiti povlateni pristup informacijskom sustavu (primjerice saznavanje
identifikacijskih i autentifikacijskih oznaka korisnika s administratorskim ovlastima
pohranjenih u sefu u itljivom obliku)
izbjegavanje dijeljenja istih identifikacijskih i autentifikacijskih oznaka s pravima
povlatenog pristupa izmeu vie korisnika.
46
5.3. Kriptografija
Banka bi trebala na osnovi obavljene procjene rizika odrediti adekvatne kriptografske metode
ija e primjena smanjiti rizik od naruavanja temeljnih naela informacijskog sustava.
Osnovne komponente svake kriptografske metode jesu kriptografski algoritam (opisuje kako
se provodi transformacija) te jedan ili vie kriptografskih kljueva (podatak pomou kojeg se
obavlja transformacija). Kriptografske metode omoguuju zatitu podataka i kada oni vie
nisu pod kontrolom njihova vlasnika. Kriptografske metode rabe se kao vrsta logikih
kontrola, te se njima dodatno osigurava zatita informacija i smanjuje rizik od naruavanja
temeljnih naela informacijskog sustava. Kriptografija se najee upotrebljava:
za enkripciju (enkripcija ili ifriranje je proces u kojem se podaci transformiraju u
neitljivu formu iz koje poetne podatke mogu dobiti samo osobe koje posjeduju
kriptografski klju pomou kojega se obavlja dekripcija; enkripcija osigurava
povjerljivost podataka prilikom njihovog prijenosa ili pohrane)
za elektroniko potpisivanje (elektroniki potpis moe se dodati bilo kojem podatku
pohranjenom u elektronikom obliku; njime se, pomou kriptografskih mehanizama,
omoguuje potvrivanje temeljnih naela informacijskog sustava)
za ouvanje integriteta podataka
za utvrivanje autentinosti korisnika.
Posebnu pozornost potrebno je posvetiti upravljanju kriptografskim kljuevima (ukljuujui,
primjerice, postupke njihova generiranja, pohrane, razmjene, upotrebe, uklanjanja iz upotrebe
i unitavanja). Izgubljeni ili oteeni dekripcijski kljuevi mogu onemoguiti ovlatenim
osobama pravodobni pristup podacima.
Kriptografske metode mogu se implementirati pomou softverskih ili hardverskih resursa te
njihovom kombinacijom. Dobre prakse nalau primjenu provjerenih kriptografskih algoritama
i implementacija koje su bile predmet detaljnog i opsenog testiranja.
47
5.4. Fizika sigurnost

Fizika sigurnost obuhvaa kontrole koje se provode radi zatite resursa informacijskog
sustava od neovlatenog fizikog pristupa, krae, fizikog oteenja ili unitenja. Temeljna
naela informacijskog sustava mogu biti naruena izmeu ostalog zbog neovlatenog fizikog
pristupa i oteenja ili unitenja imovine informacijskog sustava. Rizici povezani s fizikom
sigurnou mogu se smanjiti uvoenjem sigurnosnih zona. Sigurnosne zone (u nastavku
teksta: zone) fiziki su prostori s razliitim zahtjevima fizike sigurnosti. Sigurnosni zahtjevi
za svaku zonu proizlaze iz vrste i osjetljivosti resursa informacijskog sustava koji su smjeteni
u zoni, te se trebaju definirati u skladu s procjenom rizika, pri emu valja uzeti u obzir
razliite vrste prijetnja (prirodne, uzrokovane ljudskim djelovanjem, sluajne ili namjerne) i
ranjivosti te posljedice neeljenih dogaaja.
Banka bi trebala definirati zone i primijeniti odgovarajue upravljake, logike i fizike
kontrole u svakoj od definiranih zona. Navedene se kontrole, izmeu ostalog, primjenjuju radi
zatite prostorija s resursima informacijskog sustava, samih resursa, kao i sustava koji su
podrka funkcioniranju informacijskog sustava (primjerice sustava napajanja elektrinom
energijom, sustava za grijanje i klimatizaciju i slino).
Banka bi trebala uzeti u obzir sljedee imbenike koji mogu utjecati na fiziku sigurnost:
Kontrole fizikog pristupa. Kontrole fizikog pristupa ograniavaju ulaske i
naputanje prostorija u kojima su smjeteni resursi informacijskog sustava banke kao i
unoenje te iznoenje opreme i medija. Primjeri su ovakvih prostorija raunalni centri,
prostorije s posluiteljima, prostorije s telekomunikacijskom opremom i slino.
Zatita od poara. Poar ima potencijal da djelomino ili potpuno uniti resurse
informacijskog sustava (ukljuujui i rizik za ljudske ivote). Isto tako, dim,
nagrizajui plinovi i vlaga, koji se oslobaaju za vrijeme poara, mogu nainiti tetu i
na ostalim dijelovima sustava irei se kroz graevinski objekt.
Sustavi za podrku. Banka bi trebala osigurati ispravan rad sustava za podrku.
Zastoji u radu sustava za podrku (primjerice sustava za odravanje stabilnog i
neprekinutog napajanja elektrinom energijom, sustava za grijanje, sustava za
klimatizaciju i slino) mogu izazivati prekide u radu informacijskog sustava i njegovo
oteenje. Dobre prakse nalau provoenje kontrole svojstava zraka (primjerice
temperature, vlanosti, istoe i koncentracije oneienosti zraka) u prostoru s
resursima informacijskog sustava kako bi se udovoljilo zahtjevima osoblja i
Konstrukcija objekta. Potrebno je imati u vidu da graevinski objekt moe biti
podvrgnut veem optereenju nego to je u stanju izdrati. Konstrukcija objekta moe
biti oteena, oslabljena ili unitena zbog potresa, raznih dodatnih optereenja,
eksplozija ili poara. Posljedica unitenja graevinskog objekta moe biti fiziko
oteenje ili unitenje (dijela) informacijskog sustava.
Zatita od utjecaja vode. Prodor vode moe biti razoran za informacijski sustav.
Potrebno je razmotriti posljedice koje prodor vode moe izazvati i posjedovati tone
informacije o mrei vodovodnih instalacija te instalacija rashladnih ureaja koje mogu
ugroziti resurse informacijskog sustava. Banka bi trebala, u skladu s procjenom rizika,
poduzeti adekvatne mjere za smanjenje rizika kao to su ugradnja "dvostrukog poda",
premjetanje resursa informacijskog sustava te vodovodnih instalacija i slino.
48
5.5. Upravljanje operativnim i sistemskim zapisima

Operativni i sistemski zapisi omoguuju uvid u aktivnosti resursa informacijskog sustava
(primjerice operativnih sustava, vatrozida, usmjernika, sustava za otkrivanje neovlatenog
pristupa i radnja na informacijskom sustavu, aplikacijskih sustava, procesa, osoba). U
kombinaciji s odgovarajuim internim aktima, procedurama i alatima, operativni i sistemski
zapisi (u nastavku teksta: zapisi) omoguuju postizanje ciljeva povezanih sa sigurnou i
funkcionalnou, ukljuujui rekonstrukciju dogaaja, osobnu odgovornost, otkrivanje
neovlatenog pristupa i radnja te identifikaciju problema. Zapisi se, izmeu ostalog,
upotrebljavaju za sljedee:
Rekonstrukciju dogaaja. Banka moe upotrebljavati zapise za rekonstrukciju
izvrenih radnja (primjerice kao pomo u naknadnoj istrazi kojom se utvruje kako,
kada i zato su redovne operacije prekinute te tko je, kako i kada obavio odreenu
radnju).
Osobna odgovornost. Zapisi slue za poticanje savjesnog koritenja resursa jer
korisnici znaju da se njihove radnje mogu naknadno analizirati i jedinstveno pratiti do
izvora.
Otkrivanje neovlatenog pristupa i radnja na sustavu. Zapisi se mogu rabiti kao
pomo u otkrivanju neovlatenog pristupa i radnja na sustavu ukoliko je sustav za
otkrivanje takvih aktivnosti pravilno konfiguriran, odnosno ako biljei odgovarajue
informacije. Navedene aktivnosti mogu biti otkrivene u realnom vremenu analizom
zapisa u trenutku kreiranja ili naknadno.
Identifikacija problema. Zapisi mogu takoer pomoi u identificiranju ostalih
sigurnosnih i funkcionalnih problema na informacijskom sustavu u realnom vremenu.
Zapisi trebaju sadravati dovoljnu koliinu informacija za utvrivanje pojave dogaaja i
njihova uzroka. Obuhvat i sadraj zapisa potrebno je pomno definirati, u skladu s procjenom
rizika, kako bi se uravnoteila potreba izmeu sigurnosti s jedne strane, te uinkovitosti i
trokova s druge strane. Posebnu pozornost treba posvetiti ouvanju integriteta zapisa, da bi
se osigurala dokazivost i neporecivost dogaaja. Isto tako, potrebno je osigurati i povjerljivost
zapisa u skladu s klasifikacijom informacija. Openito, zapis o dogaaju treba pruiti
informaciju:
o vrsti dogaaja
o vremenu kada se dogaaj dogodio
o identifikaciji osoba, sustava ili procesa povezanih s dogaajem
o programu ili naredbi koja je upotrijebljena za pokretanje dogaaja.
5.5.1. Sigurnost operativnih i sistemskih zapisa

U svrhu zatite integriteta, dokazivosti i neporecivosti informacijskog sustava operativni i
sistemski zapisi moraju biti adekvatno zatieni od neautoriziranog pristupa, izmjena i
brisanja, pri emu treba imati u vidu barem sljedee:
povjerljivost i integritet zapisa moraju biti adekvatno zatieni;
potrebno je razdvojiti dunosti osoba koje administriraju kontrole pristupa i osoba
zaduenih za sigurnost od osoba koje administriraju zapise;
49
pristup zapisima putem javno dostupnih telekomunikacijskih mrea treba biti strogo
kontroliran.
5.5.2. Praenje operativnih i sistemskih zapisa

Osobe odgovorne za praenje zapisa trebaju redovito pratiti zapise u skladu sa svojim
organizacijskim zaduenjima i ovlastima. Prilikom praenja zapisa potrebno je obratiti
pozornost na sljedee:
Prepoznati uobiajene aktivnosti. Osobe odgovorne za praenje zapisa trebaju znati
koje su aktivnosti uobiajene kako bi mogle uspjeno uoiti neuobiajene aktivnosti.
Omoguiti djelotvorno pretraivanje zapisa. Praenje zapisa moe se olakati
pregledom po parametrima kao to su: korisnika, terminalska i aplikativna
identifikacija, datum i vrijeme ili bilo koji drugi grupni parametar.
Saznanja o postojeim problemima i ogranienjima. Administratori na razini
sustava ili aplikacija trebali bi pregledavati zapise uzimajui u obzir poznate probleme
sustava ili aplikacija, poznata krenja postojeih zahtjeva od strane korisnika i slino.
Razviti smjernice za praenje zapisa. Osobe odgovorne za aplikacije, informacije,
obradu podataka i sigurnost te administratori informacijskog sustava trebaju na
temelju procjene rizika odrediti opseg i uestalost pregleda zapisa.
Automatizirani alati. Banka bi trebala razmotriti primjenu alata koji pomau u
izdvajanju korisnih informacija iz velike koliine podataka koje sadre zapisi
(primjerice u prepoznavanju neovlatenih i neuobiajenih radnja pomou poznatih
uzoraka).
50
5.6. Zatita od malicioznog koda

Maliciozni kod je bilo koji oblik programskog koda koji djeluje neoekivano i na potencijalno
tetan nain. Uobiajene su vrste malicioznog koda virusi, crvi i "trojanski konji", a njihovo
djelovanje moe imati samostalan uinak ili kombinirani, ime se postie vea teta.
Maliciozni kod moe imati mogunost repliciranja i irenja na druge resurse informacijskog
sustava. Nadalje, maliciozni kod moe ugroziti povjerljivost, integritet i raspoloivost resursa
informacijskog sustava mijenjajui i briui podatke, aljui podatke izvan informacijskog
sustava, uklanjajui dokaze koji se mogu iskoristiti za potrebe forenzike ili stvarajui skrivene
ranjivosti koje mogu olakati neovlateni pristup i radnje na informacijskom sustavu.
Zatitne mjere i kontrole
Zatitne mjere i kontrole koje se primjenjuju radi smanjenja rizika od naruavanja ili gubitka
temeljnih naela informacijskog sustava zbog utjecaja malicioznog koda, podrazumijevaju
slojevito oblikovanje sigurnosne infrastrukture to, izmeu ostalog, ukljuuje primjenu
adekvatne tehnologije, internih akata i edukaciju zaposlenika.
Kontrole koje bi banka trebala primijeniti kako bi smanjila prije navedene rizike, izmeu
ostalog, ukljuuju proizvode i sustave za otkrivanje i unitavanje malicioznog koda kao i
ostale sustave za ograniavanje i otkrivanje neuobiajenih ili neovlatenih radnja te za
nadziranje i upravljanje radnjama koje su doputene (primjerice vatrozid, IDS).
Budui da se svakodnevno pojavljuju novi primjeri malicioznog koda i neovlatenih pristupa i
radnja, banka bi trebala to ee, a najmanje jednom dnevno, provjeriti aurnost svojih
sustava zatite od malicioznog koda te neuobiajenih i neovlatenih radnja. Banka bi u sklopu
procjene rizika trebala takoer uzeti u obzir injenicu da sustavi za otkrivanje malicioznog
koda koji se temelje na prepoznavanju uzorka mogu bitno tee (potrebna je dekripcija) otkriti
maliciozni kod u enkriptiranim podacima (primjerice VPN i slino).
Nadalje, banka bi, zbog potencijalno sve sloenijih neovlatenih radnja i zbog toga to se
autori malicioznog koda esto koriste metodama socijalnog inenjeringa, trebala
implementirati ostale kontrole koje, izmeu ostalog, ukljuuju interne akte o upotrebi resursa
informacijskog sustava i edukaciju korisnika informacijskog sustava o moguim prijetnjama.
Banka bi trebala uzeti u obzir sljedee imbenike koji mogu utjecati na sigurnost:
potrebu za redovitim pregledom resursa informacijskog sustava s obzirom na
neautorizirani odnosno nedoputeni softver
sprjeavanje neovlatene instalacije softvera
edukaciju zaposlenika kako bi ih se upozorilo na opasnosti itanja poruka nepoznatog
podrijetla, pokretanja izvrnih datoteka, socijalni inenjering i slino
rukovanje medijima za pohranu i prijenos podataka
naine pristupa javno dostupnim telekomunikacijskim mreama
doputene aktivnosti tijekom pristupa javno dostupnim telekomunikacijskim mreama
kao i tijekom upotrebe tehnologije za komunikaciju (primjerice elektronike pote i
slino)
uklanjanje ranjivosti sustava povezanih s poznatim malicioznim kodovima
51
52
adekvatno upravljanje operativnim i sistemskim zapisima koji se odnose na

maliciozni kod.
6. Odravanje informacijskog sustava

6.1. Upravljanje imovinom informacijskog sustava
Upravljanje imovinom informacijskog sustava proces je koji obuhvaa detektiranje,
evidentiranje, raspolaganje, praenje, planiranje, obnavljanje, zatitu i odlaganje imovine.
Pod imovinom informacijskog sustava (u nastavku teksta: imovina) podrazumijevaju se sve
vrste raunalnog softvera, hardvera, pripadajuih komponenata te informacija koje se
upotrebljavaju za obavljanje poslovnih procesa u banci. Imovina, izmeu ostalog, ukljuuje
sljedee:
informacijsku imovinu: podatke u bazama podataka i datoteke s podacima,
programski kod, sistemsku i aplikacijsku dokumentaciju, korisnike prirunike,
materijal za obuku, planove, politike, strategije, standarde i procedure banke,
arhivirane informacije i slino
softversku imovinu: aplikacijski softver, sistemski softver, razvojne alate i uslune
programe i slino
hardversku imovinu: raunalnu opremu (osobna raunala, posluitelje, monitore,
modeme i slino), komunikacijsku opremu (usmjernike, vatrozide, telefonske centrale,
telefakse, telefonske sekretarice i slino), medije za pohranu podataka (trake,
magnetne diskove, optike medije i slino) i ostalu tehniku opremu (ureaje za
neprekidno napajanje strujom, klimatizacijske ureaje i slino).
Nepostojanje primjerenog procesa praenja imovine moe imati negativan utjecaj na
raspodjelu resursa, distribuciju softvera i hardvera i njihovo odravanje, sigurnost
informacijskog sustava, na popravke imovine i slino. Isto tako, neprimjereno upravljanje
imovinom moe oteati ili onemoguiti identifikaciju imovine te osoba odgovornih za
imovinu i ostalih korisnika, lociranje imovine u svrhu zamjene i auriranja te djelotvorno
obavljanje revizije. Nadalje, neadekvatno upravljanje imovinom poveava pravni rizik,
primjerice rizik od povrede ugovora o upotrebi licenciranog softvera.
Dobre prakse nalau da je u sklopu upravljanja imovinom informacijskog sustava potrebno:
planirati investicije, operativne aktivnosti i pruanje podrke vezane uz imovinu
alocirati imovinu tako da se osigura djelotvorno pruanje usluga
uspostaviti sustav izvjetavanja o planiranim investicijama i koristima koje takve
investicije donose banci
imenovati osobe odgovorne za imovinu
dodijeliti pripadajue odgovornosti za upravljanje i zatitu imovine.
Banka bi trebala uspostaviti proces upravljanja imovinom informacijskog sustava i donijeti
pripadajue interne akte koji e omoguiti adekvatno upravljanje imovinom tijekom njezina
ivotnog ciklusa. ivotni je ciklus imovine razdoblje u kojem se imovina upotrebljava za
obavljanje poslovnih procesa te se, primjerice, sastoji od faze nabave, implementacije,
koritenja, podrke te povlaenja imovine iz upotrebe.
Isto tako, banka bi u sklopu procesa upravljanja imovinom trebala definirati barem sljedee:
postupke upravljanja ivotnim ciklusom imovine
prava i obveze korisnika pri rukovanju imovinom
postupke oznaavanja postojee i novonabavljene imovine
53
54
nain evidentiranja postojanja i lokacije fizikih komponenata imovine

nain evidentiranja ugovora o licenciranju, distribucije softvera, odnosno procesa
instalacije softverske podrke te nadogradnje
postupke za izdavanje imovine zaposlenicima, nadzor nad njom i auriranje evidencija
na godinjoj osnovi
postupke premjetanja, zamjene, skladitenja, unitavanja i trajnog povlaenja imovine
(imajui u vidu, primjerice, brisanje podataka s medija prilikom zamjene, skladitenja
imovine, trajnog naputanja imovine banke i slino).
6.2. Upravljanje promjenama

Brzi napredak informacijske tehnologije, kao i este izmjene poslovnih zahtjeva uzrokuju
potrebu za promjenom softverskih i hardverskih komponenata informacijskog sustava banke.
Navedene promjene mogu rezultirati neoekivanim ponaanjem informacijskog sustava
(primjerice, nekompatibilnou i nestabilnou dijelova sustava, programskim pogrekama
engl. bug i slino) i negativno utjecati na njegovu sigurnost. Stoga postupke izmjene
informacijskih sustava treba formalno propisati, te se ponaati oprezno i u skladu s dobrim
praksama, kako bi se negativni utjecaji sveli na najmanju moguu mjeru. Osnovni je zadatak
upravljanja promjenama osigurati da promjene komponenata informacijskog sustava ne
narue (namjerno ili nenamjerno) sigurnost i funkcionalnost informacijskog sustava.
Proces upravljanja promjenama obuhvaa postupak identifikacije poetnih inaica softverskih
i hardverskih komponenata informacijskog sustava te praenje svih njihovih promjena.
Upravljanje promjenama ukljuuje i upravljanje novim verzijama softvera i hardverskim
komponentama, kao i upravljanje programskim ispravkama ("zakrpa", engl. patch). Potrebno
je sustavno pratiti objavljivanje programskih ispravaka i izmjena, kao i novih verzija
aplikativnih programa i operativnih sustava te ih, ovisno o procjeni prednosti i nedostataka
implementirati na informacijskom sustavu. Posebnu pozornost treba posvetiti programskim
ispravkama i novim verzijama dijelova informacijskog sustava koji ispravljaju sigurnosne
propuste, te ih je na osnovi procjene rizika, a nakon testiranja, potrebno to prije integrirati u
informacijski sustav.
Razina detaljnosti i formalnost procesa upravljanja promjenama trebale bi ovisiti o
osjetljivosti dijela informacijskog sustava koji se mijenja, odnosno trebale bi biti u skladu s
opsegom i karakteristikama samih promjena.
Takoer je potrebno analizirati potencijalne promjene informacijskog sustava te na temelju
definiranih razloga i oekivanja od provoenja promjene odrediti i odobriti daljnje postupke i
njihov opseg. Ovisno o rezultatima analize, a u skladu s opsegom i karakteristikama
promjene, analiza uvoenja promjene ne mora nuno ukljuivati i provedbu procjene rizika.
Proces promjene informacijskih sustava trebao bi biti propisan, standardiziran i sadravati
barem sljedee:
definiranje zahtjeva kojim se trai promjena
analizu opravdanosti zahtjeva s izvedenim zakljucima kao i procjenu utjecaja na
poslovne procese, pojedine dijelove i komponente informacijskog sustava te sigurnost
sustava (primjerice planiranje kontinuiteta poslovanja, politiku sigurnosti
informacijskog sustava, funkcionalnost i sigurnost aplikacija i baza podataka)
planiranje testiranja i definiranje rezultata koji se trebaju ostvariti kako bi se
promijenjeni sustav postavio u produkcijsku okolinu; testiranje se mora obaviti u
obuhvatu koji ovisi o opsegu i karakteristikama promjene sustava i u kontroliranim
uvjetima te u okolini koja je u najveoj moguoj mjeri slina produkcijskoj; prilikom
testiranja treba voditi rauna o povjerljivosti informacija
kreiranje nove odnosno nadopunu ve postojee dokumentacije
provedbu potrebne edukacije zaposlenika
planiranje i uvoenje promjena informacijskog sustava u produkcijsku okolinu;
posebnu pozornost potrebno je posvetiti sigurnosti informacijskog sustava odnosno
55
mogunosti naruavanja temeljnih naela informacijskog sustava prije, tijekom ili

nakon provoenja promjene
dokumentiranje provedenih promjena
definiranje osoba ovlatenih i odgovornih za provoenje svih navedenih postupaka
arhiviranje dokumentacije nastale u procesu promjene informacijskih sustava.
Banka bi trebala posebnu pozornost posvetiti rizicima koji proizlaze iz neadekvatnog

upravljanja promjenama, zato to:
izostanak pravodobne promjene informacijskog sustava banke moe ostaviti
neispravljenima uoene sigurnosne propuste
izostanak analize ili provedba neadekvatne analize moe dovesti do uvoenja
nepotrebne ili ak tetne promjene informacijskog sustava
izostanak testiranja promjena informacijskog sustava moe dovesti do
nekompatibilnosti dijela informacijskog sustava, nestabilnosti sustava ili poveane
izloenosti banke vanjskim i unutarnjim prijetnjama;
promjena informacijskog sustava bez pravodobnog auriranja dokumentacije moe
dovesti do neusklaenosti izmeu stvarnog i dokumentiranog stanja sustava
promjena informacijskog sustava bez pravodobne edukacije korisnika moe dovesti do
njihove neadekvatne osposobljenosti za rad na informacijskom sustavu
suvie formalan i detaljan proces upravljanja promjenama informacijskog sustava
moe dovesti do nepravodobnog provoenja ili neprovoenja potrebnih promjena, to
moe rezultirati nestabilnou sustava ili poveanom izloenou banke vanjskim i
unutarnjim prijetnjama
neadekvatno praenje objave novih programskih ispravaka i izmjena, te novih verzija
dijelova informacijskog sustava moe ugroziti sigurnost i smanjiti funkcionalnost
56
6.3. Upravljanje konfiguracijama

Veinu hardverskih i softverskih komponenata informacijskog sustava mogue je pomou
niza postavka prilagoditi specifinim potrebama banke. Navedene postavke moraju biti na
zadovoljavajui nain konfigurirane, kako bi se funkcionalnost i sigurnost sustava dovele i
odrale na potrebnoj razini. Postupak upravljanja postavkama sustava nazivamo upravljanjem
konfiguracijama sustava. Upravljanje konfiguracijama je proces analize, definiranja,
dokumentiranja, testiranja, uvoenja u produkcijski rad, kontrole i praenja izmjena u
postavkama komponenata informacijskog sustava. Upravljanje konfiguracijama treba
obuhvatiti sve osjetljive postavke informacijskog sustava. Osjetljivim postavkama smatraju se
sve postavke ija izmjena moe znatno utjecati na sigurnost ili funkcionalnost informacijskog
sustava. Kriteriji, naini i postupci upravljanja konfiguracijama trebaju biti definirani i
propisani.
Procjenu rizika potrebno je provesti za nove komponente sustava, kao i prilikom promjena
sustava koje imaju utjecaj na funkcionalnost postojeih postavka ili omoguuju nove postavke
komponenata informacijskog sustava. Banka bi trebala na temelju obavljene procjene rizika
za hardverske i softverske komponente informacijskog sustava analizirati, odrediti, testirati i
dokumentirati sigurnosne i funkcionalne postavke komponenata sustava koje moraju biti
primijenjene kako bi se osiguralo odravanje temeljnih naela informacijskog sustava.
Izmjene propisanih postavka komponenata informacijskog sustava potrebno je dokumentirati
na nain koji omoguuje praenje izmjena tijekom vremena. Sustav upravljanja
konfiguracijama mora omoguiti identifikaciju svih osjetljivih postavka informacijskog
sustava (koje su znaajne za djelotvorno i sigurno funkcioniranje sustava) u odreenom
trenutku. Isto tako, potrebno je definirati odgovornosti za upravljanje konfiguracijama
informacijskog sustava s posebnim naglaskom na zaposlenike koji su ovlateni mijenjati
osjetljive postavke sustava. Pristup postavkama koje mogu utjecati na sigurnost i mogunost
njihove izmjene moraju biti nadzirani i kontrolirani.
Banka bi trebala posebnu pozornost posvetiti rizicima koji proizlaze iz neadekvatnog
upravljanja konfiguracijama, zato to:
nezadovoljavajue postavljena poetna konfiguracija hardverskih i softverskih
komponenata moe dovesti do nekompatibilnosti dijela informacijskog sustava, do
nestabilnosti sustava, te do poveane izloenosti banke vanjskim i unutarnjim
prijetnjama;
izmjene dijelova informacijskog sustava bez adekvatnog praenja postavka ili
nekontrolirane promjene postavki mogu naruiti sigurnost i funkcionalnost sustava;
suvie restriktivan proces upravljanja konfiguracijama moe obeshrabriti, sprijeiti ili
usporiti provoenje potrebnih izmjena dijelova informacijskih sustava.
57
6.4. Dokumentacija
Banka bi trebala definirati standarde izrade, pohrane, odravanja i uvanja dokumentacije
koja se odnosi na informacijski sustav banke (u nastavku teksta: dokumentacija).
Dokumentacija je korisna samo ako je tona, potpuna i aurna, te je takvom treba i odravati.
Stoga je potrebno definirati osobe odgovorne za dokumentaciju i njihove dunosti u
odravanju tonosti, potpunosti i aurnosti dokumentacije.
Banka bi trebala zaposlenicima osigurati pristup dokumentaciji koja je povezana s njihovim
poslovnim potrebama. Pristup povjerljivoj dokumentaciji mora biti ogranien, kako bi svaki
zaposlenik mogao pristupiti samo dokumentima za koje je ovlaten. Vanu dokumentaciju (u
skladu s klasifikacijom informacija) trebalo bi pohraniti i na sigurnu udaljenu lokaciju te je
periodino aurirati.
Dobre prakse nalau organiziranje i voenje dokumentacije na takav nain da se za dokument
mogu utvrditi odgovorne osobe, vrijeme nastanka, poetak primjene, klasifikacija te inaica.
Potrebno je uspostaviti i evidenciju koja e omoguiti sveobuhvatni pregled postojee
dokumentacije.
Primjeri dokumentacije:
interni akti vezani uz informacijski sustav (odluke, politike, procedure, upute,
standardi i slino)
opisi hardvera i softvera
programska dokumentacija (programski kod, dijagrami i opisi naina funkcioniranja
programa i slino)
dijagrami i opisi poslovnih procesa
korisnika dokumentacija
ugovori s dobavljaima i pruateljima usluga
izvjea, planovi, zapisnici, dopisi i ostala korespondencija.
58
6.5. Izobrazba
Izobrazba, odnosno edukacija, kontinuirani je proces koji se mora neprekidno odvijati kako bi
se osiguralo da znanja korisnika sustava prate promjene i u informacijskom sustavu i u
njegovoj okolini. Spomenute promjene ukljuuju izmjene postojeih funkcionalnosti i
sigurnosnih obiljeja informacijskog sustava ili dodavanje novih kao i sve promjene izvan
informacijskog sustava banke koje na njega mogu utjecati.
Veina tetnih (neplaniranih i neeljenih) dogaaja na informacijskim sustavima nastaje kao
posljedica ljudskog djelovanja. Od navedenih tetnih dogaaja zaposlenici poslovnog subjekta
uzrokuju kudikamo vei broj nego ostale osobe. Neplanirani i neeljeni dogaaji najee
nastaju kao posljedica nenamjernih radnja (pogreaka ili propusta) ili, rjee, kao posljedica
namjernih radnja poinjenih s ciljem nanoenja tete informacijskom sustavu banke. Kako bi
se navedeni dogaaji i njihovo tetno djelovanje sveli na prihvatljivu razinu, potrebno je
primjereno educirati sve korisnike informacijskog sustava banke.
Posljedica primjerene izobrazbe bit e smanjivanje broja pogreaka i propusta i ograniavanje
njihova dosega te uoavanje i sprjeavanje pokuaja naruavanja temeljnih naela
Edukacija bi trebala obuhvatiti sve osobe koje se koriste informacijskim sustavom banke:
informatiko osoblje banke
osobe zaduene za sigurnost informacijskog sustava i unutarnju reviziju
ostale zaposlenike banke koji se koriste informacijskim sustavom, i na operativnim i
na upravljakim razinama
osobe koje nisu zaposlenici banke, ali se koriste informacijskim sustavom banke
(primjerice korisnici e-bankarstva, zaposlenici tvrtki vanjskih suradnika i slino).
Izobrazba korisnika informacijskog sustava trebala bi omoguiti navedenim osobama
djelotvorno obavljanje poslovnih zadataka uz istodobno svoenje neeljenih dogaaja na
prihvatljivu razinu. Preciznije, ciljevi edukacije korisnika informacijskog sustava banke jesu:
razviti i odravati znanja i vjetine korisnika na primjerenoj razini, kako bi oni mogli
obavljati poslovne zadatke na djelotvoran i siguran nain
upoznati korisnike s internim aktima (primjerice politikama, procedurama i ostalim
postupcima kojih se navedeni korisnici moraju pridravati) kako bi se tono ustanovili
zadaci, okviri djelovanja i osobna odgovornost svakog korisnika
uspostaviti i unapreivati svijest o potrebi zatite resursa informacijskog sustava
razviti i odravati znanja potrebna da bi se funkcionalnost i sigurnost informacijskog
sustava zadrale na zadovoljavajuoj razini tijekom cijeloga ivotnog ciklusa
Izobrazba bi trebala biti sastavni dio strategije informacijskog sustava banke te u skladu s
planiranim promjenama informacijskog sustava . Izobrazbu je potrebno unaprijed planirati te
formalno identificirati i specificirati potrebne aktivnosti, nain njihova provoenja te
vremenske i financijske okvire unutar kojih e se provoditi. Prilikom planiranja izobrazbe
posebnu pozornost valja posvetiti potrebi usvajanja i odravanja visoko specijaliziranih
tehnikih znanja ije stjecanje zahtijeva koritenje znaajnim financijskim i vremenskim
resursima te veliki osobni angaman zaposlenika. Navedena visoko specijalizirana znanja
59
obino se stjeu kontinuiranom izobrazbom i strunim usavravanjem stoga ih je potrebno

adekvatno planirati i provoditi. Pri tome bi banka trebala posebnu pozornost posvetiti
izobrazbi unutarnje revizije, kako bi se revizija informacijskog sustava provodila na
zadovoljavajui i djelotvoran nain.
Ostvarivanje plana izobrazbe i njegovu provedbu potrebno je dokumentirati i pratiti. Pravilno
planirana i provedena izobrazba poveat e produktivnost, iskoritenje postojeih resursa te
omoguiti podizanje razine sigurnosti cjelokupnoga informacijskog sustava banke.
Izobrazbu je mogue provoditi na razliite naine, od najjednostavnijih poput distribucije
pisane dokumentacije do kompleksnih i dugotrajnih usavravanja. Opseg, detaljnost, trajanje i
nain provoenja edukacije trebaju biti u skladu s obiljejima ciljane grupe odnosno ciljanih
korisnika te s opsenosti i kompleksnosti tematike. Prilikom odreivanja obiljeja ciljanih
korisnika potrebno je uzeti u obzir poslovne funkcije koje navedeni korisnici obavljaju,
njihovo predznanje o predmetu edukacije te openito poznavanje funkcioniranja
informacijskih sustava. Korisnike je potrebno educirati do razine detaljnosti koju zahtijevaju
njihovi poslovni zadaci.
60
7. Planiranje kontinuiteta poslovanja

Planiranje kontinuiteta poslovanja treba u najveoj moguoj mjeri osigurati kontinuitet
poslovanja te omoguiti banci da pomou adekvatnih mjera za oporavak u to kraem
vremenu smanji ukupni uinak havarije ili drugih neeljenih i nepredvienih dogaaja (ije
posljedice mogu prouzroiti prekid poslovnih procesa te u konanici i poslovanja banke) na
prihvatljivu razinu. Osiguravanje kontinuiteta poslovanja postie se poduzimanjem mjera
prevencije neeljenih dogaaja, ograniavanja njihova uinka i oporavka u sluaju prekida
poslovnih procesa. Planiranje kontinuiteta poslovanja treba se temeljiti na analizi utjecaja na
poslovanje i na procjeni rizika te omoguiti dosljedno odvijanje poslovnih procesa banke i
nastavak pruanja usluga uz znaajno smanjenje rizika kojima je banka u svom poslovanju
izloena (primjerice reputacijskog, financijskog, operativnog, stratekog i pravnog rizika).
Zbog velike ovisnosti banke o informacijskoj tehnologiji te informacijskom sustavu koji
omoguuje odvijanje poslovnih procesa, banka bi trebala pri planiranju kontinuiteta
poslovanja posebnu pozornost posvetiti osiguranju raspoloivosti resursa informacijskog
sustava potrebnih za odvijanje kritinih i/ili vitalnih poslovnih procesa.
Djelotvornost planiranja kontinuiteta poslovanja ocjenjuje se pomou testiranja i primjene
plana kontinuiteta poslovanja, plana oporavka, plana odgovora na incidente kao i uspostavom
adekvatnog procesa upravljanja priuvnom pohranom.
Banka bi prilikom planiranja kontinuiteta poslovanja trebala obratiti posebnu pozornost:
na identificiranje kritinih i/ili vitalnih poslovnih procesa
na procjenu prihvatljivog vremena neraspoloivosti pojedinih poslovnih procesa
na identificiranje resursa koji su potrebni za odravanje kritinih i/ili vitalnih
poslovnih procesa
na procjenjivanje pojave i uinka potencijalnih incidenata, havarija te ostalih
neeljenih i nepredvienih dogaaja na poslovne procese banke i njezine klijente
na dodjelu odgovornosti u svezi s izradom, aktiviranjem i provedbom planova
na revidiranje planova s obzirom na promjene (primjerice osoblja, vanjskog i
unutarnjeg okruenja i slino)
na donoenje ostalih internih akata u svezi s planiranjem kontinuiteta poslovanja
na testiranje plana kontinuiteta poslovanja, plana oporavka i plana odgovora na
incidente te priuvne pohrane i priuvnoga raunalnog centra
na procjenu rizika ugovornih odnosa s kljunim pruateljima usluga i dobavljaima;
na raspoloivost priuvnoga raunalnog centra na udaljenoj lokaciji
na uspostavu standarda i procedura za komunikaciju sa svim osobama potrebnim za
osiguranje kontinuiteta poslovanja
komunikaciji osoba zaduenih za osiguravanje kontinuiteta poslovanja (primjerice
tima za odgovore na incidente) i osoba zaduenih za odnose s javnou.
Dobre prakse nalau uspostavu odbora za planiranje kontinuiteta poslovanja koji bi, izmeu
ostalog, trebao imati savjetodavnu ulogu prilikom donoenja stratekih odluka te nadzirati i
koordinirati aktivnosti u svezi s planiranjem kontinuiteta poslovanja. lanovi odbora za
planiranje kontinuiteta poslovanja trebali bi biti predstavnici poslovnih organizacijskih
jedinica, voditelj sigurnosti informacijskog sustava, unutarnja revizija, predstavnici
organizacijske jedinice za informacijsku tehnologiju te lan uprave banke.
61
Neadekvatno planiranje kontinuiteta poslovanja moe prouzroiti:

gubitak raspoloivosti
gubitak reputacije
gubitak konkurentskih prednosti
gubitak podataka
gubitak produktivnosti
poveanje operativnih trokova
povredu ugovornih odnosa
povredu vaeih propisa
financijski gubitak.
62
7.1. Analiza utjecaja na poslovanje

Analiza utjecaja na poslovanje (engl. Business Impact Analysis) jest proces analiziranja
poslovnih procesa i resursa informacijskog sustava potrebnih za odvijanje poslovnih procesa
koji obuhvaa barem sljedee:
1. identifikaciju poslovnih procesa i klasifikaciju s obzirom na njihovu kritinost i/ili
vitalnost
2. identifikaciju resursa informacijskog sustava potrebnih za odvijanje poslovnih
procesa, njihovih meuovisnosti te povezanosti s drugim informacijskim sustavima
3. procjenu rizika vezanih uz pojedine poslovne procese
4. odreivanje prihvatljive razine pojedinih rizika
5. odreivanje prihvatljivog vremena neraspoloivosti pojedinih poslovnih procesa, tj.
vremena u kojem je potrebno obnoviti poslovni proces (engl. Recovery Time Objective
RTO)
6. odreivanje vremena (u odnosu na vrijeme poetka havarije ili drugog neeljenog i
nepredvienog dogaaja) od kojeg e banka biti u stanju obnoviti podatke (engl.
Recovery Point Objective RPO)
7. utvrivanje prioriteta oporavka poslovnih procesa.
Analiza utjecaja na poslovanje temelj je za planiranje kontinuiteta poslovanja i djelotvornog
oporavka poslovnih procesa odnosno resursa informacijskog sustava potrebnih za odvijanje
poslovnih procesa. Vrijeme i ostali resursi potrebni za provoenje analize utjecaja na
poslovanje ovisit e prije svega o veliini banke i kompleksnosti poslovnih procesa i
Analiza utjecaja na poslovanje treba obuhvatiti sve poslovne procese te:
identificirati potencijalni uinak neeljenog, nepredvienog (i neuobiajenog)
dogaaja na poslovne procese odnosno resurse informacijskog sustava potrebne za
odvijanje tih procesa
razmotriti utjecaj zahtjeva vaeih propisa te potreba za izvjeivanjem Hrvatske
narodne banke i ostalih nadlenih institucija na poslovne procese
procijeniti najdue vrijeme neraspoloivosti pojedinih vitalnih poslovnih procesa,
ciljeve i prioritete oporavka te trokove vezane uz zastoje i oporavak
procijeniti i postaviti prioritete na kritine i/ili vitalne poslovne procese
razmotriti utjecaj prekida poslovnih procesa na klijente (primjerice obveze banke
prema klijentima, oekivanja klijenata) i reputaciju banke.
Uinak neeljenog i nepredvienog dogaaja moe se promatrati kao gubitak ili naruavanje
temeljnih naela informacijskog sustava. Uinak neeljenih i nepredvienih dogaaja moe se
mjeriti:
kvantitativno (primjerice na osnovi izgubljenih prihoda ili na osnovi trokova ponovne
uspostave poslovnih procesa)
kvalitativno (primjerice dogaaji s velikim, srednjim ili malim utjecajem na poslovne
procese odnosno na resurse informacijskog sustava).
Informacije potrebne u analizi utjecaja na poslovanje mogu se prikupiti na razliite naine
(primjerice uvidom u dokumentaciju i intervjuiranjem). Proces prikupljanja informacija
trebao bi biti ujednaen (primjerice potrebno je provoditi intervjuiranje pomou upitnika koji
e se moi primjenjivati na sve poslovne procese i organizacijske jedinice banke). Na taj e se
63
nain omoguiti postojanost i usporedivost dobivenih informacija ijom analizom bi se

trebala odrediti kritinost i/ili vitalnost poslovnih procesa banke. Prilikom provoenja analize
utjecaja na poslovanje posebnu pozornost potrebno je posvetiti:
identificiranju svih resursa informacijskog sustava koji su potrebni za odvijanje
kritinih i/ili vitalnih poslovnih procesa
identificiranju osoba odgovornih za odvijanje kritinih i/ili vitalnih poslovnih procesa
utjecaju analiziranih poslovnih procesa na cjelokupno poslovanje banke
odreivanju prihvatljivog vremena neraspoloivosti poslovnih procesa i resursa
informacijskog sustava potrebnih za odvijanje poslovnih procesa, odnosno vremena
unutar kojeg je potrebno obnoviti poslovne procese (engl. Recovery Time Objective RTO)
odreivanju vremena od kojeg e banka biti u stanju obnoviti podatke (engl. Recovery
Point Objective - RPO)
meuovisnosti prethodno navedenog
resursima potrebnim za oporavak.
Analizu utjecaja na poslovanje potrebno je usklaivati s promjenama poslovnih procesa
banke, njezina okruenja, informacijskog sustava i drugih okolnosti koje mogu utjecati na
poslovanje banke. Budui da je analiza utjecaja na poslovanje temelj za planiranje
kontinuiteta poslovanja, nedostatak ili neadekvatno provoenje analize moe rezultirati
neadekvatnim planiranjem kontinuiteta poslovanja. Navedeno se oituje u nemogunosti
banke da prepozna kritine i/ili vitalne poslovne procese, odredi prihvatljivo vrijeme
neraspoloivosti poslovnih procesa kao i mogue trokove. Sve navedeno moe dovesti do
nemogunosti uspostave kritinih i/ili vitalnih poslovnih procesa, gubitka operativne
uinkovitosti, neraspoloivosti informacijskog sustava, znatnoga financijskoga gubitka te
gubitka reputacije banke.
64
7.2. Plan kontinuiteta poslovanja

U okviru planiranja kontinuiteta poslovanja banka bi trebala donijeti plan kontinuiteta
poslovanja. Planom kontinuiteta poslovanja trebalo bi detaljno opisati postupke koje je
potrebno slijediti kako bi se oporavili kritini i/ili vitalni poslovni procesi. Prilikom izrade
plana kontinuiteta poslovanja banka bi trebala uzeti u obzir sve vrste dogaaja koji mogu
negativno utjecati na poslovne procese i resurse informacijskog sustava potrebne za odvijanje
poslovnih procesa.
Svrha plana kontinuiteta poslovanja jest:
osigurati ponovnu uspostavu kritinih i/ili vitalnih poslovnih procesa u zahtijevanom
vremenu
ograniiti i smanjiti gubitke koji mogu nastati kao posljedica prekida poslovnih
procesa.
Plan kontinuiteta poslovanja trebao bi:
biti u pisanom obliku
temeljiti se na analizi utjecaja na poslovanje i procjeni rizika
precizno definirati uvjete pod kojima se aktivira te odgovornosti za njegovu aktivaciju
i provedbu
biti specifian s obzirom na uvjete u kojima se plan treba izvriti
biti specifian s obzirom na hitne postupke u sluaju prekida poslovnih procesa
uzeti u obzir resurse potrebne za obnavljanje poslovnih procesa
biti dovoljno prilagodljiv kako bi se mogao primijeniti u nepredvienim situacijama
biti usredotoen na odravanje kontinuiteta poslovnih procesa, a ne na istraivanje
uzroka incidenta
biti djelotvoran u smanjivanju tetnog uinka na poslovne procese i financijskog
gubitka.
Plan kontinuiteta poslovanja potrebno je usklaivati s promjenama poslovnih procesa banke,
njezina okruenja, informacijskog sustava i drugih okolnosti koje mogu utjecati na poslovanje
banke. Nadalje, plan kontinuiteta poslovanja potrebno je periodino testirati kako bi bio
efikasan i usklaen s navedenim promjenama.
65
7.3. Plan oporavka

Zastoji i razliiti poremeaji u radu informacijskog sustava mogu znaajno ugroziti
poslovanje banke zbog nemogunosti odvijanja kritinih i/ili vitalnih poslovnih procesa.
Prilikom planiranja oporavka informacijskog sustava banka bi trebala uzeti u obzir mogue
negativne uinke na resurse informacijskog sustava u sluaju razliitih havarija te ostalih
neeljenih i nepredvienih dogaaja. Navedeni negativni uinci mogu nastati kao posljedica
ostvarenja prijetnja koje mogu biti prirodne ili uzrokovane ljudskim djelovanjem (sluajno ili
namjerno).
U sklopu planiranja oporavka u sluaju havarije te ostalih neeljenih i nepredvienih dogaaja
banka bi trebala donijeti plan oporavka kojem je cilj osigurati raspoloivost resursa
informacijskog sustava potrebnih za odvijanje kritinih i/ili vitalnih poslovnih procesa u
zahtijevanom vremenu. Plan oporavka je skup procedura koje obuhvaaju postupke hitnog
odgovora na neeljeni dogaaj i oporavka resursa informacijskog sustava.
Banka bi trebala biti svjesna da su vrijeme i ostali resursi potrebni za provoenje analize
utjecaja na poslovanje, procjenu rizika, izradu plana oporavka te izradu priuvnih kopija
neusporedivo manji od resursa koji bi bili potrebni kad navedeno ne bi bilo napravljeno, a kad
bi dolo do havarije ili nekog drugog neeljenog i nepredvienog dogaaja. Gubitak
funkcionalnosti glavnog i/ili priuvnog raunalnog centra moe usporiti ili u potpunosti
onemoguiti odvijanje poslovnih procesa banke te uzrokovati znaajan financijski gubitak,
ugroziti konkurentski poloaj, utjecati na reputaciju banke i prouzroiti znatne povrede
vaeih propisa.
Plan oporavka, izmeu ostalog, trebao bi:
imati jasno definirane postupke oporavka ovisno o vrsti dogaaja i njegovu uinku na
resurse informacijskog sustava, ukljuujui postupke prelaska na priuvnu lokaciju
imati definirane prioritete u oporavku resursa informacijskog sustava potrebnih za
odvijanje kritinih i/ili vitalnih poslovnih procesa
definirati postupke evakuacije
definirati odgovornosti i ovlasti osoba zaduenih za oporavak
imati jasno definirane postupke vezane uz ugovorni odnos s pruateljima usluga, a
koji se odnose na oporavak.
Nadalje, plan oporavka trebao bi osigurati sljedee:
ubrzati potrebno vrijeme reakcije
skratiti vrijeme oporavka (primjerice definiranjem rutinskih procedura)
pomoi u donoenju odluka u kriznim situacijama
jamiti pouzdanost priuvnih sustava.
Najvei prioritet pri oporavku u sluaju havarije te ostalih neeljenih i nepredvienih
dogaaja ima sigurnost ljudi.
Banka bi trebala osigurati da plan oporavka bude cjelovit, provediv, auran, testiran,
dokumentiran te trokovno opravdan. Budui da je planiranje oporavka u sluaju havarije te
ostalih neeljenih i nepredvienih dogaaja iznimno sloen i zahtjevan proces, dobre prakse
nalau osnivanje odbora za planiranje oporavka.
66
7.4. Upravljanje incidentima

Incident je neplanirani i neeljeni dogaaj ija je posljedica povreda (ili koji neposredno
prijeti povredom) vaeih propisa RH, politike sigurnosti informacijskog sustava, ostalih
internih akata banke vezanih uz informacijsku sigurnost kao i naruavanje temeljnih naela
informacijskog sustava, prihvaenih praksi vezanih uz informacijsku sigurnost te
funkcionalnosti informacijskog sustava. Upravljanje incidentima je sastavni dio planiranja
kontinuiteta poslovanja jer mu je cilj omoguavanje brzog i uinkovitog odgovora u sluaju
naruavanja sigurnosti i funkcionalnosti resursa informacijskog sustava koji podravaju
odvijanje poslovnih procesa.
Kako bi banka mogla djelotvorno i pravodobno reagirati u sluajevima naruavanja
funkcionalnosti i sigurnosti dijela ili cijeloga informacijskog sustava, potrebno je planirati
postupke u sluaju incidenata, to ukljuuje i izradu plana odgovora na incidente. Cilj
planiranja odgovora na incidente jest smanjivanje rizika od naruavanja sigurnosti i
funkcionalnosti informacijskog sustava u incidentnim situacijama te pruanje praktinih
smjernica za djelotvorno postupanje kad se dogode incidenti. Adekvatnim planiranjem
odgovora na incidente poveava se sposobnost banke da uspjeno i brzo odgovori na
incidente, da ogranii i ispravi nastale tetne uinke te da smanji tetne posljedice buduih
incidenata. Pretpostavka je za uspjeno planiranje odgovora na incidente dobro poznavanje
okruenja informacijskog sustava i samog sustava, to se odnosi na poznavanje i praenje
potencijalnih prijetnja, s jedne strane, i poznavanja ranjivosti informacijskog sustava s druge
strane.
S obzirom na postupke koji se provode prilikom planiranja odgovora na incidente kao i na
postupke u kriznim situacijama, upravljanje incidentima moe se podijeliti u osnovne faze:
1. Priprema. Faza pripreme ukljuuje:
preventivne metode sprjeavanja incidenata
podrku rukovodstva
odreivanje osoba zaduenih za odgovor na incidente te definiranje njihovih ovlasti,
odgovornosti i djelokruga rada
planiranje komunikacije u hitnim sluajevima
organizaciju sustava izvjeivanja
izobrazbu zaposlenika u vezi s prepoznavanjem incidenata
izobrazbu osoba zaduenih za odgovor na incidente
donoenje smjernica za suradnju meu razliitim organizacijskim jedinicama
definiranje odgovornosti korisnika informacijskog sustava u svezi s incidentima
uspostavljanje odnosa s nadlenim institucijama kao i drugim timovima za odgovor na
incidente.
2. Identifikacija. Faza identifikacije ukljuuje identifikaciju incidenta.
3. Ograniavanje. Faza ograniavanja ukljuuje provoenje potrebnih radnja od strane
osoba zaduenih za odgovor na incidente (primjerice ispitivanje situacije, izbjegavanje
neovlateno promijenjenog koda, izradu priuvne pohrane, procjenu rizika od nastavka
rada kompromitiranog dijela informacijskog sustava, suradnju s osobama odgovornim za
kompromitirani dio informacijskog sustava, promjenu zaporka i slino).
67
4. Uklanjanje. Faza uklanjanja ukljuuje:

odreivanje uzroka i znaajka incidenta
poboljanje sigurnosnih postavka informacijskog sustava
provoenje analize ranjivosti
uklanjanje uzroka incidenta
lociranje aurnih priuvnih kopija koje su napravljene prije nego to je naruena
funkcionalnost i sigurnost informacijskog sustava.
5. Oporavak. Faza oporavka ukljuuje ponovnu uspostavu kompromitiranih dijelova
informacijskog sustava te procjenu stanja i nadzor poslovnih procesa.
6. Izvjeivanje. Faza izvjeivanja ukljuuje:
izvjetavanje o svim fazama upravljanja incidentom te izradu izvjea o incidentu
izradu preporuka radi breg prepoznavanja ili spreavanja ponavljanja incidenta.
Upravljanje incidentima obuhvaa i odreivanje radnja za obranu od specifinih napada kao
to su maliciozni kod, neovlateno analiziranje mree, napad uskraivanjem usluge (engl.
Denial of Service), neprimjereno koritenje sustavom, pijunaa, prijevare, neautorizirani
pristup i slino. Nadalje, dobre prakse upuuju na potrebu praenja statistika raznih prijetnja
(ukljuujui razliite tipove napada) i ranjivosti sustava. Nemogunost pravodobnog
odgovora na incidente izlae banku znaajnom operativnom, pravnom, reputacijskom i
financijskom riziku.
Banka bi trebala donijeti plan odgovora na incidente. Plan odgovora na incidente nastaje
dokumentiranjem procesa planiranja odgovora na incidente, a temelji se na procjeni rizika
informacijskog sustava. Plan odgovora na incidente trebao bi podrati sve faze upravljanja
incidentima pri emu bi posebno valjalo istaknuti:
definiranje incidenata te njihovo rangiranje
definiranje procedura za postupanje u sluaju incidenata
odreivanje postupaka izvjeivanja uprave banke, ostalih odgovornih osoba kao i
nadlenih institucija ovisno o uincima sigurnosnog incidenta (primjerice
izvjeivanje Hrvatske narodne banke, Ministarstva unutarnjih poslova i slino)
odreivanje osoba zaduenih za odgovore na incidente te definiranje njihova
djelokruga rada, ovlasti i odgovornosti
izobrazbu osoba zaduenih za odgovore na incidente.
Budui da velik broj incidenata ima karakteristike sigurnosnih incidenata pa njihovo
rjeavanje zahtijeva brzi odgovor te primjenu specijalistikih znanja i multidisciplinarni
pristup, dobre prakse nalau osnivanje operativnog ekspertnog tima koji e odgovarati na
incidente. Osobe zaduene za odgovor na incidente odnosno tim za odgovor na incidente
(engl. incident response team) treba biti u svako vrijeme dostupan svim stranama koje
sumnjaju u pojavu ili su primijetile incident. Postupci lanova tima za odgovor na incidente
obuhvaaju:
prikupljanje i analizu informacija o incidentu
odreivanje uinka incidenta
poduzimanje radnja potrebnih za ograniavanje i smanjivanje nastale tete
poduzimanje radnja za oporavak kompromitiranih poslovnih procesa.
68
Dobre prakse nalau usku suradnju tima za odgovor na incidente i pravnika kako bi se rijeila
pravna pitanja koja se mogu pojaviti kao posljedica incidenta (primjerice odgovornost banke
kada je s njezina sustava koji je kompromitiran izvren napad na sustav neke druge institucije,
utvrivanje odgovornosti za nastalu tetu te odgovornost banke za izvjeivanje nadlenih
institucija u sluaju incidenata).
69
7.5. Upravljanje priuvnom pohranom

Proces upravljanja priuvnom pohranom obuhvaa postupke izrade, pohrane, testiranja i
restauracije podataka s priuvnih kopija. Priuvne kopije moraju sadravati sve podatke
(poslovne podatke, dokumentaciju, aplikativni i sistemski softver i slino) koji su potrebni za
ponovno uspostavljanje poslovnih procesa koje podrava informacijski sustav banke. Izrada
priuvnih kopija podataka koji se nalaze u informacijskom sustavu zadatak je s visokim
prioritetom u procesu upravljanja informacijskim sustavom.
Upravljanje priuvnom pohranom potrebno je uspostaviti u skladu s klasifikacijom
informacija, analizom utjecaja na poslovanje i procjenom rizika, kako bi se osigurala temeljna
naela informacijskog sustava.
Banka bi trebala osigurati postojanje aurnih priuvnih kopija kao i provjerenih i testiranih
metoda restauriranja podataka, odnosno ponovnog uspostavljanja poslovnih procesa kako bi
bio mogu uspjean oporavak u sluaju incidenata, havarija te ostalih neeljenih i
nepredvienih dogaaja.
Banka bi trebala donijeti interne akte kojima se definiraju kriteriji, naini i postupci
upravljanja priuvnom pohranom kao to su kategorizacija, uestalost izrade, vrsta,
rukovanje, pohrana, restauracija i uvanje priuvnih kopija. Isto tako, potrebno je definirati i
ovlasti i odgovornosti za upravljanje priuvnom pohranom.
Priuvne kopije omoguuju oporavak informacijskog sustava u sluajevima gubitka podataka
povezanih s dogaajima kao to su:
sigurnosni incidenti
brisanje podataka zbog sluajnih ili namjernih dogaaja
neoekivani prekidi u radu informacijskog sustava
havarije
ostali neeljeni i nepredvieni dogaaji.
Uobiajene dobre prakse pri uspostavljanju sustava upravljanja priuvnom pohranom
ukljuuju, izmeu ostalog, sljedee:
odreivanje uestalosti izrade priuvnih kopija s obzirom na rizik i klasifikaciju
informacija te u skladu s time sastavljanje plana izrade priuvnih kopija
izradu, odravanje i pregled evidencije o priuvnim kopijama
obiljeavanje medija na kojima su pohranjeni podaci, to ukljuuje informacije kao to
su sadraj, datum izrade, vrsta kopije, sistemsko okruenje, razina osjetljivosti te
ostale informacije
izradu priuvnih kopija sistemskih datoteka (primjerice operativnih sustava,
pogonskih programa za hardver i slino)
adekvatno upravljanje fizikom sigurnou priuvnih kopija
verificiranje podataka na priuvnim kopijama kako bi se omoguila uspjena
restauracija podataka
periodino restauriranje podataka na testnu okolinu i/ili provjeru pomou
odgovarajuega softverskog alata kako bi se potvrdilo da su priuvne kopije
pohranjene na ispravan nain, da nije naruen integritet podataka te da je podatke
mogue restaurirati
70
periodino revidiranje procesa izrade i pohrane priuvnih kopija

redovito pohranjivanje priuvnih kopija na udaljenu sigurnu lokaciju
uporabu kriptografskih metoda
redovito zamjenjivanje i odlaganje medija na kojima se pohranjuju podaci
osiguranje raspoloivosti priuvnoga raunalnog centra na udaljenoj lokaciji. Priuvni
raunalni centar, ovisno o procjeni rizika, moe imati razliitu razinu opremljenosti:
od redundantnog, koji je opremljen jednako kao i glavni raunalni centar, do centra
koji ima samo adekvatni prostor i instalacije (energetsku i telekomunikacijsku mreu
te ostale potrebne instalacije). Posebnu pozornost potrebno je posvetiti
telekomunikacijskoj povezanosti priuvnog centra i ugovornim odnosima banke s
pruateljima usluga i dobavljaima opreme.
71
8. Razvoj sustava i eksternalizacija

8.1. Razvoj informacijskih sustava unutar banke
Razvoj informacijskih sustava unutar banke (engl. in-house development) sloen je proces,
koji je potrebno precizno i detaljno definirati te standardizirati kako bi se rizici razvoja sveli
na najmanju moguu mjeru. Banka bi trebala donijeti interne akte koji propisuju postupak
razvoja informacijskih sustava i koji e se primjenjivati na sve razvojne projekte (u nastavku
teksta: projekte), neovisno o karakteristikama samih projekata. Navedeni akti trebali bi
obuhvatiti barem sljedea podruja:
planiranje i formalnu organizaciju projekta razvoja informacijskih sustava
programski razvoj i isporuku informacijskih sustava
odravanje informacijskih sustava.
Interni akti o razvoju informacijskih sustava trebali bi za svako od navedenih podruja
propisati postupke odobravanja, pregleda, provoenja i dokumentiranja vanijih aktivnosti.
Pri razvoju informacijskih sustava potrebno je uvijek imati u vidu sigurnost cjelokupnog
sustava. Prilikom provedbe opsenijih projekata razvoja informacijskih sustava obino se
propisuju i posebni standardi koji se primjenjuju na taj projekt. Navedeni posebni standardi
trebali bi biti u skladu s internim aktima banke. Projekti koji se mogu promatrati kao izmjene
ve postojeih sustava moraju biti u skladu s postupcima definiranim u poglavlju "Upravljanje
promjenama".
8.1.1. Planiranje i formalna organizacija projekta razvoja informacijskih sustava

Planiranje projekta je kritino razdoblje ivotnog ciklusa informacijskog sustava. Propusti u
procesu planiranja esto se manifestiraju kao pomicanje rokova, poveanje trokova,
neadekvatno ispunjavanje ciljeva ili ak odustajanje od projekta. Stoga je potrebno definirati
sve parametre koji se moraju analizirati i dokumentirati u ovom procesu.
Prije zapoinjanja projekta odgovorne osobe u banci trebale bi izraditi formalni plan koji e
definirati standarde i postupke koji e se primjenjivati u svim fazama razvoja informacijskog
sustava. Detaljnost i formalnost projektnog plana trebaju biti razmjerne opsegu projekta i
procjeni rizika. Dobre prakse nalau da projektni plan obuhvaa barem sljedee:
jasan prikaz sadanjeg stanja (ukljuujui meuovisnosti s postojeim sustavom) te
potreba korisnika i preciznu definiciju ciljeva projekta
analizu isplativosti projekta koja e identificirati oekivane koristi i trokove razvoja
sustava te procijeniti mogua alternativna rjeenja
definiranje uloga i odgovornosti osoba koje e biti ukljuene u razvoj i isporuku
sustava
jasno razdvajanje dunosti izmeu osoba koje e biti zaduene za implementaciju
informacijskog sustava i osoba koje e biti zaduene za kontrolu te implementacije;
propisivanje postupaka komunikacije i izvjeivanja svih osoba koje e biti
ukljuene u razvoj i isporuku sustava
identifikaciju potrebne dokumentacije koja treba nastati u sklopu projekta razvoja
72
definiranje standarda za pisanje dokumentacije, koji e precizno opisati svrhu i

formu svakog potrebnog dokumenta te uvjete pod kojima navedeni dokument
nastaje
planove testiranja
planove izobrazbe osoba ukljuenih u projekt kako bi se on dovrio unutar
planiranih vremenskih i financijskih okvira te da bi se uspjeno odravao
novonastali sustav
definiranje kontrolnih mehanizama koji e pratiti tijek projekta i aktivnosti koje se
moraju poduzeti u sluaju odstupanja od projektnog plana.
8.1.2. Programski razvoj i isporuka sustava

Programski razvoj informacijskih sustava moe se podijeliti (neovisno o odabranoj razvojnoj
metodologiji i tehnologiji), izmeu ostalog, na sljedee procese:
analizu i projektiranje
programiranje
testiranje
uvoenje u produkcijski rad.
U svakom od navedenih procesa moraju se primjenjivati odgovarajue procedure definirane
pri planiranju i organizaciji projekta. Standardi programskog razvoja informacijskih sustava
trebali bi biti dovoljno fleksibilni, kako se njima ne bi ograniavala kreativna i kvalitetna
rjeenja.
Dobre prakse nalau da razvojna, testna i produkcijska okolina budu meusobno odvojene na
odgovarajui nain.
8.1.2.1. Analiza i projektiranje
U postupku analize i projektiranja informacijskog sustava odgovorne osobe trebale bi
podijeliti projekt u projektne zadatke koje e zaposlenici i druge osobe moi samostalno
rjeavati (primjerice programeri). Pri analizi i projektiranju posebnu pozornost potrebno je
posvetiti kontrolama sigurnosti. Isto tako, prilikom podjele projekta u projektne zadatke
potrebno je izgraditi odgovarajuu dokumentaciju svakoga projektnog zadatka, koja bi morala
sadravati barem sljedee:
opis poslovnog procesa ili dijela poslovnog procesa koji e se implementirati
projektnim zadatkom
opis potrebnih funkcionalnosti procesa opisanog u projektnom zadatku ukljuujui
(gdje je to mogue) i grafike prikaze
meuovisnosti s postojeim poslovnim procesima i sustavom
opis svih kontrola koje moraju biti ugraene u sustav
opis ulaznih i izlaznih vrijednosti projektnog zadatka
specifikaciju procesa koje treba zabiljeiti u operativnim i sistemskim zapisima
popis osoba koje su zaduene za provedbu projektnog zadatka
vremenski plan obavljanja projektnog zadatka
73
osnovni plan testiranja koji e pokazati da realizirani projektni zadatak daje oekivane
rezultate.
8.1.2.2. Programiranje
Dobre prakse nalau propisivanje standarda programiranja koji bi trebali obuhvatiti barem
sljedee:
principe i pravila pisanja programskog koda, nazivanja programskih dijelova,
varijabla, elemenata baza podataka i slino
obavezne kontrole koje treba ugraditi neovisno o specifinostima odreenoga
projektnog zadatka
principe i pravila upotrebe i dokumentiranja standardiziranih programskih rutina kako
bi se izbjeglo dupliciranje programskoga koda.
Aktivnosti programera trebale bi biti jasno definirane. Pristup programima izvan
programerovih osobnih odgovornosti potrebno je ograniiti. Izvorni programski kod morao bi
biti adekvatno zatien s obzirom na potrebu za odravanjem temeljnih naela informacijskog
sustava.
8.1.2.3. Testiranje
Prije putanja informacijskog sustava u produkcijski rad potrebno je provesti testiranje.
Testiranje razvijenog sustava trebalo bi biti detaljno i na adekvatan nain kontrolirano, kako
bi se utvrdilo odgovara li razvijeni sustav postavljenim ciljevima. Potrebno je propisati
procedure testiranja te prije samog poetka testiranja izraditi detaljni testni plan. Testni plan
trebao bi obuhvaati kombinacije kojima e se analizirati ponaanje sustava:
u standardnim uvjetima
u graninim sluajevima
u svim realno zamislivim neregularnim situacijama.
Testove je potrebno provoditi u kontroliranim uvjetima i upotrijebiti prethodno definirane
podatke. Testni podaci trebali bi biti to sliniji pravim, produkcijskim podacima. Pri
testiranju potrebno je voditi rauna o povjerljivosti informacija. Dobre prakse nalau
verifikaciju rezultata testiranja tako da se usporede s unaprijed definiranim oekivanim
rezultatima. Rezultati testova trebali bi se dokumentirati u standardiziranoj, propisanoj formi.
Konane rezultate trebale bi prekontrolirati sve ukljuene strane te pisano potvrditi njihovu
prihvatljivost.
8.1.2.4. Uvoenje informacijskog sustava u produkcijski rad
Banka bi trebala propisati postupke uvoenja novih ili izmijenjenih sustava u produkcijski
rad. Navedene procedure trebale bi definirati ovlasti, odgovornosti i nain prijenosa s testnog
na produkcijsko okruenje. Prije uvoenja sustava u produkcijski rad potrebno je:
organizirati izobrazbu svih zaposlenika koji e se tim sustavom sluiti
svim korisnicima omoguiti pristup potpunoj korisnikoj dokumentaciji s
jednostavnim, netehnikim opisom svih funkcionalnosti kojima e se sluiti u radu.
74
8.1.3. Odravanje informacijskih sustava

Banka bi trebala definirati postupke odravanja informacijskih sustava i promjena tih sustava.
Sve programske promjene trebale bi se strogo kontrolirati i dokumentirati kako bi se sprijeile
bilo kakve neovlatene promjene te osiguralo odravanje temeljnih naela informacijskog
sustava. Provoenje promjena trebalo bi biti u skladu s propisanim internim aktima banke
vezanim uz upravljanje promjenama. Programske promjene veeg opsega treba tretirati kao
zasebne projekte i na njih valja primijeniti ve navedene procese planiranja i formalne
organizacije te programskog razvoja i isporuke informacijskih sustava. Banka bi trebala
propisati standardne postupke za dokumentiranje programskih promjena informacijskih
sustava koji trebaju obuhvatiti barem sljedee:
identifikaciju programa ili sustava
identifikaciju osobe koja je inicirala promjenu sustava
datum kada je zatraena promjena sustava
opis traene promjene
odobrenje zatraene promjene.
Prilikom izrade traenih promjena valja slijediti sve navedene smjernice za programski razvoj
i isporuku informacijskih sustava. U sklopu analize, projektiranja, programiranja i testiranja
sustava treba analizirati i dokumentirati sigurnosne rizike i negativne utjecaje koji mogu
nastati na sustavu kao posljedica programske promjene.
U odreenim uvjetima moe se pojaviti potreba za hitnom promjenom programa,
zaobilaenjem standardnih postupaka provoenja promjena, odnosno izradom izvanrednih ili
privremenih programskih promjena. Banka bi trebala propisati takve postupke koji e
obuhvatiti barem sljedee:
opis situacija u kojima se smiju provoditi izvanredne ili privremene programske
promjene
popis osoba ovlatenih za odobravanje izvanrednih ili privremenih programskih
promjena
kontrolne postupke za sprjeavanje zloporabe.
Nakon to je sustav izmijenjen po hitnoj proceduri, izvanredne ili privremene programske
promjene potrebno je dokumentirati kao i ostale promjene.
75
8.2. Eksternalizacija (dijela) informacijskog sustava

Nastojanje da se smanje trokovi poslovanja te potreba za visokom razinom usluga i vrlo
visokom strunom osposobljenou zaposlenika esto nameu potrebu da banke
eksternaliziraju poslovne procese (ili dio poslovnih procesa) te da se koriste uslugama
pruatelja usluga kako bi ostvarile svoje strateke ciljeve.
Koritenje usluga koje ine sastavni dio poslovnih procesa banke, a koje na temelju ugovora
banci pruaju pruatelji usluga na kontinuiranoj osnovi i kojima se podrava pruanje
bankovnih, financijskih i/ili pomonih bankovnih usluga od strane same banke, naziva se
eksternalizacija (engl. outsourcing). Postupak nabave robe te ugovor(i) o nabavi robe
(primjerice nabavi informacijske, hardverske i softverske imovine) ne smatraju se
eksternalizacijom.
Razliiti modeli eksternalizacije prisutni su ne samo u bankarskom sektoru nego u svim
ostalim poslovnim sektorima. S obzirom na velik utjecaj eksternalizacije u svakodnevnom
poslovanju banaka i rizik vezan uz eksternalizaciju, banke bi trebale na adekvatan nain
upravljati odnosom s pruateljem usluga i nadzirati pruanje usluga u skladu s odredbama
ugovora. Nadalje, banke bi trebale poduzeti potrebne korake kako bi se rizik eksternalizacije
smanjio na prihvatljivu razinu s obzirom na to da se obujam aktivnosti i poslovnih procesa
banaka koji su predmet eksternalizacije, ukljuujui i aktivnosti vezane uz informacijski
sustav sve vie poveava.
Predmetom eksternalizacije mogu biti razliite aktivnosti vezane uz informacijski sustav,
primjerice:
usluge odravanja hardvera
usluge obrade podataka
usluge razvoja poslovnih aplikacija
usluge odravanja poslovnih aplikacija
usluge upravljanja operativnim sustavima i usluge odravanja tih sustava
usluge upravljanja telekomunikacijskim mreama i odravanja tih mrea
usluge upravljanja bazama podataka i odravanja tih baza
usluge upravljanja sigurnosnom infrastrukturom i odravanja te infrastrukture
usluge upravljanja internetskim stranicama i odravanja tih stranica
usluge e-bankarstva
usluge upravljanja pozivnim centrima (engl. call-center) i odravanja tih centara
usluge upravljanja centrima za pomo korisnicima (engl. help-desk) i odravanja tih
centara
usluge upravljanja podacima (skladitenje podataka, pronalaenje podataka - tzv.
rudarenje - engl. data mining) i odravanja tih podataka.
Za potrebe ovog dokumenta eksternalizacija aktivnosti vezanih uz informacijski sustav smatra
se eksternalizacijom (dijela) informacijskog sustava. U nastavku teksta pojam eksternalizacija
odnosi se na eksternalizaciju (dijela) informacijskog sustava.
Odluka o eksternalizaciji strateka je odluka banke, koja treba biti usklaena s poslovnom
strategijom i ciljevima banke te, izmeu ostaloga, ovisi:
76
o sposobnosti banke da upravlja rizikom vezanim uz eksternalizaciju (dijela)

poslovnih procesa
o nainu nadzora i kontrole ugovorenih aktivnosti
o usklaenosti s vaeim propisima.
Pruatelji usluga bankama mogu biti rezidenti i nerezidenti. S tim u svezi treba napomenuti da
izravni nadzor koji provodi Hrvatska narodna banka u odnosu na pruanje usluga od strane
pruatelja usluga rezidenta i/ili nerezidenta ne smije ni na koji nain i ni u kojem trenutku biti
onemoguen, ogranien ili otean bez obzira na to obavlja li se na teritoriju Republike
Hrvatske ili izvan njega.
Radi postizanja prethodno navedenoga, ako je pruatelj usluga nerezident, banke bi svakako
trebale prije donoenja odluke o izboru pojedinog pruatelja usluga utvrditi da li
zakonodavstvo odnosno propisi drave u kojima dotini pruatelj usluga posluje,
omoguavaju Hrvatskoj narodnoj banci da ostvari cjelovit i neogranien pristup djelatnostima
i poslovima u svezi s kojima obavlja nadzor.
Ugovor(i) i nalazi odnosno izvjea unutarnjih i vanjskih revizora vezani uz eksternalizaciju
(dijela) poslovnih procesa trebali bi biti dostupni na hrvatskom jeziku zbog njihove bolje
razumljivosti kako bi se tonije provelo analiziranje, ocjenjivanje i revidiranje aktivnosti koje
su predmet eksternalizacije.
Rizik u poslovanju postoji bez obzira na to hoe li banke same obavljati aktivnosti vezane uz
informacijski sustav ili e se koristiti uslugama pruatelja usluga. Pri razmatranju svrhovitosti
eksternalizacije aktivnosti vezanih uz informacijski sustav banke trebaju:
biti svjesne rizika vezanog uz eksternalizaciju aktivnosti vezanih uz informacijski
sustav
osigurati da odnos izmeu banke i pruatelja usluga bude prihvatljiv sa stajalita rizika
i u skladu s poslovnim ciljevima banke
implementirati adekvatne zatitne mjere i kontrole kojima bi se smanjili identificirani
rizici
osigurati kontinuirano praenje rizika kako bi se identificirale i procijenile promjene u
odnosu na inicijalnu procjenu rizika
regulirati sve elemente i postupke koji se odnose na eksternalizaciju aktivnosti vezanih
uz informacijski sustav svojim internim aktima.
77
Upravljanje rizikom eksternalizacije ukljuuje:

procjenu rizika vezanog uz eksternalizaciju
dubinsko ispitivanje (engl. due diligence) pruatelja usluga pri njegovu odabiru
definiranje sadraja ugovora s pruateljem usluga
osiguravanje kontinuiranog nadzora pruanja usluga u skladu s ugovornim obvezama
osiguravanje neogranienoga i svakodobnog pristupa informacijama povezanim s
uslugom koja je predmet eksternalizacije.
8.2.1. Procjena rizika vezanog uz eksternalizaciju

Prije sklapanja ugovora s pruateljem usluga banka bi trebala procijeniti rizik eksternalizacije
i mogunosti kontrole tog rizika. Pri toj procjeni potrebno je osobitu pozornost posvetiti
procjeni rizika koji bi mogli utjecati na financijske rezultate, financijsku poziciju, kontinuitet
poslovanja ili reputaciju banke. Za svaki pojedinani sluaj eksternalizacije (dijela) poslovnih
procesa banka treba procijeniti rizik eksternalizacije.
Kao dio procjene rizika eksternalizacije banka bi trebala procijeniti primjerice: strateki rizik,
operativni rizik (npr. rizik gubitka podataka i kontrole nad znaajnim poslovnim procesima,
rizik povezan s koritenjem informacijske tehnologije, rizik povezan s raspoloivou usluge,
rizik prekida kontinuiteta poslovanja, transakcijski rizik i sl.), financijski rizik (primjerice
rizik poveanja trokova), reputacijski rizik, pravni rizik (primjerice neusklaenost s
propisima) te rizik zemlje podrijetla pruatelja usluga. Isto tako, banka treba procijeniti na
koji e nain odnos s pruateljem usluga pomoi ostvarivanju stratekih ciljeva i
zadovoljavanju poslovnih potreba banke.
Pri procjeni rizika vezanog uz eksternalizaciju aktivnosti vezanih uz informacijski sustav
banka bi trebala procijeniti sljedee:
mogunost pruatelja usluga da osigura pruanje usluga u skladu sa stratekim
ciljevima i poslovnim potrebama banke,
pouzdanost, ekonomsku odrivost i sposobnost pruatelja usluga,
nain na koji e banka nadzirati pruanje usluga,
adekvatnost strunog osoblja u banci, odnosno je li ono u stanju provoditi kvalitetan
nadzor nad pruateljem usluga i na adekvatan nain upravljati odnosom s pruateljem
usluga,
vanost, opseg i sloenost (dijelova) poslovnih procesa koji su predmet
eksternalizacije,
mogunost "vraanja" u banku (engl. reinsourcing) aktivnosti vezanih uz
informacijski sustav koje e se eksternalizirati, za sluaj da pruatelj usluga ne postupa
u skladu s odredbama ugovora ili ne odrava ugovorenu kvalitetu pruene usluge.
8.2.2. Dubinsko ispitivanje pruatelja usluga pri njegovu odabiru

Nakon to je napravljena procjena rizika eksternalizacije banka bi trebala provesti dubinsko
ispitivanje pruatelja usluga kako bi se utvrdilo moe li pruatelj usluga (financijski i
operativno) pruiti banci zahtijevane usluge. Odabir sposobnoga i kvalitetnog pruatelja
78
usluga osobito je vaan kako bi se smanjio rizik eksternalizacije. Ovisno o utvrenim

rizicima, banka bi trebala pri provedbi dubinskog ispitivanja uzeti u obzir sljedee:
iskustvo pruatelja usluga i mogunosti pruanja potrebnih usluga radi ispunjenja
postojeih i oekivanih potreba banke
reputaciju i trini udio pruatelja usluga
eventualne podizvoae pruatelja usluga koji e pruati podrku pruatelju usluga u
ispunjavanju ugovornih obveza prema banci
eventualnu potrebu za dodatnim sustavima, konverzijama podataka i uslugama
sposobnost pruatelja usluga da na odgovarajui nain postupi u sluaju privremene
nemogunosti pruanja usluga iz bilo kojeg razloga
strunu osposobljenost odgovornih osoba koje e biti odreene za pruanje podrke
banci
lokaciju pruanja usluga kako bi se utvrdili uvjeti pod kojima pruatelj usluga djeluje i
prua svoje usluge,
revizorska i posljednja financijska izvjea pruatelja usluga
mogunost neogranienog i svakodobnog pristupa svojim informacijama
poznavanje propisa relevantnih za pruanje usluga koje su predmet eksternalizacije.
Nadalje, banka bi trebala pri provedbi dubinskog ispitivanja pruatelja usluga ije je pruanje
usluga vrlo vano za banku, uzeti u obzir i sljedee:
adekvatnost internih akata pruatelja usluga koji se odnose:
na upravljanje informacijskim sustavom
na sigurnost informacijskog sustava
na upravljake, logike i fizike kontrole
na planiranje kontinuiteta poslovanja
na upravljanje operativnim i sistemskim zapisima
na razvoj i odravanje informacijskog sustava,
adekvatnost kontrola primijenjenih kod pruatelja usluga
financijske mogunosti investiranja i pruanja zahtijevane podrke od strane pruatelja
usluga
postojanje odgovarajueg osiguranja, ugovorenog od strane pruatelja usluga.
8.2.3. Definiranje sadraja ugovora s pruateljem usluga

Uprava banke odgovorna je prema ZOB-u za svaku aktivnost koju za potrebe banke provodi
pruatelj usluga.
U ugovoru izmeu banke i pruatelja usluga treba definirati poslovne potrebe banke te
regulirati imbenike rizika identificirane pri procjeni rizika eksternalizacije i dubinskog
ispitivanja. Uprava banke duna je ugovornim odredbama osigurati zatitu bankovne i
poslovne tajne, povjerljivost baninih podataka te omoguiti Hrvatskoj narodnoj banci
obavljanje nadzora.
Ugovori trebaju biti u pisanom obliku, jasno sastavljeni i dovoljno detaljni kako bi osigurali
ispunjavanje preuzetih obveza koje se odnose na pruanje usluga. Isto tako, ugovori trebaju
jasno definirati sve relevantne pojmove, uvjete, prava i obveze te odgovornosti ugovornih
strana, pri emu minimalno trebaju sadravati sljedee odredbe:
79
detaljan opis usluga koje su predmet ugovora te nain ispunjenja ugovornih obveza
odgovornost za tetu u sluaju povrede ugovornih obveza
obvezu pruatelja usluga da prije zakljuenja ugovora s podizvoaem zatrai
prethodnu pismenu suglasnost banke
obvezu zatite bankovne i poslovne tajne te povjerljivosti baninih podataka
detaljan opis prava i obveza ugovornih strana za sluaj prestanka ugovora, i to na
nain koji e osigurati kontinuitet poslovanja banke
pravo banke na pristup informacijama i vlasnitvo nad informacijama
nain na koji e banka obavljati nadzor nad pruateljem usluga
osigurati zaposlenicima Hrvatske narodne banke izravni nadzor djelatnosti i poslova u
svezi s kojima Hrvatska narodna banka obavlja nadzor
osigurati zaposlenicima Hrvatske narodne banke fiziki pristup resursima pruatelja
usluga koji su neophodni za izvrenje usluga koje su predmet ugovora
odgovornost pruatelja usluga za neobavljene, nepravodobne i neispravne transakcije i
ostale ugovorene aktivnosti
detaljan opis prava i obveza ugovornih strana koje e osigurati kontinuitet poslovanja
banke u sluaju raskida ugovora
identifikaciju kljunih kontrola, vremena odgovora na incidente, procedura i stupnjeva
eskalacije u sluaju pojave nepredvienih dogaaja, pokrivenosti osiguranjem,
mogunosti oporavka te drugih mjera upravljanja rizicima koje bi pruatelj usluga
trebao primijeniti
osigurati uvid u financijska izvjea, izvjea unutarnje i vanjske revizije kao i u ostala
izvjea vezana uz poslovanje pruatelja usluga, a koja bi mogla biti relevantna za
banku.
8.2.4. Osiguravanje kontinuiranog nadzora pruanja usluga u skladu s ugovornim

obvezama
Nakon sklapanja ugovora s pruateljem usluga banka bi trebala uvesti adekvatan sustav
nadzora i kontinuirano ga provoditi kako bi kontrolirala nain pruanja usluga i kvalitetu
pruenih usluga.
Isto tako, banka treba utvrditi je li pruatelj usluga implementirao i primjenjuje li
kontinuirano adekvatne kontrole vezane uz pruanje usluga koje su predmet ugovora.
Kontrole trebaju biti barem jednake kontrolama koje bi bile primijenjene kad bi se dotine
aktivnosti obavljale u banci.
Banka treba osigurati struno osoblje koje je u stanju omoguiti kvalitetan nadzor nad
pruateljem usluga i koje e na adekvatan nain upravljati odnosom s pruateljem usluga.
Kontinuirani nadzor pruanja usluga u skladu s ugovornim obvezama treba obuhvaati barem
sljedee:
praenje i analiziranje kvalitete obavljanja usluga
praenje svih injenica i okolnosti koje mogu utjecati na potrebu da se izmijeni ugovor
praenje i analiziranje financijskog stanja te priljeva i odljeva kadrova kod pruatelja
usluga kako bi se na vrijeme uoile financijske potekoe i izbjegli rizici za banku koji
proizlaze iz nemogunosti pruanja ugovorenih usluga
80
procjenjivanje kvalitete revizorskih izvjea pruatelja usluga kako bi se ustanovilo

jesu li opseg i dubina revizije adekvatni i u skladu s pravilima struke
Nadalje, banka bi trebala u sklopu provedbe nadzora pruatelja usluga ije je pruanje usluga
vrlo vano za banku, obuhvatiti i sljedee:
praenje i analiziranje sadraja i kvalitete internih akata pruatelja usluga kako bi se
uoila eventualna odstupanja od zadanih smjernica i ugovornih obveza
neposredan uvid na lokaciji pruanja usluga kako bi se utvrdila primjenjivost
donesenih internih akata pruatelja usluga
procjenjivanje rezultata testiranja plana kontinuiteta poslovanja i plana oporavka
praenje postojanja odgovarajueg osiguranja, ugovorenog od strane pruatelja usluga.
8.2.5. Osiguravanje neogranienoga i svakodobnog pristupa informacijama

Banci mora biti osiguran neogranien i svakodobni pristup informacijama koje su predmet
eksternalizacije ili su na bilo koji nain povezane s eksternalizacijom (dijela) poslovnih
procesa. Isto tako, banke bi trebale imati adekvatan plan kako bi se osigurao kontinuirani
pristup informacijama i kontinuitet poslovnih procesa u sluaju neoekivanog prekida ili
ogranienja pruanja usluga od strane pruatelja usluga.
81
9. E-bankarstvo
9.1. Uvod
Za potrebe ovog dokumenta elektroniko bankarstvo (u nastavku teksta: e-bankarstvo)
definira se kao neposredna ponuda novih i tradicionalnih proizvoda i usluga klijentima putem
elektronikih interaktivnih komunikacijskih kanala. E-bankarstvo ukljuuje sustave koji
klijentima banke pruaju bankarske proizvode i usluge (to su primjerice pristup financijskim
informacijama, voenje poslovanja, informiranje o proizvodima i uslugama, personalizirani
financijski portali, agregirani rauni, elektroniko plaanje, elektroniki novac i slino).
Budui da je uslugama i proizvodima e-bankarstva veim dijelom podrka informacijska
infrastruktura banke koja je podrka i tradicionalnim distribucijskim kanalima, sve navedeno
u ostalim poglavljima ovog dokumenta odnosi se i na e-bankarstvo. U ovom poglavlju
naglasit e se specifinosti pojedinih zahtjeva koji proizlaze iz potrebe za adekvatnim
upravljanjem rizicima povezanima s e-bankarstvom.
E-bankarstvo moemo podijeliti u tri kategorije:
1. informativno: odnosi se na pruanje informacija klijentima o proizvodima i
uslugama; iako rizik za banku u ovom sluaju nije velik, potrebno je uvesti kontrole
kako bi se sprijeile neautorizirane promjene informacija koje se prezentiraju
klijentima;
2. komunikacijsko: odnosi se na interakciju banke i klijenata (primjerice obuhvaa
promjene osobnih podataka, traenje informacija o financijskim raunima kao to su
stanja i transakcije, podnoenje zahtjeva za kreditom i slino); rizik je za banku bitno
vei, posebice zato to u veini sluajeva postoji veza izmeu infrastrukture ebankarstva koja prezentira informacije i usluge klijentu te ostalih dijelova
infrastrukture informacijskog sustava banke;
3. transakcijsko: odnosi se na provoenje transakcija (primjerice prijenos novca s
rauna na raun, kupnja vrijednosnih papira i slino); rizik je najvei i u skladu s time
trebaju biti primijenjene adekvatne kontrole.
Stalne tehnoloke inovacije, irenje telekomunikacijskih kanala, a posebice interneta, te sve
vea konkurencija na tritu omoguili su ubrzan razvoj postojeih i novih bankarskih
proizvoda, usluga te naina isporuke, to stvara nove poslovne mogunosti za banke i njihove
klijente. Iako samo e-bankarstvo nije uzrok nastanka novih rizika u poslovanju banaka,
razvidno je da e-bankarstvo utjee na poveanje i promjenu karakteristika ve poznatih rizika
u bankarskom poslovanju (primjerice stratekog, operativnog, pravnog i reputacijskog rizika).
Neka od specifinih svojstava e-bankarstva, izmeu ostalog, ukljuuju:
izrazito brze promjene vezane uz informacijsku tehnologiju
promjenu oekivanja klijenata
sve veu konkurenciju
iroku dostupnost telekomunikacijskih mrea (primjerice interneta)
sve manje tradicionalne komunikacije izmeu klijenta i banke
integraciju aplikacija koje podravaju e-bankarstvo s tradicionalnim bankarskim
aplikacijama
veliku ovisnost banaka o dobavljaima i pruateljima usluga
ubrzanu pojavu prijetnja i ranjivosti povezanih s telekomunikacijskim mreama.
82
Iz prije navedenog moe se zakljuiti da postojei sustav upravljanja rizikom u banci mora
biti prilagoen kako bi adekvatno obuhvatio posebnosti rizika koje proizlaze iz specifinih
svojstava e-bankarstva, opsega e-bankarstva u ukupnom poslovanju te mogunosti banke da
upravlja rizicima. Sve navedeno poveava potrebu da se i prije uvoenja (nove) e-bankarske
usluge provede procjena rizika e-bankarstva i izradi (aurira) strategija e-bankarstva.
83
9.2. Rizici povezani s e-bankarstvom

Brzim napretkom informacijske tehnologije i njezinim uvoenjem kao i tehnolokom
sloenou poslova e-bankarstva posebno su poveani rizici povezani s e-bankarstvom
odnosno operativni, reputacijski, pravni i strateki rizik. Banka bi trebala osigurati
adekvatnost usluga e-bankarstva s obzirom na temeljna naela informacijskih sustava kako bi
se smanjili prije navedeni rizici. Budui da klijenti banke oekuju svakodobnu raspoloivost
usluge, banka bi trebala osigurati dovoljan kapacitet i redundanciju resursa informacijskog
sustava kako bi usluge bile pouzdane i raspoloive.
Nadalje, kako bi se banka zatitila od pravnog i reputacijskog rizika, usluge e-bankarstva
moraju biti pruene na dosljedan i pravodoban nain u skladu s vaeim propisima i u skladu
s korisnikim oekivanjima da e usluge biti brze i neprekidne. Isto tako, banka je duna
pruiti svojim klijentima sigurnost s obzirom na povjerljivost i integritet podataka.
uvanje povjerljivosti podataka klijenata zakonska je obveza banke pa postupanje protivno
vaeim propisima izlae banku pravnom i reputacijskom riziku. Banka bi trebala na temelju
procjene rizika primijeniti adekvatne zatitne mjere i kontrole koje e osiguravati zatitu
povjerljivosti podataka o klijentima te donijeti pripadajue interne akte i standarde.
imbenici koji odreuju pravni i reputacijski rizik povezan s e-bankarstvom proizlaze i iz
injenice da je e-bankarstvo relativno nov distribucijski kanal kao i iz izrazito velikog
poveanja upotrebe e-bankarstva. Neki od imbenika koji imaju utjecaj na pravni i
reputacijski rizik jesu:
neovlateno (namjerno ili sluajno) otkrivanje, mijenjanje ili unitavanje informacija
gubitak povjerenja klijenata i javnosti zbog neovlatenih radnja na raunima klijenata
neovlateno objavljivanje povjerljivih podataka
nenamjerne greke i propusti
poremeaji rada informacijskog sustava
nemogunost pruanja usluge na oekivani nain (primjerice nezadovoljavajua
funkcionalnost, raspoloivost i slino)
pritube klijenata na tekoe pri koritenju usluge e-bankarstva
neprimjereno upravljanje informacijskim sustavom
nemogunost adekvatnog i pravodobnog odgovora banke na pritube klijenata.
Strateki rizik moe proizai iz nedostatka jasno definiranih poslovnih ciljeva prema kojima
se vrednuje uspjeh provedbe strategije e-bankarstva, loih i proturjenih poslovnih odluka,
neadekvatne primjene poslovnih odluka te neprilagoivanja promjenama u okruenju. Prije
donoenja odluke o uvoenju e-bankarstva banka bi trebala biti upoznata s rizicima
povezanima s e-bankarstvom te napraviti analizu isplativosti odnosno procijeniti cjelokupne
trokove uvoenja e-bankarstva i upravljanja njime.
84
9.3. Upravljanje rizikom e-bankarstva

Kao to je ve navedeno, upravljanje rizikom je proces procjene rizika, poduzimanja radnja za
smanjenje rizika na prihvatljivu razinu i odravanja te razine rizika. Banka bi trebala osigurati
da je upravljanje rizikom e-bankarstva sastavni dio sveobuhvatnog upravljanja rizicima
kojima je banka u svom poslovanju izloena.
Proces upravljanja rizikom i nadzor e-bankarstva trebaju provoditi osobe s adekvatnim
strunim znanjima, bez obzira je li e-bankarstvo podrano u banci ili od strane pruatelja
usluga. Isto tako, banka bi trebala nadzirati razvoj, implementaciju i odravanje sigurnosne
infrastrukture koja e uinkovito tititi resurse e-bankarstva od unutarnjih i vanjskih prijetnja.
Sigurnosna infrastruktura e-bankarstva i upravljanje njome ukljuuju barem sljedee:
detaljne interne akte vezane uz e-bankarstvo
logike i fizike kontrole, osobito kontrole pristupa
primjerenu infrastrukturu koja ograniava aktivnosti korisnika informacijskog sustava
dodjelu odgovornosti za nadzor razvoja, implementacije i odravanja pojedinih
dijelova sigurnosne infrastrukture
praenje aktivnosti radi sprjeavanja i otkrivanja neovlatenog pristupa i radnja na
informacijskom sustavu
kontinuirano revidiranje zatitnih mjera i kontrola (ukljuujui neprekidno praenje
novih sigurnosnih trendova te instalaciju programskih ispravaka i nadogradnja).
Budui da je uprava banke, izmeu ostalog, odgovorna i za razvoj poslovne strategije i
djelotvorno upravljanje svim rizicima kojima je u svom poslovanju izloena, prije uvoenja
usluge e-bankarstva trebala bi o tome donijeti eksplicitnu strateku odluku.
Banka bi trebala provesti analizu isplativosti koja e biti podloga za donoenje odluke o
uvoenju usluga i proizvoda e-bankarstva. Pri provoenju analize isplativosti potrebno je
uzeti u obzir procijenjene rizike, trokove primjene zatitnih mjera i kontrola, vrijeme,
tehniku kompetentnost i ostale resurse neophodne za adekvatno upravljanje i nadzor
aktivnosti e-bankarstva (primjerice osoblje te hardversku, softversku i komunikacijsku
podrku). Prilikom provoenja analize isplativosti uvoenja usluga i proizvoda e-bankarstva,
potrebno je uzeti u obzir i sljedee imbenike:
promjene u internim aktima banke i praksama
utjecaj na funkcionalnost i sigurnost informacijskog sustava
postizanje i odravanje primjerene mrene infrastrukture
postizanje i odravanje kompetentnosti na podruju sigurnosti, sustava za podrku
raspoloivosti sustava kao i sustava za otkrivanje neovlatenog pristupa i radnja na
informacijskom sustavu
praenje i nadzor pruatelja usluga i dobavljaa.
Na temelju navedenog potrebno je donijeti strategiju e-bankarstva koja bi trebala uzeti u obzir
razliite imbenike (primjerice elje i potrebe klijenata, konkurenciju, kompetentnost,
trokove uvoenja i odravanja te postojea financijska sredstva) i biti u skladu s poslovnom
strategijom banke.
Zbog specifinosti rizika povezanih s e-bankarstvom u sklopu upravljanja tim rizicima
potrebno je razmotriti sljedee:
85
nadzor i praenje e-bankarstva

uspostavljanje kontrola
sigurnost klijenta.
9.3.1. Nadzor i praenje e-bankarstva

Djelotvoran sustav nadzora i praenja e-bankarstva nuan je za efikasno upravljanje i kontrolu
nad e-bankarstvom te postizanje poslovnih ciljeva. Praenje i nadzor e-bankarstva trebali bi
obuhvatiti cjelokupni proces e-bankarstva uzimajui u obzir:
konfiguraciju i sigurnost mree
meuovisnosti i veze s postojeim sustavom
usuglaenost s vaeim propisima
usuglaenost s internim aktima (primjerice s politikom sigurnosti informacijskog
sustava)
zatitne mjere i kontrole
aktivnosti pruatelja usluga
tehniku kompetentnost osoblja
potrebu za odravanjem kontinuiteta poslovanja
praenje neuobiajenih aktivnosti.
Isto tako, banka bi trebala implementirati adekvatan sustav kontinuiranog nadzora u sluaju
eksternalizacije (dijela) sustava e-bankarstva kako bi kontrolirala nain i kvalitetu pruanja
usluga.
9.3.1.1. Planiranje kontinuiteta pruanja usluge e-bankarstva
Banka bi trebala uspostaviti proces planiranja kontinuiteta pruanja usluge e-bankarstva koji
bi trebao biti sastavni dio plana kontinuiteta poslovanja banke. Navedeno je potrebno kako bi
se smanjio reputacijski, pravni i operativni rizik povezan s neraspoloivou ili neadekvatnom
kvalitetom pruanja usluga e-bankarstva.
U sklopu planiranja kontinuiteta pruanja usluge e-bankarstva banka bi trebala, izmeu
ostalog, osigurati sljedee:
analizu postojeih kapaciteta informacijskog sustava koji podravaju e-bankarstvo,
ukljuujui procjenjivanje kapaciteta procesiranja transakcija e-bankarstva
mogunost nadogradnje sustava e-bankarstva
testiranje sustava e-bankarstva pod optereenjem (s obzirom na oekivani broj
korisnika)
ponovnu uspostavu ili zamjenu e-bankarskih procesnih mogunosti
rekonstrukciju transakcija u sluaju potrebe
procjenu ugovornih odnosa s dobavljaima i pruateljima usluga
mogunost koritenja priuvnoga telekomunikacijskog kanala koji klijentima moe
pruiti adekvatnu razinu usluge.
Nadalje, pri planiranju kontinuiteta poslovanja banka bi trebala donijeti odgovarajui plan
odgovora na incidente kako bi odgovorila na incidente koji nastaju zbog neoekivanih i
86
neeljenih dogaaja (kao to su unutarnji i vanjski napadi koji mogu imati negativne
posljedice kad je rije o pruanju usluga e-bankarstva) radi njihova rjeavanja ili smanjenja. U
sluaju nastanka incidenta, ukoliko su naruena prava odreenih klijenata banke, klijente je
potrebno o tome obavijestiti.
9.3.1.2. Praenje neuobiajenih aktivnosti
Dobre prakse nalau provoenje procjene rizika i razmatranje uvoenja djelotvornog i
pravodobnog sustava praenja neuobiajenih aktivnosti koje se odnose na e-bankarstvo kao
to su:
transakcije e-bankarstva s neaktivnih rauna, vei broj transakcija u kraem razdoblju
prema raunima s kojima do tada nije bilo transakcija (posebice ako ukupni preneseni
iznos novca prelazi granini iznos novca koji podlijee odredbama Zakona o
sprjeavanju pranja novca, "Narodne novine", br. 69/1997., 106/1997, 67/2001.,
114/2001., 117/2003., 142/2003.), transakcije u offshore zone i slino
promjena osobnih podataka klijenata (primjerice adrese klijenta), nakon koje slijede
aktivnosti kao to su novi ekovi, nove zaporke, PIN-ovi koji se alju na tu adresu,
poveanje limita, vei iznosi koji se prenose i ostalo. Navedeni slijed aktivnosti
upuuje na moguu prijevaru.
Nadalje, u sklopu sustava praenja neuobiajenih aktivnosti banka bi trebala razmotriti
postupke komunikacije s klijentom te izvjeivanja odgovornih osoba i institucija.
9.3.2. Kontrole
Uprava banke je odgovorna za uspostavu adekvatnog sustava kontrola e-bankarstva.
Navedeno ukljuuje uspostavu upravljakih, logikih i fizikih kontrola na svim razinama.
Zbog specifinosti rizika e-bankarstva posebnu pozornost valja posvetiti sljedeim
imbenicima:
identifikaciji, autentifikaciji i autorizaciji
povjerljivosti
integritetu podataka i transakcija
raspoloivosti
razdvajanju dunosti
upravljanju operativnim i sistemskim zapisima
sigurnoj i robusnoj infrastrukturi sustava e-bankarstva
neporecivosti
dokazivosti.
Neki od navedenih imbenika detaljnije su razloeni u nastavku teksta.
9.3.2.1. Identifikacija, autentifikacija i autorizacija
Banka je duna na temelju procjene rizika, koja obuhvaa i specifinosti e-bankarstva,
donijeti standarde i ostale interne akte te u skladu s tim:
87
primijeniti sigurnu i djelotvornu tehnologiju autentifikacije za potvrdu identiteta i

ovlasti osoba, procesa i sustava
primjereno upravljati identifikacijskim i autentifikacijskim oznakama klijenata.
Prilikom procjene rizika potrebno je uzeti u obzir vrstu pojedine transakcije, osjetljivost
informacija koje se prenose i pohranjuju te pouzdanost, sigurnost, provjerenost i nain
primjene pojedine autentifikacijske metode. Autentifikacija klijenata trebala bi biti "jaka"
odnosno ukljuivati najmanje dva od tri naina utvrivanja neospornosti korisnikog
identiteta (detaljnije objanjeno u poglavlju "Upravljanje kontrolama pristupa").
9.3.2.2. Povjerljivost, integritet i raspoloivost
E-bankarstvo poveava rizik od neovlatenog pristupa informacijama pri prijenosu javno
dostupnom ili privatnom telekomunikacijskom mreom kao i onda kad su pohranjene u
informacijskom sustavu banke. Kako bi se zatitila povjerljivost informacija, banka bi trebala
osigurati barem sljedee:
resursi informacijskog sustava trebaju biti dostupni samo ovlatenim i autentificiranim
osobama, procesima i sustavima;
resursi informacijskog sustava trebaju biti zatieni od neovlatenog otkrivanja ili
mijenjanja za vrijeme prijenosa javno dostupnim i privatnim telekomunikacijskim
mreama kao i pri pohranjivanju i uvanju informacija na sustavima banke;
adekvatnu kontrolu pristupa pruatelja usluga koji imaju pristup povjerljivim
informacijama;
pristup osjetljivim informacijama ili bilo kakva modifikacija konfiguracije resursa
informacijskog sustava (ija posljedica moe biti otkrivanje, unitavanje ili mijenjanje
informacija) trebali bi se zapisivati u operativne i sistemske zapise.
Neadekvatna zatita integriteta sustava i podataka moe dovesti do netonosti, prijevara ili
pogrenih odluka, to moe biti prvi korak u naruavanju povjerljivosti i raspoloivosti
sustava i podataka te smanjiti povjerenje u usluge e-bankarstva openito. Sve navedeno moe
rezultirati poveanjem svih rizika kojima je banaka u svom poslovanju izloena. Kako bi
ouvala integritet podataka, banka bi trebala implementirati adekvatne zatitne mjere i
kontrole koje bi, uz potrebu ouvanja povjerljivosti, osigurale barem sljedee:
e-bankarske transakcije trebaju se provoditi na takav nain da budu izrazito otporne na
neovlatene utjecaje tijekom cijelog procesa;
e-bankarske transakcije te procesi upravljanja podacima trebali bi biti planirani i
izvedeni tako da rizik neprimjeivanja neovlatenih aktivnosti bude sveden na
najmanju moguu mjeru;
adekvatno upravljanje promjenama, ukljuujui praenje i testiranje sustava;
primjenu kriptografskih metoda (primjerice banka bi trebala za prijenos osjetljivih
informacija razmotriti uvoenje enkripcije od polazita do odredita informacije bez
prijelazne dekripcije);
aplikativne kontrole (primjerice za provjeru usklaenosti iznosa nakon izvrenja
transakcija, kao i provjeru integriteta podataka prenesenih izmeu razliitih sustava);
praenje neuobiajenih aktivnosti.
Isto tako, jedna od vanijih karakteristika e-bankarstva jest raspoloivost usluge. Pojam
raspoloivosti odnosi se na svojstvo mogunosti pristupa i upotrebljivosti na zahtjev
88
ovlatenog korisnika usluge e-bankarstva. Kako bi pruila zadovoljavajuu kvalitetu usluge ebankarstva, banka bi trebala osigurati primjerene kapacitete informacijske i
telekomunikacijske infrastrukture te adekvatnu zatitu od namjernog ili sluajnog
uskraivanja usluge.
Neporecivost i dokazivost mogue je promatrati i kao kombinaciju naela povjerljivosti,
integriteta i raspoloivosti. Banka bi trebala koristiti autentifikacijske metode kojima se
osigurava neporecivost i dokazivost transakcija e-bankarstva. Rizik poricanja transakcija ve
je prisutan pri tradicionalnim plaanjima kreditnim karticama, a e-bankarstvo poveava taj
rizik:
zbog kompleksnosti identificiranja, autentificiranja i autoriziranja osoba, procesa ili
sustava koji iniciraju transakciju
zbog mogunosti neovlatene promjene ili "prisvajanja" transakcija
zbog mogunosti osporavanja transakcija e-bankarstva od strane korisnika.
S obzirom na sve navedeno banka bi trebala ovisno o vrsti e-bankarske transakcije osigurati
barem sljedee:
sustavi e-bankarstva trebaju biti projektirani na nain kojim se smanjuje vjerojatnost
iniciranja nenamjernih transakcija od strane ovlatenih korisnika;
korisnici trebaju biti upoznati s rizicima povezanima s transakcijom koju zapoinju;
osobe, procesi i sustavi trebaju biti identificirani i autentificirani;
primjenu odgovarajuih kontrola nad autentificiranim kanalom.
9.3.2.3. Razdvajanje (segregacija) dunosti
Razdvajanje dunosti je vrsta upravljake kontrole kojoj je cilj smanjiti rizik prijevare u
poslovnim procesima te osigurati tonost i integritet podataka. Banka bi trebala primijeniti
adekvatne kontrole radi djelotvornog razdvajanja dunosti u procesu e-bankarstva.
Uobiajene prakse koje se koriste prilikom razdvajanja dunosti ukljuuju sljedee:
transakcijski procesi i sustavi trebali bi biti projektirani tako da ni jedan zaposlenik
banke ili osoba zaposlena kod pruatelja usluga ne moe samostalno zapoeti,
autorizirati i zavriti transakciju;
dunosti bi trebalo razdvojiti na dunosti onih (osoba, procesa i sustava) koji iniciraju
poslovni proces u sklopu e-bankarstva i onih koji su odgovorni za verifikaciju
integriteta tog procesa;
potrebno je testirati sustav e-bankarstva kako bi se iskljuila mogunost zaobilaenja
kontrola uvedenih radi razdvajanja dunosti;
dunosti bi trebalo razdvojiti na dunosti osoblja koje razvija, osoblja koje testira i
dunosti osoblja koje administrira sustav e-bankarstva.
9.3.2.4. Sigurnost aplikacija e-bankarstva
Neprimjerena arhitektura aplikacija e-bankarstva poveava rizik koji proizlazi iz neovlatenih
radnja. Banka bi stoga trebala osigurati primjerenu razinu sigurnosti sustava e-bankarstva
adekvatnom arhitekturom aplikacije, imajui u vidu barem sljedee:
odabir softverskih alata i tehnologije za razvoj e-bankarskih aplikacija s obzirom na
znaajke sigurnosti;
89
potrebno je provoditi detaljnu i djelotvornu provjeru ispravnosti podataka (dobivenih

javno dostupnim telekomunikacijskim mreama) u nadziranoj i sigurnoj okolini kako
bi se smanjio rizik od obraivanja neispravnih podataka ili neovlatenog pristupa,
radnja i slino;
informacije koje sustav e-bankarstva uputi na suelje klijenta ne bi smjele otkrivati
osjetljive informacije koje se odnose na arhitekturu aplikacije ili drugih resursa
sustava e-bankarstva;
povjerljive informacije koje se prosljeuju sa sustava e-bankarstva na suelje klijenta
ili u suprotnom smjeru ne bi se trebale pohranjivati u privremene ili trajne resurse za
uvanje podataka na ureaju klijenta bez njegova izriitog zahtjeva te ne bi smjele biti
vidljive neovlatenim osobama;
upravljanje aktivnim komunikacijskim kanalom e-bankarstva trebalo bi biti sigurno,
to primjerice ukljuuje i njegovo zatvaranje odnosno prekidanje nakon razdoblja
neaktivnosti klijenta.
9.3.2.5. Sigurnosna infrastruktura koja podrava e-bankarstvo

Banka bi trebala uspostaviti adekvatno operativno okruenje koje podrava i titi sustav ebankarstva. Navedeno obuhvaa sigurnu infrastrukturu prema javno dostupnim
telekomunikacijskim mreama, adekvatne zatitne mjere za lokalnu komunikacijsku mreu i
veze prema drugim poslovnim subjektima. Nadalje, banka bi trebala implementirati
hardversku i softversku podrku koja e:
djelotvorno ograniavati radnje koje nisu neophodne
detaljno nadzirati sve radnje koje su doputene i upravljati njima (primjerice
primjenom vatrozida i sustava za otkrivanje neovlatenog pristupa i radnja na
informacijskom sustavu).
Potrebno je proaktivno i kontinuirano pratiti i nadzirati infrastrukturu prema javno dostupnim
i privatnim telekomunikacijskim mreama kako bi se smanjio rizik koji proizlazi iz
neprimjeivanja povreda sigurnosti, sumnjivih radnja, neovlatenog pristupa sustavima banke
te ostalih prijetnja.
9.3.3. Sigurnost klijenata

Kako bi banka smanjila pravni i reputacijski rizik, potrebno je prije zapoinjanja transakcije
na distribucijskim kanalima osigurati adekvatnu informaciju o identitetu banke (primjerice
ime banke i adresu sjedita banke, opis naina na koji klijenti mogu kontaktirati banku u svezi
s problemima, prijedlozima, pritubama i slino). Isto tako, banka bi trebala osigurati
adekvatnu potvrdu svog identiteta i autentinosti (primjerice upotrebom digitalnog certifikata)
kako bi se smanjila mogunost neovlatenog predstavljanja u ime banke putem elektronikih
distribucijskih kanala.
Banka ne bi smjela traiti od klijenata informacije o identifikacijskim i autentifikacijskim
oznakama putem komunikacijskih kanala koji ne osiguravaju odravanje temeljnih naela
informacijskog sustava. Isto tako, banka bi svoje klijente trebala upoznati s moguim
nainima provjere da li komuniciraju s bankom putem adekvatno osiguranoga slubenog
elektronikog kanala distribucije (npr. oznaka sigurne transakcije ili provjera certifikata).
90
Nadalje, dobre prakse nalau da je klijente potrebno upoznati s injenicom da banka

poduzima sve potrebne radnje kako bi osigurala adekvatnu zatitu usluge e-bankarstva.
Kako bi se klijentu pruila odgovarajua sigurnost i kako bi se kontrolirao proces prijenosa
novca kanalima e-bankarstva, dobre prakse nalau razmatranje sljedeeg:
definiranja graninih iznosa transakcija (limita)
odabira rauna koji mogu sudjelovati u transakcijama
ovlasti klijenta za promjenu parametara transakcija (primjerice graninog iznosa,
rauna)
revidiranja korisnikih ovlasti ovisno o dotadanjem koritenju usluge e-bankarstva
(primjerice izmjena graninih iznosa transakcija ovisno o razdoblju koritenja usluge,
uvjetima koritenja, broju transakcija i slino)
primjena adekvatne tehnologije identifikacije, autentifikacije i autorizacije s obzirom
na tip klijenata, granine iznose i slino.
Prilikom definiranja procesa odobravanja koritenja usluge e-bankarstva, kao i promjene
parametara rauna klijenta, potrebno je definirati kriterije, naine i postupke:
podnoenja zahtjeva
odobravanja koritenja usluge e-bankarstva
slanja povjerljivih podataka klijentima banke
promjene osobnih podataka klijenata
primjene tehnologija autentifikacije i autorizacije za spomenute procese.
91
10. Zakljuci i preporuke

Upravljanje informacijskim sustavom
1.
Uprava banke trebala bi odrediti lana uprave koji e biti nadlean za nadzor i
kontrolu procesa upravljanja informacijskim sustavom.
2.
Uprava banke trebala bi uspostaviti adekvatnu organizacijsku strukturu,

odgovarajue funkcije i odbore te proces upravljanja rizikom informacijskog sustava
kako bi se osiguralo primjereno upravljanje informacijskim sustavom.
3.
Uprava banke trebala bi delegirati ovlasti

organizacijskom i funkcionalnom strukturom.
4.
Uprava banke trebala bi donijeti strategiju informacijskog sustava koja mora biti u
skladu s poslovnom strategijom banke. Strategiju informacijskog sustava potrebno je
razraditi u stratekim i operativnim planovima.
5.
Uprava banke trebala bi donijeti interne akte kojima se ureuje upravljanje

informacijskim sustavom.
6.
Potrebno je definirati kriterije, naine i postupke izvjeivanja uprave banke.
7.
Uprava banke trebala bi imenovati voditelja organizacijske jedinice informacijske

tehnologije, koji bi trebao biti usmjeren na strateka pitanja, funkcionalnost i
djelotvornost informacijskog sustava u cjelini, te bi trebala definirati njegove ovlasti,
odgovornosti i djelokrug rada.
8.
Uprava banke trebala bi uspostaviti neovisnu funkciju voditelja sigurnosti

informacijskog sustava, koji bi trebao biti usmjeren na pitanja sigurnosti
informacijskog sustava u cjelini, te bi trebala definirati njegove ovlasti, odgovornosti
i djelokrug rada. Voditelj sigurnosti informacijskog sustava ne bi smio istodobno biti
angairan na drugim funkcijama koje mogu stvoriti sukob interesa.
9.
Uprava banke trebala bi imenovati odbor za upravljanje informacijskim sustavom ili

druge odbore ija je uloga praenje i nadziranje informacijskog sustava i njegovih
aktivnosti te koordinacija inicijativa vezanih uz informacijski sustav, a koje se tiu
usklaenosti s poslovnim ciljevima i stratekim planom banke.
10.
Banka bi trebala donijeti metodologiju upravljanja projektima kojom bi se definirali

kriteriji, naini i postupci upravljanja projektima.
skladu
uspostavljenom
Upravljanje rizikom informacijskog sustava

1.
92
Upravljanje rizikom potrebno je uspostaviti kao kontinuirani proces procjene rizika,

poduzimanja radnja za smanjenje rizika na prihvatljivu razinu i odravanja
prihvatljive razine rizika.
2.
Banka bi trebala donijeti metodologiju upravljanja rizikom informacijskog sustava u

kojoj bi se definirali kriteriji, naini i postupci upravljanja rizikom.
3.
Uprava banke trebala bi biti pisanim putem obavijetena o najznaajnijim

rezultatima procjene rizika.
4.
Banka bi trebala odabrati i provesti mjere za smanjivanje rizika na prihvatljivu

razinu.
5.
Banka bi trebala pri provoenju odabranih mjera uvesti nove i/ili izmijeniti
postojee upravljake, logike ili fizike kontrole. Nakon provoenja odabranih
mjera potrebno je utvrditi preostale rizike.
6.
Uprava banke trebala bi biti upoznata sa svim identificiranim preostalim rizicima te

u skladu s time donijeti odluku o prihvaanju preostalih rizika ili poduzimanju
radnja za daljnje smanjenje rizika.
7.
Banka bi trebala klasificirati informacije u razliite grupe prema stupnju njihove

osjetljivosti s obzirom na mogue posljedice naruavanja temeljnih naela
8.
Banka bi trebala donijeti interne akte kojima se definiraju kriteriji, postupci i

odgovornosti za provoenje klasifikacije informacija.
9.
Banka bi trebala zatititi informacije na osnovi provedene klasifikacije informacija i

procjene rizika.
Unutarnja revizija
1.
Unutarnja revizija treba biti organizirana tako da se osigura sustavno obavljanje

revizije informacijskog sustava.
2.
Banka bi trebala donijeti metodologiju za provoenje unutarnje revizije

informacijskog sustava temeljenu na procjeni rizika.
3.
Banka treba na temelju godinjeg programa rada unutarnje revizije donijeti i

operativne planove rada za reviziju informacijskog sustava.
4.
Banka bi trebala kontinuirano obavljati unutarnju reviziju informacijskog sustava i

definirati razdoblje unutar kojeg e obaviti reviziju cjelokupnoga informacijskog
sustava.
5.
Izvjea o radu unutarnje revizije trebala bi sadravati i izvjea o obavljenim

revizijama informacijskog sustava.
93
Sigurnost informacijskog sustava
94
1.
Banka bi trebala donijeti politiku sigurnosti informacijskog sustava, upoznati

korisnike informacijskog sustava s njom te imenovati osobu odgovornu za kontrolu
provoenja te politike.
2.
Politika sigurnosti informacijskog sustava trebala bi sadravati naela upravljanja

sigurnou informacijskih resursa te odgovornosti koje se odnose na sigurnost
3.
Na temelju politike sigurnosti informacijskog sustava banka bi trebala donijeti i

primijeniti detaljne interne akte koji se odnose na sve aspekte sigurnosti
4.
Politiku sigurnosti informacijskog sustava potrebno je usklaivati s promjenama na

informacijskom sustavu i u njegovoj okolini, u sluajevima naruavanja sigurnosti
informacijskog sustava, te ovisno o rezultatima procjene rizika.
5.
Banka bi trebala definirati kriterije na temelju kojih e kontrolirati pristup resursima

informacijskog sustava, te u skladu s definiranim kriterijima i procjenom rizika
uvesti adekvatne upravljake, logike i fizike kontrole pristupa. Uvedene kontrole
pristupa trebale bi biti u skladu sa standardima i pravilima struke.
6.
Banka bi trebala uspostaviti sustav upravljanja korisnikim pravima pristupa koji

obuhvaa procese evidentiranja, autorizacije, identifikacije i autentifikacije te
nadzora.
7.
Banka bi trebala posvetiti posebnu pozornost identifikaciji i autentifikaciji korisnika

8.
Banka bi trebala posvetiti posebnu pozornost povlatenom i udaljenom pristupu

resursima informacijskog sustava te ostalim pristupima koji, prema procjeni rizika,
izlau banku poveanom riziku.
9.
Banka bi trebala u skladu s provedenom procjenom rizika odrediti adekvatne

kriptografske metode ijom e se primjenom osigurati odravanje temeljnih naela
10.
Banka bi trebala definirati i primijeniti postupke generiranja, pohrane, distribucije,

aktiviranja, upotrebe, arhiviranja, zamjene, deaktivacije i unitavanja kriptografskih
kljueva.
11.
Banka bi trebala, na osnovi provedene procjene rizika, primijeniti odgovarajue

upravljake, logike i fizike kontrole radi fizike zatite prostorija s resursima
informacijskog sustava, samih resursa, kao i sustava koji su podrka funkcioniranju
12.
Banka bi trebala osigurati izradu, praenje i analizu operativnih i sistemskih zapisa

kojima bi se omoguilo rekonstruiranje dogaaja, otkrivanje neovlatenih pristupa i
radnja na informacijskom sustavu, identificiranje problema i utvrivanje

odgovornosti.
13.
Operativni i sistemski zapisi moraju biti adekvatno zatieni od neovlatenog

pristupa, izmjena i brisanja.
14.
Banka bi trebala primijeniti odgovarajue upravljake, logike i fizike kontrole

kako bi se resursi informacijskog sustava zatitili od malicioznog koda. Kontrole je
potrebno neprekidno nadzirati i redovito nadopunjavati.
Odravanje informacijskog sustava

1.
Banka bi trebala uspostaviti proces upravljanja imovinom informacijskog sustava

koji obuhvaa detektiranje, evidentiranje, raspolaganje, praenje, planiranje,
obnavljanje, zatitu i odlaganje imovine.
2.
Banka bi trebala uspostaviti proces upravljanja promjenama hardverskih i

softverskih komponenata informacijskog sustava banke koji obuhvaa postupke
utvrivanja poetnih inaica softverskih i hardverskih komponenata informacijskog
sustava te identifikacije i praenja svih promjena u vezi s njima.
3.
Banka bi trebala uspostaviti proces upravljanja konfiguracijama hardverskih i

softverskih komponenata informacijskog sustava koji obuhvaa postupke analize,
definiranja, dokumentiranja, testiranja, uvoenja u produkcijski rad, kontrole i
praenja izmjena svih osjetljivih postavka komponenata informacijskog sustava.
4.
Banka bi trebala definirati postupke izrade, pohrane, odravanja i uvanja

dokumentacije koja se odnosi na informacijski sustav banke.
5.
Dokumentacija bi trebala biti tona, potpuna i aurna.
6.
Banka bi trebala korisnicima informacijskog sustava osigurati pristup dokumentaciji

koja je potrebna za obavljanje njihovih poslovnih zadataka.
7.
Banka bi trebala osigurati primjerenu izobrazbu svih korisnika informacijskog

sustava koja e navedenim osobama omoguiti djelotvorno obavljanje poslovnih
zadataka te smanjiti mogunost pojave neeljenih dogaaja na prihvatljivu razinu.
Izobrazbu bi trebalo uspostaviti kao kontinuirani proces kako bi se osiguralo da
znanja korisnika informacijskog sustava prate promjene u informacijskom sustavu i
u njegovoj okolini.
Planiranje kontinuiteta poslovanja

1.
Banka bi trebala uspostaviti proces planiranja kontinuiteta poslovanja kako bi

osigurala postojanost kritinih i/ili vitalnih poslovnih procesa.
2.
Banka bi trebala izraditi i dokumentirati analizu utjecaja na poslovanje koja e

odrediti utjecaj neraspoloivosti pojedinih poslovnih procesa odnosno resursa
95
informacijskog sustava potrebnih za odvijanje tih procesa na poslovanje banke.

Analiza utjecaja na poslovanje trebala bi posluiti kao podloga za planiranje
kontinuiteta poslovanja.
96
3.
Banka bi trebala usvojiti plan kontinuiteta poslovanja koji e osigurati ponovnu

uspostavu kritinih i/ili vitalnih poslovnih procesa u zahtijevanom vremenu te
ograniiti i smanjiti gubitke koji mogu nastati kao posljedica prekida poslovnih
procesa. Plan kontinuiteta poslovanja treba se temeljiti na analizi utjecaja na
poslovanje i procjeni rizika.
4.
Banka bi trebala usvojiti plan oporavka koji e osigurati raspoloivost resursa

informacijskog sustava potrebnih za odvijanje kritinih i/ili vitalnih poslovnih
procesa u zahtijevanom vremenu. Plan oporavka treba se temeljiti na analizi utjecaja
na poslovanje i procjeni rizika.
5.
Banka bi trebala uspostaviti proces upravljanja incidentima te izraditi plan odgovora

na incidente koji treba definirati procedure za postupanje u sluaju incidenata i
odrediti osobe zaduene za odgovore na incidente te definirati njihov djelokrug rada,
ovlasti i odgovornosti.
6.
Banka bi trebala, u sluaju teih incidenata, obavijestiti Hrvatsku narodnu banku o

incidentu, njegovim uzrocima, uinku te nainu rjeavanja.
7.
Banka bi trebala upravljati priuvnom pohranom na nain koji ukljuuje postupke

izrade, pohrane i testiranja priuvnih kopija te restauracije podataka kako bi se
omoguila ponovna uspostava poslovnih procesa i osigurala temeljna naela
8.
Banka bi trebala osigurati postojanje aurnih priuvnih kopija kao i provjerenih i

testiranih metoda restauriranja podataka. Priuvne kopije trebale bi biti, u skladu s
procjenom rizika, pohranjene i na udaljenu sigurnu lokaciju.
9.
Banka bi trebala, u skladu s procjenom rizika i analizom utjecaja na poslovanje,

osigurati raspoloivost priuvnoga raunalnog centra na udaljenoj lokaciji s
odgovarajuom opremljenou, funkcionalnou i sigurnou.
10.
Banka bi trebala testirati plan kontinuiteta poslovanja, plan oporavka i plan

odgovora na incidente nakon znaajnih promjena u poslovnim procesima ili na
informacijskom sustavu, a najmanje svakih 18 mjeseci. Potrebno je sastaviti pisana
izvjea o rezultatima testiranja.
11.
Postupke izrade i pohrane priuvnih kopija potrebno je periodino, a najmanje

jednom godinje, revidirati, kako bi se osigurala usklaenost navedenih postupaka sa
zahtjevima koji proizlaze iz plana kontinuiteta poslovanja i plana oporavka.
12.
Postupke restauracije podataka s priuvnih kopija potrebno je periodino testirati, a

najmanje jednom godinje, kako bi se osigurala usklaenost navedenih postupaka sa
zahtjevima koji proizlaze iz plana kontinuiteta poslovanja i plana oporavka.
Potrebno je sastaviti pisano izvjee o rezultatima testiranja.
13.
Banka bi trebala testirati funkcionalnost i sigurnost priuvnoga raunalnog centra

najmanje svakih 18 mjeseci. Potrebno je sastaviti pisano izvjee o rezultatima
testiranja.
Razvoj sustava i eksternalizacija

1.
Banka bi trebala definirati nain, kriterije, postupke i standarde razvoja

informacijskih sustava, imajui u vidu funkcionalne i sigurnosne aspekte.
2.
Banka bi trebala proces razvoja informacijskog sustava organizirati kroz projekte.

Projekte razvoja potrebno je planirati i formalno organizirati.
3.
Banka bi trebala projekte razvoja informacijskih sustava planirati i formalno

organizirati kao sastavni dio procesa razvoja informacijskih sustava.
4.
Banka bi trebala uspostaviti i dokumentirati proces programskog razvoja i isporuke

informacijskog sustava koji obuhvaa postupke analize i projektiranja,
programiranja, testiranja i uvoenja u produkcijski rad.
5.
Banka bi trebala uspostaviti proces upravljanja programskim promjenama

informacijskih sustava radi odravanja temeljnih naela informacijskog sustava.
6.
Banka bi trebala adekvatno razdvojiti razvojnu, testnu i produkcijsku okolinu.
7.
Prije donoenja odluke o eksternalizaciji banka bi trebala utvrditi da li

zakonodavstvo odnosno propisi drave u kojima pruatelj usluga posluje
omoguavaju Hrvatskoj narodnoj banci da ostvari cjelovit i neogranien pristup
djelatnostima i poslovima u svezi s kojima Hrvatska narodna banka obavlja nadzor.
8.
Izravni nadzor od strane Hrvatske narodne banke u odnosu na pruanje usluga na

teritoriju Republike Hrvatske i izvan njega od strane pruatelja usluga rezidenata ili
nerezidenata ne smije ni na koji nain i ni u kojem trenutku biti onemoguen,
ogranien ili otean.
9.
Prije donoenja odluke o eksternalizaciji (dijela) informacijskog sustava banka bi

trebala procijeniti rizik eksternalizacije.
10. Banka bi prije sklapanja ugovora s pruateljem usluga trebala provesti dubinsko
ispitivanje pruatelja usluga.
11.
Banka bi trebala osigurati da odnos izmeu banke i pruatelja usluga bude

prihvatljiv sa stajalita rizika i u skladu s poslovnim ciljevima banke.
12.
Ugovori izmeu Banke i pruatelja usluga trebaju biti u pisanom obliku, jasno
sastavljeni i dovoljno detaljni kako bi osigurali ispunjavanje preuzetih obveza
pruanja usluga. Isto tako, ugovori trebaju jasno definirati sve relevantne pojmove,
uvjete, prava i obveze te odgovornosti ugovornih strana.
97
13.
Banka bi trebala kontinuirano nadzirati pruanje ugovorenih usluga i upravljati

rizikom eksternalizacije, ukljuujui i primjenu adekvatnih zatitnih mjera i kontrola
kako bi se rizik eksternalizacije smanjio na prihvatljivu razinu.
14.
Banka bi trebala svojim internim aktima regulirati sve elemente i postupke vezane
uz eksternalizaciju.
15.
Banci bi trebao biti osiguran neogranien i svakodoban pristup informacijama koje

su predmet eksternalizacije ili su na bilo koji nain povezane s eksternalizacijom.
E-bankarstvo
98
1.
Banka bi trebala donijeti strategiju e-bankarstva kao sastavni dio poslovne strategije
banke.
2.
Banka bi trebala prije donoenja odluke o uvoenju e-bankarstva ili novih usluga
procijeniti rizike povezane s e-bankarstvom i tim uslugama.
3.
Banka bi trebala osigurati djelotvoran sustav nadzora i praenja e-bankarstva.
4.
Banka bi trebala uspostaviti sigurnosnu infrastrukturu koja e djelotvorno tititi

resurse e-bankarstva. Navedeno ukljuuje i uspostavu slojevitih upravljakih,
logikih i fizikih kontrola.
5.
Banka bi trebala primijeniti sigurne i uinkovite autentifikacijske metode za potvrdu

identiteta i ovlasti osoba, procesa i sustava. Autentifikacija osoba trebala bi biti
"jaka" odnosno ukljuivati najmanje dva naina utvrivanja neospornosti identiteta.
6.
Banka bi trebala zatititi informacije od neovlatenog otkrivanja, mijenjanja ili

brisanja za vrijeme unosa, obrade, prijenosa preko telekomunikacijskih mrea kao i
pri pohrani i uvanju informacija na sustavima banke i klijenata.
7.
Banka bi trebala osigurati adekvatnu potvrdu svog identiteta na distribucijskom

kanalu e-bankarstva kako bi klijent mogao provjeriti i potvrditi identitet i izvornost
banke.
8.
Banka bi trebala osigurati postojanje operativnih i sistemskih zapisa za sve

financijske i nefinancijske transakcije e-bankarstva.
9.
Banka bi trebala upoznati korisnike e-bankarstva s rizicima koritenja ebankarstvom.

Smjernice Za Upravljanje Informacijskim Sustavom

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Smjernice Za Upravljanje Informacijskim Sustavom

Uploaded by

Copyright:

Available Formats

SMJERNICE ZA UPRAVLJANJE

INFORMACIJSKIM SUSTAVOM U CILJU

Hrvatska narodna banka