Program testování podle DORA: mapování testů na ISO 27001

Je únor 2026. CISO středně velké platební instituce má za dva dny jednání vedoucího orgánu, za šest týdnů dozorový audit ISO/IEC 27001:2022 a ve schránce týmu compliance leží žádost příslušného orgánu dohledu podle DORA.

Regulační orgán nepožaduje uhlazenou kybernetickou strategii. Žádost je praktická:

• Předložte program testování digitální provozní odolnosti pro rok 2026.
• Ukažte, které testy pokrývají kritické nebo důležité funkce.
• Doložte, jak jsou zjištění napravována a opakovaně testována.
• Doložte dohled vedoucího orgánu.
• Vysvětlete, jak jsou zapojeni poskytovatelé služeb třetích stran v oblasti ICT.
• Předložte záznamy k hodnocením zranitelností, scénářovým testům, testování výkonnosti a kapacity a penetračnímu testování.

CISO otevře čtyři složky. Skeny zranitelností jsou v systému SOC pro správu tiketů. Poznámky ze scénářových cvičení typu tabletop jsou na sdíleném disku. Výsledky zátěžových testů spravuje engineering. Zprávy z penetračního testování jsou v omezeném repozitáři právního oddělení. Sledování nápravných opatření je rozdělené mezi Jira, e-mail a tabulku vytvořenou pro loňský audit ISO.

Nic z toho není fingované. Velká část představuje kvalitní práci. Zatím však nejde o řízený program testování digitální provozní odolnosti podle DORA. Je to soubor testů.

V roce 2026 je tento rozdíl podstatný. DORA se použije od 17. ledna 2025 a zavádí jednotný rámec EU pro digitální provozní odolnost v oblastech řízení rizik v oblasti ICT, hlášení incidentů, testování odolnosti, sdílení informací o kybernetických hrozbách a zranitelnostech, řízení rizik třetích stran v oblasti ICT, smluvních požadavků a dohledu nad kritickými poskytovateli služeb třetích stran v oblasti ICT. Vztahuje se na široký okruh finančních subjektů, včetně úvěrových institucí, platebních institucí, investičních podniků, poskytovatelů služeb souvisejících s kryptoaktivy, pojišťoven a dalších regulovaných subjektů. DORA zároveň působí jako odvětvový právní akt Unie pro finanční subjekty, na které by se jinak vztahovaly rovnocenné povinnosti kybernetické bezpečnosti podle NIS2.

Praktická otázka pro vedoucí orgány, CISO, manažery compliance a poskytovatele ICT už nezní, zda testování probíhá. Otázka zní, zda je testování plánované, rizikově orientované, doložené, napravené, přezkoumané a opakovaně použitelné napříč DORA a ISO/IEC 27001:2022.

Provozní model Clarysec je postaven právě pro tento problém. Pomocí Zenith Blueprint: 30kroková roadmapa auditora, sady politik Clarysec sladěné s ISO a Zenith Controls: průvodce souladem napříč rámci mohou organizace proměnit roztříštěné aktivity v oblasti odolnosti v řízený roční katalog testů, který obstojí před orgány dohledu, auditory, klienty i vedoucími orgány.

Proč DORA mění testování na otázku správy a řízení

DORA je výslovná v otázce odpovědnosti vrcholového vedení. Article 5 ukládá odpovědnost za řízení rizik v oblasti ICT vedoucímu orgánu. Article 6 vyžaduje spolehlivý, komplexní a dobře zdokumentovaný rámec řízení rizik v oblasti ICT integrovaný do celkového systému řízení rizik organizace. Article 4 doplňuje proporcionalitu, tedy že požadavky se mají uplatňovat podle velikosti, celkového rizikového profilu a povahy, rozsahu a složitosti služeb, činností a provozu.

Testování digitální provozní odolnosti tím přestává být jen technickým úkolem. Stává se důkazem, že vedoucí orgán rozumí rizikům, schválil strategii, dostává smysluplné reporty a řídí nápravu.

