Kad uprava pita može li organizacija održati ključnu uslugu tijekom ransomware napada, odgovor ne smije biti skriven u nekoliko nepovezanih Excel tablica, zapisnika i e-poruka. Dobar primjer registra cyber rizika daje provjerljiv odgovor: koji je rizik prepoznat, tko je za njega odgovoran, koliko je izloženost ozbiljna, koje kontrole već postoje i što treba učiniti dalje.
Za subjekte obuhvaćene Zakonom o kibernetičkoj sigurnosti i NIS2 obvezama registar nije administrativna formalnost. On je radni zapis upravljanja rizicima koji povezuje poslovne usluge, informacijsku imovinu, sigurnosne mjere, odluke uprave i dokaze o provedbi. Ako taj lanac nije vidljiv, teško je dokazati da organizacija rizicima upravlja sustavno i razmjerno stvarnoj izloženosti.
Čemu služi registar cyber rizika
Registar cyber rizika pretvara općenitu zabrinutost, primjerice strah od prekida rada, krađe podataka ili kompromitacije dobavljača, u odluke kojima se može upravljati. Njegova je svrha usmjeriti ograničene ljude, vrijeme i proračun na rizike koji mogu najviše narušiti poslovanje, sigurnost korisnika, povjerljivost podataka ili regulatornu usklađenost.
Dobar registar zato nije popis svih tehničkih slabosti koje je skener pronašao. Ranjivost je jedan od mogućih uzroka. Rizik nastaje kada prijetnja može iskoristiti ranjivost i stvoriti poslovnu posljedicu. Neažurirani poslužitelj sam po sebi nije dovoljno jasan zapis za upravu. Jasniji zapis glasi da bi iskorištavanje kritične ranjivosti na poslužitelju za udaljeni pristup moglo prekinuti pružanje ključne usluge i dovesti do gubitka ili izloženosti podataka.
Takva formulacija omogućuje da vlasnik procesa, voditelj informatike, CISO, službenik za zaštitu podataka i uprava razgovaraju o istom problemu, ali iz svojih odgovornosti. Tehnički tim može zatvoriti ranjivost, poslovni vlasnik može procijeniti prihvatljiv prekid, a uprava može odlučiti hoće li prihvatiti preostali rizik ili financirati dodatne mjere.
Što mora sadržavati primjer registra cyber rizika
Korisni registar treba biti dovoljno detaljan za provedbu, ali ne toliko opterećen tehničkim pojedinostima da postane neupotrebljiv. Za svaki zapis potrebno je jasno odvojiti opis scenarija, procjenu izloženosti i plan postupanja.
Opis rizika počinje poslovnim učinkom
Najprije se navode poslovna usluga ili proces, povezana imovina te scenarij rizika. Imovina može biti aplikacija za naručivanje, sustav za obradu plaćanja, identitetska infrastruktura, podatkovna baza ili usluga vanjskog pružatelja. Scenarij treba sadržavati prijetnju, moguću slabost i posljedicu, a ne samo naziv prijetnje poput phishinga ili ransomwarea.
Zatim se evidentiraju postojeće kontrole. To mogu biti višefaktorska autentifikacija, segmentacija mreže, sigurnosne kopije, nadzor zapisa, upravljanje zakrpama, plan oporavka ili ugovorne obveze dobavljača. Uz naziv kontrole vrijedi zabilježiti dokaz njezine provedbe, primjerice izvješće o testiranju oporavka, zapis konfiguracije ili zapisnik o edukaciji zaposlenika.
Procjena mora razlikovati početni i preostali rizik
Početni ili inherentni rizik procjenjuje se prije uzimanja postojećih kontrola u obzir. Preostali rizik pokazuje izloženost nakon njihova djelovanja. Ta razlika je presudna: organizacija može imati ozbiljan scenarij, ali prihvatljiv preostali rizik ako su kontrole učinkovite i redovito provjerene. Obrnuto, postojanje sigurnosne politike ne smanjuje rizik ako se politika ne provodi ili za nju nema dokaza.
Jednostavna ljestvica od 1 do 5 za vjerojatnost i učinak često je dovoljna, pod uvjetom da su kriteriji unaprijed definirani. Učinak treba obuhvatiti kontinuitet poslovanja, povjerljivost, integritet, ugled, financijski učinak i regulatorne posljedice. Nije potrebno svaki put jednako vrednovati sva područja. Poremećaj rada hitne usluge ima drukčiju težinu od prekida pomoćnog internog alata.
| Polje registra | Primjer unosa | |—|—| | Naziv rizika | Ransomware prekida rad sustava za obradu zahtjeva | | Poslovna usluga | Obrada zahtjeva korisnika | | Imovina i ovisnosti | Virtualni poslužitelji, Active Directory, sigurnosne kopije, vanjski SOC | | Scenarij | Napadač kompromitira korisnički račun phishingom i širi se na poslužitelje | | Postojeće kontrole | MFA, EDR, segmentacija mreže, dnevne kopije, plan oporavka | | Inherentni rizik | Vjerojatnost 4, učinak 5, ukupno 20 | | Preostali rizik | Vjerojatnost 2, učinak 4, ukupno 8 | | Vlasnik rizika | Direktor informatike uz vlasnika poslovne usluge | | Plan postupanja | Testirati oporavak, ograničiti privilegirane račune, zatvoriti nalaze segmentacije | | Rok i status | 30. lipnja 2026., u provedbi | | Dokazi | Izvješće o testu oporavka, zapis EDR nadzora, zapisnik upravljačkog odbora |
Kako čitati konkretan primjer
Pretpostavimo da organizacija pruža uslugu koja ovisi o centralnom sustavu za obradu zahtjeva. Tijekom procjene utvrđeno je da zaposlenici imaju udaljeni pristup, dio administrativnih računa nije zaštićen dodatnim ograničenjima, a oporavak iz sigurnosnih kopija nije testiran u posljednjih dvanaest mjeseci.
Rizik se ne opisuje kao „loše sigurnosne kopije”. Precizniji zapis je: „Kompromitacija administratorskog računa može omogućiti šifriranje centralnih sustava, a nedokazana mogućnost oporavka može produljiti prekid ključne usluge.” Vjerojatnost može biti ocijenjena s 3 ili 4, ovisno o izloženosti računa, rezultatima testiranja i obavještajnim podacima o prijetnjama. Učinak je 5 ako bi prekid premašio prihvatljivo vrijeme oporavka ili ugrozio ugovorene i zakonske obveze.
Postojeći EDR i dnevne kopije mogu smanjiti početni rezultat, ali samo ako se njihova učinkovitost može dokazati. Plan postupanja tada nije općenita formulacija „povećati sigurnost”, nego mjerljiv skup aktivnosti: uvesti odvojene administrativne račune, provesti test vraćanja kritične usluge, dokumentirati rezultate i otkloniti utvrđena odstupanja. Svaka aktivnost dobiva vlasnika, rok, prioritet i status.
Bodovanje pomaže, ali ne smije zamijeniti prosudbu
Matrica rizika olakšava prioritizaciju, no brojčani rezultat nije objektivna istina. Rizik s rezultatom 10 može zaslužiti hitniji tretman od rizika s rezultatom 12 ako utječe na sigurnost pacijenata, regulatorno izvješćivanje ili uslugu koja nema prihvatljivu zamjenu. Zato pragovi prihvatljivosti trebaju biti usklađeni s poslovnim kontekstom i potvrđeni na odgovarajućoj upravljačkoj razini.
Posebnu pozornost zaslužuju povezani rizici. Prekid rada pružatelja usluge u oblaku, kompromitacija identitetskog sustava i nedostupnost sigurnosnih kopija mogu pojedinačno izgledati upravljivo, ali zajedno stvaraju scenarij ozbiljnog prekida. Registar treba omogućiti označavanje ovisnosti i grupiranje rizika prema usluzi, lokaciji, dobavljaču ili vrsti prijetnje.
Registar kao dokaz upravljanja za NIS2 obveze
U nadzoru nije dovoljno reći da organizacija provodi procjene rizika. Potrebno je pokazati metodologiju, datum procjene, sudionike, odluke, povezane mjere i dokaze da su mjere provedene. Registar zato treba imati povijest izmjena i jasnu vezu s evidencijom kontrola, nalaza, incidenata, planova kontinuiteta i izvješća za upravu.
Rizik treba ponovno procijeniti nakon značajne promjene: uvođenja novog dobavljača, migracije u oblak, spajanja organizacija, ozbiljnog incidenta, nalaza penetracijskog testiranja ili promjene ključne poslovne usluge. Godišnje ažuriranje bez provjere promjena rijetko daje stvarnu sliku izloženosti.
Odgovornost također mora biti razdvojena. Vlasnik rizika odgovara za poslovnu odluku i prihvaćanje preostalog rizika u okviru svojih ovlasti. Vlasnik kontrole odgovara za rad konkretne mjere. Tim za sigurnost ili usklađenost koordinira metodologiju, prati rokove i izvješćuje, ali ne može umjesto poslovnih vlasnika preuzeti odluke o riziku.
Od tablice do kontinuiranog upravljanja
Tablica može biti dobar početak za manji broj jasno omeđenih rizika. Problemi počinju kada je potrebno pratiti stotine dokaza, rokove korektivnih mjera, više procjenitelja i različite verzije dokumenata. Tada se lako izgubi veza između procjene, kontrole i stvarnog dokaza provedbe.
Platforma poput ITrevizija.hr može povezati AI vođenu procjenu usklađenosti, upravljanje dokazima, evidentiranje neusklađenosti i plan provedbe aktivnosti u jedinstven trag. Vrijednost nije u samoj automatizaciji, nego u tome da se svaka tvrdnja o usklađenosti i svaka odluka o riziku može brzo potkrijepiti dokumentiranim dokazom, uz kontrolu pristupa i zaštitu podataka.
Najčešća pogreška nije nedostatak zapisa, nego registar koji se ažurira tek pred reviziju. Registar postaje koristan kada se koristi na sastancima uprave, pri odobravanju projekata, u procjeni dobavljača i nakon incidenata. Tada više nije obrazac koji treba popuniti, već jasan mehanizam za donošenje sigurnosnih odluka prije nego što ih nametne stvarni događaj.