Připravenost na DORA pro finanční subjekty a jejich dodavatele IKT

Nařízení DORA se použije od 17. ledna 2025. Pro finanční subjekty dnes připravenost znamená udržovat provozní model digitální provozní odolnosti, nikoli se připravovat na budoucí termín. Pro technologické dodavatele znamená pochopit své odpovědnosti vůči zákazníkům a zjistit, zda se na ně vztahuje samostatný režim přímého dozoru.

Otázka pro vedení je praktická: dokáže organizace vysvětlit, které finanční služby závisejí na kterých systémech IKT, jak bude narušení řešeno a jaké důkazy podporují její předpoklady o obnově? Politiky jsou důležité, samy však na tuto otázku odpovědět nemohou. Vedení potřebuje propojený pohled na odpovědnosti, závislosti, smlouvy, testy, incidenty a nevyřešená rizika.

Než sestavíte kontrolní seznam, určete svou roli

Začněte zdokumentovaným rozhodnutím o použitelnosti pro každý relevantní právní subjekt. Článek 2 nařízení DORA vymezuje dotčené kategorie a výjimky. Podnik, který se označuje za fintech, startup nebo malý či střední podnik, není automaticky v působnosti ani z ní vyňat.

Příklady dotčených finančních subjektů zahrnují úvěrové instituce, platební instituce, investiční podniky a pojišťovny, s výhradou podrobných pravidel působnosti nařízení. Zaznamenejte příslušnou kategorii, případné vynětí nebo výjimku, příslušný orgán a zdůvodnění svého závěru.

U dodavatelů rozlišujte tři pozice:

Dodavatel, který podporuje kritickou nebo důležitou finanční funkci, není jen z tohoto důvodu určeným kritickým třetím poskytovatelem služeb IKT. Finanční subjekty posuzují význam svých funkcí a závislostí; určení kritických poskytovatelů probíhá v rámci dohledu podle článku 31.

Sídlo otázku dodavatele nerozhoduje. Poskytovatel cloudu nebo softwaru se sídlem v USA může čelit zákaznickým požadavkům souvisejícím s DORA, pokud obsluhuje finanční subjekty v EU. Tento obchodní vztah jej však automaticky nepodřizuje všem povinnostem uloženým finančnímu subjektu.

I proporcionalita vyžaduje odůvodněné posouzení. Článek 4 zohledňuje faktory včetně velikosti, celkového rizikového profilu a povahy, rozsahu a složitosti služeb. Článek 16 stanoví zjednodušený rámec řízení rizik v oblasti IKT pro vymezené kategorie. Nejde o zaměnitelné pojmy a běžný status malého či středního podniku není univerzální zkratkou. Analýzu způsobilosti uchovávejte spolu s rozhodnutím o působnosti.

Zviditelněte odpovědnost vedení

Podle článku 5 nařízení DORA nese řídicí orgán konečnou odpovědnost za řízení rizik v oblasti IKT finančního subjektu. Delegování implementace na CISO, technologický tým nebo externího poskytovatele tuto odpovědnost nepřenáší.

Vedení by mělo stanovit, kdo rozhodnutí navrhuje, kdo je schvaluje a kdo kontroluje, zda implementace funguje. Provozní model by měl pokrývat kontinuitu činností, reakci na incidenty a obnovu, ujednání se třetími stranami, rozpočet a znalosti potřebné pro smysluplný dohled.

Praktickým doporučením je poskytovat vedení reportingový balíček zaměřený na rozhodnutí, nikoli dashboard s procentem dokončení. Zahrňte:

• Kritické nebo důležité funkce s neotestovanými předpoklady obnovy.
• Závažné incidenty, dopady na zákazníky a nedokončená nápravná opatření.
• Závislosti na dodavatelích s neúplnými smlouvami nebo slabými možnostmi odchodu.
• Významné nedostatky v opatřeních, odpovědné vlastníky a termíny nápravy.
• Rozhodnutí vyžadující financování, změnu dodavatele nebo výslovnou reakci na riziko.

U každého nedostatku by se měl rozlišovat regulatorní požadavek, současná provozní slabina a navrhovaná náprava. Chybějící záznam o schválení je něco jiného než záloha, kterou nelze obnovit. Obojí může vyžadovat kroky, ale s jinými vlastníky a prioritami.

Schválení plánu nápravy vedením není povolením k neomezenému odkládání použitelných povinností. Je-li nedostatek podstatný, zvažte vedle dlouhodobé opravy i okamžitá ochranná opatření, eskalaci a případné dopady na vztah s orgánem dohledu.

Postavte program kolem finančních funkcí

