Класификация на тежестта на инциденти за DORA, NIS2 и GDPR

Обаждането за инцидент в 02:17, което се превръща в регулаторно решение

В 02:17 в четвъртък сутрин Сара, главен директор по информационна сигурност (CISO) на FinScale, вижда първото предупреждение: необичаен API трафик, рязко увеличение на неуспешните опити за автентикация и латентност на таблото за плащания над 3000 ms. В рамките на минути клиентската поддръжка докладва грешки в статуса на плащанията. Доставчикът на облачни услуги съобщава, че няма инцидент на ниво платформа. SOC вижда подозрителни токени за достъп от два географски региона. Продуктовият екип потвърждава, че таблото отново е онлайн след 19 минути, но дванадесет клиенти вече са отворили билети.

В 03:05 Сара е в кризисна конферентна връзка с ръководителя на инцидента, правния консултант, координатора по поверителност, ръководителя на облачните операции и изпълнителния спонсор. Техническият въпрос е достатъчно ясен: какво се случи с API шлюза? Регулаторните въпроси са по-трудни:

1. Това съществен ИКТ инцидент по DORA ли е?
2. Това значим инцидент по NIS2 ли е?
3. Има ли нарушение на сигурността на личните данни по GDPR, което изисква уведомяване?
4. Може ли организацията да докаже как е стигнала до тези отговори?

Грешният отговор може да създаде регулаторна експозиция. Бавният отговор може да доведе до пропуснат срок за докладване. Недокументираният отговор може да доведе до несъответствие при одит по ISO/IEC 27001:2022 месеци по-късно.

Това е предизвикателството пред реагирането при инциденти през 2026 г. Много организации имат план за реагиране при инциденти (IRP), форензични процедури, наръчници за поверителност и шаблони за кризисна комуникация. По-малко организации имат защитим модел за класификация на тежестта на инциденти, който превръща шумно събитие по сигурността в документирано решение спрямо очакванията за доказателства по DORA, NIS2, GDPR и ISO/IEC 27001:2022.

Решението не е в три отделни процеса за триаж. Решението е един управляван модел за тежест с отделни регулаторни слоеве, измерими прагове, правила за ескалация, регистри на решенията и изисквания за събиране на доказателства. На практика тежестта на инцидента не трябва да бъде етикет, избран под натиск. Тя трябва да бъде контролирано бизнес решение, което издържа на проверка от регулатори, одитори, членове на управителния орган, клиенти и длъжностното лице по защита на данните (DPO).

Защо класификацията на тежестта на инциденти вече е контрол на ниво управителен орган

Класификацията на инциденти преди беше предимно техническа: тежест на зловредния софтуер, засегнати хостове, експлоатирани уязвимости и дали е имало извличане на данни. През 2026 г. тя е и правна, финансова, обществена и договорна.

DORA превръща цифровата оперативна устойчивост в управленско задължение за финансовите субекти. От управителния орган се очаква да определя, одобрява, надзирава и запазва отговорността за рамката за управление на ИКТ риска. Това включва непрекъсваемост на дейността в областта на ИКТ, планове за реагиране и възстановяване, канали за докладване на съществени инциденти, риск от ИКТ трети страни и извлечени поуки.

NIS2 повишава управленския залог за съществените и важните субекти. Article 20 изисква управителните органи да одобряват мерките за управление на риска в киберсигурността, да наблюдават внедряването им и да преминават обучение. Той също свързва пропуските в управлението на риска и докладването на инциденти със сериозни надзорни последици. За съществените субекти максималните базови административни глоби могат да достигнат най-малко 10 000 000 евро или 2 процента от общия световен годишен оборот, в зависимост от това коя стойност е по-висока. За важните субекти базата е най-малко 7 000 000 евро или 1,4 процента от оборота, в зависимост от това коя стойност е по-висока.

GDPR добавя различна перспектива. Нарушението на сигурността на личните данни не се ограничава до потвърдено публично разкриване или откраднати файлове. То включва случайно или незаконосъобразно унищожаване, загуба, промяна, неразрешено разкриване или достъп до лични данни. Администраторите трябва да оценят риска за физическите лица и да докажат отчетност за решението дали да уведомят, или да не уведомят.

