← Zpět na všechny články

Soulad s DORA v roce 2026: Kompletní průvodce pro finanční subjekty EU

Lhůty hlášení podle článku 19, kritéria klasifikace závažných incidentů, riziko ICT třetích stran podle kapitoly V a požadavky na forenzní důkazy, které odlišují finanční subjekty připravené na DORA od těch, které regulaci stále považují za papírování. Aktualizováno pro květen 2026 — jeden rok aplikace, prvních 19 CTPPs určených a vymáhání v aktivní fázi.

Nařízení DORA Článek 19 Finanční sektor Hlášení ICT incidentů

DORA v roce 2026: jeden rok aplikace, co se změnilo

Před rokem, 17. ledna 2025, vstoupilo nařízení o digitální provozní odolnosti finančního sektoru (DORA) do aplikace. Jako nařízení, nikoli směrnice, se DORA od prvního dne přímo aplikovala ve všech 27 členských státech EU — bez nutnosti transpozice, bez národních variant na základních povinnostech. Do května 2026 se rámec posunul z fáze implementace do aktivní fáze vymáhání. Národní příslušné orgány — BaFin v Německu, ACPR ve Francii, CSSF v Lucembursku, MNB v Maďarsku, ČNB v Česku a jejich ekvivalenty napříč Unií — se přesunuly od vydávání pokynů k provádění inspekcí.

Přechod nebyl hladký. Cvičení Evropských orgánů dohledu (ESA) z roku 2024 v rámci dry-run testu registru informací zjistilo, že pouze 6,5 % z téměř 1 000 firem napříč EU úspěšně prošlo všemi 116 kontrolami kvality dat. Cyklus 2025 ukázal zlepšení, ale stále odhalil významné mezery v souladu v dokumentaci rizik třetích stran, postupech klasifikace incidentů a testování provozní odolnosti. Cyklus 2026 s referenčním datem 31. prosince 2025 je první, který bude plně hodnocen v rámci posturu vymáhání.

Dva vývoje na konci roku 2025 a začátku roku 2026 vykrystalizovaly regulační prostředí. Za prvé, 18. listopadu 2025 zveřejnily Evropské orgány dohledu první oficiální seznam 19 určených kritických ICT poskytovatelů třetích stran podle DORA — včetně AWS, Microsoft Azure, Google Cloud, IBM, Bloomberg, London Stock Exchange Group, Tata Consultancy Services a Orange. Tato určení přinášejí jmenovité globální poskytovatele pod přímý dohled EU, přičemž společné vyšetřovací týmy jsou nyní aktivní.

Za druhé, přezkum Komise podle článku 58, splatný do 17. ledna 2026, zkoumal, zda by požadavky DORA měly být zpřísněny pro statutární auditory a auditorské společnosti — v současnosti v působnosti, ale s omezenými povinnostmi. Přezkum otevírá dveře k postupným úpravám působnosti v pozdějších letech této dekády. Prozatím subjekty v působnosti fungují podle původního rámce a praktickým testem je, zda mohou produkovat obhájitelné důkazy v rámci čtyřhodinového hodinového limitu, když dojde k incidentu.

Pro organizace podléhající DORA se tento průvodce zaměřuje spíše na operační test než na text politiky. Třístupňová kaskáda hlášení podle článku 19 je nejvýznamnější jednotlivou povinností v nařízení a čtyřhodinové okno initial hlášení je výrazně přísnější než 24hodinové early warning podle NIS2. Zbytek nařízení — riziko třetích stran, provozní testování, sankce — krouží kolem tohoto centrálního bodu: když se něco pokazí, dokáže vaše organizace zdokumentovat, co se stalo, s rychlostí a integritou, kterou regulátor nyní očekává?

Působnost: kdo spadá pod DORA

Působnost DORA je definována pozitivně a široce. Na rozdíl od NIS2, která používá kritičnost sektoru plus pravidlo size-cap, se DORA aplikuje prakticky na každý regulovaný finanční subjekt v Evropské unii — bez minimální velikostní prahové hodnoty pro většinu kategorií. Evropský orgán pro bankovnictví odhaduje, že přibližně 22 000 finančních subjektů spadá do působnosti DORA napříč Unií.

Finanční subjekty v působnosti (neúplný seznam)

Kategorie zahrnují úvěrové instituce, platební instituce a instituce elektronických peněz, investiční podniky, poskytovatele služeb spojených s kryptoaktivy, centrální depozitáře cenných papírů, ústřední protistrany, obchodní systémy, registry obchodních údajů, správce alternativních investičních fondů, správcovské společnosti SKIPCP, poskytovatele datových služeb, pojišťovny a zajišťovny, pojišťovací zprostředkovatele, instituce zaměstnaneckého penzijního pojištění, ratingové agentury, statutární auditory a auditorské společnosti, správce kritických referenčních hodnot, poskytovatele služeb skupinového financování a registry sekuritizace. Téměř každá kategorie specificky definovaná v právu finančních služeb EU je zahrnuta.

Žádná obecná výjimka size-cap

Toto je zásadní rozdíl od NIS2. Kde NIS2 ve výchozím nastavení vyjímá subjekty pod 50 zaměstnanců a 10 milionů EUR obratu, DORA se obecně aplikuje bez ohledu na velikost. Menší finanční subjekty — malé platební instituce, menší investiční podniky, menší poskytovatelé služeb spojených s kryptoaktivy — spadají do působnosti vedle největších bank. DORA obsahuje princip přiměřenosti: nařízení výslovně vyžaduje, aby byly povinnosti aplikovány zjednodušeným způsobem na určité mikropodniky a menší instituce, ale podstatné povinnosti se aplikují.

Poskytovatelé ICT služeb třetích stran jako samostatná kategorie

Poskytovatelé ICT služeb třetích stran obsluhující finanční subjekty jsou řešeni odlišně. Nejsou přímými adresáty povinností DORA v oblasti řízení rizik nebo hlášení incidentů. Místo toho jsou dosaženi nepřímo prostřednictvím smluvních požadavků kapitoly V uložených finančním subjektům a přímo — pro největší poskytovatele — prostřednictvím rámce dohledu pro kritické ICT poskytovatele třetích stran (CTPPs). 19 CTPPs určených v listopadu 2025 nyní podléhá přímému dohledu EU prostřednictvím společných vyšetřovacích týmů a platí poplatek za dohled.

Geografický dosah a extrateritoriální účinek

DORA se aplikuje na finanční subjekty zřízené v Unii. Poskytovatelé ICT služeb třetích stran zřízení mimo Unii, ale obsluhující finanční subjekty EU v působnosti, jsou dosaženi smluvně prostřednictvím požadavků kapitoly V — finanční subjekt musí třetí straně uložit podmínky v souladu s DORA bez ohledu na to, kde je třetí strana zřízena. To efektivně tlačí povinnosti rovnocenné DORA do standardních smluvních podmínek velkých globálních cloudových poskytovatelů, softwarových dodavatelů a outsourcingových partnerů, a to i v případě, že tito poskytovatelé mají sídlo ve Spojených státech nebo jinde mimo EU.

Pět pilířů DORA v přehledu

DORA se obvykle popisuje jako spočívající na pěti pilířích, odpovídajících jejím hlavním podstatným kapitolám. Pochopení pěti pilířů a toho, jak se vzájemně proplétají, poskytuje rámec pro zbytek tohoto průvodce.

Pilíř 1: Řízení ICT rizik (články 5–16)

Finanční subjekty musí implementovat komplexní rámec řízení ICT rizik, přičemž odpovědnost spočívá na úrovni řídícího orgánu. Rámec musí pokrývat identifikaci, ochranu, detekci, reakci, obnovu a průběžné učení. Článek 6 uvádí komponenty: ujednání o správě, politiku ICT business continuity, postupy reakce a obnovy a mechanismy učení a vývoje. Rámec musí být přezkoumán alespoň jednou ročně a aktualizován po významných incidentech souvisejících s ICT.