Inventář aktiv je nezbytný, plánování odolnosti by však mělo začínat službou, která musí pokračovat. Určete finanční funkci, jejího vlastníka v byznysu, důsledky narušení a systémy a poskytovatele, kteří ji podporují.

U platební služby zmapujte identity, cloudovou infrastrukturu, zpracování transakcí, monitorování a eskalaci u dodavatelů. Zahrňte i méně viditelné závislosti, jako jsou DNS, konektivita, privilegovaný přístup, šifrovací klíče a nástroje podpory. Alternativní produkční prostředí může být nepoužitelné, pokud závisí na téže selhané službě identit.

Výsledná mapa by měla každou funkci propojit s:

• Podpůrnými aplikacemi, infrastrukturou, informačními aktivy a externími službami.
• Relevantními smlouvami a vlastníky služeb.
• Cíli obnovy a analýzou dopadů na činnost, která je podporuje.
• Opatřeními pro detekci, reakci, obnovu a komunikaci.
• Testy, zjištěními a nevyřešenými riziky závislostí.

Mapu ověřte s provozními i obchodními týmy. Nákupní záznamy ukazují, co bylo zakoupeno; nemusí však ukazovat, jak služba dnes funguje.

Tento model použijte k uspořádání řízení rizik v oblasti IKT, řízení a hlášení incidentů, testování odolnosti a rizik spojených s třetími stranami v oblasti IKT. DORA obsahuje také ustanovení o dobrovolném sdílení informací o kybernetických hrozbách. Pokud se do něj zapojíte, definujte členství, důvěrnost, povolené použití a pravidla zacházení, místo abyste sdílení považovali za neomezenou výměnu údajů o incidentech.

Převeďte řízení rizik v oblasti IKT na financovanou práci

Ustanovení DORA o řízení rizik v oblasti IKT pokrývají identifikaci, ochranu a prevenci, detekci, reakci a obnovu, poučení a komunikaci. Rámec musí tyto činnosti propojovat, nikoli je ponechat jako oddělené sbírky politik.

Analýzu nedostatků začněte u zmapovaných funkcí. Ptejte se, zda řízení přístupu chrání jejich systémy, zda se řeší zranitelnosti, zda jsou změny řízeny, zda je zjišťována podezřelá aktivita a zda opatření pro obnovu odrážejí realistická selhání. Zvažte technické poruchy a provozní chyby stejně jako škodlivé útoky.

Pro každou podstatnou slabinu vytvořte záznam o nápravě s vlastníkem, dopadem na činnost, požadovaným krokem, kritérii dokončení a důkazem o uzavření. Na závislostech záleží: zlepšení postupů obnovy může vyžadovat změny v přístupu k zálohám, závazcích dodavatelů a školení pracovníků dříve, než bude možný úspěšný test.

Cíle obnovy by měly vycházet z obchodních potřeb a analýzy dopadů, nikoli z toho, co náhodou nabízí standardní úroveň služeb dodavatele. Pokud technické schopnosti cíl splnit nedokážou, musí vedení rozhodnout, zda zlepšit architekturu, změnit ujednání o službě, nebo přehodnotit provozní model. Cíl zapsaný v plánu kontinuity není důkazem obnovitelnosti.

Rozhodnutí o incidentech připravte dříve, než k narušení dojde

DORA vyžaduje, aby finanční subjekty řídily incidenty související s IKT a hlásily závažné incidenty příslušnému orgánu. Rámec stanoví články 17–23; podrobná klasifikační kritéria, prahové hodnoty, obsah hlášení a postupy upravují příslušné regulační technické a prováděcí normy.

Pro podrobný harmonogram hlášení se nespoléhejte na obecný kontrolní seznam incidentů. Udržujte aktuální matici hlášení, která uvádí použitelné normy, pokyny orgánu, kanál pro podání, fáze hlášení a výpočet lhůt. Určete odpovědnost za její aktualizaci.

Proces reakce by měl zajistit, aby šlo několik rozhodnutí provést i pod tlakem:

• Kdo zaznamenává časová razítka zjištění, posouzení a klasifikace?
• Kdo získává informace o dopadech od provozu a dodavatelů?
• Kdo rozhoduje, zda jsou splněna kritéria závažného incidentu?
• Kdo schvaluje a podává hlášení, včetně doby mimo běžnou pracovní dobu?
• Kdo řeší komunikaci se zákazníky a další příslušná oznámení?

Zdůvodnění klasifikace zaznamenejte i tehdy, když incident není hlášen jako závažný. Neúplný počáteční obraz by měl vést k novému posouzení, jakmile se objeví další informace, nikoli k trvalému předpokladu, že jde o méně významnou událost.

Závazky dodavatelů k oznamování by měly finančnímu subjektu ponechat dostatek času na posouzení a splnění vlastních povinností. Úkoly spojené s hlášením lze tam, kde je to dovoleno, outsourcovat, odpovědnost však zůstává na finančním subjektu.

