DORA apetit za IKT rizikom: vodič za odobrenje upravljačkog tijela za 2026.

Utorak je, 08:15, a CISO srednje velike tehnološke tvrtke za platne usluge stoji ispred dvorane za sastanke upravljačkog tijela s tri dokumenta otvorena na tabletu.

Prvi je registar IKT rizika. Ima 137 redaka, ocjene označene bojama i nekoliko visokih rizika povezanih s koncentracijom u oblaku, pristupom s povišenim ovlastima, oporavkom od ransomwarea, izloženošću podataka klijenata i odgovorom dobavljača na incidente. Drugi je DORA alat za praćenje spremnosti. U njemu stoji da društvo ima politike, postupke za incidente, registre trećih strana i planove testiranja otpornosti. Treći je materijal za upravljačko tijelo pripremljen za regulatorni sastanak.

Predsjednik ima jedno pitanje, i ono nije tehničko:

„Koju smo razinu IKT rizika zapravo pristali prihvatiti?”

U prostoriji nastaje tišina jer društvo ima procjene rizika, ali nema apetit za IKT rizikom odobren na razini upravljačkog tijela. Ima ocjene utjecaja, ali nema mjerljive pragove tolerancije. Ima sastanke za eskalaciju, ali nema formalni okidač koji određuje kada kibernetički rizik postaje odluka upravljačkog tijela. Ima prihvaćene preostale rizike, ali neki su obrazloženi kao „poslovne odluke” bez jasne poveznice s kriterijima rizika, razmjernošću prema GDPR Article 32, očekivanjima tolerancije prema DORA-i ili odgovornošću uprave prema NIS2.

Taj je jaz u 2026. sve vidljiviji. DORA se primjenjuje od 17. siječnja 2025. i zahtijeva od financijskih subjekata održavanje okvira upravljanja i kontrola za IKT rizik, uključujući odgovornost upravljačkog tijela za okvir upravljanja IKT rizicima, strategiju digitalne operativne otpornosti i toleranciju IKT rizika. NIS2 zahtijeva da upravljačka tijela odobre mjere upravljanja kibernetičkim rizicima i nadziru njihovu provedbu. GDPR Article 32 zahtijeva odgovarajuće tehničke i organizacijske sigurnosne mjere utemeljene na riziku. ISO/IEC 27001:2022 daje mehaniku sustava upravljanja: kontekst, zainteresirane strane, kriterije rizika, planove obrade rizika, dokumentirane informacije i preispitivanje od strane uprave.

Nedostajući most jest izjava o apetitu za IKT rizikom i toleranciji koju upravljačko tijelo može razumjeti, odobriti, preispitivati i koristiti.

Ovaj vodič objašnjava kako izgraditi taj most koristeći Clarysecov Zenith Blueprint: revizorov plan puta u 30 koraka, Clarysecovu Politiku upravljanja rizicima, Clarysecovu Politiku upravljanja rizicima za MSP-ove i Zenith Controls: vodič za međusobnu usklađenost.

Zašto registri rizika nisu apetit za rizikom

Mnoge organizacije pogrešno poistovjećuju registar rizika s upravljanjem rizicima. Registar rizika pokazuje koji rizici postoje, kako su ocijenjeni, tko je njihov vlasnik i koja je obrada planirana. On ne odgovara automatski na pitanja na razini upravljačkog tijela koja DORA, NIS2, GDPR i ISO/IEC 27001:2022 očekuju da vodstvo razmotri.

Zrela izjava o apetitu za IKT rizikom odgovara na pitanja kao što su:

• Koji su IKT rizici neprihvatljivi bez obzira na trošak?
• Koji operativni prekid poslovanje može tolerirati za kritičnu ili važnu funkciju?
• Koja je razina gubitka podataka ili narušavanja cjelovitosti podataka izvan apetita?
• Koji rizik koncentracije trećih strana zahtijeva pažnju upravljačkog tijela?
• Tko smije prihvatiti preostali IKT rizik i na kojoj razini?
• Kada se rizik mora eskalirati višem rukovodstvu ili upravljačkom tijelu?
• Kako su pravni, regulatorni i ugovorni zahtjevi ugrađeni u kriterije rizika?

