Hlášení incidentů podle DORA a opatření ISO 27001 v roce 2026

Je úterý ráno v roce 2026, 08:17. Sarah, CISO evropské fintechové společnosti, vidí na řídicím panelu oranžové, nikoli červené upozornění. Kritická platforma pro vypořádání plateb se zpomaluje. Transakce neselhávají úplně, ale trvají třikrát déle, než umožňuje dohoda o úrovni služeb. SOC zaznamenává neobvyklé pokusy o autentizaci vůči administrátorskému účtu. Poskytovatel cloudové infrastruktury hlásí degradovanou službu v jedné zóně dostupnosti. Zákaznická podpora začíná přijímat hovory od firemních klientů, kteří se ptají, proč dochází ke zpoždění platebních souborů.

Zatím nikdo neví, zda jde o kybernetický útok, selhání provozní odolnosti, výpadek dodavatele, incident v oblasti ochrany soukromí, nebo o vše současně.

Sarah má problém podle DORA dříve, než jsou technická fakta úplná. Je to závažný incident související s IKT? Ovlivňuje kritickou nebo důležitou funkci? Překročil interní prahovou hodnotu závažnosti? Koho je nutné informovat, kdy a s jakými důkazy? Pokud jsou dotčeny osobní údaje, začala běžet také oznamovací lhůta podle GDPR? Pokud je součástí řetězce incidentu poskytovatel IKT služeb z řad třetích stran, kdo odpovídá za fakta?

Právě zde finanční subjekty zjišťují rozdíl mezi tím, že mají plán reakce na incidenty, a tím, že mají auditovatelný provozní model pro hlášení incidentů podle DORA.

Hlášení incidentů podle DORA v roce 2026 vyžaduje více než rychlou eskalaci. Vyžaduje obhajitelný řetězec od detekce ke klasifikaci, od klasifikace k hlášení orgánu dohledu, od hlášení k nápravě a od nápravy k získaným poznatkům. ISO/IEC 27001:2022 poskytuje strukturu systému řízení. Opatření přílohy A ISO/IEC 27002:2022 poskytují praktická očekávání vůči opatřením. Politiky Clarysec, 30krokový plán a průvodce křížovým souladem převádějí tato očekávání do implementace připravené na důkazy.

Proč hlášení incidentů podle DORA pod tlakem selhává

Většina selhání při hlášení incidentů podle DORA nezačíná nedbalostí. Začíná nejasností.

Bezpečnostní analytik vidí upozornění, ale neví, zda se podle DORA kvalifikuje jako incident související s IKT. Manažer IT služeb považuje degradovaný výkon za technický problém služby, zatímco compliance jej považuje za regulatorní událost. Právní oddělení čeká na potvrzení, než eskaluje. Vlastník obchodního procesu zatím nedokáže vyčíslit dopad na klienty. CISO chce důkazy, ale relevantní logy jsou rozptýlené napříč cloudovými službami, koncovými body, systémy identit, SIEM a platformami dodavatelů.

Než se organizace shodne na klasifikaci, oznamovací lhůta je již pod tlakem.

Články DORA 17 až 21 vytvářejí strukturované očekávání pro řízení incidentů souvisejících s IKT, klasifikaci, hlášení, obsah hlášení a postup orgánů dohledu. Pro finanční subjekty je praktický požadavek jasný: monitorovat, řídit, protokolovat, klasifikovat, hlásit, aktualizovat a vyvozovat poučení z incidentů souvisejících s IKT způsobem, který lze později rekonstruovat.

Politika reakce na incidenty [IRP] společnosti Clarysec začleňuje DORA přímo do referenčního rámce:

DORA EU (2022/2554): Článek 17: požadavky na hlášení IKT incidentů finančními institucemi příslušným orgánům.

Stejná politika propojuje řízení incidentů s opatřeními ISO/IEC 27002:2022 5.25 až 5.27, která pokrývají odpovědnosti za posouzení incidentu, reakci, komunikaci a zlepšování.

