DORA IKT-riskivalmidus: juhtorgani heakskiidu juhend 2026. aastaks

On teisipäeva hommik kell 08.15 ja keskmise suurusega maksetehnoloogia ettevõtte infoturbejuht seisab nõupidamisruumi ukse taga, tahvelarvutis avatud kolm dokumenti.

Esimene on IKT-riskiregister. Selles on 137 rida, värvikoodidega hinnangud ja mitu kõrget riski, mis on seotud pilveteenuste kontsentratsiooniga, privilegeeritud juurdepääsuga, lunavarast taastumisega, kliendiandmete avalikuks saamisega ja tarnija intsidentidele reageerimisega. Teine on DORA valmisoleku jälgija. Selle järgi on ettevõttel poliitikad, intsidendiprotseduurid, kolmandate osapoolte registrid ja tegevuskerksuse testimise plaanid. Kolmas on juhtorgani materjal regulatiivseks kohtumiseks.

Esimehel on üks küsimus ja see ei ole tehniline:

„Millise IKT-riski taseme oleme tegelikult kokku leppinud aktsepteerida?“

Ruum jääb vaikseks, sest ettevõttel on riskihindamised, kuid mitte juhtorgani heakskiidetud IKT-riskivalmidust. Ettevõttel on mõjuhinnangud, kuid mitte mõõdetavaid taluvuslävendeid. On eskaleerimiskoosolekud, kuid puudub ametlik käivitustingimus, mis määraks, millal küberrisk muutub juhtorgani otsuseks. Jääkriske on aktsepteeritud, kuid osa neist on põhjendatud kui „äriotsused“ ilma selge seoseta riskikriteeriumide, GDPR Article 32 proportsionaalsuse, DORA taluvusootuste või NIS2 juhtkonna vastutusega.

See lünk on 2026. aastal üha nähtavam. DORA kohaldub alates 17. jaanuarist 2025 ja nõuab, et finantsettevõtted hoiaksid toimivana IKT-riski juhtimise ja kontrolliraamistikku, sealhulgas juhtorgani vastutust IKT-riski juhtimise raamistiku, digitaalse tegevuskerksuse strateegia ja IKT-riski taluvuse eest. NIS2 suunab juhtorganeid küberturbe riskijuhtimismeetmeid heaks kiitma ja nende rakendamise üle järelevalvet tegema. GDPR Article 32 nõuab riskipõhiseid asjakohaseid tehnilisi ja korralduslikke turvameetmeid. ISO/IEC 27001:2022 annab juhtimissüsteemi toimemehhanismi: kontekst, huvitatud pooled, riskikriteeriumid, käsitlusplaanid, dokumenteeritud teave ja juhtkonna läbivaatus.

Puuduv ühenduslüli on IKT-riskivalmiduse ja riskitaluvuse avaldus, mida juhtorgan suudab mõista, heaks kiita, vaidlustada ja kasutada.

See juhend selgitab, kuidas see ühendus luua, kasutades Claryseci Zenith Blueprint: audiitori 30-sammuline teekaart, Claryseci Riskijuhtimise poliitikat, Claryseci VKE-de riskijuhtimise poliitikat ja Zenith Controls: ristvastavuse juhendit.

Miks riskiregister ei ole riskivalmidus

Paljud organisatsioonid ajavad riskiregistri segi riskijuhtimisega. Riskiregister näitab, millised riskid eksisteerivad, kuidas neid hinnatakse, kes nende eest vastutab ja milline käsitlus on kavandatud. See ei vasta automaatselt juhtorgani tasandi küsimustele, millele DORA, NIS2, GDPR ja ISO/IEC 27001:2022 eeldavad juhtidelt vastuseid.

Küps IKT-riskivalmiduse avaldus vastab muu hulgas järgmistele küsimustele:

• Millised IKT-riskid on kulust sõltumata lubamatud?
• Millist tööseisakut saab organisatsioon kriitilise või olulise funktsiooni puhul taluda?
• Milline andmekao või andmete tervikluse kahjustamise tase jääb väljapoole riskivalmidust?
• Milline kolmanda osapoole kontsentratsioonirisk nõuab juhtorgani tähelepanu?
• Kes võib aktsepteerida IKT jääkriski ja millisel tasemel?
• Millal tuleb risk eskaleerida kõrgemale juhtkonnale või juhtorganile?
• Kuidas on õiguslikud, regulatiivsed ja lepingulised nõuded riskikriteeriumidesse lõimitud?