Pokud závažný incident související s IKT ovlivní finanční zájmy klientů, DORA vyžaduje, aby finanční subjekty tyto klienty bez zbytečného odkladu informovaly o incidentu a o opatřeních přijatých ke zmírnění jeho nepříznivých účinků. Samostatně posuďte povinnosti týkající se porušení zabezpečení osobních údajů a další příslušná pravidla. Jedno narušení může vyvolat několik rozhodnutí o oznámení s různými adresáty a právními testy.

Testujte předpoklady, na které vedení spoléhá

Program testování digitální provozní odolnosti by měl být přiměřený a založený na riziku. Hodnocení zranitelností, scénářová cvičení, bezpečnostní testy a testy obnovy odpovídají na různé otázky; žádné z nich by se nemělo považovat za univerzální náhradu ostatních.

Simulační cvičení u stolu může prokázat, zda osoby s rozhodovací pravomocí rozumějí eskalaci. Nemůže však prokázat, že lze transakční data přesně obnovit. Penetrační test může odhalit zneužitelné slabiny, aniž by prokázal, že alternativní dodavatel dokáže službu převzít.

Pro každý test definujte funkci, scénář, rozsah, kritéria úspěchu, případně požadované zajištění nezávislosti a očekávané důkazy. Uchovávejte výsledky, zjištění, rozhodnutí o nápravě a výsledky opakovaných testů. Ověřte příslušné požadavky na pokrytí a četnost podle DORA a souvisejících norem, včetně případných výjimek nebo ustanovení o zjednodušeném rámci.

Penetrační testování na základě hrozeb (TLPT) je samostatným požadavkem orgánů dohledu pro vybrané finanční subjekty podle článku 26. Nejde o plošnou povinnost pro každý finanční podnik nebo dodavatele IKT.

Vedení by mělo přezkoumávat selhané předpoklady, nejen to, zda testy proběhly. Pokud cvičení odhalí, že obnova závisí na jediném nedostupném administrátorovi, výsledkem je provozní riziko vyžadující kroky, nikoli splněný milník testování.

Riziko třetích stran berte jako otázku kontinuity služeb

Podle DORA zůstává finanční subjekt odpovědný za své povinnosti i při využívání dodavatelů IKT. Články 28–30 propojují posouzení rizik třetích stran, smluvní ujednání, monitorování a plánování odchodu.

Udržujte registr i provozní obraz

Finanční subjekty musí vést registr informací o smluvních ujednáních týkajících se IKT na požadované individuální, subkonsolidované a konsolidované úrovni. Pro jeho strukturu použijte příslušné prováděcí normy. Nákupní tabulka nebo seznam schválených dodavatelů automaticky nestačí.

Registr porovnávejte se smlouvami, vlastnictvím služeb a mapami závislostí. Zachovávejte požadovaná rozlišení u služeb podporujících kritické nebo důležité funkce. Nový subdodavatel, místo poskytování služby nebo rozšířený rozsah mohou změnit rizikový obraz, i když název dodavatele zůstává stejný.

Smlouvy přezkoumávejte vůči skutečné službě

Posuďte příslušné smluvní požadavky, včetně popisu služeb, míst, ochrany údajů, přístupu k údajům a jejich obnovy, pomoci při incidentech, součinnosti, práv na ukončení a úrovní služeb. Ujednání podporující kritické nebo důležité funkce vyžadují další ustanovení, včetně příslušných ujednání o reportingu, kontinuitě, přístupu, kontrolách, auditu a odchodu.

Právní oddělení, nákup, technologie a vlastníci v byznysu by je měli přezkoumávat společně. Smluvní právo na audit může být v praxi obtížně uplatnitelné; přislíbené opatření pro obnovu nemusí pokrývat celý řetězec služeb zákazníka. Tato omezení identifikujte dříve, než ujednání přijmete.

Prověřte koncentraci a schopnost odchodu

Koncentrační riziko se neomezuje na nákup několika služeb od jedné firmy. Různí dodavatelé mohou spoléhat na tutéž cloudovou platformu, region, síť nebo subdodavatele. Posuďte nahraditelnost, složitost migrace a důsledky společného selhání.

Plán odchodu by měl řešit formáty dat, jejich vytěžení, přístup, závislosti migrace, podporu při přechodu, výmaz a kontinuitu během přesunu. U kritických nebo důležitých funkcí považujte testování a přezkum odchodu za věcnou práci, nikoli za psaní dokumentu.

