DORA 2026: plán pro rizika IKT, dodavatele a TLPT

Vyhledávací panika kolem DORA 2026 ve skutečnosti není o regulaci, ale o důkazech

Je pondělí 08:15 a CISO ve středně velké platební instituci má v prohlížeči otevřené tři karty: „DORA RTS/ITS checklist“, „DORA ICT third-party register template“ a „TLPT requirements financial entities“.

Manažer souladu se už zeptal, zda mají podklady pro správní orgán obsahovat nejnovější postup klasifikace incidentů. Nákup chce zařadit novou cloudovou analytickou platformu. COO požaduje ujištění, že hlavní poskytovatel bankovního SaaS nemá skrytou expozici vůči subdodavatelům mimo EU. Interní audit žádá kalendář testování. Právní oddělení se ptá, zda byly lhůty pro oznamování porušení zabezpečení podle GDPR sladěny s hlášením incidentů podle DORA.

Nikdo neklade teoretickou otázku. Všichni se ptají: „Dokážeme to doložit do pátku?“

To je skutečný problém DORA 2026. Většina finančních subjektů chápe hlavní povinnosti: řízení rizik v oblasti IKT, hlášení incidentů souvisejících s IKT, testování digitální provozní odolnosti, řízení rizik IKT třetích stran a posílený dohled nad kritickými poskytovateli služeb IKT. Nejtěžší je převést Regulatory Technical Standards, Implementing Technical Standards a povinnosti na úrovni článků do řízené, opakovatelné a auditovatelné praxe.

Digital Operational Resilience Act vyžaduje, aby finanční subjekty udržovaly robustní schopnosti řízení rizik v oblasti IKT, politiky pro řízení a hlášení incidentů souvisejících s IKT, testování systémů, kontrol a procesů IKT a strukturovaný dohled nad poskytovateli služeb IKT z řad třetích stran. Zároveň vyžaduje proporcionalitu. Menší investiční společnost a velká bankovní skupina nepotřebují totožné důkazní modely, ale obě musí prokázat, že jejich přístup odpovídá jejich velikosti, rizikovému profilu, složitosti a kritickým funkcím.

Projekty DORA obvykle selhávají z jednoho ze tří důvodů. Zaprvé organizace pojímá DORA jako právní mapovací cvičení, nikoli jako provozní model. Zadruhé je dodavatelské riziko dokumentováno jako seznam dodavatelů, nikoli jako závislost, nahraditelnost a riziko koncentrace. Zatřetí se testování chápe jako každoroční penetrační test, nikoli jako program odolnosti zahrnující skeny zranitelností, scénářové testování, cvičení incidentů a tam, kde je to relevantní, penetrační testování řízené hrozbami, běžně vyhledávané jako TLPT.

Lepším přístupem je vybudovat jeden důkazní systém, který propojuje politiky, registry, vlastníky, rizika, incidenty, dodavatele, testování, obnovu a přezkoumání vedením. Právě zde Zenith Blueprint od Clarysec, hotové politiky a Zenith Controls pomáhají finančním subjektům proměnit DORA z termínu splnění povinností v provozní rytmus.

Začněte provozním modelem DORA, ne tabulkou RTS/ITS

Mnoho týmů začíná tabulkou se seznamem článků DORA a požadavků RTS/ITS. Je to užitečné, ale nestačí to. Tabulka může říct, co musí existovat. Nepřiřadí vlastníky, nedefinuje frekvenci přezkumu, neuchová důkazy ani neprokáže, že opatření skutečně funguje.

V dokumentu Zenith Blueprint: 30krokový plán auditora Clarysec toto řeší ve fázi Řízení rizik, v kroku 14, Politiky ošetření rizik a regulatorní křížové odkazy:

„DORA: U společností finančního sektoru DORA vyžaduje rámec řízení rizik v oblasti IKT, který je velmi úzce sladěn s tím, co jsme provedli: identifikovat rizika, zavést kontroly a politiky a testovat je. DORA zároveň klade důraz na reakci na incidenty a hlášení incidentů a na dohled nad poskytovateli služeb IKT z řad třetích stran.“

Praktické sdělení je jednoduché: nebudujte „soulad s DORA“ jako paralelní byrokracii. Vybudujte rizikově orientovanou vrstvu správy IKT, která mapuje požadavky DORA na politiky, registry, vlastníky kontrol, záznamy o testování, důkazy od dodavatelů a přezkoumání vedením.

