DORA a cloud: exit strategie, registr informací a koncentrace rizika

Kde DORA stojí v říjnu 2026

Nařízení (EU) 2022/2554 o digitální provozní odolnosti finančního sektoru se podle České národní banky používá od 17. ledna 2025. Fáze „připravujeme se“ tedy skončila a dohled má první data, ze kterých může vycházet.

Tři události stojí za pozornost:

• 18. listopadu 2025 zveřejnily evropské orgány dohledu (EBA, EIOPA, ESMA) první seznam kritických poskytovatelů ICT (CTPP). Hodnotily systémový význam poskytovatele, jeho roli při podpoře kritických nebo důležitých funkcí a míru nahraditelnosti jeho služeb.
• 2. března 2026 uplynul termín, do kterého české finanční subjekty předkládaly ČNB registr informací ve druhém sběru; první proběhl v roce 2025.
• 3. června 2026 vyšla první výroční zpráva ESAs o závažných incidentech: za rok 2025 jich finanční subjekty v EU nahlásily 3 383, zhruba třetina měla původ v selhání třetí strany a přibližně třetina měla přeshraniční dopad.

Poslední číslo je pro tento článek podstatné. Závislost na dodavatelích není teoretické riziko z regulatorní příručky, ale původ přibližně každého třetího závažného incidentu.

Co přesně říkají články 28 až 30

Kapitola o riziku třetích stran má tři články, které se promítají přímo do architektury. Znění jednotlivých odstavců je dostupné na EUR-Lexu a přehledně po článcích například zde.

Článek 28: registr a strategie ukončení

• Odst. 3 ukládá vést a aktualizovat registr informací o všech smluvních ujednáních o využívání služeb ICT, na úrovni subjektu i na subkonsolidované a konsolidované úrovni. Nejde tedy jen o cloud ani jen o kritické služby.
• Odst. 4 vyžaduje před uzavřením smlouvy posoudit, zda služba podporuje kritickou nebo důležitou funkci, a vyhodnotit rizika včetně rizika koncentrace.
• Odst. 8 požaduje pro služby ICT podporující kritické nebo důležité funkce strategie ukončení. Subjekt musí být schopen smluvní vztah opustit bez narušení své činnosti, bez omezení plnění regulatorních požadavků a bez újmy na kontinuitě a kvalitě služeb klientům. Exit plány mají být komplexní, zdokumentované, dostatečně otestované a pravidelně přezkoumávané; subjekt má určit alternativní řešení a mít plán přechodu, který umožní službu i data převést k jinému poskytovateli nebo zpět do vlastní správy.

Článek 29: riziko koncentrace

Subjekt má u kritických nebo důležitých funkcí vyhodnotit, zda nevstupuje do vztahu s poskytovatelem, který není snadno nahraditelný, a zda nemá více smluv u téhož poskytovatele nebo u úzce propojených poskytovatelů. Má přitom zvážit přínosy a náklady alternativních řešení. Druhý odstavec míří na subdodavatelské řetězce, zejména ve třetích zemích.

Článek 30: povinný obsah smlouvy

Odst. 2 platí pro všechny smlouvy na služby ICT: úplný popis služeb, lokality (regiony nebo země), kde se služby poskytují a data zpracovávají, a ujednání o přístupu k datům, jejich obnově a vrácení ve snadno přístupném formátu. Odst. 3 přidává pro kritické nebo důležité funkce mimo jiné právo průběžného monitoringu a auditu, povinnost dodavatele účastnit se TLPT a strategie ukončení se stanovením povinného přiměřeného přechodného období.

Kritičtí poskytovatelé: co seznam mění a co ne

Na seznamu je 19 poskytovatelů. Z pohledu cloudu a infrastruktury jsou to Amazon Web Services EMEA, Microsoft Ireland Operations, Google Cloud EMEA, Oracle Nederland, IBM, SAP, Deutsche Telekom, Orange, Colt, Equinix a InterXion; dále integrátoři a outsourcingové firmy Accenture, Capgemini, Kyndryl, NTT DATA a Tata Consultancy Services a poskytovatelé finančních dat a softwaru Bloomberg, LSEG Data and Risk a FIS.

Určení znamená přímý dohled ESAs nad poskytovatelem. Hlavní orgán dohledu může při neplnění uložených opatření nařídit penále až 1 % průměrného denního celosvětového obratu, a to denně po dobu nejvýše šesti měsíců (čl. 35 odst. 6–8).

Pro finanční subjekt jsou důležité dva důsledky.