ISO/IEC 27001:2022 осигурява доказателствената основа за тези задължения. Клаузи 4.1 до 4.4 изискват организацията да разбира своя контекст, изискванията на заинтересованите страни, обхвата, интерфейсите и зависимостите. Клаузи 5.1 до 5.3 изискват ангажимент на ръководството, политика, роли, отговорности и докладване. Клаузи 6.1.1 до 6.1.3 изискват планиране, основано на риска, оценка на риска, третиране на риска и Декларация за приложимост. Клаузи 8.1 до 8.3 изискват оперативен контрол, контрол на промените, съхранени доказателства и повторна оценка, когато рисковите условия се променят. ISO/IEC 27001:2022

Когато се случи обаждането за инцидент, въпросът не трябва да бъде: „Кой смята, че това е критично?“ Той трябва да бъде: „Какво изискват от нас сега одобрените критерии, правните тригери, доказателствата и правилата за ескалация?“

Едно събитие, три системи за регулаторна класификация

DORA, NIS2 и GDPR не използват един и същ език за инцидентите. Това е основната причина организациите да срещат затруднения през първия час.

DORA Article 17 изисква финансовите субекти да създадат процес за управление на инциденти, свързани с ИКТ, който открива, управлява и уведомява за ИКТ инциденти, регистрира инциденти, свързани с ИКТ, и значими киберзаплахи, адресира първопричините, използва индикатори за ранно предупреждение, категоризира и класифицира инцидентите, възлага роли, управлява комуникациите, ескалира съществени инциденти към висшето ръководство и възстановява сигурните операции.

DORA Article 18 изисква класификация чрез критерии като засегнати клиенти, засегнати контрагенти, трансакции, продължителност, прекъсване, географски обхват, загуба на данни, засягаща наличността, автентичността, целостта или поверителността, критичност на засегнатите услуги и икономическо въздействие. DORA Article 19 изисква докладване на съществени инциденти, свързани с ИКТ, и комуникация с клиентите, когато са засегнати финансовите им интереси.

NIS2 Article 23 определя значим инцидент като инцидент, който е причинил или може да причини сериозно оперативно прекъсване или финансова загуба, или е засегнал или може да засегне други лица чрез причиняване на значителни материални или нематериални вреди. Той изисква ранно предупреждение в рамките на 24 часа от узнаването за значимия инцидент, уведомление за инцидента в рамките на 72 часа, междинни доклади при поискване и окончателен доклад в рамките на един месец от уведомлението за инцидента. Когато е приложимо, засегнатите получатели на услуги трябва също да бъдат информирани за мерките или средствата за защита, които могат да предприемат.

GDPR поставя въпроса за риска за поверителността. Довело ли е нарушение на сигурността до унищожаване, загуба, промяна, неразрешено разкриване или достъп до лични данни? Ако да, администраторът трябва да оцени риска за правата и свободите на физическите лица. Ако има вероятност нарушението да доведе до риск, надзорният орган по правило трябва да бъде уведомен в рамките на 72 часа от узнаването. Ако има вероятност да доведе до висок риск, засегнатите физически лица може да трябва да бъдат информирани без неоправдано забавяне.

Следователно един инцидент изисква едновременна класификация.

За финансовите субекти DORA е секторно-специфичният правен акт на Съюза за управление на ИКТ риска и задължения за докладване на инциденти, които се припокриват с NIS2. Това не прави NIS2 неотносима. Тя все още може да има значение за сътрудничество, информационни потоци, услуги извън периметъра на DORA, нефинансови дружества в групата, облачни услуги, управлявани услуги и договорни задължения към клиенти. Моделът за тежест трябва да записва не само резултата, но и логиката за приложимост.

Моделът на Clarysec: класифицирайте събитието, не емоцията

Clarysec започва с ISO/IEC 27002:2022 контрол 5.25, оценка и решение относно събития по информационната сигурност, като опорна точка за кръстосано съответствие. В Zenith Controls: The Cross-Compliance Guide Zenith Controls тази тема е съпоставена чрез записа „Оценка и решение относно събития по информационната сигурност“ за контрол 5.25, подкрепена от „Планиране и подготовка за управление на инциденти по информационната сигурност“ за контрол 5.24 и „Събиране на доказателства“ за контрол 5.28.