Pro menší finančně-technologické společnosti a štíhlé regulované subjekty převádí Politika reakce na incidenty - SME [IRP-SME] společnosti Clarysec tuto povinnost do praxe tím, že zdůrazňuje, že DORA vyžaduje, aby finanční subjekty incidenty a narušení související s IKT klasifikovaly, hlásily a sledovaly.

Na této formulaci záleží. Soulad s DORA není pouze šablona hlášení. Organizace musí klasifikovat, hlásit a sledovat. To znamená důkazy o počáteční události, rozhodovacích kritériích, úrovni závažnosti, rozhodnutí o hlášení, komunikaci, opatřeních obnovy, zapojení dodavatele a následných krocích.

ISO/IEC 27001:2022 jako řídicí centrum incidentů podle DORA

Vyspělý systém řízení bezpečnosti informací (ISMS) podle ISO/IEC 27001:2022 se nemá stát dalším izolovaným compliance systémem vedle DORA. Má fungovat jako řídicí centrum pro hlášení incidentů podle DORA.

ISMS již vyžaduje vlastnictví rizik, výběr bezpečnostních opatření, interní audit, přezkoumání vedením, dokumentované informace, neustálé zlepšování a důkazy o fungování opatření. DORA přidává sektorově specifický tlak na hlášení, ale ISO/IEC 27001:2022 poskytuje strukturu správy a řízení, která umožňuje proces opakovaně a konzistentně provádět.

Zenith Blueprint: 30krokový plán auditora [ZB] společnosti Clarysec tuto integraci posiluje v kroku 13, Plánování ošetření rizik a Prohlášení o použitelnosti. Blueprint doporučuje mapovat opatření na rizika a ustanovení kvůli dohledatelnosti, včetně doplnění odkazu na opatření přílohy A k rizikům a poznámky, kdy opatření podporují GDPR, NIS2 nebo DORA.

U incidentu Sarah týkajícího se vypořádání plateb by záznam v registru rizik mohl znít:

„Narušení nebo kompromitace platformy pro zpracování plateb.“

Namapovaná opatření přílohy A ISO/IEC 27001:2022 by zahrnovala 5.24, 5.25, 5.26, 5.27, 5.28, 6.8, 8.15 a 8.16 s poznámkou DORA ke klasifikaci a hlášení závažného incidentu souvisejícího s IKT.

Zenith Controls: Průvodce křížovým souladem [ZC] společnosti Clarysec poté slouží jako kompas křížového souladu. V Zenith Controls Clarysec mapuje opatření ISO/IEC 27002:2022 na další opatření ISO/IEC 27001:2022, související normy, auditní očekávání a právní předpisy, jako jsou DORA, GDPR a NIS2. Nevytváří samostatná „Zenith controls“. Ukazuje, jak stávající opatření ISO fungují společně a jak jsou testována.

Pracovní postup hlášení podle DORA lze chápat jako řetězec opatření:

Nemůžete hlásit to, co jste nedetekovali. Nemůžete klasifikovat to, co jste neposoudili. Nemůžete obhájit rozhodnutí o hlášení bez záznamů. Nemůžete se zlepšit bez přezkoumání po incidentu.

Opatření 6.8: Lhůta podle DORA začíná u lidí

Ve scénáři Sarah nemusí první užitečný signál přijít ze SOC. Může přijít od relationship manažera, který slyší stížnosti klientů, od pracovníka financí, který vidí selhané dávky vypořádání, nebo od inženýra, který zaznamená abnormální latenci.

Proto je opatření 6.8 přílohy A ISO/IEC 27001:2022, hlášení událostí informační bezpečnosti, pro DORA zásadní. Z hlášení činí odpovědnost pracovníků, nikoli pouze funkci bezpečnostního provozu.

