DORA IKT riska apetīte: ceļvedis valdes apstiprināšanai 2026. gadam

Otrdien plkst. 08.15 vidēja lieluma maksājumu tehnoloģiju uzņēmuma informācijas drošības vadītājs (CISO) stāv pie valdes sēžu telpas ar planšetē atvērtiem trim dokumentiem.

Pirmais ir IKT riska reģistrs. Tajā ir 137 rindas, ar krāsām kodēti vērtējumi un vairāki augsti riski, kas saistīti ar mākoņpakalpojumu koncentrāciju, privileģētas piekļuves pārvaldību, atjaunošanos pēc izspiedējprogrammatūras incidentiem, klientu datu ekspozīciju un piegādātāju incidentu pārvaldību. Otrais ir DORA gatavības uzraudzības materiāls. Tajā norādīts, ka uzņēmumam ir politikas, incidentu procedūras, trešo pušu reģistri un noturības testēšanas plāni. Trešais ir valdes materiālu pakete regulatīvajai sanāksmei.

Valdes priekšsēdētājam ir viens jautājums, un tas nav tehnisks:

“Kādu IKT riska līmeni mēs faktiski esam vienojušies pieņemt?”

Telpā iestājas klusums, jo uzņēmumam ir risku novērtējums, bet nav valdes apstiprinātas IKT riska apetītes. Tam ir ietekmes vērtējumi, bet nav izmērāmu tolerances robežvērtību. Tam ir eskalācijas sanāksmes, bet nav formāla kritērija, kas nosaka, kad kiberrisks kļūst par vadības struktūras lēmumu. Tam ir pieņemti atlikušie riski, bet daži no tiem ir pamatoti kā “biznesa lēmumi” bez skaidras sasaistes ar riska kritērijiem, GDPR Article 32 proporcionalitāti, DORA tolerances prasībām vai NIS2 vadības pārskatatbildību.

Šī plaisa 2026. gadā kļūst arvien redzamāka. DORA piemēro no 2025. gada 17. janvāra, un tā prasa finanšu vienībām uzturēt IKT riska pārvaldības un kontroles ietvaru, tostarp vadības struktūras atbildību par IKT riska pārvaldības ietvaru, digitālās darbības noturības stratēģiju un IKT riska toleranci. NIS2 nosaka, ka vadības struktūrām jāapstiprina kiberdrošības riska pārvaldības pasākumi un jāuzrauga to ieviešana. GDPR Article 32 prasa riskā balstītus un atbilstošus tehniskos un organizatoriskos drošības pasākumus. ISO/IEC 27001:2022 nodrošina pārvaldības sistēmas mehānismu: kontekstu, ieinteresētās puses, riska kritērijus, riska apstrādes plānus, dokumentētu informāciju un vadības pārskatīšanu.

Trūkstošais tilts ir IKT riska apetītes un tolerances paziņojums, ko valde var saprast, apstiprināt, apstrīdēt un izmantot.

Šajā ceļvedī skaidrots, kā šo tiltu izveidot, izmantojot Clarysec Zenith Blueprint: auditora 30 soļu ceļvedi, Clarysec Risku pārvaldības politiku, Clarysec Risku pārvaldības politiku MVU un Zenith Controls: savstarpējās atbilstības ceļvedi.

Kāpēc riska reģistri nav riska apetīte

Daudzas organizācijas riska reģistru kļūdaini uzskata par risku pārvaldību. Riska reģistrs parāda, kādi riski pastāv, kā tie ir novērtēti, kam tie pieder un kāda apstrāde ir plānota. Tas pats par sevi neatbild uz valdes līmeņa jautājumiem, uz kuriem DORA, NIS2, GDPR un ISO/IEC 27001:2022 sagaida vadības atbildes.

Nobriedis IKT riska apetītes paziņojums atbild uz šādiem jautājumiem:

• Kuri IKT riski ir nepieņemami neatkarīgi no izmaksām?
• Kādu darbības dīkstāvi organizācija var pieļaut kritiskai vai svarīgai funkcijai?
• Kāds datu zuduma vai datu integritātes kompromitēšanas līmenis ir ārpus riska apetītes?
• Kāds trešo pušu koncentrācijas risks prasa valdes uzmanību?
• Kas drīkst pieņemt atlikušo IKT risku un kādā līmenī?
• Kad risks jāeskalē augstākajai vadībai vai vadības struktūrai?
• Kā tiesiskās, regulatīvās un līgumiskās prasības ir iestrādātas riska kritērijos?

