Apetít voči riziku IKT podľa DORA: sprievodca schválením riadiacim orgánom na rok 2026

Je utorok 08:15 a CISO stredne veľkej spoločnosti poskytujúcej platobné technológie stojí pred zasadacou miestnosťou riadiaceho orgánu s tromi dokumentmi otvorenými v tablete.

Prvým je register rizík IKT. Má 137 riadkov, farebne označené hodnotenia a viacero vysokých rizík súvisiacich s koncentráciou v cloude, privilegovaným prístupom, obnovou po ransomvéri, sprístupnením údajov zákazníkov a reakciou dodávateľov na incidenty. Druhým je prehľad pripravenosti na DORA. Uvádza, že spoločnosť má politiky, incidentné postupy, registre tretích strán a plány testovania odolnosti. Tretím je podklad pre riadiaci orgán k regulačnému stretnutiu.

Predseda má jednu otázku a nie je technická:

„Akú úroveň rizika IKT sme sa vlastne dohodli akceptovať?“

V miestnosti nastane ticho, pretože spoločnosť má posúdenia rizík, ale nemá apetít voči riziku IKT schválený riadiacim orgánom. Má hodnotenia dopadu, ale nie merateľné prahové hodnoty tolerancie. Má eskalačné stretnutia, ale nemá formálny spúšťač, ktorý určuje, kedy sa kybernetické riziko stáva rozhodnutím riadiaceho orgánu. Má akceptované reziduálne riziká, no niektoré sú odôvodnené ako „obchodné rozhodnutia“ bez jasnej väzby na kritériá rizika, proporcionalitu podľa GDPR Article 32, očakávania DORA v oblasti tolerancie alebo zodpovednosť manažmentu podľa NIS2.

Táto medzera je v roku 2026 čoraz viditeľnejšia. DORA sa uplatňuje od 17. januára 2025 a vyžaduje, aby finančné subjekty udržiavali rámec správy a kontrol pre riziko IKT vrátane zodpovednosti riadiaceho orgánu za rámec riadenia rizík IKT, stratégiu digitálnej prevádzkovej odolnosti a toleranciu rizika IKT. NIS2 smeruje riadiace orgány k schvaľovaniu opatrení na riadenie kybernetických rizík a dohľadu nad ich implementáciou. GDPR Article 32 vyžaduje primerané technické a organizačné bezpečnostné opatrenia založené na riziku. ISO/IEC 27001:2022 poskytuje mechaniku systému manažérstva: kontext, zainteresované strany, kritériá rizika, plány ošetrenia rizík, zdokumentované informácie a preskúmanie manažmentom.

Chýbajúcim mostom je vyhlásenie o apetíte voči riziku IKT a tolerancii, ktorému riadiaci orgán rozumie a ktoré môže schváliť, spochybňovať a používať.

Tento sprievodca vysvetľuje, ako tento most vybudovať pomocou Clarysec Zenith Blueprint: An Auditor’s 30-Step Roadmap, Clarysec Risk Management Policy, Clarysec Risk Management Policy-sme a Zenith Controls: The Cross-Compliance Guide.

Prečo registre rizík nie sú apetítom voči riziku

Mnohé organizácie si mýlia register rizík so správou a riadením rizík. Register rizík uvádza, aké riziká existujú, ako sú hodnotené, kto ich vlastní a aké ošetrenie rizík sa plánuje. Automaticky však neodpovedá na otázky na úrovni riadiaceho orgánu, ktoré DORA, NIS2, GDPR a ISO/IEC 27001:2022 očakávajú od vedenia.

Zrelé vyhlásenie o apetíte voči riziku IKT odpovedá na otázky ako:

• Ktoré riziká IKT sú neprijateľné bez ohľadu na náklady?
• Aký prevádzkový výpadok môže organizácia tolerovať pri kritickej alebo dôležitej funkcii?
• Aká úroveň straty údajov alebo narušenia integrity údajov je mimo apetítu?
• Aké riziko koncentrácie tretej strany vyžaduje pozornosť riadiaceho orgánu?
• Kto môže akceptovať reziduálne riziko IKT a na akej úrovni?
• Kedy musí byť riziko eskalované na vrcholový manažment alebo riadiaci orgán?
• Ako sú zákonné, regulačné a zmluvné požiadavky zahrnuté do kritérií rizika?