Prema DORA-i, to nije neobavezno dotjerivanje upravljanja. Article 5 zahtijeva da upravljačko tijelo definira, odobri, nadzire i bude odgovorno za okvir upravljanja IKT rizicima, uključujući strategiju digitalne operativne otpornosti i toleranciju IKT rizika. Article 6 zahtijeva dokumentirani okvir upravljanja IKT rizicima, godišnje preispitivanje za subjekte koji nisu mikropoduzeća, internu reviziju, otklanjanje kritičnih nalaza revizije i strategiju digitalne operativne otpornosti s IKT ciljevima, tolerancijom rizika, tolerancijom utjecaja, arhitekturom, testiranjem i strategijom komunikacije tijekom incidenata.

NIS2 dodaje paralelni model odgovornosti. Article 20 zahtijeva da upravljačka tijela ključnih i važnih subjekata odobre mjere upravljanja kibernetičkim rizicima, nadziru provedbu i pohađaju osposobljavanje. Article 21 zahtijeva odgovarajuće i razmjerne tehničke, operativne i organizacijske mjere na temelju pristupa koji obuhvaća sve prijetnje, uključujući analizu rizika, postupanje s incidentima, neprekidnost poslovanja, sigurnost opskrbnog lanca, siguran razvoj, djelotvornost kontrola, osposobljavanje, kriptografiju, sigurnost ljudskih resursa, kontrolu pristupa, upravljanje imovinom i MFA gdje je primjereno.

Za financijske subjekte DORA se smatra sektorskim pravnim aktom Unije kada se primjenjuju preklapajuće obveze iz NIS2. U praksi DORA općenito zamjenjuje preklapajuće zahtjeve NIS2 za upravljanje rizicima i prijavljivanje incidenata za financijske subjekte unutar svojeg područja primjene, dok NIS2 ostaje važan za koordinaciju i za pružatelje usluga izvan izravnih obveza financijskih subjekata prema DORA-i. Za SaaS, oblak, pružatelje upravljanih usluga i pružatelje upravljanih sigurnosnih usluga NIS2 se može izravno primjenjivati kada su ispunjeni uvjeti opsega.

Zato apetit za IKT rizikom odobren na razini upravljačkog tijela više nije artefakt financijskog rizika. To je kontrola upravljanja kibernetičkom sigurnošću.

Koristite ISO/IEC 27001:2022 kao operativni sustav

DORA i NIS2 govore vodstvu čime se mora upravljati. ISO/IEC 27001:2022 organizacijama daje praktičan operativni sustav za način upravljanja.

ISO/IEC 27001:2022 točke 4.1 do 4.4 zahtijevaju da organizacija definira kontekst, zainteresirane strane, zahtjeve, opseg ISMS-a i procese ISMS-a. To je važno jer DORA, NIS2, GDPR, ugovori, očekivanja nadzornih tijela, klijenti, pružatelji usluga u oblaku i aranžmani izdvajanja postaju zahtjevi koji utječu na kriterije rizika.

Točke 5.1 do 5.3 zahtijevaju predanost vodstva, usklađenost politike, resurse, odgovornosti i izvješćivanje najvišem rukovodstvu o učinkovitosti ISMS-a. Točke 6.1.1 do 6.1.3 zahtijevaju planiranje temeljeno na riziku, dokumentirani proces procjene rizika, kriterije prihvata rizika, dosljedne kriterije procjene, vlasnike rizika, usporedbu s kriterijima rizika, planiranje obrade rizika, Izjavu o primjenjivosti i odobrenje preostalog rizika.

To je temelj za DORA toleranciju IKT rizika.

U fazi upravljanja rizicima, korak 10 Zenith Blueprinta nalaže organizacijama da definiraju kriterije rizika prije ocjenjivanja rizika:

„Kriteriji rizika pravila su i mjerila koja vaša organizacija koristi za procjenu značajnosti svakog rizika. Uspostava tih kriterija unaprijed osigurava da svi govore istim jezikom rizika.”

Isti korak upozorava da se regulatorni utjecaj mora ugraditi u definicije rizika:

„Svaki rizik koji bi mogao dovesti do neusklađenosti s primjenjivim zakonima (GDPR itd.) nije prihvatljiv i mora se ublažiti.”

Zenith Blueprint daje i praktične smjernice za skaliranje utjecaja:

„Pri definiranju utjecaja preporučljivo je povezati razine s konkretnom poslovnom veličinom vaše organizacije. Na primjer, ‘značajan financijski utjecaj = gubitak > 100 tisuća USD’ (prilagodite svojem kontekstu). Uzmite u obzir i regulatorni utjecaj: primjerice, povreda osobnih podataka može automatski biti ‘značajna’ ili ’teška’ zbog GDPR kazni i zahtjeva za obavješćivanje, čak i ako je izravan financijski gubitak nejasan. Slično tome, ako ste u opsegu NIS2 (ključne usluge), incident koji uzrokuje prekid usluge može biti najmanje ‘značajan’ zbog pravnih posljedica. Uključite takva razmatranja u svoje definicije.”

Ta smjernica sprječava čest propust: ocjenjivanje kibernetičkog rizika kao umjerenog jer se neposredni financijski gubitak čini malim, uz zanemarivanje pravnog utjecaja, utjecaja na operativnu otpornost, utjecaja na ispitanike ili utjecaja na korisnike.

Model spreman za upravljačko tijelo trebao bi razdvojiti četiri sloja:

Ova struktura čini apetit za rizikom provjerljivim u reviziji jer se svaka izjava može povezati s kriterijima rizika, kontrolama, dokazima i odlukama.

Izjava o DORA apetitu za IKT rizikom spremna za upravljačko tijelo

Snažna izjava o apetitu za IKT rizikom dovoljno je kratka da je upravljačko tijelo može odobriti, dovoljno konkretna da je uprava može primijeniti i dovoljno mjerljiva da je revizori mogu testirati. Treba izbjegavati žargon, ali ne smije biti neodređena.

Praktična izjava visoke razine mogla bi glasiti:

„Naše društvo ima nizak apetit za IKT rizike koji bi mogli dovesti do značajne štete za klijente, prekida kritičnih ili važnih funkcija, neovlaštenog otkrivanja ili izmjene reguliranih podataka, neispunjavanja pravnih obveza ili gubitka otpornosti kritičnih IKT usluga trećih strana.”

Ta izjava zatim treba mjerljive pragove tolerancije i okidače eskalacije.

Ova tablica mijenja razgovor. Upravljačko tijelo više ne odobrava slogan. Odobrava operativne granice za dostupnost, povjerljivost, cjelovitost, dobavljače, ranjivosti, oporavak i usklađenost.

Clarysecova Politika upravljanja rizicima podržava ovaj model upravljanja. Politika za veće organizacije navodi:

„Odobrava okvir za upravljanje rizicima i definira prihvatljiv apetit za rizikom i pragove tolerancije.”

Točka 6.2.1 izričito uvodi zahtjev mjerenja:

„Rizici se moraju procjenjivati prema vjerojatnosti i utjecaju koristeći standardnu matricu rizika s jasno definiranim ljestvicama bodovanja.”

Točka 6.3.4 uspostavlja pravilo prihvaćanja koje će revizori očekivati:

„Rizici prihvaćeni bez obrade moraju biti pisano obrazloženi, povezani s apetitom organizacije za rizikom i odobreni na odgovarajućoj razini.”

Za mala i srednja poduzeća Politika upravljanja rizicima za MSP-ove zadržava isto načelo upravljanja u jednostavnijem obliku:

„Osigurati uključenost uprave u odobravanje tolerancije rizika i glavnih planova obrade rizika.”

Također zahtijeva eskalaciju visokih rizika:

„Visoki rizici moraju se eskalirati glavnom direktoru radi odluke.”

To je razmjernost u praksi. DORA Article 4 zahtijeva da se zahtjevi primjenjuju razmjerno veličini, profilu rizika te prirodi, opsegu i složenosti usluga. ISO/IEC 27001:2022 omogućuje isto načelo kroz opseg, kontekst, kriterije rizika i odluke o obradi rizika. Standard upravljanja nije da svaka organizacija mora imati istu strukturu odbora. Standard upravljanja jest da su apetit za rizikom, tolerancija, eskalacija i prihvaćanje definirani, odobreni, potkrijepljeni dokazima i primjenjivani.

GDPR Article 32 mijenja razgovor o riziku

GDPR Article 32 često se promatra kao tehnička sigurnosna odredba. U kontekstu upravljanja, to je i odredba o apetitu za rizikom.

Article 32 zahtijeva da voditelji obrade i izvršitelji obrade provedu odgovarajuće tehničke i organizacijske mjere kako bi osigurali razinu sigurnosti primjerenu riziku. Taj pristup temeljen na riziku uzima u obzir najnovija dostignuća, troškove provedbe, prirodu, opseg, kontekst i svrhe obrade te rizike za prava i slobode fizičkih osoba.

To utječe na apetit za IKT rizikom na tri načina.

Prvo, utjecaj na osobne podatke ne može se svesti na financijski gubitak. Izloženost male baze podataka može imati ograničen izravan trošak, ali ozbiljne posljedice za povjerljivost, identitet, prijevaru, diskriminaciju ili ostvarivanje prava. Ako su uključene posebne kategorije osobnih podataka, kao što su zdravstveni, biometrijski ili genetski podaci, apetit mora biti znatno niži.

Drugo, uloge u obradi moraju se povezati s vlasništvom nad rizikom. GDPR razlikuje voditelje obrade i izvršitelje obrade. DORA razlikuje financijske subjekte i pružatelje IKT usluga trećih strana. NIS2 razlikuje ključne i važne subjekte. ISO/IEC 27001:2022 zahtijeva vlasnike rizika. Zrela izjava o apetitu treba identificirati tko je vlasnik odluka o riziku koje uključuju osobne podatke, izdvojenu obradu, kritične usluge i prekogranične ovisnosti.

Treće, razmjernost iz Article 32 treba biti vidljiva u odabiru kontrola. Šifriranje, pseudonimizacija, kontrola pristupa, sigurnosno kopiranje, zapisivanje događaja, praćenje, odgovor na incidente i otpornost nisu izolirani tehnički zadaci. To su mjere obrade rizika odabrane zato što je rizik premašio apetit ili toleranciju.

Clarysecova Politika upravljanja rizicima to izričito povezuje:

„Article 32: nalaže pristup sigurnosnim mjerama temeljen na riziku, koji se ispunjava procjenama rizika temeljenima na utjecaju i odabirom kontrola.”

To je operativna poveznica koju revizori traže: zahtjev iz Article 32, procjena rizika, ocjena rizika, plan obrade rizika, odabir kontrola, preostali rizik i odobrenje.

Kako Zenith Controls podržava dokaze za međusobnu usklađenost

Izjava o apetitu koju je odobrilo upravljačko tijelo postaje snažna kada se mapira na kontrole. Zenith Controls djeluje kao Clarysecov vodič za međusobnu usklađenost i pomaže timovima ponovno koristiti dokaze kroz ISO/IEC 27001:2022, DORA, NIS2, GDPR, NIST CSF i osiguranje u stilu COBIT-a.

Tri kontrolna područja ISO/IEC 27002:2022 posebno su važna:

Ovo nije vježba mapiranja na papiru. Mijenja način donošenja odluka.

Ako vlasnik poslovanja zatraži prihvaćanje odgođenog uvođenja MFA za administratore, Zenith Controls pomaže CISO-u pokazati zašto to nije samo pitanje kontrole pristupa. Dotiče upravljanje politikama, odgovornost rukovodstva, pravne i regulatorne zahtjeve, sigurnost obrade prema GDPR-u, DORA upravljanje IKT rizicima, NIS2 mjere kibernetičke sigurnosti, utjecaj incidenta i revizijske dokaze.