DORA kontekstā tā nav izvēles pārvaldības formalitāte. Article 5 prasa vadības struktūrai definēt, apstiprināt, pārraudzīt IKT riska pārvaldības ietvaru un uzņemties par to atbildību, tostarp par digitālās darbības noturības stratēģiju un IKT riska toleranci. Article 6 prasa dokumentētu IKT riska pārvaldības ietvaru, ikgadēju pārskatīšanu vienībām, kas nav mikrouzņēmumi, iekšējo auditu, kritisku audita konstatējumu novēršanu un digitālās darbības noturības stratēģiju ar IKT mērķiem, riska toleranci, ietekmes toleranci, arhitektūru, testēšanu un incidentu komunikācijas stratēģiju.

NIS2 pievieno paralēlu pārskatatbildības modeli. Article 20 prasa būtisko un svarīgo vienību vadības struktūrām apstiprināt kiberdrošības riska pārvaldības pasākumus, uzraudzīt ieviešanu un apgūt apmācību. Article 21 prasa atbilstošus un samērīgus tehniskos, operacionālos un organizatoriskos pasākumus, kas balstīti uz visu apdraudējumu pieeju, tostarp riska analīzi, incidentu apstrādi, darbības nepārtrauktību, piegādes ķēdes drošību, drošu izstrādi, kontroles efektivitāti, apmācību, kriptogrāfiju, personāla drošību, piekļuves kontroli, aktīvu pārvaldību un MFA, ja tas ir piemērojami.

Finanšu vienībām DORA tiek uzskatīta par nozarei specifisku Savienības tiesību aktu gadījumos, kad piemērojamas pārklājošās NIS2 prasības. Praksē DORA parasti aizstāj pārklājošās NIS2 riska pārvaldības un incidentu ziņošanas prasības finanšu vienībām tās darbības jomā, savukārt NIS2 joprojām ir būtiska koordinācijai un pakalpojumu sniedzējiem ārpus DORA tiešajām finanšu vienību prasībām. SaaS, mākoņpakalpojumu, pārvaldīto pakalpojumu un pārvaldītās drošības pakalpojumu sniedzējiem NIS2 var būt tieši piemērojama, ja ir izpildīti darbības jomas nosacījumi.

Tāpēc valdes apstiprināta IKT riska apetīte vairs nav finanšu riska artefakts. Tā ir kiberdrošības pārvaldības kontrole.

Izmantojiet ISO/IEC 27001:2022 kā operacionālo sistēmu

DORA un NIS2 vadībai nosaka, kas jāpārvalda. ISO/IEC 27001:2022 organizācijām sniedz praktisku operacionālo sistēmu, kā to pārvaldīt.

ISO/IEC 27001:2022 4.1 līdz 4.4 punkti prasa organizācijai definēt kontekstu, ieinteresētās puses, prasības, ISMS darbības jomu un ISMS procesus. Tas ir būtiski, jo DORA, NIS2, GDPR, līgumi, uzraudzības iestāžu gaidas, klienti, mākoņpakalpojumu sniedzēji un ārpakalpojumu vienošanās kļūst par prasībām, kas ietekmē riska kritērijus.

5.1 līdz 5.3 punkti prasa vadības apņemšanos, politikas saskaņošanu, resursus, pienākumus un ziņošanu par ISMS sniegumu augstākajai vadībai. 6.1.1 līdz 6.1.3 punkti prasa riskā balstītu plānošanu, dokumentētu riska novērtēšanas procesu, riska pieņemšanas kritērijus, konsekventus novērtēšanas kritērijus, riska īpašniekus, salīdzināšanu ar riska kritērijiem, riska apstrādes plānošanu, Piemērojamības paziņojumu un atlikušā riska apstiprināšanu.

Tas ir DORA IKT riska tolerances pamats.

Risku pārvaldības posmā Zenith Blueprint 10. solis organizācijām norāda definēt riska kritērijus pirms risku vērtēšanas:

“Riska kritēriji ir noteikumi un etaloni, ko jūsu organizācija izmanto, lai izvērtētu katra riska nozīmīgumu. Šo kritēriju noteikšana sākumā nodrošina, ka visi izmanto vienotu riska valodu.”