V Zenith Blueprint, kroku 16, People Controls II, Clarysec uvádí:

Účinný systém reakce na incidenty nezačíná nástroji, ale lidmi.

Krok 16 doporučuje jasné kanály pro hlášení, školení povědomí, kulturu bez obviňování, triáž, důvěrnost a pravidelné simulace. Nejužitečnější praktické sdělení je jednoduché:

„Pokud máte pochybnosti, hlaste.“

To je princip opatření podle DORA. Pokud zaměstnanci čekají, dokud si nejsou jisti, organizace ztrácí čas. Pokud hlásí včas, organizace může posoudit, klasifikovat a rozhodnout.

V Zenith Controls je 6.8 namapováno jako detekční opatření podporující důvěrnost, integritu a dostupnost. Navazuje na 5.24, protože kanály pro hlášení musí být součástí incidentního plánu. Napájí 5.25, protože události lze posoudit pouze tehdy, jsou-li nahlášeny. Spouští 5.26, protože formální reakce začíná po vyhodnocení hlášení.

Pro DORA to podporuje články 17 a 18, podle nichž finanční subjekty musí řídit, klasifikovat a hlásit závažné incidenty související s IKT a významné kybernetické hrozby. Podporuje také GDPR Article 33 a Recital 85, protože interní hlášení určuje, jak rychle je identifikováno a eskalováno porušení zabezpečení osobních údajů.

Praktickou implementací Clarysec je jednostránkový pokyn „Jak hlásit IKT incident“. Měl by obsahovat:

• Co hlásit, včetně výpadků, podezřelých e-mailů, ztracených zařízení, neobvyklého chování systémů, podezření na kompromitaci dodavatele, neoprávněného přístupu, úniku dat a degradace služeb s dopadem na klienty.
• Jak hlásit, a to prostřednictvím monitorované poštovní schránky, kategorie záznamu v systému pro správu incidentů, horké linky, kanálu pro spolupráci nebo portálu SOC.
• Co uvést, například čas, systém, uživatele, obchodní proces, pozorovaný dopad, snímky obrazovky, pokud je to bezpečné, a zda mohou být dotčeni klienti nebo osobní údaje.
• Co nedělat, včetně nemazání logů, nerestartování kritických systémů bez pokynu, nekontaktování klientů externě bez schválení a neprovádění vyšetřování nad rámec své role.
• Co následuje, včetně triáže, klasifikace, eskalace, reakce, uchování důkazů a případného regulatorního posouzení.

Cílem není udělat z každého zaměstnance vyšetřovatele. Cílem je, aby byl každý zaměstnanec spolehlivým zdrojem signálu.

Opatření 5.25: Rozhodovací bod klasifikace podle DORA

Hlášení závažných incidentů souvisejících s IKT podle DORA stojí na klasifikaci. Zde se ústředním stává opatření 5.25 přílohy A ISO/IEC 27001:2022, posuzování událostí informační bezpečnosti a rozhodování o nich.

Zenith Blueprint, krok 23, vysvětluje praktickou výzvu:

Ne každá anomálie je katastrofa. Ne každé upozornění signalizuje kompromitaci.

Následně popisuje účel 5.25 takto:

odlišit neškodné od škodlivého a vědět, co vyžaduje eskalaci.

Pro DORA je to okamžik, kdy se bezpečnostní událost, degradace služby, výpadek dodavatele, expozice dat nebo provozní narušení posuzuje proti kritériím závažného incidentu. Organizace musí zohlednit provozní dopad, dotčené služby, kritické nebo důležité funkce, dotčené klienty a transakce, dobu trvání, geografický rozsah, dopad na data, reputační důsledky a ekonomický dopad.

V Zenith Controls je 5.25 přímo namapováno na DORA Article 18, klasifikaci závažných IKT incidentů. Jde o strukturovaný hodnoticí proces pro určení, zda se pozorovaná událost kvalifikuje jako bezpečnostní incident. Navazuje také na 8.16, monitorovací činnosti, protože upozornění a logová data musí projít triáží, a na 5.26, protože klasifikace spouští reakci.

