DORA za hrvatske financijske institucije: što traže regulatori

DORA, Uredba (EU) 2022/2554 o digitalnoj operativnoj otpornosti, na snazi je u cijeloj Europskoj uniji od 17. siječnja 2025.¹ Za hrvatske financijske institucije to znači da skup pravila o upravljanju rizicima informacijske i komunikacijske tehnologije više nije preporuka nego izravna zakonska obveza. Regulatori u Hrvatskoj, HNB za banke i platne institucije te Hanfa za društva za osiguranje, investicijska društva i fondove, traže dokaze da imate uspostavljen okvir, da ga provjeravate testiranjem i da znate što ćete učiniti kad incident udari.²

Glavno pitanje koje nam postavljaju voditelji rizika i članovi uprava glasi ovako: što točno regulator očekuje vidjeti kad pita za DORA usklađenost. Odgovor je konkretan. Očekuje dokumentirani okvir upravljanja IKT rizicima, registar svih ugovora s pružateljima IKT usluga, mehanizam prijave značajnih incidenata u propisanim rokovima, program testiranja otpornosti i jasno definirane odgovornosti uprave. U ovom tekstu razlažemo svaki od tih zahtjeva, objašnjavamo kako se DORA odnosi prema postojećim okvirima poput ISO 27001 i NIS2, te opisujemo kako naša GRC usluga pomaže instituciji da sve to poveže u koherentan sustav.

Što je DORA i koga obvezuje u Hrvatskoj

DORA je uredba, a ne direktiva. Razlika je važna. Uredba se primjenjuje izravno, bez potrebe za prenošenjem u nacionalni zakon. To znači da hrvatske institucije ne čekaju domaći propis nego primjenjuju tekst uredbe onakav kakav jest, uz delegirane i provedbene akte Europske komisije koji razrađuju tehničke detalje. Cilj uredbe je osigurati da financijski sektor izdrži ozbiljne poremećaje u radu informacijskih sustava, bilo da ih izazove kibernetički napad, kvar pružatelja usluga ili interna pogreška.

Krug obveznika je širok i obuhvaća gotovo cijeli financijski sektor. Mnoge institucije podcjenjuju da ih uredba uopće dotiče, pa kasne s pripremom.

• Kreditne institucije, odnosno banke, koje u Hrvatskoj nadzire Hrvatska narodna banka, čine prvu i najregulisaniju skupinu obveznika.
• Platne institucije i institucije za elektronički novac također ulaze u okvir DORA-e i moraju dokazati istu razinu operativne otpornosti kao i veće banke.
• Društva za osiguranje i reosiguranje te posrednici u osiguranju koje nadzire Hanfa moraju uskladiti svoje IKT procese s odredbama uredbe.
• Investicijska društva, društva za upravljanje fondovima i pružatelji usluga povezanih s kriptoimovinom pripadaju širem krugu financijskih subjekata na koje se DORA odnosi.
• Pružatelji IKT usluga koji posluju s financijskim institucijama, posebno oni označeni kao kritični, podliježu nadzoru i ugovornim zahtjevima koje propisuje uredba.

Pet stupova DORA-e koje regulator provjerava

Uredba je strukturirana oko pet glavnih područja. Kad regulator dolazi u nadzor ili traži dokumentaciju, pitanja gotovo uvijek slijede ovu podjelu. Razumijevanje strukture pomaže instituciji da organizira svoj program i da ne propusti nijedan dio.

Okvir upravljanja IKT rizicima u praksi

Prvi i najopsežniji zahtjev je uspostava okvira upravljanja rizicima IKT. Regulator ne traži samo da imate dokument nego da taj dokument živi. To znači da postoji odobrenje uprave, da su uloge dodijeljene konkretnim osobama i da se okvir redovito preispituje. Okvir mora pokrivati identifikaciju kritičnih funkcija, klasifikaciju informacijske imovine, zaštitne mjere, otkrivanje anomalija, odgovor na incidente i oporavak.

U praksi institucije koje već imaju uspostavljen sustav upravljanja informacijskom sigurnošću prema normi ISO 27001 imaju veliku prednost. Mnoge kontrole koje DORA traži već postoje u 93 kontrole iz Priloga A norme ISO/IEC 27001:2022, raspoređene u četiri teme: organizacijske, ljudske, fizičke i tehnološke. Ne postoji potpuno preslikavanje, ali postoji znatno preklapanje. Mi tu poveznicu mapiramo eksplicitno, da institucija ne radi isti posao dvaput.

DORA ne traži savršen sustav. Traži sustav koji znate dokazati, testirati i popraviti kad zataji.

Prijava incidenata i propisani rokovi

