Apetit po IKT-tveganju po DORA: vodnik za odobritev upravljalnega organa za leto 2026

Torek je, ura je 08:15, vodja informacijske varnosti srednje velikega podjetja za plačilno tehnologijo pa stoji pred sejno sobo s tremi dokumenti, odprtimi na tablici.

Prvi je register IKT-tveganj. Ima 137 vrstic, barvno označene ocene in več visokih tveganj, povezanih s koncentracijo v oblaku, privilegiranim dostopom, obnovitvijo po napadu z izsiljevalsko programsko opremo, izpostavljenostjo podatkov strank in odzivom dobaviteljev na incidente. Drugi je sledilnik pripravljenosti na DORA. Navaja, da ima podjetje politike, postopke za obravnavo incidentov, registre tretjih oseb in načrte testiranja odpornosti. Tretji je gradivo za upravljalni organ za regulativni sestanek.

Predsednik ima eno vprašanje, ki ni tehnično:

»Katero raven IKT-tveganja smo se dejansko dogovorili sprejeti?«

V sobi nastane tišina, ker ima podjetje ocene tveganj, nima pa apetita po IKT-tveganju, ki bi ga odobril upravljalni organ. Ima ocene vpliva, nima pa merljivih pragov tolerance. Ima eskalacijske sestanke, nima pa formalnega sprožilca, ki določa, kdaj kibernetsko tveganje postane odločitev upravljalnega organa. Sprejelo je preostala tveganja, vendar so nekatera utemeljena kot »poslovne odločitve« brez jasne povezave z merili tveganj, sorazmernostjo po GDPR Article 32, pričakovanji glede tolerance po DORA ali odgovornostjo poslovodstva po NIS2.

Ta vrzel je v letu 2026 vse bolj vidna. DORA se uporablja od 17. januarja 2025 in od finančnih subjektov zahteva vzdrževanje okvira upravljanja in kontrol za IKT-tveganja, vključno z odgovornostjo upravljalnega organa za okvir upravljanja IKT-tveganj, strategijo digitalne operativne odpornosti in toleranco do IKT-tveganja. NIS2 upravljalne organe usmerja k odobritvi ukrepov za obvladovanje tveganj kibernetske varnosti in nadzoru nad njihovim izvajanjem. GDPR Article 32 zahteva ustrezne tehnične in organizacijske varnostne ukrepe na podlagi tveganja. ISO/IEC 27001:2022 zagotavlja mehaniko sistema upravljanja: kontekst, zainteresirane strani, merila tveganj, načrte obravnave tveganj, dokumentirane informacije in vodstveni pregled.

Manjkajoči most je izjava o apetitu po IKT-tveganju in toleranci, ki jo upravljalni organ lahko razume, odobri, izpodbija in uporablja.

Ta vodnik pojasnjuje, kako ta most zgraditi z uporabo Clarysecovega Zenith Blueprint: 30-koračni časovni načrt presojevalca, Clarysecove Politike upravljanja tveganj, Clarysecove Politike upravljanja tveganj za MSP in Zenith Controls: vodnika za navzkrižno skladnost.

Zakaj registri tveganj niso apetit po tveganju

Številne organizacije register tveganj zamenjujejo z upravljanjem tveganj. Register tveganj pove, katera tveganja obstajajo, kako so ocenjena, kdo je njihov lastnik in katera obravnava je načrtovana. Sam po sebi pa ne odgovori na vprašanja na ravni upravljalnega organa, za katera DORA, NIS2, GDPR in ISO/IEC 27001:2022 pričakujejo, da jih vodstvo obravnava.

Zrela izjava o apetitu po IKT-tveganju odgovarja na vprašanja, kot so:

• Katera IKT-tveganja so nesprejemljiva ne glede na stroške?
• Kakšen operativni izpad lahko poslovanje prenese pri kritični ali pomembni funkciji?
• Katera raven izgube podatkov ali ogrožanja celovitosti podatkov je zunaj apetita?
• Katero tveganje koncentracije pri tretjih osebah zahteva pozornost upravljalnega organa?
• Kdo lahko sprejme preostalo IKT-tveganje in na kateri ravni?
• Kdaj mora biti tveganje eskalirano višjemu vodstvu ali upravljalnemu organu?
• Kako so zakonske, regulativne in pogodbene zahteve vključene v merila tveganj?

