Kapitola má čtyři články a rozhoduje o dvou věcech: jestli se na vás nařízení použije a v jakém rozsahu. Zařadili jsme všechny čtyři, protože bez nich nemá zbytek smysl číst. Nevypisujeme celý výčet jedenadvaceti kategorií adresátů v čl. 2 odst. 1 ani všech 65 definic v čl. 3 — popisujeme jejich logiku a u obou vedeme odkaz do úředního znění, kde jsou úplné.
Co tato stránka je a co není
Nařízení má 64 článků, tato stránka rozebírá 37 z nich v praktickém výběru — ne úplný výčet. Vynechané články buď jen zmocňují evropské orgány dohledu k vydání technických norem, nebo upravují vnitřní chod dohledových struktur EU, nebo mění jiná nařízení; co z které kapitoly vypadlo a proč, říká sekce Přehled na začátku každé části. U zařazených článků uvádíme úřední nadpis, vlastní parafrázi předmětu úpravy a samostatnou vysvětlivku CypherOn s praktickým dopadem. Text nařízení tu neopisujeme a stránka není úředním zněním ani právním stanoviskem — pro závaznou citaci vždy otevřete české znění na EUR-Lexu, odkaz vede u každého článku zvlášť. Ještě jedna past: úřední překlad píše IKT tam, kde praxe říká ICT. V nadpisech proto najdete IKT, v našich větách ICT — a při hledání v úředním textu je nutné psát IKT, jinak dotaz nic nenajde. Bloky „Vysvětlivka CypherOn“ jsou náš výklad, ne text nařízení.
Žádný paragraf neodpovídá hledanému výrazu.
Kapitola I
Obecná ustanovení (čl. 1 až 4)
Vymezuje šest oblastí, které nařízení sjednocuje: řízení rizika ICT, hlášení závažných incidentů, hlášení platebních incidentů u bank a platebních institucí, testování digitální provozní odolnosti, sdílení informací o hrozbách a řízení rizika u dodavatelů ICT. K tomu přidává pravidla pro smlouvy s poskytovateli ICT a rámec dohledu nad těmi kritickými. Odstavec 2 určuje, že vůči finančním subjektům, které jsou podle národní transpozice NIS2 základními nebo důležitými subjekty, se DORA považuje za odvětvový akt ve smyslu čl. 4 uvedené směrnice. Úřední znění čl. 1
Vysvětlivka CypherOn
Odstavec 2 je věta, kvůli které se finanční sektor neřídí zákonem o kybernetické bezpečnosti v plném rozsahu — DORA je vůči NIS2 lex specialis. Neznamená to, že vám ZKB nemůže dopadnout vůbec: rozhoduje, kterou službu poskytujete a v jaké roli. Souběh obou předpisů rozebírá průvodce. A protože jde o nařízení, je přímo použitelné — čekat na „českou DORA“ nemá smysl, zákon č. 31/2025 Sb. řeší jen dohled, pravomoci a přestupky.
Odstavec 1 vyjmenovává pod písmeny a) až u) jedenadvacet kategorií adresátů — od úvěrových institucí, platebních institucí a institucí elektronických peněz přes investiční podniky, fondy, pojišťovny a zprostředkovatele až po tržní infrastrukturu, ratingové agentury a poskytovatele služeb ICT z řad třetích stran. Odstavec 2 říká, že souhrnný pojem finanční subjekt se týká jen písmen a) až t); poskytovatel ICT pod písmenem u) finančním subjektem není. Odstavec 3 vyjímá šest skupin, mimo jiné malé správce alternativních fondů, malé zprostředkovatele pojištění a penzijní instituce s celkem nejvýše 15 účastníky. Odstavec 4 dovoluje členskému státu vyjmout některé instituce podle směrnice 2013/36/EU. Úřední znění čl. 2
Vysvětlivka CypherOn
Dva omyly, na které narážíme nejčastěji. První: „jsme jen softwarový dodavatel, na nás DORA neplatí“ — poskytovatel služeb ICT je v působnosti podle písm. u). Přímý dohled EU na něj dopadne jen tehdy, je-li určen jako kritický (čl. 31), ale povinnosti z čl. 30 na něj přenese klient ve smlouvě a odmítnout je znamená přijít o zakázku. Druhý: „jsme malí, takže mimo“ — z působnosti vypadávají jen skupiny vyjmenované v odst. 3, malá velikost sama o sobě nestačí. Malý subjekt bývá ve zjednodušeném režimu podle čl. 16, což není totéž jako být mimo nařízení. Než začnete číst povinnosti, určete si roli — na to je část průvodce o působnosti.
Obsahuje 65 definic. Čtyři z nich rozhodují o rozsahu povinností: zásadní nebo důležitá funkce (funkce, jejíž narušení by významně zasáhlo finanční výkonnost, kontinuitu služeb nebo plnění podmínek povolení), závažný incident související s IKT (incident s velkým nepříznivým dopadem na systémy zajišťující tyto funkce), mikropodnik (finanční subjekt s méně než 10 zaměstnanci a obratem či bilanční sumou do 2 milionů eur, s výjimkou obchodních systémů, ústředních protistran, registrů obchodních údajů a centrálních depozitářů) a poskytovatel služeb IKT z řad třetích stran. Úřední znění čl. 3
Vysvětlivka CypherOn
Určení zásadních a důležitých funkcí je nejdůležitější rozhodnutí celého projektu — visí na něm rozsah smluvních povinností podle čl. 30 odst. 3, rozsah testování podle čl. 24 odst. 6, obsah registru informací i to, co budete hlásit. Doporučujeme ho udělat písemně a s odůvodněním, protože je to první věc, na kterou se dozorový orgán zeptá, a druhá věc, kterou vám zpochybní dodavatel při vyjednávání o auditních právech. Pozor také na to, že mikropodnik podle DORA není totéž co subjekt ve zjednodušeném režimu podle čl. 16 — jsou to dvě různé kategorie s různými důsledky a pletou se pravidelně.
Pravidla kapitoly II se uplatňují úměrně velikosti subjektu, jeho rizikovému profilu a povaze, rozsahu a složitosti jeho služeb. U kapitol III, IV a V oddílu I platí proporcionalita jen tam, kde ji konkrétní ustanovení výslovně připouští. Příslušné orgány k uplatnění proporcionality přihlédnou při přezkumu rámce na základě zpráv podle čl. 6 odst. 5 a čl. 16 odst. 2. Úřední znění čl. 4
Vysvětlivka CypherOn
Proporcionalita není výjimka, je to měřítko hloubky. Neomlouvá chybějící dokument — omlouvá jeho rozsah. V praxi se osvědčuje mít v rámci řízení rizik ICT jeden odstavec, který zdůvodňuje zvolenou úroveň podrobnosti ve vztahu k velikosti a rizikovému profilu; když ho tam nemáte, argumentujete proporcionalitou až ve chvíli, kdy se vás někdo ptá, a to je pozdě.
Kapitola II · čl. 5 až 15
Rámec řízení rizika ICT (čl. 5 až 15)
Jádro nařízení. Kapitola má dva oddíly — oddíl I tvoří samotný čl. 5, oddíl II články 6 až 16 — a my z ní čl. 16 vyčleňujeme do samostatné části níž, protože se týká jiného okruhu subjektů. Čl. 5 přiděluje odpovědnost vedení, čl. 6 zakládá rámec řízení rizika ICT a čl. 7 až 14 rozepisují jeho obsah v pořadí identifikace, ochrana, detekce, reakce a obnova, zálohování, poučení a komunikace. Zařadili jsme čl. 5 až 14. Vynechali jsme čl. 15, protože je to zmocnění evropských orgánů dohledu k vydání technické normy — jeho výsledkem je nařízení v přenesené pravomoci (EU) 2024/1774, které jednotlivá opatření rozepisuje mnohem podrobněji než samotná DORA a je to text, který se v projektech reálně používá. Ustanovení této kapitoly se nepoužijí na subjekty ve zjednodušeném režimu podle čl. 16.
Finanční subjekt má vnitřní řídicí a kontrolní rámec pro řízení rizika ICT. Vedoucí orgán schvaluje opatření rámce, dohlíží na ně a odpovídá za ně — nese konečnou odpovědnost za řízení rizika ICT, schvaluje strategii digitální provozní odolnosti včetně přípustné odchylky rizika, schvaluje politiku zachování provozu a plány reakce a obnovy, schvaluje plány auditů ICT, přiděluje na odolnost rozpočet a schvaluje strategii pro využívání dodavatelů ICT. Subjekty jiné než mikropodniky navíc zřídí funkci pro sledování dodavatelských ujednání, nebo tím pověří jednoho vedoucího pracovníka. Členové vedoucího orgánu se v této oblasti pravidelně školí. Úřední znění čl. 5
Vysvětlivka CypherOn
Tenhle článek se plní hůř, než vypadá, protože se plní doklady, ne tvrzeními. Zápis z jednání, kde vedení schválilo rámec řízení rizika ICT, přijalo strategii odolnosti, stanovilo přípustnou odchylku rizika a přidělilo rozpočet, plus prezenční listina ze školení vedení — to je celý důkazní balík a stojí jedno jednání ročně. Bez něj nemáte čím doložit ani konečnou odpovědnost, ani školení. Zároveň je to nejlevnější položka celého projektu, takže odkládat ji na konec je typická chyba pořadí.
Zakládá povinnost mít spolehlivý, ucelený a zdokumentovaný rámec pro řízení rizika ICT jako součást celkového systému řízení rizik, včetně ochrany fyzických součástí a prostor. Subjekty jiné než mikropodniky pověří řízením a kontrolou rizika ICT nezávislou kontrolní funkci a oddělí řídicí, kontrolní a auditní role. Rámec se reviduje nejméně jednou ročně, dále po závažném incidentu a na základě zjištění z testů, auditů nebo pokynů dohledu; u mikropodniků pravidelně. Rámec obsahuje strategii digitální provozní odolnosti s cíli, ukazateli, referenční architekturou a komunikační strategií. Ověřování souladu lze zadat externě, odpovědnost zůstává subjektu. Úřední znění čl. 6
Vysvětlivka CypherOn
Kdo má ISMS podle ISO/IEC 27001, má podstatnou část rámce hotovou — ale ne celou. Chybět typicky bude tolerance dopadu narušení a přípustná odchylka rizika (odst. 8 písm. b)), doložení stavu odolnosti počtem hlášených závažných incidentů a účinností preventivních opatření (písm. f)) a napojení na program testování podle kapitoly IV. Zpráva o přezkumu rámce se předkládá na žádost, ne automaticky — což v praxi znamená, že musí existovat dřív, než si o ni orgán řekne. A pozor na požadavek nezávislosti kontrolní funkce: u menších subjektů kolem deseti lidí je to nejčastější místo, kde se model tří linií obrany rozpadne, protože jedna osoba dělá provoz i kontrolu.
Požaduje, aby používané systémy, protokoly a nástroje ICT byly aktualizované, spolehlivé, přiměřené rozsahu činností a kapacitně dostatečné pro zpracování dat a objemů transakcí — a to i při zavádění nové technologie. Vedle toho musí být technologicky odolné, aby zvládly zvýšené nároky za napjatých tržních podmínek nebo v jiných nepříznivých situacích. Úřední znění čl. 7
Vysvětlivka CypherOn
Krátký článek s nepříjemným dosahem: legacy systém po konci podpory, který nejde aktualizovat, je porušení požadavku „aktualizované“ bez ohledu na to, jak dobře je zasíťovaný. Kapacitní požadavek zase míří na chování ve špičce — pokud výkonnostní testy děláte jen na běžném provozu, doklad o zvládnutí napjatých podmínek nemáte. Praktické vodítko: mít plán životního cyklu klíčových komponent a kapacitní testy nad špičkovým, ne průměrným zatížením.
Ukládá identifikovat, klasifikovat a zdokumentovat obchodní funkce podporované ICT, informační aktiva a aktiva ICT, jejich role a vzájemné závislosti, a klasifikaci přezkoumat nejméně jednou ročně. Zdroje rizika se identifikují průběžně, rizikové scénáře se revidují nejméně ročně. Subjekty jiné než mikropodniky posuzují rizika po každé velké změně infrastruktury nebo procesů. Součástí je evidence konfigurací, propojení a závislostí, včetně aktiv na vzdálených pracovištích, a dokumentace procesů závislých na dodavatelích ICT. Úřední znění čl. 8
Vysvětlivka CypherOn
Tady se láme celý projekt. Bez mapy „obchodní funkce → aplikace → infrastruktura → dodavatel“ nelze určit zásadní a důležité funkce, nelze naplnit registr informací podle čl. 28 odst. 3 a nelze určit rozsah testování. Zároveň je to nejpracnější položka, takže se nejčastěji odkládá a pak se dohání v termínu výkazu. Doporučení z praxe: stavět evidenci rovnou v podobě, kterou pobere registr informací podle prováděcího nařízení 2024/2956 — jinak ji budete dělat dvakrát.
Požaduje průběžné sledování a kontrolu bezpečnosti a fungování systémů ICT a nasazení politik, postupů, protokolů a nástrojů, které zajistí odolnost, kontinuitu a dostupnost, zejména u systémů podporujících zásadní nebo důležité funkce. Řešení mají chránit přenos dat, minimalizovat riziko poškození, ztráty a neoprávněného přístupu a bránit chybám ve správě dat. Součástí je zdokumentovaná politika bezpečnosti informací a navazující opatření k řízení přístupů, změn a zranitelností. Úřední znění čl. 9
Vysvětlivka CypherOn
Obsah tohoto článku je v DORA psaný obecně, ale nařízení 2024/1774 ho rozepisuje do konkrétních požadavků — od řízení identit a privilegovaných přístupů přes kryptografii a správu klíčů až po řízení změn a zranitelností. Kdo si vystačí s textem DORA, dostane od auditora seznam chybějících politik. Kdo staví podle 2024/1774, má rovnou strukturu, kterou dohled očekává. To je nejužitečnější věc, kterou o kapitole II umíme říct.
Ukládá mít mechanismy včasné detekce neobvyklých aktivit, problémů v síti a incidentů, včetně identifikace potenciálních kritických míst, a tyto mechanismy pravidelně testovat. Detekce má umožňovat vícestupňovou kontrolu, mít nastavené prahové hodnoty a kritéria výstrah, které spouštějí postupy reakce, včetně automatického upozornění odpovědných pracovníků. Na sledování aktivity uživatelů a anomálií je třeba vyčlenit dostatečné zdroje a kapacity. Úřední znění čl. 10
Vysvětlivka CypherOn
Prahové hodnoty výstrah nejsou technický detail — jsou to hodinky, které rozhodují, kdy vám začne běžet čtyřhodinová lhůta pro prvotní oznámení. Když detekce nefunguje v noci a o víkendu, incident se klasifikuje v pondělí ráno a doložit včasnost hlášení je pak obtížné. Doporučujeme mít písemně, kdo v jaké době výstrahu přebírá a jak se eskaluje k rozhodnutí o klasifikaci; jinak je proces hlášení postavený na tom, kdo se náhodou dívá do konzole.
Zakládá ucelenou politiku zachování provozu ICT a navazující plány reakce a obnovy, které mají zajistit kontinuitu zásadních nebo důležitých funkcí, rychlé zvládnutí incidentu, izolační opatření, odhad dopadů a krizovou komunikaci. Plány se nejméně jednou ročně testují, u subjektů jiných než mikropodniky včetně scénářů kybernetického útoku a přepnutí na záložní kapacitu. Tyto subjekty také zřizují funkci řízení krizí a jejich plány reakce a obnovy podléhají nezávislému internímu auditu. Součástí je analýza dopadu na činnost a vedení záznamů o průběhu výpadků. Úřední znění čl. 11
Vysvětlivka CypherOn
Nejčastější zjištění v této oblasti nejsou chybějící plány, ale plány netestované v tom scénáři, který nastane: obnova ze zálohy se testuje, přepnutí do záložní lokality při ransomwaru ne. Druhá častá mezera je funkce řízení krizí — bývá „u ředitele IT“, což při incidentu znamená, že tentýž člověk řeší technickou obnovu i komunikaci s ČNB a klienty. Rozdělte role dřív, než je budete potřebovat, a záznam o průběhu výpadku veďte průběžně: později z něj vzniká závěrečná zpráva podle nařízení 2025/301 a dohledávat časovou osu zpětně je drahé.
Požaduje zdokumentovanou politiku zálohování s určeným rozsahem dat a minimální frekvencí podle významu a důvěrnosti informací, a k tomu postupy a metody obnovy. Záložní systémy musí být aktivovatelné, aniž ohrozí bezpečnost a integritu dat, a zálohování i obnova se pravidelně testují. Při obnově z vlastních systémů se použije prostředí fyzicky i logicky oddělené od zdrojového. Ústřední protistrany mají navíc obnovit všechny obchody k okamžiku přerušení. Úřední znění čl. 12
Vysvětlivka CypherOn
Požadavek na fyzicky a logicky oddělené prostředí pro obnovu je odpověď na ransomware a v cloudových architekturách bývá formálně splněný, fakticky ne — záloha v témže tenantu a pod týmiž identitami oddělená není. Ověřte tři věci: že obnova nepotřebuje přihlášení do kompromitovaného adresáře, že zálohy nelze smazat provozními oprávněními a že jste obnovu skutečně zkusili, ne jen naplánovali. Doklad o úspěšném testu obnovy je zároveň nejpřesvědčivější příloha při hodnocení dodavatele podle čl. 30 odst. 3 písm. c).
Ukládá sbírat informace o zranitelnostech, hrozbách a incidentech a analyzovat jejich dopad na odolnost. Po závažném incidentu, který narušil hlavní činnosti, se provádí přezkum, který hodnotí rychlost reakce, kvalitu forenzní analýzy, účinnost eskalace a komunikace; subjekty jiné než mikropodniky na žádost sdělí orgánu provedené změny. Poznatky z testování a z reálných incidentů se promítají do posuzování rizik a do školení. Součástí je také sledování technologického vývoje a programy zvyšování povědomí o bezpečnosti pro zaměstnance i vedení. Úřední znění čl. 13
Vysvětlivka CypherOn
Poincidentový přezkum je levný způsob, jak si vyrobit důkaz o fungujícím rámci — a zároveň jediné místo, kde nařízení výslovně chce hodnotit kvalitu forenzní analýzy. Pokud ji nakupujete externě, ošetřete si dostupnost forenzní kapacity smluvně předem; sjednávat ji v den incidentu znamená ztratit první den a s ním velkou část stop. Výstup přezkumu patří na stůl vedoucího orgánu, protože z něj podle čl. 6 odst. 5 vzniká revize rámce.
Požaduje krizové komunikační plány, které umožní odpovědně informovat klienty, protistrany a případně veřejnost alespoň o závažných incidentech a zranitelnostech. Komunikační strategie se odděleně nastavuje pro zaměstnance a pro externí strany, přičemž se rozlišuje mezi lidmi, kteří incident řeší, a těmi, které je třeba informovat. Alespoň jedna osoba v subjektu odpovídá za styk s veřejností a médii pro tyto účely. Úřední znění čl. 14
Vysvětlivka CypherOn
Komunikační plán se v praxi potkává se dvěma dalšími povinnostmi, které mají vlastní hodiny: informováním klientů podle čl. 19 odst. 3, když má incident dopad na jejich finanční zájmy, a případným oznámením porušení zabezpečení osobních údajů podle GDPR. Mít tři různé procesy s třemi různými schvalovateli je spolehlivý způsob, jak zmeškat všechny. Připravte si předschválené šablony sdělení a jasné pravidlo, kdo je pouští ven — v krizi se nevymýšlí, v krizi se doplňují údaje.
Kapitola II · čl. 16
Zjednodušený rámec pro řízení rizika ICT
Zjednodušený režim nahrazuje čl. 5 až 15 osmi povinnostmi. Nemění nic jiného. Klasifikace a hlášení incidentů podle kapitoly III platí stejně, řízení rizika u dodavatelů podle čl. 28 až 30 platí také — s jedinou výjimkou strategie pro riziko třetích stran podle čl. 28 odst. 2, kterou tyto subjekty přijímat nemusí. Z testování je vyňato jen pokročilé penetrační testování na základě hrozeb podle čl. 26; obecný program testování podle čl. 24 se na subjekt použije, pokud není mikropodnikem. Vynechali jsme z této části jen odstavec 3 čl. 16, což je zmocnění k technické normě — tou je nařízení (EU) 2024/1774, jehož hlava II zjednodušený rámec rozepisuje.
Vyjímá z působnosti čl. 5 až 15 pět skupin: malé a nepropojené investiční podniky, platební instituce vyňaté podle směrnice 2015/2366, instituce vyňaté podle směrnice 2013/36/EU (u nichž stát nevyužil možnost podle čl. 2 odst. 4), instituce elektronických peněz vyňaté podle směrnice 2009/110/ES a malé instituce zaměstnaneckého penzijního pojištění. Místo toho jim ukládá osm povinností: zdokumentovaný rámec řízení rizika ICT včetně ochrany fyzických součástí, průběžné sledování bezpečnosti systémů, používání odolných a aktualizovaných nástrojů, rychlou identifikaci zdrojů rizik a anomálií, určení klíčových závislostí na dodavatelích ICT, plány zachování provozu se zálohováním a obnovou, pravidelné testování těchto plánů a kontrol a promítnutí zjištění do posuzování rizik včetně školení. Rámec se dokumentuje, pravidelně přezkoumává a po závažných incidentech reviduje; zpráva o přezkumu se předkládá na žádost. Úřední znění čl. 16
Vysvětlivka CypherOn
Nejčastější omyl v celém nařízení: mikropodnik ve výčtu čl. 16 odst. 1 není. Být mikropodnikem znamená mít úlevy uvnitř čl. 5 až 15 (nemusíte zřizovat nezávislou kontrolní funkci, interní audit rámce, funkci řízení krizí ani program testování podle čl. 24), ale rámec podle čl. 6 vám zůstává. Naopak subjekt ve zjednodušeném režimu může být klidně větší než mikropodnik a čl. 5 až 15 se na něj nepoužijí vůbec. Druhá past je slovo „zjednodušený“ — osm povinností písm. a) až h) je vlastně kompletní malý bezpečnostní program a nařízení 2024/1774 je rozepisuje do konkrétních politik. Když si nejste jistí, do které skupiny patříte, rozhoduje váš status podle sektorové směrnice, ne počet zaměstnanců; probrat to jde v FAQ.
Kapitola III
Řízení, klasifikace a hlášení incidentů (čl. 17 až 23)
Kapitola platí pro všechny finanční subjekty včetně těch ve zjednodušeném režimu a je to část, jejíž nesplnění je nejlépe viditelné — zmeškaná lhůta je datovaná. Zařadili jsme čl. 17 až 20, 22 a 23. Vynechali jsme čl. 21, protože ukládá evropským orgánům dohledu vypracovat zprávu o proveditelnosti jednotného centra EU pro příjem hlášení; pro povinnosti finančního subjektu z něj dnes neplyne nic. Samotné lhůty a prahové hodnoty v DORA nejsou — jsou v navazujících normách, na které u čl. 18 a 20 odkazujeme.
Ukládá zavést proces pro detekci, řízení a hlášení incidentů a zaznamenávat všechny incidenty i závažné kybernetické hrozby. Proces má obsahovat ukazatele včasného varování, postupy pro evidenci, kategorizaci a klasifikaci podle priority a závažnosti, rozdělení rolí pro různé scénáře, komunikační plány včetně informování klientů a interní eskalace a postupy reakce s bezpečnou obnovou služeb. Závažné incidenty se hlásí vedoucím pracovníkům a informuje se o nich vedoucí orgán, včetně dopadů a přijatých opatření. Úřední znění čl. 17
Vysvětlivka CypherOn
Povinnost evidovat všechny incidenty, ne jen ty závažné, se podceňuje. Je to přitom praktická pojistka: bez evidence běžných incidentů nelze doložit, proč jste konkrétní událost neklasifikovali jako závažnou, a to je přesně otázka, která přijde po prvním hlášení. Doporučujeme mít v ticketu povinné pole s výsledkem posouzení podle kritérií čl. 18 a časem, kdy se posouzení dokončilo — od něj se odvíjí čtyřhodinová lhůta.
Stanoví šest kritérií, podle kterých se posuzuje dopad incidentu: počet nebo význam dotčených klientů a protistran a objem transakcí včetně poškození pověsti, doba trvání a odstávka, územní rozsah, ztráta údajů, význam dotčených služeb a ekonomický dopad. Kybernetické hrozby se klasifikují jako významné podle toho, jak zásadní služby ohrožují, koho se týkají a jak velké území zasahují. Prahové hodnoty k těmto kritériím DORA nestanoví — svěřuje je technické normě. Úřední znění čl. 18
Vysvětlivka CypherOn
Prahové hodnoty jsou v nařízení v přenesené pravomoci (EU) 2024/1772: podle jeho čl. 8 odst. 1 je incident závažný, jsou-li dotčeny významné služby podle čl. 6 a zároveň buď došlo k úspěšnému zlovolnému a neoprávněnému přístupu s možnou ztrátou údajů, nebo jsou dosaženy dvě a více jiných prahových hodnot z čl. 9 odst. 1 až 6. Počítací jednotkou je odstavec, ne podmínka uvnitř něj: víc než 10 % klientů a zároveň víc než 10 % transakcí je jedna prahová hodnota, protože obojí je v témže odstavci. Tohle je nejčastější chyba v klasifikaci a vede k oběma směrům omylu. Průchod kritérii nabízí naše stránka o klasifikaci a lhůtách.
Čl. 19
Hlášení závažných incidentů souvisejících s IKT a dobrovolné oznamování významných kybernetických hrozeb
¶Ukládá hlásit závažné incidenty příslušnému orgánu, a to ve třech krocích: prvotní oznámení, průběžná zpráva při významné změně stavu nebo řešení a závěrečná zpráva po dokončení analýzy hlavní příčiny, kdy odhady nahradí skutečná čísla. Významné kybernetické hrozby lze oznamovat dobrovolně. Má-li incident dopad na finanční zájmy klientů, subjekt je bez zbytečného prodlení informuje. Hlášení lze zajistit externě, odpovědnost za jeho splnění zůstává finančnímu subjektu. Orgán obdržené informace předává dál — evropským orgánům dohledu, ECB, orgánům podle NIS2 i orgánům pro řešení krize. Úřední znění čl. 19
Vysvětlivka CypherOn
V Česku se hlásí České národní bance výkazem v systému SDAT; bez registrace do SDAT a bez kódu LEI hlášení neodešlete, což je věc, kterou je třeba vyřídit dopředu, ne během incidentu. Lhůty jsou v nařízení 2025/301: prvotní oznámení do 4 hodin od klasifikace incidentu jako závažného, nejpozději do 24 hodin od okamžiku, kdy jste se o něm dozvěděli; průběžná zpráva do 72 hodin od prvotního oznámení; závěrečná do jednoho měsíce. Odklad na následující pracovní den existuje, ale u prvotního oznámení a průběžné zprávy se nepoužije pro úvěrové instituce, ústřední protistrany, provozovatele obchodních systémů a další subjekty určené podle NIS2 jako základní nebo důležité — a příslušný orgán ho může vypnout i dalším. Spočítat konkrétní termíny umí naše kalkulačka lhůt.
Zmocňuje evropské orgány dohledu k vypracování technických norem, které stanoví obsah hlášení závažného incidentu, obsah oznámení významné kybernetické hrozby a — což je pro praxi nejdůležitější — lhůty pro prvotní oznámení a pro každou z navazujících zpráv. Druhá norma vytváří standardní formuláře, vzory a postupy pro podání. Úřední znění čl. 20
Vysvětlivka CypherOn
Kdo hledá lhůty v samotné DORA, nenajde je — jsou právě zde delegované. Výsledkem jsou dvě normy: nařízení v přenesené pravomoci (EU) 2025/301 pro obsah a lhůty a prováděcí nařízení (EU) 2025/302 pro formuláře a postupy. Praktický důsledek: interní směrnice o hlášení incidentů má odkazovat na tyto dvě normy, ne na čl. 19 DORA, protože veškeré termíny a pole výkazu žijí tam.
Příslušný orgán potvrdí přijetí prvotního oznámení i každé zprávy a může subjektu poskytnout přiměřenou zpětnou vazbu nebo obecné pokyny, včetně anonymizovaných informací o podobných hrozbách, a projednat přijatá nápravná opatření. Odpovědnost za řešení incidentu a jeho důsledky tím nepřechází na orgán. Evropské orgány dohledu každoročně souhrnně a anonymizovaně informují o závažných incidentech a vydávají varování a statistiky. Úřední znění čl. 22
Vysvětlivka CypherOn
Věta o tom, že odpovědnost zůstává subjektu, má praktický obsah: potvrzení přijetí hlášení není souhlas s vaším postupem a mlčení orgánu není schválení. Když od dohledu dostanete pokyn nebo doporučení, založte si ho k incidentu a doložte, jak jste s ním naložili — při dalším kontaktu se k němu vrací jako první.
Rozšiřuje požadavky celé kapitoly III u úvěrových institucí, platebních institucí, poskytovatelů služeb informování o účtu a institucí elektronických peněz i na provozní a bezpečnostní incidenty související s platbami, včetně těch závažných. Úřední znění čl. 23
Vysvětlivka CypherOn
Pro platební sektor to znamená, že režim hlášení nezávisí na tom, jestli byla příčina „kybernetická“ — pod stejná pravidla spadne i provozní výpadek platební služby bez útočníka. V praxi to ruší dřívější zvyk posílat kybernetické a provozní události dvěma různými cestami a dvěma různým lidem; sjednocení procesu je tady nejlevnější opatření.
Kapitola IV
Testování digitální provozní odolnosti (čl. 24 až 27)
Kapitola má dvě patra. Obecné testování podle čl. 24 a 25 se týká všech finančních subjektů kromě mikropodniků, tedy i těch ve zjednodušeném režimu. Pokročilé penetrační testování na základě hrozeb podle čl. 26 a 27 se týká jen subjektů, které k tomu určí příslušný orgán, a subjekty ze zjednodušeného režimu i mikropodniky jsou z něj vyňaty. Zařadili jsme všechny čtyři články; vynechány jsou jen odstavce se zmocněním k technickým normám, jejichž výsledek uvádíme u čl. 26.
Ukládá subjektům jiným než mikropodniky vytvořit a udržovat program testování jako součást rámce řízení rizika ICT, postavený na posouzení rizik. Testy provádějí nezávislé interní nebo externí subjekty a při interním provedení je nutné vyloučit střet zájmů. Zjištěné problémy se prioritizují, klasifikují a odstraňují, přičemž existuje interní metodika ověřující, že náprava byla úplná. Systémy a aplikace podporující zásadní nebo důležité funkce se testují alespoň jednou ročně. Úřední znění čl. 24
Vysvětlivka CypherOn
Roční test podle odstavce 6 je nejčastěji přehlížená povinnost u menších subjektů, protože se plete s pokročilým testováním podle čl. 26, které se jich netýká. Netýká se jich čl. 26, ale čl. 24 ano. Druhá věc je nezávislost: nechat vlastní vývojáře testovat vlastní aplikaci nestačí, i kdyby test byl technicky dobrý. A pozor na uzavření smyčky — bez doloženého ověření nápravy je test jen seznam nálezů, což je z pohledu dohledu horší než žádný test, protože jste o problému věděli.
Vyjmenovává typy testů, které program obsahuje: hodnocení a skenování zranitelností, analýzy otevřených zdrojů, posouzení bezpečnosti sítě, analýzy nedostatků, přezkumy fyzické bezpečnosti, dotazníky, ověření antivirových řešení, kde je to proveditelné přezkumy zdrojového kódu, scénářové testy, testování kompatibility, výkonu, mezi koncovými body a penetrační testování. Centrální depozitáře a ústřední protistrany provádějí hodnocení zranitelnosti před každým nasazením nových i stávajících komponent podporujících zásadní nebo důležité funkce. Mikropodniky testují podle rizik a strategického plánu s ohledem na své zdroje. Úřední znění čl. 25
Vysvětlivka CypherOn
Výčet není nákupní seznam — je to nabídka, ze které se vybírá podle rizika, a rozhodnutí je třeba umět zdůvodnit. Přezkum zdrojového kódu má výhradu „kde je to proveditelné“, takže u nakupovaného softwaru se nahrazuje jinými zárukami (výsledky testů dodavatele, certifikace, smluvní záruky). Praktické vodítko, které v textu nenajdete: plánujte testy tak, aby jejich výstupy padly do ročního přezkumu rámce podle čl. 6 odst. 5 — jinak vám revize rámce nemá o co se opřít.
Subjekty určené příslušným orgánem provádějí alespoň jednou za tři roky penetrační testování na základě hrozeb; četnost lze podle rizikového profilu upravit. Test běží na produkčních systémech zajišťujících vybrané zásadní nebo důležité funkce a jeho rozsah potvrzuje orgán. Jsou-li do rozsahu zahrnuti dodavatelé ICT, subjekt zajistí jejich účast; při riziku dopadu na ostatní zákazníky dodavatele lze uspořádat společné testování více finančních subjektů. Po skončení se orgánu předkládá souhrn zjištění a plán nápravy a orgán vydá osvědčení, které umožňuje vzájemné uznávání testů. Používá-li subjekt interní testery, musí každý třetí test zadat externě; významné úvěrové instituce používají výhradně externí testery. Úřední znění čl. 26
Vysvětlivka CypherOn
Tohle není běžný penetrační test — je to řízené cvičení červeného týmu podle scénářů z operativních informací o hrozbách, s účastí dohledu a s délkou v měsících. V Česku je rámcem TIBER-EU, ke kterému ČNB přistoupila v září 2024 a ke kterému v březnu 2025 vydala implementačního průvodce TIBER-CZ. Podrobnosti k testerům a fázím testu rozvádí nařízení v přenesené pravomoci (EU) 2025/1190. Pro subjekty, které do určení nespadají, z toho plyne užitečné vodítko: roční test podle čl. 24 odst. 6 má být test schopnosti detekovat a reagovat, ne jen výstup ze skeneru zranitelností.
Testery lze najmout jen tehdy, mají-li nejlepší pověst, prokazatelné schopnosti v oblasti operativních informací o hrozbách, penetračního testování a testování metodou červeného týmu, certifikaci akreditačního orgánu nebo dodržování formálních etických rámců, nezávislé potvrzení řádného řízení rizik testování a pojištění odpovědnosti za škodu. Při použití interních testerů musí navíc souhlasit příslušný orgán, orgán ověří dostatečné zdroje a vyloučení střetu zájmů a poskytovatel operativních informací o hrozbách musí být externí. Smlouva s testerem musí ošetřit nakládání s výsledky. Úřední znění čl. 27
Vysvětlivka CypherOn
Požadavky na testera se vyplatí znát i subjektům mimo TLPT — jsou to rozumná kritéria pro výběr dodavatele jakéhokoli ofenzivního testu a dají se převzít do poptávky beze změny. Nejčastěji chybí dvě položky: pojištění odpovědnosti za škodu při výkonu povolání a smluvní ošetření osudu výsledků testu (kde se uloží, kdo k nim má přístup, kdy se zničí). Zpráva z červeného týmu je návod, jak vás kompromitovat; nakládat s ní jako s běžnou přílohou e-mailu je vlastní bezpečnostní incident.
Kapitola V · oddíl I
Řízení rizika ICT spojeného s třetími stranami (čl. 28 až 30)
Tři články, které mají největší dopad mimo finanční sektor — přes smlouvy dopadají na každého dodavatele ICT. Pro finanční subjekt platí celý oddíl včetně těch ve zjednodušeném režimu, s jedinou výjimkou: strategii pro riziko třetích stran podle čl. 28 odst. 2 nemusí přijímat subjekty podle čl. 16 odst. 1 ani mikropodniky. Zařadili jsme všechny tři články. Vynechány jsou odstavce se zmocněním k technickým normám — jejich výsledky (vzory registru informací a pravidla pro subdodávky) uvádíme přímo u dotčených ustanovení.
Stanoví, že za plnění povinností odpovídá vždy finanční subjekt, i když službu zajišťuje dodavatel. Subjekty jiné než mikropodniky a než subjekty ve zjednodušeném režimu přijímají strategii pro riziko třetích stran. Všechny finanční subjekty vedou registr informací o smluvních ujednáních na služby ICT, odlišují v něm ujednání podporující zásadní nebo důležité funkce, alespoň jednou ročně hlásí orgánu počet nových ujednání a kategorie dodavatelů a předem informují orgán o plánovaném ujednání na zásadní nebo důležitou funkci. Před uzavřením smlouvy je nutné posoudit rizika včetně koncentrace, prověřit dodavatele a jeho bezpečnostní standardy a ošetřit střety zájmů. Článek dále vyjmenovává důvody, pro které musí jít smlouvu ukončit, a u zásadních nebo důležitých funkcí vyžaduje otestované strategie ukončení vztahu. Úřední znění čl. 28
Vysvětlivka CypherOn
Registr informací se předkládá České národní bance přes systém SDAT a jeho strukturu určuje prováděcí nařízení (EU) 2024/2956 patnácti vzory. Dvě věci, které registr nejčastěji zabijí: chybějící kód LEI (bez něj výkaz neprojde) a nevyjasněné pořadí v dodavatelském řetězci — přímý dodavatel má vždy pořadí 1, subdodavatel vyšší, a žádný pevný počet vrstev norma nestanoví. Exit strategie je druhá nedoceněná položka: nařízení chce, aby byla otestovaná, ne jen napsaná, a zkusit obnovu dat od dodavatele nanečisto je jediný způsob, jak zjistit, že vám je vydá v použitelném formátu. Podrobný návod máme v průvodci.
Před uzavřením smlouvy na službu podporující zásadní nebo důležitou funkci je nutné zvážit, zda nejde o obtížně nahraditelného dodavatele nebo o hromadění více takových smluv u jednoho či úzce propojených dodavatelů, a porovnat přínosy a náklady alternativ. Připouští-li smlouva subdodávky, posuzují se jejich výhody a rizika, zejména u subdodavatele ze třetí země. U dodavatelů ze třetích zemí se navíc zvažuje insolvenční právo, dodržování unijních pravidel ochrany údajů a vymahatelnost práva, a u dlouhých subdodavatelských řetězců schopnost subjektu i orgánu službu vůbec ukontrolovat. Úřední znění čl. 29
Vysvětlivka CypherOn
Riziko koncentrace se v praxi neposuzuje na úrovni dodavatele, ale na úrovni závislosti: tři různé SaaS aplikace běžící u téhož hyperscalera jsou jedna koncentrace, i když máte tři různé smlouvy. Doporučujeme si v evidenci vést i nepřímé závislosti (kde služba fyzicky běží), protože jinak posouzení vyjde vždy příznivě. Prvky, které je třeba určit a posoudit u subdodávek zásadních funkcí, rozvádí nařízení v přenesené pravomoci (EU) 2025/532.
Práva a povinnosti stran musí být písemné, v jednom dokumentu včetně dohod o úrovni služeb. Odstavec 2 vyjmenovává devět náležitostí pro každou smlouvu na služby ICT: popis funkcí a podmínky subdodávek, místa poskytování a zpracování dat s povinností oznámit jejich změnu, ustanovení o dostupnosti a ochraně údajů, právo na přístup a vrácení dat při insolvenci nebo ukončení, popis úrovně služeb, pomoc při incidentu za předem známých nákladů, spolupráci s orgány, práva na ukončení s výpovědními lhůtami a účast na školeních. Odstavec 3 přidává u služeb podporujících zásadní nebo důležité funkce dalších šest: přesné kvantitativní cíle úrovně služeb, oznamovací povinnosti dodavatele, jeho vlastní plány zachování provozu a bezpečnostní opatření, účast na penetračním testování na základě hrozeb, neomezená práva na přístup, kontrolu a audit včetně kontrol na místě, a exit strategii s přechodným obdobím. Strany mají zvážit standardní smluvní doložky vypracované veřejnými orgány. Úřední znění čl. 30
Vysvětlivka CypherOn
Tohle je článek, kvůli kterému chodí softwarovým domům dodatky od bank — a je užitečné vědět, co se v nich nedá škrtnout a co ano. Nedají se škrtnout auditní práva a kontroly na místě u zásadních funkcí (odst. 3 písm. e)) ani exit s přechodným obdobím. Vyjednat se naopak dá četnost a rozsah auditů předem podle rizika (čl. 28 odst. 6), použití standardních doložek místo individuálních výmyslů (odst. 4) a u finančního subjektu, který je mikropodnikem, i to, že auditní práva vykonává nezávislá třetí strana určená dodavatelem (poslední pododstavec odst. 3). Rozbor jednotlivých bodů z pohledu dodavatele je v průvodci.
Kapitola V · oddíl II
Dohled nad kritickými poskytovateli ICT (čl. 31 až 44)
Oddíl zavádí přímý evropský dohled nad dodavateli, kteří nejsou finančními subjekty — historicky novou věc. Týká se úzkého okruhu: kritickými se stávají jen poskytovatelé určení evropskými orgány dohledu. Zařadili jsme čl. 31, 33, 35, 42 a 43, tedy určení, úkoly a pravomoci hlavního orgánu dohledu, dopad na finanční subjekty a poplatky. Vynechali jsme čl. 32, 34 a 36 až 41 a čl. 44 — upravují vnitřní uspořádání dohledu (fórum dohledu, koordinace, žádosti o informace, šetření, kontroly, společné kontrolní týmy, mezinárodní spolupráce). Pro rozhodování finančního subjektu ani dodavatele z nich neplyne samostatná povinnost.
Evropské orgány dohledu určují kritické poskytovatele podle čtyř kritérií: systémový dopad výpadku, systémový význam obsluhovaných finančních subjektů, míra spoléhání na dodavatele u zásadních nebo důležitých funkcí a jeho nahraditelnost. Určenému poskytovateli se jmenuje hlavní orgán dohledu a poskytovatel má šest týdnů na odůvodněné vyjádření. Určení se nevztahuje mimo jiné na poskytovatele uvnitř skupiny ani na ty, kteří působí jen v jednom členském státě. Seznam kritických poskytovatelů se zveřejňuje a ročně aktualizuje a poskytovatel se může o určení sám přihlásit. Kritický poskytovatel ze třetí země musí do 12 měsíců od určení založit v Unii dceřiný podnik, jinak jeho služby nelze využívat. Úřední znění čl. 31
Vysvětlivka CypherOn
Pro drtivou většinu dodavatelů platí, že kritickými nebudou — kritéria míří na hyperscalery a velké poskytovatele infrastruktury pro celý sektor. Praktický význam článku je proto jinde: vaše smlouva s kritickým poskytovatelem se může měnit kvůli rozhodnutí, na které nemáte vliv, včetně krajního opatření podle čl. 42 odst. 6. Proto má smysl mít exit plán i tam, kde je dodavatel zdánlivě neotřesitelný. Kritéria pro určení upřesňuje nařízení v přenesené pravomoci (EU) 2024/1502.
Hlavní orgán dohledu je pro kritického poskytovatele hlavním kontaktním místem a posuzuje, zda má zavedená ucelená pravidla a mechanismy pro řízení rizika ICT, které může finančním subjektům způsobit. Posouzení se soustředí na služby podporující zásadní nebo důležité funkce a v případě potřeby se rozšíří i na ostatní. Zahrnuje požadavky na bezpečnost, dostupnost, kontinuitu, škálovatelnost a kvalitu služeb, fyzické zabezpečení včetně datových center, procesy řízení rizik, plány zachování provozu a testování. Úřední znění čl. 33
Vysvětlivka CypherOn
Pro finanční subjekt je tu nepřímý, ale užitečný důsledek: hodnoticí okruhy hlavního orgánu dohledu jsou dobrým kontrolním seznamem pro vlastní posuzování dodavatelů. Ptáte-li se dodavatele na totéž, na co se ptá dohled (kontinuita, testování, fyzické zabezpečení, subdodávky), máte jednak srovnatelné odpovědi napříč dodavateli, jednak argument, proč ptát se musíte.
Hlavní orgán dohledu si může vyžádat informace a dokumentaci, vést obecná šetření a kontroly, požadovat zprávy o nápravě a vydávat doporučení — mimo jiné k bezpečnostním požadavkům, ke smluvním podmínkám vůči finančním subjektům a k plánovaným subdodávkám. Neplní-li poskytovatel uložená opatření, orgán po lhůtě nejméně 30 kalendářních dnů rozhodne o penále. Penále se ukládá na denním základě až do dosažení souladu, nejdéle šest měsíců, a činí až 1 % průměrného denního celosvětového obratu poskytovatele za předchozí účetní období. Uložené penále se zveřejňuje. Úřední znění čl. 35
Vysvětlivka CypherOn
Penále je konstruované jako donucení, ne jako trest za minulost — počítá se denně, dokud trvá nesoulad. To je pro poskytovatele podstatný rozdíl oproti jednorázové pokutě a v praxi to znamená, že spor s dohledem má cenu vyřešit rychle, ne dobře. Doporučení podle písm. d) přitom nejsou závazná; teprve jejich neuznání spouští následná opatření podle čl. 42, která dopadají na klienty poskytovatele.
Kritický poskytovatel má 60 kalendářních dnů na to, aby oznámil, že se doporučeními bude řídit, nebo vysvětlil proč ne; nedostatečné vysvětlení nebo mlčení hlavní orgán dohledu zveřejní včetně totožnosti poskytovatele. Národní orgány informují dotčené finanční subjekty o rizicích z doporučení a subjekty je musí zohlednit ve svém řízení rizika třetích stran. Neděje-li se tak, orgán subjekt upozorní a jako krajní opatření může rozhodnout, že finanční subjekty musí dočasně zcela nebo zčásti přestat služby kritického poskytovatele využívat, případně smlouvy ukončit. Před rozhodnutím orgán zvažuje závažnost porušení i riziko pro kontinuitu činnosti subjektu a poskytne mu lhůtu na úpravu smluv a spuštění exit plánů. Úřední znění čl. 42
Vysvětlivka CypherOn
Tohle je nejtvrdší nástroj v celém nařízení a dopadá na klienta, ne na dodavatele: povinnost přestat službu využívat dostane finanční subjekt. Je to zároveň nejlepší argument pro to, aby exit strategie podle čl. 28 odst. 8 nebyla formalita — scénář „regulátor nám zakázal používat současné řešení“ je jediný, kdy se plán přechodu spouští bez vaší chyby a bez času na přípravu. Doporučujeme mít u zásadních funkcí odhad doby a nákladů přechodu, i kdyby jen hrubý; bez něj se o krajním opatření nedá rozhodovat.
Kritickým poskytovatelům se účtují poplatky, které plně pokrývají náklady hlavního orgánu dohledu na výkon dohledu, včetně práce společných kontrolních týmů a nákladů na nezávislé odborníky. Výše poplatku je úměrná obratu poskytovatele a podrobnosti stanoví akt v přenesené pravomoci. Úřední znění čl. 43
Vysvětlivka CypherOn
Praktický dopad je nepřímý, ale reálný: dohledové poplatky a náklady na jeho obsluhu se u kritických poskytovatelů promítají do ceny služeb pro finanční sektor. Při plánování rozpočtu na víceleté smlouvy s velkými poskytovateli s tím počítejte jako s faktorem, který tlačí ceny nahoru. Způsob výpočtu poplatků upravuje nařízení v přenesené pravomoci (EU) 2024/1505.
Kapitoly VI až IX
Sdílení informací, dozor, sankce a použitelnost (čl. 45 až 64)
Závěr nařízení upravuje sdílení informací o hrozbách, určení příslušných orgánů, jejich pravomoci a sankce a nakonec použitelnost. Zařadili jsme čl. 45, 46, 50 a 64. Vynechali jsme čl. 47 až 49 a 51 až 57 (spolupráce orgánů, meziodvětvová cvičení, výkon sankční pravomoci, trestní sankce, uveřejňování sankcí, profesní tajemství, ochrana údajů, přenesená pravomoc) a čl. 58 až 63, což jsou přezkumné klauzule a novely jiných nařízení. Pro každodenní rozhodování finančního subjektu z nich neplyne samostatná povinnost; kdo řeší sankční řízení, potřebuje stejně český zákon č. 31/2025 Sb.
Umožňuje finančním subjektům vyměňovat si informace o hrozbách — indikátory kompromitace, taktiky, techniky a postupy, výstrahy i konfigurace — pokud to zlepšuje jejich odolnost, probíhá to v důvěryhodných komunitách a v rámci ujednání, které chrání citlivost sdílených informací, obchodní tajemství, osobní údaje a soutěžní pravidla. Ujednání stanoví podmínky účasti, případné zapojení veřejných orgánů a dodavatelů ICT a provozní podrobnosti včetně použitých platforem. Účast a její ukončení subjekt oznamuje příslušnému orgánu. Úřední znění čl. 45
Vysvětlivka CypherOn
Sdílení je dobrovolné, ale oznámení účasti dobrovolné není — a právě to se zapomíná. Než se přidáte do sektorové komunity, ověřte tři věci: jak je ošetřené nakládání s osobními údaji v indikátorech, jestli pravidla komunity (typicky protokol TLP) sedí na vaše interní klasifikační schéma a kdo za vás smí informace odesílat. Bez třetího bodu se dřív nebo později stane, že komunitě pošlete víc, než jste chtěli.
Určuje, který orgán dohlíží na dodržování nařízení, a to podle typu subjektu — u úvěrových institucí orgán podle směrnice 2013/36/EU a u významných bank ECB, u platebních institucí a institucí elektronických peněz orgán podle směrnice 2015/2366, u investičních podniků orgán podle směrnice 2019/2034 a obdobně pro další sektory. Dohled nad kritickými poskytovateli ICT tím není dotčen, ten patří do rámce podle kapitoly V oddílu II. Úřední znění čl. 46
Vysvětlivka CypherOn
V Česku je příslušným orgánem Česká národní banka; plyne to ze zákona č. 31/2025 Sb. o digitalizaci finančního trhu, který zároveň upravuje její pravomoci a přestupky. Prakticky to znamená jednu adresu pro registr informací, hlášení incidentů i dotazy — a systém SDAT jako kanál. Rozdělení rolí mezi ČNB a NÚKIB u subjektů, které se potkávají s oběma předpisy, popisuje jejich společné prohlášení, které shrnujeme v průvodci.
Příslušné orgány mají mít kontrolní, vyšetřovací a sankční pravomoci — přístup k dokumentům a datům, kontroly na místě, předvolání zástupců subjektu a možnost požadovat nápravná opatření. Členské státy stanoví účinné, přiměřené a odrazující správní sankce a nápravná opatření, včetně příkazu k ukončení protiprávního jednání a dočasného nebo trvalého ukončení určité praxe. Odstavec 5 předpokládá, že sankce a nápravná opatření lze uplatnit i vůči členům vedoucího orgánu a dalším odpovědným osobám. Úřední znění čl. 50
Vysvětlivka CypherOn
Konkrétní výše pokut v DORA nejsou — nastavuje je členský stát. V Česku to dělá zákon č. 31/2025 Sb., který obsahuje skutkové podstaty zvlášť pro finanční subjekty a zvlášť pro dodavatele; sazby a jejich navázání na jednotlivé povinnosti rozebíráme ve FAQ. Pro vedení je podstatnější odstavec 5: odpovědnost může dopadnout osobně, což je při schvalování rámce a rozpočtu podle čl. 5 dobré vědět předem.
Nařízení vstoupilo v platnost dvacátým dnem po vyhlášení v Úředním věstníku, tedy 16. ledna 2023, a použije se ode dne 17. ledna 2025. Je závazné v celém rozsahu a přímo použitelné ve všech členských státech. Úřední znění čl. 64
Vysvětlivka CypherOn
Dvě data se pletou dodnes, a to i ve zdrojích, které jinak stojí za citaci: Česká národní banka o datu 17. 1. 2025 psala jako o „nabytí účinnosti“, ačkoli jde o použitelnost podle čl. 64. Věcně to nic nemění — od 17. 1. 2025 jsou povinnosti vymahatelné a dvouleté přechodné období skončilo. Kdo dnes teprve začíná, nemá odklad: nezpracovaný registr informací nebo chybějící proces hlášení jsou zjistitelné okamžitě a bez kontroly na místě.