Ako tim proizvoda želi lansirati uslugu na novom tržištu EU koristeći novu uslugu u oblaku, ISO/IEC 27002:2022 kontrola 5.31 uvodi pregled pravnih i regulatornih zahtjeva u opseg ISMS-a. ISO/IEC 27001:2022 točka 4.2 zahtijeva identificiranje zahtjeva zainteresiranih strana, uključujući pravne, regulatorne i ugovorne obveze. Točka 8.1 zahtijeva operativno planiranje i kontrolu, uključujući kontrolu eksterno osiguranih procesa, proizvoda ili usluga relevantnih za ISMS.

Cilj je jedan jezik rizika, a ne odvojeni dijalekti usklađenosti.

Tijek odobravanja: tko o čemu odlučuje

CISO može predložiti apetit za IKT rizikom, ali upravljačko tijelo mora ga preuzeti kao svoju odgovornost. To vlasništvo treba tijek odobravanja.

To je usklađeno i s NIST CSF 2.0. Funkcija GOVERN, osobito GV.RM, očekuje dogovorene ciljeve upravljanja rizicima, izjave o apetitu za rizikom i toleranciji, aktivnosti rizika integrirane u korporativno upravljanje rizicima, definirane mogućnosti odgovora na rizik, komunikacijske linije i standardizirane metode za izračun, dokumentiranje, kategorizaciju i prioritizaciju kibernetičkih rizika. GV.RR očekuje odgovornost vodstva, uloge, ovlasti i resurse usklađene sa strategijom rizika. GV.PO očekuje da politike budu uspostavljene, priopćene, provedene, pregledane i ažurirane.

COBIT 19 i stručnjaci za osiguranje u stilu ISACA-e pitat će je li apetit za rizikom integriran u korporativno upravljanje informacijama i tehnologijom, a ne samo priložen kao dodatak kibernetičkoj politici.

Izradite paket apetita za IKT rizikom u jednoj radnoj sesiji

Praktična radionica o apetitu za IKT rizikom može organizaciju premjestiti iz raspršenih registara u paket za upravljačko tijelo koji je provjerljiv u reviziji.

Korak 1: prikupite prave ulazne podatke

Pripremite aktualni registar IKT rizika, analizu utjecaja na poslovanje, ciljeve oporavka, popis kritičnih ili važnih funkcija, popis IKT imovine, popis IKT usluga, registar ovisnosti o dobavljačima i oblaku, kriterije klasifikacije incidenata, GDPR evidenciju aktivnosti obrade, DPIA-e gdje su relevantne, registar pravnih obveza, politike, Izjavu o primjenjivosti i postojeću izjavu o apetitu za rizikom na razini organizacije.

To je usklađeno s ISO/IEC 27001:2022 točkama 4, 6 i 8 te s metodama profila NIST CSF-a koje počinju od poslovnih prioriteta, prioriteta rizika, zahtjeva, zaštitnih mjera i uloga.

Korak 2: definirajte ljestvice utjecaja koje uključuju regulativu

Koristeći Zenith Blueprint korak 10, definirajte vjerojatnost i utjecaj poslovnim jezikom. Uključite financijski gubitak, operativni prekid, utjecaj na korisnike, reputacijsku štetu, pravni i regulatorni utjecaj, štetu za ispitanike i utjecaj na kritičnu funkciju.

Na primjer, „značajan” utjecaj može uključivati produljeni prekid kritične usluge, potvrđenu povredu osobnih podataka koja zahtijeva obavješćivanje, neispunjavanje DORA obveze prijavljivanja incidenta ili neuspjeh dobavljača koji utječe na kritičnu ili važnu funkciju.

Korak 3: napišite apetit po domenama