Най-важният момент за съответствие често не е ограничаването. Това е разклонението, при което събитие по сигурността става регулаторен инцидент, или при което то защитимо се записва като събитие с по-ниска тежест.

Zenith Blueprint: An Auditor’s 30-Step Roadmap на Clarysec Zenith Blueprint описва този момент във фазата „Контроли в действие“, стъпка 23:

„Не всяка аномалия е бедствие. Не всяко предупреждение сигнализира компрометиране. В реалния свят екипите по сигурност и бизнес звената са залети от шум, опити за вписване, аномалии в журналите, незначителни нарушения на политиката, неразрешени ИТ ресурси. Истинското предизвикателство не е само в откриването, а в разграничаването на безвредното от вредното и в знанието кое изисква ескалация.“

Това изречение улавя оперативния проблем. SIEM предупреждение не означава автоматично съществен инцидент по DORA. Временно прекъсване не означава автоматично значим инцидент по NIS2. Подозрителна заявка към база данни не означава автоматично задължение за уведомяване по GDPR. Всяко от тях може да стане подлежащо на докладване в зависимост от въздействието, обхвата, данните, засегнатите страни и доказателствата.

Zenith Blueprint, фаза „Управление на риска“, стъпка 10, също препоръчва дефинициите за въздействие да бъдат адаптирани към мащаба на бизнеса и регулаторната експозиция:

„Когато дефинирате въздействие, е разумно да обвържете нивата с конкретния мащаб на вашия бизнес. Например „Съществено финансово въздействие = загуба > $100k“ (адаптирайте към вашия контекст). Също така вземете предвид регулаторното въздействие: например нарушение на сигурността на личните данни може автоматично да бъде „Съществено“ или „Тежко“ поради глоби и изисквания за уведомяване по GDPR, дори ако пряката финансова загуба е неясна.“

Това е проектният принцип за класификацията на тежестта на инциденти през 2026 г.: тежестта е бизнес въздействие плюс правно въздействие плюс надеждност на доказателствата.

Практическа таксономия на тежестта на инциденти за DORA, NIS2 и GDPR

Защитимата таксономия трябва да отделя вътрешната тежест от регулаторната класификация. Вътрешната тежест определя спешността на реагирането, разпределението на ресурси и ескалацията към изпълнителното ръководство. Регулаторната класификация определя уведомяването, правния преглед и външната комуникация.

Вътрешното ниво на тежест не е окончателният регулаторен отговор. То е оперативният режим. Събитие SEV 3 може да стане подлежащо на уведомяване по GDPR след преглед на журналите. Прекъсване SEV 2 може да не е съществен инцидент по DORA, ако праговете за въздействие не са изпълнени. Инцидент с рансъмуер SEV 1 може едновременно да задейства DORA, NIS2, GDPR, клиентски договори и координация с правоприлагащи органи.

По-подробна матрица за класификация помага на екипа да премине от предупреждение към действие.

Моделът трябва да бъде вграден в политика, а не оставен на най-силния глас в кризисната връзка. SME Incident Response Policy-sme Incident Response Policy-sme - SME, „Изисквания за управление“, клауза 5.3.1, посочва:

„Управителят, с принос от доставчика на ИТ услуги, трябва да класифицира всички инциденти по тежест в рамките на един час от уведомяването.“

Същата SME политика, „Третиране на риска и изключения“, клауза 7.4.1, добавя:

„Когато са засегнати клиентски данни, управителят трябва да оцени правните задължения за уведомяване въз основа на приложимостта на GDPR, NIS2 или DORA.“

За по-големи организации корпоративната Политика за реагиране при инциденти Политика за реагиране при инциденти, „Изисквания за управление“, клауза 5.3, формализира същата концепция:

„Класификацията на инциденти трябва да се извършва по многостепенен модел:“

Езикът на политиката има значение, защото регулаторите и одиторите ще попитат дали критериите за класификация са съществували преди инцидента. Матрица, създадена след факта, е слабо доказателство. Матрица, която е одобрена, обучена, упражнявана и използвана последователно, е защитима.

Регистърът на решенията: най-важният доказателствен артефакт

Когато одитори, регулатори или членове на управителния орган преглеждат инцидент, те рядко питат само: „Какво се случи?“ Те питат: „Кога разбрахте, кой взе решението, въз основа на какви доказателства и защо не уведомихте по-рано?“