Tas pats solis brīdina, ka regulatīvā ietekme jāiekļauj riska definīcijās:

“Jebkurš risks, kas varētu izraisīt neatbilstību piemērojamiem tiesību aktiem (GDPR u. c.), nav pieņemams un ir jāmazina.”

Zenith Blueprint sniedz arī praktiskas norādes ietekmes mērogošanai:

“Definējot ietekmi, ir lietderīgi sasaistīt līmeņus ar jūsu konkrēto biznesa mērogu. Piemēram, ‘būtiska finanšu ietekme = zaudējumi > 100 tūkst. USD’ (pielāgojiet savam kontekstam). Ņemiet vērā arī regulatīvo ietekmi: piemēram, personas datu aizsardzības pārkāpums automātiski var būt ‘būtisks’ vai ‘smags’ GDPR sodu un paziņošanas prasību dēļ, pat ja tiešie finanšu zaudējumi nav skaidri. Līdzīgi, ja uz jums attiecas NIS2 (būtiskie pakalpojumi), incidents, kas izraisa pakalpojuma darbības traucējumus, juridisko seku dēļ var būt vismaz ‘būtisks’. Iekļaujiet šādus apsvērumus savās definīcijās.”

Šīs norādes novērš biežu kļūdu: kiberrisku novērtēt kā vidēju tāpēc, ka tūlītējie finanšu zaudējumi šķiet nelieli, vienlaikus ignorējot tiesisko, darbības noturības, datu subjekta vai klientu ietekmi.

Valdei piemērots modelis jānodala četros slāņos:

Šī struktūra padara riska apetīti auditējamu, jo katru paziņojumu var izsekot līdz riska kritērijiem, kontroles pasākumiem, pierādījumiem un lēmumiem.

Valdei piemērots DORA IKT riska apetītes paziņojums

Spēcīgs IKT riska apetītes paziņojums ir pietiekami īss, lai valde to apstiprinātu, pietiekami konkrēts, lai vadība to piemērotu, un pietiekami izmērāms, lai auditori to pārbaudītu. Tam jāizvairās no žargona, bet tas nedrīkst būt neskaidrs.

Praktisks augsta līmeņa paziņojums varētu būt šāds:

“Mūsu uzņēmumam ir zema apetīte pret IKT riskiem, kas varētu radīt būtisku kaitējumu klientiem, traucējumus kritiskām vai svarīgām funkcijām, neatļautu reglamentētu datu izpaušanu vai izmainīšanu, tiesisko pienākumu neizpildi vai noturības zudumu kritiskos IKT trešo pušu pakalpojumos.”

Šādam paziņojumam pēc tam nepieciešamas izmērāmas tolerances robežvērtības un eskalācijas kritēriji.

Šī tabula maina sarunu. Valde vairs neapstiprina saukli. Tā apstiprina operacionālās robežas pieejamībai, konfidencialitātei, integritātei, piegādātājiem, ievainojamībām, atjaunošanai un atbilstībai.

Clarysec Risku pārvaldības politika atbalsta šo pārvaldības modeli. Uzņēmuma politika nosaka:

“Apstiprina risku pārvaldības ietvaru un definē pieņemamu riska apetīti un tolerances robežvērtības.”

6.2.1. punkts mērījumu prasību formulē skaidri:

“Riski jāizvērtē pēc iespējamības un ietekmes, izmantojot standarta riska matricu ar skaidri definētām vērtēšanas skalām.”

6.3.4. punkts izveido pieņemšanas noteikumu, ko sagaidīs auditori:

“Riski, kas pieņemti bez apstrādes, rakstiski jāpamato, jāsasaista ar organizācijas riska apetīti un jāapstiprina atbilstošā līmenī.”

MVU vajadzībām Risku pārvaldības politika MVU to pašu pārvaldības principu saglabā vienkāršākā formātā:

“Nodrošināt vadības iesaisti riska tolerances un būtisku riska apstrādes plānu apstiprināšanā.”

Tā prasa arī augstu risku eskalāciju:

“Augsti riski lēmuma pieņemšanai jāeskalē ģenerāldirektoram.”