Právě zde mnoho organizací u auditů selhává. Mají záznamy v systému pro správu incidentů, ale ne klasifikační záznamy. Mají štítky závažnosti, ale ne kritéria. Mají regulatorní hlášení, ale ne rozhodovací stopu prokazující, proč incident byl nebo nebyl považován za závažný.

Clarysec to řeší začleněním klasifikace podle DORA do modelu závažnosti incidentů. V podnikové Politice reakce na incidenty obsahuje ustanovení 5.3.1 jasný příklad úrovně Tier 1:

Tier 1: Kritický (např. potvrzené porušení zabezpečení dat, propuknutí ransomwaru, kompromitace produkčního systému)

Pro menší organizace přidává Politika reakce na incidenty - SME přesný provozní požadavek:

Generální ředitel musí se vstupem od poskytovatele IT služeb klasifikovat všechny incidenty podle závažnosti do jedné hodiny od oznámení.

Tento jednohodinový cíl klasifikace je účinný, protože vynucuje disciplínu správy a řízení. Menší regulovaný subjekt nemusí mít SOC v režimu 24/7, ale stále může určit, kdo klasifikuje, kdo poskytuje doporučení a jak rychle musí rozhodnutí proběhnout.

Záznam triáže incidentu DORA-to-ISO

Aby byla klasifikace obhajitelná, vytvořte záznam triáže incidentu podle DORA ve svém systému pro správu incidentů, platformě GRC nebo systému řízení incidentů. Záznam má být vytvořen pro každou potenciálně významnou událost v oblasti IKT, i když je později snížena její závažnost.

Přidejte poznámku k rozhodnutí:

„Na základě narušení platební služby ovlivňující kritický obchodní proces, nevyřešené kořenové příčiny a potenciálního dopadu na klienty je událost eskalována jako potenciální závažný incident související s IKT. Compliance a právní oddělení posoudí požadavky na regulatorní oznámení. Zahájeno uchování důkazů.“

Tento jediný záznam podporuje sledování podle DORA Article 17, klasifikaci podle Article 18, rozhodnutí o hlášení podle Article 19, posouzení podle přílohy A ISO/IEC 27001:2022 5.25, hlášení podle 6.8, reakci podle 5.26 a nakládání s důkazy podle 5.28.

Opatření 5.24 a 5.26: Plánování, role a reakce

Když nastane incident podle DORA, plán reakce již musí odpovídat na nepříjemné otázky.

Kdo má pravomoc klasifikovat? Kdo kontaktuje příslušný orgán? Kdo schvaluje počáteční oznámení? Kdo komunikuje s klienty? Kdo kontaktuje poskytovatele IKT služeb z řad třetích stran? Kdo rozhoduje, zda incident zároveň spouští oznámení podle GDPR? Kdo uchovává důkazy? Kdo odpovídá za závěrečnou zprávu?

Opatření 5.24 přílohy A ISO/IEC 27001:2022, plánování a příprava řízení incidentů informační bezpečnosti, odpovídá na tyto otázky před krizí. Opatření 5.26, reakce na incidenty informační bezpečnosti, zajišťuje, že se plán během incidentu promění v řízenou činnost.

V Zenith Controls je 5.24 navázáno na články DORA 17 až 21, protože uvádí do provozu dokumentovanou, testovanou a přezkoumávanou reakci na incidenty, včetně interní eskalace, externího regulatorního oznámení, komunikace se zainteresovanými stranami a získaných poznatků.

ISO/IEC 27035-1:2023 to podporuje tím, že rozšiřuje řízení incidentů nad rámec postupů reakce na politiku, plánování, schopnosti, vztahy, podpůrné mechanismy, povědomí, školení a pravidelné testování. ISO/IEC 27035-2:2023 dále podrobně popisuje proces řízení incidentů od přípravy až po získané poznatky.