ISO/IEC 27001:2022 používá podobnou logiku systému řízení. Kapitoly 4.1 až 4.4 vyžadují, aby organizace porozuměla kontextu, zainteresovaným stranám, právním a smluvním povinnostem, rozsahu, rozhraním a závislostem. Kapitoly 5.1 až 5.3 vyžadují vedení, sladění politik, zdroje, komunikaci, přiřazené odpovědnosti a reportování vrcholovému vedení. Kapitola 6.1 vyžaduje posouzení rizik bezpečnosti informací a ošetření rizik.

Program testování podle DORA by proto měl propojovat:

• podnikové služby a kritické nebo důležité funkce,
• aktiva ICT, data a závislosti na třetích stranách,
• posouzení rizik, vlastníky rizik a plány ošetření rizik,
• typy testů, četnost a spouštěče,
• autorizaci, nezávislost a pravidla zapojení,
• zjištění, lhůty nápravy a retestování,
• uchovávání důkazů a řízení přístupu,
• reportování vedení a neustálé zlepšování.

Pro menší finanční subjekty nebo finanční subjekty s nižším rizikem poskytuje Article 16 zjednodušený rámec řízení rizik v oblasti ICT, ale zjednodušený neznamená neformální. I odstupňované programy stále potřebují zdokumentované řízení rizik v oblasti ICT, monitorování, odolné systémy, identifikaci zdrojů rizik ICT a anomálií, klíčové závislosti na třetích stranách v oblasti ICT, opatření kontinuity a obnovy, pravidelné testování a získané poznatky.

Jinými slovy, DORA neodměňuje objem testů. Oceňuje řízené, rizikově orientované testování, které prokazuje odolnost služeb s nejvyšší důležitostí.

Co patří do programu testování podle DORA pro rok 2026?

Vyspělý program testování podle DORA by měl fungovat jako roční katalog testů. Neměl by se omezit na jeden roční penetrační test ani na hromadu exportů ze skenů zranitelností. Měl by zahrnovat základní i pokročilé testy plánované podle rizik, kritičnosti služeb, regulačních povinností, závislostí na dodavatelích, významných změn a předchozích zjištění.

DORA Article 24 stanoví program testování digitální provozní odolnosti. Article 25 popisuje škálu testů včetně hodnocení a skenů zranitelností, open-source analýz, hodnocení zabezpečení sítě, analýz mezer, přezkumů fyzické bezpečnosti, dotazníků, softwarových skenovacích řešení, přezkumů zdrojového kódu tam, kde je to proveditelné, scénářových testů, testování kompatibility, testování výkonnosti, end-to-end testování a penetračního testování. Article 26 doplňuje penetrační testování vedené hrozbami pro finanční subjekty určené příslušnými orgány.

U většiny organizací je praktický katalog postaven na čtyřech rodinách testování.

Politika bezpečnostního testování a red teamingu od Clarysec poskytuje pro tento katalog silnou oporu v politice:

“Typy testů: Program bezpečnostního testování musí zahrnovat minimálně: (a) skenování zranitelností, které spočívá v automatizovaných týdenních nebo měsíčních skenech sítí a aplikací za účelem identifikace známých zranitelností; (b) penetrační testování, které spočívá v manuálním hloubkovém testování konkrétních systémů nebo aplikací kvalifikovanými testery za účelem identifikace složitých slabin; a (c) cvičení red teamingu, která spočívají ve scénářových simulacích reálných útoků, včetně sociálního inženýrství a dalších taktik, za účelem otestování detekčních a reakčních schopností organizace jako celku.”

Stejná politika vyžaduje pravidelné plánování:

“Harmonogram testování: Organizace musí provádět bezpečnostní testování podle pravidelného harmonogramu. Klíčové systémy dostupné z internetu a kritické interní aplikace musí podstoupit penetrační testování alespoň jednou ročně. Vysoce rizikové změny, jako je nasazení nového kritického systému nebo významné upgrady, vyžadují ad hoc testování před spuštěním do produkčního prostředí a/nebo krátce po něm.”

