DORA 2026: co musí české finance mít hotové do ledna

Nařízení o digitální provozní odolnosti finančního sektoru (DORA, Digital Operational Resilience Act) platí v EU přímo od 17. ledna 2025. V Česku ho vykonává ČNB a v 2026 už není „nová věc, co se chystá", je to věc, na kterou regulátor začíná chodit s prvními kontrolami. Tenhle článek je praktický soupis toho, co musí mít banka, pojišťovna, platební instituce, fintech nebo investiční firma reálně v šuplíku, když vám zazvoní revizor.

Koho se DORA týká

DORA dopadá na prakticky všechny licencované finanční subjekty pod dohledem ČNB: banky, družstevní záložny, pojišťovny a zajišťovny, platební instituce a instituce elektronických peněz, investiční podniky, správce alternativních fondů (AIFMD), penzijní fondy, ratingové agentury, crypto-asset service providery podle MiCA, crowdfundingové platformy, a, důležitý detail, i ICT dodavatele finančních institucí, pokud jsou označeni jako kritičtí.

Pro malé subjekty (typicky pod 10 zaměstnanců a 2 mil. EUR bilance) platí zjednodušený režim, ale není to výjimka, pořád musí mít risk management framework a hlásit incidenty. Pravidlo de minimis tu prakticky neexistuje.

Pět pilířů DORA, na které vás budou ptát

• ICT risk management framework. Schválený statutárním orgánem, aktualizovaný minimálně ročně, s konkrétními postupy pro identifikaci, ochranu, detekci, reakci a obnovu. Ne dokument do šuplíku, ale živý proces s odpovědnými lidmi.
• Hlášení významných ICT incidentů. Iniciální notifikace ČNB do 4 hodin od klasifikace incidentu jako významný, interim report do 72 hodin, final report do 1 měsíce. Klasifikační kritéria jsou v RTS, počet dotčených klientů, geografický rozsah, doba trvání, finanční dopad, reputační dopad.
• Testing digitální provozní odolnosti. Základní testing každoročně (vulnerability scanning, penetration testing, scenario-based testing). Threat-Led Penetration Testing (TLPT) podle TIBER-EU framework každé 3 roky pro významné subjekty.
• Management ICT třetích stran. Register ICT smluv (jeden centrální, ne 12 excelů po útvarech), kontraktuální požadavky podle čl. 30 DORA, exit strategie pro kritické dodavatele, monitoring koncentračního rizika.
• Sdílení informací o kybernetických hrozbách. Účast v information-sharing arrangements je dobrovolná, ale ČNB to očekává od subjektů určité velikosti. Threat-intel feed napojený na váš SIEM, ne PDF e-mailem od kolegy.

DORA vs. NIS2: kde se to kříží

Pokud jste současně pod NIS2 (např. banka, která je „essential entity") i pod DORA, platí pravidlo lex specialis: DORA má přednost v oblasti ICT risk managementu a incident reportingu. Neznamená to ale, že NIS2 ignorujete, povinnosti mimo ICT (krizový management, governance, supply chain mimo ICT) zůstávají z NIS2. V praxi to znamená jeden risk management framework, který pokrývá oba předpisy, a dva reporting kanály: NÚKIB pro NIS2, ČNB pro DORA.

Praktický rozdíl: NIS2 dává „incident" víc volnou definici, DORA má v RTS přesné prahy, kolik klientů, jak dlouho, kolik peněz. Pro vaši incident response je tedy DORA přesnější vodítko: pokud splňuje DORA threshold, hlaste; pokud ne, do NIS2 reportingu může jít stejně podle vašich interních kritérií.

Co reálně dělat teď, pokud DORA-ready ještě nejste

• Gap analýza proti DORA + NIS2 (max 2 týdny). Mapování stávajících controls na konkrétní články DORA. Výstupem je list otevřených bodů, ne 200stránková zpráva.
• ICT third-party register. Jeden zdroj pravdy, kde je každý ICT dodavatel s rolí, kritičností, daty, exit plánem. Ne projekt na rok, dá se rozjet za měsíc.
• Incident classification matrix. Konkrétní prahy „kdy je to významný incident podle DORA". Bez toho budete buď přehlašovat (a otravovat ČNB), nebo podhlašovat (a porušovat nařízení).
• Continuous monitoring. SIEM (Microsoft Sentinel, Splunk, Wazuh) napojený na klíčové ICT systémy. Bez monitoring vrstvy nezajistíte detection time, který DORA očekává.
• TLPT plán. I když ho fyzicky pustíte za rok nebo dva, plán + rozpočet by měl být na stole už teď. ČNB se na to ptá.

Jak se vyhnout typickým past

Klasická chyba je dělat DORA jako jednorázový projekt s deadline „leden 2025". To už je za námi. Regulátor teď chce vidět provozní rytmus: tabletop cvičení dvakrát ročně, kvartální review ICT registru, měsíční incident review. Druhá past: pokrývat jen vlastní systémy a zapomenout na cloudové dodavatele. AWS, Azure, GCP, Stripe, kdokoliv kritický musí být ve vašem registru a smluvně pokrytý podle čl. 30.

Třetí past: incident report napsaný 5 hodin po incidentu, kdy už neznáte timeline minutu po minutě. DORA chce přesnou rekonstrukci (kdy detected, kdy contained, kdy resolved, jaká byla rozhodnutí). Bez automatizovaného audit trailu se to dělá hodně bolavě.

Jak vám můžeme pomoct

Náš produkt AI NIS2 Watch je postavený přesně na tenhle průnik DORA + NIS2 pro české finance. Kontinuálně mapuje vaše ICT systémy na konkrétní články DORA, automaticky klasifikuje incidenty podle prahů a draftuje notifikační text pro ČNB do 4hodinového okna. Plus drží regulator-ready evidence vault, každý alert, change a akce má timestamped audit trail, ready na inspekci.

Sedí nad vaším stávajícím SIEM (Sentinel, Splunk, Wazuh) přes API. Nenahrazujeme váš security stack, doplňujeme tu vrstvu, která mapuje technickou realitu na regulatorní jazyk, což je práce, ve které se interní týmy obvykle utopí.