Financijski subjekt ne smije procjenu ICT dobavljača svesti na upitnik koji se popuni prije potpisa ugovora i zatim odloži u arhivu. Dobar primjer DORA procjene dobavljača povezuje poslovnu važnost usluge, rizike za kontinuitet poslovanja, sigurnosne dokaze, ugovorne obveze i odluku odgovorne osobe. Cilj nije dokazati da dobavljač nema rizika, nego utvrditi jesu li rizici razumljivi, prihvatljivi i pod kontrolom prije ugovaranja te tijekom cijelog odnosa.
Uredba (EU) 2022/2554 o digitalnoj operativnoj otpornosti, poznata kao DORA, primjenjuje se od 17. siječnja 2025. na financijske subjekte iz njezina područja primjene. DORA je uredba EU-a koja se izravno primjenjuje, dok hrvatski Zakon o kibernetičkoj sigurnosti i njegova Uredba uređuju zaseban nacionalni okvir. Organizacija koja podliježe obama režimima treba uskladiti procese i dokaze gdje se zahtjevi preklapaju, ali ne smije pretpostaviti da jedna procjena automatski ispunjava sve obveze drugog propisa.
Što DORA traži prije ugovaranja ICT usluge
Članak 28. DORA-e zahtijeva upravljanje rizikom povezanima s ICT uslugama koje pružaju treće strane. Financijski subjekt ostaje potpuno odgovoran za ispunjavanje regulatornih obveza i kada dio aktivnosti povjeri vanjskom pružatelju usluge. Članak 29. posebno traži da subjekt prije sklapanja ugovora procijeni podržava li ICT usluga kritičnu ili važnu funkciju, procijeni relevantne rizike i provede odgovarajuću dubinsku analizu potencijalnog pružatelja.
Prvi korak stoga nije slanje sigurnosnog upitnika, nego klasifikacija usluge. Usluga može biti operativno korisna, ali ne mora podržavati kritičnu ili važnu funkciju. S druge strane, naizgled standardna usluga za upravljanje identitetima, obradu platnih naloga, čuvanje podataka ili nadzor transakcija može imati izravan učinak na pružanje financijske usluge, kontinuitet poslovanja, povjerljivost podataka ili regulatorno izvještavanje.
Klasifikacija mora biti obrazložena i povezana s analizom poslovnog učinka. Ako je funkcija označena kao kritična ili važna, očekivana dubina procjene, ugovornih zaštita, plana izlaska i kontinuiranog nadzora bit će veća. DORA ne propisuje jedinstveni obrazac upitnika ni univerzalni prag bodovanja. To su organizacijski alati koji moraju biti razmjerni riziku.
Primjer DORA procjene dobavljača u praksi
Zamislimo kreditnu instituciju koja želi ugovoriti SaaS rješenje za praćenje sumnjivih transakcija. Rješenje obrađuje podatke o klijentima i transakcijama, stvara upozorenja za stručne timove te se integrira s ključnim internim sustavima. Prekid usluge dulji od jednog radnog dana mogao bi znatno usporiti obvezne kontrole i povećati operativni i usklađenosni rizik.
Procjenom poslovnog učinka institucija zaključuje da usluga podržava važnu funkciju. Zaključak ne proizlazi samo iz naziva proizvoda ili vrijednosti ugovora, nego iz ovisnosti procesa o usluzi, vrste podataka, dopuštenog vremena prekida, mogućnosti ručnog rada i posljedica nedostupnosti. Vlasnik poslovnog procesa, informacijska sigurnost, nabava, pravna služba, rizici i usklađenost trebaju sudjelovati u procjeni, uz jasno određenog vlasnika odluke.
| Područje procjene | Pitanje za dobavljača | Primjer prihvatljivog dokaza | Rizik ako dokaz nedostaje | |—|—|—|—| | Uloga usluge | Koje poslovne procese i podatke usluga podržava? | Opis arhitekture, tokovi podataka, popis integracija | Pogrešna klasifikacija funkcije | | Sigurnosne kontrole | Kako se upravlja pristupima, enkripcijom i ranjivostima? | Politike, zapisi o pregledima pristupa, neovisna izvješća o kontrolama | Neprimjeren pristup ili gubitak podataka | | Kontinuitet | Koliko brzo se usluga oporavlja nakon prekida? | Plan kontinuiteta, ciljevi oporavka, rezultati testiranja | Nedokazana sposobnost oporavka | | Lokacija i podugovaratelji | Gdje se obrađuju podaci i tko sudjeluje u isporuci? | Popis lokacija, podugovaratelja i njihovih uloga | Nepregledan lanac ovisnosti | | Izlazna strategija | Kako se prenose podaci i održava usluga pri izlasku? | Plan prijenosa, format izvoza, procjena troška i rokova | Zaključanost kod dobavljača |
U praksi je korisno odvojiti inherentni rizik od rezidualnog rizika. Inherentni rizik u ovom je primjeru visok zbog osjetljivosti podataka, povezanosti s ključnim sustavima i utjecaja prekida rada. Nakon pregleda kontrola i ugovornih odredbi rezidualni rizik može biti srednji, ali samo ako su kontrolne mjere stvarno provjerene i ako je preostali rizik formalno prihvaćen na odgovarajućoj razini upravljanja.
Primjer bodovanja i odluke
Institucija može koristiti ljestvicu od 1 do 5 za pojedino područje, pri čemu 1 označava zadovoljavajuće stanje, a 5 neprihvatljiv rizik. Međutim, prosjek bodova ne smije prikriti kritični nedostatak. Dobavljač može imati dobar ukupni rezultat, ali ako ne dopušta potrebna prava pristupa, revizije i nadzora ili nema izvediv izlazni plan, ugovor se ne bi smio odobriti bez otklanjanja tog nedostatka.
U navedenom primjeru dobavljač dostavlja izvješće neovisne provjere kontrola, opis enkripcije i rezultate godišnjeg testiranja kontinuiteta. Istodobno ne daje dovoljno precizan popis podugovaratelja koji sudjeluju u obradi podataka. Odluka može biti uvjetno odobrenje: ugovor se sklapa tek nakon dopune popisa, procjene utjecaja relevantnih podugovaratelja i ugradnje obveze prethodne obavijesti o bitnim promjenama lanca pružanja usluge.
To je kvalitetnija odluka od pukog odgovora „dobavljač je usklađen”. Procjena mora pokazati što je pregledano, što nije dokazano, tko prihvaća preostali rizik, koje su korektivne mjere, rokovi i posljedice njihova neizvršenja.
Ugovor nije zamjena za procjenu
Članak 30. DORA-e uređuje ključne ugovorne elemente za korištenje ICT usluga. Opseg obveza ovisi o vrsti usluge i njezinoj kritičnosti, ali ugovor u pravilu mora jasno urediti opis usluge, lokacije obrade, zaštitu podataka, razine usluge, prijavu i pomoć pri incidentima, kontinuitet, raskid te prava pristupa, inspekcije i revizije.
Česta pogreška je prihvatiti dobavljačev standardni ugovor bez usporedbe s rezultatima procjene. Ako procjena pokaže da je oporavak ključan unutar četiri sata, a ugovor ne definira mjerljive ciljeve oporavka ni obvezu testiranja, pravni dokument ne prati stvarni poslovni rizik. Jednako tako, široko formulirano pravo revizije bez praktične mogućnosti dobivanja dokaza možda neće biti dovoljno za nadzor usluge.
Kod složenijih odnosa posebno treba obraditi podugovaranje. Financijski subjekt mora razumjeti koristi li dobavljač infrastrukturnog pružatelja, specijalizirani sigurnosni servis ili druge podizvršitelje te kako promjene u tom lancu utječu na sigurnost, kontinuitet i mogućnost izlaska. Za ICT usluge koje podupiru kritične ili važne funkcije dodatno su relevantna detaljnija pravila o podugovaranju iz Delegirane uredbe Komisije (EU) 2025/532.
Dokazi koje treba sačuvati za nadzor i reviziju
Revizijski trag mora omogućiti neovisnoj osobi da razumije zašto je dobavljač odabran i kako se rizik nadzire. Osnovni paket dokumentacije čine klasifikacija usluge, analiza poslovnog učinka, popunjena procjena, priloženi dokazi, zapis o provjerama, procjena rizika, odluka nadležne razine upravljanja, ugovor i plan korektivnih mjera.
DORA također zahtijeva vođenje registra informacija o ugovornim aranžmanima s ICT pružateljima usluga. Registar nije samo popis dobavljača. Trebao bi omogućiti pregled ovisnosti, usluga, funkcija koje se podupiru, lokacija i povezanih ugovornih odnosa. Zato podaci prikupljeni tijekom inicijalne procjene trebaju biti strukturirani tako da se mogu ponovno koristiti za registar, periodične preglede i izvještavanje nadležnom tijelu kada je to potrebno.
Automatizirana platforma može smanjiti ručni rad tako da povezuje pitanja procjene s dokazima, bilježi nedostatke, dodjeljuje vlasnike mjera i čuva slijed od zahtjeva do odluke. No automatizacija ne može sama utvrditi je li poslovna funkcija kritična niti može preuzeti odgovornost upravljačkog tijela. Vrijednost alata je u dosljednosti, sljedivosti i pravodobnom praćenju otvorenih obveza.
Kontinuirani nadzor nakon odobrenja
Procjena prije ugovaranja je početna točka. DORA pristup traži kontinuirano praćenje ICT rizika trećih strana, osobito ako se mijenja opseg usluge, arhitektura, lokacija podataka, podugovaratelj ili profil prijetnji. U primjeru SaaS usluge institucija bi najmanje jednom godišnje, a prema riziku i češće, trebala pregledati rezultate kontrola, incidente, dostupnost, promjene podugovaratelja, provedbu korektivnih mjera i izvedivost izlazne strategije.
Najkorisniji primjer procjene nije onaj s najviše pitanja, nego onaj koji svaku tvrdnju veže uz provjerljiv dokaz, vlasnika rizika i konkretnu odluku. Kada se pojavi promjena kod dobavljača ili potreba za revizijom, upravo će ta sljedivost odlučiti može li organizacija pokazati stvarnu kontrolu nad ovisnošću o ICT usluzi.