To je pro DORA zásadní. Statický roční plán nestačí, pokud subjekt nasadí novou platební bránu, migruje klíčový systém do cloudu, změní poskytovatele řízených služeb nebo uvolní nový tok autentizace zákazníků. Vysoce riziková změna musí spustit dodatečné testování.

Vytvořte roční katalog testů jako jediný zdroj pravdy

Nejúčinnějším způsobem, jak splnit DORA a ISO/IEC 27001:2022, je vytvořit jeden řízený roční katalog testů. Může být veden v platformě GRC, ve workflow pro správu tiketů nebo v řízené tabulce. Formát je méně důležitý než dohledatelnost.

Každý test by měl odpovědět na pět auditních otázek:

1. Která služba, aktivum, dodavatel, aplikace nebo proces byly testovány?
2. Které riziko, povinnost nebo požadavek opatření test spustily?
3. Kdo test autorizoval a provedl?
4. Jaká zjištění byla identifikována, akceptována, napravena nebo odložena?
5. Jaké důkazy prokazují, že test proběhl a výsledek byl přezkoumán?

Praktický katalog ve stylu Clarysec obsahuje tato pole.

Politika monitorování auditu a compliance pro SME od Clarysec stanoví stručné pravidlo správy, které do této struktury zapadá:

“Každý audit musí mít definovaný rozsah, cíle, odpovědné osoby a požadované důkazy.”

Ačkoli je pravidlo napsáno pro audity, stejné pravidlo má platit i pro testy odolnosti. Pokud sken zranitelností, tabletop cvičení, simulace přepnutí na záložní řešení nebo penetrační test nemají definovaný rozsah, cíl, vlastníka a požadované důkazy, budou slabé jak podle DORA, tak při auditu ISO.

Stejná politika uvádí:

“Důkazy musí být uchovávány alespoň dva roky, případně déle, pokud to vyžaduje certifikace nebo klientské dohody.”

U finančních subjektů a poskytovatelů ICT regulovaných podle DORA je třeba dva roky považovat za minimum. Smluvní povinnosti, očekávání orgánů dohledu, certifikační cykly a vyšetřování incidentů mohou vyžadovat delší uchovávání.

Mapujte typy testů DORA na důkazy pro ISO 27001

Síla integrovaného programu spočívá v tom, že jeden test může plnit více povinností. Klíčem je důkazy správně označit a propojit je s ISMS.

Zenith Blueprint to vysvětluje ve fázi Audit, přezkum a zlepšování, krok 24:

“Vaše SoA by mělo být konzistentní s registrem rizik a plánem ošetření rizik. Znovu ověřte, že každé opatření, které jste zvolili jako ošetření rizika, je v SoA označeno jako „Použitelné“.”

U programu testování podle DORA se katalog testů stává mostem mezi ošetřením rizik a provozními důkazy. Prohlášení o použitelnosti by nemělo uvádět, že se opatření použije, zatímco důkazy z testů leží jinde, bez mapování a bez řízení.

Tato tabulka pomáhá CISO odpovědět na častou otázku CEO: “Stačí naše ISO penetrační testy a skeny zranitelností pro DORA?”

Odpověď zní: mohou být součástí souladu s DORA, ale pouze tehdy, pokud jsou rizikově orientované, navázané na kritické nebo důležité funkce, řízené politikou, sledované až po nápravu a reportované vedení.

Hodnocení zranitelností: průběžné důkazy, nejen výstup ze skenu

Hodnocení zranitelností je často nejjednodušší testovací aktivita na spuštění a zároveň nejsnazší k chybnému uchopení. Mnoho organizací dokáže předložit zprávy ze skenů. Méně jich dokáže prokázat, že skeny pokrývají správná aktiva, prioritizují kritické služby, generují včasnou nápravu a vstupují do rozhodnutí o ošetření rizik.

Politika řízení zranitelností a záplat pro SME od Clarysec začíná správným cílem:

“Včas a konzistentně identifikovat a hodnotit známé zranitelnosti napříč všemi IT aktivy”

