DORA platí od januára 2025. Rok uplynul. Väčšina regulovaných inštitúcií má „splnené“. Incident response plán existuje, eskalačná matica je podpísaná, procesy sú opísané.
Lenže realita má jeden nepríjemný test.
Keď systém skutočne padne, zistíte či proces funguje – alebo len leží v šanóne. Poznáte ten moment: ľudia sa zídu na call, niekto hľadá „aktuálnu verziu“ dokumentu, niekto sa snaží dovolať dodávateľovi a popri tom tikajú lehoty.
Vtedy sa papierová pripravenosť rozbije veľmi rýchlo.
Čo DORA reálne vyžaduje od incident response
DORA nie je smernica. Je to nariadenie – priamo aplikovateľné, bez priestoru na voľnú interpretáciu.
V incident response sa to láme na troch veciach.
Klasifikácia incidentu podľa jasných pravidiel.
Nestačí povedať „máme incident“. Musíte vedieť kto rozhoduje o závažnosti, podľa akých kritérií a mať z toho záznam. Inak sa to v krízovom momente zmení na dohadovanie.
Reportovanie v lehotách ktoré vie regulátor overiť.
Nejde len o to niečo nahlásiť. Ide o to preukázať že ste incident identifikovali, posúdili dopad, rozhodli o eskalácii a splnili oznamovacie povinnosti v stanovených časoch.
Preukázateľná funkčnosť procesu.
Regulátor nechce len papier. Chce dôkazy že proces žije – časová os incidentu, záznam z incident callu, klasifikácia s odôvodnením, komunikácia smerom k vedeniu aj regulátorovi, post incident review s konkrétnymi opatreniami.
Ak toto neviete vytiahnuť na stôl – máte dokument, nie funkčný proces.
Kde firmy najčastejšie zlyhávajú
Aj po 25 rokoch v IT ma niektoré veci stále prekvapujú. Eskalačné matice ktoré nikto neprešiel
Dokument existuje. Kontakty sú zapísané. Ale nikto nikdy neoveril či sú aktuálne – a či dotyční ľudia vedia že tam sú.
Príklad z praxe: eskalácia smeruje na Technického riaditeľa dodávateľa. Incident nastane. Voláme. Dotyčný nevie o čom hovoríme – nikto ho o tejto roli nikdy neinformoval.
Vendor manažment na papieri
DORA explicitne rieši tretie strany. Mnoho firiem má zmluvne ošetrené SLA a bezpečnostné požiadavky. Málokto však vie odpovedať na jednoduchú otázku: keď to horí – kto u dodávateľa rozhoduje, kto je dostupný, ako prebieha spoločná triáž?
Ak toto nie je natrénované, zmluva vám v prvých hodinách nepomôže.
Plánované testy ktoré sa nekonajú. Tabletop cvičenie prebehlo raz pri implementácii. Odvtedy nič. Kontakty sa neoverujú. Scenáre sa nerevidujú.
Proces sa netestuje preto že funguje. Testuje sa preto aby sme zistili kde nefunguje.
Ako to otestovať bez toho aby ste spustili chaos
Testovanie incident response nemusí znamenať simuláciu plného výpadku produkcie. Tri prístupy ktoré fungujú aj v bežnej prevádzke.
Tabletop cvičenie
Posadíte kľúčových ľudí – interných aj zástupcov kritických dodávateľov. Prechádzate scenár od prvého signálu až po stabilizáciu. Kto spúšťa incident režim? Kto klasifikuje závažnosť? Kto komunikuje smerom k regulátorovi?
Cieľ nie je spraviť to pekne. Cieľ je nájsť slabé miesta.
Verifikácia eskalačnej matice
Nie audit dokumentu. Reálne overenie – zavolajte kontaktom ktoré máte zapísané. Zistite či vedia že tam sú, či majú prístupy ktoré budú potrebovať a či máte funkčný komunikačný kanál vrátane out of band variantu.
Znie to triviálne. Výsledky väčšinou nie sú.
Čiastočný test s dodávateľom
Vyberte jedného kritického dodávateľa. Dohodnite si plánovaný scenár – nie prekvapivý test. Preverte spoločnú triáž, eskaláciu a tok informácií.
Zistíte viac ako z akejkoľvek SLA dokumentácie. Najmä v prvých hodinách incidentu – ktoré sú pre DORA reporting rozhodujúce.
Dokument vás nezachráni. Proces áno.
DORA od vás nežiada dokumentáciu. Žiada aby ste vedeli čo má každý robiť – a žiada aby ste to mali otestované a verifikované.
Ak dnes neviete jasne odpovedať na tieto otázky, je čas to zistiť: Kto klasifikuje incident a na základe čoho? Ako rýchlo viete spustiť incident režim a zapojiť dodávateľov? Aké dôkazy viete predložiť z testov aj z reálnych udalostí? Sú kontakty, roly a prístupy overené a aktuálne?
Lepšie je nájsť slabé miesto pri plánovanom teste – než pri reálnom incidente alebo pri kontrole regulátora.
