Klasifikace závažnosti incidentů pro DORA, NIS2 a GDPR

Hovor ve 02:17 k incidentu, který se mění v regulatorní rozhodnutí

Ve čtvrtek ve 02:17 ráno Sarah, ředitelka informační bezpečnosti společnosti FinScale, vidí první upozornění: abnormální provoz API, nárůst neúspěšných autentizací a latenci platebního přehledového panelu nad 3000 ms. Během několika minut zákaznická podpora hlásí chyby stavu plateb. Poskytovatel cloudových služeb uvádí, že nejde o incident v celé platformě. SOC vidí podezřelé přístupové tokeny ze dvou geografických oblastí. Produktový tým potvrzuje, že přehledový panel je po 19 minutách opět dostupný, ale dvanáct zákazníků již otevřelo tikety.

Ve 03:05 je Sarah na krizovém hovoru s vedoucím řešení incidentu, právním poradcem, koordinátorem ochrany soukromí, vedoucím cloudového provozu a výkonným garantem. Technická otázka je poměrně jasná: co se stalo s API bránou? Regulatorní otázky jsou obtížnější:

1. Jde o závažný incident související s ICT podle DORA?
2. Jde o významný incident podle NIS2?
3. Došlo k porušení zabezpečení osobních údajů podle GDPR, které vyžaduje oznámení?
4. Může organizace doložit, jak k těmto odpovědím dospěla?

Nesprávná odpověď může vytvořit regulatorní expozici. Pomalá odpověď může vést ke zmeškání oznamovací lhůty. Nedokumentovaná odpověď může o několik měsíců později neobstát při auditu ISO/IEC 27001:2022.

To je výzva reakce na incidenty v roce 2026. Mnoho organizací má plán reakce na incidenty, forenzní postupy, scénáře ochrany soukromí a šablony krizové komunikace. Méně organizací má obhajitelný model klasifikace závažnosti incidentů, který převádí nepřehlednou bezpečnostní událost na dokumentované rozhodnutí napříč DORA, NIS2, GDPR a důkazními očekáváními ISO/IEC 27001:2022.

Řešením nejsou tři oddělené procesy třídění. Řešením je jeden řízený model závažnosti se samostatnými regulatorními vrstvami, měřitelnými prahovými hodnotami, pravidly eskalace, záznamy rozhodnutí a požadavky na sběr důkazů. Prakticky řečeno, závažnost incidentu nemá být štítek zvolený pod tlakem. Má jít o řízené obchodní rozhodnutí, které obstojí při přezkumu regulačními orgány, auditory, členy řídicího orgánu, zákazníky a pověřencem pro ochranu osobních údajů (DPO).

Proč je klasifikace závažnosti incidentů nyní kontrolou na úrovni řídicího orgánu

Klasifikace incidentů bývala převážně technická: závažnost malwaru, dotčení hostitelé, zneužité zranitelnosti a to, zda došlo k exfiltraci dat. V roce 2026 je také právní, finanční, společenská a smluvní.

DORA činí z digitální provozní odolnosti povinnost správy a řízení pro finanční subjekty. Očekává se, že řídicí orgán stanoví, schválí a dohlédne na rámec řízení rizik v oblasti ICT a zůstane za něj odpovědný. To zahrnuje kontinuitu činností v oblasti ICT, plány reakce a obnovy, kanály pro hlášení závažných incidentů, rizika třetích stran v oblasti ICT a získané poznatky.

NIS2 zvyšuje nároky na správu a řízení u základních a důležitých subjektů. Article 20 vyžaduje, aby řídicí orgány schvalovaly opatření pro řízení rizik kybernetické bezpečnosti, dohlížely na jejich zavedení a absolvovaly školení. Zároveň propojuje selhání v řízení rizik a hlášení incidentů se závažnými dohledovými důsledky. U základních subjektů mohou základní maximální správní pokuty dosahovat alespoň 10 000 000 EUR nebo 2 procent celkového celosvětového ročního obratu podle toho, která hodnota je vyšší. U důležitých subjektů je základ alespoň 7 000 000 EUR nebo 1,4 procenta obratu podle toho, která hodnota je vyšší.