Podľa DORA nejde o voliteľné zlepšenie správy a riadenia. Article 5 vyžaduje, aby riadiaci orgán definoval, schvaľoval, dohliadal a niesol zodpovednosť za rámec riadenia rizík IKT vrátane stratégie digitálnej prevádzkovej odolnosti a tolerancie rizika IKT. Article 6 vyžaduje zdokumentovaný rámec riadenia rizík IKT, ročné preskúmanie pre podniky, ktoré nie sú mikropodnikmi, vnútorný audit, nápravu kritických auditných zistení a stratégiu digitálnej prevádzkovej odolnosti s cieľmi IKT, toleranciou rizika, toleranciou dopadu, architektúrou, testovaním a stratégiou komunikácie incidentov.

NIS2 pridáva paralelný model zodpovednosti. Article 20 vyžaduje, aby riadiace orgány základných a dôležitých subjektov schvaľovali opatrenia na riadenie kybernetických rizík, dohliadali na implementáciu a absolvovali školenie. Article 21 vyžaduje primerané a proporcionálne technické, prevádzkové a organizačné opatrenia založené na prístupe zahŕňajúcom všetky hrozby vrátane analýzy rizík, riešenia incidentov, kontinuity činností, bezpečnosti dodávateľského reťazca, bezpečného vývoja, účinnosti kontrolných opatrení, školení, kryptografie, bezpečnosti v oblasti ľudských zdrojov, riadenia prístupu, správy aktív a MFA, ak je to vhodné.

Pre finančné subjekty sa DORA považuje za sektorovo špecifický právny akt Únie tam, kde sa uplatňujú prekrývajúce sa povinnosti NIS2. V praxi DORA vo všeobecnosti nahrádza prekrývajúce sa požiadavky NIS2 na riadenie rizík a nahlasovanie incidentov pre finančné subjekty v jej rozsahu, zatiaľ čo NIS2 zostáva dôležitá pre koordináciu a pre poskytovateľov mimo priamych povinností finančných subjektov podľa DORA. Pre poskytovateľov SaaS, cloudových služieb, riadených služieb a riadených bezpečnostných služieb sa NIS2 môže uplatniť priamo, ak sú splnené podmienky rozsahu pôsobnosti.

Preto apetít voči riziku IKT schválený riadiacim orgánom už nie je artefaktom finančného rizika. Je to kontrolný mechanizmus správy a riadenia kybernetickej bezpečnosti.

Použite ISO/IEC 27001:2022 ako prevádzkový systém

DORA a NIS2 hovoria vedeniu, čo musí byť riadené. ISO/IEC 27001:2022 dáva organizáciám praktický prevádzkový systém, ako to riadiť.

ISO/IEC 27001:2022 kapitoly 4.1 až 4.4 vyžadujú, aby organizácia definovala kontext, zainteresované strany, požiadavky, rozsah ISMS a procesy ISMS. Je to dôležité, pretože DORA, NIS2, GDPR, zmluvy, očakávania orgánov dohľadu, zákazníci, poskytovatelia cloudových služieb a outsourcingové dohody sa všetky stávajú požiadavkami, ktoré ovplyvňujú kritériá rizika.

Kapitoly 5.1 až 5.3 vyžadujú záväzok vedenia, zosúladenie politík, zdroje, zodpovednosti a reportovanie výkonnosti ISMS vrcholovému manažmentu. Kapitoly 6.1.1 až 6.1.3 vyžadujú plánovanie založené na riziku, zdokumentovaný proces posudzovania rizík, kritériá akceptácie rizika, konzistentné kritériá posudzovania, vlastníkov rizík, porovnanie s kritériami rizika, plánovanie ošetrenia rizík, vyhlásenie o uplatniteľnosti (SoA) a schválenie reziduálneho rizika.

Toto je základ tolerancie rizika IKT podľa DORA.

Vo fáze riadenia rizík Step 10 v Zenith Blueprint ukladá organizáciám definovať kritériá rizika pred hodnotením rizík:

„Kritériá rizika sú pravidlá a referenčné hodnoty, ktoré vaša organizácia používa na vyhodnotenie významnosti každého rizika. Ich stanovenie vopred zabezpečí, že všetci používajú rovnaký jazyk rizík.“

Ten istý krok upozorňuje, že regulačný dopad musí byť zahrnutý do definícií rizika:

„Akékoľvek riziko, ktoré by mohlo viesť k nesúladu s uplatniteľnými právnymi predpismi (GDPR atď.), nie je prijateľné a musí byť zmiernené.“

Zenith Blueprint poskytuje aj praktické usmernenie k škálovaniu dopadu:

„Pri definovaní dopadu je vhodné vzťahovať úrovne na konkrétnu mierku vášho podnikania. Napríklad: „Významný finančný dopad = strata > 100 tis. USD“ (upravte podľa svojho kontextu). Zohľadnite aj regulačný dopad: napríklad porušenie ochrany osobných údajov môže byť automaticky „významné“ alebo „závažné“ z dôvodu pokút podľa GDPR a oznamovacích povinností, aj keď priama finančná strata nie je jasná. Podobne, ak patríte do rozsahu NIS2 (základné služby), incident spôsobujúci prerušenie služby môže byť minimálne „významný“ z dôvodu právnych dôsledkov. Zahrňte takéto úvahy do svojich definícií.“

Toto usmernenie predchádza častému zlyhaniu: hodnoteniu kybernetického rizika ako stredného len preto, že bezprostredná finančná strata sa javí ako malá, pričom sa ignoruje právny dopad, prevádzková odolnosť, dopad na dotknuté osoby alebo dopad na zákazníkov.

Model pripravený pre riadiaci orgán má oddeliť štyri vrstvy:

Táto štruktúra robí apetít voči riziku auditovateľným, pretože každé vyhlásenie možno vysledovať ku kritériám rizika, kontrolným opatreniam, dôkazom a rozhodnutiam.

Vyhlásenie o apetíte voči riziku IKT podľa DORA pripravené pre riadiaci orgán

Silné vyhlásenie o apetíte voči riziku IKT je dostatočne krátke na schválenie riadiacim orgánom, dostatočne konkrétne na používanie manažmentom a dostatočne merateľné na testovanie audítormi. Má sa vyhýbať žargónu, ale nesmie byť vágne.

Praktické vyhlásenie na vysokej úrovni môže znieť:

„Naša spoločnosť má nízky apetít voči rizikám IKT, ktoré by mohli viesť k podstatnej ujme klientov, narušeniu kritických alebo dôležitých funkcií, neoprávnenému sprístupneniu alebo zmene regulovaných údajov, nesplneniu zákonných povinností alebo strate odolnosti v kritických IKT službách tretích strán.“

Toto vyhlásenie potom potrebuje merateľné prahové hodnoty tolerancie a spúšťače eskalácie.

Táto tabuľka mení rozhovor. Riadiaci orgán už neschvaľuje slogan. Schvaľuje prevádzkové hranice pre dostupnosť, dôvernosť, integritu, dodávateľov, zraniteľnosti, obnovu a súlad.

Clarysec Risk Management Policy podporuje tento model správy a riadenia. Podniková politika uvádza:

„Schvaľuje rámec riadenia rizík a definuje prijateľný apetít voči riziku a prahové hodnoty tolerancie.“

Bod 6.2.1 explicitne stanovuje požiadavku merania:

„Riziká sa posudzujú z hľadiska pravdepodobnosti a dopadu pomocou štandardnej matice rizík s jasne definovanými škálami skórovania.“

Bod 6.3.4 vytvára pravidlo akceptácie, ktoré budú audítori očakávať:

„Riziká akceptované bez ošetrenia musia byť písomne odôvodnené, prepojené s apetítom organizácie voči riziku a schválené na príslušnej úrovni.“

Pre MSP zachováva Risk Management Policy-sme rovnaký princíp správy a riadenia v ľahšej forme:

„Zabezpečiť zapojenie manažmentu do schvaľovania tolerancie rizika a významných plánov ošetrenia rizík.“

