DORA szerinti IKT-kockázatvállalási hajlandóság: vezető testületi jóváhagyási útmutató 2026-ra

Kedd reggel 08:15 van, és egy közepes méretű fizetéstechnológiai vállalat információbiztonsági vezetője a tárgyalóterem előtt áll, a táblagépén három dokumentummal.

Az első az IKT-kockázati nyilvántartás. 137 sort tartalmaz, színkódolt besorolásokkal és több magas kockázattal, amelyek a felhőkoncentrációhoz, az emelt szintű jogosultságokhoz, a zsarolóvírus-támadás utáni helyreállításhoz, az ügyféladatok kitettségéhez és a beszállítói incidensreagáláshoz kapcsolódnak. A második a DORA-felkészültségi nyomonkövetési tábla. Eszerint a vállalat rendelkezik szabályzatokkal, incidenskezelési eljárásokkal, harmadik felek nyilvántartásaival és rezilienciatesztelési tervekkel. A harmadik a felügyeleti egyeztetésre készített vezető testületi anyag.

Az elnöknek egyetlen kérdése van, és nem technikai jellegű:

„Pontosan milyen szintű IKT-kockázat elfogadásában állapodtunk meg?”

A terem elcsendesedik, mert a vállalatnak vannak kockázatértékelései, de nincs vezető testület által jóváhagyott IKT-kockázatvállalási hajlandósága. Vannak hatásbesorolásai, de nincsenek mérhető kockázattűrési küszöbértékei. Vannak eszkalációs megbeszélései, de nincs formális kiváltó esemény arra, hogy egy kiberkockázat mikor válik vezető testületi döntéssé. Vannak elfogadott maradványkockázatai, de ezek egy részét „üzleti döntésként” indokolják anélkül, hogy egyértelműen kapcsolódnának a kockázati kritériumokhoz, a GDPR Article 32 szerinti arányossághoz, a DORA kockázattűrési elvárásaihoz vagy a NIS2 vezetői elszámoltathatóságához.

Ez a hiányosság 2026-ban egyre látványosabb. A DORA 2025. január 17-től alkalmazandó, és előírja a pénzügyi szervezetek számára az IKT-kockázatokra vonatkozó irányítási és kontrollkeretrendszer fenntartását, beleértve a vezető testület felelősségét az IKT-kockázatkezelési keretrendszerért, a digitális működési rezilienciastratégiáért és az IKT-kockázattűrésért. A NIS2 a vezető testületeket a kiberbiztonsági kockázatkezelési intézkedések jóváhagyására és végrehajtásuk felügyeletére kötelezi. A GDPR Article 32 kockázatalapú, megfelelő technikai és szervezési biztonsági intézkedéseket követel meg. Az ISO/IEC 27001:2022 biztosítja az irányítási rendszer működési mechanizmusát: szervezeti környezet, érdekelt felek, kockázati kritériumok, kockázatkezelési tervek, dokumentált információ és vezetőségi átvizsgálás.

A hiányzó kapocs egy olyan IKT-kockázatvállalási hajlandósági és kockázattűrési nyilatkozat, amelyet a vezető testület megért, jóváhagy, megkérdőjelez és alkalmazni tud.

Ez az útmutató bemutatja, hogyan építhető fel ez a kapocs a Clarysec Zenith Blueprint: Egy auditor 30 lépéses ütemterve, a Clarysec Kockázatkezelési szabályzat, a Clarysec Kockázatkezelési szabályzat kkv-knak és a Zenith Controls: Keresztmegfelelési útmutató használatával.

Miért nem azonos a kockázati nyilvántartás a kockázatvállalási hajlandósággal

Sok szervezet összekeveri a kockázati nyilvántartást a kockázatirányítással. A kockázati nyilvántartás megmutatja, milyen kockázatok léteznek, hogyan vannak besorolva, ki a tulajdonosuk, és milyen kockázatkezelés van tervezve. Önmagában azonban nem válaszolja meg automatikusan azokat a vezető testületi szintű kérdéseket, amelyeket a DORA, a NIS2, a GDPR és az ISO/IEC 27001:2022 elvár a vezetéstől.

Egy érett IKT-kockázatvállalási hajlandósági nyilatkozat ilyen kérdésekre ad választ:

• Mely IKT-kockázatok elfogadhatatlanok költségtől függetlenül?
• Mekkora működési kiesést képes elviselni az üzletmenet egy kritikus vagy fontos funkció esetében?
• Milyen szintű adatvesztés vagy adatsértetlenségi kompromittálódás esik a kockázatvállalási hajlandóságon kívülre?
• Milyen harmadik félhez kapcsolódó koncentrációs kockázat igényel vezető testületi figyelmet?
• Ki fogadhat el maradvány IKT-kockázatot, és milyen szinten?
• Mikor kell egy kockázatot a felső vezetéshez vagy a vezető testülethez eszkalálni?
• Hogyan épülnek be a jogi, szabályozási és szerződéses követelmények a kockázati kritériumokba?