Po DORA to ni neobvezna upravljavska dovršenost. Article 5 zahteva, da upravljalni organ opredeli, odobri, nadzira in prevzame odgovornost za okvir upravljanja IKT-tveganj, vključno s strategijo digitalne operativne odpornosti in toleranco do IKT-tveganja. Article 6 zahteva dokumentiran okvir upravljanja IKT-tveganj, letni pregled za podjetja, ki niso mikropodjetja, notranjo revizijo, odpravo kritičnih revizijskih ugotovitev in strategijo digitalne operativne odpornosti z IKT-cilji, toleranco do tveganja, toleranco vpliva, arhitekturo, testiranjem in strategijo komuniciranja o incidentih.

NIS2 dodaja vzporeden model odgovornosti. Article 20 zahteva, da upravljalni organi bistvenih in pomembnih subjektov odobrijo ukrepe za obvladovanje tveganj kibernetske varnosti, nadzirajo izvajanje in se usposabljajo. Article 21 zahteva ustrezne in sorazmerne tehnične, operativne in organizacijske ukrepe na podlagi pristopa vseh nevarnosti, vključno z analizo tveganj, obravnavanjem incidentov, neprekinjenim poslovanjem, varnostjo dobavne verige, varnim razvojem, učinkovitostjo kontrol, usposabljanjem, kriptografijo, kadrovsko varnostjo, nadzorom dostopa, upravljanjem sredstev in MFA, kadar je to ustrezno.

Za finančne subjekte se DORA obravnava kot sektorski pravni akt Unije, kadar se prekrivajo obveznosti po NIS2. V praksi DORA praviloma nadomesti prekrivajoče se zahteve NIS2 glede obvladovanja tveganj in poročanja o incidentih za finančne subjekte v njenem področju uporabe, NIS2 pa ostaja pomembna za koordinacijo in za ponudnike zunaj neposrednih obveznosti finančnih subjektov po DORA. Za ponudnike SaaS, oblaka, upravljanih storitev in upravljanih varnostnih storitev se NIS2 lahko uporablja neposredno, kadar so izpolnjeni pogoji področja uporabe.

Zato apetit po IKT-tveganju, ki ga odobri upravljalni organ, ni več artefakt finančnega tveganja. Je kontrola upravljanja kibernetske varnosti.

Uporabite ISO/IEC 27001:2022 kot operativni sistem

DORA in NIS2 vodstvu povesta, kaj mora biti upravljano. ISO/IEC 27001:2022 organizacijam daje praktičen operativni sistem za to, kako to upravljati.

ISO/IEC 27001:2022 Clauses 4.1 do 4.4 zahtevajo, da organizacija opredeli kontekst, zainteresirane strani, zahteve, obseg ISMS in procese ISMS. To je pomembno, ker DORA, NIS2, GDPR, pogodbe, pričakovanja nadzornih organov, stranke, ponudniki storitev v oblaku in ureditve zunanjega izvajanja postanejo zahteve, ki vplivajo na merila tveganj.

Clauses 5.1 do 5.3 zahtevajo zavezanost vodstva, uskladitev politike, vire, odgovornosti in poročanje o uspešnosti ISMS najvišjemu vodstvu. Clauses 6.1.1 do 6.1.3 zahtevajo načrtovanje na podlagi tveganj, dokumentiran proces ocenjevanja tveganj, merila za sprejem tveganja, dosledna merila ocenjevanja, lastnike tveganj, primerjavo z merili tveganj, načrtovanje obravnave, izjavo o uporabnosti (SoA) in odobritev preostalega tveganja.

To je temelj za toleranco do IKT-tveganja po DORA.

V fazi upravljanja tveganj Step 10 v Zenith Blueprint organizacijam nalaga, naj merila tveganj opredelijo pred ocenjevanjem tveganj:

»Merila tveganj so pravila in primerjalna merila, ki jih vaša organizacija uporablja za ocenjevanje pomena posameznega tveganja. Vnaprejšnja vzpostavitev teh meril zagotavlja, da vsi uporabljajo isti jezik tveganj.«

Isti korak opozarja, da mora biti regulativni vpliv vgrajen v opredelitve tveganj:

»Vsako tveganje, ki bi lahko povzročilo neskladnost z veljavno zakonodajo (GDPR itd.), ni sprejemljivo in ga je treba ublažiti.«

Zenith Blueprint daje tudi praktična navodila za stopnjevanje vpliva:

»Pri opredeljevanju vpliva je smiselno ravni povezati z dejanskim obsegom vašega poslovanja. Na primer: ‘Velik finančni vpliv = izguba > 100 tisoč USD’ (prilagodite svojemu kontekstu). Upoštevajte tudi regulativni vpliv: kršitev varnosti osebnih podatkov se lahko na primer samodejno šteje za ‘veliko’ ali ‘hudo’ zaradi glob po GDPR in zahtev glede obveščanja, tudi če neposredna finančna izguba ni jasna. Podobno je lahko incident, ki povzroči prekinitev storitve, če spadate v področje uporabe NIS2 (bistvene storitve), najmanj ‘velik’ zaradi pravnih posledic. Takšne vidike vključite v svoje opredelitve.«

Ta usmeritev preprečuje pogosto napako: da se kibernetsko tveganje oceni kot zmerno, ker se neposredna finančna izguba zdi majhna, pri tem pa se spregledajo pravni vpliv, operativna odpornost, vpliv na posameznike, na katere se podatki nanašajo, ali vpliv na stranke.

Model, pripravljen za upravljalni organ, mora ločiti štiri plasti:

Ta struktura naredi apetit po tveganju preverljiv, ker je vsako izjavo mogoče povezati z merili tveganj, kontrolami, dokazili in odločitvami.

Izjava o apetitu po IKT-tveganju po DORA, pripravljena za upravljalni organ

Močna izjava o apetitu po IKT-tveganju je dovolj kratka, da jo upravljalni organ odobri, dovolj specifična, da jo vodstvo uporablja, in dovolj merljiva, da jo presojevalci lahko testirajo. Izogibati se mora žargonu, ne sme pa biti nejasna.

Praktična krovna izjava se lahko glasi:

»Naše podjetje ima nizek apetit po IKT-tveganjih, ki bi lahko povzročila pomembno škodo strankam, motnje kritičnih ali pomembnih funkcij, nepooblaščeno razkritje ali spremembo reguliranih podatkov, neizpolnjevanje zakonskih obveznosti ali izgubo odpornosti pri kritičnih IKT-storitvah tretjih oseb.«

Ta izjava nato potrebuje merljive pragove tolerance in sprožilce eskalacije.

Ta tabela spremeni razpravo. Upravljalni organ ne odobrava več slogana. Odobrava operativne meje za razpoložljivost, zaupnost, celovitost, dobavitelje, ranljivosti, obnovitev in skladnost.

Clarysecova Politika upravljanja tveganj podpira ta model upravljanja. Politika za večja podjetja določa:

»Odobri okvir za obvladovanje tveganj ter opredeli sprejemljiv apetit po tveganju in pragove tolerance.«

Clause 6.2.1 izrecno določa zahtevo po merjenju:

»Tveganja je treba oceniti glede na verjetnost in vpliv z uporabo standardne matrike tveganj z jasno opredeljenimi ocenjevalnimi lestvicami.«

Clause 6.3.4 vzpostavlja pravilo sprejema, ki ga bodo presojevalci pričakovali:

»Tveganja, sprejeta brez obravnave, morajo biti pisno utemeljena, povezana z apetitom organizacije po tveganju in odobrena na ustrezni ravni.«

Za MSP Politika upravljanja tveganj za MSP ohranja isto upravljavsko načelo v lažji obliki:

»Zagotovite vključenost vodstva pri odobritvi tolerance do tveganja in pomembnih načrtov obravnave tveganj.«