Praktický provozní model DORA má mít pět důkazních pilířů:

U regulovaných finančních subjektů tato struktura převádí implementaci RTS/ITS do auditně připraveného důkazního systému. U subjektů ve zjednodušeném režimu řízení rizik v oblasti IKT lze stejný model zmenšit na méně dokumentů a jednodušší registry. Základní disciplíny zůstávají stejné: identifikovat, chránit, detekovat, reagovat, obnovit, testovat a řídit dodavatele.

Řízení rizik v oblasti IKT: registr je řídicí centrum

Očekávání DORA v oblasti řízení rizik v oblasti IKT vyžadují, aby finanční subjekty identifikovaly, klasifikovaly a řídily rizika IKT napříč systémy, daty, procesy, kritickými nebo důležitými funkcemi a závislostmi na třetích stranách.

Častým selháním není absence registru rizik. Problémem je, že registr není propojen s dodavateli, aktivy, incidenty a testy. DORA neocení dokonale vypadající tabulku, pokud nevysvětluje, proč vysoce rizikový dodavatel nemá plán ukončení spolupráce nebo proč kritická zákaznická platební platforma nebyla testována.

SME Politika řízení rizik od Clarysec poskytuje menším finančním subjektům stručný důkazní základ:

„Každá položka rizika musí obsahovat: popis, pravděpodobnost, dopad, skóre, vlastníka a plán ošetření rizik.“
Ze sekce „Požadavky na správu a řízení“, ustanovení politiky 5.1.2.

Pro větší finanční subjekty vyžaduje Enterprise Politika řízení rizik od Clarysec formálnější proces:

„Formální proces řízení rizik musí být udržován v souladu s ISO/IEC 27005 a ISO 31000 a musí pokrývat identifikaci rizik, analýzu rizik, hodnocení rizik, ošetření rizik, monitorování rizik a komunikaci rizik.“
Ze sekce „Požadavky na správu a řízení“, ustanovení politiky 5.1.

Na tomto rozlišení záleží. DORA je proporcionální, ale proporcionalita neznamená neformálnost. Malá platební firma může používat zjednodušený registr, zatímco bankovní skupina může používat integrované nástroje GRC. V obou případech se auditor stále zeptá: Jaká jsou vaše rizika IKT? Kdo je vlastní? Jaký je plán ošetření? Jaké důkazy dokládají pokrok? Jak dodavatelé a kritické funkce ovlivňují skóre?

Silný registr rizik IKT pro DORA má obsahovat tato pole:

Praktické cvičení spočívá v tom, že vezmete jednu kritickou službu IKT, například platformu pro monitorování transakcí hostovanou v cloudu, a během 20 minut vytvoříte položku rizika. Popište scénář selhání nebo kompromitace, ohodnoťte pravděpodobnost a dopad, přiřaďte vlastníka, identifikujte související dodavatele, definujte plán ošetření rizik a propojte položku s důkazy, jako je náležitá péče vůči dodavateli, SLA, incidentní doložky, BIA, výsledky testů DR, monitorovací dashboardy a přezkum přístupových práv.

Tato jediná položka se stává vláknem propojujícím řízení rizik v oblasti IKT podle DORA, dohled nad třetími stranami, detekci incidentů, kontinuitu a testování. Tak se z registru rizik stává řídicí centrum, nikoli kartotéka.

Připravenost na RTS/ITS: mapujte povinnosti na politiky, ne na sliby

Praktický vyhledávací výraz „DORA RTS/ITS checklist“ obvykle znamená „Jaké dokumenty budou orgány dohledu očekávat?“ Finanční subjekty by se měly vyhnout proklamování souladu prostřednictvím obecných prohlášení. Potřebují mapování, které váže každou povinnost na politiku, opatření, vlastníka a položku důkazu.

SME Politika právního a regulatorního souladu od Clarysec zavádí jednoduchou kotvu správy:

„Generální ředitel musí udržovat jednoduchý, strukturovaný registr souladu, který uvádí:“
Ze sekce „Požadavky na správu a řízení“, ustanovení politiky 5.1.1.

Pro DORA 2026 má váš registr souladu obsahovat:

• Povinnost DORA nebo oblast požadavků RTS/ITS.
• Použitelnost včetně odůvodnění proporcionality.
• Odkaz na politiku nebo postup.
• Vlastníka opatření.
• Umístění důkazů.
• Frekvenci přezkumu.
• Otevřené mezery a termín nápravy.
• Stav reportingu správnímu orgánu nebo vedení.