Tā ir proporcionalitāte praksē. DORA Article 4 prasa prasības piemērot samērīgi ar lielumu, riska profilu un pakalpojumu raksturu, mērogu un sarežģītību. ISO/IEC 27001:2022 ļauj īstenot to pašu principu, izmantojot darbības jomu, kontekstu, riska kritērijus un riska apstrādes lēmumus. Pārvaldības standarts nav tas, ka katrai organizācijai nepieciešama vienāda komiteju struktūra. Pārvaldības standarts ir tas, ka riska apetīte, tolerance, eskalācija un pieņemšana ir definēta, apstiprināta, pierādāma un lietota.

GDPR Article 32 maina sarunu par risku

GDPR Article 32 bieži tiek uztverts kā tehniskās drošības pants. Pārvaldības izpratnē tas ir arī riska apetītes pants.

Article 32 prasa pārziņiem un apstrādātājiem ieviest atbilstošus tehniskos un organizatoriskos pasākumus, lai nodrošinātu riskam atbilstošu drošības līmeni. Šī riskā balstītā pieeja ņem vērā jaunāko tehnikas attīstības līmeni, ieviešanas izmaksas, apstrādes raksturu, apjomu, kontekstu un nolūkus, kā arī riskus fizisko personu tiesībām un brīvībām.

Tas ietekmē IKT riska apetīti trīs veidos.

Pirmkārt, personas datu ietekmi nevar reducēt uz finanšu zaudējumiem. Nelielas datubāzes ekspozīcijai var būt ierobežotas tiešās izmaksas, bet nopietnas sekas konfidencialitātei, identitātei, krāpšanai, diskriminācijai vai tiesību īstenošanai. Ja iesaistīti īpašu kategoriju personas dati, piemēram, veselības, biometriskie vai ģenētiskie dati, apetītei jābūt būtiski zemākai.

Otrkārt, apstrādes lomām jābūt saistītām ar atbildību par risku. GDPR nošķir pārziņus un apstrādātājus. DORA nošķir finanšu vienības un IKT trešo pušu pakalpojumu sniedzējus. NIS2 nošķir būtiskās un svarīgās vienības. ISO/IEC 27001:2022 prasa riska īpašniekus. Nobriedušam apetītes paziņojumam jānosaka, kam pieder riska lēmumi, kas ietver personas datus, ārpakalpojumā nodotu apstrādi, kritiskos pakalpojumus un pārrobežu atkarības.

Treškārt, Article 32 proporcionalitātei jābūt redzamai kontroles pasākumu izvēlē. Šifrēšana, pseidonimizācija, piekļuves kontrole, rezerves kopijas, žurnālfiksēšana, uzraudzība, reaģēšana uz incidentiem un noturība nav izolēti tehniski uzdevumi. Tie ir apstrādes pasākumi, kas izvēlēti tāpēc, ka risks pārsniedza apetīti vai toleranci.

Clarysec Risku pārvaldības politika šo sasaisti formulē tieši:

“Article 32: nosaka riskā balstītu pieeju drošības pasākumiem, kas tiek izpildīta ar ietekmē balstītu riska izvērtēšanu un kontroles pasākumu atlasi.”

Tā ir operacionālā saikne, ko meklē auditori: Article 32 prasība, risku novērtējums, riska vērtējums, riska apstrādes plāns, kontroles pasākumu izvēle, atlikušais risks un apstiprinājums.

Kā Zenith Controls atbalsta savstarpējās atbilstības pierādījumus

Valdes apstiprināts apetītes paziņojums kļūst iedarbīgs, kad tas ir kartēts ar kontroles pasākumiem. Zenith Controls darbojas kā Clarysec savstarpējās atbilstības ceļvedis, palīdzot komandām atkārtoti izmantot pierādījumus ISO/IEC 27001:2022, DORA, NIS2, GDPR, NIST CSF un COBIT tipa apliecinājuma vajadzībām.

Īpaši svarīgas ir trīs ISO/IEC 27002:2022 kontroles jomas:

Tā nav formāla kartēšana uz papīra. Tā maina lēmumu pieņemšanas veidu.

Ja biznesa īpašnieks lūdz pieņemt aizkavētu MFA ieviešanu administratoriem, Zenith Controls palīdz CISO parādīt, kāpēc tas nav tikai piekļuves kontroles jautājums. Tas skar politikas pārvaldību, vadības atbildību, tiesiskās un regulatīvās prasības, GDPR apstrādes drošību, DORA IKT riska pārvaldību, NIS2 kiberdrošības pasākumus, incidenta ietekmi un audita pierādījumus.