Zahteva tudi eskalacijo visokih tveganj:

»Visoka tveganja morajo biti eskalirana generalnemu direktorju v odločanje.«

To je sorazmernost v praksi. DORA Article 4 zahteva, da se zahteve uporabljajo sorazmerno z velikostjo, profilom tveganja ter naravo, obsegom in kompleksnostjo storitev. ISO/IEC 27001:2022 omogoča isto načelo prek obsega, konteksta, meril tveganj in odločitev o obravnavi. Standard upravljanja ni, da vsaka organizacija potrebuje enako strukturo odborov. Standard upravljanja je, da so apetit po tveganju, toleranca, eskalacija in sprejem opredeljeni, odobreni, dokazani in uporabljeni.

GDPR Article 32 spreminja razpravo o tveganjih

GDPR Article 32 se pogosto obravnava kot tehnična varnostna klavzula. Z vidika upravljanja je tudi klavzula o apetitu po tveganju.

Article 32 zahteva, da upravljavci in obdelovalci uvedejo ustrezne tehnične in organizacijske ukrepe za zagotovitev ravni varnosti, primerne tveganju. Ta pristop na podlagi tveganj upošteva stanje tehnike, stroške izvedbe, naravo, obseg, kontekst in namene obdelave ter tveganja za pravice in svoboščine posameznikov.

To vpliva na apetit po IKT-tveganju na tri načine.

Prvič, vpliva osebnih podatkov ni mogoče zmanjšati na finančno izgubo. Izpostavljenost majhne podatkovne baze ima lahko omejene neposredne stroške, vendar resne posledice za zaupnost, identiteto, goljufije, diskriminacijo ali pravice posameznikov. Če gre za posebne vrste osebnih podatkov, kot so zdravstveni, biometrični ali genetski podatki, mora biti apetit bistveno nižji.

Drugič, vloge pri obdelavi morajo biti povezane z lastništvom tveganj. GDPR razlikuje med upravljavci in obdelovalci. DORA razlikuje med finančnimi subjekti in ponudniki IKT-storitev tretjih oseb. NIS2 razlikuje med bistvenimi in pomembnimi subjekti. ISO/IEC 27001:2022 zahteva lastnike tveganj. Zrela izjava o apetitu mora opredeliti, kdo je lastnik odločitev o tveganjih, ki vključujejo osebne podatke, zunanje izvajanje obdelave, kritične storitve in čezmejne odvisnosti.

Tretjič, sorazmernost po Article 32 mora biti vidna pri izbiri kontrol. Šifriranje, psevdonimizacija, nadzor dostopa, varnostno kopiranje, beleženje, spremljanje, odziv na incidente in odpornost niso izolirane tehnične naloge. So ukrepi obravnave, izbrani zato, ker je tveganje preseglo apetit ali toleranco.

Clarysecova Politika upravljanja tveganj to izrecno povezuje:

»Article 32: zahteva pristop k varnostnim ukrepom na podlagi tveganj, ki se izpolni z ocenami tveganj na podlagi vpliva in izbiro kontrol.«

To je operativna povezava, ki jo iščejo presojevalci: zahteva Article 32, ocena tveganja, razvrstitev tveganja po ravni, načrt obravnave tveganja, izbira kontrol, preostalo tveganje in odobritev.

Kako Zenith Controls podpira dokazila za navzkrižno skladnost

Izjava o apetitu, ki jo odobri upravljalni organ, postane učinkovita, ko je preslikana na kontrole. Zenith Controls deluje kot Clarysecov vodnik za navzkrižno skladnost in ekipam pomaga ponovno uporabiti dokazila v ISO/IEC 27001:2022, DORA, NIS2, GDPR, NIST CSF in zagotavljanju zaupanja v slogu COBIT.

Posebej pomembna so tri področja kontrol ISO/IEC 27002:2022:

To ni vaja preslikave na papirju. Spreminja način odločanja.