Nemojte stvarati jedan generički kibernetički apetit. Definirajte domene kao što su dostupnost kritičnih usluga, povjerljivost osobnih podataka, cjelovitost podataka, pristup s povišenim ovlastima, IKT ovisnost o trećim stranama, koncentracija u oblaku, izloženost ranjivostima, spremnost za prijavljivanje incidenata, sigurnosno kopiranje i oporavak te rizik promjena u sigurnom razvoju.

Za svaku domenu napišite jednu izjavu o apetitu, jedan ili više pragova tolerancije i okidače eskalacije.

Korak 4: povežite obradu rizika s Izjavom o primjenjivosti

Korak 13 Zenith Blueprinta nalaže organizacijama odabir opcija obrade rizika: ublažiti, izbjeći, prenijeti ili prihvatiti. Također naglašava odobrenje rukovodstva:

„Odluke o obradi rizika i SoA trebaju pregledati i odobriti najviše rukovodstvo.”

Za DORA i NIS2 to je dokaz da su upravljačko tijelo ili delegirano vodstvo pregledali ključne rizike, obrade rizika i prihvaćenu preostalu izloženost. Za GDPR podržava odgovornost pokazivanjem zašto su odabrane mjere bile primjerene riziku.

Korak 5: evidentirajte prihvaćanje s istekom i uvjetima

Svaki prihvaćeni srednji ili visoki preostali rizik treba uključivati:

• ID rizika i vlasnika
• Poslovno obrazloženje
• Referencu na izjavu o apetitu
• Zahvaćeni prag tolerancije
• Pravnu i regulatornu analizu
• Kompenzacijske kontrole
• Datum isteka ili pregleda
• Odobravatelja
• Lokaciju dokaza
• Okidač za ponovno otvaranje odluke

Politika upravljanja rizicima za MSP-ove navodi:

„Svaka odluka o prihvaćanju ili odgodi obrade visokog ili srednjeg rizika mora biti dokumentirana u registru rizika. Ta dokumentacija mora uključivati:”

U poslovnim okruženjima to postaje tijek odobravanja i paket za odbor za rizike. U manjim organizacijama to može biti strukturirana kartica registra rizika s odobrenjem uprave. Poanta nije birokracija. Poanta je dokazivost i obrazložljivost.

Tolerancija incidenta: gdje se apetit susreće sa satom

Apetit za rizikom postaje stvaran tijekom incidenata.

DORA Article 17 zahtijeva od financijskih subjekata uspostavu procesa upravljanja incidentima povezanima s IKT-om radi otkrivanja, upravljanja i obavješćivanja o incidentima, evidentiranja svih incidenata i značajnih kibernetičkih prijetnji, utvrđivanja temeljnih uzroka, korištenja pokazatelja ranog upozorenja, klasificiranja incidenata prema prioritetu, ozbiljnosti i kritičnosti usluge, dodjele uloga, komunikacije s dionicima, eskalacije barem značajnih incidenata povezanih s IKT-om višem rukovodstvu i upravljačkom tijelu te pravodobne obnove sigurnog rada.

DORA Article 18 klasificira incidente koristeći čimbenike kao što su pogođeni klijenti, trajanje, prekid rada, geografska rasprostranjenost, gubici podataka koji utječu na dostupnost, autentičnost, cjelovitost ili povjerljivost, kritičnost pogođenih usluga i ekonomski utjecaj. Article 19 zahtijeva prijavu značajnih incidenata povezanih s IKT-om nadležnom tijelu, uz informiranje klijenata kada su pogođeni njihovi financijski interesi.

NIS2 Article 23 ima fazno izvješćivanje za značajne incidente, uključujući rano upozorenje bez nepotrebnog odgađanja i, gdje je primjenjivo, u roku od 24 sata, obavijest o incidentu bez nepotrebnog odgađanja i, gdje je primjenjivo, u roku od 72 sata, međuizvješća kada se zatraže i završno izvješće najkasnije jedan mjesec nakon obavijesti o incidentu. Značajni incidenti uključuju one koji uzrokuju ozbiljan operativni prekid, financijski gubitak ili materijalnu ili nematerijalnu štetu drugima.