GDPR přidává jinou perspektivu. Porušení zabezpečení osobních údajů se neomezuje na potvrzené veřejné zpřístupnění nebo odcizené soubory. Zahrnuje náhodné nebo protiprávní zničení, ztrátu, změnu, neoprávněné zpřístupnění osobních údajů nebo neoprávněný přístup k nim. Správci musí posoudit riziko pro fyzické osoby a doložit odpovědnost za rozhodnutí oznámit nebo neoznámit.

ISO/IEC 27001:2022 dává těmto povinnostem důkazní páteř. Kapitoly 4.1 až 4.4 vyžadují, aby organizace porozuměla svému kontextu, požadavkům zainteresovaných stran, rozsahu, rozhraním a závislostem. Kapitoly 5.1 až 5.3 vyžadují závazek vedení, politiku, role, odpovědnosti a reporting. Kapitoly 6.1.1 až 6.1.3 vyžadují plánování založené na rizicích, posuzování rizik, ošetření rizik a prohlášení o použitelnosti. Kapitoly 8.1 až 8.3 vyžadují provozní řízení, řízení změn, uchované důkazy a opětovné posouzení při změně rizikových podmínek. ISO/IEC 27001:2022

Když probíhá hovor k incidentu, otázka nemá znít: „Kdo si myslí, že je to kritické?“ Má znít: „Co nám naše schválená kritéria, právní spouštěče, důkazy a pravidla eskalace ukládají udělat nyní?“

Jedna událost, tři regulatorní klasifikační systémy

DORA, NIS2 a GDPR nepoužívají pro incidenty stejný jazyk. To je hlavní důvod, proč organizace v první hodině selhávají.

DORA Article 17 vyžaduje, aby finanční subjekty zavedly proces řízení incidentů souvisejících s ICT, který detekuje, řídí a oznamuje ICT incidenty, zaznamenává incidenty související s ICT a významné kybernetické hrozby, řeší kořenové příčiny, používá ukazatele včasného varování, kategorizuje a klasifikuje incidenty, přiřazuje role, řídí komunikaci, eskaluje závažné incidenty vrcholovému vedení a obnovuje bezpečný provoz.

DORA Article 18 vyžaduje klasifikaci podle kritérií, jako jsou dotčení klienti, dotčené protistrany, transakce, doba trvání, nedostupnost, geografický rozsah, ztráta dat ovlivňující dostupnost, autenticitu, integritu nebo důvěrnost, kritičnost dotčených služeb a ekonomický dopad. DORA Article 19 vyžaduje hlášení závažných incidentů souvisejících s ICT a komunikaci s klienty tam, kde jsou dotčeny finanční zájmy.

NIS2 Article 23 definuje významný incident jako incident, který způsobil nebo je schopen způsobit závažné narušení provozu nebo finanční ztrátu, nebo zasáhl či je schopen zasáhnout jiné osoby způsobením značné hmotné nebo nehmotné újmy. Vyžaduje včasné varování do 24 hodin od zjištění významného incidentu, oznámení incidentu do 72 hodin, průběžné zprávy na vyžádání a závěrečnou zprávu do jednoho měsíce od oznámení incidentu. Je-li to relevantní, musí být dotčení příjemci služeb informováni také o opatřeních nebo nápravných prostředcích, které mohou přijmout.

GDPR klade otázku rizika pro ochranu soukromí. Způsobilo porušení bezpečnosti zničení, ztrátu, změnu, neoprávněné zpřístupnění osobních údajů nebo neoprávněný přístup k nim? Pokud ano, správce musí posoudit riziko pro práva a svobody fyzických osob. Pokud je pravděpodobné, že porušení povede k riziku, musí být dozorový úřad zpravidla informován do 72 hodin od okamžiku zjištění. Pokud je pravděpodobné, že povede k vysokému riziku, může být nutné bez zbytečného odkladu informovat dotčené fyzické osoby.