Vyžaduje tiež eskaláciu vysokých rizík:

„Vysoké riziká musia byť eskalované generálnemu manažérovi na rozhodnutie.“

Toto je proporcionalita v praxi. DORA Article 4 vyžaduje, aby sa požiadavky uplatňovali spôsobom primeraným veľkosti, rizikovému profilu a povahe, rozsahu a zložitosti služieb. ISO/IEC 27001:2022 umožňuje rovnaký princíp prostredníctvom rozsahu, kontextu, kritérií rizika a rozhodnutí o ošetrení rizík. Štandardom správy a riadenia nie je, že každá organizácia potrebuje rovnakú štruktúru výborov. Štandardom je, že apetít voči riziku, tolerancia, eskalácia a akceptácia sú definované, schválené, podložené dôkazmi a používané.

GDPR Article 32 mení rozhovor o riziku

GDPR Article 32 sa často považuje za technickú bezpečnostnú klauzulu. Z hľadiska správy a riadenia je to aj klauzula o apetíte voči riziku.

Article 32 vyžaduje, aby prevádzkovatelia a sprostredkovatelia zaviedli primerané technické a organizačné opatrenia na zabezpečenie úrovne bezpečnosti primeranej riziku. Tento prístup založený na riziku zohľadňuje stav techniky, náklady na implementáciu, povahu, rozsah, kontext a účely spracúvania a riziká pre práva a slobody fyzických osôb.

To ovplyvňuje apetít voči riziku IKT tromi spôsobmi.

Po prvé, dopad na osobné údaje nemožno redukovať na finančnú stratu. Sprístupnenie malej databázy môže mať obmedzené priame náklady, ale závažné dôsledky pre dôvernosť, identitu, podvody, diskrimináciu alebo práva dotknutých osôb. Ak ide o osobitné kategórie osobných údajov, napríklad zdravotné, biometrické alebo genetické údaje, apetít má byť podstatne nižší.

Po druhé, roly pri spracúvaní musia byť prepojené s vlastníctvom rizika. GDPR rozlišuje prevádzkovateľov a sprostredkovateľov. DORA rozlišuje finančné subjekty a poskytovateľov IKT služieb tretích strán. NIS2 rozlišuje základné a dôležité subjekty. ISO/IEC 27001:2022 vyžaduje vlastníkov rizík. Zrelé vyhlásenie o apetíte má identifikovať, kto vlastní rozhodnutia o riziku týkajúce sa osobných údajov, outsourcovaného spracúvania, kritických služieb a cezhraničných závislostí.

Po tretie, proporcionalita podľa Article 32 má byť viditeľná vo výbere kontrolných opatrení. Šifrovanie, pseudonymizácia, riadenie prístupu, zálohovanie, logovanie, monitorovanie, reakcia na incidenty a odolnosť nie sú izolované technické úlohy. Sú to opatrenia na ošetrenie rizík vybrané preto, že riziko prekročilo apetít alebo toleranciu.

Clarysec Risk Management Policy toto prepojenie uvádza explicitne:

„Article 32: Ukladá prístup k bezpečnostným opatreniam založený na riziku, ktorý sa napĺňa prostredníctvom hodnotení rizík založených na dopade a výberu kontrol.“

To je prevádzková väzba, ktorú audítori hľadajú: požiadavka Article 32, posúdenie rizík, hodnotenie rizika, plán ošetrenia rizík, výber kontrolných opatrení, reziduálne riziko a schválenie.

Ako Zenith Controls podporuje dôkazy pre viacnásobný súlad

Vyhlásenie o apetíte schválené riadiacim orgánom nadobúda význam, keď je namapované na kontrolné opatrenia. Zenith Controls slúži ako sprievodca Clarysec pre viacnásobný súlad a pomáha tímom opätovne používať dôkazy naprieč ISO/IEC 27001:2022, DORA, NIS2, GDPR, NIST CSF a uistením v štýle COBIT.

Mimoriadne dôležité sú tri oblasti kontrol ISO/IEC 27002:2022:

Nejde o papierové mapovanie. Mení to spôsob rozhodovania.