Pro DORA to podporuje identifikaci zdrojů rizik ICT, odolné a aktualizované systémy, monitorování, detekci anomálií a neustálé zlepšování. Pro ISO/IEC 27001:2022 se to přímo mapuje na 8.8 Řízení technických zranitelností a zároveň se opírá o 5.9 Evidenci informací a dalších souvisejících aktiv, 8.16 Monitorovací činnosti a 8.32 Řízení změn.

Silný záznam o hodnocení zranitelností by měl obsahovat:

• snímek evidence aktiv použitý pro vymezení rozsahu,
• datum skenu, nástroj a autentizovanou nebo neautentizovanou metodu,
• vyloučení a obchodní odůvodnění,
• zjištění podle závažnosti, zneužitelnosti a podnikové služby,
• mapování na kritické nebo důležité funkce a typy dat,
• reference na tikety a vlastníka rizika,
• SLA nápravy a termín splnění,
• výsledek retestu,
• výjimky se schválením zbytkového rizika.

Zenith Controls staví 8.8 Řízení technických zranitelností jako klíčovou oblast důkazů pro identifikaci, hodnocení, prioritizaci a sledování nápravy. Zároveň ukazuje, proč auditoři prověřují i navazující procesy. Pokud je evidence aktiv neúplná, je neúplné i pokrytí zranitelností. Pokud je obcházeno řízení změn, může nasazení záplat vytvořit nové provozní riziko. Pokud je monitorování slabé, pokusy o zneužití nemusí být detekovány.

Scénářové testy: prokažte rozhodování před skutečným incidentem

Scénářové testy jsou místem, kde je provozní odolnost viditelná pro vrcholové vedení. Tabletop cvičení ransomwaru, simulace výpadku cloudového regionu, cvičení kompromitace privilegovaného přístupu nebo scénář selhání kritického poskytovatele ICT odhalí slabiny, které sken neukáže.

DORA Articles 17 až 20 vyžadují formální životní cyklus incidentu souvisejícího s ICT: detekovat, řídit, oznamovat, zaznamenávat, monitorovat, zvládat, navazovat, dokumentovat kořenovou příčinu, napravovat, klasifikovat závažnost, přiřazovat role, eskalovat závažné incidenty a reportovat v požadovaných fázích. Pokud jsou dotčeny finanční zájmy klientů, musí být klienti informováni bez zbytečného odkladu.

NIS2 má podobnou naléhavost pro subjekty ve svém rozsahu, včetně včasného varování, oznámení, průběžného reportování a závěrečného reportování. Pro finanční subjekty v rozsahu působnosti je DORA odvětvovým právním aktem pro rovnocenné povinnosti v oblasti řízení rizik kybernetické bezpečnosti a reportování. Poskytovatelé ICT, SaaS platformy, MSP a MSSP si stále musí ověřit, zda spadají přímo do rozsahu NIS2 nebo zda jsou smluvně zahrnuti do ujištění podle DORA regulovanými klienty.

Zenith Blueprint, fáze Controls in Action, krok 23, dává praktický model důkazů:

“Vyberte nedávnou událost nebo proveďte tabletop cvičení k ověření svého plánu. Zachyťte a zalogujte všechna rozhodnutí, role a komunikaci (5.26) a aktualizujte plán o získané poznatky (5.27).”

Scénářový test DORA má vytvářet auditovatelné záznamy, nejen poznámky ze schůzky:

• zadání scénáře a cíle,
• účastníky a role, včetně právního oddělení, komunikace, IT, SOC, vlastníka podnikové oblasti a kontaktů dodavatelů,
• časovou osu vstupů a rozhodnutí,
• rozhodnutí o klasifikaci a analýzu prahových hodnot pro hlášení,
• návrhy interní a externí komunikace,
• kroky k uchování důkazů,
• získané poznatky,
• vlastníky opatření a termíny splnění,
• aktualizované incidentní, kontinuitní nebo komunikační postupy.

Politika kontinuity činností a obnovy po havárii pro SME od Clarysec posiluje požadavek na každoroční testování:

“Organizace musí alespoň jednou ročně testovat své schopnosti BCP i DR. Testy musí zahrnovat:”