DORA kontekstis ei ole see vabatahtlik juhtimise täiendus. Article 5 nõuab, et juhtorgan määratleks, kiidaks heaks, jälgiks ja vastutaks IKT-riski juhtimise raamistiku eest, sealhulgas digitaalse tegevuskerksuse strateegia ja IKT-riski taluvuse eest. Article 6 nõuab dokumenteeritud IKT-riski juhtimise raamistikku, iga-aastast läbivaatust mitte-mikroettevõtetele, siseauditit, kriitiliste auditileidude kõrvaldamist ning digitaalse tegevuskerksuse strateegiat koos IKT-eesmärkide, riskitaluvuse, mõjitaluvuse, arhitektuuri, testimise ning intsidentidega seotud kommunikatsioonistrateegiaga.

NIS2 lisab paralleelse vastutusmudeli. Article 20 nõuab oluliste ja tähtsate üksuste juhtorganitelt küberturbe riskijuhtimismeetmete heakskiitmist, rakendamise järelevalvet ja koolituse läbimist. Article 21 nõuab kõiki ohte hõlmaval lähenemisel põhinevaid asjakohaseid ja proportsionaalseid tehnilisi, operatiivseid ja korralduslikke meetmeid, sealhulgas riskianalüüsi, intsidentide käsitlemist, talitluspidevust, tarneahela turvet, turvalist arendust, kontrollimeetmete tõhusust, koolitust, krüptograafiat, personaliturvet, juurdepääsukontrolli, varahaldust ja vajaduse korral mitmetegurilist autentimist.

Finantsettevõtete puhul käsitatakse DORA-t sektoripõhise liidu õigusaktina seal, kus kattuvad NIS2 kohustused on kohaldatavad. Praktikas tõrjub DORA üldjuhul oma kohaldamisalasse kuuluvate finantsettevõtete puhul kattuvad NIS2 riskijuhtimise ja intsidentidest teatamise nõuded kõrvale, samas kui NIS2 jääb oluliseks koordineerimiseks ja teenuseosutajate jaoks, kes ei kuulu DORA otseste finantsettevõtete kohustuste alla. SaaS-i, pilveteenuste, hallatud teenuste ja hallatud turvateenuste pakkujatele võib NIS2 kohalduda otse, kui kohaldamisala tingimused on täidetud.

Seetõttu ei ole juhtorgani heakskiidetud IKT-riskivalmidus enam finantsriski artefakt. See on küberturbe juhtimise kontrollimeede.

Kasuta ISO/IEC 27001:2022 standardit toimemudelina

DORA ja NIS2 ütlevad juhtidele, mida tuleb juhtida. ISO/IEC 27001:2022 annab organisatsioonidele praktilise toimemudeli selle juhtimiseks.

ISO/IEC 27001:2022 punktid 4.1 kuni 4.4 nõuavad, et organisatsioon määratleks konteksti, huvitatud pooled, nõuded, ISMS-i kohaldamisala ja ISMS-i protsessid. See on oluline, sest DORA, NIS2, GDPR, lepingud, järelevalveootused, kliendid, pilveteenuse pakkujad ja allhankekorraldused muutuvad kõik nõueteks, mis mõjutavad riskikriteeriume.

Punktid 5.1 kuni 5.3 nõuavad juhtkonna pühendumust, poliitikate kooskõla, ressursse, vastutusi ja ISMS-i toimivuse aruandlust tippjuhtkonnale. Punktid 6.1.1 kuni 6.1.3 nõuavad riskipõhist planeerimist, dokumenteeritud riskihindamise protsessi, riski aktsepteerimise kriteeriume, järjepidevaid hindamiskriteeriume, riskiomanikke, võrdlust riskikriteeriumidega, käsitluse kavandamist, kohaldatavusavaldust ja jääkriski heakskiitu.

See on DORA IKT-riski taluvuse alus.

Riskijuhtimise etapis juhendab Zenith Blueprint 10. samm organisatsioone määratlema riskikriteeriumid enne riskide hindamist:

„Riskikriteeriumid on reeglid ja võrdlusalused, mida teie organisatsioon kasutab iga riski olulisuse hindamiseks. Nende kriteeriumide eelnev kehtestamine tagab, et kõik kasutavad sama riskikeelt.“

Sama samm hoiatab, et regulatiivne mõju tuleb riskimääratlustesse lõimida:

„Iga risk, mis võib viia kohaldatavate seaduste (GDPR jne) nõuete rikkumiseni, ei ole aktsepteeritav ja tuleb maandada.“

Zenith Blueprint annab ka praktilised suunised mõju skaleerimiseks:

„Mõju määratlemisel on mõistlik siduda tasemed teie konkreetse äritegevuse mastaabiga. Näiteks: „suur finantsmõju = kahju > 100 000 USD“ (kohandage oma kontekstile). Arvestage ka regulatiivset mõju: näiteks isikuandmete rikkumine võib GDPR trahvide ja teavitamisnõuete tõttu olla automaatselt „suur“ või „väga tõsine“, isegi kui otsene rahaline kahju ei ole selge. Samamoodi võib NIS2 kohaldamisalasse kuulumisel (olulised teenused) teenusekatkestust põhjustav intsident olla õiguslike tagajärgede tõttu vähemalt „suur“. Lisage sellised kaalutlused oma määratlustesse.“

See juhis hoiab ära levinud vea: küberrisk hinnatakse mõõdukaks, sest vahetu rahaline kahju paistab väike, kuid õiguslikku, talitluspidevuse, andmesubjekti või kliendimõju eiratakse.

Juhtorgani jaoks valmis mudel peaks eristama nelja kihti:

Selline struktuur muudab riskivalmiduse auditeeritavaks, sest iga avaldust saab seostada riskikriteeriumide, kontrollimeetmete, tõendusmaterjali ja otsustega.

Juhtorgani jaoks valmis DORA IKT-riskivalmiduse avaldus

Tugev IKT-riskivalmiduse avaldus peab olema piisavalt lühike, et juhtorgan selle heaks kiidaks, piisavalt konkreetne, et juhtkond seda rakendaks, ja piisavalt mõõdetav, et audiitorid seda kontrolliksid. See peaks vältima žargooni, kuid ei tohi olla ebamäärane.

Praktiline kõrgetasemeline avaldus võib olla järgmine:

„Meie ettevõttel on madal riskivalmidus IKT-riskide suhtes, mis võivad põhjustada olulist kahju klientidele, kriitiliste või oluliste funktsioonide häireid, reguleeritud andmete loata avalikustamist või muutmist, õiguslike kohustuste täitmata jätmist või kriitiliste kolmandate osapoolte IKT-teenuste tegevuskerksuse kadu.“

See avaldus vajab seejärel mõõdetavaid taluvuslävendeid ja eskaleerimise aluseid.

See tabel muudab arutelu. Juhtorgan ei kiida enam heaks loosungit. Ta kiidab heaks tegevuspiirid käideldavuse, konfidentsiaalsuse, tervikluse, tarnijate, haavatavuste, taastamise ja vastavuse kohta.

Claryseci Riskijuhtimise poliitika toetab seda juhtimismudelit. Ettevõtte poliitika sätestab:

„Kiidab heaks riskijuhtimise raamistiku ning määratleb aktsepteeritava riskivalmiduse ja taluvuslävendid.“

Punkt 6.2.1 muudab mõõtmisnõude selgesõnaliseks:

„Riske hinnatakse tõenäosuse ja mõju alusel, kasutades standardset riskimaatriksit koos selgelt määratletud hindamisskaaladega.“

Punkt 6.3.4 loob aktsepteerimisreegli, mida audiitorid eeldavad:

„Käsitlemata aktsepteeritud riskid tuleb kirjalikult põhjendada, siduda organisatsiooni riskivalmidusega ja kinnitada asjakohasel tasemel.“

VKE-de puhul säilitab VKE-de riskijuhtimise poliitika sama juhtimispõhimõtte lihtsamas vormis:

„Tagada juhtkonna osalus riskitaluvuse ja peamiste riskikäsitlusplaanide heakskiitmisel.“

See nõuab ka kõrgete riskide eskaleerimist:

„Kõrged riskid tuleb otsustamiseks eskaleerida tegevjuhile.“

