Klasifikácia závažnosti incidentov pre DORA, NIS2 a GDPR

Telefonát o incidente o 02:17, z ktorého sa stane regulačné rozhodnutie

Vo štvrtok ráno o 02:17 Sarah, CISO spoločnosti FinScale, vidí prvé upozornenie: anomálnu API prevádzku, prudký nárast zlyhaní autentifikácie a latenciu platobného dashboardu nad 3000 ms. V priebehu niekoľkých minút zákaznícka podpora hlási chyby stavu platieb. Cloudový poskytovateľ uvádza, že nejde o incident na úrovni celej platformy. SOC vidí podozrivé prístupové tokeny z dvoch geografických regiónov. Produktový tím potvrdzuje, že dashboard je po 19 minútach opäť dostupný, no dvanásť zákazníkov už otvorilo tickety.

O 03:05 je Sarah na krízovom koordinačnom hovore s koordinátorom incidentu, právnikom, koordinátorom ochrany súkromia, vedúcim cloudovej prevádzky a výkonným garantom. Technická otázka je pomerne jasná: čo sa stalo s API bránou? Regulačné otázky sú ťažšie:

1. Ide o závažný incident súvisiaci s IKT podľa DORA?
2. Ide o významný incident podľa NIS2?
3. Došlo k porušeniu ochrany osobných údajov podľa GDPR, ktoré vyžaduje oznámenie?
4. Dokáže organizácia preukázať, ako k týmto odpovediam dospela?

Nesprávna odpoveď môže vytvoriť regulačnú expozíciu. Pomalá odpoveď môže znamenať zmeškanie oznamovacej lehoty. Nezdokumentovaná odpoveď môže o niekoľko mesiacov neskôr zlyhať pri audite ISO/IEC 27001:2022.

Toto je výzva reakcie na incidenty v roku 2026. Mnohé organizácie majú plán reakcie na incidenty, forenzné postupy, playbooky ochrany súkromia a šablóny krízovej komunikácie. Menej organizácií má obhájiteľný model klasifikácie závažnosti incidentov, ktorý premieňa chaotickú bezpečnostnú udalosť na zdokumentované rozhodnutie naprieč DORA, NIS2, GDPR a dôkazovými očakávaniami ISO/IEC 27001:2022.

Riešením nie sú tri samostatné procesy triáže. Riešením je jeden riadený model závažnosti so samostatnými regulačnými vrstvami, merateľnými prahovými hodnotami, pravidlami eskalácie, záznamami rozhodnutí a požiadavkami na zber dôkazov. V praxi závažnosť incidentu nemá byť označenie vybrané pod tlakom. Má ísť o riadené rozhodnutie organizácie, ktoré obstojí pred regulátormi, audítormi, členmi riadiaceho orgánu, zákazníkmi a zodpovednou osobou.

Prečo je klasifikácia závažnosti incidentov opatrením na úrovni riadiaceho orgánu

Klasifikácia incidentov bola kedysi najmä technická: závažnosť malvéru, dotknutí hostitelia, zneužité zraniteľnosti a otázka, či došlo k exfiltrácii údajov. V roku 2026 je zároveň právna, finančná, spoločenská a zmluvná.

DORA mení digitálnu prevádzkovú odolnosť na povinnosť správy a riadenia pre finančné subjekty. Riadiaci orgán má definovať, schvaľovať a dohliadať na rámec riadenia IKT rizík a zároveň zaň niesť zodpovednosť. To zahŕňa kontinuitu činností v oblasti IKT, plány reakcie a obnovy, kanály na hlásenie závažných incidentov, riziko tretích strán v oblasti IKT a získané poznatky.

NIS2 zvyšuje význam správy a riadenia pre základné a dôležité subjekty. Article 20 vyžaduje, aby riadiace orgány schvaľovali opatrenia riadenia kybernetických rizík, dohliadali na ich implementáciu a absolvovali školenie. Zároveň spája zlyhania v riadení rizík a nahlasovaní incidentov so závažnými dôsledkami dohľadu. Pri základných subjektoch môžu základné úrovne maximálnych správnych pokút dosiahnuť najmenej 10 000 000 EUR alebo 2 percentá celkového celosvetového ročného obratu podľa toho, ktorá hodnota je vyššia. Pri dôležitých subjektoch je základná úroveň najmenej 7 000 000 EUR alebo 1,4 percenta obratu podľa toho, ktorá hodnota je vyššia.