To odpovídá přístupu Zenith Blueprint, krok 14: mapovat regulatorní požadavky na opatření a politiky ISMS tak, aby nic nepropadlo mezi trhlinami. Místo otázky „Jsme v souladu s DORA?“ se vedení může ptát: „Které důkazy DORA jsou po termínu, kterým kritickým dodavatelům chybí plány ukončení spolupráce a které testovací aktivity dosud nevytvořily důkazy o nápravě?“

Riziko IKT třetích stran: koncentrace, nahraditelnost a subdodavatelé

DORA změnila diskusi o dodavatelích ve finančních službách. Už nestačí ptát se, zda má poskytovatel bezpečnostní certifikaci, pojištění nebo smlouvu o zpracování osobních údajů. Finanční subjekty musí hodnotit, zda poskytovatel vytváří riziko koncentrace, zda jej lze reálně nahradit, zda více kritických služeb závisí na jednom dodavateli nebo souvisejících dodavatelích a zda subdodávky zavádějí další právní expozici nebo expozici vůči narušení odolnosti.

Právě to mnoha CISO nedá spát. Společnost může spoléhat na jednoho hlavního poskytovatele cloudových služeb pro zpracování transakcí, datovou analytiku, zákaznické portály a interní spolupráci. Pokud tento poskytovatel utrpí dlouhodobý výpadek, regulatorní spor nebo selhání subdodavatele, otázka nezní jen „Máme smlouvu?“ Otázka zní: „Dokážeme pokračovat v kritických službách, komunikovat se zákazníky a prokázat, že jsme závislosti rozuměli ještě před jejím selháním?“

SME Bezpečnostní politika dodavatelů a poskytovatelů služeb třetích stran od Clarysec stanoví základ:

„Registr dodavatelů musí udržovat a aktualizovat administrativní kontaktní osoba nebo kontaktní osoba pro nákup. Musí obsahovat:“
Ze sekce „Požadavky na správu a řízení“, ustanovení politiky 5.4.

Pro enterprise programy jde Politika řízení rizik závislostí na dodavatelích od Clarysec hlouběji do závislostí a nahraditelnosti specifických pro DORA:

„Registr závislostí na dodavatelích: kancelář pro řízení dodavatelů (VMO) musí udržovat aktuální registr všech kritických dodavatelů, včetně údajů, jako jsou poskytované služby/produkty; zda je dodavatel jediným zdrojem dodávky; dostupní alternativní dodavatelé nebo nahraditelnost; aktuální smluvní podmínky; a posouzení dopadu, pokud by dodavatel selhal nebo byl kompromitován. Registr musí jasně identifikovat dodavatele s vysokou mírou závislosti, například ty, pro které neexistuje rychlá alternativa.“
Ze sekce „Požadavky na implementaci“, ustanovení politiky 6.1.

To jsou dodavatelské důkazy, které projektům DORA často chybí. Registr dodavatelů říká, kdo je dodavatel. Registr závislostí říká, co se stane, když dodavatel selže.

Zenith Blueprint, fáze Opatření v praxi, krok 23, Organizační opatření, poskytuje praktický postup pro dohled nad dodavateli. Doporučuje sestavit úplný seznam dodavatelů, klasifikovat dodavatele podle přístupu k systémům, datům nebo provoznímu řízení, ověřovat, že bezpečnostní očekávání jsou zakotvena ve smlouvách, řídit subdodavatelská a navazující rizika, definovat postupy změn a monitorování a vytvořit proces hodnocení cloudových služeb.

V Zenith Controls: Průvodce křížovým souladem je opatření ISO/IEC 27002:2022 5.21, řízení bezpečnosti informací v dodavatelském řetězci IKT, mapováno jako preventivní opatření podporující důvěrnost, integritu a dostupnost. Je spojeno s bezpečností dodavatelských vztahů a konceptem kybernetické bezpečnosti Identify. Propojuje se s bezpečným inženýrstvím, bezpečným programováním, řízením přístupu, bezpečnostním testováním, sběrem důkazů, bezpečným životním cyklem vývoje a outsourcovaným vývojem.