See on proportsionaalsus praktikas. DORA Article 4 nõuab nõuete kohaldamist viisil, mis on proportsionaalne suuruse, riskiprofiili ning teenuste laadi, ulatuse ja keerukusega. ISO/IEC 27001:2022 võimaldab sama põhimõtet kohaldamisala, konteksti, riskikriteeriumide ja käsitlusotsuste kaudu. Juhtimisstandard ei tähenda, et igal organisatsioonil peab olema sama komiteestruktuur. Juhtimisstandard tähendab, et riskivalmidus, taluvus, eskaleerimine ja aktsepteerimine on määratletud, heaks kiidetud, tõendatud ja kasutusel.

GDPR Article 32 muudab riskikäsitlust

GDPR Article 32 käsitatakse sageli tehnilise turbeklauslina. Juhtimise vaates on see ka riskivalmiduse säte.

Article 32 nõuab, et vastutavad töötlejad ja volitatud töötlejad rakendaksid asjakohaseid tehnilisi ja korralduslikke meetmeid, et tagada riskile vastav turvalisuse tase. See riskipõhine lähenemine arvestab tehnika taset, rakendamise kulusid, töötlemise laadi, ulatust, konteksti ja eesmärke ning füüsiliste isikute õigustele ja vabadustele avalduvaid riske.

See mõjutab IKT-riskivalmidust kolmel viisil.

Esiteks ei saa isikuandmete mõju taandada rahalisele kahjule. Väikese andmebaasi avalikuks saamisel võib otsene kulu olla piiratud, kuid konfidentsiaalsuse, identiteedi, pettuse, diskrimineerimise või õigustele avalduva mõju tagajärjed võivad olla tõsised. Kui kaasatud on isikuandmete eriliigid, näiteks tervise-, biomeetrilised või geneetilised andmed, peab riskivalmidus olema oluliselt madalam.

Teiseks peavad töötlemisrollid olema seotud riskivastutusega. GDPR eristab vastutavaid töötlejaid ja volitatud töötlejaid. DORA eristab finantsettevõtteid ja kolmandatest osapooltest IKT-teenuseosutajaid. NIS2 eristab olulisi ja tähtsaid üksusi. ISO/IEC 27001:2022 nõuab riskiomanikke. Küps riskivalmiduse avaldus peaks määrama, kes vastutab riskiotsuste eest, mis puudutavad isikuandmeid, allhanke korras töötlemist, kriitilisi teenuseid ja piiriüleseid sõltuvusi.

Kolmandaks peab Article 32 proportsionaalsus olema nähtav kontrollimeetmete valikus. Krüptimine, pseudonüümimine, juurdepääsukontroll, varundamine, logimine, seire, intsidendile reageerimine ja tegevuskerksus ei ole eraldiseisvad tehnilised ülesanded. Need on käsitlusmeetmed, mis valitakse seetõttu, et risk ületas riskivalmiduse või taluvuse.

Claryseci Riskijuhtimise poliitika seob selle selgesõnaliselt:

„Article 32: nõuab riskipõhist lähenemist turvameetmetele, mida täidetakse mõjupõhiste riskihindamiste ja kontrollimeetmete valiku kaudu.“

See on operatiivne seos, mida audiitorid otsivad: Article 32 nõue, riskihindamine, riskihinnang, käsitlusplaan, kontrollimeetme valik, jääkrisk ja heakskiit.

Kuidas Zenith Controls toetab ristvastavuse tõendusmaterjali

Juhtorgani heakskiidetud riskivalmiduse avaldus muutub mõjusaks siis, kui see on kaardistatud kontrollimeetmetega. Zenith Controls toimib Claryseci ristvastavuse juhendina, aidates meeskondadel taaskasutada tõendusmaterjali ISO/IEC 27001:2022, DORA, NIS2, GDPR, NIST CSF ja COBIT-stiilis kindlustandvate tegevuste jaoks.

Eriti olulised on kolm ISO/IEC 27002:2022 kontrollivaldkonda:

See ei ole paberil kaardistamise harjutus. See muudab otsuste tegemist.