Pilíř 2: Řízení, klasifikace a hlášení incidentů souvisejících s ICT (články 17–23)

Články 17 až 23 stanoví, jak musí finanční subjekty detekovat, klasifikovat, řídit a hlásit incidenty související s ICT. Povinnosti hlášení podle článku 19 — a přísný třístupňový časový harmonogram, který ukládají — jsou operačně nejnáročnější součástí DORA pro týmy reakce na incidenty. Tento pilíř je středem velké části tohoto průvodce.

Pilíř 3: Testování digitální provozní odolnosti (články 24–27)

Finanční subjekty musí pravidelně testovat svou digitální provozní odolnost s programem testování přiměřeným velikosti a riziku. Článek 25 specifikuje základní požadavky na testování aplikovatelné na všechny subjekty v působnosti; článek 26 zavádí threat-led penetrační testování pro významné finanční subjekty na základě rámce TIBER-EU, prováděné alespoň jednou za tři roky na produkčních systémech v živém provozu.

Pilíř 4: Řízení rizika ICT třetích stran (články 28–44)

Kapitola V se zabývá rizikem třetích stran, které regulátor považuje za hlavní vektor systémového narušení v moderních finančních službách. Kapitola zahrnuje povinnosti týkající se smluvních podmínek, due diligence dodavatelů, registru informací, kontrol subdodavatelů a — nejvýrazněji — rámce dohledu pro kritické ICT poskytovatele třetích stran. Zde sídlí nejnovější strukturální inovace nařízení.

Pilíř 5: Ujednání o sdílení informací (článek 45)

Článek 45 podporuje finanční subjekty k účasti na ujednáních o sdílení informací týkajících se informací a zpravodajských informací o kybernetických hrozbách. Účast je dobrovolná, ale nařízení zavádí povolující právní rámec — včetně, což je důležité, vyjasnění, že sdílení informací v rámci parametrů rámce nepředstavuje porušení důvěrnosti nebo povinností ochrany údajů. Pilíř je operačně lehčí než ostatní, ale právně umožňující.

Rámec řízení ICT rizik (články 5–16)

Kapitola II DORA, sestávající z článků 5 až 16, zavádí rámec řízení ICT rizik, který musí každý finanční subjekt v působnosti implementovat a udržovat. Rámec je základem, na němž spočívají pilíře reakce na incidenty, testování a rizika třetích stran. Kde je rámec slabý, závislé povinnosti nelze během inspekce věrohodně splnit.

Odpovědnost řídícího orgánu (článek 5)

Článek 5 svěřuje konečnou odpovědnost za rámec řízení ICT rizik řídícímu orgánu — představenstvu nebo ekvivalentu. Řídící orgán musí definovat a schválit rámec, dohlížet na jeho implementaci a zajistit přiměřený rozpočet a lidské zdroje. Členové řídícího orgánu musí udržovat dostatečné znalosti a dovednosti k pochopení a posouzení ICT rizika; toto je podstatná povinnost, nikoli formální, a regulátor může požadovat důkazy o školení na úrovni představenstva a aktivním zapojení.

Komplexní rámec řízení ICT rizik (článek 6)

Článek 6 specifikuje komponenty: zdokumentovaný rámec schválený řídícím orgánem, organizační ujednání s jasnými rolemi a odpovědnostmi, politiku business continuity, postupy reakce a obnovy, mechanismy učení a ochranu ICT aktiv napříč jejich životním cyklem. Rámec musí být přiměřený velikosti, povaze, složitosti a rizikovému profilu subjektu — ale podstatné prvky jsou povinné. Přiměřenost ovlivňuje intenzitu, nikoli pokrytí.

Identifikace, ochrana, detekce, reakce, obnova (články 7–13)

Články 7 až 13 rozpracovávají funkční schopnosti. Identifikace pokrývá ICT systémy, klasifikaci informačních aktiv a identifikaci ICT podporovaných obchodních funkcí. Ochrana pokrývá bezpečnostní politiky, správu identit a přístupu, šifrování a bezpečnost provozu. Detekce pokrývá monitorování, detekci anomálií a upozorňování. Reakce a obnova pokrývají business continuity, postupy reakce a krizovou komunikaci. Učení pokrývá post-incident reviews, analýzu kořenových příčin a průběžné zlepšování.

Plán krizové komunikace (článek 14)

Článek 14 vyžaduje, aby subjekty měly plán krizové komunikace pokrývající interní zaměstnance, klienty, finanční protistrany, veřejnost a orgány dohledu. Plán musí řešit, jak bude komunikace koordinována, když dojde k incidentu napříč více skupinami zúčastněných stran — pro což se forenzní důkazy stávají zásadními, jak jako vstup do komunikace, tak jako defenzivní záznam pro případ, že by komunikace byla později zpochybněna klienty, protistranami nebo regulátory.

Roční přezkum (článek 6 odst. 5)

Rámec musí být přezkoumán alespoň jednou ročně a aktualizován vždy, když dojde k významným incidentům souvisejícím s ICT, když vzniknou dohledové pokyny nebo když dojde k významným změnám ICT prostředí subjektu. Roční přezkum je sám zdokumentován a prokazatelný; tvoří součást audit trailu, který orgány dohledu zkoumají během inspekcí, a mezery v historii přezkumů se staly opakovaným bodem dohledové zpětné vazby v rané fázi vymáhání.

Článek 19: třístupňová lhůta hlášení

Článek 19 je operační srdce DORA pro reakci na incidenty. Zavádí třístupňovou kaskádu hlášení spouštěnou, když je incident související s ICT klasifikován jako závažný — a lhůty jsou znatelně přísnější než ekvivalentní povinnosti NIS2. Podrobné lhůty a obsahové požadavky jsou specifikovány v nařízení Komise v přenesené pravomoci (EU) 2025/301 ze dne 23. října 2024, přičemž šablony a postupy jsou specifikovány v prováděcím nařízení Komise (EU) 2025/302.

Stupeň 1 — initial hlášení: 4 hodiny od klasifikace, max 24 hodin od detekce

Initial hlášení musí dorazit příslušnému orgánu do 4 hodin od okamžiku, kdy finanční subjekt klasifikuje incident jako závažný. Klasifikace samotná musí nastat co nejdříve to bude rozumně proveditelné po detekci, a v každém případě do 24 hodin od detekce. Kombinovaný účinek: od detekce po initial hlášení je maximální přípustná uplynulá doba 28 hodin — ale v praxi regulátoři očekávají, že se řetězec zkomprimuje na otázku hodin, nikoli dnů. Zadržení hlášení proto, že vyšetřování není dokončeno, výslovně není v souladu; initial hlášení má poskytnout včasné povědomí, nikoli kompletní analýzu.

Stupeň 2 — intermediate zpráva: 72 hodin od initial hlášení

Do 72 hodin od initial hlášení musí finanční subjekt předložit intermediate zprávu poskytující podstatně bohatší popis incidentu, včetně aktuálního stavu, zpřesněné klasifikace, posouzení dopadu a jakýchkoli dalších informací požadovaných příslušným orgánem. Kde incident zůstává aktivní nebo kde je analýza kořenových příčin neúplná, intermediate zpráva to výslovně uznává a nastiňuje další kroky. 72 hodin běží od initial hlášení, nikoli od detekce — kritické rozlišení od GDPR.

Stupeň 3 — závěrečná zpráva: nejpozději jeden měsíc po intermediate zprávě