Jeden incident proto vyžaduje souběžnou klasifikaci.

Pro finanční subjekty je DORA sektorově specifickým právním aktem Unie pro řízení rizik v oblasti ICT a povinnosti hlášení incidentů, které se překrývají s NIS2. To neznamená, že NIS2 je irelevantní. Může být stále relevantní pro spolupráci, informační toky, služby mimo perimetr DORA, nefinanční subjekty ve skupině, cloudové služby, řízené služby a smluvní povinnosti vůči zákazníkům. Model závažnosti má zaznamenávat nejen výsledek, ale také logiku použitelnosti.

Model Clarysec: klasifikujte událost, ne emoci

Clarysec vychází z opatření ISO/IEC 27002:2022 5.25, posouzení událostí bezpečnosti informací a rozhodování o nich, jako z kotvy pro soulad napříč požadavky. V Zenith Controls: The Cross-Compliance Guide Zenith Controls je toto téma mapováno prostřednictvím položky „Posouzení událostí bezpečnosti informací a rozhodování o nich“ pro opatření 5.25, podporované položkou „Plánování a příprava řízení incidentů IS“ pro opatření 5.24 a „Sběr důkazů“ pro opatření 5.28.

Nejdůležitějším okamžikem souladu často není zamezení šíření. Je to rozcestí, na kterém se bezpečnostní událost stává regulatorním incidentem, nebo je obhajitelně zaznamenána jako událost s nižší závažností.

Zenith Blueprint: An Auditor’s 30-Step Roadmap od Clarysec Zenith Blueprint popisuje tento okamžik ve fázi Controls in Action, Step 23:

„Ne každá anomálie je katastrofa. Ne každé upozornění znamená kompromitaci. V reálném světě jsou bezpečnostní týmy a obchodní útvary zahlceny šumem, pokusy o přihlášení, anomáliemi v logách, drobnými porušeními politik a aktivitami stínového IT. Skutečná výzva nespočívá jen v detekci, ale v rozlišení neškodného od škodlivého a ve znalosti toho, co vyžaduje eskalaci.“

Tato věta vystihuje provozní problém. Upozornění ze SIEM automaticky neznamená závažný incident podle DORA. Dočasný výpadek automaticky neznamená významný incident podle NIS2. Podezřelý databázový dotaz automaticky neznamená oznamovací povinnost podle GDPR. Každý z nich se může stát incidentem podléhajícím hlášení v závislosti na dopadu, rozsahu, datech, dotčených stranách a důkazech.

Zenith Blueprint, fáze Risk Management, Step 10, také doporučuje, aby definice dopadu byly přizpůsobeny velikosti podnikání a regulatorní expozici:

„Při definování dopadu je vhodné vztáhnout úrovně ke konkrétnímu rozsahu vašeho podnikání. Například ‚závažný finanční dopad = ztráta > 100 tis. USD‘ (upravte podle svého kontextu). Zvažte také regulatorní dopad: například porušení zabezpečení osobních údajů může být automaticky ‚závažné‘ nebo ‚kritické‘ kvůli pokutám podle GDPR a oznamovacím povinnostem, i když přímá finanční ztráta není jasná.“

To je návrhový princip klasifikace závažnosti incidentů pro rok 2026: závažnost je obchodní dopad plus právní dopad plus míra jistoty důkazů.

Praktická taxonomie závažnosti incidentů pro DORA, NIS2 a GDPR

Obhajitelná taxonomie musí oddělovat interní závažnost od regulatorní klasifikace. Interní závažnost řídí naléhavost reakce, přidělení zdrojů a eskalaci výkonnému vedení. Regulatorní klasifikace řídí oznámení, právní přezkum a externí komunikaci.

Interní úroveň závažnosti není konečnou regulatorní odpovědí. Je to provozní režim. Událost SEV 3 se může po přezkumu logů stát oznamovatelnou podle GDPR. Výpadek SEV 2 nemusí být závažným incidentem podle DORA, pokud nejsou splněny prahové hodnoty dopadu. Ransomwarový incident SEV 1 může současně spustit DORA, NIS2, GDPR, zákaznické smlouvy a koordinaci s orgány činnými v trestním řízení.