A DORA alapján ez nem opcionális irányítási finomhangolás. Article 5 előírja, hogy a vezető testület határozza meg, hagyja jóvá, felügyelje és vállaljon felelősséget az IKT-kockázatkezelési keretrendszerért, beleértve a digitális működési rezilienciastratégiát és az IKT-kockázattűrést. Article 6 dokumentált IKT-kockázatkezelési keretrendszert, a nem mikrovállalkozásoknál éves felülvizsgálatot, belső auditot, a kritikus auditmegállapítások helyesbítését, valamint IKT-célokat, kockázattűrést, hatástűrést, architektúrát, tesztelést és incidenskommunikációs stratégiát tartalmazó digitális működési rezilienciastratégiát ír elő.

A NIS2 párhuzamos elszámoltathatósági modellt ad hozzá. Article 20 előírja, hogy az alapvető és fontos szervezetek vezető testületei hagyják jóvá a kiberbiztonsági kockázatkezelési intézkedéseket, felügyeljék a végrehajtást, és képzésben részesüljenek. Article 21 megfelelő és arányos technikai, operatív és szervezési intézkedéseket követel meg minden veszélyre kiterjedő megközelítés alapján, ideértve a kockázatelemzést, az incidenskezelést, az üzletmenet-folytonosságot, az ellátási lánc biztonságát, a biztonságos fejlesztést, a kontrollhatékonyságot, a képzést, a kriptográfiát, a HR-biztonságot, a hozzáférés-szabályozást, az eszközkezelést és adott esetben a többtényezős hitelesítést.

Pénzügyi szervezetek esetében a DORA ágazatspecifikus uniós jogi aktusnak minősül azokon a területeken, ahol átfedő NIS2-kötelezettségek alkalmazandók. A gyakorlatban a DORA általában kiváltja a hatálya alá tartozó pénzügyi szervezetekre vonatkozó átfedő NIS2 kockázatkezelési és incidensjelentési követelményeket, miközben a NIS2 továbbra is fontos a koordináció, valamint a DORA közvetlen pénzügyi szervezeti kötelezettségein kívüli szolgáltatók szempontjából. SaaS-, felhő-, menedzselt szolgáltatási és menedzselt biztonsági szolgáltatókra a NIS2 közvetlenül is alkalmazandó lehet, ha a hatályi feltételek teljesülnek.

Ezért a vezető testület által jóváhagyott IKT-kockázatvállalási hajlandóság már nem pénzügyi kockázati artefaktum. Kiberbiztonsági irányítási kontroll.

Használja az ISO/IEC 27001:2022 szabványt működési rendszerként

A DORA és a NIS2 megmondja a vezetőknek, mit kell irányítani. Az ISO/IEC 27001:2022 gyakorlati működési rendszert ad ahhoz, hogyan kell ezt irányítani.

Az ISO/IEC 27001:2022 4.1–4.4 pontjai előírják, hogy a szervezet határozza meg a környezetét, az érdekelt feleket, a követelményeket, az IBIR alkalmazási területét és az IBIR-folyamatokat. Ez azért lényeges, mert a DORA, a NIS2, a GDPR, a szerződések, a felügyeleti elvárások, az ügyfelek, a felhőszolgáltatók és a kiszervezési megállapodások mind olyan követelményekké válnak, amelyek befolyásolják a kockázati kritériumokat.

Az 5.1–5.3 pontok vezetői elkötelezettséget, a szabályzatokkal való összhangot, erőforrásokat, felelősségeket és az IBIR-teljesítmény felső vezetés felé történő jelentését írják elő. A 6.1.1–6.1.3 pontok kockázatalapú tervezést, dokumentált kockázatértékelési folyamatot, kockázatelfogadási kritériumokat, egységes értékelési kritériumokat, kockázattulajdonosokat, a kockázati kritériumokkal való összevetést, kockázatkezelési tervezést, alkalmazhatósági nyilatkozatot és a maradványkockázat jóváhagyását követelik meg.

Ez képezi a DORA szerinti IKT-kockázattűrés alapját.

A Kockázatkezelés szakaszban a Zenith Blueprint 10. lépése arra utasítja a szervezeteket, hogy a kockázatok minősítése előtt határozzák meg a kockázati kritériumokat:

„A kockázati kritériumok azok a szabályok és viszonyítási alapok, amelyeket a szervezet az egyes kockázatok jelentőségének értékelésére használ. E kritériumok előzetes meghatározása biztosítja, hogy mindenki ugyanazt a kockázati nyelvet használja.”