Če lastnik poslovnega procesa predlaga sprejem zamaknjenega uvajanja MFA za administratorje, Zenith Controls pomaga CISO pokazati, zakaj to ni le vprašanje nadzora dostopa. Dotika se upravljanja politik, odgovornosti vodstva, zakonskih in regulativnih zahtev, varnosti obdelave po GDPR, upravljanja IKT-tveganj po DORA, ukrepov kibernetske varnosti po NIS2, vpliva incidentov in revizijskih dokazil.

Če želi produktna ekipa lansirati storitev na novem trgu EU z uporabo nove storitve v oblaku, kontrola ISO/IEC 27002:2022 5.31 vključi pregled zakonskih in regulativnih zahtev v obseg ISMS. ISO/IEC 27001:2022 Clause 4.2 zahteva identifikacijo zahtev zainteresiranih strani, vključno z zakonskimi, regulativnimi in pogodbenimi obveznostmi. Clause 8.1 zahteva operativno načrtovanje in nadzor, vključno z nadzorom zunanje zagotovljenih procesov, produktov ali storitev, pomembnih za ISMS.

Cilj je en jezik tveganj, ne ločena narečja skladnosti.

Potek odobritve: kdo odloča o čem

CISO lahko predlaga apetit po IKT-tveganju, vendar ga mora imeti v lasti upravljalni organ. To lastništvo potrebuje delovni tok.

To je usklajeno tudi z NIST CSF 2.0. Funkcija GOVERN, zlasti GV.RM, pričakuje dogovorjene cilje upravljanja tveganj, izjave o apetitu po tveganju in toleranci, dejavnosti tveganj, vključene v korporativno upravljanje tveganj, opredeljene možnosti odziva na tveganja, komunikacijske poti ter standardizirane metode za izračun, dokumentiranje, kategorizacijo in določanje prioritet kibernetskih tveganj. GV.RR pričakuje odgovornost vodstva, vloge, pooblastila in vire, usklajene s strategijo tveganj. GV.PO pričakuje, da so politike vzpostavljene, sporočene, uveljavljene, pregledane in posodobljene.

Strokovnjaki za zagotavljanje zaupanja po COBIT 19 in v slogu ISACA bodo vprašali, ali je apetit po tveganju vključen v korporativno upravljanje informacij in tehnologije, ne pa zgolj priložen kot dodatek k kibernetski politiki.

Pripravite paket apetita po IKT-tveganju v eni delovni seji

Praktična delavnica o apetitu po IKT-tveganju lahko organizacijo premakne od razpršenih registrov do preverljivega gradiva za upravljalni organ.

Step 1: zberite prave vhodne podatke

Pripravite trenutni register IKT-tveganj, analizo vpliva na poslovanje, cilje obnovitve, seznam kritičnih ali pomembnih funkcij, evidenco IKT-sredstev, evidenco IKT-storitev, register odvisnosti od dobaviteljev in oblaka, merila za razvrščanje incidentov, popis dejavnosti obdelave po GDPR, DPIA, kjer so relevantne, evidenco zakonskih obveznosti, politike, izjavo o uporabnosti (SoA) in obstoječo izjavo o apetitu podjetja po tveganju.

To je usklajeno z ISO/IEC 27001:2022 Clauses 4, 6 in 8 ter z metodami profilov NIST CSF, ki se začnejo s poslovnimi prioritetami, prioritetami tveganj, zahtevami, varovali in vlogami.

Step 2: opredelite lestvice vpliva, ki vključujejo regulativo

Z uporabo Zenith Blueprint Step 10 opredelite verjetnost in vpliv v poslovnem jeziku. Vključite finančno izgubo, operativne motnje, vpliv na stranke, škodo za ugled, pravni in regulativni vpliv, škodo za posameznike, na katere se podatki nanašajo, ter vpliv na kritične funkcije.

Na primer, »velik« vpliv lahko vključuje daljši izpad kritične storitve, potrjeno kršitev varnosti osebnih podatkov, ki zahteva obveščanje, neizpolnitev obveznosti poročanja o incidentu po DORA ali odpoved dobavitelja, ki vpliva na kritično ali pomembno funkcijo.

Step 3: zapišite apetit po področjih

