Rizikový apetit v oblasti IKT podle DORA: průvodce schválením vedoucím orgánem pro rok 2026

Je úterý 08:15 a CISO středně velké společnosti působící v oblasti platebních technologií stojí před zasedací místností vedoucího orgánu se třemi dokumenty otevřenými na tabletu.

Prvním je registr IKT rizik. Obsahuje 137 řádků, barevně odlišená hodnocení a několik vysokých rizik souvisejících s koncentrací v cloudu, privilegovaným přístupem, obnovou po ransomwaru, expozicí zákaznických dat a reakcí dodavatelů na incidenty. Druhým je přehled připravenosti na DORA. Uvádí, že společnost má politiky, postupy pro incidenty, registry třetích stran a plány testování odolnosti. Třetím je podkladový balíček pro jednání vedoucího orgánu k regulatorním tématům.

Předseda má jedinou otázku, a není technická:

„Jakou úroveň IKT rizika jsme se vlastně dohodli přijmout?“

V místnosti se rozhostí ticho, protože společnost má posouzení rizik, ale nemá rizikový apetit v oblasti IKT schválený vedoucím orgánem. Má hodnocení dopadů, ale ne měřitelné prahové hodnoty tolerance. Má eskalační jednání, ale žádný formální spouštěč určující, kdy se kybernetické riziko stává rozhodnutím vedoucího orgánu. Má přijatá zbytková rizika, ale některá jsou odůvodněna jako „obchodní rozhodnutí“ bez jasné vazby na kritéria rizik, proporcionalitu podle GDPR Article 32, očekávání DORA v oblasti tolerance nebo odpovědnost vedení podle NIS2.

Tato mezera je v roce 2026 stále viditelnější. DORA se použije od 17. ledna 2025 a vyžaduje, aby finanční subjekty udržovaly rámec správy a řízení a vnitřní kontroly pro IKT riziko, včetně odpovědnosti vedoucího orgánu za rámec řízení IKT rizik, strategii digitální provozní odolnosti a toleranci IKT rizik. NIS2 vede vedoucí orgány ke schvalování opatření k řízení kybernetických rizik a k dohledu nad jejich implementací. GDPR Article 32 vyžaduje vhodná technická a organizační bezpečnostní opatření založená na riziku. ISO/IEC 27001:2022 poskytuje mechanismy systému řízení: kontext, zainteresované strany, kritéria rizik, plány ošetření rizik, dokumentované informace a přezkoumání vedením.

Chybějícím mostem je prohlášení o rizikovém apetitu v oblasti IKT a o toleranci IKT rizik, kterému vedoucí orgán rozumí, které může schválit, zpochybnit a používat.

Tento průvodce vysvětluje, jak tento most vybudovat pomocí Clarysec Zenith Blueprint: 30krokový plán auditora, Clarysec Politika řízení rizik, Clarysec Politika řízení rizik pro SME a Zenith Controls: průvodce napříč požadavky souladu.

Proč registr rizik není rizikový apetit

Mnoho organizací zaměňuje registr rizik za řízení rizik na úrovni správy a řízení. Registr rizik říká, jaká rizika existují, jak jsou hodnocena, kdo je vlastní a jaké ošetření je plánováno. Automaticky však neodpovídá na otázky na úrovni vedoucího orgánu, které DORA, NIS2, GDPR a ISO/IEC 27001:2022 očekávají, že vedení bude řešit.

Vyspělé prohlášení o rizikovém apetitu v oblasti IKT odpovídá na otázky jako:

• Která IKT rizika jsou nepřijatelná bez ohledu na náklady?
• Jaký provozní výpadek může organizace tolerovat u kritické nebo důležité funkce?
• Jaká úroveň ztráty dat nebo narušení integrity dat je mimo rizikový apetit?
• Jaké riziko koncentrace třetích stran vyžaduje pozornost vedoucího orgánu?
• Kdo smí přijmout zbytkové IKT riziko a na jaké úrovni?
• Kdy musí být riziko eskalováno na vrcholové vedení nebo vedoucí orgán?
• Jak jsou právní, regulatorní a smluvní požadavky zahrnuty do kritérií rizik?