Ugyanez a lépés figyelmeztet arra, hogy a szabályozási hatást be kell építeni a kockázatdefiníciókba:

„Minden olyan kockázat, amely az alkalmazandó jogszabályoknak (GDPR stb.) való meg nem feleléshez vezethet, nem elfogadható, és azt csökkenteni kell.”

A Zenith Blueprint gyakorlati útmutatást is ad a hatásskálázáshoz:

„A hatás meghatározásakor célszerű a szinteket az adott üzleti mérethez igazítani. Például: ‘Jelentős pénzügyi hatás = veszteség > 100 000 USD’ (igazítsa a saját környezetéhez). Vegye figyelembe a szabályozási hatást is: például a személyes adatokkal kapcsolatos adatsértés a GDPR-bírságok és bejelentési követelmények miatt automatikusan ‘Jelentős’ vagy ‘Súlyos’ lehet, akkor is, ha a közvetlen pénzügyi veszteség nem egyértelmű. Hasonlóképpen, ha a NIS2 hatálya alá tartozik (alapvető szolgáltatások), egy szolgáltatáskimaradást okozó incidens jogi következményei miatt legalább ‘Jelentős’ lehet. Ezeket a szempontokat építse be a definíciókba.”

Ez az útmutatás megelőz egy gyakori hibát: azt, hogy egy kiberkockázatot mérsékeltnek minősítsenek pusztán azért, mert a közvetlen pénzügyi veszteség alacsonynak tűnik, miközben figyelmen kívül hagyják a jogi, működési reziliencia-, érintetti vagy ügyfélhatást.

Egy vezető testület elé vihető modellnek négy réteget kell elkülönítenie:

Ez a struktúra auditálhatóvá teszi a kockázatvállalási hajlandóságot, mert minden nyilatkozat visszavezethető a kockázati kritériumokra, kontrollokra, bizonyítékokra és döntésekre.

Vezető testület elé vihető DORA IKT-kockázatvállalási hajlandósági nyilatkozat

Egy erős IKT-kockázatvállalási hajlandósági nyilatkozat elég rövid ahhoz, hogy a vezető testület jóváhagyja, elég konkrét ahhoz, hogy a vezetés alkalmazza, és elég mérhető ahhoz, hogy az auditorok teszteljék. Kerülnie kell a zsargont, de nem lehet homályos.

Egy gyakorlati, magas szintű nyilatkozat így hangozhat:

„Vállalatunk alacsony kockázatvállalási hajlandóságot alkalmaz azokkal az IKT-kockázatokkal szemben, amelyek az ügyfeleknek okozott lényeges kárral, kritikus vagy fontos funkciók megszakadásával, szabályozott adatok jogosulatlan közzétételével vagy módosításával, jogi kötelezettségek nem teljesítésével, illetve kritikus, harmadik fél által nyújtott IKT-szolgáltatások rezilienciájának elvesztésével járhatnak.”

Ehhez a nyilatkozathoz mérhető kockázattűrési küszöbértékekre és eszkalációs kiváltó eseményekre van szükség.

Ez a táblázat megváltoztatja a beszélgetést. A vezető testület már nem szlogent hagy jóvá. Működési határokat hagy jóvá a rendelkezésre állásra, a bizalmasságra, a sértetlenségre, a beszállítókra, a sérülékenységekre, a helyreállításra és a megfelelésre.

A Clarysec Kockázatkezelési szabályzata támogatja ezt az irányítási modellt. A vállalati szabályzat kimondja:

„Jóváhagyja a kockázatkezelési keretrendszert, és meghatározza az elfogadható kockázatvállalási hajlandóságot és kockázattűrési küszöbértékeket.”

A 6.2.1 pont egyértelművé teszi a mérési követelményt:

„A kockázatokat valószínűség és hatás szerint, egyértelműen meghatározott pontozási skálákkal rendelkező standard kockázati mátrix alapján kell értékelni.”

A 6.3.4 pont létrehozza azt az elfogadási szabályt, amelyet az auditorok elvárnak:

„A kezelés nélkül elfogadott kockázatokat írásban kell indokolni, össze kell kapcsolni a szervezet kockázatvállalási hajlandóságával, és a megfelelő szinten jóvá kell hagyni.”

KKV-k esetében a Kockázatkezelési szabályzat kkv-knak ugyanazt az irányítási elvet könnyített formában tartja fenn:

„Biztosítani kell a vezetés részvételét a kockázattűrés és a jelentős kockázatkezelési tervek jóváhagyásában.”

A magas kockázatok eszkalációját is előírja:

„A magas kockázatokat döntésre az ügyvezetőhöz kell eszkalálni.”