Zenith Blueprint, krok 23, uvádí přímý implementační pokyn:

Zajistěte, aby byl váš plán reakce na incidenty (5.24) aktuální a pokrýval přípravu, eskalaci, reakci a komunikaci.

Plán reakce na incidenty připravený na DORA by měl definovat:

• Tým reakce na IKT incidenty a zástupce.
• Pravomoc pro klasifikaci závažnosti a eskalaci hlášení podle DORA.
• Odpovědnosti právního oddělení, compliance, ochrany soukromí, komunikace, IT, bezpečnosti, dodavatele a vlastníka obchodního procesu.
• Kritéria pro klasifikaci závažného incidentu souvisejícího s IKT.
• Postupy pro počáteční, průběžné a závěrečné regulatorní hlášení.
• Posouzení oznamovacích spouštěčů podle GDPR, NIS2, smluv, kybernetického pojištění a vůči orgánům dohledu.
• Kroky zamezení šíření, eradikace, obnovy a ověření.
• Požadavky na uchování důkazů.
• Postupy eskalace vůči dodavatelům a přístupu k logům.
• Sledování získaných poznatků a nápravných opatření.

Politika reakce na incidenty - SME také propojuje lhůty reakce 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 požadavkem GDPR na oznámení porušení zabezpečení osobních údajů do 72 hodin.

To je zásadní, protože jeden IKT incident se může stát závažným incidentem podle DORA, porušením zabezpečení osobních údajů podle GDPR, významným incidentem podle NIS2, smluvní oznamovací událostí vůči klientovi a otázkou řízení dodavatelů. Plán musí tyto vrstvy koordinovat, nikoli s nimi zacházet jako s oddělenými světy.

Opatření 8.15 a 8.16: Logy činí hlášení obhajitelným

Hlášení incidentů podle DORA závisí na faktech. Fakta závisí na protokolování a monitorování.

Ve scénáři vypořádání plateb potřebuje Sarah vědět, kdy degradace začala, které systémy byly dotčeny, zda byly použity privilegované účty, zda data opustila prostředí, zda výpadek cloudového poskytovatele odpovídá interní telemetrii a kdy byla obnova dokončena.

Opatření 8.15, protokolování, a 8.16, monitorovací činnosti, přílohy A ISO/IEC 27001:2022 podporují tuto důkazní základnu. V Zenith Controls se obě propojují s 5.24, protože plánování reakce na incidenty musí zahrnovat použitelná logová data a monitorovací schopnosti. Opatření 8.16 se také propojuje s 5.25, protože upozornění musí být triážována do rozhodnutí.

Politika protokolování a monitorování - SME [LMP-SME] společnosti Clarysec obsahuje praktický požadavek na eskalaci:

Upozornění s vysokou prioritou musí být eskalována na GM a koordinátora ochrany soukromí do 24 hodin

U subjektů regulovaných DORA potenciálně závažné IKT incidenty obvykle vyžadují rychlejší provozní model eskalace, zejména pokud jsou dotčeny kritické nebo důležité funkce. Vzor správy a řízení je však správný: upozornění s vysokou prioritou nesmí zůstat uvnitř IT. Musí se dostat k obchodním, privacy a řídicím rolím.

Model protokolování připravený na DORA by měl zahrnovat:

• Centralizované protokolování pro kritické systémy, platformy identit, koncové body, cloudové služby, nástroje zabezpečení sítí a podnikové aplikace.
• Synchronizaci času napříč systémy, aby byly časové osy incidentů spolehlivé.
• Kategorizaci upozornění sladěnou se závažností incidentu a klasifikací DORA.
• Uchovávání logů sladěné s regulatorními, smluvními a forenzními potřebami.
• Řízení přístupu chránící integritu logů.
• Postupy pro pořizování snapshotů logů během závažných incidentů.
• Požadavky na přístup k logům dodavatelů u kritických IKT služeb.