Podle DORA nejde o volitelnou kosmetickou úpravu správy a řízení. Article 5 vyžaduje, aby vedoucí orgán definoval a schvaloval rámec řízení IKT rizik, dohlížel na něj a nesl za něj odpovědnost, včetně strategie digitální provozní odolnosti a tolerance IKT rizik. Article 6 vyžaduje dokumentovaný rámec řízení IKT rizik, každoroční přezkum u podniků, které nejsou mikropodniky, interní audit, nápravu kritických zjištění auditu a strategii digitální provozní odolnosti s IKT cíli, tolerancí rizik, tolerancí dopadů, architekturou, testováním a strategií komunikace při incidentech.

NIS2 doplňuje paralelní model odpovědnosti. Article 20 vyžaduje, aby vedoucí orgány základních a důležitých subjektů schvalovaly opatření k řízení kybernetických rizik, dohlížely na jejich implementaci a absolvovaly školení. Article 21 vyžaduje vhodná a přiměřená technická, provozní a organizační opatření založená na přístupu zohledňujícím všechna rizika, včetně analýzy rizik, zvládání incidentů, kontinuity činností, zabezpečení dodavatelského řetězce, bezpečného vývoje, účinnosti opatření, školení, kryptografie, personální bezpečnosti, řízení přístupu, správy aktiv a MFA tam, kde je to vhodné.

Pro finanční subjekty je DORA považována za odvětvový právní akt Unie tam, kde se překrývají povinnosti podle NIS2. V praxi DORA zpravidla nahrazuje překrývající se požadavky NIS2 na řízení rizik a hlášení incidentů u finančních subjektů spadajících do její působnosti, zatímco NIS2 zůstává důležitá pro koordinaci a pro poskytovatele mimo přímé povinnosti finančních subjektů podle DORA. Pro poskytovatele SaaS, cloudových služeb, řízených služeb a řízených bezpečnostních služeb se NIS2 může použít přímo, pokud jsou splněny podmínky působnosti.

Proto již rizikový apetit v oblasti IKT schválený vedoucím orgánem není artefaktem finančního rizika. Je to mechanismus správy a řízení kybernetické bezpečnosti.

Použijte ISO/IEC 27001:2022 jako operační systém

DORA a NIS2 říkají vedení, co musí být řízeno. ISO/IEC 27001:2022 dává organizacím praktický operační systém, jak to řídit.

Kapitoly ISO/IEC 27001:2022 4.1 až 4.4 vyžadují, aby organizace definovala kontext, zainteresované strany, požadavky, rozsah ISMS a procesy ISMS. Je to důležité, protože DORA, NIS2, GDPR, smlouvy, očekávání dohledových orgánů, zákazníci, poskytovatelé cloudových služeb a outsourcingová ujednání se stávají požadavky, které ovlivňují kritéria rizik.

Kapitoly 5.1 až 5.3 vyžadují závazek vedení, sladění politik, zdroje, odpovědnosti a vykazování výkonnosti ISMS vrcholovému vedení. Kapitoly 6.1.1 až 6.1.3 vyžadují plánování založené na rizicích, dokumentovaný proces posouzení rizik, kritéria pro přijetí rizik, konzistentní kritéria hodnocení, vlastníky rizik, porovnání s kritérii rizik, plánování ošetření rizik, Prohlášení o použitelnosti a schválení zbytkového rizika.

To je základ pro toleranci IKT rizika podle DORA.

Ve fázi řízení rizik krok 10 dokumentu Zenith Blueprint stanoví, že organizace mají definovat kritéria rizik před samotným hodnocením rizik:

„Kritéria rizik jsou pravidla a měřítka, která vaše organizace používá k hodnocení významnosti jednotlivých rizik. Stanovení těchto kritérií předem zajišťuje, že všichni používají stejný jazyk rizik.“

Tentýž krok upozorňuje, že regulatorní dopad musí být zahrnut do definic rizik:

„Jakékoli riziko, které by mohlo vést k nesouladu s použitelnými právními předpisy (GDPR apod.), není přijatelné a musí být zmírněno.“

Zenith Blueprint poskytuje také praktické pokyny pro škálování dopadů:

„Při definování dopadu je vhodné vztáhnout jednotlivé úrovně ke konkrétnímu rozsahu vašeho podnikání. Například: ‘Závažný finanční dopad = ztráta > 100 tis. USD’ (upravte podle svého kontextu). Zvažte také regulatorní dopad: například porušení zabezpečení osobních údajů může být automaticky ‘Závažné’ nebo ‘Kritické’ kvůli pokutám podle GDPR a oznamovacím povinnostem, i když přímá finanční ztráta není jasná. Podobně pokud spadáte do působnosti NIS2 (základní služby), incident způsobující narušení služby může být alespoň ‘Závažný’ kvůli právním důsledkům. Zahrňte takové úvahy do svých definic.“

Toto doporučení předchází častému selhání: hodnocení kybernetického rizika jako středního jen proto, že okamžitá finanční ztráta vypadá nízká, zatímco právní dopad, provozní odolnost, dopad na subjekt údajů nebo dopad na zákazníka jsou ignorovány.

Model připravený pro vedoucí orgán by měl oddělit čtyři vrstvy:

Tato struktura činí rizikový apetit auditovatelným, protože každé prohlášení lze dohledat ke kritériím rizik, opatřením, důkazům a rozhodnutím.

Prohlášení o rizikovém apetitu v oblasti IKT podle DORA připravené pro vedoucí orgán

Silné prohlášení o rizikovém apetitu v oblasti IKT je dostatečně krátké, aby je vedoucí orgán mohl schválit, dostatečně konkrétní, aby je vedení mohlo používat, a dostatečně měřitelné, aby je auditoři mohli ověřit. Mělo by se vyhnout žargonu, ale nesmí být vágní.

Praktické prohlášení na vysoké úrovni může znít:

„Naše společnost má nízký rizikový apetit v oblasti IKT rizik, která by mohla vést k významné újmě klientů, narušení kritických nebo důležitých funkcí, neoprávněnému zpřístupnění nebo změně regulovaných dat, nesplnění právních povinností nebo ztrátě odolnosti u kritických IKT služeb třetích stran.“

Toto prohlášení poté potřebuje měřitelné prahové hodnoty tolerance a eskalační spouštěče.

Tato tabulka mění diskusi. Vedoucí orgán již neschvaluje slogan. Schvaluje provozní hranice pro dostupnost, důvěrnost, integritu, dodavatele, zranitelnosti, obnovu a soulad.

Clarysec Politika řízení rizik tento model správy a řízení podporuje. Podniková politika uvádí:

„Schvaluje rámec řízení rizik a definuje přijatelný rizikový apetit a prahové hodnoty tolerance.“

Kapitola 6.2.1 výslovně stanoví požadavek na měření:

„Rizika musí být posuzována z hlediska pravděpodobnosti a dopadu pomocí standardní matice rizik s jasně definovanými hodnoticími škálami.“

Kapitola 6.3.4 vytváří pravidlo přijetí, které auditoři očekávají:

„Rizika přijatá bez ošetření musí být písemně odůvodněna, navázána na rizikový apetit organizace a schválena na odpovídající úrovni.“

Pro SME zachovává Politika řízení rizik pro SME stejný princip správy a řízení v odlehčené podobě:

„Zajistit zapojení vedení při schvalování tolerance rizik a významných plánů ošetření rizik.“

Vyžaduje také eskalaci vysokých rizik:

„Vysoká rizika musí být eskalována generálnímu řediteli k rozhodnutí.“

To je proporcionalita v praxi. DORA Article 4 vyžaduje, aby byly požadavky uplatňovány způsobem přiměřeným velikosti, rizikovému profilu a povaze, rozsahu a složitosti služeb. ISO/IEC 27001:2022 umožňuje stejný princip prostřednictvím rozsahu, kontextu, kritérií rizik a rozhodnutí o ošetření rizik. Standardem správy a řízení není to, že každá organizace potřebuje stejnou strukturu výborů. Standardem správy a řízení je, že rizikový apetit, tolerance, eskalace a přijetí jsou definovány, schváleny, doloženy a používány.

GDPR Article 32 mění diskusi o riziku

GDPR Article 32 je často vnímán jako ustanovení o technickém zabezpečení. Z pohledu správy a řízení je také ustanovením o rizikovém apetitu.

Article 32 vyžaduje, aby správci a zpracovatelé zavedli vhodná technická a organizační opatření k zajištění úrovně zabezpečení odpovídající riziku. Tento přístup založený na riziku zohledňuje stav techniky, náklady na implementaci, povahu, rozsah, kontext a účely zpracování a rizika pro práva a svobody fyzických osob.

To ovlivňuje rizikový apetit v oblasti IKT třemi způsoby.

Za prvé, dopad na osobní údaje nelze redukovat na finanční ztrátu. Expozice malé databáze může mít omezené přímé náklady, ale závažné důsledky pro důvěrnost, identitu, podvody, diskriminaci nebo práva osob. Pokud jsou dotčeny zvláštní kategorie osobních údajů, například zdravotní, biometrické nebo genetické údaje, měl by být rizikový apetit podstatně nižší.

Za druhé, role při zpracování musí být propojeny s vlastnictvím rizika. GDPR rozlišuje správce a zpracovatele. DORA rozlišuje finanční subjekty a poskytovatele IKT služeb třetích stran. NIS2 rozlišuje základní a důležité subjekty. ISO/IEC 27001:2022 vyžaduje vlastníky rizik. Vyspělé prohlášení o rizikovém apetitu by mělo určit, kdo vlastní rozhodnutí o rizicích týkajících se osobních údajů, outsourcovaného zpracování, kritických služeb a přeshraničních závislostí.

Za třetí, proporcionalita podle Article 32 má být viditelná ve výběru bezpečnostních opatření. Šifrování, pseudonymizace, řízení přístupu, zálohování, protokolování, monitorování, reakce na incidenty a odolnost nejsou izolované technické úlohy. Jsou to opatření ošetření rizik vybraná proto, že riziko překročilo rizikový apetit nebo toleranci.

Clarysec Politika řízení rizik tuto vazbu výslovně uvádí:

„Article 32: Ukládá přístup k bezpečnostním opatřením založený na riziku, naplňovaný prostřednictvím hodnocení rizik podle dopadu a výběru bezpečnostních opatření.“

To je provozní vazba, kterou auditoři hledají: požadavek Article 32, posouzení rizik, hodnocení rizika, plán ošetření rizik, výběr bezpečnostních opatření, zbytkové riziko a schválení.

Jak Zenith Controls podporuje důkazy napříč požadavky souladu

Prohlášení o rizikovém apetitu schválené vedoucím orgánem získává sílu, když je namapováno na opatření. Zenith Controls funguje jako průvodce Clarysec napříč požadavky souladu a pomáhá týmům znovu využívat důkazy napříč ISO/IEC 27001:2022, DORA, NIS2, GDPR, NIST CSF a zajištěním ve stylu COBIT.

Zvláště důležité jsou tři oblasti opatření podle ISO/IEC 27002:2022:

Nejde o papírové mapování. Mění to způsob rozhodování.