Ez az arányosság a gyakorlatban. A DORA Article 4 előírja, hogy a követelményeket a mérettel, a kockázati profillal, valamint a szolgáltatások jellegével, nagyságrendjével és összetettségével arányosan kell alkalmazni. Az ISO/IEC 27001:2022 ugyanezt az elvet az alkalmazási területen, a környezeten, a kockázati kritériumokon és a kockázatkezelési döntéseken keresztül teszi lehetővé. Az irányítási elvárás nem az, hogy minden szervezetnek azonos bizottsági struktúrája legyen. Az elvárás az, hogy a kockázatvállalási hajlandóság, a kockázattűrés, az eszkaláció és az elfogadás meghatározott, jóváhagyott, bizonyított és ténylegesen használt legyen.

A GDPR Article 32 megváltoztatja a kockázati beszélgetést

A GDPR Article 32 rendelkezést gyakran technikai biztonsági követelményként kezelik. Irányítási szempontból azonban ez kockázatvállalási hajlandósági követelmény is.

Article 32 előírja az adatkezelők és adatfeldolgozók számára, hogy a kockázatnak megfelelő biztonsági szintet biztosító technikai és szervezési intézkedéseket hajtsanak végre. Ez a kockázatalapú megközelítés figyelembe veszi a technika állását, a megvalósítás költségeit, az adatkezelés jellegét, hatókörét, körülményeit és céljait, valamint a természetes személyek jogait és szabadságait fenyegető kockázatokat.

Ez három módon érinti az IKT-kockázatvállalási hajlandóságot.

Először: a személyes adatokra gyakorolt hatás nem szűkíthető pénzügyi veszteségre. Egy kis adatbázis kitettsége korlátozott közvetlen költséggel járhat, de súlyos bizalmassági, identitás-, csalási, diszkriminációs vagy jogi hatásokat okozhat. Ha különleges kategóriájú személyes adatok érintettek, például egészségügyi, biometrikus vagy genetikai adatok, a kockázatvállalási hajlandóságnak érdemben alacsonyabbnak kell lennie.

Másodszor: az adatkezelési szerepeket össze kell kapcsolni a kockázattulajdonosi felelősséggel. A GDPR különbséget tesz adatkezelők és adatfeldolgozók között. A DORA megkülönbözteti a pénzügyi szervezeteket és az IKT-szolgáltatást nyújtó harmadik feleket. A NIS2 különbséget tesz alapvető és fontos szervezetek között. Az ISO/IEC 27001:2022 kockázattulajdonosokat követel meg. Egy érett kockázatvállalási hajlandósági nyilatkozatnak meg kell határoznia, ki felel a személyes adatokkal, kiszervezett adatkezeléssel, kritikus szolgáltatásokkal és határokon átnyúló függőségekkel kapcsolatos kockázati döntésekért.

Harmadszor: az Article 32 szerinti arányosságnak láthatónak kell lennie a kontrollkiválasztásban. A titkosítás, az álnevesítés, a hozzáférés-szabályozás, a biztonsági mentés, a naplózás, a monitorozás, az incidensreagálás és a reziliencia nem elkülönült technikai feladatok. Ezek olyan kockázatkezelési intézkedések, amelyeket azért választanak ki, mert egy kockázat meghaladta a kockázatvállalási hajlandóságot vagy a kockázattűrést.

A Clarysec Kockázatkezelési szabályzata ezt kifejezetten összekapcsolja:

„Article 32: Kockázatalapú megközelítést ír elő a biztonsági intézkedésekre, amely hatásalapú kockázatértékelésekkel és kontrollkiválasztással teljesül.”

Ez az a működési kapcsolat, amelyet az auditorok keresnek: Article 32 követelmény, kockázatértékelés, kockázati besorolás, kockázatkezelési terv, kontrollkiválasztás, maradványkockázat és jóváhagyás.

Hogyan támogatja a Zenith Controls a keresztmegfelelőségi bizonyítékokat

A vezető testület által jóváhagyott kockázatvállalási hajlandósági nyilatkozat akkor válik erőssé, ha kontrollokhoz van rendelve. A Zenith Controls a Clarysec keresztmegfelelőségi útmutatójaként működik, és segíti a csapatokat abban, hogy a bizonyítékokat újrahasznosítsák az ISO/IEC 27001:2022, a DORA, a NIS2, a GDPR, a NIST CSF és a COBIT-stílusú bizonyossági igények között.

Három ISO/IEC 27002:2022 kontrollterület különösen fontos:

Ez nem papíralapú leképezési gyakorlat. Megváltoztatja a döntéshozatalt.