Auditoři nepřijmou tvrzení „SIEM to má“ jako dostatečný důkaz. Budou se ptát, zda existovaly správné logy, zda byla upozornění přezkoumána, zda eskalace proběhla včas a zda byly logy uchovány, jakmile se incident stal potenciálně hlásitelným.

Opatření 5.28: Shromažďování důkazů a řetězec opatrování

U závažného incidentu souvisejícího s IKT slouží důkazy třem účelům: technickému vyšetřování, regulatorní odpovědnosti a právní obhajitelnosti.

Pokud jsou důkazy neúplné, přepsané, změněné nebo nedokumentované, organizace může mít potíže prokázat, co se stalo. Může mít také potíže obhájit své klasifikační rozhodnutí.

Politika shromažďování důkazů a forenzního šetření [ECF] společnosti Clarysec uvádí:

Log řetězce opatrování musí doprovázet veškeré fyzické nebo digitální důkazy od okamžiku získání přes archivaci nebo předání a musí dokumentovat:

Verze pro SME, Politika shromažďování důkazů a forenzního šetření - SME [ECF-SME], ponechává požadavek jednoduchý:

Každá položka digitálních důkazů musí být zaznamenána s:

Provozní poučení je přímé. Nakládání s důkazy nemůže začít až poté, co si je vyžádá právní oddělení. Musí být začleněno do reakce na incidenty.

ISO/IEC 27006-1:2024 posiluje toto auditní očekávání zdůrazněním postupů pro identifikaci, shromažďování a uchování důkazů z incidentů informační bezpečnosti. U DORA může stejná sada důkazů podporovat počáteční oznámení, průběžné aktualizace, závěrečnou zprávu, přezkoumání po incidentu a dotazy orgánu dohledu.

Praktický kontrolní seznam důkazů pro incidenty související s DORA by měl zahrnovat:

• Záznam o incidentu a poznámky z triáže.
• Časovou osu detekce, eskalace, klasifikace, hlášení, zamezení šíření, obnovy a uzavření.
• Upozornění SIEM a korelované logy.
• Artefakty koncových bodů a serverů.
• Logy identit a privilegovaného přístupu.
• Souhrny síťového provozu.
• Stav cloudového poskytovatele a auditní logy.
• Komunikaci s dodavateli a prohlášení k incidentu.
• Záznamy o dopadu na obchodní činnost, včetně klientů, služeb, transakcí a nedostupnosti.
• Návrhy a podání regulatorních oznámení.
• Rozhodnutí a schválení vedení.
• Analýzu kořenové příčiny.
• Získané poznatky a nápravná opatření.

Důkazy musí ukazovat technická fakta i rozhodnutí v oblasti správy a řízení. Hlášení podle DORA není pouze o tom, co se stalo systémům. Je také o tom, jak vedení incident rozpoznalo, posoudilo, eskalovalo, řídilo a jak se z něj poučilo.

Opatření 5.27: Získané poznatky a neustálé zlepšování

Incident podle DORA není uzavřen, když je podána závěrečná zpráva. Je uzavřen tehdy, když se z něj organizace poučila, přiřadila nápravná opatření, aktualizovala opatření a ověřila zlepšení.

Opatření 5.27 přílohy A ISO/IEC 27001:2022, učení se z incidentů informační bezpečnosti, propojuje hlášení podle DORA s cyklem neustálého zlepšování ISO/IEC 27001:2022. V Zenith Controls je 5.24 propojeno s 5.27, protože řízení incidentů je neúplné bez analýzy kořenové příčiny, získaných poznatků a zlepšování opatření.