Podrobnější klasifikační matice pomáhá týmu přejít od upozornění k opatřením.

Model musí být zakotven v politice, nikoli ponechán nejsilnějšímu hlasu na krizovém hovoru. SME Incident Response Policy-sme Incident Response Policy-sme - SME, Požadavky na správu a řízení, bod 5.3.1, uvádí:

„Generální ředitel musí s přispěním poskytovatele IT služeb klasifikovat všechny incidenty podle závažnosti do jedné hodiny od oznámení.“

Stejná SME politika, Ošetření rizik a výjimky, bod 7.4.1, dodává:

„Pokud jsou zapojena zákaznická data, musí generální ředitel posoudit právní oznamovací povinnosti na základě použitelnosti GDPR, NIS2 nebo DORA.“

Pro větší organizace podniková Incident Response Policy Incident Response Policy, Požadavky na správu a řízení, bod 5.3, formalizuje stejný koncept:

„Klasifikace incidentů se musí řídit víceúrovňovým modelem:“

Jazyk politiky je důležitý, protože regulační orgány a auditoři se budou ptát, zda klasifikační kritéria existovala před incidentem. Matice vytvořená dodatečně je slabým důkazem. Matice schválená, proškolená, procvičená a konzistentně používaná je obhajitelná.

Záznam rozhodnutí: nejdůležitější důkazní artefakt

Když auditoři, regulační orgány nebo členové řídicích orgánů přezkoumávají incident, jen zřídka se ptají pouze: „Co se stalo?“ Ptají se: „Kdy jste to věděli, kdo rozhodl, na základě jakých důkazů a proč jste neoznámili dříve?“

Proto Clarysec doporučuje záznam rozhodnutí o závažnosti pro každou událost SEV 3 a vyšší a pro každou událost zahrnující osobní údaje, kritické služby, finanční zákazníky, řízené služby, cloudovou infrastrukturu nebo přeshraniční dopad.

To přímo mapuje na ISO/IEC 27001:2022. Kapitola 8.1 vyžaduje, aby procesy byly plánovány, implementovány a řízeny a aby byly uchovány dostatečné dokumentované informace dokládající, že fungovaly podle plánu. Kapitoly 8.2 a 8.3 vyžadují opětovné posouzení při významných změnách a uchování důkazů o ošetření rizik. Opatření přílohy A A.5.24 až A.5.28 tvoří páteř řízení incidentů: plánování a příprava, posouzení událostí a rozhodnutí, reakce, učení se z incidentů a sběr důkazů.

SME Data Protection and Privacy Policy-sme Data Protection and Privacy Policy-sme - SME, Vynucování a dodržování, bod 8.3.2, podporuje stranu modelu týkající se GDPR:

„Koordinátor ochrany soukromí určí závažnost, zahájí opatření k zamezení šíření a zdokumentuje případ.“

Posouzení ochrany soukromí nemá začínat až ve chvíli, kdy regulatorní lhůta začíná být nepříjemná. Patří přímo do pracovního postupu třídění.

Praktický příklad: klasifikace incidentu Sarah s API

Vraťme se k FinScale. Jde o B2B fintech platformu využívající cloudovou infrastrukturu, externího poskytovatele analytiky podvodů a poskytovatele řízených bezpečnostních služeb. Pro některé činnosti je finančním subjektem spadajícím pod DORA. Zároveň je poskytovatelem digitální služby s činnostmi relevantními podle NIS2 v jednom členském státě. Zpracovává osobní údaje zákazníků jako správce pro služby účtů a jako zpracovatel pro některé podnikové klienty.

Ve 02:17 je detekován abnormální provoz API. Ve 02:35 je otevřen incidentní tiket. Ve 03:00 Sarah dokončí počáteční třídění s vedoucím řešení incidentu.