Ha egy üzleti felelős az adminisztrátorok MFA-bevezetésének halasztott elfogadását kéri, a Zenith Controls segít az információbiztonsági vezetőnek megmutatni, hogy ez nem pusztán hozzáférés-szabályozási kérdés. Érinti a szabályzatirányítást, a vezetői felelősséget, a jogi és szabályozási követelményeket, a GDPR szerinti adatkezelés biztonságát, a DORA szerinti IKT-kockázatkezelést, a NIS2 szerinti kiberbiztonsági intézkedéseket, az incidenshatást és az auditbizonyítékot.

Ha egy termékcsapat új uniós piacon kíván elindulni egy új felhőszolgáltatás használatával, az ISO/IEC 27002:2022 5.31 kontrollja a jogi és szabályozási követelmények felülvizsgálatát az IBIR alkalmazási területébe emeli. Az ISO/IEC 27001:2022 4.2 pontja előírja az érdekelt felek követelményeinek azonosítását, beleértve a jogi, szabályozási és szerződéses kötelezettségeket. A 8.1 pont előírja a működéstervezést és -szabályozást, beleértve az IBIR szempontjából releváns, külső fél által biztosított folyamatok, termékek vagy szolgáltatások kontrollját.

A cél egyetlen kockázati nyelv, nem különálló megfelelőségi dialektusok.

Jóváhagyási munkafolyamat: ki miről dönt

Az információbiztonsági vezető javaslatot tehet az IKT-kockázatvállalási hajlandóságra, de annak tulajdonosa a vezető testület. Ehhez a tulajdonosi felelősséghez munkafolyamat szükséges.

Ez összhangban van a NIST CSF 2.0-val is. A GOVERN funkció, különösen a GV.RM, megállapodott kockázatkezelési célkitűzéseket, kockázatvállalási hajlandósági és kockázattűrési nyilatkozatokat, a vállalati kockázatkezelésbe integrált kockázati tevékenységeket, meghatározott kockázatkezelési válaszlehetőségeket, kommunikációs vonalakat, valamint a kiberbiztonsági kockázatok kiszámítására, dokumentálására, kategorizálására és priorizálására szolgáló standardizált módszereket vár el. A GV.RR vezetői elszámoltathatóságot, szerepeket, hatásköröket és a kockázati stratégiához igazított erőforrásokat vár el. A GV.PO azt várja el, hogy a szabályzatokat létrehozzák, kommunikálják, betartassák, felülvizsgálják és frissítsék.

A COBIT 19 és az ISACA-stílusú bizonyossági szakemberek azt fogják vizsgálni, hogy a kockázatvállalási hajlandóság beépül-e az információ és technológia vállalatirányításába, és nem csupán egy kiberbiztonsági szabályzat melléklete.

IKT-kockázatvállalási hajlandósági vezető testületi csomag elkészítése egy munkamenetben

Egy gyakorlati IKT-kockázatvállalási hajlandósági workshop a szétszórt nyilvántartásokból auditálható vezető testületi csomagot készíthet.

1. lépés: a megfelelő bemenetek összegyűjtése

Készítse elő az aktuális IKT-kockázati nyilvántartást, az üzleti hatáselemzést, a helyreállítási célkitűzéseket, a kritikus vagy fontos funkciók listáját, az IKT-eszköznyilvántartást, az IKT-szolgáltatásnyilvántartást, a beszállítói és felhőfüggőségi nyilvántartást, az incidensbesorolási kritériumokat, a GDPR szerinti adatkezelési tevékenységek nyilvántartását, a releváns DPIA-kat, a jogi kötelezettségek nyilvántartását, a szabályzatokat, az alkalmazhatósági nyilatkozatot és a meglévő vállalati kockázatvállalási hajlandósági nyilatkozatot.

Ez összhangban van az ISO/IEC 27001:2022 4., 6. és 8. pontjával, valamint a NIST CSF profilkialakítási módszereivel, amelyek az üzleti prioritásokból, kockázati prioritásokból, követelményekből, védelmi intézkedésekből és szerepkörökből indulnak ki.

2. lépés: szabályozási hatást is tartalmazó hatásskálák meghatározása

A Zenith Blueprint 10. lépését használva határozza meg a valószínűséget és a hatást üzleti nyelven. Tartalmazza a pénzügyi veszteséget, a működési zavart, az ügyfélhatást, a reputációs kárt, a jogi és szabályozási hatást, az érintetteket érő kárt és a kritikus funkciókra gyakorolt hatást.

Például a „Jelentős” hatás magában foglalhat egy kritikus szolgáltatás elhúzódó kiesését, bejelentést igénylő megerősített személyesadat-sértést, DORA incidensjelentési kötelezettség elmulasztását vagy egy kritikus vagy fontos funkciót érintő beszállítói hibát.

3. lépés: kockázatvállalási hajlandóság megfogalmazása területenként