Ne ustvarite enega generičnega kibernetskega apetita. Opredelite področja, kot so razpoložljivost kritičnih storitev, zaupnost osebnih podatkov, celovitost podatkov, privilegirani dostop, odvisnost od IKT-tretjih oseb, koncentracija v oblaku, izpostavljenost ranljivostim, pripravljenost na poročanje o incidentih, varnostno kopiranje in obnovitev ter tveganje sprememb pri varnem razvoju.

Za vsako področje napišite eno izjavo o apetitu, enega ali več pragov tolerance in sprožilce eskalacije.

Step 4: povežite obravnavo z izjavo o uporabnosti

Step 13 v Zenith Blueprint organizacijam nalaga, naj izberejo možnosti obravnave tveganja: zmanjšanje, izogibanje, prenos ali sprejem. Poudarja tudi odobritev vodstva:

»Odločitve o obravnavi tveganj in SoA mora pregledati in odobriti najvišje vodstvo.«

Za DORA in NIS2 je to dokazilo, da je upravljalni organ ali delegirano vodstvo pregledalo ključna tveganja, obravnave in sprejeto preostalo izpostavljenost. Za GDPR podpira odgovornost, ker pokaže, zakaj so bili izbrani ukrepi ustrezni glede na tveganje.

Step 5: zabeležite sprejem z datumom poteka in pogoji

Vsako sprejeto srednje ali visoko preostalo tveganje mora vključevati:

• ID tveganja in lastnika
• poslovno utemeljitev
• sklic na izjavo o apetitu
• prizadeti prag tolerance
• pravno in regulativno analizo
• kompenzacijske kontrole
• datum poteka ali pregleda
• odobritelja
• lokacijo dokazil
• sprožilec za ponovno odprtje odločitve

Politika upravljanja tveganj za MSP določa:

»Vsaka odločitev o sprejemu ali odlogu obravnave visokega ali srednjega tveganja mora biti dokumentirana v registru tveganj. Ta dokumentacija mora vključevati:«

V večjih podjetjih to postane odobritveni delovni tok in gradivo za odbor za tveganja. V manjših organizacijah je to lahko strukturiran zavihek registra tveganj z odobritvijo vodstva. Namen ni birokracija. Namen je dokazljiva odgovornost.

Toleranca incidentov: kjer se apetit sreča z uro

Apetit po tveganju postane stvaren med incidenti.

DORA Article 17 zahteva, da finančni subjekti vzpostavijo proces upravljanja incidentov, povezanih z IKT, za odkrivanje, upravljanje in obveščanje o incidentih, evidentiranje vseh incidentov in pomembnih kibernetskih groženj, ugotavljanje temeljnih vzrokov, uporabo kazalnikov zgodnjega opozarjanja, razvrščanje incidentov po prioriteti, resnosti in kritičnosti storitve, dodelitev vlog, komuniciranje z zainteresiranimi stranmi, eskalacijo vsaj večjih incidentov, povezanih z IKT, višjemu vodstvu in upravljalnemu organu ter pravočasno obnovitev varnega delovanja.

DORA Article 18 razvršča incidente z uporabo dejavnikov, kot so prizadete stranke, trajanje, izpad, geografska razširjenost, izgube podatkov, ki vplivajo na razpoložljivost, avtentičnost, celovitost ali zaupnost, kritičnost prizadetih storitev in gospodarski vpliv. Article 19 zahteva, da se o večjih incidentih, povezanih z IKT, poroča pristojnemu organu, stranke pa se obvesti, kadar so prizadeti njihovi finančni interesi.

NIS2 Article 23 določa fazno poročanje za pomembne incidente, vključno z zgodnjim opozorilom brez nepotrebnega odlašanja in, kjer je ustrezno, v 24 urah, obvestilom o incidentu brez nepotrebnega odlašanja in, kjer je ustrezno, v 72 urah, vmesnimi posodobitvami na zahtevo ter končnim poročilom najpozneje en mesec po obvestilu o incidentu. Pomembni incidenti vključujejo tiste, ki povzročijo hude operativne motnje, finančno izgubo ali materialno ali nematerialno škodo drugim.