Затова Clarysec препоръчва регистър на решенията за тежест за всяко събитие SEV 3 и по-високо и за всяко събитие, включващо лични данни, критични услуги, финансови клиенти, управлявани услуги, облачна инфраструктура или трансгранично въздействие.

Това се съпоставя пряко с ISO/IEC 27001:2022. Клауза 8.1 изисква процесите да бъдат планирани, внедрени и контролирани, като се съхранява достатъчна документирана информация, за да се покаже, че са функционирали по план. Клаузи 8.2 и 8.3 изискват повторна оценка при настъпване на значими промени и съхранение на доказателства за третиране на риска. Контролите в Приложение A от A.5.24 до A.5.28 осигуряват гръбнака на управлението на инциденти: планиране и подготовка, оценка и решение за събития, реагиране, учене от инциденти и събиране на доказателства.

SME Политика за защита на данните и поверителност-sme Политика за защита на данните и поверителност-sme - SME, „Прилагане и съответствие“, клауза 8.3.2, подкрепя GDPR страната на модела:

„Координаторът по поверителност трябва да определи тежестта, да започне действия за ограничаване и да документира случая.“

Оценката на поверителността не трябва да започва едва след като регулаторният часовник стане неудобен. Тя принадлежи в работния поток за триаж.

Практически пример: класифициране на API инцидента на Сара

Да се върнем към FinScale. Това е B2B fintech платформа, която използва облачна инфраструктура, външен доставчик на анализ за измами и доставчик на управлявани услуги за сигурност. За част от дейностите си тя е финансов субект, обхванат от DORA. Тя е също доставчик на цифрови услуги с операции, релевантни за NIS2, в една държава членка. Обработва клиентски лични данни като администратор за услуги по акаунти и като обработващ лични данни за някои корпоративни клиенти.

В 02:17 е открит необичаен API трафик. В 02:35 е отворен билет за инцидента. В 03:00 Сара завършва първоначалния триаж с ръководителя на инцидента.

Първо се определя вътрешната тежест. Инцидентът е засегнал наличността на клиентско табло за 19 минути, включвал е подозрителни токени за достъп и е засягал критична клиентска функция. Той е класифициран като SEV 3 Умерена до потвърждение, с ескалация към ръководителя на инцидента, координатора по поверителност, правния консултант и собственика на услугата.

Второ, проверката по DORA е завършена. Екипът проверява засегнати клиенти, контрагенти, трансакции, продължителност, прекъсване, географски обхват, загуба на данни, критичност и икономическо въздействие. Не са потвърдени неуспешни или променени трансакции. Прекъсването е ограничено. Не е доказана загуба на данни. Въпреки това, тъй като може да са засегнати компонент на критична финансова услуга и финансовите интереси на клиенти, инцидентът остава под мониторинг по DORA и може да бъде прекласифициран.

Трето, проверката по NIS2 е записана. Екипът отбелязва, че DORA е основният секторно-специфичен режим за докладване за задълженията на обхванатия финансов субект. Той също проверява дали инцидентът засяга услуги или клиенти извън периметъра на DORA. На този етап не е потвърдено сериозно оперативно прекъсване или значителна вреда.

Четвърто, започва проверката по GDPR. Подозрителните токени може да са позволили достъп до данни в клиентското табло. Координаторът по поверителност документира категориите данни, засегнатите потребители, обхвата на токените, прегледаните журнали, дали данните са били прегледани или експортирани, както и предпазни мерки като изтичане на токени и контроли на достъпа.

Към 04:20 анализът на журналите показва, че два токена са използвани за достъп до метаданни в таблото за 41 клиенти, включително имена, идентификатори на акаунти и статус на трансакции, но без платежни удостоверителни данни или документи за самоличност. Екипът актуализира инцидента до SEV 2 Съществена, защото е засегната поверителността на лични данни и може да се изисква комуникация с клиенти. DPO оценява риска за физическите лица по GDPR. Решението по DORA се преразглежда въз основа на въздействието върху клиенти, трансакции и икономическо въздействие.

Това е практическата стойност на модела. Първоначалната класификация не е окончателно правно заключение. Тя е решение, основано на доказателства, което може да бъде актуализирано с развитието на фактите.