Přesně to je realita dohledu nad třetími stranami podle DORA. Dodavatelské riziko není jen otázkou nákupu. Dotýká se architektury, vývoje, reakce na incidenty, řízení přístupu, kontinuity činností a právních záležitostí.

Z pohledu křížového souladu Zenith Controls mapuje bezpečnost dodavatelského řetězce IKT na GDPR Articles 28 and 32, protože zpracovatelé a dílčí zpracovatelé musí být vybíráni a dozorováni s odpovídajícími technickými a organizačními opatřeními (TOM). Podporuje očekávání NIS2 v oblasti zabezpečení dodavatelského řetězce, včetně Article 21 pro opatření řízení rizik kybernetické bezpečnosti a Article 22 pro koordinovaná posouzení rizik dodavatelského řetězce. Silně se mapuje na DORA Articles 28, 29 and 30, kde jsou ústředními tématy rizika IKT třetích stran, riziko koncentrace, sub-outsourcing a smluvní ustanovení.

Podpůrné normy důkazy posilují. ISO/IEC 27036-3:2021 podporuje pořizování IKT a bezpečnost výběru dodavatelů. ISO/IEC 20243:2018 podporuje integritu důvěryhodných technologických produktů a zabezpečení dodavatelského řetězce. ISO/IEC 27001:2022 to propojuje s ošetřením rizik a dodavatelskými opatřeními Annex A.

Hlášení incidentů: vybudujte eskalační řetězec před incidentem

Hlášení incidentů podle DORA není jen o podání oznámení. Jde o detekci, klasifikaci, eskalaci, komunikaci a učení se z incidentů souvisejících s IKT. Finanční subjekty musí udržovat procesy pro řízení a hlášení incidentů IKT s definovanými rolemi, klasifikačními kritérii, oznamovacími trasami a analýzou po incidentu.

SME Politika reakce na incidenty od Clarysec propojuje časové lhůty reakce na incidenty s právními požadavky:

„Lhůty reakce, včetně obnovy dat a oznamovacích povinností, musí být dokumentovány a sladěny s právními požadavky, například s 72hodinovou lhůtou GDPR pro oznámení porušení zabezpečení osobních údajů.“
Ze sekce „Požadavky na správu a řízení“, ustanovení politiky 5.3.2.

Pro enterprise prostředí přidává Politika reakce na incidenty od Clarysec pohled eskalace regulovaných dat:

„Pokud incident vede k potvrzené nebo pravděpodobné expozici osobních údajů nebo jiných regulovaných dat, právní oddělení a DPO musí posoudit použitelnost:“
Ze sekce „Požadavky na implementaci politiky“, ustanovení politiky 6.4.1.

Citace končí v místě spouštěče, což je přesně bod, kde mnoho incidentních procesů selhává. Pokud je spouštěč nejasný, týmy diskutují o oznamovacích povinnostech, zatímco lhůta už běží.

Zenith Blueprint, fáze Opatření v praxi, krok 16, Opatření týkající se osob II, zdůrazňuje hlášení incidentů řízené personálem. Zaměstnanci, dodavatelé a zainteresované strany musí vědět, jak rozpoznat a hlásit potenciální bezpečnostní incidenty prostřednictvím jednoduchých kanálů, například vyhrazené schránky, portálu nebo linky. Blueprint to propojuje s GDPR Article 33, NIS2 Article 23 a DORA Article 17, protože regulatorní oznamování začíná interním povědomím a eskalací.

V Zenith Controls je opatření ISO/IEC 27002:2022 5.24, plánování a příprava řízení incidentů informační bezpečnosti, mapováno jako nápravné opatření podporující důvěrnost, integritu a dostupnost, sladěné s Respond a Recover. Přímo se váže na hodnocení událostí, učení se z incidentů, protokolování a monitorování, bezpečnost během narušení, kontinuitu informační bezpečnosti a kontakt s orgány. Průvodce toto mapuje na DORA Articles 17 to 23 pro řízení, klasifikaci a hlášení incidentů souvisejících s IKT a dobrovolné oznamování kybernetických hrozeb, GDPR Articles 33 and 34 pro oznámení porušení zabezpečení a NIS2 Article 23 pro oznamování incidentů.

Proces incidentů připravený na DORA má zahrnovat:

• Jasné kanály příjmu hlášení incidentů.
• Triáž událostí a klasifikační kritéria.
• Eskalační postup pro významné incidenty související s IKT.
• Rozhodovací body pro právní oddělení, DPO a regulatorní oznámení.
• Spouštěče oznamování incidentů dodavatelům.
• Požadavky na uchování důkazů.
• Pravidla komunikace s výkonným vedením a správním orgánem.
• Přezkoumání po incidentu a získané poznatky.
• Vazbu na aktualizace registru rizik a nápravu opatření.

Podpůrné normy přidávají strukturu. ISO/IEC 27035-1:2023 poskytuje zásady plánování a přípravy pro řízení incidentů. ISO/IEC 27035-2:2023 podrobně popisuje kroky zvládání incidentů. ISO/IEC 22320:2018 podporuje velení, řízení a strukturovanou krizovou komunikaci. To je důležité, když se výpadek IKT stane krizí s dopadem na zákazníky a subjekt musí prokázat, že rozhodnutí byla včasná, koordinovaná a podložená důkazy.

Testování digitální provozní odolnosti a TLPT: nedovolte, aby se test stal incidentem

Testování patří mezi nejvyhledávanější témata DORA 2026, protože je současně technické i náročné na správu. Finanční subjekty musí testovat systémy, kontroly a procesy IKT. U určených subjektů se pokročilé testování, jako je TLPT, stává ústředním požadavkem podle DORA Article 26.

Auditní otázka nezní jen „Testovali jste?“ Zní: „Byl test založený na riziku, autorizovaný, bezpečný, tam, kde je vyžadováno, nezávislý, napravený a propojený s cíli odolnosti?“

Enterprise Politika bezpečnostního testování a red teamingu od Clarysec jasně definuje minimální program testování:

„Typy testů: Program bezpečnostního testování musí minimálně zahrnovat: (a) skenování zranitelností, sestávající z automatizovaných týdenních nebo měsíčních skenů sítí a aplikací za účelem identifikace známých zranitelností; (b) penetrační testování, sestávající z manuálního hloubkového testování konkrétních systémů nebo aplikací kvalifikovanými testery za účelem identifikace komplexních slabin; a (c) cvičení red teamu, sestávající ze scénářových simulací skutečných útoků, včetně sociálního inženýrství a dalších taktik, za účelem otestování schopností organizace detekovat a reagovat jako celek.“
Ze sekce „Požadavky na implementaci“, ustanovení politiky 6.1.

To je most mezi rutinním testováním a vyspělostí TLPT. Skenování zranitelností nachází známé slabiny. Penetrační testování ověřuje zneužitelnost. Red teaming testuje detekci a reakci jako systém. TLPT tam, kde je relevantní, musí být součástí řízeného programu testování s kontrolou rozsahu, bezpečnostními pravidly, řízením rizik produkčního prostředí, zachycením důkazů a sledováním nápravy.

Zenith Blueprint, fáze Opatření v praxi, krok 21, se zabývá ochranou informačních systémů během auditu a testování. Upozorňuje, že audity, penetrační testy, forenzní přezkumy a provozní hodnocení mohou zavádět riziko, protože mohou zahrnovat zvýšený přístup, invazivní nástroje nebo dočasné změny chování systémů. Blueprint tuto oblast mapuje na GDPR Article 32, očekávání DORA ohledně testování digitální provozní odolnosti, otázky kontinuity podle NIS2 a postupy COBIT 2019 pro bezpečné provádění auditů a hodnocení.

V Zenith Controls je opatření ISO/IEC 27002:2022 5.35, nezávislý přezkum bezpečnosti informací, mapováno jako preventivní a nápravné opatření podporující důvěrnost, integritu a dostupnost. Váže se na dodržování politik, odpovědnost vedení, učení se z incidentů, ochranu záznamů, mazání informací, protokolování a monitorování. Pro DORA jsou relevantní povinnosti testování především Articles 24 to 27, včetně Article 26 pro TLPT. To podporuje také GDPR Article 32(1)(d), který vyžaduje pravidelné testování a hodnocení technických a organizačních opatření, a NIS2 Article 21, který vyžaduje opatření pro řízení rizik kybernetické bezpečnosti.

Balíček připravenosti na DORA TLPT má obsahovat:

Klíčové poučení DORA je, že důkazy z testování nesmí skončit zprávou. Auditoři se budou ptát, zda byla zjištění ohodnocena podle rizika, přiřazena, napravena a znovu otestována. Mohou také ověřovat, zda testování pokrývalo kritické nebo důležité funkce, nikoli pouze aktiva dostupná z internetu.