• Povinnosti z čl. 28–30 se nemění. Platí bez ohledu na to, zda je dodavatel na seznamu. Poskytovatelé podle komentáře Morgan Lewis mohou při vyjednávání argumentovat, že přímý dohled sám o sobě dává zákazníkům určitou míru ujištění. Čl. 28 odst. 1 písm. a) ovšem stanoví, že finanční subjekt zůstává za plnění všech povinností podle nařízení vždy plně odpovědný, a totéž pro poskytovatele pod přímým dohledem ESAs uvádí i citované shrnutí PwC Legal.
• Exit může přijít zvenčí. Podle čl. 42 odst. 6 může příslušný orgán jako krajní opatření požadovat, aby finanční subjekty dočasně pozastavily využívání služby kritického poskytovatele, případně smlouvu zcela nebo zčásti ukončily. Je to krajní scénář, ale právě pro něj má exit plán existovat.

Registr informací jako inventář závislostí

V Česku se registr předkládá přes systém SDAT. ČNB uvádí, že výkazy jsou vykazujícím osobám generovány automaticky a lze je dodat jako soubor XBRL-CSV, importem z excelové šablony nebo vyplněním formuláře; subjekt musí mít a uvést vlastní kód LEI. Úvěrové instituce, pojišťovny a zajišťovny předkládají hlášení na nejvyšší úrovni konsolidace v rámci EU. Šablony určuje prováděcí nařízení (EU) 2024/2956, na jehož závazné kategorie služeb upozorňuje i česká odborná praxe.

Typický problém není formát, ale zdroj dat. Registr vyplňovaný jednou ročně ze smluvní evidence se rozejde s tím, co skutečně běží. Platformní tým přitom většinu podkladů už má: seznam cloudových účtů a subscription, regiony, použité managed služby, SaaS integrace v pipeline.

Praktické řešení je vést inventář závislostí vedle kódu a registr z něj odvozovat. Struktura může být jednoduchá:

service: platebni-brana
function_critical: true          # kritická nebo důležitá funkce
owner: tym-platby
dependencies:
  - provider: Microsoft Ireland Operations Limited
    contract_ref: SML-2024-017
    services: [AKS, Azure SQL Managed Instance, Key Vault]
    regions: [westeurope, northeurope]
    data: [osobni-udaje, transakce]
    substitutability: stredni    # nízká / střední / vysoká
    exit_plan: docs/exit/platebni-brana.md
    exit_last_tested: 2026-05-14
  - provider: dodavatel-monitoringu-saas
    contract_ref: SML-2025-003
    services: [metriky, alerting]
    subcontractors: [AWS eu-central-1]
    substitutability: vysoka

Pole subcontractors není navíc. Nařízení v přenesené pravomoci (EU) 2025/532 o subdodávkách, vyhlášené 2. července 2025 a platné od 22. července 2025, chce, aby smlouva výslovně určila, které služby lze dále subdodávat, a aby byl finanční subjekt o podstatných změnách v řetězci předem informován s právem vznést námitku nebo smlouvu ukončit. SaaS nástroj, který sám běží u hyperscalera, tak vstupuje i do úvahy o koncentraci.

Exit plán, který projde testem

Nařízení neříká, jak má test vypadat. Rozumný výklad je, že „dostatečně otestovaný“ znamená doložitelný důkaz, že klíčové kroky přechodu fungují, nikoli plnou migraci nanečisto každý rok. Kde dohled laťku nastaví, se teprve ukáže; opatrnější je mít víc než stolní cvičení.

Přenositelnost: kde končí a co stojí

Kontejnery a Kubernetes přenášejí výpočetní vrstvu poměrně dobře. Hůř se přenáší to okolo: IAM, síťování, managed databáze, fronty, serverless funkce a observabilita. Terraform nebo OpenTofu samy přenositelnost nezaručí, protože moduly jsou psané proti konkrétnímu provideru. Zaručí ale něco jiného a pro exit zásadního: úplný a čitelný popis toho, co je potřeba jinde postavit. K disciplíně kolem infrastruktury jako kódu viz bezpečnost IaC.

Realistický postup je rozdělit komponenty kritické funkce do tří skupin: přenositelné beze změny (kontejnerizované aplikace), přenositelné s náhradou (managed PostgreSQL za jinou PostgreSQL službu) a nepřenositelné bez přepisu (proprietární služby). U třetí skupiny patří do exit plánu poctivý odhad pracnosti, ne tvrzení, že to půjde.

Zálohy mimo poskytovatele