Pokud vlastník obchodního procesu požádá o přijetí odloženého zavedení MFA pro administrátory, Zenith Controls pomáhá CISO ukázat, proč nejde jen o otázku řízení přístupu. Dotýká se správy politik, odpovědnosti vedení, právních a regulatorních požadavků, zabezpečení zpracování podle GDPR, řízení IKT rizik podle DORA, opatření kybernetické bezpečnosti podle NIS2, dopadu incidentů a auditních důkazů.

Pokud chce produktový tým spustit službu na novém trhu EU pomocí nové cloudové služby, opatření ISO/IEC 27002:2022 5.31 posouvá přezkum právních a regulatorních požadavků do rozsahu ISMS. ISO/IEC 27001:2022 kapitola 4.2 vyžaduje identifikaci požadavků zainteresovaných stran, včetně právních, regulatorních a smluvních povinností. Kapitola 8.1 vyžaduje operativní plánování a řízení, včetně řízení externě poskytovaných procesů, produktů nebo služeb relevantních pro ISMS.

Cílem je jeden jazyk rizik, nikoli oddělené dialekty souladu.

Schvalovací postup: kdo o čem rozhoduje

CISO může rizikový apetit v oblasti IKT navrhnout, ale vlastnit jej musí správní orgán nebo vedoucí orgán. Toto vlastnictví vyžaduje schvalovací postup.

To je také v souladu s NIST CSF 2.0. Funkce GOVERN, zejména GV.RM, očekává odsouhlasené cíle řízení rizik, prohlášení o rizikovém apetitu a toleranci, rizikové činnosti integrované do podnikového řízení rizik, definované možnosti reakce na riziko, komunikační linie a standardizované metody pro výpočet, dokumentaci, kategorizaci a prioritizaci kybernetických rizik. GV.RR očekává odpovědnost vedení, role, pravomoci a zdroje sladěné se strategií rizik. GV.PO očekává, že politiky budou stanoveny, komunikovány, prosazovány, přezkoumávány a aktualizovány.

Odborníci na zajištění ve stylu COBIT 19 a ISACA se budou ptát, zda je rizikový apetit integrován do správy a řízení podnikových informací a technologií, nikoli pouze připojen jako příloha ke kybernetické politice.

Vytvořte balíček k rizikovému apetitu v oblasti IKT během jednoho pracovního jednání

Praktický workshop k rizikovému apetitu v oblasti IKT může organizaci posunout od roztříštěných registrů k auditovatelnému balíčku pro vedoucí orgán.

Krok 1: shromážděte správné vstupy

Připravte aktuální registr IKT rizik, analýzu dopadů na obchodní činnost, cíle obnovy, seznam kritických nebo důležitých funkcí, evidenci IKT aktiv, evidenci IKT služeb, registr závislostí na dodavatelích a cloudu, kritéria klasifikace incidentů, evidenci činností zpracování podle GDPR, relevantní DPIA, registr právních povinností, politiky, Prohlášení o použitelnosti a stávající podnikové prohlášení o rizikovém apetitu.

To odpovídá kapitolám ISO/IEC 27001:2022 4, 6 a 8 a metodám profilů NIST CSF, které začínají obchodními prioritami, rizikovými prioritami, požadavky, ochrannými opatřeními a rolemi.

Krok 2: definujte škály dopadů včetně regulace

Pomocí Zenith Blueprint krok 10 definujte pravděpodobnost a dopad v obchodním jazyce. Zahrňte finanční ztrátu, provozní narušení, dopad na zákazníky, poškození dobré pověsti, právní a regulatorní dopad, újmu subjektů údajů a dopad na kritické funkce.

Například „závažný“ dopad může zahrnovat dlouhodobý výpadek kritické služby, potvrzené porušení zabezpečení osobních údajů vyžadující oznámení, nesplnění oznamovací povinnosti k incidentu podle DORA nebo selhání dodavatele ovlivňující kritickou nebo důležitou funkci.

Krok 3: formulujte rizikový apetit podle domén