Izjava o apetitu treba definirati pragove eskalacije prije nego što se incident dogodi.

Kontrole iz Annex A oko planiranja incidenata, procjene događaja informacijske sigurnosti, odgovora na incidente, učenja iz incidenata, prikupljanja dokaza, održavanja informacijske sigurnosti tijekom prekida i IKT spremnosti za neprekidnost poslovanja podržavaju ove pragove. Ishodi NIST CSF-a kroz IDENTIFY, PROTECT, DETECT, RESPOND i RECOVER podržavaju isti operativni model, uključujući sigurnosne kopije, praćenje, proglašenje incidenta, eskalaciju, analizu temeljnog uzroka, komunikaciju s dionicima i provjeru oporavka.

Tolerancija dobavljača i oblaka koju upravljačka tijela često propuste

DORA čini IKT rizik trećih strana temeljnom obvezom usklađenosti. Article 28 zahtijeva od financijskih subjekata upravljanje IKT rizikom trećih strana kao dijelom okvira upravljanja IKT rizicima, uz punu odgovornost za usklađenost. Zahtijeva strategiju IKT rizika trećih strana, registre ugovornih aranžmana za IKT usluge, razlikovanje usluga koje podržavaju kritične ili važne funkcije, godišnje izvješćivanje, obavješćivanje o planiranim aranžmanima, procjene prije ugovaranja, dubinsku analizu dobavljača, prava na reviziju i inspekciju, prava raskida i dokumentirane strategije izlaska.

Article 29 dodaje analizu rizika koncentracije, uključujući nezamjenjivost, višestruke ovisnosti o istim ili povezanim pružateljima usluga, rizike podugovaranja, podugovaratelje iz trećih zemalja, usklađenost zaštite podataka, provedivost i složene lance podugovaranja. Article 30 zahtijeva pisana ugovorna prava i obveze, opise usluga, lokacije, sigurnosne zaštite, pristup podacima i povrat podataka, razine usluge, pomoć pri incidentima, suradnju s tijelima, prava raskida, testirane planove kontinuiteta, praćenje i aranžmane izlaska.

Izjava o toleranciji dobavljača odobrena na razini upravljačkog tijela mogla bi glasiti:

„Imamo nizak apetit za ovisnost kritičnih ili važnih funkcija o pružatelju IKT usluga treće strane kada nemamo ugovorna prava na reviziju, testirane aranžmane izlaska, obveze obavješćivanja o incidentima, ciljeve razine usluge, prava povrata podataka ili vidljivost nad značajnim podugovaranjem.”

Ta rečenica nabavi daje praktično pravilo. Ako ugovor ne zadovoljava prag, projektni tim ne može tiho prihvatiti rizik.

Kako će revizori testirati vaš apetit za IKT rizikom

Snažna izjava o apetitu izrađuje se imajući reviziju na umu.

Korak 28 Zenith Blueprinta, u fazi revizije, pregleda i poboljšanja, jača sloj preispitivanja od strane uprave. Upućuje organizacije da prikupe ulazne informacije kao što su promjene vanjskih i unutarnjih pitanja, učinkovitost ISMS-a, rezultati revizije, praćenje i mjerenje, incidenti, nesukladnosti, prilike za poboljšanje i potrebe za resursima. Također navodi da preispitivanje od strane uprave mora dovesti do odluka i radnji, a ne samo do prezentacija.

Najmanje jednom godišnje, i kad god nastupe značajne promjene, uprava treba pregledati jesu li pragovi tolerancije i dalje usklađeni s poslovnim modelom, jesu li incidenti premašili apetit, ostaju li prihvaćeni rizici unutar odobrenih granica, jesu li novi DORA, NIS2, GDPR ili ugovorni zahtjevi promijenili polaznu osnovu, ostaju li dobavljači unutar tolerancija koncentracije i uzrokuju li KRI-jevi pravodobnu eskalaciju.