Nejprve je stanovena interní závažnost. Incident ovlivnil dostupnost zákaznického přehledového panelu po dobu 19 minut, zahrnoval podezřelé přístupové tokeny a dotkl se kritické funkce určené zákazníkům. Je klasifikován jako SEV 3 Střední do potvrzení dalších skutečností, s eskalací vedoucímu řešení incidentu, koordinátorovi ochrany soukromí, právnímu poradci a vlastníkovi služby.

Za druhé je dokončeno vstupní posouzení DORA. Tým kontroluje dotčené klienty, protistrany, transakce, dobu trvání, nedostupnost, geografický rozsah, ztrátu dat, kritičnost a ekonomický dopad. Nejsou potvrzeny žádné selhané nebo změněné transakce. Nedostupnost je omezená. Ztráta dat není prokázána. Protože však může být dotčena kritická komponenta finanční služby a finanční zájmy zákazníků, incident zůstává pod monitorováním DORA a může být reklasifikován.

Za třetí je zaznamenáno vstupní posouzení NIS2. Tým konstatuje, že DORA je primárním sektorově specifickým režimem hlášení pro povinnosti regulovaného finančního subjektu. Zároveň kontroluje, zda incident zasahuje služby nebo zákazníky mimo perimetr DORA. V této fázi není potvrzeno žádné závažné narušení provozu ani značná újma.

Za čtvrté je zahájeno vstupní posouzení GDPR. Podezřelé tokeny mohly umožnit přístup k datům v zákaznickém přehledovém panelu. Koordinátor ochrany soukromí dokumentuje kategorie údajů, dotčené uživatele, rozsah tokenů, přezkoumané logy, zda byla data zobrazena nebo exportována, a ochranná opatření, jako je expirace tokenů a řízení přístupu.

Ve 04:20 analýza logů ukazuje, že dva tokeny byly použity k přístupu k metadatům přehledového panelu u 41 zákazníků, včetně jmen, ID účtů a stavu transakcí, nikoli však platebních přihlašovacích údajů nebo dokladů totožnosti. Tým aktualizuje incident na SEV 2 Závažná, protože byla dotčena důvěrnost osobních údajů a může být vyžadována komunikace se zákazníky. DPO posuzuje riziko podle GDPR pro fyzické osoby. Rozhodnutí podle DORA je znovu přezkoumáno na základě dopadu na klienty, dopadu na transakce a ekonomického dopadu.

To je praktická hodnota modelu. Počáteční klasifikace není konečný právní závěr. Je to rozhodnutí založené na důkazech, které lze aktualizovat podle vývoje zjištěných skutečností.

Protokolování, monitorování a forenzní důkazy: důkazní vrstva

Model závažnosti bez důkazů je názor z porady. Očekáváním pro rok 2026 je, že klasifikace je podpořena logy, monitorováním, uchovanými artefakty a řetězcem předávání důkazů.

SME Logging and Monitoring Policy-sme Logging and Monitoring Policy-sme - SME, Vynucování a dodržování, bod 8.3.4, uvádí:

„Vyšetřování porušení zabezpečení musí být podpořeno odpovídajícími logy, aby byl splněn princip odpovědnosti podle GDPR a DORA.“

Stejně důležité je forenzní nakládání. SME Evidence Collection and Forensics Policy-sme Evidence Collection and Forensics Policy-sme - SME, Požadavky na správu a řízení, bod 5.3.1, vyžaduje:

„Pro každý incident musí být veden jednoduchý záznam řetězce předávání důkazů (např. soubor Excel nebo šablona dokumentu).“

Pro podniková prostředí Evidence Collection and Forensics Policy Evidence Collection and Forensics Policy, Požadavky na správu a řízení, bod 5.5, vyžaduje:

„Všechny shromážděné důkazy musí být jednoznačně identifikovány, označeny a uloženy v zabezpečeném repozitáři s:“

Zenith Blueprint, fáze Controls in Action, Step 23, vysvětluje, proč je to důležité pro opatření ISO/IEC 27002:2022 5.28:

„Když nastane incident informační bezpečnosti, jedním z nejkritičtějších, a přesto často přehlížených prvků reakce jsou důkazy. Ne logy, ne snímky obrazovky, ne volné narativy, ale řádně uchované důkazy respektující řetězec předávání důkazů a odolné proti manipulaci.“

Praktický důkazní balíček pro závažný nebo potenciálně oznamovatelný incident má zahrnovat:

• Incidentní tiket a časovou osu
• Záznam rozhodnutí o závažnosti a historii reklasifikace
• Upozornění SIEM, upozornění EDR, cloudové logy a logy identit
• Logy přístupu k datům a logy exportů
• Záznamy o dotčených aktivech a službách v evidenci
• Posouzení dopadu na zákazníky, transakce a geografii
• Pracovní formulář vstupního posouzení DORA, NIS2 a GDPR
• Posouzení DPO nebo právní posouzení
• Schválení komunikace a odeslané zprávy
• Záznam řetězce předávání důkazů
• Analýzu kořenové příčiny
• Nápravná opatření a získané poznatky

Tento důkazní balíček podporuje také opatření přílohy A ISO/IEC 27001:2022 A.8.15 protokolování, A.8.16 monitorovací činnosti, A.5.28 sběr důkazů, A.5.27 učení se z incidentů informační bezpečnosti, A.5.31 právní, zákonné, regulatorní a smluvní požadavky a A.5.34 ochranu soukromí a ochranu osobně identifikovatelných údajů.

Mapování napříč požadavky: vytvořit jednou, odpovědět mnoha auditorům

Nejsilnější modely závažnosti incidentů jsou vytvořeny jednou a mapovány mnohokrát. Zenith Controls je navržen jako kompas pro soulad napříč požadavky pro tuto práci. Pro toto téma jsou klíčovými položkami ISO/IEC 27002:2022 5.24 plánování a příprava řízení incidentů informační bezpečnosti, 5.25 posouzení událostí bezpečnosti informací a rozhodování o nich, 5.26 reakce na incidenty informační bezpečnosti, 5.27 učení se z incidentů informační bezpečnosti a 5.28 sběr důkazů.

Tato opatření přirozeně navazují na systém řízení podle ISO/IEC 27001:2022. Kapitoly 4, 5, 6 a 8 definují rozsah, vedení, kritéria rizik, ošetření a provozní důkazy. ISO/IEC 27002:2022 poskytuje jazyk pro implementaci opatření. Uvažování o kontinuitě činností ve stylu ISO 22301 podporuje prahové hodnoty narušení, priority obnovy a krizové řízení. Postupy řízení incidentů ve stylu ISO/IEC 27035 podporují strukturovanou detekci, hlášení, posouzení, reakci a učení. Správa ochrany soukromí ve stylu ISO/IEC 27701 podporuje role při porušení zabezpečení osobních údajů, úvahy o správci a zpracovateli, důkazy k ochraně soukromí a odpovědnost.

Stejný model se mapuje na NIST Cybersecurity Framework 2.0. Funkce GOVERN vyžaduje, aby právní, regulatorní, smluvní povinnosti, povinnosti v oblasti ochrany soukromí a občanských svobod byly pochopeny a řízeny. Očekává také definovanou ochotu podstupovat riziko, role, pravomoci, politiky a dohled. Funkce DETECT, RESPOND a RECOVER podporují třídění, analýzu, eskalaci, zamezení šíření, obnovu, komunikaci a zlepšování.

Přínos je praktický. Když dohledový orgán podle DORA požádá o odůvodnění závažného incidentu souvisejícího s ICT, orgán podle NIS2 se zeptá na rozhodnutí o včasném varování do 24 hodin, úřad pro ochranu osobních údajů se zeptá, proč oznámení podle GDPR bylo nebo nebylo podáno, a auditor ISO se zeptá, zda ISMS fungoval podle plánu, organizace může odpovědět ze stejné sady důkazů.

Jak auditoři a regulační orgány otestují váš model