Kontinuita činností a obnova po havárii: odolnost musí fungovat provozně

DORA je právní předpis o digitální provozní odolnosti. Obnova je stejně důležitá jako prevence. Zdokumentovaný rámec rizik IKT nepomůže, pokud výpadek platební platformy odhalí, že cílové doby obnovy nebyly nikdy testovány, kontaktní stromy dodavatelů jsou zastaralé a krizový tým se nedokáže shodnout, kdo komunikuje se zákazníky.

SME Politika kontinuity činností a obnovy po havárii od Clarysec stanoví jasný základ:

„Organizace musí alespoň jednou ročně testovat jak svůj BCP, tak schopnosti DR. Testy musí zahrnovat:“
Ze sekce „Požadavky na implementaci politiky“, ustanovení politiky 6.4.1.

Enterprise Politika kontinuity činností a obnovy po havárii začíná dopadem na činnost:

„Analýza dopadů na činnost (BIA) musí být provedena alespoň jednou ročně pro všechny kritické obchodní jednotky a přezkoumána při významných změnách systémů, procesů nebo závislostí. Výstupy BIA musí definovat:“
Ze sekce „Požadavky na správu a řízení“, ustanovení politiky 5.2.

Pro DORA má být BIA propojena s aktivy IKT, dodavateli, reakcí na incidenty a testováním. Pokud BIA identifikuje „zákaznické platby“ jako kritickou funkci, registr závislostí na dodavatelích má identifikovat zpracovatele, cloudové služby a síťové poskytovatele, kteří ji podporují. Registr rizik má obsahovat scénáře selhání. Plán testování má zahrnovat validaci odolnosti. Plán reakce na incidenty má obsahovat eskalaci a komunikaci. Test DR má vytvářet důkazy, nikoli jen zápis ze schůzky.

Právě tato dohledatelnost mění soulad s DORA v systém provozní odolnosti.

Křížový soulad: jedna sada důkazů, mnoho auditních otázek

Finanční subjekty se s DORA setkávají málokdy izolovaně. Často mají povinnosti podle GDPR, expozici vůči NIS2, smluvní bezpečnostní závazky, cíle ISO/IEC 27001:2022, požadavky interního auditu, náležitou péči zákazníků, očekávání SOC a reporting rizik správním orgánům. Řešením není vytvářet oddělená důkazní sila. Řešením je vybudovat důkazní model pro křížový soulad.

Zenith Controls je kompas křížového souladu od Clarysec. Nevymýšlí nové povinnosti. Mapuje oficiální normy a rámce, aby organizace rozuměly tomu, jak jedna oblast opatření podporuje více výsledků souladu.

To je důležité pro rozpočet i správu. CISO může správnímu orgánu vysvětlit, že zlepšení klasifikace incidentů podporuje hlášení podle DORA, oznamování porušení zabezpečení podle GDPR, zvládání incidentů podle NIS2 a interní odolnost. Vedoucí nákupu může odůvodnit mapování závislostí na dodavatelích tím, že podporuje riziko koncentrace podle DORA, náležitou péči vůči zpracovatelům podle GDPR a zabezpečení dodavatelského řetězce podle NIS2. Vedoucí testování může ukázat, že cvičení red teamu a nezávislé přezkumy podporují testování podle DORA, hodnocení kontrol podle GDPR a širší ujištění.

Auditní pohled: jak hodnotitelé ověří vaše důkazy DORA

Připravenost na DORA se stává reálnou ve chvíli, kdy někdo požádá o důkazy. Různí auditoři a hodnotitelé budou ke stejnému tématu přistupovat z různých úhlů.

Auditor orientovaný na ISO/IEC 27001:2022 začne logikou ISMS: rozsah, posouzení rizik, ošetření rizik, použitelnost opatření Annex A, interní audit, přezkoumání vedením a důkazy, že kontroly jsou implementovány. U bezpečnosti dodavatelského řetězce IKT se podívá na politiky, klasifikaci dodavatelů, smluvní doložky, náležitou péči a průběžné monitorování. U řízení incidentů zkontroluje plán, role, eskalační trasy, nástroje a záznamy. U testování bude očekávat plánované intervaly, nezávislost tam, kde je vhodná, nápravu a vstupy do přezkoumání vedením.