Регистриране, мониторинг и форензични доказателства: доказателственият слой

Модел за тежест без доказателства е мнение от среща. Очакването през 2026 г. е класификацията да бъде подкрепена с журнали, мониторинг, запазени артефакти и верига на съхранение.

SME Политика за регистриране и мониторинг-sme Политика за регистриране и мониторинг-sme - SME, „Прилагане и съответствие“, клауза 8.3.4, посочва:

„Разследванията на нарушения трябва да бъдат подкрепени с достатъчни журнали, за да отговорят на принципа на отчетност по GDPR и DORA.“

Форензичната обработка е също толкова важна. SME Политика за събиране на доказателства и форензика-sme Политика за събиране на доказателства и форензика-sme - SME, „Изисквания за управление“, клауза 5.3.1, изисква:

„За всеки инцидент трябва да се поддържа прост регистър на веригата на съхранение (напр. Excel файл или шаблонен документ).“

За корпоративни среди Политика за събиране на доказателства и форензика Политика за събиране на доказателства и форензика, „Изисквания за управление“, клауза 5.5, изисква:

„Всички събрани доказателства трябва да бъдат уникално идентифицирани, етикетирани и съхранявани в защитено хранилище с:“

Zenith Blueprint, фаза „Контроли в действие“, стъпка 23, обяснява защо това е важно за ISO/IEC 27002:2022 контрол 5.28:

„Когато настъпи инцидент по информационна сигурност, един от най-критичните, но често пренебрегвани елементи на реагирането са доказателствата. Не журнали, не екранни снимки, не свободни разкази, а правилно запазени доказателства, които спазват веригата на съхранение и са устойчиви на подправяне.“

Практическият доказателствен пакет за съществен или потенциално подлежащ на докладване инцидент трябва да включва:

• Билет за инцидента и хронология
• Регистър на решенията за тежест и история на прекласификацията
• SIEM предупреждения, EDR предупреждения, облачни журнали и журнали за идентичности
• Журнали за достъп до данни и журнали за експортиране
• Записи в инвентара на засегнатите активи и услуги
• Оценка на въздействието върху клиенти, трансакции и географски обхват
• Работен лист за проверка по DORA, NIS2 и GDPR
• Оценка от DPO или правен отдел
• Одобрения на комуникации и изпратени съобщения
• Запис на веригата на съхранение
• Анализ на първопричините
• Коригиращи действия и извлечени поуки

Този доказателствен пакет също подкрепя контролите от Приложение A на ISO/IEC 27001:2022 A.8.15 регистриране, A.8.16 дейности по мониторинг, A.5.28 събиране на доказателства, A.5.27 учене от инциденти по информационна сигурност, A.5.31 правни, законови, регулаторни и договорни изисквания и A.5.34 поверителност и защита на личната идентифицираща информация.

Съпоставяне за кръстосано съответствие: изградете веднъж, отговаряйте на много одитори

Най-силните модели за тежест на инциденти се изграждат веднъж и се съпоставят многократно. Zenith Controls е проектиран като компас за кръстосано съответствие за тази работа. За тази тема основните записи по ISO/IEC 27002:2022 са 5.24 планиране и подготовка за управление на инциденти по информационна сигурност, 5.25 оценка и решение относно събития по информационна сигурност, 5.26 реагиране на инциденти по информационна сигурност, 5.27 учене от инциденти по информационна сигурност и 5.28 събиране на доказателства.

Тези контроли естествено се свързват със системата за управление по ISO/IEC 27001:2022. Клаузи 4, 5, 6 и 8 дефинират обхват, лидерство, критерии за риска, третиране и оперативни доказателства. ISO/IEC 27002:2022 предоставя езика за внедряване на контролите. Подходът на ISO 22301 към непрекъсваемостта на дейността подкрепя прагове за прекъсване, приоритети за възстановяване и кризисно управление. Практиките за управление на инциденти по ISO/IEC 27035 подкрепят структурирано откриване, докладване, оценка, реагиране и учене. Управлението на поверителността по ISO/IEC 27701 подкрепя ролите при нарушение на сигурността на личните данни, съображенията за администратор и обработващ лични данни, доказателствата за поверителност и отчетността.