GDPR pridáva odlišnú perspektívu. Porušenie ochrany osobných údajov sa neobmedzuje na potvrdené verejné zverejnenie alebo odcudzené súbory. Zahŕňa náhodné alebo nezákonné zničenie, stratu, zmenu, neoprávnené poskytnutie osobných údajov alebo neoprávnený prístup k nim. Prevádzkovatelia musia posúdiť riziko pre jednotlivcov a preukázať zodpovednosť pri rozhodnutí oznámiť alebo neoznámiť incident.

ISO/IEC 27001:2022 poskytuje týmto povinnostiam dôkazovú oporu. Kapitoly 4.1 až 4.4 vyžadujú, aby organizácia porozumela svojmu kontextu, požiadavkám zainteresovaných strán, rozsahu, rozhraniam a závislostiam. Kapitoly 5.1 až 5.3 vyžadujú záväzok vedenia, politiku, roly, zodpovednosti a reportovanie. Kapitoly 6.1.1 až 6.1.3 vyžadujú plánovanie založené na riziku, posúdenie rizík, ošetrenie rizík a vyhlásenie o uplatniteľnosti (SoA). Kapitoly 8.1 až 8.3 vyžadujú prevádzkové riadenie, riadenie zmien, uchované dôkazy a prehodnotenie pri zmene rizikových podmienok. ISO/IEC 27001:2022

Keď nastane incidentný hovor, otázka nemá znieť: „Kto si myslí, že je to kritické?“ Má znieť: „Čo od nás naše schválené kritériá, právne spúšťače, dôkazy a pravidlá eskalácie vyžadujú urobiť teraz?“

Jedna udalosť, tri regulačné klasifikačné systémy

DORA, NIS2 a GDPR nepoužívajú pre incidenty rovnaký jazyk. To je hlavný dôvod, prečo organizácie zápasia počas prvej hodiny.

DORA Article 17 vyžaduje, aby finančné subjekty zaviedli proces riadenia incidentov súvisiacich s IKT, ktorý deteguje, riadi a oznamuje IKT incidenty, zaznamenáva incidenty súvisiace s IKT a významné kybernetické hrozby, rieši koreňové príčiny, používa ukazovatele včasného varovania, kategorizuje a klasifikuje incidenty, prideľuje roly, riadi komunikáciu, eskaluje závažné incidenty vrcholovému vedeniu a obnovuje bezpečnú prevádzku.

DORA Article 18 vyžaduje klasifikáciu podľa kritérií, ako sú dotknutí klienti, dotknuté protistrany, transakcie, trvanie, výpadok, geografický rozsah, strata údajov ovplyvňujúca dostupnosť, autentickosť, integritu alebo dôvernosť, kritickosť dotknutých služieb a ekonomický dopad. DORA Article 19 vyžaduje hlásenie závažných incidentov súvisiacich s IKT a komunikáciu s klientmi, ak sú dotknuté ich finančné záujmy.

NIS2 Article 23 definuje významný incident ako incident, ktorý spôsobil alebo je schopný spôsobiť závažné narušenie prevádzky alebo finančnú stratu, alebo ovplyvnil či je schopný ovplyvniť iné osoby spôsobením značnej materiálnej alebo nemateriálnej škody. Vyžaduje včasné varovanie do 24 hodín od zistenia významného incidentu, oznámenie incidentu do 72 hodín, priebežné správy na požiadanie a záverečnú správu do jedného mesiaca od oznámenia incidentu. Ak je to uplatniteľné, dotknutí príjemcovia služieb musia byť informovaní aj o opatreniach alebo nápravných prostriedkoch, ktoré môžu prijať.

GDPR kladie otázku rizika pre súkromie. Spôsobilo porušenie bezpečnosti zničenie, stratu, zmenu, neoprávnené poskytnutie osobných údajov alebo neoprávnený prístup k nim? Ak áno, prevádzkovateľ musí posúdiť riziko pre práva a slobody fyzických osôb. Ak je pravdepodobné, že porušenie povedie k riziku, dozorný orgán sa spravidla musí informovať do 72 hodín od zistenia. Ak je pravdepodobné, že povedie k vysokému riziku, dotknuté osoby môže byť potrebné informovať bez zbytočného odkladu.