Auditní pohled ISO/IEC 19011:2018 se zaměřuje na provedení auditu. V Zenith Controls auditní metodika pro bezpečnost dodavatelského řetězce IKT uvádí, že auditoři zkoumají nákupní politiky, šablony RFP a procesy řízení dodavatelů, aby ověřili, že bezpečnostní požadavky specifické pro IKT jsou zakotveny od pořízení až po vyřazení. U řízení incidentů auditoři zkoumají plán reakce na incidenty z hlediska úplnosti a souladu s osvědčenými postupy. U nezávislého přezkumu hledají důkazy, že byly provedeny nezávislé audity nebo přezkumy.

Pohled ISO/IEC 27007:2020 je specifičtější pro audit ISMS. Zenith Controls uvádí, že auditoři mohou vést rozhovory s pracovníky nákupu, pracovníky bezpečnosti IT a manažery dodavatelů, aby posoudili porozumění opatřením dodavatelského řetězce IKT a jejich uplatňování. U přípravy na incidenty potvrzují, že existuje tým reakce na incidenty a je provozně funkční. U nezávislého přezkumu ověřují, že program interního auditu pokrývá celý rozsah ISMS a má odpovídající zdroje.

Hodnotitel testování vycházející z NIST SP 800-115 se zaměří na metodiku hodnocení zranitelností a penetračního testování. Může zkoumat, zda jsou dokumentovány rozsah testu, pravidla zapojení, zjištění, hodnocení závažnosti, náprava a retestování. U DORA TLPT to znamená, že hodnotitel nebude spokojen se sadou slidů red teamu. Bude požadovat důkaz o správě, bezpečnosti, technické hloubce a uzavření zjištění.

Auditor ve stylu COBIT 2019 nebo ISACA se zeptá, zda jsou naplněny cíle správy: kdo proces vlastní, jak se měří výkonnost, jak jsou schvalovány výjimky a jak vedení získává ujištění.

Praktický kontrolní seznam připravenosti na DORA 2026

Použijte tento kontrolní seznam jako pracovní základ pro převod vyhledávání DORA do opatření.

Správa a mapování RTS/ITS

• Udržujte registr souladu s DORA s oblastí povinností, použitelností, vlastníkem, důkazy, frekvencí přezkumu a stavem mezer.
• Mapujte požadavky DORA na politiky, registry, kontroly a reporting vedení.
• Definujte odůvodnění proporcionality pro zjednodušené nebo škálované řízení rizik v oblasti IKT tam, kde je použitelné.
• Přiřaďte odpovědnost vrcholového vedení za rizika IKT, hlášení incidentů, dohled nad třetími stranami a testování.
• Zahrňte stav DORA do přezkoumání vedením a reportingu rizik správnímu orgánu.

Řízení rizik v oblasti IKT

• Udržujte registr rizik IKT s popisem, pravděpodobností, dopadem, skóre, vlastníkem a plánem ošetření rizik.
• Propojte rizika s kritickými nebo důležitými funkcemi.
• Propojte rizika s aktivy IKT, dodavateli a procesy.
• Přezkoumávejte rizika po významných incidentech, změnách dodavatelů, technologických změnách nebo zjištěních z testů.
• Sledujte činnosti ošetření rizik až do uzavření nebo formálního přijetí rizika.

Dohled nad třetími stranami v oblasti IKT

• Udržujte registr dodavatelů a registr závislostí na dodavatelích.
• Identifikujte dodavatele podporující kritické nebo důležité funkce.
• Posuzujte dodavatele typu jediný zdroj dodávky a jejich nahraditelnost.
• Přezkoumávejte subdodavatele a ujednání o sub-outsourcingu.
• Zakotvěte do smluv doložky o bezpečnosti, přístupu, hlášení incidentů, auditu a ukončení spolupráce.
• Monitorujte kritické dodavatele alespoň jednou ročně nebo po podstatných změnách.
• Udržujte plány ukončení spolupráce a pohotovostní plány pro poskytovatele s vysokou mírou závislosti.

Řízení a hlášení incidentů

• Udržujte postupy reakce na incidenty s jasnými rolemi a eskalačními trasami.
• Definujte klasifikační kritéria incidentů IKT.
• Slaďte spouštěče hlášení podle DORA s GDPR, NIS2 a smluvními oznamovacími povinnostmi.
• Školte zaměstnance a dodavatele v kanálech pro hlášení incidentů.
• Udržujte logy incidentů, rozhodovací záznamy a důkazy.
• Provádějte přezkoumání po incidentu a aktualizujte rizika a kontroly.