Kui ärivaldkonna omanik palub aktsepteerida administraatorite MFA juurutuse edasilükkamist, aitab Zenith Controls infoturbejuhil näidata, miks see ei ole ainult juurdepääsukontrolli küsimus. See puudutab poliitika juhtimist, juhtkonna vastutust, õiguslikke ja regulatiivseid nõudeid, GDPR töötlemise turvalisust, DORA IKT-riski juhtimist, NIS2 küberturbemeetmeid, intsidendi mõju ja audititõendusmaterjali.

Kui tootemeeskond soovib käivitada teenuse uuel ELi turul, kasutades uut pilveteenust, toob ISO/IEC 27002:2022 kontrollimeede 5.31 õiguslike ja regulatiivsete nõuete läbivaatuse ISMS-i kohaldamisalasse. ISO/IEC 27001:2022 punkt 4.2 nõuab huvitatud poolte nõuete tuvastamist, sealhulgas õiguslike, regulatiivsete ja lepinguliste kohustuste tuvastamist. Punkt 8.1 nõuab tegevuse planeerimist ja ohjet, sealhulgas ISMS-i jaoks oluliste väliselt pakutavate protsesside, toodete või teenuste kontrolli.

Eesmärk on üks riskikeel, mitte eraldi vastavusmurded.

Heakskiitmise töövoog: kes mida otsustab

Infoturbejuht võib IKT-riskivalmiduse välja pakkuda, kuid selle eest peab vastutama juhtorgan. See vastutus vajab töövoogu.

See on kooskõlas ka NIST CSF 2.0-ga. Funktsioon GOVERN, eriti GV.RM, eeldab kokkulepitud riskijuhtimise eesmärke, riskivalmiduse ja taluvuse avaldusi, riskitegevuste integreerimist ettevõtte riskijuhtimisse, määratletud riskivastuse valikuid, suhtlusliine ning standardseid meetodeid küberriskide arvutamiseks, dokumenteerimiseks, kategoriseerimiseks ja prioriseerimiseks. GV.RR eeldab juhtkonna vastutust, rolle, volitusi ja ressursse, mis on kooskõlas riskistrateegiaga. GV.PO eeldab, et poliitikad on kehtestatud, teatavaks tehtud, rakendatud, läbi vaadatud ja ajakohastatud.

COBIT 19 ja ISACA-stiilis kindlustandvate tegevuste spetsialistid küsivad, kas riskivalmidus on integreeritud teabe ja tehnoloogia ettevõtte juhtimisse, mitte üksnes lisatud küberpoliitika lisana.

Koosta IKT-riskivalmiduse pakett ühe tööseansiga

Praktiline IKT-riskivalmiduse töötuba võib viia organisatsiooni hajutatud registritest auditeeritava juhtorgani paketini.

1. samm: kogu õiged sisendid

Valmista ette kehtiv IKT-riskiregister, ärimõju analüüs, taaste-eesmärgid, kriitiliste või oluliste funktsioonide loend, IKT-varade register, IKT-teenuste register, tarnijate ja pilvesõltuvuste register, intsidentide klassifitseerimiskriteeriumid, GDPR töötlemistoimingute register, asjakohased DPIA-d, õiguslike kohustuste register, poliitikad, kohaldatavusavaldus ja olemasolev ettevõtte riskivalmiduse avaldus.

See on kooskõlas ISO/IEC 27001:2022 punktidega 4, 6 ja 8 ning NIST CSF profiilimeetoditega, mis lähtuvad äriprioriteetidest, riskiprioriteetidest, nõuetest, kaitsemeetmetest ja rollidest.

2. samm: määra mõju skaalad, mis hõlmavad regulatiivset mõju

Kasutades Zenith Blueprint 10. sammu, määratle tõenäosus ja mõju ärikeeles. Kaasa rahaline kahju, tegevushäire, kliendimõju, mainekahju, õiguslik ja regulatiivne mõju, andmesubjekti kahju ning kriitilise funktsiooni mõju.

Näiteks võib „suur“ mõju hõlmata kriitilise teenuse pikaajalist katkestust, kinnitatud isikuandmetega seotud rikkumist, mis nõuab teavitamist, DORA intsidendist teatamise kohustuse täitmata jätmist või tarnija riket, mis mõjutab kriitilist või olulist funktsiooni.

3. samm: kirjuta riskivalmidus valdkondade kaupa