Izjava o apetitu mora opredeliti pragove eskalacije, preden se incident zgodi.

Kontrole iz Annex A v zvezi z načrtovanjem incidentov, ocenjevanjem dogodkov informacijske varnosti, odzivom na incidente, učenjem iz incidentov, zbiranjem dokazov, ohranjanjem informacijske varnosti med motnjami in pripravljenostjo IKT za neprekinjeno poslovanje podpirajo te pragove. Izidi NIST CSF v funkcijah IDENTIFY, PROTECT, DETECT, RESPOND in RECOVER podpirajo isti operativni model, vključno z varnostnimi kopijami, spremljanjem, razglasitvijo incidenta, eskalacijo, analizo temeljnega vzroka, komunikacijo z zainteresiranimi stranmi in preverjanjem obnovitve.

Toleranca do dobaviteljev in oblaka, ki jo upravljalni organi pogosto spregledajo

DORA tveganje IKT-tretjih oseb postavlja med ključne obveznosti skladnosti. Article 28 zahteva, da finančni subjekti upravljajo tveganja IKT-tretjih oseb kot del okvira upravljanja IKT-tveganj, pri čemer ostanejo v celoti odgovorni za skladnost. Zahteva strategijo tveganj IKT-tretjih oseb, registre pogodbenih ureditev za IKT-storitve, razlikovanje storitev, ki podpirajo kritične ali pomembne funkcije, letno poročanje, obveščanje o načrtovanih ureditvah, predpogodbene presoje, skrbni pregled, pravice do revizije in pregleda, pravice do odpovedi in dokumentirane izstopne strategije.

Article 29 dodaja analizo tveganja koncentracije, vključno z nezamenljivostjo, več odvisnostmi od istih ali povezanih ponudnikov, tveganji podizvajanja, podizvajalci iz tretjih držav, skladnostjo varstva podatkov, izvršljivostjo in kompleksnimi verigami podizvajanja. Article 30 zahteva pisne pogodbene pravice in obveznosti, opise storitev, lokacije, varnostne zaščite, dostop do podatkov in njihovo vračilo, ravni storitev, pomoč pri incidentih, sodelovanje z organi, pravice do odpovedi, testirane rezervne načrte, spremljanje in izstopne ureditve.

Izjava o toleranci do dobaviteljev, ki jo odobri upravljalni organ, se lahko glasi:

»Imamo nizek apetit po tem, da so kritične ali pomembne funkcije odvisne od IKT-ponudnika tretje osebe, kadar nimamo pogodbenih pravic do revizije, testiranih izstopnih ureditev, obveznosti obveščanja o incidentih, ciljnih ravni storitev, pravic do vračila podatkov ali vpogleda v bistveno podizvajanje.«

Ta stavek nabavi daje praktično pravilo. Če pogodba ne izpolnjuje praga, projektna ekipa tveganja ne more tiho sprejeti.

Kako bodo presojevalci testirali vaš apetit po IKT-tveganju

Močna izjava o apetitu je zasnovana z mislijo na presojo.

Step 28 v Zenith Blueprint, v fazi Presoja, pregled in izboljševanje, krepi plast vodstvenega pregleda. Organizacijam nalaga, naj zberejo vhodne informacije, kot so spremembe zunanjih in notranjih vprašanj, uspešnost ISMS, rezultati presoj, spremljanje in merjenje, incidenti, neskladnosti, priložnosti za izboljšave in potrebe po virih. Prav tako določa, da mora vodstveni pregled voditi do odločitev in ukrepov, ne zgolj do predstavitev.

Najmanj enkrat letno in ob vsaki bistveni spremembi mora vodstvo pregledati, ali so pragovi tolerance še usklajeni s poslovnim modelom, ali so incidenti presegli apetit, ali sprejeta tveganja ostajajo znotraj odobrenih meja, ali so nove zahteve DORA, NIS2, GDPR ali pogodbene zahteve spremenile izhodišče, ali dobavitelji ostajajo znotraj toleranc koncentracije in ali KRI povzročajo pravočasno eskalacijo.