Jeden incident preto potrebuje súbežnú klasifikáciu.

Pre finančné subjekty je DORA odvetvovo špecifickým právnym aktom Únie pre riadenie IKT rizík a povinnosti nahlasovania incidentov, ktoré sa prekrývajú s NIS2. To neznamená, že NIS2 je irelevantná. Môže byť stále dôležitá pre spoluprácu, informačné toky, služby mimo perimetra DORA, nefinančné subjekty skupiny, cloudové služby, riadené služby a zmluvné povinnosti voči zákazníkom. Model závažnosti má zaznamenať nielen výsledok, ale aj logiku uplatniteľnosti.

Model Clarysec: klasifikujte udalosť, nie emóciu

Clarysec vychádza z ISO/IEC 27002:2022 opatrenia 5.25, posúdenie udalostí informačnej bezpečnosti a rozhodovanie o nich, ako z ukotvenia naprieč požiadavkami súladu. V Zenith Controls: The Cross-Compliance Guide Zenith Controls je táto téma mapovaná cez položku „Posúdenie udalostí informačnej bezpečnosti a rozhodovanie o nich“ pre opatrenie 5.25, podporenú položkami „Plánovanie a príprava riadenia incidentov informačnej bezpečnosti“ pre opatrenie 5.24 a „Zber dôkazov“ pre opatrenie 5.28.

Najdôležitejší okamih z pohľadu súladu často nie je obmedzenie šírenia incidentu. Je to rozhodovací bod, v ktorom sa bezpečnostná udalosť stáva regulačným incidentom, alebo v ktorom je obhájiteľne zaznamenaná ako udalosť s nižšou závažnosťou.

Clarysec Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint opisuje tento okamih vo fáze Uplatnenie opatrení v praxi, krok 23:

„Nie každá anomália je katastrofa. Nie každé upozornenie signalizuje kompromitáciu. V reálnom svete sú bezpečnostné tímy a obchodné jednotky zahltené šumom, pokusmi o prihlásenie, anomáliami logov, drobnými porušeniami politík a aktivitami shadow IT. Skutočná výzva nespočíva iba v detekcii, ale v odlíšení neškodného od škodlivého a v poznaní toho, čo si vyžaduje eskaláciu.“

Táto veta vystihuje prevádzkový problém. Upozornenie zo SIEM sa automaticky nerovná závažnému incidentu podľa DORA. Dočasný výpadok sa automaticky nerovná významnému incidentu podľa NIS2. Podozrivý databázový dotaz sa automaticky nerovná incidentu podliehajúcemu oznámeniu podľa GDPR. Každý z nich sa môže stať hlásiteľným v závislosti od dopadu, rozsahu, údajov, dotknutých strán a dôkazov.

Zenith Blueprint, fáza Riadenie rizík, krok 10, zároveň odporúča prispôsobiť definície dopadu rozsahu podnikania a regulačnej expozícii:

„Pri definovaní dopadu je rozumné vzťahovať úrovne na konkrétny rozsah vášho podnikania. Napríklad: ‚Významný finančný dopad = strata > 100 tis. USD‘ (upravte podľa svojho kontextu). Zohľadnite aj regulačný dopad: napríklad porušenie ochrany osobných údajov môže byť automaticky hodnotené ako ‚významné‘ alebo ‚závažné‘ z dôvodu pokút a oznamovacích povinností podľa GDPR, aj keď priama finančná strata nie je jasná.“

Toto je návrhový princíp klasifikácie závažnosti incidentov pre rok 2026: závažnosť je dopad na organizáciu plus právny dopad plus spoľahlivosť dôkazov.

Praktická taxonómia závažnosti incidentov pre DORA, NIS2 a GDPR

Obhájiteľná taxonómia má oddeliť internú závažnosť od regulačnej klasifikácie. Interná závažnosť riadi naliehavosť reakcie, prideľovanie zdrojov a eskaláciu na vrcholové vedenie. Regulačná klasifikácia riadi oznámenie, právne preskúmanie a externú komunikáciu.

Úroveň internej závažnosti nie je konečnou regulačnou odpoveďou. Je to prevádzkový režim. Udalosť SEV 3 sa po preskúmaní logov môže stať oznamovateľnou podľa GDPR. Výpadok SEV 2 nemusí byť závažným incidentom podľa DORA, ak nie sú splnené prahové hodnoty dopadu. Ransomvérový incident SEV 1 môže súčasne aktivovať DORA, NIS2, GDPR, zákaznícke zmluvy a koordináciu s orgánmi činnými v trestnom konaní.