Ak vlastník podnikovej oblasti požiada o akceptáciu oneskoreného zavedenia MFA pre administrátorov, Zenith Controls pomôže CISO ukázať, prečo nejde len o otázku riadenia prístupu. Dotýka sa správy politík, zodpovednosti manažmentu, zákonných a regulačných požiadaviek, bezpečnosti spracúvania podľa GDPR, riadenia rizík IKT podľa DORA, kybernetických opatrení podľa NIS2, dopadu incidentov a auditných dôkazov.

Ak produktový tím chce spustiť službu na novom trhu EÚ s použitím novej cloudovej služby, kontrola ISO/IEC 27002:2022 5.31 prenáša preskúmanie zákonných a regulačných požiadaviek do rozsahu ISMS. ISO/IEC 27001:2022 kapitola 4.2 vyžaduje identifikáciu požiadaviek zainteresovaných strán vrátane zákonných, regulačných a zmluvných povinností. Kapitola 8.1 vyžaduje prevádzkové plánovanie a riadenie vrátane riadenia externe poskytovaných procesov, produktov alebo služieb relevantných pre ISMS.

Cieľom je jeden jazyk rizík, nie samostatné dialekty súladu.

Schvaľovací pracovný tok: kto o čom rozhoduje

CISO môže navrhnúť apetít voči riziku IKT, ale vlastniť ho musí riadiaci orgán. Toto vlastníctvo potrebuje pracovný tok.

Toto je zosúladené aj s NIST CSF 2.0. Funkcia GOVERN, najmä GV.RM, očakáva dohodnuté ciele riadenia rizík, vyhlásenia o apetíte voči riziku a tolerancii, aktivity rizík integrované do podnikového riadenia rizík, definované možnosti reakcie na riziko, komunikačné línie a štandardizované metódy na výpočet, dokumentovanie, kategorizáciu a prioritizáciu kybernetických rizík. GV.RR očakáva zodpovednosť vedenia, roly, právomoci a zdroje zosúladené so stratégiou rizík. GV.PO očakáva, že politiky budú vytvorené, komunikované, uplatňované, preskúmavané a aktualizované.

Odborníci na uistenie v štýle COBIT 19 a ISACA sa budú pýtať, či je apetít voči riziku integrovaný do podnikového riadenia informácií a technológií, a nie iba priložený ako príloha ku kybernetickej politike.

Vytvorte balík apetítu voči riziku IKT počas jedného pracovného stretnutia

Praktický workshop k apetítu voči riziku IKT dokáže organizáciu posunúť od roztrúsených registrov k auditovateľnému balíku pre riadiaci orgán.

Krok 1: zhromaždite správne vstupy

Pripravte aktuálny register rizík IKT, analýzu vplyvu na podnikanie, ciele obnovy, zoznam kritických alebo dôležitých funkcií, inventár IKT aktív, inventár IKT služieb, register závislostí od dodávateľov a cloudových služieb, kritériá klasifikácie incidentov, evidenciu spracovateľských činností podľa GDPR, relevantné DPIA, register zákonných povinností, politiky, vyhlásenie o uplatniteľnosti (SoA) a existujúce podnikové vyhlásenie o apetíte voči riziku.

Toto je v súlade s ISO/IEC 27001:2022 kapitolami 4, 6 a 8 a s metódami profilov NIST CSF, ktoré začínajú prioritami organizácie, prioritami rizík, požiadavkami, ochrannými opatreniami a rolami.

Krok 2: definujte škály dopadu, ktoré zahŕňajú reguláciu

Pomocou Zenith Blueprint Step 10 definujte pravdepodobnosť a dopad jazykom organizácie. Zahrňte finančnú stratu, prevádzkové narušenie, dopad na zákazníkov, reputačnú ujmu, právny a regulačný dopad, ujmu dotknutých osôb a dopad na kritické funkcie.

Napríklad „významný“ dopad môže zahŕňať dlhší výpadok kritickej služby, potvrdené porušenie ochrany osobných údajov vyžadujúce oznámenie, nesplnenie oznamovacej povinnosti podľa DORA alebo zlyhanie dodávateľa ovplyvňujúce kritickú alebo dôležitú funkciu.

Krok 3: napíšte apetít podľa domén