Nejpozději jeden měsíc po intermediate zprávě finanční subjekt předkládá závěrečnou zprávu. Obsahuje komplexní popis incidentu, jeho kořenové příčiny, technické a operační detaily, dopad (včetně finanční ztráty a počtu postižených klientů), nápravné akce přijaté, získané ponaučení a plánovaná zlepšení. Závěrečná zpráva je dokument, ke kterému se orgány dohledu vracejí během následných inspekcí a auditů — její kvalita určuje, jak je incident zapamatován v regulačním záznamu.

Dobrovolné oznámení významných kybernetických hrozeb (čl. 19 odst. 2)

Článek 19 odst. 2 umožňuje — ale nevyžaduje — aby finanční subjekty dobrovolně oznamovaly významné kybernetické hrozby. Režim dobrovolného oznamování umožňuje subjektům sdílet zpravodajské informace o hrozbách, i když se žádný incident nematerializoval, a pomáhá tak širšímu finančnímu sektoru se připravit. Členské státy mohou rozšířit směrování dobrovolného oznamování i na CSIRT podle NIS2. Ačkoli jsou dobrovolná, tato oznámení jsou součástí pohledu regulátora na zralost ICT rizika subjektu a posturu zapojení.

Povinnost oznámení klientům (čl. 19 odst. 3)

Pokud má závažný incident související s ICT dopad na finanční zájmy klientů, finanční subjekt musí — bez zbytečného odkladu, jakmile se o tom dozví — informovat klienty o incidentu a o opatřeních přijatých ke zmírnění nepříznivých účinků. Oznámení klientům jsou součástí veřejného důkazního záznamu; jakmile jsou zveřejněna, omezují, jak subjekt může později charakterizovat incident v regulačních podáních nebo v soudních sporech. Forenzní zachycení oznámení klientům samotných — včetně zveřejněné verze, časového razítka a všech následných aktualizací — se stává součástí defenzivního záznamu.

Klasifikace závažných incidentů: sedm kritérií

Pouze závažné incidenty související s ICT spouštějí povinnosti hlášení podle článku 19. Práh je definován v nařízení Komise v přenesené pravomoci (EU) 2024/1772, které specifikuje sedm klasifikačních kritérií a prahových hodnot významnosti pro každé. Pochopení kritérií přesně je zásadní — nesprávná klasifikace je sama o sobě selháním souladu a nadměrné hlášení není sankcionováno, zatímco podhlášení nese přímé administrativní důsledky.

Sedm klasifikačních kritérií

Sedm kritérií jsou: kritičnost postižených služeb; počet a relevance postižených klientů, finančních protistran a transakcí; reputační dopad; doba trvání a výpadek služby; geografické rozšíření; ztráty dat; a ekonomický dopad. Každé kritérium má vlastní práh významnosti a klasifikační logika je kombinuje prostřednictvím duální spouštěcí struktury, spíše než aby považovala jakékoli jednotlivé kritérium za rozhodující.

Dvojitý spouštěč: kritické služby + ztráta dat NEBO dva prahy

Incident související s ICT je klasifikován jako závažný, pokud byly poškozeny kritické nebo důležité služby a buď byla dosažena prahová hodnota významnosti pro ztráty dat — což znamená jakýkoli úspěšný, zákeřný a neoprávněný přístup k síti a informačním systémům vedoucí ke ztrátě dat — nebo byly překročeny alespoň dvě další prahové hodnoty významnosti. Duální spouštěcí logika zajišťuje, že vážné jedno-kriteriální incidenty (zejména ztráty dat) jsou zachyceny vedle vícestranných narušení, která nemusí jednotlivě prolomit žádný jednotlivý strop.

Kvantitativní prahové hodnoty významnosti

Několik prahových hodnot je kvantitativních. Počet postižených finančních protistran musí překročit 30 % všech finančních protistran využívajících postiženou službu. Počet postižených transakcí musí překročit 10 % denního průměrného počtu nebo 10 % denní průměrné hodnoty transakcí souvisejících se službou. Ostatní prahy jsou kvalitativní, včetně reputačního dopadu posuzovaného proti faktorům, jako je pokrytí mainstreamovými médii, eskalace regulačního dohledu a riziko podstatného odlivu zákazníků.

Úspěšný zákeřný neoprávněný přístup jako automatický spouštěč

Stejně jako v případě prováděcího nařízení Komise 2024/2690 podle NIS2, klasifikační pravidla DORA považují úspěšný zákeřný neoprávněný přístup za automatický ukazatel závažnosti. Pokud útočník získal přístup k síti a informačním systémům se zřejmým zákeřným úmyslem a přístup vedl nebo může vést ke ztrátě dat, je incident závažný bez ohledu na ostatní prahy. To odstraňuje debatu během prvních hodin reakce: pokud je vetřelec potvrzen a přístup je podezřelý, čtyřhodinový hodinový limit začíná běžet.

Opakující se incidenty a agregátní posouzení

Série menších incidentů může souhrnně splnit závažný práh, i když by tak neudělala žádná jednotlivá událost. Klasifikační nařízení vyžaduje, aby subjekty posuzovaly opakující se incidenty v souhrnu, zejména pokud stejná kořenová příčina produkuje více odlišných událostí. Dokumentace souvislosti mezi incidenty je sama o sobě důkazní výzva — vyžaduje konzistentní uchování logů, forenzní zachycení opakujících se web-orientovaných útočných artefaktů a zdokumentovaný analytický řetězec spojující události napříč tím, co může být týdny nebo měsíce.

Proč uchování důkazů znamená soulad s DORA

Čtyřhodinové okno initial hlášení podle DORA mění operační kalkulus reakce na incidenty způsobem, který málo prvoročních DORA-regulovaných subjektů plně internalizovalo. Tam, kde NIS2 24hodinové early warning umožňuje určitý čas na triáž, DORA očekává, že initial hlášení bude předloženo s jakýmikoli dostupnými informacemi — a později zpřesněno v intermediate a závěrečné zprávě. To znamená, že důkazy podporující případnou závěrečnou zprávu musí být zachyceny během prvních hodin incidentu, kdy týmy současně potlačují útok, obnovují služby a oznamují orgánům. Okno pro budování schopností se zavírá v okamžiku, kdy dojde k detekci.

Nařízení Komise v přenesené pravomoci (EU) 2025/301, které specifikuje obsah initial a následných oznámení, vyžaduje, aby initial zpráva obsahovala — pokud jsou informace k dispozici — informace o tom, zda incident zahrnuje zákeřnou činnost, okamžitý dopad na služby, geografické rozšíření a postižené finanční protistrany. Do intermediate zprávy musí být tento obsah zpřesněn a rozšířen. Do závěrečné zprávy musí být zdokumentována analýza kořenových příčin, technické detaily útoku a získané ponaučení. Žádné z toho nelze dosáhnout bez forenzních důkazů uchovaných od okamžiku detekce.

Operačně nejzranitelnější kategorií důkazů pro finanční subjekty je web-orientovaná útočná infrastruktura. Phishingové stránky napodobující retailové bankovní rozhraní, falešné stránky autorizace plateb, podvodné stránky pro odeslání KYC dokumentů, podobně vypadající investiční platformy a kampaně napodobující značku na sociálních sítích jsou všechny navrženy tak, aby sbíraly finanční přihlašovací údaje, platební údaje nebo onboardingovou dokumentaci. Každá z nich je hostována na infrastruktuře, kterou finanční subjekt neovládá. Hostingoví poskytovatelé sundají phishingové stránky během hodin od oznámení. Útočníci opouštějí infrastrukturu, která byla detekována. Než bude intermediate zpráva splatná 72 hodin později, jsou důkazy pryč, pokud nebyly zachyceny během prvních hodin.