Zenith Blueprint, krok 23, ukládá organizacím aktualizovat plán na základě získaných poznatků a zajistit cílené školení v oblasti reakce na incidenty a nakládání s důkazy. To je u DORA obzvlášť důležité, protože opakující se zpoždění klasifikace, chybějící důkazy dodavatelů, slabé logy nebo nejasná komunikace se mohou stát předmětem zájmu orgánu dohledu.

Šablona získaných poznatků by měla zachytit:

• Co se stalo a kdy.
• Které kritické nebo důležité funkce byly dotčeny.
• Zda byla klasifikace včasná a přesná.
• Zda byla rozhodnutí o hlášení podle DORA učiněna s dostatečnými důkazy.
• Zda byly posouzeny spouštěče oznámení podle GDPR, NIS2, smluv nebo vůči klientům.
• Zda dodavatelé reagovali v dohodnutých lhůtách.
• Zda byly uchovány logy a forenzní důkazy.
• Která opatření selhala nebo chyběla.
• Které politiky, playbooky, školení nebo technická opatření musí být zlepšeny.
• Kdo vlastní každé nápravné opatření a do kdy.

To se promítá také do přezkoumání ISMS vedením podle ISO/IEC 27001:2022. Trendy incidentů má přezkoumávat vedení, nemají zůstat pohřbeny v technických rozborech po incidentech.

Křížový soulad: DORA, GDPR, NIS2, NIST a COBIT 2019

DORA je pro finanční subjekty hlavním tématem, ale hlášení incidentů jen zřídka patří pouze do jednoho rámce.

Jeden IKT incident může zahrnovat hlášení závažného incidentu souvisejícího s IKT podle DORA, oznámení porušení zabezpečení osobních údajů podle GDPR, hlášení významného incidentu podle NIS2, smluvní povinnosti vůči zákazníkům, oznámení kybernetické pojišťovně a reporting orgánům dohledu.

Zenith Controls pomáhá tuto složitost snižovat mapováním opatření ISO/IEC 27002:2022 napříč rámci. Například:

Z pohledu NIST stejný model podporuje výsledky Detect, Respond a Recover. Z pohledu COBIT 2019 a auditu ISACA je hlavním tématem správa a řízení: zda jsou řízení incidentů, kontinuita, rizika, soulad, odpovědnosti dodavatelů a monitorování výkonnosti pod kontrolou.

Nejvyspělejší organizace nevytvářejí samostatné pracovní postupy pro každý rámec. Vytvářejí jeden proces řízení incidentů s regulatorními vrstvami. Záznam zachytí stejná základní fakta jednou a poté se podle potřeby větví na hlášení podle DORA, GDPR, NIS2, smluv, pojištění nebo sektorově specifických požadavků.

Jak auditoři otestují váš proces incidentů podle DORA

Proces hlášení incidentů připravený na DORA musí obstát při různých auditních pohledech.

Auditor ISO/IEC 27001:2022 bude zkoumat, zda ISMS vybral a implementoval relevantní opatření přílohy A, zda Prohlášení o použitelnosti tato opatření podporuje, zda existují záznamy o incidentech a zda interní audit a přezkoumání vedením zahrnují výkonnost incidentního procesu.

Zenith Controls pro 5.24, 5.25 a 6.8 cituje metodiku auditu ISO/IEC 19011:2018. U 5.24 auditoři zkoumají plán reakce na incidenty z hlediska typů incidentů, klasifikací závažnosti, přiřazených rolí, seznamů kontaktů, eskalačních cest, instrukcí pro regulatorní hlášení a komunikačních odpovědností. U 5.25 zkoumají, zda existují dokumentovaná klasifikační kritéria, například matice závažnosti nebo rozhodovací stromy založené na dopadu na systém, citlivosti dat a době trvání. U 6.8 posuzují mechanismy hlášení, metriky času do nahlášení a důkazy, že nahlášené události jsou protokolovány, triážovány a vyřešeny.