Същият модел се съпоставя с NIST Cybersecurity Framework 2.0. Функцията GOVERN изисква правните, регулаторните, договорните, свързаните с поверителността и гражданските свободи задължения да бъдат разбрани и управлявани. Тя също очаква да бъдат дефинирани апетит за риск, роли, правомощия, политики и надзор. Функциите DETECT, RESPOND и RECOVER подкрепят триаж, анализ, ескалация, ограничаване, възстановяване, комуникации и подобрение.

Ползата е практическа. Когато надзорен орган по DORA поиска обосновка за съществен инцидент, свързан с ИКТ, орган по NIS2 попита за решението относно ранното предупреждение в рамките на 24 часа, орган по защита на данните попита защо е направено или не е направено уведомление по GDPR, а ISO одитор попита дали СУИС е функционирала по план, организацията може да отговори от един и същ набор доказателства.

Как одиторите и регулаторите ще тестват вашия модел

Одитор по ISO/IEC 27001:2022 обикновено ще започне с обхвата и правните изисквания. Той ще попита дали DORA, NIS2, GDPR, клиентските договори и задълженията към ИКТ трети страни са идентифицирани като изисквания на заинтересованите страни. След това ще проследи следата към критериите за риска, Декларацията за приложимост, процедурите за инциденти, оперативните записи и съхранението на доказателства. Той иска доказателство, че процесът за класификация не е измислен по време на инцидента.

Надзорен орган по DORA или екип за вътрешен одит ще търси контрол през целия жизнен цикъл: процес за управление на инциденти, индикатори за ранно предупреждение, критерии за класификация, ескалация на съществени инциденти, комуникация с клиенти, първопричина, окончателни стойности на въздействието, тестване на устойчивостта и надзор от управителния орган. Те също ще попитат дали са разгледани зависимостите от ИКТ трети страни, особено когато са участвали облак, SaaS, управлявани услуги за сигурност или доставчици на външно възложени услуги.

Одитор или орган с фокус върху NIS2 ще провери дали субектът може да идентифицира значими инциденти, да спазва поетапните срокове, да комуникира със засегнатите получатели на услуги и да предоставя доказателства за оценка на трансграничното въздействие. Той ще свърже обработването на инциденти с мерките за управление на риска по Article 21, включително непрекъсваемост на дейността, кризисно управление, сигурност на веригата на доставки, контрол на достъпа, управление на активите и обучение.

DPO по GDPR или надзорен орган ще провери дали организацията е идентифицирала лични данни, роли, субекти на данни, категории, засегнати системи, тип нарушение и риск за физическите лица. Те ще проверят дали администраторът може да докаже отчетност и дали уведомленията от обработващи лични данни към администратори са били своевременни и пълни.

Одитор в стил ISACA или COBIT 2019 ще се фокусира върху управленските доказателства. Кой одобри таксономията на тежестта? Кой е собственик на риска? Какви показатели се докладват на ръководството? Как се обработват изключенията? Как извлечените поуки се превръщат в подобрения на контролите?

Чести модели на неуспех при класификацията на инциденти

Първият неуспех е мисленето с един етикет. Екипите класифицират събитие като високо, средно или ниско, но никога не оценяват отделно тригерите по DORA, NIS2 и GDPR. Резултатът е етикет за тежест, който не може да обясни решение за докладване.

Вторият неуспех е пристрастност към потвърдено нарушение. Екипите чакат абсолютно доказателство за извличане на данни, преди да включат поверителност или правен отдел. Оценката на нарушение по GDPR често започва с възможен неразрешен достъп, загуба, промяна или разкриване, а не само с потвърдено публикуване на данни.

Третият неуспех е объркване на часовника. Сроковете по NIS2 и GDPR зависят от узнаването и оценката. Ако билетът за инцидента не улавя часа на узнаване, часа на класификация и часа на ескалация, организацията може да има затруднения да докаже своевременност.

Четвъртият неуспех е форензика след почистване. Инженерите ротират ключове, преизграждат хостове и изтриват временни доказателства, преди да бъде задействан режим за разследване. Това може да унищожи доказателства, необходими за регулаторен, договорен или правен преглед.