Ne hozzon létre egyetlen általános kiberkockázati hajlandóságot. Határozzon meg területeket, például kritikus szolgáltatások rendelkezésre állása, személyes adatok bizalmassága, adatsértetlenség, emelt szintű jogosultságok, harmadik félhez kapcsolódó IKT-függőség, felhőkoncentráció, sérülékenységi kitettség, incidensjelentési felkészültség, biztonsági mentés és helyreállítás, valamint biztonságos fejlesztési és változáskezelési kockázat.

Minden területhez írjon egy kockázatvállalási hajlandósági nyilatkozatot, egy vagy több kockázattűrési küszöbértéket és eszkalációs kiváltó eseményt.

4. lépés: a kockázatkezelés összekapcsolása az alkalmazhatósági nyilatkozattal

A Zenith Blueprint 13. lépése arra utasítja a szervezeteket, hogy válasszanak kockázatkezelési opciókat: csökkentés, elkerülés, átruházás vagy elfogadás. A vezetői jóváhagyást is hangsúlyozza:

„A kockázatkezelési döntéseket és az SoA-t a felső vezetésnek felül kell vizsgálnia és jóvá kell hagynia.”

A DORA és a NIS2 szempontjából ez bizonyíték arra, hogy a vezető testület vagy a delegált vezetés felülvizsgálta a fő kockázatokat, kockázatkezeléseket és elfogadott maradványkitettséget. A GDPR szempontjából támogatja az elszámoltathatóságot, mert megmutatja, hogy a kiválasztott intézkedések miért voltak megfelelőek a kockázathoz.

5. lépés: az elfogadás rögzítése lejárattal és feltételekkel

Minden elfogadott közepes vagy magas maradványkockázatnak tartalmaznia kell:

• Kockázati azonosítót és tulajdonost
• Üzleti indoklást
• Hivatkozást a kockázatvállalási hajlandósági nyilatkozatra
• Érintett kockázattűrési küszöbértéket
• Jogi és szabályozási elemzést
• Kompenzáló kontrollokat
• Lejárati vagy felülvizsgálati dátumot
• Jóváhagyót
• Bizonyíték helyét
• A döntés újranyitását kiváltó eseményt

A Kockázatkezelési szabályzat kkv-knak kimondja:

„A magas vagy közepes kockázat elfogadására vagy kezelésének elhalasztására vonatkozó minden döntést dokumentálni kell a kockázati nyilvántartásban. Ennek a dokumentációnak tartalmaznia kell:”

Vállalati környezetben ez jóváhagyási munkafolyamattá és kockázati bizottsági csomaggá válik. Kisebb szervezeteknél lehet strukturált kockázati nyilvántartási fül vezetői aláírással. A cél nem a bürokrácia. A cél az igazolhatóság.

Incidenstűrés: ahol a kockázatvállalási hajlandóság találkozik az órával

A kockázatvállalási hajlandóság incidensek során válik valósággá.

A DORA Article 17 előírja a pénzügyi szervezetek számára IKT-vonatkozású incidenskezelési folyamat létrehozását az incidensek észlelésére, kezelésére és bejelentésére, valamennyi incidens és jelentős kiberfenyegetés rögzítésére, a gyökérokok azonosítására, korai figyelmeztető indikátorok használatára, az incidensek prioritás, súlyosság és szolgáltatáskritikusság szerinti besorolására, szerepkörök kijelölésére, az érdekelt felek felé történő kommunikációra, legalább a súlyos IKT-vonatkozású incidensek felső vezetéshez és vezető testülethez történő eszkalálására, valamint a biztonságos működés időben történő helyreállítására.

A DORA Article 18 az incidenseket olyan tényezők alapján sorolja be, mint az érintett ügyfelek, az időtartam, a kiesési idő, a földrajzi kiterjedés, a rendelkezésre állást, hitelességet, sértetlenséget vagy bizalmasságot érintő adatvesztések, az érintett szolgáltatások kritikussága és a gazdasági hatás. Article 19 előírja, hogy a súlyos IKT-vonatkozású incidenseket jelenteni kell az illetékes hatóságnak, és tájékoztatni kell az ügyfeleket, ha pénzügyi érdekeik érintettek.

A NIS2 Article 23 szakaszos jelentést ír elő jelentős incidensekre, beleértve az indokolatlan késedelem nélküli és adott esetben 24 órán belüli korai figyelmeztetést, az indokolatlan késedelem nélküli és adott esetben 72 órán belüli incidensbejelentést, a kért közbenső frissítéseket, valamint az incidensbejelentést követő legkésőbb egy hónapon belüli zárójelentést. Jelentős incidensnek minősülnek azok, amelyek súlyos működési zavart, pénzügyi veszteséget vagy másoknak okozott lényeges vagy nem vagyoni kárt eredményeznek.