Ära loo ühte üldist küberriskivalmidust. Määratle valdkonnad, nagu kriitilise teenuse käideldavus, isikuandmete konfidentsiaalsus, andmete terviklus, privilegeeritud juurdepääs, kolmanda osapoole IKT-sõltuvus, pilvekontsentratsioon, haavatavuse kokkupuude, valmisolek intsidentidest teatamiseks, varundamine ja taastamine ning turvalise arenduse muudatusrisk.

Iga valdkonna kohta kirjuta üks riskivalmiduse avaldus, üks või mitu taluvuslävendit ja eskaleerimise alus.

4. samm: seo käsitlus kohaldatavusavaldusega

Zenith Blueprint 13. samm juhendab organisatsioone valima riskikäsitluse valikud: maandada, vältida, üle kanda või aktsepteerida. Samuti rõhutab see juhtkonna heakskiitu:

„Riskikäsitluse otsused ja SoA peavad olema läbi vaadatud ja tippjuhtkonna poolt heaks kiidetud.“

DORA ja NIS2 jaoks on see tõendusmaterjal, et juhtorgan või delegeeritud juhtkond vaatas üle peamised riskid, käsitlused ja aktsepteeritud jääkkokkupuute. GDPR puhul toetab see vastutust, näidates, miks valitud meetmed olid riskile vastavad.

5. samm: registreeri aktsepteerimine aegumistähtaja ja tingimustega

Iga aktsepteeritud keskmine või kõrge jääkrisk peaks sisaldama järgmist:

• Riski ID ja omanik
• Äriline põhjendus
• Viide riskivalmiduse avaldusele
• Mõjutatud taluvuslävend
• Õiguslik ja regulatiivne analüüs
• Kompenseerivad kontrollimeetmed
• Aegumis- või läbivaatamise kuupäev
• Heakskiitja
• Tõendusmaterjali asukoht
• Otsuse uuesti avamise alus

VKE-de riskijuhtimise poliitika sätestab:

„Iga otsus aktsepteerida kõrge või keskmine risk või lükata selle käsitlus edasi tuleb dokumenteerida riskiregistris. See dokumentatsioon peab sisaldama:“

Ettevõttekeskkondades kujuneb sellest kinnitamise töövoog ja riskikomitee pakett. Väiksemates organisatsioonides võib see olla struktureeritud riskiregistri vahekaart koos juhtkonna kinnitusega. Eesmärk ei ole bürokraatia. Eesmärk on kaitstavus.

Intsidenditaluvus: kus riskivalmidus kohtub kellaga

Riskivalmidus muutub tegelikuks intsidentide ajal.

DORA Article 17 nõuab, et finantsettevõtted kehtestaksid IKT-ga seotud intsidendihalduse protsessi intsidentide tuvastamiseks, haldamiseks ja neist teatamiseks, kõigi intsidentide ja oluliste küberohtude registreerimiseks, algpõhjuste tuvastamiseks, varajase hoiatuse indikaatorite kasutamiseks, intsidentide klassifitseerimiseks prioriteedi, tõsiduse ja teenuse kriitilisuse järgi, rollide määramiseks, sidusrühmadega suhtlemiseks, vähemalt suuremate IKT-ga seotud intsidentide eskaleerimiseks kõrgemale juhtkonnale ja juhtorganile ning turvalise tegevuse õigeaegseks taastamiseks.

DORA Article 18 klassifitseerib intsidente selliste tegurite alusel nagu mõjutatud kliendid, kestus, seisak, geograafiline ulatus, andmekaod, mis mõjutavad käideldavust, autentsust, terviklust või konfidentsiaalsust, mõjutatud teenuste kriitilisus ja majanduslik mõju. Article 19 nõuab suuremate IKT-ga seotud intsidentide teatamist pädevale asutusele ning klientide teavitamist, kui nende finantshuvid on mõjutatud.

NIS2 Article 23 näeb oluliste intsidentide puhul ette etapiviisilise teatamise, sealhulgas varajase hoiatuse põhjendamatu viivituseta ja kohaldataval juhul 24 tunni jooksul, intsidenditeate põhjendamatu viivituseta ja kohaldataval juhul 72 tunni jooksul, vahearuanded nõudmisel ning lõpparuande hiljemalt ühe kuu jooksul pärast intsidenditeadet. Olulised intsidendid hõlmavad neid, mis põhjustavad tõsise tegevushäire, rahalise kahju või olulise varalise või mittevaralise kahju teistele isikutele.