Článek 12 vyžaduje zálohovací politiky, postupy obnovy a jejich pravidelné testování; při obnově dat vlastními systémy mají být použity systémy fyzicky a logicky oddělené od zdrojového systému. Výslovnou povinnost držet zálohy u jiného poskytovatele nařízení neobsahuje. Pro exit je ale kopie mimo účet a mimo řídicí rovinu poskytovatele jediný způsob, jak mít data k dispozici ve scénáři, kdy je služba nedostupná nebo pozastavená.

Tři věci rozhodují, zda je taková záloha použitelná: formát čitelný bez služby poskytovatele (logický dump, Parquet, ne jen snapshot), šifrovací klíče pod vlastní kontrolou a obnova skutečně vyzkoušená v cílovém prostředí včetně změřeného času.

TLPT a dodavatelský řetězec

Penetrační testování na základě hrozeb se netýká všech. Článek 26 ho ukládá vybraným subjektům nejméně jednou za tři roky, na živých produkčních systémech a s pokrytím několika nebo všech kritických funkcí, včetně těch, které zajišťuje dodavatel. Odpovědnost zůstává na finančním subjektu. Pokud by účast poskytovatele ohrozila jeho ostatní zákazníky, připouští odst. 4 sdružené testování pro více subjektů.

ČNB přistoupila k rámci TIBER-EU v září 2024 a v březnu 2025 schválila Implementačního průvodce standardu TIBER-EU pro český finanční trh (TIBER-CZ). Podle ČNB se TLPT vztahuje na nejvýznamnější finanční instituce.

Co z toho plyne pro IT dodavatele

• Počítejte s tím, že zákazník bude chtít do smlouvy prvky z čl. 30: lokality zpracování, auditní práva, součinnost při incidentech, vrácení dat a přechodné období.
• Mějte připravený seznam vlastních subdodavatelů a proces, jak změny oznamujete předem.
• Popište, jak zákazník dostane svá data a konfiguraci ve strojově čitelné podobě. Kdo to umí předvést, má kratší nákupní proces.
• Pokud podporujete kritickou funkci, vyjasněte si předem podmínky účasti na TLPT: rozsah, okna, izolaci ostatních zákazníků.

Kdy doporučení neplatí a co udělat hned

DORA nenařizuje multi-cloud. Článek 29 chce posouzení koncentrace a zvážení přínosů a nákladů alternativ, ne provoz ve dvou cloudech. Aktivní multi-cloud zdvojuje provozní znalosti, zvětšuje plochu útoku a u malého týmu může odolnost reálně snížit. Zdokumentované a obhájené rozhodnutí zůstat u jednoho poskytovatele s otestovaným exitem je legitimní výsledek.

Stejně tak neplatí, že je nutné se vyhnout managed službám. Vlastní provoz databáze kvůli přenositelnosti přesouvá riziko od dodavatele k vlastním lidem. Smysl má chtít přenositelnost tam, kde je levná (kontejnery, otevřené protokoly a formáty), a jinde vědomě přijmout závislost a zapsat cenu exitu.

A exit strategie podle čl. 28 odst. 8 se vztahuje na kritické nebo důležité funkce. Interní wiki nepotřebuje stejný plán jako platební brána; registr informací ale pokrývá obojí.

Poslední bod souvisí s tím, jak je postavený dohled nad provozem; k tomu viz bezpečnostní monitoring a logování.

Klíčové poznatky

• Exit plán musí být otestovaný. Čl. 28 odst. 8 chce plány komplexní, zdokumentované, dostatečně otestované a pravidelně revidované; smluvní doložka nestačí.
• Seznam 19 kritických poskytovatelů nic neulehčuje. Dohled ESAs nad AWS, Microsoftem nebo Google Cloudem nenahrazuje povinnosti finančního subjektu a čl. 42 odst. 6 připouští i nařízené pozastavení služby.
• Registr informací má vznikat z inventáře, ne z paměti. Závislosti vedené vedle kódu udrží registr aktuální i mezi ročními sběry.
• Subdodavatelé se počítají. Nařízení (EU) 2025/532 platí od 22. července 2025 a řetězec subdodávek vstupuje do posouzení koncentrace.
• Multi-cloud povinný není. Čl. 29 vyžaduje posouzení a zvážení nákladů a přínosů; obhájené rozhodnutí pro jednoho poskytovatele je v pořádku.
• Třetí strany jsou reálný zdroj incidentů. Zhruba třetina z 3 383 závažných incidentů nahlášených za rok 2025 měla původ u třetí strany.