Nevytvářejte jeden obecný kybernetický rizikový apetit. Definujte domény, jako je dostupnost kritických služeb, důvěrnost osobních údajů, integrita dat, privilegovaný přístup, závislost na IKT třetích stranách, koncentrace v cloudu, expozice zranitelnostem, připravenost na hlášení incidentů, zálohování a obnova a riziko změn v bezpečném vývoji.

Pro každou doménu napište jedno prohlášení o rizikovém apetitu, jednu nebo více prahových hodnot tolerance a eskalační spouštěče.

Krok 4: propojte ošetření rizik s Prohlášením o použitelnosti

Krok 13 dokumentu Zenith Blueprint ukládá organizacím vybrat možnosti ošetření rizik: zmírnit, vyhnout se, přenést nebo přijmout. Zdůrazňuje také schválení vedením:

„Rozhodnutí o ošetření rizik a SoA mají být přezkoumána a schválena vrcholovým vedením.“

Pro DORA a NIS2 je to důkaz, že vedoucí orgán nebo delegované vedení přezkoumalo klíčová rizika, ošetření a přijatou zbytkovou expozici. Pro GDPR to podporuje odpovědnost tím, že ukazuje, proč byla vybraná opatření přiměřená riziku.

Krok 5: zaznamenejte přijetí s expirací a podmínkami

Každé přijaté střední nebo vysoké zbytkové riziko by mělo obsahovat:

• ID rizika a vlastníka
• Obchodní odůvodnění
• Odkaz na prohlášení o rizikovém apetitu
• Dotčenou prahovou hodnotu tolerance
• Právní a regulatorní analýzu
• Kompenzační opatření
• Datum expirace nebo přezkumu
• Schvalovatele
• Umístění důkazů
• Spouštěč pro opětovné otevření rozhodnutí

Politika řízení rizik pro SME uvádí:

„Jakékoli rozhodnutí přijmout nebo odložit ošetření vysokého nebo středního rizika musí být zdokumentováno v registru rizik. Tato dokumentace musí obsahovat:“

V podnikovém prostředí se z toho stává schvalovací pracovní postup a balíček pro výbor pro rizika. V menších organizacích může jít o strukturovanou záložku registru rizik se schválením vedením. Smyslem není byrokracie. Smyslem je obhajitelnost.

Tolerance incidentů: kde se rizikový apetit potkává s časem

Rizikový apetit se stává reálným během incidentů.

DORA Article 17 vyžaduje, aby finanční subjekty zavedly proces řízení incidentů souvisejících s IKT k detekci, řízení a oznamování incidentů, zaznamenávaly všechny incidenty a významné kybernetické hrozby, identifikovaly kořenové příčiny, používaly indikátory včasného varování, klasifikovaly incidenty podle priority, závažnosti a kritičnosti služby, přiřadily role, komunikovaly se zainteresovanými stranami, eskalovaly alespoň závažné incidenty související s IKT na vrcholové vedení a vedoucí orgán a včas obnovily bezpečný provoz.

DORA Article 18 klasifikuje incidenty pomocí faktorů, jako jsou dotčení klienti, trvání, výpadek, geografický rozsah, ztráty dat ovlivňující dostupnost, autenticitu, integritu nebo důvěrnost, kritičnost dotčených služeb a ekonomický dopad. Article 19 vyžaduje hlášení závažných incidentů souvisejících s IKT příslušnému orgánu a informování klientů, pokud jsou dotčeny jejich finanční zájmy.

NIS2 Article 23 stanoví postupné hlášení významných incidentů, včetně včasného varování bez zbytečného odkladu a tam, kde je to použitelné, do 24 hodin, oznámení incidentu bez zbytečného odkladu a tam, kde je to použitelné, do 72 hodin, průběžných aktualizací na vyžádání a závěrečné zprávy nejpozději jeden měsíc po oznámení incidentu. Významné incidenty zahrnují incidenty způsobující závažné provozní narušení, finanční ztrátu nebo hmotnou či nehmotnou újmu jiným osobám.