Riskivalmiduse avaldus peab määratlema eskaleerimislävendid enne intsidendi toimumist.

Annex A kontrollimeetmed, mis puudutavad intsidendiplaneerimist, infoturbesündmuste hindamist, intsidentidele reageerimist, intsidentidest õppimist, tõendite kogumist, infoturbe säilitamist häire ajal ja IKT valmisolekut talitluspidevuseks, toetavad kõiki neid lävendeid. NIST CSF tulemused üle funktsioonide IDENTIFY, PROTECT, DETECT, RESPOND ja RECOVER toetavad sama toimemudelit, sealhulgas varukoopiaid, seiret, intsidendi väljakuulutamist, eskaleerimist, algpõhjuse analüüsi, sidusrühmade teavitamist ja taastamise verifitseerimist.

Tarnija- ja pilvetaluvus, mille juhtorganid sageli tähelepanuta jätavad

DORA muudab kolmandate osapoolte IKT-riski keskseks vastavuskohustuseks. Article 28 nõuab, et finantsettevõtted juhiksid kolmandate osapoolte IKT-riski IKT-riski juhtimise raamistiku osana, jäädes samal ajal täielikult vastutavaks vastavuse eest. See nõuab kolmandate osapoolte IKT-riskistrateegiat, IKT-teenuste lepinguliste kokkulepete registreid, kriitilisi või olulisi funktsioone toetavate teenuste eristamist, iga-aastast aruandlust, kavandatava kokkuleppe teavitamist, lepingueelseid hindamisi, taustakontrolli, auditi- ja kontrolliõigusi, lõpetamisõigusi ning dokumenteeritud väljumisstrateegiaid.

Article 29 lisab kontsentratsiooniriski analüüsi, sealhulgas asendatavuse, mitmed sõltuvused samadest või seotud teenuseosutajatest, alltöövõturiskid, kolmandate riikide alltöövõtjad, andmekaitsenõuete täitmise, jõustatavuse ja keerukad alltöövõtuahelad. Article 30 nõuab kirjalikke lepingulisi õigusi ja kohustusi, teenusekirjeldusi, asukohti, turvakaitseid, andmetele juurdepääsu ja tagastamist, teenustasemeid, intsidendiabi, koostööd asutustega, lõpetamisõigusi, testitud varuplaane, seiret ja väljumiskorraldusi.

Juhtorgani heakskiidetud tarnijataluvuse avaldus võib olla järgmine:

„Meil on madal riskivalmidus selle suhtes, et kriitilised või olulised funktsioonid sõltuvad kolmandast osapoolest IKT-teenuseosutajast, kui meil puuduvad lepingulised auditiõigused, testitud väljumiskorraldused, intsidendist teavitamise kohustused, teenustaseme eesmärgid, andmete tagastamise õigused või nähtavus olulise alltöövõtu suhtes.“

See lause annab hankele praktilise reegli. Kui leping ei vasta lävendile, ei saa projektimeeskond riski vaikselt aktsepteerida.

Kuidas audiitorid testivad sinu IKT-riskivalmidust

Tugev riskivalmiduse avaldus on koostatud auditit silmas pidades.

Zenith Blueprint 28. samm, auditi, läbivaatuse ja parendamise etapp, tugevdab juhtkonna läbivaatuse kihti. See juhendab organisatsioone koguma sisendeid, nagu muutused välistes ja sisemistes teemades, ISMS-i toimivus, auditi tulemused, seire ja mõõtmine, intsidendid, mittevastavused, parendusvõimalused ja ressursivajadused. Samuti ütleb see, et juhtkonna läbivaatus peab viima otsuste ja tegevusteni, mitte üksnes esitlusteni.

Vähemalt kord aastas ja alati oluliste muudatuste korral peaks juhtkond üle vaatama, kas taluvuslävendid on endiselt kooskõlas ärimudeliga, kas intsidendid ületasid riskivalmidust, kas aktsepteeritud riskid jäävad heakskiidetud piiridesse, kas uued DORA, NIS2, GDPR või lepingulised nõuded muutsid lähteolukorda, kas tarnijad püsivad kontsentratsioonitaluvuse piires ning kas KRI-d põhjustavad õigeaegset eskaleerimist.