Ako je odgovor ne, izjava o apetitu mora se promijeniti ili se kontrole moraju promijeniti.

Česti obrasci neuspjeha u radu na spremnosti za 2026.

U projektima DORA, NIS2, GDPR i ISO/IEC 27001:2022 iste se slabosti ponavljaju:

• Apetit bez pragova, kada upravljačko tijelo odobri izjavu, ali nitko ne može reći kada je ona prekršena.
• Pragovi bez ovlasti, kada postoje razine ozbiljnosti, ali vlasnici rizika mogu prihvatiti iznimke bez odobrenja višeg rukovodstva.
• Pravni rizik izvan modela bodovanja, kada su GDPR, DORA, NIS2 i ugovori navedeni odvojeno, ali nisu ugrađeni u kriterije utjecaja.
• Tolerancija dobavljača nedostaje u paketu za upravljačko tijelo, iako su kritične IKT ovisnosti poznate nabavi ili IT-u.
• Preispitivanje od strane uprave kao predstava, kada se prezentiraju slajdovi, ali odluke, radnje, potrebe za resursima i prihvaćanja rizika nisu dokumentirani.
• Fragmentacija revizijskih dokaza, kada politike, registri, KRI-jevi, izvješća o incidentima, pregledi dobavljača i zapisnici upravljačkog tijela postoje na različitim mjestima bez međureferenci.

Clarysecov pristup osmišljen je za uklanjanje tih praznina. Zenith Blueprint pruža fazni put implementacije. Politika upravljanja rizicima i Politika upravljanja rizicima za MSP-ove pružaju klauzule upravljanja prilagođene okruženjima velikih organizacija i malih i srednjih poduzeća. Zenith Controls mapira kontrolnu okosnicu kroz politiku informacijske sigurnosti, odgovornost rukovodstva i pravne ili regulatorne zahtjeve, čineći dokaze ponovno upotrebljivima kroz ISO/IEC 27001:2022, DORA, NIS2, GDPR, NIST CSF i osiguranje u stilu COBIT-a.

Pretvorite namjeru upravljačkog tijela u provjerljivo upravljanje IKT rizicima

Ako vaša organizacija ima registar rizika, ali ne može pokazati apetit za IKT rizikom odobren na razini upravljačkog tijela, mjerljive pragove tolerancije, okidače eskalacije i formalna pravila prihvaćanja, taj jaz nije kozmetički. Utječe na DORA upravljanje, odgovornost uprave prema NIS2, dokazivost prema GDPR Article 32 i spremnost za reviziju prema ISO/IEC 27001:2022.

Praktičan sljedeći korak jest provesti usmjerenu radionicu o apetitu za IKT rizikom koristeći Clarysecov skup alata:

1. Upotrijebite Zenith Blueprint korak 10 za definiranje kriterija rizika i ljestvica utjecaja.
2. Upotrijebite Zenith Blueprint korak 13 za povezivanje opcija obrade rizika, preostalog rizika i odobrenja Izjave o primjenjivosti.
3. Upotrijebite Zenith Blueprint korak 14 za unakrsno povezivanje obveza prema GDPR-u, NIS2 i DORA-i.
4. Upotrijebite Zenith Blueprint korak 28 za uključivanje apetita, KRI-jeva, prihvaćenih rizika i odluka o resursima u preispitivanje od strane uprave.
5. Primijenite Politiku upravljanja rizicima ili Politiku upravljanja rizicima za MSP-ove za formalizaciju pravila odobravanja i prihvaćanja.
6. Upotrijebite Zenith Controls za mapiranje kontrola upravljanja na revizijske dokaze i očekivanja međusobne usklađenosti.

Clarysec vam može pomoći pretvoriti raspršene artefakte rizika u model apetita za IKT rizikom koji je odobren na razini upravljačkog tijela, spreman za regulatorni nadzor i upotrebljiv vašim timovima kada sljedeći prekid usluge u oblaku, neuspjeh dobavljača, objava ranjivosti ili incident u vezi s osobnim podacima testira stvarnu toleranciju organizacije.