Testování, red teaming a TLPT

• Udržujte kalendář testování založený na rizicích.
• Provádějte skenování zranitelností a penetrační testování v definovaných intervalech.
• Používejte scénářová cvičení red teamu k testování detekce a reakce.
• Pro připravenost na TLPT definujte rozsah, pravidla zapojení, bezpečnostní kontroly a koordinaci s dodavateli.
• Chraňte produkční systémy během testování.
• Sledujte zjištění, nápravu, retestování a získané poznatky.
• Reportujte výsledky testování vedení.

Kontinuita a obnova

• Provádějte každoroční BIA pro kritické obchodní jednotky a aktualizujte ji po významných změnách.
• Definujte cíle obnovy pro kritické funkce a podpůrné služby IKT.
• Testujte schopnosti BCP a DR alespoň jednou ročně.
• Zahrňte scénáře výpadku dodavatele a kybernetického incidentu.
• Uchovávejte důkazy z testů, mezery, nápravná opatření a výsledky retestů.
• Slaďte plány kontinuity s reakcí na incidenty a krizovou komunikací.

Jak Clarysec pomáhá finančním subjektům přejít od výsledků vyhledávání k auditně připraveným důkazům

Připravenost na DORA 2026 nevzniká stažením kontrolního seznamu a doufáním, že organizace mezery doplní později. Vyžaduje strukturovaný provozní model, který propojuje rizika, dodavatele, incidenty, testování, kontinuitu a auditní důkazy.

Přístup Clarysec kombinuje tři vrstvy.

Zaprvé Zenith Blueprint poskytuje implementační plán. Krok 14 pomáhá organizacím křížově odkazovat regulatorní požadavky na ošetření rizik a politiky. Krok 16 posiluje hlášení incidentů řízené personálem. Krok 21 zajišťuje, aby audity a testy neohrožovaly produkční systémy. Krok 23 mění dohled nad dodavateli v praktický postup pokrývající klasifikaci, smlouvy, subdodavatele, monitorování a hodnocení cloudu.

Zadruhé politiky Clarysec poskytují správu připravenou k provoznímu uplatnění. Politika řízení rizik, Politika právního a regulatorního souladu, Bezpečnostní politika dodavatelů a poskytovatelů služeb třetích stran, Politika řízení rizik závislostí na dodavatelích, Politika reakce na incidenty, Politika bezpečnostního testování a red teamingu a Politika kontinuity činností a obnovy po havárii poskytují týmům konkrétní ustanovení, modely vlastnictví a očekávání důkazů.

Zatřetí Zenith Controls poskytuje mapu křížového souladu. Ukazuje, jak bezpečnost dodavatelského řetězce IKT, plánování řízení incidentů a nezávislý přezkum souvisejí s DORA, GDPR, NIS2, ISO/IEC 27001:2022, ISO/IEC 27002:2022, ISO/IEC 27035, ISO/IEC 27036, ISO/IEC 22320, ISO/IEC 20243, COBIT 2019 a testovacími postupy NIST.

Výsledkem je program souladu s DORA, který je obhajitelný při auditu a užitečný během skutečného incidentu, selhání dodavatele nebo testu odolnosti.

Další krok: vybudujte balíček důkazů DORA před další žádostí z auditu

Pokud váš tým stále hledá „DORA RTS/ITS checklist“, „DORA ICT risk management template“, „DORA third-party oversight“ nebo „DORA TLPT requirements“, dalším krokem je převést tato vyhledávání do řízených důkazů.

Začněte tento týden čtyřmi kroky:

1. Vytvořte nebo aktualizujte svůj registr souladu s DORA s využitím modelu politik Clarysec.
2. Vyberte jednu kritickou funkci a vysledujte ji přes registr rizik, registr závislostí na dodavatelích, incidentní postup, BIA a plán testování.
3. Přezkoumejte pět nejvýznamnějších dodavatelů IKT z hlediska nahraditelnosti, subdodavatelů, incidentních doložek a možností ukončení spolupráce.
4. Vytvořte balíček důkazů z testování s rozsahem, autorizací, výsledky, nápravou a retestováním.

Clarysec vám může pomoci toto implementovat pomocí Zenith Blueprint, šablon politik a Zenith Controls, aby váš program DORA 2026 byl praktický, proporcionální a připravený na audit.