Nevytvárajte jeden všeobecný kybernetický apetít. Definujte domény, ako sú dostupnosť kritických služieb, dôvernosť osobných údajov, integrita údajov, privilegovaný prístup, závislosť od IKT tretích strán, koncentrácia v cloude, expozícia zraniteľnostiam, pripravenosť na hlásenie incidentov, zálohovanie a obnova a riziko zmien v bezpečnom vývoji.

Pre každú doménu napíšte jedno vyhlásenie o apetíte, jednu alebo viac prahových hodnôt tolerancie a spúšťače eskalácie.

Krok 4: prepojte ošetrenie rizík s vyhlásením o uplatniteľnosti

Step 13 v Zenith Blueprint ukladá organizáciám vybrať možnosti ošetrenia rizík: zmierniť, vyhnúť sa, preniesť alebo akceptovať. Zároveň zdôrazňuje schválenie manažmentom:

„Rozhodnutia o ošetrení rizík a SoA majú byť preskúmané a schválené vrcholovým manažmentom.“

Pre DORA a NIS2 je to dôkaz, že riadiaci orgán alebo delegované vedenie preskúmali kľúčové riziká, ošetrenia a akceptovanú zvyškovú expozíciu. Pre GDPR to podporuje preukázateľnú zodpovednosť tým, že ukazuje, prečo boli vybrané opatrenia primerané riziku.

Krok 5: zaznamenajte akceptáciu s dátumom platnosti a podmienkami

Každé akceptované stredné alebo vysoké reziduálne riziko má obsahovať:

• ID rizika a vlastníka
• obchodné odôvodnenie
• odkaz na vyhlásenie o apetíte
• dotknutú prahovú hodnotu tolerancie
• právnu a regulačnú analýzu
• kompenzačné kontroly
• dátum uplynutia platnosti alebo preskúmania
• schvaľovateľa
• umiestnenie dôkazov
• spúšťač opätovného otvorenia rozhodnutia

Risk Management Policy-sme uvádza:

„Každé rozhodnutie akceptovať alebo odložiť ošetrenie vysokého alebo stredného rizika musí byť zdokumentované v registri rizík. Táto dokumentácia musí obsahovať:“

V podnikových prostrediach sa z toho stáva schvaľovací pracovný tok a balík pre výbor pre riziká. V menších organizáciách to môže byť štruktúrovaná karta registra rizík s podpisom manažmentu. Zmyslom nie je byrokracia. Zmyslom je obhájiteľnosť.

Tolerancia incidentov: kde sa apetít stretáva s časom

Apetít voči riziku sa stáva reálnym počas incidentov.

DORA Article 17 vyžaduje, aby finančné subjekty zaviedli proces riadenia incidentov súvisiacich s IKT na detekciu, riadenie a oznamovanie incidentov, zaznamenávanie všetkých incidentov a významných kybernetických hrozieb, identifikáciu koreňových príčin, používanie indikátorov včasného varovania, klasifikáciu incidentov podľa priority, závažnosti a kritickosti služby, priradenie rolí, komunikáciu so zainteresovanými stranami, eskaláciu aspoň závažných incidentov súvisiacich s IKT na vrcholový manažment a riadiaci orgán a včasnú obnovu bezpečnej prevádzky.

DORA Article 18 klasifikuje incidenty podľa faktorov, ako sú dotknutí klienti, trvanie, výpadok, geografický rozsah, straty údajov ovplyvňujúce dostupnosť, autentickosť, integritu alebo dôvernosť, kritickosť dotknutých služieb a ekonomický dopad. Article 19 vyžaduje, aby sa závažné incidenty súvisiace s IKT oznamovali príslušnému orgánu, pričom klienti sa informujú, ak sú dotknuté ich finančné záujmy.

NIS2 Article 23 zavádza stupňované hlásenie významných incidentov vrátane včasného varovania bez zbytočného odkladu a prípadne do 24 hodín, oznámenia incidentu bez zbytočného odkladu a prípadne do 72 hodín, priebežných aktualizácií na vyžiadanie a záverečnej správy najneskôr jeden mesiac po oznámení incidentu. Významné incidenty zahŕňajú incidenty spôsobujúce závažné prevádzkové narušenie, finančnú stratu alebo materiálnu či nemateriálnu ujmu iným osobám.