Podrobnejšia klasifikačná matica pomáha tímu prejsť od upozornenia ku konaniu.

Model musí byť zakotvený v politike, nie ponechaný na najsilnejší hlas na krízovom koordinačnom hovore. SME Incident Response Policy-sme Incident Response Policy-sme - SME, Požiadavky na správu a riadenie, ustanovenie 5.3.1, uvádza:

„Generálny manažér je s prispením poskytovateľa IT služieb povinný klasifikovať všetky incidenty podľa závažnosti do jednej hodiny od oznámenia.“

Tá istá SME politika, Ošetrenie rizík a výnimky, ustanovenie 7.4.1, dodáva:

„Ak sú zapojené údaje zákazníkov, generálny manažér musí posúdiť právne oznamovacie povinnosti na základe uplatniteľnosti GDPR, NIS2 alebo DORA.“

Pre väčšie organizácie podniková Incident Response Policy Incident Response Policy, Požiadavky na správu a riadenie, ustanovenie 5.3, formalizuje rovnaký koncept:

„Klasifikácia incidentov sa musí riadiť viacúrovňovým modelom:“

Jazyk politiky je dôležitý, pretože regulátori a audítori sa budú pýtať, či klasifikačné kritériá existovali pred incidentom. Matica vytvorená dodatočne je slabý dôkaz. Matica, ktorá bola schválená, odškolená, precvičená a konzistentne používaná, je obhájiteľná.

Záznam rozhodnutia: najdôležitejší dôkazový artefakt

Keď audítori, regulátori alebo členovia riadiaceho orgánu preskúmavajú incident, zriedka sa pýtajú iba: „Čo sa stalo?“ Pýtajú sa: „Kedy ste to vedeli, kto rozhodol, na základe akých dôkazov a prečo ste neoznámili skôr?“

Preto Clarysec odporúča viesť záznam rozhodnutia o závažnosti pre každú udalosť SEV 3 a vyššie a pre každú udalosť zahŕňajúcu osobné údaje, kritické služby, finančných zákazníkov, riadené služby, cloudovú infraštruktúru alebo cezhraničný dopad.

Toto sa priamo mapuje na ISO/IEC 27001:2022. Kapitola 8.1 vyžaduje, aby procesy boli plánované, implementované a riadené a aby sa uchovávali dostatočné zdokumentované informácie preukazujúce, že fungovali podľa plánu. Kapitoly 8.2 a 8.3 vyžadujú prehodnotenie pri významných zmenách a uchovávanie dôkazov o ošetrení rizík. Opatrenia prílohy A A.5.24 až A.5.28 tvoria chrbticu riadenia incidentov: plánovanie a prípravu, posúdenie udalosti a rozhodnutie, reakciu, poučenie z incidentov a zber dôkazov.

SME Data Protection and Privacy Policy-sme Data Protection and Privacy Policy-sme - SME, Presadzovanie a súlad, ustanovenie 8.3.2, podporuje GDPR stranu modelu:

„Koordinátor ochrany súkromia určí závažnosť, iniciuje opatrenia na obmedzenie šírenia incidentu a zdokumentuje prípad.“

Posúdenie ochrany súkromia nemá začínať až vtedy, keď sa regulačné hodiny stanú nepríjemnými. Patrí priamo do pracovného toku triáže.

Praktický príklad: klasifikácia incidentu Sarah s API

Vráťme sa k FinScale. Ide o B2B fintech platformu využívajúcu cloudovú infraštruktúru, externého poskytovateľa analytiky podvodov a poskytovateľa riadených bezpečnostných služieb. Pri niektorých činnostiach je finančným subjektom podliehajúcim DORA. Zároveň je poskytovateľom digitálnych služieb s prevádzkou relevantnou pre NIS2 v jednom členskom štáte. Osobné údaje zákazníkov spracúva ako prevádzkovateľ pri účtových službách a ako sprostredkovateľ pri niektorých podnikových klientoch.

O 02:17 je zistená anomálna API prevádzka. O 02:35 je otvorený incidentný ticket. O 03:00 Sarah dokončí počiatočnú triáž s koordinátorom incidentu.