Katalog testování by měl tuto povinnost převést do konkrétních cvičení, jako jsou tabletop cvičení krizového řízení, test obnovy ze zálohy, test přepnutí cloudu na záložní řešení, test kontaktního stromu a simulace narušení dodavatelem.

Testy výkonnosti, kapacity a obnovy: opomíjené důkazy odolnosti

Testování výkonnosti se často považuje za věc engineeringu. Pod DORA se z něj stávají důkazy odolnosti.

Obchodní platforma, platební služba, systém pro likvidaci škod, platforma identit nebo zákaznický portál nepotřebují kybernetický útok, aby selhaly vůči zákazníkům. Vyčerpání kapacity, saturace front, úzká místa databáze, chybně nakonfigurované autoscalingové mechanismy nebo nefunkční přepnutí na záložní řešení mohou způsobit stejné provozní narušení jako bezpečnostní incident.

Primární kotvou je příloha A ISO/IEC 27001:2022, 8.6 Řízení kapacity. Důkazy mohou zahrnovat zátěžové testování, stresové testování, testování degradace služby, ověření infrastrukturních prahových hodnot, testy obnovy ze záloh a simulace přepnutí na záložní řešení.

Kvalitní záznam o testu výkonnosti a kapacity by měl zachytit:

• výchozí předpoklady běžné a špičkové zátěže,
• testované kritické transakční průchody,
• testované limity infrastruktury a cloudu,
• monitorovací řídicí panely a prahové hodnoty upozornění,
• režimy selhání, jako je saturace front nebo úzká místa databáze,
• relevantnost RTO a RPO tam, kde se testuje přepnutí nebo obnova,
• obchodní dopad při překročení prahových hodnot,
• nápravná opatření, rozhodnutí o škálování nebo architektonické změny,
• akceptaci zbytkového kapacitního rizika vedením.

Zenith Blueprint, krok 23, propojuje očekávání obnovy s důkazy:

“Ověřte, že cílové doby obnovy (RTO) a cílové body obnovy (RPO) pro kritické systémy odpovídají očekáváním kontinuity činností (5.30). Proveďte alespoň jeden technický test obnovy nebo simulaci přepnutí na záložní řešení a výsledky zdokumentujte.”

To je rozdíl mezi tvrzením “máme zálohy” a prokázáním, že kritická služba byla obnovena v dohodnuté toleranci, se zdokumentovanými výsledky a viditelností pro vedení.

Penetrační testování a red teaming: silné důkazy vyžadují silné řízení

Penetrační testování je velmi hodnotný důkaz, ale nese i provozní riziko. Špatně řízené testování může zasáhnout produkční systémy, vystavit citlivá data, spustit nekontrolovaná upozornění, vytvořit právní problémy nebo narušit zákazníky.

Politika požadavků na zabezpečení aplikací pro SME stanoví jasnou bránu před vydáním:

“Před nasazením musí všechny aplikace projít bezpečnostním testováním za účelem ověření výše uvedených základních funkcí.”

U kritických aplikací by to mělo vstupovat do katalogu DORA jako bezpečnostní testování v předprodukčním prostředí, validace po spuštění do produkce u vysoce rizikových změn a pravidelné penetrační testování podle expozice a kritičnosti.

Politika bezpečnostního testování a red teamingu posiluje řetězec nápravy:

“Náprava zjištění: Všechny identifikované zranitelnosti nebo slabiny musí být zdokumentovány ve zprávě o zjištěních s hodnocením závažnosti. Po obdržení zprávy jsou vlastníci systémů odpovědní za vytvoření plánu nápravy s termíny splnění; například kritická zjištění musí být napravena do 30 dnů a zjištění s vysokou závažností do 60 dnů, v souladu s Politikou řízení zranitelností a záplat organizace. STC musí sledovat postup nápravy. Retestování musí být provedeno k potvrzení, že kritické problémy byly vyřešeny nebo dostatečně zmírněny.”

Stejná politika definuje očekávání pro reportování:

“Reportování: Po dokončení každého testu musí být vydána formální zpráva. U penetračního testování musí zpráva obsahovat shrnutí pro vedení, metodiku a podrobná zjištění s podpůrnými důkazy a doporučeními.”