Če je odgovor ne, se mora izjava o apetitu spremeniti ali pa se morajo spremeniti kontrole.

Pogosti vzorci neuspeha pri pripravljenosti v letu 2026

V projektih DORA, NIS2, GDPR in ISO/IEC 27001:2022 se vedno znova pojavljajo iste slabosti:

• Apetit brez pragov, kjer upravljalni organ odobri izjavo, nihče pa ne zna povedati, kdaj je bila prekoračena.
• Pragovi brez pooblastil, kjer ravni resnosti obstajajo, lastniki tveganj pa lahko sprejemajo izjeme brez odobritve višjega vodstva.
• Pravno tveganje zunaj modela točkovanja, kjer so GDPR, DORA, NIS2 in pogodbe navedeni ločeno, niso pa vgrajeni v merila vpliva.
• Toleranca do dobaviteljev manjka v gradivu za upravljalni organ, čeprav so kritične IKT-odvisnosti znane nabavi ali IT.
• Vodstveni pregled kot formalnost, kjer se predstavijo prosojnice, odločitve, ukrepi, potrebe po virih in sprejemi tveganj pa niso dokumentirani.
• Razdrobljenost revizijskih dokazil, kjer politike, registri, KRI, poročila o incidentih, pregledi dobaviteljev in zapisniki upravljalnega organa obstajajo na različnih mestih brez navzkrižnega sklica.

Clarysecov pristop je zasnovan za odpravo teh vrzeli. Zenith Blueprint zagotavlja fazno pot implementacije. Politika upravljanja tveganj in Politika upravljanja tveganj za MSP zagotavljata upravljavske klavzule, prilagojene velikim podjetjem in okoljem MSP. Zenith Controls preslika hrbtenico kontrol prek politike informacijske varnosti, odgovornosti vodstva ter zakonskih ali regulativnih zahtev, s čimer so dokazila ponovno uporabna v ISO/IEC 27001:2022, DORA, NIS2, GDPR, NIST CSF in zagotavljanju zaupanja v slogu COBIT.

Namen upravljalnega organa pretvorite v preverljivo upravljanje IKT-tveganj

Če ima vaša organizacija register tveganj, ne more pa pokazati apetita po IKT-tveganju, ki ga je odobril upravljalni organ, merljivih pragov tolerance, sprožilcev eskalacije in formalnih pravil sprejema, vrzel ni kozmetična. Vpliva na upravljanje po DORA, odgovornost vodstva po NIS2, dokazljivo odgovornost po GDPR Article 32 in pripravljenost na presojo po ISO/IEC 27001:2022.

Praktičen naslednji korak je izvedba osredotočene delavnice o apetitu po IKT-tveganju z uporabo Clarysecovega nabora orodij:

1. Uporabite Zenith Blueprint Step 10 za opredelitev meril tveganj in lestvic vpliva.
2. Uporabite Zenith Blueprint Step 13 za povezavo možnosti obravnave, preostalega tveganja in odobritve izjave o uporabnosti (SoA).
3. Uporabite Zenith Blueprint Step 14 za navzkrižni sklic obveznosti GDPR, NIS2 in DORA.
4. Uporabite Zenith Blueprint Step 28 za vključitev apetita, KRI, sprejetih tveganj in odločitev o virih v vodstveni pregled.
5. Uporabite Politiko upravljanja tveganj ali Politiko upravljanja tveganj za MSP za formalizacijo pravil odobritve in sprejema.
6. Uporabite Zenith Controls za preslikavo kontrol upravljanja na revizijska dokazila in pričakovanja navzkrižne skladnosti.

Clarysec vam lahko pomaga razpršene artefakte tveganj pretvoriti v regulatorno pripravljen model apetita po IKT-tveganju, ki ga odobri upravljalni organ in ki ga lahko vaše ekipe uporabijo, ko naslednji izpad oblaka, odpoved dobavitelja, razkritje ranljivosti ali incident v zvezi z osebnimi podatki preizkusi dejansko toleranco organizacije.