Ja produktu komanda vēlas sākt darbību jaunā ES tirgū, izmantojot jaunu mākoņpakalpojumu, ISO/IEC 27002:2022 kontrole 5.31 ievada tiesisko un regulatīvo prasību pārskatīšanu ISMS darbības jomā. ISO/IEC 27001:2022 4.2. punkts prasa identificēt ieinteresēto pušu prasības, tostarp tiesiskos, regulatīvos un līgumiskos pienākumus. 8.1. punkts prasa darbības plānošanu un kontroli, tostarp ārēji nodrošināto procesu, produktu vai pakalpojumu kontroli, kas ir būtiski ISMS.

Mērķis ir viena riska valoda, nevis atsevišķi atbilstības dialekti.

Apstiprināšanas darbplūsma: kurš ko lemj

CISO var ierosināt IKT riska apetīti, bet valdei vai vadības struktūrai tā ir jāuzņemas. Šai atbildībai nepieciešama darbplūsma.

Tas atbilst arī NIST CSF 2.0. GOVERN funkcija, īpaši GV.RM, sagaida saskaņotus riska pārvaldības mērķus, riska apetītes un tolerances paziņojumus, riska darbību integrāciju uzņēmuma risku pārvaldībā, definētas riska reaģēšanas iespējas, komunikācijas līnijas un standartizētas metodes kiberdrošības risku aprēķināšanai, dokumentēšanai, kategorizēšanai un prioritizēšanai. GV.RR sagaida vadības pārskatatbildību, lomas, pilnvaras un resursus, kas saskaņoti ar riska stratēģiju. GV.PO sagaida, ka politikas tiek izveidotas, komunicētas, piemērotas, pārskatītas un atjauninātas.

COBIT 19 un ISACA tipa apliecinājuma speciālisti jautās, vai riska apetīte ir integrēta uzņēmuma informācijas un tehnoloģiju pārvaldībā, nevis tikai pievienota kā kiberdrošības politikas pielikums.

Izveidojiet IKT riska apetītes paketi vienā darba sesijā

Praktiska IKT riska apetītes darbnīca var pārvērst organizāciju no izkaisītiem reģistriem uz auditējamu valdes materiālu paketi.

1. solis: apkopojiet pareizos ievaddatus

Sagatavojiet pašreizējo IKT riska reģistru, biznesa ietekmes analīzi, atjaunošanas mērķus, kritisko vai svarīgo funkciju sarakstu, IKT aktīvu uzskaiti, IKT pakalpojumu uzskaiti, piegādātāju un mākoņpakalpojumu atkarību reģistru, incidentu klasifikācijas kritērijus, GDPR apstrādes darbību uzskaiti, DPIA, kur tas ir būtiski, juridisko pienākumu reģistru, politikas, Piemērojamības paziņojumu un esošo uzņēmuma riska apetītes paziņojumu.

Tas atbilst ISO/IEC 27001:2022 4., 6. un 8. punktam un NIST CSF profilu metodēm, kas sākas ar biznesa prioritātēm, riska prioritātēm, prasībām, drošības pasākumiem un lomām.

2. solis: definējiet ietekmes skalas, kas ietver regulējumu

Izmantojot Zenith Blueprint 10. soli, definējiet iespējamību un ietekmi biznesa valodā. Iekļaujiet finanšu zaudējumus, darbības traucējumus, ietekmi uz klientiem, reputācijas kaitējumu, tiesisko un regulatīvo ietekmi, kaitējumu datu subjektam un ietekmi uz kritisku funkciju.

Piemēram, “būtiska” ietekme var ietvert ilgstošu kritiska pakalpojuma nepieejamību, apstiprinātu personas datu aizsardzības pārkāpumu, par kuru jāziņo, DORA incidentu ziņošanas pienākuma neizpildi vai piegādātāja atteici, kas ietekmē kritisku vai svarīgu funkciju.

3. solis: formulējiet apetīti pa jomām

Neveidojiet vienu vispārīgu kiberriska apetīti. Definējiet tādas jomas kā kritisku pakalpojumu pieejamība, personas datu konfidencialitāte, datu integritāte, privileģēta piekļuve, trešo pušu IKT atkarība, mākoņpakalpojumu koncentrācija, ievainojamību ekspozīcija, gatavība incidentu ziņošanai, rezerves kopijas un atjaunošana, kā arī drošas izstrādes izmaiņu risks.