Dohledový přezkum podle DORA se zaměří na to, zda jsou závažné incidenty související s IKT detekovány, klasifikovány, hlášeny, aktualizovány a uzavírány podle regulatorních očekávání. Přezkoumávající osoba může požádat o vzorový incident a sledovat jej od prvního upozornění až po závěrečnou zprávu.

Auditor ochrany soukromí se zaměří na to, zda bylo posouzeno riziko porušení zabezpečení osobních údajů a zda byly spuštěny povinnosti podle GDPR Article 33 a Article 34. BS EN 17926:2023 je zde relevantní, protože doplňuje odpovědnosti v oblasti privacy incidentů, kritéria oznámení, načasování a sladění s očekáváními ohledně oznámení orgánu dohledu.

Stejné důkazy mohou zodpovědět více auditních otázek, pokud jsou od začátku správně strukturovány.

Kontrolní seznam připravenosti hlášení incidentů podle DORA pro rok 2026

Před dalším tabletop cvičením, interním auditem nebo dohledovým přezkumem otestujte svou organizaci podle tohoto kontrolního seznamu:

• Vědí zaměstnanci, jak hlásit podezřelé IKT incidenty?
• Existuje samostatný kanál pro hlášení incidentů?
• Jsou bezpečnostní události konzistentně protokolovány a triážovány?
• Existuje dokumentovaná matice závažnosti a klasifikace závažných incidentů podle DORA?
• Je klasifikace vyžadována v definovaném čase po oznámení?
• Jsou kritické nebo důležité funkce namapovány na systémy a dodavatele?
• Jsou spouštěče oznámení podle DORA, GDPR, NIS2, smluv, pojištění a vůči klientům posuzovány v jednom pracovním postupu?
• Jsou role v incidentním procesu definovány napříč IT, bezpečností, právním oddělením, compliance, ochranou soukromí, komunikací a vlastníky obchodních procesů?
• Jsou logy dostatečné k rekonstrukci časových os incidentů?
• Jsou důkazy uchovávány s řetězcem opatrování?
• Jsou testovány incidentní povinnosti dodavatelů a práva přístupu k logům?
• Probíhají tabletop cvičení s realistickými scénáři DORA?
• Jsou získané poznatky sledovány až k nápravným opatřením?
• Jsou metriky incidentů přezkoumávány v rámci přezkoumání vedením?
• Je Prohlášení o použitelnosti namapováno na opatření ISO/IEC 27001:2022 relevantní pro DORA?

Pokud je odpověď na cokoli z toho „částečně“, nejde pouze o problém souladu. Jde o provozní odolnost.

Vybudujte model hlášení incidentů podle DORA připravený na důkazy

Hlášení incidentů podle DORA v roce 2026 je testem správy a řízení pod tlakem. Organizace, které obstojí, nebudou ty s nejdelšími dokumenty reakce na incidenty. Budou to ty, které mají jasné kanály pro hlášení, rychlou klasifikaci, spolehlivé logy, uchované důkazy, vyškolené lidi, otestovanou eskalaci vůči dodavatelům a dohledatelnost napříč rámci.

Clarysec vám může pomoci tento provozní model vybudovat.

Začněte mapováním incidentních rizik a Prohlášení o použitelnosti pomocí Zenith Blueprint: 30krokového plánu auditora. Poté slaďte svá incidentní opatření s Zenith Controls: Průvodcem křížovým souladem. Uveďte proces do provozu pomocí Politiky reakce na incidenty, Politiky reakce na incidenty - SME, Politiky protokolování a monitorování - SME, Politiky shromažďování důkazů a forenzního šetření a Politiky shromažďování důkazů a forenzního šetření - SME společnosti Clarysec.

Pokud chce váš tým vedení získat jistotu před dalším skutečným incidentem, proveďte tabletop cvičení závažného incidentu souvisejícího s IKT podle DORA s nástroji Clarysec a vytvořte balíček důkazů, který by auditor nebo orgán dohledu očekával.