Drugi stup je upravljanje incidentima. DORA propisuje da institucija mora otkriti, klasificirati i upravljati incidentima povezanim s IKT, te da značajne incidente mora prijaviti nadležnom regulatoru. Provedbeni akti definiraju kriterije značajnosti i rokove. Inicijalna obavijest dolazi vrlo brzo nakon klasifikacije incidenta kao značajnog, nakon čega slijede međuizvješće i konačno izvješće. Rokovi su kratki i institucija koja nema unaprijed pripremljen postupak gotovo sigurno kasni.

Najveći problem koji vidimo nije tehnička sposobnost otkrivanja nego nedostatak jasnog postupka odlučivanja. Kad incident udari, netko mora odlučiti je li značajan, tko sastavlja izvješće i tko ga šalje. Te odgovornosti moraju biti definirane prije incidenta, ne tijekom njega. Naša usluga otkrivanja prijetnji i odgovora pomaže instituciji da uspostavi praćenje, klasifikaciju i postupke koji se uklapaju u rokove iz uredbe.

Testiranje otpornosti: od procjene ranjivosti do TLPT

Treći stup je vjerojatno najzanimljiviji tehničkim timovima jer od riječi prelazi na djela. DORA traži redovit program testiranja digitalne operativne otpornosti. Osnovna razina obuhvaća alate i tehnike koje koristi većina institucija: skeniranje, procjenu ranjivosti, testove scenarija, provjere fizičke sigurnosti i penetracijsko testiranje. Za to je korisno razumjeti razliku između procjene ranjivosti i penetracijskog testiranja jer uredba implicira oba pristupa, a oni nisu zamjenjivi.

Najzahtjevniji subjekti, oni čiji bi prekid rada ozbiljno utjecao na financijski sustav, moraju provoditi napredno testiranje vođeno prijetnjama, poznato kao TLPT, threat-led penetration testing. To je strukturiran oblik Red Team angažmana koji oponaša stvarne napadače na temelju obavještajnih podataka o prijetnjama. TLPT se provodi prema metodologiji TIBER-EU i obuhvaća produkcijske sustave, što ga čini znatno složenijim od standardnog penetracijskog testiranja.

• Procjena ranjivosti daje širok pregled poznatih slabosti u sustavu i obično se provodi automatiziranim alatima uz ručnu provjeru rezultata.
• Penetracijsko testiranje ide korak dalje i aktivno iskorištava ranjivosti da pokaže stvarni utjecaj, što je opisano u tekstu o tome što je penetracijsko testiranje.
• TLPT oponaša ciljanog napadača nad produkcijskim okruženjem i zahtijeva uključivanje obavještajnih podataka o prijetnjama te koordinaciju s regulatorom.
• Testiranje aplikacija pokriva web sučelja i API-je prema metodologiji OWASP, što je posebno važno za institucije koje nude digitalne kanale.
• Testovi scenarija i vježbe oporavka provjeravaju mogu li ljudi i procesi izdržati stvaran poremećaj, ne samo tehnologija.

Naš pristup ofenzivnom testiranju opisujemo na stranici ofenzivne sigurnosti, a testiranje aplikacija i API-ja na stranici sigurnosti aplikacija. Otkrivamo sigurnosne propuste prije napadača, što je upravo ono što uredba želi postići.

Upravljanje rizikom trećih strana i registar pružatelja

Četvrti stup mnoge institucije iznenadi opsegom. DORA traži potpun registar svih ugovornih aranžmana s pružateljima IKT usluga. To ne znači samo velike cloud pružatelje nego svakog dobavljača koji pruža IKT uslugu, uključujući manje partnere. Registar mora sadržavati propisane podatke i institucija ga mora moći dostaviti regulatoru na zahtjev. Hanfa i HNB već prikupljaju ove registre od obveznika.

Osim registra, ugovori moraju sadržavati određene odredbe. To uključuje pravo na pristup i reviziju, jasne razine usluge, planove izlaska i pravila o podugovaranju. Kod kritičnih pružatelja IKT usluga uredba uvodi i izravan europski nadzor. Institucija koja je sav svoj IKT prepustila vanjskim partnerima ne može tu odgovornost prebaciti. Ona ostaje odgovorna za rizik, čak i kad uslugu obavlja netko drugi.

• Registar mora obuhvatiti sve pružatelje IKT usluga, a ne samo one koje institucija subjektivno smatra važnima.
• Ugovori moraju izričito predvidjeti pravo institucije i regulatora na pristup, inspekciju i reviziju pružatelja.
• Za funkcije koje podupiru kritične ili važne funkcije ugovori moraju sadržavati planove izlaska i strategije zamjene pružatelja.
• Institucija mora procijeniti koncentracijski rizik kad više kritičnih funkcija ovisi o istom pružatelju usluga.
• Podaci iz registra moraju biti ažurni jer regulator očekuje da odražavaju stvarno stanje, a ne zatečeno stanje od prije godinu dana.

Odgovornost uprave: zašto regulator gleda na vrh