Najskôr sa stanoví interná závažnosť. Incident ovplyvnil dostupnosť zákazníckeho dashboardu počas 19 minút, zahŕňal podozrivé prístupové tokeny a dotkol sa kritickej funkcie orientovanej na zákazníkov. Je klasifikovaný ako SEV 3 Stredná do potvrdenia skutočností, s eskaláciou na koordinátora incidentu, koordinátora ochrany súkromia, právnika a vlastníka služby.

Následne sa dokončí posúdenie DORA. Tím kontroluje dotknutých klientov, protistrany, transakcie, trvanie, výpadok, geografický rozsah, stratu údajov, kritickosť a ekonomický dopad. Nie sú potvrdené žiadne zlyhané ani zmenené transakcie. Výpadok je obmedzený. Strata údajov nie je preukázaná. Keďže však môže byť dotknutý kritický komponent finančnej služby a finančné záujmy zákazníkov, incident zostáva pod monitorovaním DORA a môže byť reklasifikovaný.

Po tretie sa zaznamená posúdenie NIS2. Tím uvedie, že DORA je primárnym odvetvovo špecifickým režimom hlásenia pre povinnosti dotknutého finančného subjektu. Zároveň preverí, či incident ovplyvňuje služby alebo zákazníkov mimo perimetra DORA. V tejto fáze nie je potvrdené závažné narušenie prevádzky ani značná škoda.

Po štvrté sa začne posúdenie GDPR. Podozrivé tokeny mohli umožniť prístup k údajom zákazníckeho dashboardu. Koordinátor ochrany súkromia dokumentuje kategórie údajov, dotknutých používateľov, rozsah tokenov, preskúmané logy, či boli údaje zobrazené alebo exportované, a ochranné opatrenia, ako je expirácia tokenov a riadenie prístupu.

O 04:20 analýza logov ukáže, že dva tokeny boli použité na prístup k metadátam dashboardu pre 41 zákazníkov vrátane mien, identifikátorov účtov a stavu transakcií, ale bez platobných poverení alebo dokladov totožnosti. Tím aktualizuje incident na SEV 2 Významná, pretože bola dotknutá dôvernosť osobných údajov a môže byť potrebná komunikácia so zákazníkmi. Zodpovedná osoba posúdi riziko podľa GDPR pre jednotlivcov. Rozhodnutie podľa DORA sa opätovne preskúma na základe dopadu na klientov, transakcie a ekonomického dopadu.

Toto je praktická hodnota modelu. Počiatočná klasifikácia nie je konečný právny záver. Je to rozhodnutie riadené dôkazmi, ktoré možno aktualizovať podľa vývoja skutočností.

Logovanie, monitorovanie a forenzné dôkazy: dôkazová vrstva

Model závažnosti bez dôkazov je iba názor zo stretnutia. Očakávaním roku 2026 je, že klasifikácia bude podporená logmi, monitorovaním, uchovanými artefaktmi a reťazcom zverenia.

SME Logging and Monitoring Policy-sme Logging and Monitoring Policy-sme - SME, Presadzovanie a súlad, ustanovenie 8.3.4, uvádza:

„Vyšetrovanie porušení musí byť podporené primeranými logmi, aby bola splnená zásada zodpovednosti podľa GDPR a DORA.“

Rovnako dôležité je forenzné nakladanie s dôkazmi. SME Evidence Collection and Forensics Policy-sme Evidence Collection and Forensics Policy-sme - SME, Požiadavky na správu a riadenie, ustanovenie 5.3.1, vyžaduje:

„Pre každý incident musí byť vedený jednoduchý záznam reťazca zverenia, napríklad súbor Excel alebo šablóna dokumentu.“

Pre podnikové prostredia Evidence Collection and Forensics Policy Evidence Collection and Forensics Policy, Požiadavky na správu a riadenie, ustanovenie 5.5, vyžaduje:

„Všetky zozbierané dôkazy musia byť jednoznačne identifikované, označené a uložené v zabezpečenom úložisku s:“

Zenith Blueprint, fáza Uplatnenie opatrení v praxi, krok 23, vysvetľuje, prečo je to dôležité pre ISO/IEC 27002:2022 opatrenie 5.28:

„Keď nastane incident informačnej bezpečnosti, jedným z najkritickejších, no často prehliadaných prvkov reakcie sú dôkazy. Nie logy, nie snímky obrazovky, nie voľné opisy, ale riadne uchované dôkazy rešpektujúce reťazec zverenia a odolné voči manipulácii.“