Katrai jomai uzrakstiet vienu apetītes paziņojumu, vienu vai vairākas tolerances robežvērtības un eskalācijas kritērijus.

4. solis: sasaistiet riska apstrādi ar Piemērojamības paziņojumu

Zenith Blueprint 13. solis norāda organizācijām izvēlēties riska apstrādes iespējas: mazināt, izvairīties, pārnest vai pieņemt. Tas uzsver arī vadības apstiprinājumu:

“Riska apstrādes lēmumi un SoA jāpārskata un jāapstiprina augstākajai vadībai.”

DORA un NIS2 vajadzībām tas ir pierādījums, ka vadības struktūra vai deleģētā vadība ir pārskatījusi galvenos riskus, apstrādes pasākumus un pieņemto atlikušo riska ekspozīciju. GDPR vajadzībām tas atbalsta pārskatatbildību, parādot, kāpēc izvēlētie pasākumi bija atbilstoši riskam.

5. solis: reģistrējiet pieņemšanu ar termiņu un nosacījumiem

Katram pieņemtam vidējam vai augstam atlikušajam riskam jāietver:

• Riska ID un īpašnieks
• Biznesa pamatojums
• Atsauce uz apetītes paziņojumu
• Ietekmētā tolerances robežvērtība
• Tiesiskā un regulatīvā analīze
• Kompensējošie kontroles pasākumi
• Beigu vai pārskatīšanas datums
• Apstiprinātājs
• Pierādījumu atrašanās vieta
• Kritērijs lēmuma atkārtotai atvēršanai

Risku pārvaldības politika MVU nosaka:

“Jebkurš lēmums pieņemt augstu vai vidēju risku vai atlikt tā apstrādi jādokumentē Riska reģistrā. Šajā dokumentācijā jāiekļauj:”

Uzņēmuma vidēs tas kļūst par apstiprināšanas darbplūsmu un riska komitejas materiālu paketi. Mazākās organizācijās tā var būt strukturēta riska reģistra cilne ar vadības apstiprinājumu. Mērķis nav birokrātija. Mērķis ir aizstāvamība.

Incidentu tolerance: kur apetīte satiekas ar pulksteni

Riska apetīte incidentu laikā kļūst reāla.

DORA Article 17 prasa finanšu vienībām izveidot ar IKT saistītu incidentu pārvaldības procesu, lai atklātu, pārvaldītu un paziņotu incidentus, reģistrētu visus incidentus un nozīmīgus kiberdraudus, identificētu pamatcēloņus, izmantotu agrīnās brīdināšanas indikatorus, klasificētu incidentus pēc prioritātes, smaguma pakāpes un pakalpojuma kritiskuma, piešķirtu lomas, komunicētu ar iesaistītajām pusēm, eskalētu vismaz būtiskus ar IKT saistītus incidentus augstākajai vadībai un vadības struktūrai un savlaicīgi atjaunotu drošas darbības.

DORA Article 18 klasificē incidentus, izmantojot tādus faktorus kā ietekmētie klienti, ilgums, dīkstāve, ģeogrāfiskā izplatība, datu zudumi, kas ietekmē pieejamību, autentiskumu, integritāti vai konfidencialitāti, ietekmēto pakalpojumu kritiskums un ekonomiskā ietekme. Article 19 prasa būtiskus ar IKT saistītus incidentus ziņot kompetentajai iestādei, informējot klientus, ja tiek ietekmētas viņu finansiālās intereses.

NIS2 Article 23 paredz pakāpenisku ziņošanu par nozīmīgiem incidentiem, tostarp agrīno brīdinājumu bez nepamatotas kavēšanās un, ja piemērojams, 24 stundu laikā, incidenta paziņojumu bez nepamatotas kavēšanās un, ja piemērojams, 72 stundu laikā, starpposma atjauninājumus pēc pieprasījuma un gala ziņojumu ne vēlāk kā vienu mēnesi pēc incidenta paziņojuma. Nozīmīgi incidenti ietver tādus, kas izraisa smagus darbības traucējumus, finanšu zaudējumus vai materiālu vai nemateriālu kaitējumu citām personām.