Dodavatelé mohou připravit jednotný balíček záruk obsahující rozsah služby, hranice odpovědnosti, kontakty pro incidenty, důkazy o kontinuitě, informace o subdodávkách a smluvní pozice. Požadavky konkrétních zákazníků je přesto třeba přezkoumat; certifikát je nenahrazuje.

Pochopte, kde se DORA a NIS2 setkávají

DORA je nařízení EU s přímou použitelností. NIS2 je směrnice prováděná vnitrostátním právem, jejíž použitelnost závisí na odvětví, velikosti, službě a pravidlech zahrnutí. Lhůta pro její provedení do vnitrostátního práva uplynula 17. října 2024; organizace musí prověřit příslušnou vnitrostátní úpravu, místo aby předpokládaly jediný shodný provozní režim.

Čl. 1 odst. 2 nařízení DORA spolu s článkem 4 směrnice NIS2 stanoví odvětvově specifický vztah pro dotčené finanční subjekty v příslušných oblastech. Nevykládejte to jako pokyn ke zdvojování rovnocenných opatření pro řízení rizik a hlášení incidentů. Stejně tak nepředpokládejte, že tento vztah odstraňuje povinnosti každé společnosti ve finanční skupině nebo v jejím dodavatelském řetězci.

Poskytovatel řízených služeb, který obsluhuje banku, může potřebovat vlastní posouzení podle NIS2 a zároveň plnit smluvní závazky související s DORA. Matice povinností po jednotlivých subjektech by měla zaznamenávat právní základ, rozsah, orgán, cestu hlášení a požadované důkazy.

Sdílená opatření mohou podporovat DORA, ISO 27001, povinnosti v oblasti ochrany osobních údajů i záruky pro zákazníky, pokud se shoduje rozsah a důkazy. Přezkum přístupů nebo test obnovy využijte opakovaně tam, kde skutečně podporuje několik požadavků, a přitom zachovejte specifika finančního sektoru. Certifikát ISO 27001 neprokazuje soulad s DORA.

Liší se i vymáhání. Pravomoci dohledu a sankce vůči finančním subjektům podle DORA závisejí na jejích ustanoveních a příslušných vnitrostátních opatřeních; určení kritičtí poskytovatelé podléhají samostatnému režimu dozoru. Nerozpočtujte riziko podle údajné univerzální pokuty podle DORA. Posuďte relevantní právní expozici a provozní důsledky nedostatečné odolnosti.

Modelový příklad: přezkum závislostí platební služby

Představme si ilustrativní platební instituci, která využívá cloudovou platformu, poskytovatele identit a outsourcovanou monitorovací službu. Předpokládejme, že instituce spadá do působnosti DORA a provádění plateb je klasifikováno jako kritická nebo důležitá funkce.

První přezkum odhalí tři slabiny: produkční prostředí i prostředí pro obnovu sdílejí tutéž závislost na identitách; proces eskalace incidentů u dodavatele monitorování je nejasný; a plán odchodu z cloudu uvádí alternativního poskytovatele, aniž by prokazoval vytěžení dat a migraci.

Vedení zadá tři propojené pracovní balíčky:

Vlastník v byznysu ověří, zda zůstávají cíle obnovy plateb dosažitelné. Compliance ověří, že postupy hlášení a záznamy v registru odpovídají ujednáním. Vedení schválí potřebné financování a přezkoumá zbývající omezení.

Tento příklad sám o sobě soulad neprokazuje. Ukazuje, jak jedna funkce může odhalit rozhodnutí, která by v oddělených kontrolních seznamech politik, dodavatelů a testování zůstala skryta.

Zaveďte rytmus přezkumů založený na důkazech

DORA nemá žádný univerzální certifikační proces, který by nahrazoval průběžné povinnosti. Nezávislé ujištění může vedení poskytnout informace, připravenost však musí být prokázána fungujícími opatřeními, záznamy a v případě potřeby komunikací s orgánem dohledu.

Praktickým dalším krokem je vybrat jednu kritickou nebo důležitou funkci a sestavit k ní rozhodnutí o působnosti, mapu závislostí, posouzení rizik, smlouvy, postupy pro incidenty, výsledky testů a otevřené úkoly. Přezkoumejte, zda tyto záznamy vyprávějí konzistentní příběh.

Secani tento postup podporuje modelováním systémů a služeb, propojováním závislostí a udržováním požadavků, důkazů, vlastníků, úkolů a rozhodnutí z přezkumů v kontextu. Nahrajte stávající materiály k relevantním objektům, mezery převeďte na přidělenou práci a u návrhů a závěrů s podporou AI zachovejte výslovné lidské schválení.

Od této první funkce postupujte dál, jakmile budou jasné cesty vlastnictví a důkazů. Vedení by mělo vidět, co bylo prokázáno, co zůstává nejisté a jaké rozhodnutí je potřeba jako další.