DORA v roce 2026: co musí mít české finanční instituce připravené

Nařízení o digitální provozní odolnosti finančního sektoru (DORA, nařízení (EU) 2022/2554 (otevře se v novém okně)) platí v celé EU přímo od 17. ledna 2025. V Česku na jeho dodržování dohlíží ČNB. V roce 2026 už nejde o přípravu, ale o běžný provoz: povinnosti musíte plnit průběžně a umět to doložit. Tento článek shrnuje, co má mít finanční instituce připravené.

DORA dopadá na většinu regulovaných finančních subjektů: banky a družstevní záložny, pojišťovny a zajišťovny, platební instituce a instituce elektronických peněz, obchodníky s cennými papíry, správce investičních fondů, poskytovatele služeb kryptoaktiv podle MiCA, poskytovatele služeb skupinového financování a další.

Nepřímo se týká i dodavatelů ICT služeb. Finanční instituce jim musí promítnout požadavky DORA do smluv. Nejvýznamnější (kritické) dodavatele určují a dozorují evropské orgány dohledu.

Mikropodniky (méně než 10 zaměstnanců a roční obrat nebo bilanční suma do 2 mil. EUR) mají v některých bodech mírnější požadavky a vybrané typy menších institucí mohou použít zjednodušený rámec řízení ICT rizik (čl. 16). Povinnost hlásit závažné incidenty ale platí pro všechny.

• Řízení ICT rizik: rámec schválený vedením a pravidelně přezkoumávaný, s postupy pro identifikaci, ochranu, detekci, reakci a obnovu. Ne dokument do šuplíku, ale proces s odpovědnými lidmi.
• Hlášení závažných incidentů: počáteční oznámení ČNB do 4 hodin od klasifikace incidentu jako závažného a nejpozději do 24 hodin od jeho zjištění, průběžná zpráva do 72 hodin od počátečního oznámení a závěrečná zpráva do jednoho měsíce od poslední průběžné zprávy. Kritéria klasifikace (například počet dotčených klientů, doba trvání, geografický rozsah, ztráta dat, kritičnost služeb a hospodářský dopad) stanoví prováděcí předpisy.
• Testování odolnosti: systémy podporující kritické nebo důležité funkce testujete alespoň jednou ročně (skenování zranitelností, penetrační testy, scénáře). Instituce, které k tomu určí orgán dohledu, podstupují nejméně jednou za tři roky penetrační testy vedené hrozbami (TLPT), které vycházejí z rámce TIBER-EU.
• Rizika třetích stran: registr informací o všech smlouvách o ICT službách (jeden, ne dvanáct tabulek po útvarech), smluvní náležitosti podle čl. 30, strategie odchodu u kritických dodavatelů a sledování koncentračního rizika.
• Sdílení informací o hrozbách: účast ve výměně informací o kybernetických hrozbách je dobrovolná (čl. 45), ale pomáhá včas zachytit nové hrozby.

Pro finanční subjekty je DORA zvláštní úprava. V řízení ICT rizik a hlášení incidentů má přednost před směrnicí NIS2 i před českým zákonem č. 264/2025 Sb. Závažné incidenty související s ICT proto hlásíte ČNB podle DORA a ČNB je předává dalším dotčeným orgánům.

Zákon o kybernetické bezpečnosti se na vás uplatní jen tam, kde DORA danou oblast neupravuje rovnocenně, typicky u registrace u NÚKIB. Vztah obou předpisů vysvětluje společné prohlášení ČNB a NÚKIB z 24. června 2026 (otevře se v novém okně).

• Rozdílová analýza vůči DORA: namapujte stávající opatření na konkrétní články nařízení. Výstupem má být seznam otevřených bodů, ne dvousetstránková zpráva.
• Registr ICT smluv: jeden zdroj pravdy, kde má každý dodavatel roli, kritičnost, zpracovávaná data a plán odchodu.
• Klasifikace incidentů: jasná pravidla, kdy je incident podle DORA závažný. Bez nich budete buď hlásit zbytečně, nebo nehlásit, co máte.
• Průběžný dohled: SIEM (například Microsoft Sentinel, Splunk nebo Wazuh) napojený na klíčové ICT systémy, abyste incidenty zachytili včas a měli podklady pro hlášení.
• Plán testování: roční plán testů, a pokud vás ČNB určí pro TLPT, i plán a rozpočet na něj.

Klasická chyba je brát DORA jako jednorázový projekt s termínem v lednu 2025. Důležitý je provozní rytmus, například pravidelná cvičení, čtvrtletní revize registru ICT smluv a měsíční přehled incidentů. Druhá past: pokrýt jen vlastní systémy a zapomenout na cloudové a další kritické dodavatele. I ti musí být v registru a smluvně pokrytí podle čl. 30.

Třetí past: hlášení psané zpětně, kdy už neznáte přesnou časovou osu. Hlášení musí zachytit, kdy byl incident zjištěn, jak jste ho klasifikovali a jaká opatření jste přijali. Bez automatické auditní stopy se to skládá velmi těžko.

Náš produkt AI NIS2 Watch pomáhá právě s tímto průnikem DORA a zákona o kybernetické bezpečnosti. Mapuje ICT systémy na konkrétní požadavky, pomáhá klasifikovat incidenty podle prahů a připravuje podklady pro hlášení ČNB. Každý alert, změna a akce mají časovou stopu pro audit.

Běží nad stávajícím SIEM přes API. Nenahrazuje váš bezpečnostní stack, ale doplňuje vrstvu, která překládá technickou realitu do jazyka regulace.