Vyhlásenie o apetíte má definovať prahové hodnoty eskalácie ešte pred tým, ako incident nastane.

Kontroly v Annex A týkajúce sa plánovania incidentov, posudzovania udalostí informačnej bezpečnosti, reakcie na incidenty, poučenia z incidentov, zberu dôkazov, udržiavania informačnej bezpečnosti počas narušenia a pripravenosti IKT na kontinuitu činností podporujú tieto prahové hodnoty. Výstupy NIST CSF naprieč IDENTIFY, PROTECT, DETECT, RESPOND a RECOVER podporujú rovnaký prevádzkový model vrátane záloh, monitorovania, vyhlásenia incidentu, eskalácie, analýzy koreňovej príčiny, komunikácie so zainteresovanými stranami a overenia obnovy.

Tolerancia dodávateľov a cloudu, ktorú riadiace orgány často prehliadajú

DORA robí z rizika IKT tretích strán kľúčovú povinnosť súladu. Article 28 vyžaduje, aby finančné subjekty riadili riziko IKT tretích strán ako súčasť rámca riadenia rizík IKT, pričom zostávajú plne zodpovedné za súlad. Vyžaduje stratégiu rizika IKT tretích strán, registre zmluvných dohôd o IKT službách, rozlíšenie služieb podporujúcich kritické alebo dôležité funkcie, ročné výkazníctvo, oznamovanie plánovaných dohôd, predzmluvné posúdenia, due diligence, práva na audit a kontrolu, práva na ukončenie a zdokumentované stratégie ukončenia.

Article 29 pridáva analýzu rizika koncentrácie vrátane nenahraditeľnosti, viacnásobných závislostí od rovnakých alebo prepojených poskytovateľov, rizík subdodávok, subdodávateľov z tretích krajín, súladu s ochranou údajov, vymožiteľnosti a zložitých reťazcov subdodávateľov. Article 30 vyžaduje písomné zmluvné práva a povinnosti, opisy služieb, umiestnenia, bezpečnostné ochrany, prístup k údajom a ich vrátenie, úrovne služieb, pomoc pri incidentoch, spoluprácu s orgánmi, práva na ukončenie, otestované plány pre mimoriadne situácie, monitorovanie a dohody o ukončení.

Vyhlásenie o tolerancii dodávateľov schválené riadiacim orgánom môže znieť:

„Máme nízky apetít voči závislosti kritických alebo dôležitých funkcií od poskytovateľa IKT služieb tretej strany, ak nemáme zmluvné práva na audit, otestované dohody o ukončení, povinnosti oznamovania incidentov, ciele úrovne služieb, práva na vrátenie údajov alebo viditeľnosť podstatného subdodávateľského reťazca.“

Táto veta dáva obstarávaniu praktické pravidlo. Ak zmluva nespĺňa prahovú hodnotu, projektový tím nemôže riziko ticho akceptovať.

Ako audítori otestujú váš apetít voči riziku IKT

Silné vyhlásenie o apetíte je navrhnuté s ohľadom na audit.

Step 28 v Zenith Blueprint, vo fáze Audit, preskúmanie a zlepšovanie, posilňuje vrstvu preskúmania manažmentom. Ukladá organizáciám zhromaždiť vstupy, ako sú zmeny externých a interných otázok, výkonnosť ISMS, výsledky auditov, monitorovanie a meranie, incidenty, nezhody, príležitosti na zlepšenie a potreby zdrojov. Zároveň uvádza, že preskúmanie manažmentom musí viesť k rozhodnutiam a opatreniam, nie iba k prezentáciám.

Aspoň raz ročne a vždy pri podstatných zmenách má manažment preskúmať, či sú prahové hodnoty tolerancie stále zosúladené s obchodným modelom, či incidenty prekročili apetít, či akceptované riziká zostávajú v schválených hraniciach, či nové požiadavky DORA, NIS2, GDPR alebo zmluvné požiadavky zmenili základnú úroveň, či dodávatelia zostávajú v toleranciách koncentrácie a či KRI spôsobujú včasnú eskaláciu.

