Kada nadzorno tijelo zatraži dokaz o upravljanju ICT rizikom, nije dovoljno pokazati pravilnik, zapisnik sa sastanka ili popis alata. Potrebno je dokazati da su ključne kontrole za DORA definirane, dodijeljene odgovornim osobama, redovito provedene i provjerljive. Upravo u toj razlici između formalne dokumentacije i operativno dokazane kontrole nastaje najveći regulatorni rizik.
DORA, odnosno Uredba o digitalnoj operativnoj otpornosti, financijskim subjektima postavlja očekivanje kontinuirane otpornosti, a ne jednokratne usklađenosti. Obveze se odnose na upravljanje ICT rizicima, prijavu ozbiljnih incidenata, testiranje digitalne operativne otpornosti te upravljanje rizicima koje stvaraju vanjski pružatelji ICT usluga. Kontrole zato moraju pokriti cijeli životni ciklus rizika – od identifikacije do korektivne aktivnosti i izvješćivanja uprave.
Ključne kontrole za DORA počinju odgovornošću uprave
DORA jasno postavlja upravljačko tijelo u središte odgovornosti za ICT rizik. To ne znači da uprava mora odobravati svaku promjenu konfiguracije ili pregledavati svaki sigurnosni zapis. Znači da mora razumjeti najvažnije digitalne rizike, odrediti prihvatljivu razinu rizika, osigurati resurse i donositi odluke na temelju redovitih, vjerodostojnih izvješća.
Prva kontrola stoga nije tehnička, nego upravljačka: formalno utvrđen okvir upravljanja ICT rizicima. Taj okvir treba odrediti tko odlučuje o rizicima, tko ih prati, kome se i kada eskaliraju incidenti te kako se nadzire provedba korektivnih mjera. CISO, voditelj IT-a, vlasnici poslovnih procesa, funkcija rizika, usklađenost i interna revizija moraju imati jasno razdvojene uloge.
U praksi su najkorisnija kratka periodična izvješća za upravu. Ona trebaju prikazati otvorene kritične rizike, ozbiljne incidente, status ranjivosti, rezultate testiranja oporavka, ovisnosti o ključnim dobavljačima i kašnjenja u akcijskom planu. Izvješće koje navodi samo da je sigurnost pod kontrolom ne daje upravi osnovu za donošenje odluka niti predstavlja dostatan revizijski dokaz.
Inventar imovine i procjena ICT rizika
Organizacija ne može zaštititi ono što nije identificirala. Potpun i održavan inventar informacijskih resursa jedna je od temeljnih kontrola: aplikacija, poslužitelja, krajnjih uređaja, mrežnih komponenti, podatkovnih spremišta, cloud usluga, integracija, korisničkih računa i vanjskih pružatelja usluga.
Inventar mora biti povezan s poslovnim funkcijama. Za svaki kritični sustav trebalo bi biti jasno tko mu je vlasnik, koje podatke obrađuje, koje poslovne procese podržava, gdje se nalazi, o kojim dobavljačima ovisi te kakve bi posljedice nastale u slučaju nedostupnosti, kompromitacije ili izmjene podataka. Sam popis uređaja bez poslovnog konteksta ne omogućuje stvarno upravljanje rizikom.
Procjena ICT rizika treba biti periodična, ali i aktivirana promjenama. Uvođenje novog sustava, migracija u cloud, spajanje s vanjskom platformom, promjena ključnog dobavljača ili pojava ozbiljne ranjivosti mogu promijeniti razinu rizika prije sljedećeg planiranog ciklusa procjene. Zato je korisno povezati upravljanje promjenama s obvezom procjene sigurnosnog i regulatornog učinka.
Rizik se ne uklanja uvijek istom mjerom. Ponekad je potrebno uvesti dodatnu kontrolu, ponekad ugovorom prenijeti dio obveza na dobavljača, a ponekad svjesno prihvatiti preostali rizik uz formalno odobrenje. Bitno je da odluka bude dokumentirana, obrazložena i vezana uz konkretnog vlasnika rizika i rok preispitivanja.
Kontrole pristupa, promjena i ranjivosti
Najveći broj sigurnosnih propusta i dalje se povezuje s neadekvatnim pristupima, nepravodobnim zakrpama i promjenama koje nisu dovoljno nadzirane. DORA ne propisuje jednu tehnologiju za sve subjekte, ali očekuje kontrole koje su primjerene kritičnosti sustava i stvarnom profilu rizika.
Upravljanje identitetima i pristupima treba obuhvatiti jedinstvenu dodjelu korisničkih računa, višefaktorsku autentifikaciju tamo gdje je rizik povišen, redovitu reviziju prava pristupa te brzo ukidanje pristupa zaposlenicima i vanjskim suradnicima koji više nemaju poslovnu potrebu. Posebnu pozornost zahtijevaju privilegirani računi, servisni računi i administratorski pristupi. Oni trebaju biti ograničeni, evidentirani i podložni pojačanom nadzoru.
Kontrola promjena mora odgovoriti na jednostavno pitanje: može li organizacija dokazati tko je, kada, zašto i uz čije odobrenje izmijenio kritični sustav? Za manje promjene dovoljan je proporcionalan proces, dok promjene koje utječu na kritične ili važne funkcije zahtijevaju procjenu utjecaja, testiranje, plan povratka na prethodno stanje i evidentirano odobrenje.
Upravljanje ranjivostima nije isto što i povremeno skeniranje mreže. Potrebni su redovito otkrivanje ranjivosti, procjena njihove ozbiljnosti u vlastitom okruženju, definirani rokovi otklanjanja, kontrola iznimaka i dokaz da je mjera provedena. Kritična ranjivost na sustavu izloženom internetu zahtijeva drukčiji tretman od ranjivosti u izoliranom testnom okruženju. Prioritet mora proizlaziti iz kombinacije tehničke ozbiljnosti i poslovnog učinka.
Incidenti, zapisnici i prijavljivanje
Kvaliteta odgovora na incident mjeri se prije incidenta. Organizacija mora unaprijed znati kako će prepoznati događaj, tko će procijeniti njegovu važnost, kada se aktivira krizni tim, kako se čuvaju dokazi i tko vodi komunikaciju prema upravi, klijentima, partnerima i nadležnim tijelima.
Ključna kontrola je klasifikacija događaja i incidenata prema unaprijed odobrenim kriterijima. Bez nje svaka procjena postaje improvizacija, osobito kada je potrebno odlučiti predstavlja li incident ozbiljan događaj koji podliježe regulatornom izvješćivanju. Kriteriji trebaju obuhvatiti trajanje prekida, broj pogođenih korisnika, zahvaćene kritične usluge, financijski učinak, kompromitaciju podataka i mogući reputacijski učinak.
Dnevnici aktivnosti, nadzor sigurnosnih događaja i zaštita zapisa od neovlaštene izmjene daju temelj za otkrivanje i istragu. No prikupljanje velikog broja logova bez definiranog nadzora samo povećava trošak. Potrebno je odrediti koje sustave treba nadzirati prioritetno, koje alarme treba eskalirati i koliko dugo se relevantni zapisi čuvaju.
Nakon svakog značajnijeg incidenta slijedi analiza uzroka, procjena učinka i korektivni plan. Zatvaranje incidenta bez evidentirane pouke i provjere provedbe mjera ostavlja otvoren rizik da se isti propust ponovi.
Oporavak poslovanja mora biti testiran, ne pretpostavljen
Sigurnosna kopija nije dokaz oporavka. DORA traži da financijski subjekt može održati ili obnoviti kritične funkcije unutar definiranih ciljeva. To zahtijeva usklađene planove kontinuiteta poslovanja, planove oporavka ICT sustava, komunikacijske scenarije i redovita testiranja.
Za svaku kritičnu funkciju treba definirati prihvatljivo vrijeme oporavka i maksimalni prihvatljivi gubitak podataka. Ti ciljevi moraju biti realni u odnosu na ugovorene usluge, arhitekturu sustava, raspoložive resurse i očekivanja poslovanja. Ako organizacija obećava oporavak u četiri sata, ali test vraćanja podataka traje dva dana, riječ je o neusklađenosti koju treba otvoreno evidentirati i riješiti.
Testiranje oporavka treba dokazati više od dostupnosti pričuvne kopije. Potrebno je potvrditi da se podaci mogu vratiti, da su aplikacije funkcionalne, da korisnici mogu raditi i da vanjske integracije ponovno rade očekivano. U određenim okruženjima dovoljno je ciljano tehničko testiranje, dok kritične funkcije mogu zahtijevati složenije scenarije prekida i uključivanje poslovnih timova.
Treće strane su dio vlastite razine otpornosti
Korištenje clouda, SaaS rješenja, upravljanih sigurnosnih usluga i vanjskih razvojnih timova ne prenosi regulatornu odgovornost s financijskog subjekta na dobavljača. DORA zato traži discipliniran pristup upravljanju ICT rizikom trećih strana.
Organizacija treba imati registar ugovora i pružatelja ICT usluga, procijeniti njihovu kritičnost te utvrditi koncentracijski rizik. Poseban problem nastaje kada više ključnih procesa ovisi o istom dobavljaču ili istoj infrastrukturi, iako se ta ovisnost na prvi pogled ne vidi. Primjerice, različite poslovne aplikacije mogu dijeliti istog cloud pružatelja, identitetsku platformu ili komunikacijsku uslugu.
Ugovori trebaju sadržavati zahtjeve za sigurnost, dostupnost, prijavu incidenata, prava nadzora, zaštitu podataka, podugovaranje, lokaciju obrade podataka i podršku pri izlasku iz usluge. Izlazna strategija ne mora značiti trenutačnu mogućnost zamjene svakog dobavljača, ali mora pokazati kako će organizacija održati kritičnu funkciju ako se odnos prekine ili pružatelj više ne može ispunjavati ugovorene obveze.
Dokazivost pretvara kontrolu u regulatornu spremnost
Najčešći operativni problem nije potpuni izostanak kontrola, nego fragmentirani dokazi. Zapisnici su u e-pošti, procjene rizika u tablicama, ugovori u zasebnim repozitorijima, a tehnički izvještaji kod različitih timova. Kada započne nadzor ili interna revizija, organizacija tada troši vrijeme na ručno povezivanje sadržaja koji je već postojao.
Učinkovit model povezuje svaki regulatorni zahtjev s kontrolom, vlasnikom, dokazom, statusom procjene i planom korektivnih aktivnosti. Tako se neusklađenost ne bilježi samo kao problem, nego kao upravljiv zadatak s rokovima, odgovornim osobama i tragom provedbe. Platforme poput ITrevizija.hr mogu ubrzati taj posao AI analizom dokumentacije, upravljanjem dokazima i automatiziranim izvješćivanjem, uz kontrolu pristupa i zaštitu osjetljivih podataka.
Najbolji trenutak za provjeru ključnih kontrola za DORA nije neposredno prije nadzora. Kontrola koja se prati kroz redovit rad, uz jasne dokaze i pravodobno zatvaranje odstupanja, organizaciji daje ono što DORA stvarno traži: sposobnost da upravlja digitalnim poremećajima kada se oni stvarno dogode.