Zenith Blueprint, krok 21, také zdůrazňuje ochranu během auditu a testování:

“Žádný test ani audit nesmí proběhnout bez zdokumentovaného schválení vlastníky systémů nebo příslušnými zainteresovanými stranami.”

Pravidla zapojení, testovací okna, nouzové kontakty, dočasný přístup, nakládání s daty, protokolování, postupy vrácení změn a právní schválení nejsou byrokracie. Jsou to ochranné mechanismy odolnosti.

Zapojte poskytovatele služeb třetích stran v oblasti ICT dříve, než test selže

DORA činí z rizika třetích stran v oblasti ICT centrální otázku odolnosti. Article 28 vyžaduje, aby finanční subjekty řídily riziko třetích stran v oblasti ICT v rámci řízení rizik v oblasti ICT, zůstaly odpovědné při využívání služeb ICT, vedly informační registr, oznamovaly určitá ujednání, prováděly předsmluvní posouzení a využívaly poskytovatele splňující odpovídající standardy bezpečnosti informací. Articles 29 a 30 řeší riziko koncentrace, subdodávky, obnovu dat, smluvní ochrany, úrovně služeb, podporu při incidentech, práva na audit, testování nouzových opatření poskytovatelů, účast na testování tam, kde je relevantní, a ujednání pro ukončení spolupráce.

Příloha A ISO/IEC 27001:2022 poskytuje podpůrná dodavatelská opatření, včetně 5.19 Bezpečnost informací ve vztazích s dodavateli, 5.20 Řešení bezpečnosti informací ve smlouvách s dodavateli, 5.21 Řízení bezpečnosti informací v dodavatelském řetězci ICT, 5.22 Monitorování, přezkum a řízení změn služeb dodavatelů a 5.23 Bezpečnost informací pro používání cloudových služeb.

Katalog testů DORA by měl identifikovat, které testy vyžadují účast dodavatele nebo dodavatelské důkazy. Příklady zahrnují:

• předpoklady přepnutí poskytovatele cloudových služeb na záložní řešení,
• eskalaci a uchování důkazů u řízeného SOC,
• incidentní komunikaci platformy core bankingu,
• scénář výpadku zpracovatele plateb,
• test obnovy poskytovatele identit,
• atestace penetračního testování dodavatele SaaS,
• posouzení dopadu řetězce kritických subdodavatelů.

Program, který vylučuje kritické poskytovatele ICT, neobstojí v testu reality. Zákaznicky orientovaná služba může být vaše, ale závislost odolnosti může ležet v cloudovém regionu, outsourcovaném SOC, poskytovateli identit, dodavateli softwaru, zpracovateli plateb nebo datovém centru.

Mapování napříč požadavky: jedna sada důkazů, mnoho povinností

Dobře navržený program testování podle DORA snižuje auditní únavu. Stejné důkazy mohou podporovat DORA, ISO/IEC 27001:2022, NIS2, GDPR, NIST CSF 2.0 a přezkumy správy podle COBIT 2019, pokud jsou správně označené, uchovávané a reportované.

Na GDPR se nesmí zapomínat. Pokud testy odolnosti zahrnují osobní údaje, logy, zákaznické záznamy, údaje o identitách, HR záznamy, biometrické údaje nebo zvláštní kategorie údajů, organizace musí respektovat zásady GDPR včetně zákonnosti, korektnosti, transparentnosti, minimalizace údajů, omezení uložení, integrity, důvěrnosti a odpovědnosti. Kopie testovacích dat, exportované logy a důkazy z penetračního testování se mohou stát úložišti regulovaných dat. Program testování má definovat, kdo k nim smí přistupovat, jak dlouho jsou uchovávány a jak jsou bezpečně likvidovány.

Jak budou auditoři testovat stejný program

Orgán dohledu podle DORA, auditor ISO, hodnotitel podle NIST, přezkoumávající podle COBIT a klientský auditor mohou zkoumat stejné důkazy různými optikami.