Ak je odpoveď nie, musí sa zmeniť vyhlásenie o apetíte alebo kontrolné opatrenia.

Časté vzorce zlyhaní v práci na pripravenosti v roku 2026

V projektoch DORA, NIS2, GDPR a ISO/IEC 27001:2022 sa opakovane objavujú rovnaké slabiny:

• Apetít bez prahových hodnôt, keď riadiaci orgán schváli vyhlásenie, ale nikto nevie určiť, kedy bolo porušené.
• Prahové hodnoty bez právomoci, keď úrovne závažnosti existujú, ale vlastníci rizík môžu akceptovať výnimky bez schválenia vyšším vedením.
• Právne riziko mimo modelu skórovania, keď sú GDPR, DORA, NIS2 a zmluvy uvedené oddelene, ale nie sú zahrnuté do kritérií dopadu.
• Tolerancia dodávateľov chýba v materiáli pre riadiaci orgán, hoci kritické závislosti IKT sú známe obstarávaniu alebo IT.
• Preskúmanie manažmentom ako divadlo, keď sa prezentujú slajdy, ale rozhodnutia, opatrenia, potreby zdrojov a akceptácie rizík nie sú zdokumentované.
• Fragmentácia auditných dôkazov, keď politiky, registre, KRI, incidentné správy, preskúmania dodávateľov a zápisnice riadiaceho orgánu existujú na rôznych miestach bez krížových odkazov.

Prístup Clarysec je navrhnutý tak, aby tieto medzery odstránil. Zenith Blueprint poskytuje fázovanú cestu implementácie. Risk Management Policy a Risk Management Policy-sme poskytujú ustanovenia správy a riadenia škálované pre podnikové prostredia a prostredia MSP. Zenith Controls mapuje kostru kontrol naprieč politikou informačnej bezpečnosti, zodpovednosťou manažmentu a zákonnými alebo regulačnými požiadavkami, čím robí dôkazy opätovne použiteľnými naprieč ISO/IEC 27001:2022, DORA, NIS2, GDPR, NIST CSF a uistením v štýle COBIT.

Premena zámeru riadiaceho orgánu na auditovateľné riadenie rizík IKT

Ak vaša organizácia má register rizík, ale nevie preukázať apetít voči riziku IKT schválený riadiacim orgánom, merateľné prahové hodnoty tolerancie, spúšťače eskalácie a formálne pravidlá akceptácie, nejde o kozmetickú medzeru. Ovplyvňuje správu a riadenie podľa DORA, zodpovednosť manažmentu podľa NIS2, obhájiteľnosť podľa GDPR Article 32 a pripravenosť na audit podľa ISO/IEC 27001:2022.

Praktickým ďalším krokom je uskutočniť cielený workshop k apetítu voči riziku IKT s využitím nástrojov Clarysec:

1. Použite Zenith Blueprint Step 10 na definovanie kritérií rizika a škál dopadu.
2. Použite Zenith Blueprint Step 13 na prepojenie možností ošetrenia rizík, reziduálneho rizika a schválenia vyhlásenia o uplatniteľnosti.
3. Použite Zenith Blueprint Step 14 na krížové odkazy na povinnosti podľa GDPR, NIS2 a DORA.
4. Použite Zenith Blueprint Step 28 na zahrnutie apetítu, KRI, akceptovaných rizík a rozhodnutí o zdrojoch do preskúmania manažmentom.
5. Aplikujte Risk Management Policy alebo Risk Management Policy-sme na formalizáciu pravidiel schvaľovania a akceptácie.
6. Použite Zenith Controls na mapovanie kontrol správy a riadenia na auditné dôkazy a očakávania viacnásobného súladu.

Clarysec vám pomôže premeniť roztrúsené rizikové artefakty na model apetítu voči riziku IKT schválený riadiacim orgánom a pripravený pre regulátora, ktorý vaše tímy využijú, keď najbližší výpadok cloudu, zlyhanie dodávateľa, zverejnenie zraniteľnosti alebo incident s osobnými údajmi preverí skutočnú toleranciu organizácie.