Apetītes paziņojumam jādefinē eskalācijas robežvērtības pirms incidenta iestāšanās.

Annex A kontroles pasākumi, kas saistīti ar incidentu plānošanu, informācijas drošības notikumu izvērtēšanu, reaģēšanu uz incidentiem, mācīšanos no incidentiem, pierādījumu vākšanu, informācijas drošības uzturēšanu traucējumu laikā un IKT gatavību darbības nepārtrauktībai, atbalsta šīs robežvērtības. NIST CSF rezultāti IDENTIFY, PROTECT, DETECT, RESPOND un RECOVER jomās atbalsta to pašu operacionālo modeli, tostarp rezerves kopijas, uzraudzību, incidenta deklarēšanu, eskalāciju, pamatcēloņa analīzi, saziņu ar iesaistītajām pusēm un atjaunošanas verifikāciju.

Piegādātāju un mākoņpakalpojumu tolerance, ko valdes bieži palaiž garām

DORA padara IKT trešo pušu risku par pamatatbilstības pienākumu. Article 28 prasa finanšu vienībām pārvaldīt IKT trešo pušu risku kā daļu no IKT riska pārvaldības ietvara, vienlaikus saglabājot pilnu atbildību par atbilstību. Tas prasa IKT trešo pušu riska stratēģiju, IKT pakalpojumu līgumisko vienošanos reģistrus, kritiskas vai svarīgas funkcijas atbalstošu pakalpojumu nošķiršanu, ikgadēju ziņošanu, plānoto vienošanos paziņošanu, pirmslīguma izvērtējumus, sākotnējo izpēti, audita un pārbaudes tiesības, izbeigšanas tiesības un dokumentētas izstāšanās stratēģijas.

Article 29 pievieno koncentrācijas riska analīzi, tostarp neaizstājamību, vairākas atkarības no viena un tā paša vai saistītiem pakalpojumu sniedzējiem, apakšuzņēmēju riskus, trešo valstu apakšuzņēmējus, atbilstību datu aizsardzībai, izpildāmību un sarežģītas apakšuzņēmēju ķēdes. Article 30 prasa rakstiskas līgumiskās tiesības un pienākumus, pakalpojumu aprakstus, atrašanās vietas, drošības aizsardzības pasākumus, piekļuvi datiem un datu atgriešanu, pakalpojumu līmeņus, palīdzību incidentu gadījumā, sadarbību ar iestādēm, izbeigšanas tiesības, testētus ārkārtas rīcības plānus, uzraudzības un izstāšanās kārtību.

Valdes apstiprināts piegādātāju tolerances paziņojums varētu būt šāds:

“Mums ir zema apetīte pret kritisku vai svarīgu funkciju atkarību no IKT trešās puses pakalpojumu sniedzēja, ja mums nav līgumisku audita tiesību, testētu izstāšanās pasākumu, incidentu paziņošanas pienākumu, pakalpojumu līmeņa mērķu, datu atgriešanas tiesību vai redzamības par būtisku apakšuzņēmēju piesaisti.”

Šis teikums dod iepirkumam praktisku noteikumu. Ja līgums neatbilst robežvērtībai, projekta komanda risku nevar klusi pieņemt.

Kā auditori testēs jūsu IKT riska apetīti

Spēcīgs apetītes paziņojums tiek veidots, domājot par auditu.

Zenith Blueprint 28. solis audita, pārskatīšanas un uzlabošanas posmā pastiprina vadības pārskatīšanas slāni. Tas organizācijām norāda apkopot ievaddatus, piemēram, izmaiņas ārējos un iekšējos jautājumos, ISMS sniegumu, audita rezultātus, uzraudzību un mērījumus, incidentus, neatbilstības, uzlabošanas iespējas un resursu vajadzības. Tas arī nosaka, ka vadības pārskatīšanai jārezultējas lēmumos un darbībās, nevis tikai prezentācijās.

Vismaz reizi gadā un ikreiz, kad notiek būtiskas izmaiņas, vadībai jāpārskata, vai tolerances robežvērtības joprojām atbilst biznesa modelim, vai incidenti pārsniedza apetīti, vai pieņemtie riski paliek apstiprinātajās robežās, vai jaunas DORA, NIS2, GDPR vai līgumiskās prasības mainīja pamatlīmeni, vai piegādātāji paliek koncentrācijas tolerances robežās un vai KRI izraisa savlaicīgu eskalāciju.