Zenith Controls je zde užitečný jako kompas napříč požadavky. Pro testování DORA Clarysec zdůrazňuje 5.35 Nezávislý přezkum bezpečnosti informací, 8.8 Řízení technických zranitelností a 8.6 Řízení kapacity jako zvlášť důležité kotvy přílohy A ISO/IEC 27001:2022. Pomáhají vlastníkům kontrol propojit testování s nezávislým ujištěním, řízením zranitelností a provozní kapacitou.

Politika bezpečnosti informací od Clarysec také podporuje auditní stopu:

“Vlastníci kontrol musí uchovávat výsledky testů, logy a záznamy z přezkumů na podporu pravidelných auditů.”

Tato věta by se měla stát provozním pravidlem. Každý vlastník testu má vědět, co uchovávat, kde to uchovávat, jak to chránit a jak to navazuje na důkazy o rizicích a kontrolách.

Vytvořte důkazní balíček DORA–ISO za jeden týden

Finanční subjekt nebo poskytovatel ICT může za pět pracovních dnů dosáhnout významného pokroku.

Den 1: Definujte rozsah a kritičnost

Použijte uvažování podle kapitol 4.1 až 4.4 ISO/IEC 27001:2022. Identifikujte zainteresované strany, regulační povinnosti, smluvní povinnosti, rozhraní a závislosti. Sepište podnikové služby, kritické nebo důležité funkce, klíčová aktiva, typy dat a poskytovatele ICT.

Výstup: registr rozsahu testování DORA.

Den 2: Vytvořte roční katalog testů

Použijte čtyři rodiny testů: zranitelnosti, scénáře, výkonnost a penetrace. Pro každou službu definujte, které testy se použijí, četnost, vlastníka, úroveň nezávislosti a spouštěč. Zahrňte spouštěče vysoce rizikových změn.

Výstup: katalog testování digitální provozní odolnosti pro rok 2026.

Den 3: Namapujte opatření a povinnosti

Namapujte každý test na přílohu A ISO/IEC 27001:2022, registr rizik, SoA, články DORA, dodavatelské povinnosti a relevantní položky Zenith Controls. Například měsíční externí skeny zranitelností se mapují na 8.8 Řízení technických zranitelností, ošetření rizik, monitorování, řízení rizik ICT podle DORA a výsledky NIST CSF pro zranitelnosti.

Výstup: matice mapování opatření.

Den 4: Standardizujte složky důkazů

Vytvořte řízenou strukturu důkazů:

• 01 Plán a autorizace
• 02 Rozsah a pravidla zapojení
• 03 Surové výsledky
• 04 Závěrečná zpráva
• 05 Registr zjištění
• 06 Tikety nápravy
• 07 Důkazy z retestu
• 08 Reportování vedení
• 09 Získané poznatky a aktualizace politik

Výstup: repozitář důkazů s pravidly uchovávání.

Den 5: Přezkoumejte zjištění a reportování

Konsolidujte otevřená zjištění podle závažnosti, služby, vlastníka rizika a termínu splnění. Identifikujte prodlení v nápravě, akceptovaná rizika a mezery v retestování. Připravte řídicí panel pro vedoucí orgán, který ukazuje pokrytí testováním, závažná zjištění, zpožděná opatření, problémy třetích stran a zbytkové riziko.

Výstup: řídicí panel testování DORA a ISO připravený pro vedoucí orgán.

Častá úskalí programu testování podle DORA

Nejčastějším selháním není nedostatek testování. Je to nedostatek správy a řízení.

Sledujte tyto problémy:

• penetrační testy se provádějí ročně, ale zjištění nejsou sledována až do uzavření,
• skeny zranitelností běží často, ale kritická aktiva chybí v rozsahu,
• tabletop cvičení proběhla, ale chybí log rozhodnutí nebo akční plán získaných poznatků,
• testy obnovy ze záloh byly dokončeny, ale nejsou mapovány na RTO a RPO,
• zátěžové testy provádí engineering, ale nejsou reportovány funkci řízení rizik ani compliance,
• poskytovatelé ICT jsou vyloučeni ze scénářových a obnovovacích testů,
• důkazy jsou uloženy v osobních složkách, chatových vláknech nebo nespravovaných úložištích,
• reporty pro vedoucí orgán se zaměřují na počty aktivit místo nevyřešeného rizika odolnosti,
• SoA uvádí, že se opatření použije, ale neexistují žádné testovací důkazy,
• testování vytváří produkční riziko, protože autorizace a hranice nejsou jasné.