Praktický balík dôkazov pre závažný alebo potenciálne hlásiteľný incident má zahŕňať:

• Incidentný ticket a časovú os
• Záznam rozhodnutia o závažnosti a históriu reklasifikácie
• Upozornenia SIEM, upozornenia EDR, cloudové logy a logy identít
• Logy prístupu k údajom a exportné logy
• Položky evidencie dotknutých aktív a služieb
• Posúdenie dopadu na zákazníkov, transakcie a geografiu
• Pracovný hárok posúdenia DORA, NIS2 a GDPR
• Posúdenie zodpovednej osoby alebo právne posúdenie
• Schválenia komunikácie a odoslané správy
• Záznam reťazca zverenia
• Analýzu koreňovej príčiny
• Nápravné opatrenia a získané poznatky

Tento balík dôkazov zároveň podporuje opatrenia prílohy A ISO/IEC 27001:2022 A.8.15 logovanie, A.8.16 monitorovacie činnosti, A.5.28 zber dôkazov, A.5.27 poučenie z incidentov informačnej bezpečnosti, A.5.31 právne, zákonné, regulačné a zmluvné požiadavky a A.5.34 ochrana súkromia a ochrana osobne identifikovateľných informácií.

Mapovanie naprieč rámcami súladu: vybudujte raz, odpovedajte viacerým audítorom

Najsilnejšie modely závažnosti incidentov sú vybudované raz a mapované opakovane. Zenith Controls je navrhnutý ako kompas pre prácu naprieč požiadavkami súladu. Pre túto tému sú kľúčovými položkami ISO/IEC 27002:2022 opatrenia 5.24 plánovanie a príprava riadenia incidentov informačnej bezpečnosti, 5.25 posúdenie udalostí informačnej bezpečnosti a rozhodovanie o nich, 5.26 reakcia na incidenty informačnej bezpečnosti, 5.27 poučenie z incidentov informačnej bezpečnosti a 5.28 zber dôkazov.

Tieto opatrenia prirodzene nadväzujú na systém manažérstva podľa ISO/IEC 27001:2022. Kapitoly 4, 5, 6 a 8 definujú rozsah, vedenie, kritériá rizika, ošetrenie a prevádzkové dôkazy. ISO/IEC 27002:2022 poskytuje jazyk implementácie opatrení. Uvažovanie v štýle ISO 22301 pre kontinuitu činností podporuje prahové hodnoty narušenia, priority obnovy a krízové riadenie. Praktiky riadenia incidentov v štýle ISO/IEC 27035 podporujú štruktúrovanú detekciu, hlásenie, posúdenie, reakciu a učenie sa. Správa a riadenie ochrany súkromia v štýle ISO/IEC 27701 podporuje roly pri porušení ochrany osobných údajov, úvahy o prevádzkovateľovi a sprostredkovateľovi, dôkazy ochrany súkromia a zodpovednosť.

Rovnaký model sa mapuje na NIST Cybersecurity Framework 2.0. Funkcia GOVERN vyžaduje, aby boli právne, regulačné, zmluvné, súkromnoprávne a občianskoprávne povinnosti pochopené a riadené. Očakáva tiež definovaný apetít na riziko, roly, právomoci, politiky a dohľad. Funkcie DETECT, RESPOND a RECOVER podporujú triáž, analýzu, eskaláciu, obmedzenie šírenia, obnovu, komunikáciu a zlepšovanie.

Prínos je praktický. Keď dohľadový orgán podľa DORA žiada zdôvodnenie závažného incidentu súvisiaceho s IKT, orgán podľa NIS2 sa pýta na rozhodnutie o včasnom varovaní do 24 hodín, dozorný orgán pre ochranu údajov sa pýta, prečo bolo alebo nebolo podané oznámenie podľa GDPR, a audítor ISO sa pýta, či ISMS fungoval podľa plánu, organizácia dokáže odpovedať z rovnakého súboru dôkazov.

Ako budú audítori a regulátori testovať váš model