Ja atbilde ir nē, jāmaina apetītes paziņojums vai kontroles pasākumi.

Biežākie kļūdu modeļi 2026. gada gatavības darbā

DORA, NIS2, GDPR un ISO/IEC 27001:2022 projektos atkārtoti parādās vienas un tās pašas vājās vietas:

• Apetīte bez robežvērtībām, kad valde apstiprina paziņojumu, bet neviens nevar pateikt, kad tas ir pārkāpts.
• Robežvērtības bez pilnvarām, kad smaguma pakāpes līmeņi pastāv, bet riska īpašnieki var pieņemt izņēmumus bez augstākās vadības apstiprinājuma.
• Tiesiskais risks ārpus vērtēšanas modeļa, kad GDPR, DORA, NIS2 un līgumi ir uzskaitīti atsevišķi, bet nav iestrādāti ietekmes kritērijos.
• Piegādātāju tolerance nav iekļauta valdes materiālu paketē, lai gan kritiskās IKT atkarības ir zināmas iepirkumam vai IT.
• Vadības pārskatīšana kā formalitāte, kad tiek prezentēti slaidi, bet lēmumi, darbības, resursu vajadzības un riska pieņemšanas netiek dokumentētas.
• Audita pierādījumu fragmentācija, kad politikas, reģistri, KRI, incidentu pārskati, piegādātāju pārskatīšanas un valdes protokoli atrodas dažādās vietās bez savstarpējām atsaucēm.

Clarysec pieeja ir izstrādāta, lai šīs plaisas novērstu. Zenith Blueprint nodrošina posmos strukturētu ieviešanas ceļu. Risku pārvaldības politika un Risku pārvaldības politika MVU nodrošina pārvaldības punktus, kas mērogojami uzņēmuma un MVU vidēm. Zenith Controls kartē kontroles mugurkaulu starp informācijas drošības politiku, vadības atbildību un tiesiskajām vai regulatīvajām prasībām, padarot pierādījumus atkārtoti izmantojamus ISO/IEC 27001:2022, DORA, NIS2, GDPR, NIST CSF un COBIT tipa apliecinājuma vajadzībām.

Pārvērtiet valdes nodomu auditējamā IKT riska pārvaldībā

Ja jūsu organizācijai ir riska reģistrs, bet tā nevar uzrādīt valdes apstiprinātu IKT riska apetīti, izmērāmas tolerances robežvērtības, eskalācijas kritērijus un formālus pieņemšanas noteikumus, plaisa nav kosmētiska. Tā ietekmē DORA pārvaldību, NIS2 vadības pārskatatbildību, GDPR Article 32 aizstāvamību un ISO/IEC 27001:2022 gatavību auditam.

Praktisks nākamais solis ir īstenot fokusētu IKT riska apetītes darbnīcu, izmantojot Clarysec rīkkopu:

1. Izmantojiet Zenith Blueprint 10. soli, lai definētu riska kritērijus un ietekmes skalas.
2. Izmantojiet Zenith Blueprint 13. soli, lai sasaistītu riska apstrādes iespējas, atlikušo risku un Piemērojamības paziņojuma apstiprināšanu.
3. Izmantojiet Zenith Blueprint 14. soli, lai krusteniski sasaistītu GDPR, NIS2 un DORA pienākumus.
4. Izmantojiet Zenith Blueprint 28. soli, lai apetīti, KRI, pieņemtos riskus un resursu lēmumus iekļautu vadības pārskatīšanā.
5. Piemērojiet Risku pārvaldības politiku vai Risku pārvaldības politiku MVU, lai formalizētu apstiprināšanas un pieņemšanas noteikumus.
6. Izmantojiet Zenith Controls, lai kartētu pārvaldības kontroles pasākumus ar audita pierādījumiem un savstarpējās atbilstības gaidām.

Clarysec var palīdzēt pārvērst izkaisītus riska artefaktus valdes apstiprinātā, regulatoram gatavā IKT riska apetītes modelī, ko jūsu komandas var izmantot, kad nākamais mākoņpakalpojuma pārtraukums, piegādātāja atteice, ievainojamības izpaušana vai personas datu incidents pārbaudīs organizācijas faktisko toleranci.