Prohlášení o rizikovém apetitu má definovat eskalační prahové hodnoty ještě před vznikem incidentu.

Opatření z Annex A týkající se plánování incidentů, posouzení událostí bezpečnosti informací, reakce na incidenty, poučení z incidentů, sběru důkazů, udržení bezpečnosti informací během narušení a IKT připravenosti pro kontinuitu činností tato prahová nastavení podporují. Výstupy NIST CSF napříč IDENTIFY, PROTECT, DETECT, RESPOND a RECOVER podporují stejný provozní model, včetně záloh, monitorování, vyhlášení incidentu, eskalace, analýzy kořenové příčiny, komunikace se zainteresovanými stranami a ověření obnovy.

Tolerance dodavatelů a cloudu, kterou vedoucí orgány často přehlížejí

DORA činí riziko IKT třetích stran klíčovou povinností v oblasti souladu. Article 28 vyžaduje, aby finanční subjekty řídily IKT riziko třetích stran jako součást rámce řízení IKT rizik, přičemž zůstávají plně odpovědné za soulad. Vyžaduje strategii IKT rizik třetích stran, registry smluvních ujednání k IKT službám, rozlišení služeb podporujících kritické nebo důležité funkce, každoroční reporting, oznámení plánovaných ujednání, předsmluvní posouzení, náležitou péči, práva na audit a kontrolu, práva na ukončení a dokumentované strategie ukončení.

Article 29 doplňuje analýzu rizika koncentrace, včetně nezastupitelnosti, vícenásobných závislostí na stejných nebo propojených poskytovatelích, rizik subdodávek, subdodavatelů ze třetích zemí, souladu s ochranou údajů, vymahatelnosti a složitých subdodavatelských řetězců. Article 30 vyžaduje písemná smluvní práva a povinnosti, popisy služeb, lokality, bezpečnostní ochranu, přístup k datům a jejich vrácení, úrovně služeb, pomoc při incidentech, spolupráci s orgány, práva na ukončení, testované nouzové plány, monitorování a ujednání o ukončení.

Prohlášení o toleranci dodavatelů schválené vedoucím orgánem může znít:

„Máme nízký rizikový apetit pro situace, kdy jsou kritické nebo důležité funkce závislé na poskytovateli IKT služeb třetí strany a současně nemáme smluvní práva na audit, otestovaná ujednání o ukončení, povinnosti oznamování incidentů, cíle úrovně služeb, práva na vrácení dat nebo viditelnost významných subdodávek.“

Tato věta dává nákupu praktické pravidlo. Pokud smlouva nesplňuje prahovou hodnotu, riziko nemůže být tiše přijato projektovým týmem.

Jak auditoři otestují váš rizikový apetit v oblasti IKT

Silné prohlášení o rizikovém apetitu je navrženo s ohledem na audit.

Krok 28 dokumentu Zenith Blueprint ve fázi Audit, přezkum a zlepšování posiluje vrstvu přezkoumání vedením. Ukládá organizacím shromažďovat vstupy, jako jsou změny externích a interních otázek, výkonnost ISMS, výsledky auditů, monitorování a měření, incidenty, neshody, příležitosti ke zlepšení a potřeby zdrojů. Také uvádí, že přezkoumání vedením musí vést k rozhodnutím a opatřením, nikoli pouze k prezentacím.

Alespoň jednou ročně a vždy při významných změnách by vedení mělo přezkoumat, zda prahové hodnoty tolerance stále odpovídají obchodnímu modelu, zda incidenty překročily rizikový apetit, zda přijatá rizika zůstávají v rámci schválených hranic, zda nové požadavky DORA, NIS2, GDPR nebo smluv změnily výchozí stav, zda dodavatelé zůstávají v rámci tolerancí koncentrace a zda KRI vyvolávají včasnou eskalaci.