A kockázatvállalási hajlandósági nyilatkozatnak még az incidens bekövetkezése előtt meg kell határoznia az eszkalációs küszöbértékeket.

Az Annex A kontrollok az incidens-tervezés, az információbiztonsági események értékelése, az incidensreagálás, az incidensekből való tanulás, a bizonyítékgyűjtés, az információbiztonság fenntartása zavarhelyzetben és az IKT üzletmenet-folytonossági felkészültség területén mind támogatják ezeket a küszöbértékeket. A NIST CSF eredmények az IDENTIFY, PROTECT, DETECT, RESPOND és RECOVER funkciók mentén ugyanazt a működési modellt támogatják, beleértve a biztonsági mentéseket, a monitorozást, az incidens kihirdetését, az eszkalációt, a gyökérok-elemzést, az érdekelt felek kommunikációját és a helyreállítás ellenőrzését.

A beszállítói és felhőkockázati tűrés, amelyet a vezető testületek gyakran kihagynak

A DORA a harmadik fél által nyújtott IKT-szolgáltatások kockázatát alapvető megfelelési kötelezettséggé teszi. Article 28 előírja a pénzügyi szervezetek számára, hogy a harmadik fél által nyújtott IKT-szolgáltatások kockázatát az IKT-kockázatkezelési keretrendszer részeként kezeljék, miközben a megfelelésért teljes felelősséggel tartoznak. Előírja a harmadik fél IKT-kockázatára vonatkozó stratégiát, az IKT-szolgáltatási szerződéses megállapodások nyilvántartásait, a kritikus vagy fontos funkciókat támogató szolgáltatások megkülönböztetését, az éves jelentéstételt, a tervezett megállapodások bejelentését, a szerződéskötés előtti értékeléseket, a kellő gondosságot, az audit- és ellenőrzési jogokat, a felmondási jogokat és a dokumentált kilépési stratégiákat.

Article 29 koncentrációs kockázatelemzést ad hozzá, beleértve a helyettesíthetetlenséget, az ugyanazon vagy kapcsolt szolgáltatóktól való többszörös függőséget, az alvállalkozási kockázatokat, a harmadik országbeli alvállalkozókat, az adatvédelmi megfelelést, az érvényesíthetőséget és az összetett alvállalkozói láncokat. Article 30 írásbeli szerződéses jogokat és kötelezettségeket, szolgáltatásleírásokat, helyszíneket, biztonsági védelmi intézkedéseket, adathozzáférést és adatvisszaadást, szolgáltatási szinteket, incidenssegítséget, hatóságokkal való együttműködést, felmondási jogokat, tesztelt vészhelyzeti terveket, monitorozási és kilépési megállapodásokat ír elő.

Egy vezető testület által jóváhagyott beszállítói tűrési nyilatkozat így szólhat:

„Alacsony a kockázatvállalási hajlandóságunk arra, hogy kritikus vagy fontos funkciók olyan harmadik fél IKT-szolgáltatótól függjenek, amelynél nem rendelkezünk szerződéses auditálási jogokkal, tesztelt kilépési megállapodásokkal, incidensbejelentési kötelezettségekkel, szolgáltatási szint célértékekkel, adatvisszaadási jogokkal vagy a lényeges alvállalkozásba adás átláthatóságával.”

Ez a mondat gyakorlati szabályt ad a beszerzésnek. Ha a szerződés nem felel meg a küszöbértéknek, a kockázatot a projektcsapat nem fogadhatja el csendben.

Hogyan tesztelik az auditorok az IKT-kockázatvállalási hajlandóságot

Egy erős kockázatvállalási hajlandósági nyilatkozatot auditálási szempontok szerint kell kialakítani.

A Zenith Blueprint 28. lépése az Audit, felülvizsgálat és fejlesztés szakaszban megerősíti a vezetőségi átvizsgálási réteget. Arra utasítja a szervezeteket, hogy gyűjtsenek be bemeneteket, például a külső és belső körülmények változásait, az IBIR teljesítményét, az auditeredményeket, a monitorozást és mérést, az incidenseket, a meg nem feleléseket, a fejlesztési lehetőségeket és az erőforrásigényeket. Azt is kimondja, hogy a vezetőségi átvizsgálásnak döntésekhez és intézkedésekhez kell vezetnie, nem pusztán prezentációkhoz.

Legalább évente, valamint minden lényeges változáskor a vezetésnek felül kell vizsgálnia, hogy a kockázattűrési küszöbértékek továbbra is illeszkednek-e az üzleti modellhez, az incidensek meghaladták-e a kockázatvállalási hajlandóságot, az elfogadott kockázatok a jóváhagyott határokon belül maradtak-e, az új DORA-, NIS2-, GDPR- vagy szerződéses követelmények megváltoztatták-e az alapot, a beszállítók továbbra is a koncentrációs tűréshatárokon belül vannak-e, és a KRI-k időben kiváltják-e az eszkalációt.