DORA jasno stavlja krajnju odgovornost na upravljačko tijelo. To je možda najveći pomak u odnosu na raniju praksu. Uprava mora odobriti okvir upravljanja IKT rizicima, razumjeti izloženost institucije i osigurati dovoljno sredstava. Nije dovoljno da uprava jednom godišnje primi prezentaciju. Regulator očekuje da članovi uprave imaju dovoljno znanja da postavljaju prava pitanja i donose informirane odluke.

U praksi to znači redovito izvještavanje, dokumentirane odluke i program edukacije za upravu i zaposlenike. Kad regulator pita tko je odgovoran za IKT rizik, odgovor mora voditi prema vrhu organizacije, ne prema jednom inženjeru u podrumu. Ova odgovornost se ne može delegirati pružatelju usluga niti vanjskom savjetniku.

Kako se DORA odnosi prema NIS2 i ZKS-u

Hrvatske institucije često se pitaju moraju li ispunjavati i DORA-u i NIS2. Odgovor ovisi o sektoru. NIS2, Direktiva (EU) 2022/2555, je opći okvir za kibernetičku sigurnost u širokom rasponu sektora, a u Hrvatskoj je prenesena kroz Zakon o kibernetičkoj sigurnosti. DORA je sektorski propis za financije i kao lex specialis ima prednost za područja koja uređuje. To znači da financijska institucija primarno slijedi DORA-u za IKT rizike, a NIS2 za nju ima ograničenu izravnu primjenu.

U praksi se okviri preklapaju u temeljnim načelima: upravljanje rizicima, prijava incidenata i odgovornost uprave. Detaljnije o domaćem kontekstu pišemo u tekstu o NIS2 i Zakonu o kibernetičkoj sigurnosti. Institucija koja gradi jedan koherentan sustav, a ne odvojene silose za svaki propis, štedi vrijeme i smanjuje rizik proturječnih kontrola. Detalje DORA usklađenosti razrađujemo i na stranici posvećenoj DORA okviru.

Tipične pogreške i znakovi upozorenja

Tijekom priprema za DORA-u susrećemo iste pogreške iznova. Većina ih ne proizlazi iz nedostatka tehničke vještine nego iz pogrešnog poimanja što uredba zapravo traži. Tablica koja stoji u ormaru ne pomaže kad regulator zatraži dokaz da okvir funkcionira u stvarnom radu.

• Institucija tretira DORA-u kao jednokratan projekt usklađenja umjesto kao trajan program koji se preispituje i ažurira.
• Registar pružatelja IKT usluga je nepotpun ili zastario jer ga nitko ne održava nakon prve izrade.
• Postupak prijave incidenata postoji na papiru ali nije uvježban, pa institucija ne stigne u propisane rokove kad incident stvarno udari.
• Program testiranja se svodi na jedno godišnje skeniranje bez penetracijskog testiranja ili testova scenarija koje uredba podrazumijeva.
• Uprava nije stvarno uključena nego samo formalno potpisuje dokumente koje ne razumije, što regulator brzo prepozna kroz pitanja.
• Institucija kupuje generičke predloške bez prilagodbe vlastitom poslovanju, pa dokumentacija ne odražava stvarne procese i sustave.

Koliko traje i koliko košta priprema

Trošak i trajanje ovise o tome gdje institucija počinje. Banka koja već ima zreo sustav upravljanja informacijskom sigurnošću i certifikat prema ISO 27001 može uskladiti se s DORA-om za nekoliko mjeseci, fokusirajući se na praznine. Manja platna institucija koja kreće gotovo od nule treba više vremena, tipično od šest do dvanaest mjeseci za uspostavu cijelog okvira, registra, postupaka i prvog ciklusa testiranja.

Najveći trošak nije dokumentacija nego testiranje i trajno održavanje. Penetracijsko testiranje, a za najveće subjekte TLPT, traži stručnjake i vrijeme. Naš savjet je da institucija ne gleda na to kao na trošak usklađenja nego kao na ulaganje u stvarnu otpornost. Ako niste sigurni odakle krenuti, koristan polazni okvir nudimo u tekstu kibernetička sigurnost, odakle krenuti.

Sljedeći korak

DORA nije prolazna obveza nego trajni okvir koji oblikuje kako financijske institucije upravljaju tehnološkim rizikom. Institucije koje na nju gledaju kao na priliku da urede svoje procese izlaze jače, a one koje je odgađaju riskiraju i regulatorne sankcije i stvarne incidente. Naš posao je da taj put učinimo jasnim i mjerljivim, od analize praznina do testiranja i trajnog održavanja okvira. Pogledajte našu GRC uslugu za potpunu sliku kako povezujemo upravljanje, rizik i usklađenost, a kad budete spremni za konkretan plan, dogovorite uvodni razgovor i zajedno ćemo odrediti opseg vašeg programa.