Toto je operační mezera, kterou jsou platformy forenzních web důkazů jako GetProofAnchor navrženy vyplnit. Zachycení provedené v okamžiku detekce incidentu produkuje balíček odolný proti manipulaci — plné HTML, vykreslený screenshot, extrahovaný obsah, síťová metadata a kde je to relevantní, řetězec TLS certifikátu — svázané dohromady kvalifikovaným elektronickým časovým razítkem podle článku 42 eIDAS a nezávisle ukotvené do Bitcoin blockchainu prostřednictvím OpenTimestamps. Když národní příslušný orgán o dva týdny později požádá o důkaz, že phishingová stránka existovala a operovala proti zákazníkům banky, je důkaz k dispozici s matematickou integritou, nikoli s rekonstruovanou pamětí.

Pointa není, že každý DORA subjekt musí přijmout jeden konkrétní nástroj. Pointa je, že uchování důkazů během prvních hodin incidentu je prvotřídní povinnost souladu podle DORA — a že finanční subjekty, které tuto schopnost nevybudovaly před tím, než dojde k incidentu, zjistí během čtyřhodinového hodinového limitu, že absence uchovaných důkazů se stane jejich vlastním hlášeným selháním. Intermediate zpráva je splatná 72 hodin po initial hlášení. Závěrečná zpráva je splatná o měsíc později. Důkazy podporující obě musí být neporušené a musí být obhájitelné pro dohledový orgán.

Forenzní zachycení důkazů o ICT incidentech ve finančním sektoru

ICT incidenty ve finančním sektoru zanechávají svou primární forenzní stopu v charakteristických vzorcích. Pochopení konkrétních kategorií důkazů, které se opakují u DORA-závažných incidentů — a jak je zachytit způsobem, který uspokojuje očekávání příslušného orgánu — je jednou z nejvíce pákových operačních schopností, které může finanční subjekt v roce 2026 rozvinout. Následujících pět kategorií pokrývá většinu web-orientovaných forenzních důkazů v DORA incidentech.

Phishingové stránky napodobující retailové bankovní rozhraní