Audítor ISO/IEC 27001:2022 zvyčajne začne rozsahom a právnymi požiadavkami. Bude sa pýtať, či boli DORA, NIS2, GDPR, zákaznícke zmluvy a povinnosti voči tretím stranám v oblasti IKT identifikované ako požiadavky zainteresovaných strán. Následne bude sledovať stopu ku kritériám rizika, vyhláseniu o uplatniteľnosti, postupom riadenia incidentov, prevádzkovým záznamom a uchovávaniu dôkazov. Chce dôkaz, že klasifikačný proces nebol vymyslený počas incidentu.

Dohľadový orgán podľa DORA alebo tím vnútorného auditu bude hľadať celý životný cyklus: proces riadenia incidentov, ukazovatele včasného varovania, klasifikačné kritériá, eskaláciu závažného incidentu, komunikáciu s klientmi, koreňovú príčinu, konečné údaje o dopade, testovanie odolnosti a dohľad riadiaceho orgánu. Bude sa tiež pýtať, či boli zohľadnené závislosti od tretích strán v oblasti IKT, najmä ak boli zapojené cloud, SaaS, riadená bezpečnosť alebo poskytovatelia outsourcingu.

Audítor alebo orgán zameraný na NIS2 bude testovať, či subjekt dokáže identifikovať významné incidenty, splniť postupné lehoty, komunikovať s dotknutými príjemcami služieb a poskytnúť dôkazy o posúdení cezhraničného dopadu. Prepojí riešenie incidentov s opatreniami riadenia rizík podľa Article 21 vrátane kontinuity činností, krízového riadenia, bezpečnosti dodávateľského reťazca, riadenia prístupu, správy aktív a školenia.

Zodpovedná osoba podľa GDPR alebo dozorný orgán preskúma, či organizácia identifikovala osobné údaje, roly, dotknuté osoby, kategórie, dotknuté systémy, typ porušenia a riziko pre jednotlivcov. Bude testovať, či prevádzkovateľ dokáže preukázať zodpovednosť a či oznámenia sprostredkovateľov prevádzkovateľom boli včasné a úplné.

Audítor v štýle ISACA alebo COBIT 2019 sa zameria na dôkazy správy a riadenia. Kto schválil taxonómiu závažnosti? Kto vlastní riziko? Aké metriky sa reportujú manažmentu? Ako sa riešia výnimky? Ako sa získané poznatky premietajú do zlepšení opatrení?

Bežné vzorce zlyhania pri klasifikácii incidentov

Prvým zlyhaním je myslenie v jednom označení. Tímy klasifikujú udalosť ako vysokú, strednú alebo nízku, ale samostatne neposudzujú spúšťače DORA, NIS2 a GDPR. Výsledkom je označenie závažnosti, ktoré nevie vysvetliť rozhodnutie o hlásení.

Druhým zlyhaním je skreslenie smerom k potvrdenému porušeniu. Tímy čakajú na absolútny dôkaz exfiltrácie pred zapojením ochrany súkromia alebo právneho tímu. Posúdenie porušenia podľa GDPR často začína možným neoprávneným prístupom, stratou, zmenou alebo poskytnutím, nie až potvrdeným zverejnením údajov.

Tretím zlyhaním je nejasnosť časových okamihov. Lehoty podľa NIS2 a GDPR závisia od zistenia a posúdenia. Ak incidentný ticket nezachytáva čas zistenia, čas klasifikácie a čas eskalácie, organizácia môže mať problém preukázať včasnosť.

Štvrtým zlyhaním je forenzná analýza až po upratovaní. Inžinieri rotujú kľúče, obnovujú hostiteľov a odstraňujú dočasné dôkazy ešte pred aktiváciou vyšetrovacieho režimu. To môže zničiť dôkaz potrebný na regulačné, zmluvné alebo právne preskúmanie.

Piatym zlyhaním je slepota voči dodávateľom. DORA, NIS2 a NIST CSF 2.0 zdôrazňujú riziko tretích strán a dodávateľského reťazca. Ak je súčasťou reťazca incidentu cloudový poskytovateľ, poskytovateľ riadených služieb, spracovateľ platieb, poskytovateľ identít alebo SaaS dodávateľ, klasifikačný model musí zahŕňať dopad na dodávateľa a zmluvné oznamovacie povinnosti.

Implementačný kontrolný zoznam Clarysec pre rok 2026

Na uvedenie obhájiteľného modelu klasifikácie závažnosti incidentov do praxe Clarysec odporúča tento postup:

1. Potvrďte regulačnú uplatniteľnosť naprieč DORA, NIS2, GDPR, zákazníckymi zmluvami a odvetvovými pravidlami.
2. Aktualizujte rozsah ISMS a požiadavky zainteresovaných strán podľa ISO/IEC 27001:2022.
3. Definujte interné úrovne závažnosti s merateľnými prahovými hodnotami pre výpadok, údaje, zákazníkov, geografiu, finančnú stratu a kritickosť.
4. Pridajte samostatné otázky posúdenia DORA, NIS2 a GDPR do pracovného toku incidentného ticketu.
5. Definujte spúšťače eskalácie pre koordinátora incidentu, zodpovednú osobu, právny tím, vrcholové vedenie a riadiaci orgán.
6. Vytvorte šablónu záznamu rozhodnutia o závažnosti.
7. Prepojte klasifikáciu so zberom dôkazov a postupmi reťazca zverenia.
8. Overte pokrytie logovania pre udalosti identít, cloudu, aplikácií, databáz, sietí a dodávateľov.
9. Vykonajte stolové cvičenia pre scenáre závažného incidentu podľa DORA, významného incidentu podľa NIS2 a porušenia podľa GDPR.
10. Premietnite získané poznatky do ošetrenia rizík, vyhlásenia o uplatniteľnosti, školenia a testovania odolnosti.

Zenith Blueprint, fáza Uplatnenie opatrení v praxi, krok 16, posilňuje ľudskú stránku tohto modelu: hlásenia majú byť zaznamenané, triážované, eskalované cez plán reakcie na incidenty a aj menšie udalosti majú byť sledované, pretože trendy odhaľujú slabiny opatrení. Podporuje kultúru hlásenia s nízkym prahom: „Ak máte pochybnosti, nahláste to.“

Tento kultúrny aspekt je kritický. Model závažnosti zlyhá, ak zamestnanci odkladajú hlásenie, pretože sa obávajú prehnanej reakcie. Cieľom je rýchle hlásenie, disciplinovaná triáž a obhájiteľná klasifikácia.

Premeňte neistotu pri incidente na dôkazy pripravené na audit

V roku 2026 už klasifikácia závažnosti incidentov nie je rozhodnutím výlučne SOC. Je to regulovaný proces správy a riadenia, ktorý musí prepájať kritériá závažného incidentu súvisiaceho s IKT podľa DORA, prahové hodnoty významného incidentu podľa NIS2, riziko porušenia podľa GDPR a dôkazy podľa ISO/IEC 27001:2022.

Organizácie, ktoré najlepšie zvládnu incidenty, nebudú tie s najhrubším manuálom reakcie. Budú to tie, ktoré vedia rýchlo odpovedať na štyri otázky a neskôr každú odpoveď preukázať:

• Čo sa stalo?
• Aké závažné to je?
• Ktoré regulačné povinnosti sa môžu uplatniť?
• Aké dôkazy podporujú rozhodnutie?

Clarysec pomáha organizáciám vybudovať tento most prostredníctvom šablón politík, taxonómií závažnosti, záznamov rozhodnutí, stolových scenárov a mapovaní naprieč požiadavkami súladu. Začnite politikami riadenia incidentov, overte svoje kritériá rizika v Zenith Blueprint Zenith Blueprint a použite Zenith Controls Zenith Controls na mapovanie opatrení ISO/IEC 27002:2022 5.24, 5.25, 5.26, 5.27 a 5.28 naprieč DORA, NIS2, GDPR, NIST CSF a auditnými očakávaniami.

Ak váš tím nevie počas prvej hodiny odpovedať na otázku „Je toto závažný incident podľa DORA, významný incident podľa NIS2 alebo incident podliehajúci oznámeniu podľa GDPR?“, ďalším krokom nie je ďalší všeobecný plán reakcie na incidenty. Ďalším krokom je obhájiteľný prevádzkový model klasifikácie závažnosti incidentov, otestovaný skôr, ako príde ďalší telefonát o 02:17.

Ste pripravení nahradiť paniku procesom? Stiahnite si šablóny politík reakcie na incidenty a zberu dôkazov od Clarysec, preskúmajte svoju aktuálnu taxonómiu závažnosti podľa Zenith Blueprint alebo požiadajte o posúdenie pripravenosti Clarysec na vybudovanie modelu klasifikácie incidentov podľa DORA, NIS2, GDPR a ISO/IEC 27001 pripraveného na audit.