Pokud je odpověď záporná, musí se změnit prohlášení o rizikovém apetitu, nebo opatření.

Časté vzorce selhání v práci na připravenosti v roce 2026

V projektech DORA, NIS2, GDPR a ISO/IEC 27001:2022 se opakovaně objevují stejné slabiny:

• Rizikový apetit bez prahových hodnot, kdy vedoucí orgán schválí prohlášení, ale nikdo nedokáže říci, kdy bylo porušeno.
• Prahové hodnoty bez pravomoci, kdy existují úrovně závažnosti, ale vlastníci rizik mohou přijímat výjimky bez schválení vrcholovým vedením.
• Právní riziko mimo skórovací model, kdy jsou GDPR, DORA, NIS2 a smlouvy uvedeny odděleně, ale nejsou začleněny do kritérií dopadu.
• Tolerance dodavatelů chybí v podkladech pro vedoucí orgán, přestože kritické IKT závislosti zná nákup nebo IT.
• Přezkoumání vedením jako divadlo, kdy jsou prezentovány slidy, ale rozhodnutí, opatření, potřeby zdrojů a přijetí rizik nejsou dokumentovány.
• Fragmentace auditních důkazů, kdy politiky, registry, KRI, zprávy o incidentech, přezkumy dodavatelů a zápisy vedoucího orgánu existují na různých místech bez křížových odkazů.

Přístup Clarysec je navržen tak, aby tyto mezery odstranil. Zenith Blueprint poskytuje fázovanou implementační cestu. Politika řízení rizik a Politika řízení rizik pro SME poskytují ustanovení správy a řízení škálovaná pro podniková prostředí a prostředí SME. Zenith Controls mapuje osu opatření napříč politikou bezpečnosti informací, odpovědností vedení a právními nebo regulatorními požadavky, takže důkazy lze znovu využít napříč ISO/IEC 27001:2022, DORA, NIS2, GDPR, NIST CSF a zajištěním ve stylu COBIT.

Proměňte záměr vedoucího orgánu v auditovatelné řízení IKT rizik

Pokud vaše organizace má registr rizik, ale nedokáže doložit rizikový apetit v oblasti IKT schválený vedoucím orgánem, měřitelné prahové hodnoty tolerance, eskalační spouštěče a formální pravidla přijetí, nejde o kosmetickou mezeru. Ovlivňuje správu a řízení podle DORA, odpovědnost vedení podle NIS2, obhajitelnost podle GDPR Article 32 a připravenost na audit podle ISO/IEC 27001:2022.

Praktickým dalším krokem je uspořádat cílený workshop k rizikovému apetitu v oblasti IKT s využitím nástrojů Clarysec:

1. Použijte Zenith Blueprint krok 10 k definování kritérií rizik a škál dopadů.
2. Použijte Zenith Blueprint krok 13 k propojení možností ošetření rizik, zbytkového rizika a schválení Prohlášení o použitelnosti.
3. Použijte Zenith Blueprint krok 14 ke křížovému odkázání povinností podle GDPR, NIS2 a DORA.
4. Použijte Zenith Blueprint krok 28 k začlenění rizikového apetitu, KRI, přijatých rizik a rozhodnutí o zdrojích do přezkoumání vedením.
5. Použijte Politiku řízení rizik nebo Politiku řízení rizik pro SME k formalizaci pravidel schvalování a přijetí.
6. Použijte Zenith Controls k mapování opatření správy a řízení na auditní důkazy a očekávání napříč požadavky souladu.

Clarysec vám může pomoci převést roztříštěné rizikové artefakty na model rizikového apetitu v oblasti IKT schválený vedoucím orgánem a připravený pro regulatorní přezkum, který vaše týmy mohou použít ve chvíli, kdy další výpadek cloudu, selhání dodavatele, oznámení zranitelnosti nebo incident týkající se osobních údajů otestuje skutečnou toleranci organizace.