Phishingové stránky retailového bankovnictví jsou nejběžnějším jednotlivým útočným vektorem proti zákazníkům bank a jsou také nejvíce důkazně křehké. Phishingový operátor postaví stránku na podobně vypadající doméně, provádí kampaň po hodiny nebo dny a opouští nebo migruje infrastrukturu, jakmile je stránka nahlášena. Forenzní zachycení musí obsahovat plné HTML, vizuální vykreslení napříč desktopovým a mobilním viewportem, TLS řetězec ukazující certifikát podobné domény (často bezplatný certifikát Let's Encrypt, což je samo o sobě důkazně relevantní) a síťová zachycení ukazující exfiltrační endpoint přihlašovacích údajů. Orgán dohledu bude chtít podkladový DOM a síťovou identitu zákeřné infrastruktury, nikoli screenshot.

Falešné stránky autorizace a potvrzení plateb

Sofistikovanější varianta zachycuje tok autentizace plateb — obvykle prezentací falešné 3-D Secure nebo PSD2 strong customer authentication stránky během toho, co se zdá být legitimní transakcí. Tyto stránky existují k zachycení jednorázových přístupových kódů vedle primárních přihlašovacích údajů. Důkazní hodnota spočívá v ukázání přesné vizuální mimikry, síťových volání zachycujících OTP a logiky přesměrování. Zachycení musí proběhnout během živého provozu kampaně; poté, co je stránka stažena, forenzní stopa sestává výhradně z toho, co bylo zachyceno v té době, a defenzivní pozice banky závisí na kvalitě tohoto zachycení.

Investiční platformy a krypto burzy napodobující značku

Rostoucí podíl DORA-významných incidentů v letech 2025 a 2026 zahrnoval falešné investiční platformy a podobně vypadající rozhraní poskytovatelů služeb spojených s kryptoaktivy. Tyto obvykle kombinují napodobování domény s podstatnou vícestránkovou mimikrou — falešnými dashboards účtů, falešnými historiemi transakcí, falešnými depozitními rozhraními. Forenzní zachycení musí projít celou uživatelskou cestou napodobování, ideálně zachytit každou stránku útočníkova rozhraní spolu se síťovým stavem v době zachycení. Výsledný balíček důkazů podporuje jak hlášení DORA, tak následné zapojení orgánů činných v trestním řízení podle národního trestního práva.

Falešné KYC a portály pro odeslání onboardingových dokumentů

Některé útočné kampaně se zaměřují na onboarding zákazníků spíše než na aktivní účty. Falešné KYC portály sbírají identifikační dokumenty — pasy, řidičské průkazy, doklad o adrese — které jsou poté přeprodány nebo použity v následném podvodu. Z perspektivy finančního subjektu jsou důkazy o těchto kampaních relevantní jak pro hlášení DORA incidentů, tak pro oznámení o porušení osobních údajů podle článku 33 GDPR. Jediné forenzní zachycení podporuje obě regulační koleje, pokud je konstruováno s primitivy integrity, které oba regulátoři očekávají.

Důkazy o výpadcích a incidentech kritických ICT poskytovatelů třetích stran

Když určený kritický ICT poskytovatel třetí strany zažije výpadek, který ovlivňuje služby finančního subjektu, finanční subjekt musí zachytit důkazy o stavu třetí strany v době incidentu. Toto je skutečně nové důkazní území podle DORA — subjekt musí zdokumentovat něco, co neovládá, na infrastruktuře provozované CTPP pod přímým dohledem ESA. Forenzní zachycení stavové stránky CTPP, vlastní telemetrie degradace služby subjektu a jakýchkoli veřejných prohlášení, která CTPP během incidentu vydal, se stává základem DORA hlášení incidentu subjektu a jakéhokoli následného nároku na obnovu vůči CTPP.

Řízení rizik ICT třetích stran (kapitola V)

Kapitola V DORA — články 28 až 44 — se zabývá tím, co evropští dohlížitelé považují za hlavní vektor systémového narušení v moderních finančních službách: závislostí finančních subjektů na malém počtu velkých poskytovatelů ICT služeb třetích stran. Kapitola je nejvíce vnitřně kontroverzním prvkem DORA v průmyslových konzultacích a operačně nejnáročnějším pro subjekty v působnosti, zejména ty, které outsourcovaly podstatné části svého technologického stacku za poslední desetiletí.

Článek 28 zavádí obecnou zásadu: finanční subjekty zůstávají plně odpovědné za soulad se všemi svými povinnostmi podle DORA bez ohledu na rozsah, v jakém se spoléhají na poskytovatele ICT služeb třetích stran. Tato zásada nedelegace je základem režimu třetích stran — regulátor nemůže pronásledovat třetí stranu za selhání subjektu, ale subjekt nemůže uniknout odpovědnosti odkazem na třetí stranu. Smluvní řetězec musí přivést chování třetí strany pod kontrolu subjektu prostřednictvím specifických, vymahatelných mechanismů.

Článek 30 specifikuje povinná smluvní ustanovení pro ICT služby třetích stran podporující kritické nebo důležité funkce. Smlouvy musí obsahovat — mimo jiné — kompletní popis služeb, místa, kde jsou služby poskytovány a kde jsou data zpracovávána, požadavky na úroveň služeb, požadavky na ICT bezpečnost a odolnost, práva subjektu na audit, práva na ukončení včetně strategií ukončení, spolupráci s příslušnými orgány a povinnosti oznamování incidentů ze strany třetí strany finančnímu subjektu. Nařízení Komise v přenesené pravomoci (EU) 2025/532 ze dne 24. března 2025 specifikuje prvky, které finanční subjekty musí určit a posoudit při subdodávkách ICT služeb podporujících kritické nebo důležité funkce.

Registr informací — vyžadovaný podle čl. 28 odst. 3 a specifikovaný v prováděcích technických standardech — je centralizovaný inventář, který finanční subjekty musí udržovat o všech svých smluvních ujednáních s poskytovateli ICT služeb třetích stran, včetně subdodavatelů. Reportovací cyklus 2026 pokrývá ujednání s referenčním datem 31. prosince 2025, přičemž národní lhůty pro podání se liší podle členského státu. Cvičení ESA z roku 2024 v rámci dry-run zjistilo, že pouze 6,5 % z téměř 1 000 firem napříč EU úspěšně prošlo všemi 116 kontrolami kvality dat — což ilustruje rozsah operační úpravy stále vyžadované pro plný soulad i s dokumentárními povinnostmi kapitoly V.

Kritičtí ICT poskytovatelé třetích stran: listopadová 2025 určení

18. listopadu 2025 zveřejnily Evropské orgány dohledu — EBA, EIOPA a ESMA — první oficiální seznam 19 určených kritických ICT poskytovatelů třetích stran podle DORA. Určení staví tyto poskytovatele poprvé pod přímý dohled EU, odděleně od a navíc k jakékoli sektorové regulaci, která se již uplatňuje. 19 určených CTPPs zahrnuje dominantní hyperscale cloudové poskytovatele (AWS, Microsoft Azure, Google Cloud), klíčové poskytovatele finančních dat a platforem (Bloomberg, London Stock Exchange Group, IBM) a další významné poskytovatele služeb obsluhující finanční sektor EU (Tata Consultancy Services, Orange).

Rámec určování funguje prostřednictvím kritérií stanovených v článku 31 a rozpracovaných v aktech v přenesené pravomoci. CTPPs jsou určeny na základě systémové důležitosti — měřené proti počtu a důležitosti finančních subjektů v působnosti, které se na nich spoléhají, nenahraditelnosti jejich služeb a důsledkům jejich selhání. Určení spouští přímý dohled společných vyšetřovacích týmů (JETs) koordinovaných příslušným vedoucím dohlížitelem, poplatek za dohled placený CTPP a řadu dohledových pravomocí včetně vyšetřování, kontroly na místě a závazných doporučení.

Pro finanční subjekty jsou praktické důsledky určení CTPP podstatné. Spoléhání na určeného CTPP musí být explicitně zdokumentováno v registru informací. Riziko koncentrace — riziko, že je finanční subjekt nadměrně závislý na jednom CTPP nebo na malé skupině CTPPs operujících korelovanými způsoby — musí být posouzeno a řízeno. Strategie ukončení musí být věrohodné: smlouvy musí umožňovat přechod k alternativnímu poskytovateli v zvládnutelném časovém rámci, i když praktickou realitou je, že žádná plně rovnocenná alternativa neexistuje.

Společné vyšetřovací týmy zahájily dohledové aktivity během prvního čtvrtletí 2026. CTPPs samotné nyní operují pod přímým EU-úrovňovým dohledovým zapojením poprvé, kromě jakékoli sektorové regulace — často ve Spojených státech, kde má sídlo většina určených subjektů — která se již uplatňuje. Vzájemné působení dohledu EU a regulace domovské země je samo o sobě se vyvíjející oblastí praxe, která bude formovat realitu vymáhání DORA v nadcházejících letech.

Pro reakci na incidenty specificky určení CTPP vytváří novou důkazní dimenzi. Když určený CTPP zažije incident ovlivňující služby finančního subjektu, DORA hlášení finančního subjektu bude muset koordinovat s reakcí CTPP na incident, s dohledovým zapojením společného vyšetřovacího týmu a s jakýmikoli paralelními regulačními dotazy. Forenzní zachycení externího stavu CTPP během incidentu — veřejných stavových stránek, komunikace o incidentu, částečných důkazů o službě — se stává kritickým kouskem defenzivního záznamu finančního subjektu, zejména kde následně vznikají smluvní jednání nebo nároky na servisní kredit.

Threat-led penetrační testování (článek 26) a TIBER-EU

Článek 26 DORA zavádí podstatně novou povinnost provozního testování pro významné finanční subjekty: threat-led penetrační testování neboli TLPT. Rámec je založen na TIBER-EU — rámci Threat Intelligence-Based Ethical Red Teaming vyvinutém Evropskou centrální bankou — a představuje krokovou změnu od konvenčního penetračního testování v rozsahu, intenzitě a regulatorním zapojení.

TLPT je vyžadováno pro finanční subjekty identifikované jako významné příslušným orgánem. Seznam není veřejný, ale kritéria jsou založena na systémové důležitosti subjektu, roli v kritických infrastrukturách finančních trhů a profilu ICT rizika. Jakmile jsou identifikovány, subjekt musí provádět TLPT cvičení alespoň jednou za tři roky. Testování se provádí na produkčních systémech v živém provozu — nikoli v izolovaných testovacích prostředích — pokrývající kritické nebo důležité funkce a sleduje strukturovanou metodologii zahrnující přípravu zpravodajských informací o hrozbách, provedení červeného týmu a nápravu.

Rozsah testování musí pokrývat několik kritických nebo důležitých funkcí a musí zahrnovat živý provoz. Toto je operačně nejvíce invazivní jednotlivá povinnost podle DORA. Příslušný orgán je zapojen po celou dobu, od definice rozsahu po výběr červeného týmu (který musí zahrnovat akreditované testery) po posouzení výsledku. Příslušný orgán může vyžadovat další testování, pokud initial cvičení produkuje nedostatečné pokrytí nebo neuspokojivé výsledky.

Vzájemné uznávání napříč členskými státy je klíčovou vlastností: TLPT cvičení provedené pod dohledem příslušného orgánu jednoho členského státu je uznáváno jinými členskými státy, kde finanční subjekt operuje. To zabraňuje duplicitnímu testování pro přeshraniční subjekty a zároveň zajišťuje, že každý subjekt je testován v rámci jediného koordinovaného režimu. Implementace rámce byla postupná v letech 2025 a 2026, přičemž první cyklus TLPT cvičení nyní probíhá napříč významnými finančními subjekty.

Z důkazního hlediska TLPT generuje podstatnou dokumentární stopu — posouzení zpravodajských informací o hrozbách, plány červeného týmu, zjištění zneužití, plány nápravy a po-cvičební zprávy. Integrita této dokumentace je důležitá, protože zjištění TLPT mohou samy o sobě tvořit základ pro dohledové opatření, kde se ukáže, že kritické nebo důležité funkce jsou nedostatečně chráněny. Udržování této audit trail se stejnou důkazní integritou očekávanou pro hlášení incidentů je součástí budování koherentní DORA důkazní architektury.

Sankce, osobní odpovědnost a meziodvětvová spolupráce

Sankční rámec DORA funguje na dvou úrovních: administrativní pokuty ukládané národními příslušnými orgány finančním subjektům a periodické pokuty ukládané vedoucím dohlížitelem kritickým ICT poskytovatelům třetích stran v rámci rámce dohledu. Členské státy mohou rovněž stanovit trestní sankce podle národního práva, kde porušení DORA zahrnují porušení národního trestního práva (článek 52).

Článek 50 vyžaduje, aby členské státy zajistily, že příslušné orgány mají pravomoc ukládat přiměřené administrativní pokuty a nápravná opatření za porušení DORA. Specifické kvantitativní limity jsou ponechány na národní transpozici podpůrné směrnice (EU) 2022/2556, s výsledkem, že maximální pokuty se napříč Unií liší. V praxi několik členských států implementovalo maxima v rozmezí 5–10 milionů EUR nebo 10 % celkového ročního obratu, což zrcadlí měřítko srovnatelných sankcí finančního sektoru za selhání v správě.

Pro kritické ICT poskytovatele třetích stran článek 35 zmocňuje vedoucího dohlížitele ukládat periodické pokuty až do výše 1 % průměrného denního celosvětového obratu CTPP v předchozím obchodním roce. Periodický charakter je významný: pokuta se hromadí denně po dobu nesouladu, což vytváří trvalý tlak na nápravu spíše než zacházení s pevnou pokutou jako s nákladem podnikání. První invokace této pravomoci se očekávají v letech 2026 a 2027, jak se zralá dohledová zapojení společných vyšetřovacích týmů.

Osobní odpovědnost vrcholového managementu je v DORA implicitní spíše než explicitně strukturovaná tak, jak je v článku 20 NIS2. DORA klade odpovědnosti za řízení ICT rizik na řídící orgán (článek 5) a šíře na vrcholový management, s výsledkem, že selhání v těchto oblastech spouští úvahy o vhodnosti a slušnosti podle sektorové finanční regulace — bankovního dohledu, pojišťovacího dohledu, dohledu nad cennými papíry — které mohou zahrnovat osobní sankce, manažerské zákazy a diskvalifikace. Mechanismus je nepřímý, ale důsledky jsou přímé.

Článek 47 zavádí formální spolupráci mezi příslušnými orgány DORA a architekturou NIS2 — CSIRT určenými podle NIS2, sítí CSIRT EU a ENISA. Spolupráce funguje oběma směry: orgány DORA dostávají informace od CSIRT NIS2 o incidentech potenciálně ovlivňujících finanční subjekty a mohou kanálovat DORA-hlášené incidenty CSIRT NIS2, kde to opravňují meziodvětvové implikace. Pro finanční subjekty to znamená, že jediný incident může produkovat regulační zapojení napříč DORA, NIS2 (prostřednictvím kanálu spolupráce CSIRT), GDPR (kde jsou zapojeny osobní údaje) a sektorovou finanční regulací — přičemž každý regulátor posuzuje stejné podkladové skutečnosti nezávisle.

DORA, NIS2 a GDPR: lex specialis a překrývající se povinnosti

DORA funguje v rámci regulatorního klastru, který zahrnuje NIS2, GDPR, směrnici CER a sektorově specifický finanční dohled. Pro jediný významný incident související s ICT může finanční subjekt čelit současným povinnostem podle tří, čtyř nebo pěti z těchto rámců. Pochopení toho, jak se prolínají, je zásadní pro vyhnutí se jak mezerám, tak duplikovanému úsilí během toho, co je již vysokotlaká reakční fáze.

DORA je lex specialis k NIS2 pro finanční subjekty. Článek 4 směrnice (EU) 2022/2555 (NIS2) výslovně vyjímá finanční subjekty z povinností NIS2 v oblasti řízení rizik a hlášení incidentů, uznávaje DORA jako platný rámec. Výjimka není absolutní — členské státy mohou stále označit finanční subjekty jako kritické subjekty podle směrnice CER a kanál spolupráce CSIRT NIS2 se uplatňuje prostřednictvím článku 47 DORA — ale operační povinnosti spočívají v DORA. Toto je nejčistší meziframeworkový vztah v právu kybernetické bezpečnosti EU.

Naproti tomu článek 33 GDPR se uplatňuje paralelně bez vytěsnění. Pokud DORA-závažný incident související s ICT zahrnuje porušení osobních údajů — a většina útoků proti finančním subjektům ano — 72hodinové oznámení příslušnému úřadu pro ochranu osobních údajů běží vedle kaskády DORA 4 hodiny / 72 hodin / 1 měsíc. Spouštěče se liší (DORA: operační dopad; GDPR: riziko pro subjekty údajů), takže jediný incident může spustit oba. Důkazy podporující obě musí být uchovatelné ve formě, která uspokojuje nejpřísnější platné požadavky — typicky znamená kryptografické hashování artefaktů, kvalifikovaná elektronická časová razítka podle článku 42 eIDAS a nezávislou ověřitelnost třetími stranami.

Platformy forenzních web důkazů jako GetProofAnchor jsou navrženy tak, aby produkovaly balíčky důkazů, které uspokojují všechny tři regulátory současně. Evidence ZIP — zapečetěná kvalifikovaným časovým razítkem eIDAS dodaným prostřednictvím EU-listovaného kvalifikovaného poskytovatele služeb vytvářejících důvěru, nezávisle ukotvená do Bitcoin blockchainu prostřednictvím OpenTimestamps a dodávaná s open-source verifikační utilitou — funguje stejně pro příslušný orgán DORA, CSIRT NIS2 (kde je vyvolán kanál spolupráce) a úřad pro ochranu osobních údajů. Jediné zachycení provedené v okamžiku detekce incidentu slouží všem následným hlášecím povinnostem bez další práce.

Kromě těchto tří regulátorů by finanční subjekty měly také zvážit sektorové interakce. Hlášení provozních a bezpečnostních incidentů souvisejících s platbami podle PSD2 bylo z velké části nahrazeno DORA pro platební instituce v působnosti, ale jeho podstatné povinnosti se přesunuly do kaskády článku 19 DORA. Nařízení eIDAS upravuje služby důvěry používané pro uchování důkazů. Sektorová finanční regulace nadále funguje vedle DORA. Budování jedné koherentní důkazní architektury — spíše než samostatných důkazních toků pro každého regulátora — je operační efektivita, která odlišuje dobře připravené finanční subjekty v éře DORA.

Kontrolní seznam důkazů o DORA incidentech (15 bodů)

Následující kontrolní seznam konsoliduje operační priority z tohoto průvodce. Není náhradou za právní poradenství ani za konkrétní pokyny vašeho národního příslušného orgánu, ale zachycuje rozlišovací charakteristiky finančních subjektů, které jsou operačně DORA-připravené, na rozdíl od těch, které jsou pouze dokumentárně připravené.

  • Určete vaši DORA klasifikaci (podkategorii finančního subjektu) a zdokumentujte určení s podpůrnými odkazy na ustanovení o působnosti článku 2 a vašemu národnímu dohledovému rámci.
  • Identifikujte příslušný orgán a jakýkoli platný dohledový orgán specifický pro vaši podkategorii a navažte předincidentní komunikační kanály včetně šablon pro initial hlášení, intermediate zprávu a závěrečnou zprávu.
  • Definujte interní klasifikační kritéria pro závažné incidenty související s ICT v souladu s nařízením Komise v přenesené pravomoci (EU) 2024/1772, včetně duální spouštěcí logiky (kritické služby + ztráta dat NEBO kritické služby + dva prahy), a přezkoumávejte je alespoň jednou ročně.
  • Zajistěte 24/7 detekční schopnost, aby čtyřhodinový hodinový limit initial hlášení mohl začít v okamžiku klasifikace, bez ohledu na pracovní dobu nebo víkendy.
  • Určete primárního pracovníka pro hlášení incidentů a alespoň jednoho zástupce s plnou pravomocí podávat initial hlášení v rámci čtyřhodinového okna bez zpoždění schválením managementem.
  • Implementujte logování odolné proti manipulaci napříč ICT majetkem se zdokumentovanými integritními primitivy (hashové řetězce, kvalifikovaná elektronická časová razítka nebo ekvivalent) a uchováním přiměřeným sektorovým očekáváním — typicky minimálně 12 měsíců, s delšími obdobími pro specifické kategorie.
  • Stanovte forenzní postupy zachycení pro web-orientované útočné artefakty nejrelevantnější pro finanční subjekty — phishingové stránky napodobující retailové rozhraní, falešné stránky autorizace plateb, investiční platformy napodobující značku, falešné KYC portály a stav kritických ICT poskytovatelů třetích stran během výpadků.
  • Svažte zachycené artefakty dohromady prostřednictvím kryptografických manifestů (SHA-256 přes všechny soubory) a předložte hash manifestu EU-listovanému kvalifikovanému poskytovateli služeb vytvářejících důvěru pro kvalifikované elektronické časové razítko podle článku 42 nařízení (EU) 910/2014.
  • Ukotvěte balíčky důkazů nezávisle — například prostřednictvím Bitcoin blockchainu přes OpenTimestamps — aby integrita mohla být ověřena bez spoléhání na subjekt, poskytovatele služeb vytvářejících důvěru nebo jakýkoli jednotlivý bod selhání.
  • Zdokumentujte řetězec úschovy v souladu s fázemi ISO/IEC 27037:2012 (identifikace, sběr, akvizice, uchování) pro každou položku důkazu, s rolemi, časovými razítky a akcemi zaznamenanými.
  • Udržujte aktuální registr informací pro všechna ICT ujednání třetích stran podporující kritické nebo důležité funkce s mapováním subdodavatelů v souladu s nařízením Komise v přenesené pravomoci (EU) 2025/532, připravený k podání v národním reportovacím cyklu.
  • Identifikujte své spoléhání na každého z 19 určených kritických ICT poskytovatelů třetích stran (k listopadu 2025), posuďte riziko koncentrace a zdokumentujte strategie ukončení požadované článkem 28.
  • Proveďte nebo naplánujte threat-led penetrační testovací cvičení podle článku 26, pokud jste významný finanční subjekt, s plánem cvičení dohodnutým s příslušným orgánem a zdokumentovaným uchováním důkazů pro samotný test.
  • Zmapujte překryv mezi DORA a dalšími platnými regulacemi (kanál spolupráce NIS2 přes článek 47, GDPR článek 33, přechod PSD2, sektorová finanční regulace), aby jediný incident produkoval koordinovaná oznámení napříč všemi platnými režimy, podporovaná jediným koherentním balíčkem důkazů.
  • Učiňte všechny balíčky důkazů nezávisle ověřitelné třetími stranami — příslušnými orgány, vedoucím dohlížitelem pro záležitosti spojené s CTPP, soudy, pojišťovnami, právními zástupci — pomocí open-source verifikačních nástrojů a bez závislosti na infrastruktuře produkujícího subjektu.

Často kladené otázky a závěr

Následující odpovědi se zabývají otázkami, které se objevují nejčastěji, když finanční subjekty začínají operacionalizovat zacházení s DORA důkazy. Jsou určeny jako praktická orientace, nikoli jako právní poradenství pro jakoukoli konkrétní situaci.

Kdy začíná čtyřhodinový hodinový limit DORA?
Hodinový limit začíná v okamžiku, kdy finanční subjekt klasifikuje incident jako závažný. Klasifikace samotná musí nastat co nejdříve to bude rozumně proveditelné po detekci, a v každém případě do 24 hodin od detekce. Kumulativní účinek — od detekce po initial hlášení — by neměl překročit 28 hodin a dohledová očekávání obecně řetězec dále komprimují. Zadržení hlášení proto, že vyšetřování není dokončeno, výslovně není v souladu; initial hlášení má poskytnout včasné povědomí, nikoli kompletní analýzu.
Je 72hodinová intermediate zpráva DORA stejná jako 72hodinové oznámení GDPR?
Ne. DORA má 4hodinové initial hlášení následované 72hodinovou intermediate zprávou — 72 hodin běží od initial hlášení, nikoli od detekce incidentu. Článek 33 GDPR má jediné 72hodinové oznámení úřadu pro ochranu osobních údajů běžící od povědomí. Hodinové limity mohou běžet paralelně pro incidenty zahrnující osobní údaje, ale jsou spuštěny odděleně a běží v různých cyklech.
Co se počítá jako závažný incident související s ICT podle DORA?
Incident je závažný, když byly poškozeny kritické nebo důležité služby A buď (a) dochází ke ztrátám dat — včetně jakéhokoli úspěšného, zákeřného a neoprávněného přístupu vedoucího ke ztrátě dat — nebo (b) jsou překročeny alespoň dva ze šesti dalších prahů významnosti (klienti, transakce, reputační dopad, doba trvání, geografie, ekonomický dopad). Nařízení Komise v přenesené pravomoci (EU) 2024/1772 poskytuje specifické kvantitativní prahy, včetně prahu 30 % postižených protistran a prahu 10 % transakcí podle počtu nebo hodnoty.
Mají malé finanční subjekty výjimku size-cap jako NIS2?
Obecně ne. DORA se aplikuje prakticky na každý regulovaný finanční subjekt v Unii bez ohledu na velikost, ačkoli povinnosti musí být aplikovány zjednodušeným způsobem na mikropodniky a určité menší instituce. Podstatné povinnosti — řízení rizik, hlášení incidentů, riziko třetích stran — se aplikují plošně. Toto je jeden z hlavních rozdílů mezi DORA a NIS2 v designu působnosti.
Může finanční subjekt outsourcovat DORA hlášení incidentů?
Článek 19 odst. 5 výslovně umožňuje finančním subjektům outsourcovat operační práci hlášení poskytovateli služeb třetí strany, včetně jinému subjektu v rámci stejné finanční skupiny. Samotná povinnost hlášení zůstává na regulovaném finančním subjektu — outsourcing pokrývá přípravu, přenos a další postup, nikoli právní odpovědnost. Příslušné orgány členských států musí souhlasit s outsourcingovým ujednáním, pokud překračuje hranice subjektů.
Jaké důkazy musí být uchovány spolu s DORA initial hlášením?
Initial hlášení musí obsahovat — pokud jsou informace k dispozici — ukazatele zákeřné činnosti, okamžitý dopad na služby, geografické rozšíření a postižené finanční protistrany. Intermediate zpráva (o 72 hodin později) toto zpřesňuje technickými detaily. Závěrečná zpráva (o měsíc později) vyžaduje analýzu kořenových příčin. Žádné z toho nelze rekonstruovat z paměti — podkladové logy, síťová zachycení, forenzní kopie kompromitovaných aktiv a jakékoli související web-orientované artefakty musí být uchovány s ověřitelnou integritou od okamžiku detekce incidentu.
Jak dlouho musí být DORA-související důkazy uchovávány?
DORA nespecifikuje jednotnou dobu uchování napříč všemi kategoriemi důkazů. Povinnosti článku 17 týkající se řízení incidentů souvisejících s ICT implikují uchování dostatečné k podpoře analýzy kořenových příčin (typicky alespoň 12 měsíců pro rutinní logy), zatímco důkazy specifické pro incident — zachycené artefakty, forenzní kopie, komunikace s příslušným orgánem — by měly být uchovány alespoň po dobu promlčení relevantních řízení (která může běžet sedm let nebo více podle sektorové finanční regulace). Národní orgány dohledu mohou ukládat delší minima pro specifické kategorie dat.
Jaký je vztah mezi DORA a hlášením incidentů podle PSD2?
Hlášení provozních a bezpečnostních incidentů souvisejících s platbami podle PSD2 bylo nahrazeno DORA pro incidenty zahrnující úvěrové instituce, platební instituce, poskytovatele služeb informování o účtu a instituce elektronických peněz. Podstatné povinnosti se z velké části přesunuly do DORA, přičemž harmonizovaná třístupňová kaskáda nahradila předchozí fragmentované národní přístupy. Některá sektorová specifika PSD2 přetrvávají v národní transpozici, ale principálním režimem je nyní článek 19 DORA.
Může jediný incident spustit DORA, kanály spolupráce NIS2 a GDPR současně?
Ano. Ransomwarový útok na finanční subjekt zpracovávající osobní údaje, zejména kde útočný vektor zahrnuje ICT služby třetí strany, může zapojit článek 19 DORA (hlášení finančního sektoru), kanál spolupráce CSIRT NIS2 podle článku 47 DORA a článek 33 GDPR (porušení osobních údajů). Důkazy uchované s ověřitelnou integritou uspokojují všechny tyto současně; důkazy rekonstruované z paměti nesplňují žádné z nich.
Musím být zákazníkem kritického ICT poskytovatele třetí strany, abych byl ovlivněn režimem CTPP?
Přímí zákazníci určených CTPPs čelí nejvíce přímým povinnostem — musí zdokumentovat spoléhání v registru informací, posoudit riziko koncentrace a udržovat strategie ukončení. Nicméně nepřímé závislosti — například kde se váš subdodavatel spoléhá na určeného CTPP — musí být také mapovány podle nařízení Komise v přenesené pravomoci (EU) 2025/532. Listopadové 2025 určení 19 CTPPs má implikace viditelnosti napříč většinou ICT dodavatelských řetězců finančních subjektů, včetně AWS, Microsoft Azure, Google Cloud, IBM, Bloomberg, LSEG, TCS a Orange.
Je TLPT podle článku 26 stejné jako standardní penetrační testování?
Ne. Threat-led penetrační testování podle článku 26 je podstatně intenzivnější režim než konvenční penetrační testování. Je založen na rámci TIBER-EU, prováděn na produkčních systémech v živém provozu pro kritické nebo důležité funkce, zahrnuje fáze přípravy zpravodajských informací o hrozbách, musí být prováděn akreditovanými testery a běží pod dohledem příslušného orgánu po celou dobu. Vzájemné uznávání napříč členskými státy zabraňuje duplicitnímu testování pro přeshraniční subjekty, ale samotné testování je přísnější než typické komerční penetrační testování.
Jak se forenzní web důkaz liší od screenshotu v kontextu DORA?
Screenshot je jediný PNG soubor, který lze upravit v jakémkoli editoru obrázků během sekund. Forenzní web důkaz je víceartefaktový balíček — plné HTML, vykreslený screenshot, extrahovaný text, síťová metadata, TLS řetězec, parametry zachycení — svázaný kryptografickým manifestem, zapečetěný kvalifikovaným elektronickým časovým razítkem eIDAS a nezávisle ověřitelný třetími stranami. Pro čtyřhodinovou, 72hodinovou a měsíční hlášecí kaskádu DORA je rozdíl rozdílem mezi obhájitelným regulatorním důkazem a materiálem, který příslušný orgán bude považovat za málo vážný.
Co se stane, když finanční subjekt zmešká čtyřhodinovou hlášecí lhůtu?
Pozdní podání kterékoli fáze kaskády článku 19 je selháním souladu podle DORA a aktivuje administrativní sankční režim podle článku 50. Posouzení sankce zvažuje úmysl, historii souladu, spolupráci s orgánem a kroky ke zmírnění. Pozdní podání kombinované se zničenými forenzními důkazy — například kde náprava přepsala útočné artefakty před zachycením — je obvykle posuzováno přísněji než pouhé pozdní podání. Dobrovolné rané zveřejnění, i mimo formální časový harmonogram, je obvykle považováno za polehčující faktor.
Jak by měly multi-jurisdikční finanční subjekty zacházet s DORA hlášením?
DORA hlášení je obecně směrováno k příslušnému orgánu domovského členského státu finančního subjektu podle sektorového dohledu subjektu. Domovský orgán pak kanáluje relevantní informace ESAs a dalším postiženým členským státům prostřednictvím rámce spolupráce. Přeshraničně operující subjekty by měly udržovat jediný zdroj pravdy pro důkazy o incidentu, aby konzistentní informace mohly být produkovány jakémukoli žádajícímu orgánu — zejména kde dohledová zapojení společných vyšetřovacích týmů zahrnují CTPP-související incidenty, které překračují jurisdikční hranice.
Jak GetProofAnchor specificky podporuje DORA zacházení s důkazy?
GetProofAnchor poskytuje forenzní zachycení web důkazů pro specifické DORA use cases diskutované v tomto průvodci — phishingové stránky napodobující retailové bankovní rozhraní, falešné stránky autorizace plateb, investiční platformy napodobující značku, falešné KYC portály a zachycení stavu kritických ICT poskytovatelů třetích stran během výpadků. Každé zachycení produkuje Evidence ZIP svázaný kvalifikovaným elektronickým časovým razítkem podle článku 42 eIDAS (dodaným prostřednictvím EU-listovaného kvalifikovaného poskytovatele služeb vytvářejících důvěru) a nezávisle ukotvený do Bitcoin blockchainu přes OpenTimestamps. Důkaz je nezávisle ověřitelný pomocí open-source verifikační utility GetProofAnchor, takže národní příslušné orgány, soudy, pojišťovny, právní zástupci a společné vyšetřovací týmy v záležitostech spojených s CTPP mohou ověřit důkaz bez jakékoli závislosti na GetProofAnchor nebo na produkujícím finančním subjektu. Platforma je navržena tak, aby uspokojila požadavky na důkazy podle článku 19 DORA, požadavky na důkazy podle článku 33 GDPR (kde jsou zapojeny osobní údaje) a kanál spolupráce CSIRT NIS2 podle článku 47 DORA, vše z jediného zachycení provedeného v okamžiku detekce incidentu.

První rok aplikace DORA potvrdil to, co bylo široce očekáváno během přípravné fáze: nařízení je operačně náročné, lhůty jsou přísné a dohledové zapojení je trvalé. Míra průchodnosti 6,5 % v dry-run 2024 ilustrovala mezeru mezi politickým souladem a operační připraveností. Reportovací cyklus 2026 prováděný za aktivního vymáhání produkuje jasnější obraz o tom, kde jednotlivé subjekty stojí.

Schopnosti, které odlišují operačně DORA-připravené finanční subjekty, jsou rozpoznatelné. Detekční systémy, které mohou klasifikovat incidenty rychle. Reportovací workflow, které produkují initial hlášení v rámci čtyřhodinového okna bez zpoždění schválením managementem. Forenzní uchování artefaktů incidentu — zejména web-orientované útočné infrastruktury, která mizí nejrychleji v hodinách po detekci. Nezávislá ověřitelnost výsledných důkazů příslušným orgánem, vedoucím dohlížitelem v záležitostech spojených s CTPP a jakýmkoli následným soudem nebo pojišťovnou. Žádná z těchto schopností není exotická; co odlišuje dobře připravený subjekt, je, že všechny jsou na místě před prvním závažným incidentem.

GetProofAnchor existuje, aby učinil komponentu forenzního uchování tohoto stacku — konkrétně web-orientované artefakty, které mizí nejrychleji v okamžicích po detekci — přímočarou, obhájitelnou a nezávisle ověřitelnou napříč DORA, NIS2 spoluprací a GDPR současně. Pokud váš finanční subjekt buduje svou DORA schopnost zacházení s důkazy a chtěl by vidět, jak kvalifikovaně časově orazítkované forenzní web zachycení integruje s čtyřhodinovým reportovacím workflow, nejpřímější cestou je vytvořit vzorový proof z jakékoli veřejné URL a prohlédnout si Evidence ZIP. Ověření je open-source a běží na jakémkoli laptopu. Standard je reprodukovatelný, protože podle DORA to tak musí být.

Vybudujte DORA-připravené důkazy předtím, než začne běžet čtyřhodinový hodinový limit

Vytvořte proof odolný proti manipulaci jakékoli veřejné URL s kvalifikovanými časovými razítky eIDAS a nezávislým ukotvením do Bitcoin blockchainu. Ověření je open-source. Navrženo pro požadavky na důkazy podle DORA, NIS2 a GDPR, které platí napříč finančním sektorem EU.

GetProofAnchor je navržen pro forenzní zachycení web důkazů napříč finančním sektorem EU. Zachycení jsou zapečetěna kvalifikovanými elektronickými časovými razítky podle článku 42 eIDAS akreditovaným poskytovatelem služeb vytvářejících důvěru uvedeným na EU Trusted List.