Auditor ISO/IEC 27001:2022 obvykle začne rozsahem a právními požadavky. Bude se ptát, zda byly DORA, NIS2, GDPR, zákaznické smlouvy a povinnosti třetích stran v oblasti ICT identifikovány jako požadavky zainteresovaných stran. Poté bude sledovat stopu do kritérií rizik, prohlášení o použitelnosti, postupů pro incidenty, provozních záznamů a uchovávání důkazů. Chce důkaz, že klasifikační proces nebyl vytvořen až během incidentu.

Dohledový orgán podle DORA nebo tým interního auditu bude hledat smyčku životního cyklu: proces řízení incidentů, ukazatele včasného varování, klasifikační kritéria, eskalaci závažných incidentů, komunikaci s klienty, kořenovou příčinu, konečné údaje o dopadu, testování odolnosti a dohled řídicího orgánu. Bude se také ptát, zda byly zohledněny závislosti na třetích stranách v oblasti ICT, zejména pokud byl zapojen cloud, SaaS, řízená bezpečnost nebo poskytovatelé outsourcingu.

Auditor nebo orgán zaměřený na NIS2 ověří, zda subjekt dokáže identifikovat významné incidenty, splnit etapové lhůty, komunikovat s dotčenými příjemci služeb a poskytnout důkazy o posouzení přeshraničního dopadu. Propojí zvládání incidentů s opatřeními pro řízení rizik podle Article 21, včetně kontinuity činností, krizového řízení, zabezpečení dodavatelského řetězce, řízení přístupu, správy aktiv a školení.

DPO podle GDPR nebo dozorový úřad posoudí, zda organizace identifikovala osobní údaje, role, subjekty údajů, kategorie, dotčené systémy, typ porušení a riziko pro fyzické osoby. Ověří, zda správce dokáže prokázat odpovědnost a zda oznámení zpracovatele správci byla včasná a úplná.

Auditor ve stylu ISACA nebo COBIT 2019 se zaměří na důkazy správy a řízení. Kdo schválil taxonomii závažnosti? Kdo vlastní riziko? Jaké metriky se reportují vedení? Jak se řeší výjimky? Jak se získané poznatky převádějí do zlepšení kontrol?

Běžné vzorce selhání při klasifikaci incidentů

Prvním selháním je uvažování v jednom štítku. Týmy klasifikují událost jako vysokou, střední nebo nízkou, ale samostatně neposuzují spouštěče DORA, NIS2 a GDPR. Výsledkem je štítek závažnosti, který nedokáže vysvětlit rozhodnutí o hlášení.

Druhým selháním je zkreslení potvrzeným porušením. Týmy čekají na absolutní důkaz exfiltrace, než zapojí ochranu soukromí nebo právní oddělení. Posouzení porušení podle GDPR často začíná možným neoprávněným přístupem, ztrátou, změnou nebo zpřístupněním, nikoli jen potvrzeným zveřejněním dat.

Třetím selháním je zmatek v běhu lhůt. Lhůty NIS2 a GDPR závisí na zjištění a posouzení. Pokud incidentní tiket nezachytí čas zjištění, čas klasifikace a čas eskalace, organizace může mít problém prokázat včasnost.

Čtvrtým selháním je forenzní šetření až po úklidu. Inženýři rotují klíče, obnovují hostitele a mažou dočasné důkazy před aktivací vyšetřovacího režimu. To může zničit důkazy potřebné pro regulatorní, smluvní nebo právní přezkum.

Pátým selháním je slepota vůči dodavatelům. DORA, NIS2 a NIST CSF 2.0 všechny zdůrazňují rizika třetích stran a dodavatelského řetězce. Pokud je součástí řetězce incidentu poskytovatel cloudových služeb, poskytovatel řízených služeb, zpracovatel plateb, poskytovatel identit nebo dodavatel SaaS, musí klasifikační model zahrnovat dopad na dodavatele a smluvní oznamovací povinnosti.

Implementační kontrolní seznam Clarysec pro rok 2026

Pro uvedení obhajitelného modelu klasifikace závažnosti incidentů do provozu Clarysec doporučuje tento postup:

1. Potvrďte regulatorní použitelnost napříč DORA, NIS2, GDPR, zákaznickými smlouvami a sektorovými pravidly.
2. Aktualizujte rozsah ISMS a požadavky zainteresovaných stran podle ISO/IEC 27001:2022.
3. Definujte interní úrovně závažnosti s měřitelnými prahovými hodnotami pro nedostupnost, data, zákazníky, geografii, finanční ztrátu a kritičnost.
4. Přidejte samostatné otázky vstupního posouzení pro DORA, NIS2 a GDPR do pracovního postupu incidentního tiketu.
5. Definujte spouštěče eskalace pro vedoucího řešení incidentu, DPO, právní oddělení, vrcholové vedení a řídicí orgán.
6. Vytvořte šablonu záznamu rozhodnutí o závažnosti.
7. Propojte klasifikaci se sběrem důkazů a postupy řetězce předávání důkazů.
8. Ověřte pokrytí protokolováním pro události identit, cloudu, aplikací, databází, sítě a dodavatelů.
9. Proveďte stolní cvičení pro scénáře závažného incidentu podle DORA, významného incidentu podle NIS2 a porušení zabezpečení podle GDPR.
10. Promítněte získané poznatky do ošetření rizik, prohlášení o použitelnosti, školení a testování odolnosti.

Zenith Blueprint, fáze Controls in Action, Step 16, posiluje lidskou stránku tohoto modelu: hlášení mají být zaznamenána, roztříděna, eskalována prostřednictvím plánu reakce na incidenty a i drobné události mají být sledovány, protože trendy odhalují slabiny kontrol. Podporuje přístup s nízkým prahem pro hlášení: „V případě pochybností hlaste.“

Tento kulturní prvek je kritický. Model závažnosti selže, pokud zaměstnanci odkládají hlášení, protože se obávají přehnané reakce. Cílem je rychlé hlášení, disciplinované třídění a obhajitelná klasifikace.

Přeměňte nejistotu kolem incidentu na důkazy připravené pro audit

V roce 2026 už klasifikace závažnosti incidentů není rozhodnutím pouze pro SOC. Je to regulovaný proces správy a řízení, který musí propojit kritéria závažných incidentů souvisejících s ICT podle DORA, prahové hodnoty významných incidentů podle NIS2, riziko porušení zabezpečení podle GDPR a důkazy podle ISO/IEC 27001:2022.

Nejlépe si při incidentech povedou organizace, které nebudou mít nejtlustší pořadač reakce. Budou to organizace, které dokážou rychle odpovědět na čtyři otázky a každou odpověď později doložit:

• Co se stalo?
• Jak závažné to je?
• Které regulatorní povinnosti se mohou uplatnit?
• Jaké důkazy rozhodnutí podporují?

Clarysec pomáhá organizacím vybudovat tento most prostřednictvím šablon politik, taxonomií závažnosti, záznamů rozhodnutí, stolních cvičení a mapování souladu napříč požadavky. Začněte politikami incidentů, ověřte svá kritéria rizik v Zenith Blueprint Zenith Blueprint a použijte Zenith Controls Zenith Controls k mapování opatření ISO/IEC 27002:2022 5.24, 5.25, 5.26, 5.27 a 5.28 napříč DORA, NIS2, GDPR, NIST CSF a auditními očekáváními.

Pokud váš tým nedokáže během první hodiny odpovědět na otázku „Je to závažný incident podle DORA, významný incident podle NIS2 nebo událost oznamovatelná podle GDPR?“, dalším krokem není další obecný plán reakce na incidenty. Dalším krokem je obhajitelný provozní model klasifikace závažnosti incidentů, otestovaný dříve, než přijde další hovor ve 02:17.

Jste připraveni nahradit paniku procesem? Stáhněte si šablony politik reakce na incidenty a sběru důkazů od Clarysec, přezkoumejte svou současnou taxonomii závažnosti vůči Zenith Blueprint nebo si vyžádejte posouzení připravenosti od Clarysec a vytvořte auditně připravený model klasifikace incidentů pro DORA, NIS2, GDPR a ISO/IEC 27001.