Kui vastus on ei, tuleb riskivalmiduse avaldust muuta või kontrollimeetmeid muuta.

Levinud ebaõnnestumismustrid 2026. aasta valmisolekutöös

DORA, NIS2, GDPR ja ISO/IEC 27001:2022 projektides korduvad samad nõrkused:

• Riskivalmidus ilma lävenditeta, kus juhtorgan kiidab avalduse heaks, kuid keegi ei suuda öelda, millal seda on rikutud.
• Lävendid ilma volituseta, kus tõsidustasemed on olemas, kuid riskiomanikud saavad erandeid aktsepteerida ilma kõrgema taseme heakskiiduta.
• Õiguslik risk väljaspool hindamismudelit, kus GDPR, DORA, NIS2 ja lepingud on loetletud eraldi, kuid mitte integreeritud mõjukriteeriumidesse.
• Tarnijataluvus puudub juhtorgani paketist, kuigi kriitilised IKT-sõltuvused on hankele või IT-le teada.
• Juhtkonna läbivaatus kui teater, kus esitatakse slaide, kuid otsuseid, tegevusi, ressursivajadusi ja riski aktsepteerimisi ei dokumenteerita.
• Audititõendusmaterjali killustatus, kus poliitikad, registrid, KRI-d, intsidendiaruanded, tarnijate ülevaatused ja juhtorgani protokollid asuvad eri kohtades ilma ristviideteta.

Claryseci lähenemine on loodud nende lünkade kõrvaldamiseks. Zenith Blueprint annab etapipõhise rakendustee. Riskijuhtimise poliitika ja VKE-de riskijuhtimise poliitika annavad juhtimisklauslid, mis on skaleeritud ettevõttekeskkondadele ja VKE-dele. Zenith Controls kaardistab kontrollimeetmete selgroo infoturbepoliitika, juhtkonna vastutuse ning õiguslike või regulatiivsete nõuete lõikes, muutes tõendusmaterjali taaskasutatavaks ISO/IEC 27001:2022, DORA, NIS2, GDPR, NIST CSF ja COBIT-stiilis kindlustandvate tegevuste jaoks.

Muuda juhtorgani tahe auditeeritavaks IKT-riskijuhtimiseks

Kui sinu organisatsioonil on riskiregister, kuid ta ei suuda näidata juhtorgani heakskiidetud IKT-riskivalmidust, mõõdetavaid taluvuslävendeid, eskaleerimise aluseid ja formaalseid aktsepteerimisreegleid, ei ole lünk kosmeetiline. See mõjutab DORA juhtimist, NIS2 juhtkonna vastutust, GDPR Article 32 kaitstavust ja ISO/IEC 27001:2022 auditiks valmisolekut.

Praktiline järgmine samm on korraldada fokuseeritud IKT-riskivalmiduse töötuba, kasutades Claryseci tööriistakomplekti:

1. Kasuta Zenith Blueprint 10. sammu riskikriteeriumide ja mõju skaalade määratlemiseks.
2. Kasuta Zenith Blueprint 13. sammu käsitlusvalikute, jääkriski ja kohaldatavusavalduse heakskiidu sidumiseks.
3. Kasuta Zenith Blueprint 14. sammu GDPR, NIS2 ja DORA kohustuste ristviitamiseks.
4. Kasuta Zenith Blueprint 28. sammu riskivalmiduse, KRI-de, aktsepteeritud riskide ja ressursiotsuste toomiseks juhtkonna läbivaatusse.
5. Rakenda Riskijuhtimise poliitikat või VKE-de riskijuhtimise poliitikat, et vormistada heakskiidu ja aktsepteerimise reeglid.
6. Kasuta Zenith Controls, et kaardistada juhtimiskontrollid audititõendusmaterjali ja ristvastavuse ootustega.

Clarysec saab aidata muuta hajutatud riskiartefaktid juhtorgani heakskiidetud ja regulaatorile esitamiseks valmis IKT-riskivalmiduse mudeliks, mida sinu meeskonnad saavad kasutada siis, kui järgmine pilveteenuse katkestus, tarnija rike, haavatavuse avalikustamine või isikuandmete intsident paneb proovile organisatsiooni tegeliku taluvuse.