Петият неуспех е слепота към доставчиците. DORA, NIS2 и NIST CSF 2.0 подчертават риска от трети страни и веригата на доставки. Ако доставчик на облачни услуги, доставчик на управлявани услуги, обработващ плащания, доставчик на идентичност или SaaS доставчик е част от веригата на инцидента, моделът за класификация трябва да включва въздействие върху доставчика и договорни задължения за уведомяване.

Контролен списък на Clarysec за внедряване през 2026 г.

За да операционализира защитим модел за класификация на тежестта на инциденти, Clarysec препоръчва следната последователност:

1. Потвърдете регулаторната приложимост по DORA, NIS2, GDPR, клиентски договори и секторни правила.
2. Актуализирайте обхвата на СУИС и изискванията на заинтересованите страни по ISO/IEC 27001:2022.
3. Дефинирайте вътрешни нива на тежест с измерими прагове за прекъсване, данни, клиенти, география, финансова загуба и критичност.
4. Добавете отделни въпроси за проверка по DORA, NIS2 и GDPR към работния поток за билети за инциденти.
5. Дефинирайте тригери за ескалация към ръководителя на инцидента, DPO, правен отдел, висше ръководство и управителния орган.
6. Създайте шаблон за регистър на решенията за тежест.
7. Свържете класификацията със събиране на доказателства и процедури за верига на съхранение.
8. Валидирайте покритието на регистрирането за събития, свързани с идентичност, облак, приложение, база данни, мрежа и доставчици.
9. Проведете настолни упражнения за сценарии за съществен инцидент по DORA, значим инцидент по NIS2 и нарушение по GDPR.
10. Включете извлечените поуки в третирането на риска, Декларацията за приложимост, обучението и тестването на устойчивостта.

Zenith Blueprint, фаза „Контроли в действие“, стъпка 16, подсилва човешката страна на този модел: докладите трябва да се регистрират, триажират и ескалират чрез плана за реагиране при инциденти (IRP), а дори незначителните събития трябва да се проследяват, защото тенденциите разкриват слабости в контролите. Той насърчава нагласа за докладване при нисък праг: „При съмнение докладвайте.“

Този културен аспект е критичен. Моделът за тежест се проваля, ако служителите забавят докладването, защото се страхуват от прекомерна реакция. Целта е бързо докладване, дисциплиниран триаж и защитима класификация.

Превърнете несигурността при инциденти в доказателства, готови за одит

През 2026 г. класификацията на тежестта на инциденти вече не е решение само на SOC. Тя е регулиран управленски процес, който трябва да свързва критериите за съществен инцидент, свързан с ИКТ, по DORA, праговете за значим инцидент по NIS2, риска от нарушение по GDPR и доказателствата по ISO/IEC 27001:2022.

Организациите, които се представят най-добре по време на инциденти, няма да бъдат тези с най-дебелата папка за реагиране. Това ще бъдат тези, които могат бързо да отговорят на четири въпроса и по-късно да докажат всеки отговор:

• Какво се случи?
• Колко тежко е?
• Кои регулаторни задължения може да се прилагат?
• Какви доказателства подкрепят решението?

Clarysec помага на организациите да изградят този мост чрез шаблони за политики, таксономии на тежестта, регистри на решенията, настолни сценарии и съпоставяния за кръстосано съответствие. Започнете с политиките за инциденти, валидирайте критериите си за риска в Zenith Blueprint Zenith Blueprint и използвайте Zenith Controls Zenith Controls, за да съпоставите контролите ISO/IEC 27002:2022 5.24, 5.25, 5.26, 5.27 и 5.28 спрямо очакванията по DORA, NIS2, GDPR, NIST CSF и одит.

Ако вашият екип не може да отговори „Това DORA major, NIS2 significant или подлежащо на уведомяване по GDPR ли е?“ в рамките на първия час, следващата стъпка не е още един общ план за реагиране при инциденти (IRP). Следващата стъпка е защитим оперативен модел за класификация на тежестта на инциденти, тестван преди следващото обаждане в 02:17.

Готови ли сте да замените паниката с процес? Изтеглете шаблоните на Clarysec за политики за реагиране при инциденти и събиране на доказателства, прегледайте текущата си таксономия на тежестта спрямо Zenith Blueprint или поискайте оценка на готовността от Clarysec, за да изградите готов за одит модел за класификация на инциденти по DORA, NIS2, GDPR и ISO/IEC 27001.