Ha a válasz nem, a kockázatvállalási hajlandósági nyilatkozatot vagy a kontrollokat módosítani kell.

Gyakori hibaminták a 2026-os felkészülési munkákban

A DORA-, NIS2-, GDPR- és ISO/IEC 27001:2022-projektekben ugyanazok a gyengeségek jelennek meg ismétlődően:

• Kockázatvállalási hajlandóság küszöbértékek nélkül: a vezető testület jóváhagy egy nyilatkozatot, de senki nem tudja megmondani, mikor sérült meg.
• Küszöbértékek hatáskör nélkül: léteznek súlyossági szintek, de a kockázattulajdonosok felsővezetői jóváhagyás nélkül fogadhatnak el kivételeket.
• Jogi kockázat a pontozási modellen kívül: a GDPR, a DORA, a NIS2 és a szerződések külön vannak felsorolva, de nincsenek beépítve a hatáskritériumokba.
• Hiányzó beszállítói tűrés a vezető testületi csomagból, miközben a kritikus IKT-függőségeket a beszerzés vagy az IT ismeri.
• Vezetőségi átvizsgálás színházként: a diákat bemutatják, de a döntéseket, intézkedéseket, erőforrásigényeket és kockázatelfogadásokat nem dokumentálják.
• Auditbizonyítékok széttagoltsága: a szabályzatok, nyilvántartások, KRI-k, incidensjelentések, beszállítói felülvizsgálatok és vezető testületi jegyzőkönyvek külön helyeken léteznek, kereszthivatkozás nélkül.

A Clarysec megközelítése ezeket a hiányosságokat kezeli. A Zenith Blueprint szakaszolt bevezetési útvonalat biztosít. A Kockázatkezelési szabályzat és a Kockázatkezelési szabályzat kkv-knak vállalati és KKV-környezetekre skálázott irányítási rendelkezéseket ad. A Zenith Controls leképezi a kontrollgerincet az információbiztonsági szabályzat, a vezetői felelősség és a jogi vagy szabályozási követelmények között, és újrahasznosíthatóvá teszi a bizonyítékokat az ISO/IEC 27001:2022, a DORA, a NIS2, a GDPR, a NIST CSF és a COBIT-stílusú bizonyosság körében.

A vezető testületi szándék auditálható IKT-kockázatirányítássá alakítása

Ha szervezete rendelkezik kockázati nyilvántartással, de nem tud felmutatni vezető testület által jóváhagyott IKT-kockázatvállalási hajlandóságot, mérhető kockázattűrési küszöbértékeket, eszkalációs kiváltó eseményeket és formális elfogadási szabályokat, a hiányosság nem esztétikai jellegű. Hatással van a DORA szerinti irányításra, a NIS2 vezetői elszámoltathatóságra, a GDPR Article 32 szerinti igazolhatóságra és az ISO/IEC 27001:2022 szerinti auditfelkészültségre.

Gyakorlati következő lépésként érdemes célzott IKT-kockázatvállalási hajlandósági workshopot tartani a Clarysec eszköztárával:

1. Használja a Zenith Blueprint 10. lépését a kockázati kritériumok és hatásskálák meghatározásához.
2. Használja a Zenith Blueprint 13. lépését a kockázatkezelési opciók, a maradványkockázat és az alkalmazhatósági nyilatkozat jóváhagyásának összekapcsolásához.
3. Használja a Zenith Blueprint 14. lépését a GDPR-, NIS2- és DORA-kötelezettségek kereszthivatkozásához.
4. Használja a Zenith Blueprint 28. lépését a kockázatvállalási hajlandóság, a KRI-k, az elfogadott kockázatok és az erőforrás-döntések vezetőségi átvizsgálásba emeléséhez.
5. Alkalmazza a Kockázatkezelési szabályzatot vagy a Kockázatkezelési szabályzat kkv-knak a jóváhagyási és elfogadási szabályok formalizálásához.
6. Használja a Zenith Controls megoldást az irányítási kontrollok auditbizonyítékokhoz és keresztmegfelelőségi elvárásokhoz való leképezéséhez.

A Clarysec segít a szétszórt kockázati artefaktumokat vezető testület által jóváhagyott, felügyeleti ellenőrzésre kész IKT-kockázatvállalási hajlandósági modellé alakítani, amelyet csapatai akkor is használni tudnak, amikor a következő felhőszolgáltatási kiesés, beszállítói hiba, sérülékenységi tájékoztató vagy személyesadat-incidens próbára teszi a szervezet valódi kockázattűrését.