Každou mezeru lze řešit. Nápravou není více náhodného testování. Nápravou je jeden řízený program, který propojuje riziko, testovací aktivitu, nápravu, důkazy a dohled vedení.

Co má vedoucí orgán skutečně vidět

DORA činí z odolnosti ICT odpovědnost vedoucího orgánu. Užitečný report pro vedoucí orgán nemá obsahovat každé technické zjištění. Má odpovědět, zda je organizace dostatečně odolná vzhledem ke své ochotě podstupovat riziko a toleranci narušení.

Silný čtvrtletní nebo pololetní report zahrnuje:

• pokrytí testováním vůči kritickým nebo důležitým funkcím,
• dokončené testy oproti plánovaným,
• kritická a vysoká zjištění podle služby,
• zpožděnou nápravu podle vlastníka,
• míru úspěšnosti retestů,
• zjištění související s dodavateli a obavy z koncentrace,
• poznatky ze scénářových testů ovlivňující krizové nebo incidentní plány,
• kapacitní rizika vůči růstu podnikání a špičkovým obdobím,
• zbytková rizika vyžadující akceptaci vedením,
• omezení rozpočtu, zdrojů nebo nástrojů.

Tento report se stává vstupem pro přezkoumání vedením podle ISO, důkazem správy podle DORA a praktickým nástrojem pro rozhodování.

Od roztříštěných testů ke strategické odolnosti

Původní problém CISO nebyl v tom, že by testování chybělo. Organizace měla skeny, tabletop cvičení, zátěžové reporty a PDF zprávy z penetračních testů. Problém byl v tom, že tyto aktivity zatím nevyprávěly jeden souvislý příběh důkazů.

Jednotný program testování podle DORA a ISO/IEC 27001:2022 to mění. Posouzení rizik řídí katalog. Katalog řídí autorizované testování. Testování vytváří zjištění. Zjištění řídí nápravu a retestování. Výsledky vstupují do reportování vedení. Získané poznatky aktualizují politiky, postupy, smlouvy a opatření.

Tak se z břemene compliance stává strategická schopnost.

Clarysec pomáhá organizacím vyhnout se paralelním programům compliance. DORA, ISO/IEC 27001:2022, NIS2, GDPR, NIST CSF 2.0 a COBIT 2019 nepotřebují oddělené světy důkazů. Potřebují jediný, řízený provozní model, který lze předložit různými auditními optikami.

Náš přístup kombinuje:

• Zenith Blueprint pro fázovanou implementaci ISO a připravenost na audit,
• Zenith Controls pro mapování napříč požadavky mezi kontrolami, rámci a očekáváními auditu,
• podnikové a SME politiky pro bezpečnostní testování, monitorování auditu, řízení zranitelností, zabezpečení aplikací, kontinuitu a bezpečnost informací,
• praktické registry, struktury důkazů a šablony reportování vedení.

Pokud jsou vaše důkazy z testování DORA pro rok 2026 rozptýlené mezi skenovacími nástroji, složkami engineeringu, poznámkami z tabletop cvičení a PDF zprávami z penetračních testů, teď je čas je konsolidovat.

Začněte jedním ročním katalogem testů mapovaným na ošetření rizik podle ISO/IEC 27001:2022, vaše SoA, kritické nebo důležité funkce, třetí strany v oblasti ICT a reportování vedení. Poté použijte Zenith Blueprint, Zenith Controls a sadu politik Clarysec k tomu, aby se tento katalog proměnil v obhajitelné auditní důkazy.

Clarysec vám pomůže navrhnout program, namapovat opatření, strukturovat důkazní balíček a připravit report odolnosti pro vedoucí orgán dříve, než dorazí další žádost orgánu dohledu.