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?
Je 72hodinová intermediate zpráva DORA stejná jako 72hodinové oznámení GDPR?
Co se počítá jako závažný incident související s ICT podle DORA?
Mají malé finanční subjekty výjimku size-cap jako NIS2?
Může finanční subjekt outsourcovat DORA hlášení incidentů?
Jaké důkazy musí být uchovány spolu s DORA initial hlášením?
Jak dlouho musí být DORA-související důkazy uchovávány?
Jaký je vztah mezi DORA a hlášením incidentů podle PSD2?
Může jediný incident spustit DORA, kanály spolupráce NIS2 a GDPR současně?
Musím být zákazníkem kritického ICT poskytovatele třetí strany, abych byl ovlivněn režimem CTPP?
Je TLPT podle článku 26 stejné jako standardní penetrační testování?
Jak se forenzní web důkaz liší od screenshotu v kontextu DORA?
Co se stane, když finanční subjekt zmešká čtyřhodinovou hlášecí lhůtu?
Jak by měly multi-jurisdikční finanční subjekty zacházet s DORA hlášením?
Jak GetProofAnchor specificky podporuje DORA zacházení s důkazy?
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.