Докладване на инциденти по DORA и контроли на ISO 27001 през 2026 г.

В 08:17 във вторник сутрин през 2026 г. Сара, директор по информационна сигурност (CISO) на европейска финтех компания, вижда табло за наблюдение, което мига в кехлибарено, а не в червено. Критична платформа за сетълмент на плащания се забавя. Транзакциите не отказват напълно, но се обработват три пъти по-бавно от допустимото по споразуменията за ниво на услугата (SLA). Екипът на SOC вижда необичайни опити за автентикация към администраторски акаунт. Доставчикът на облачна инфраструктура докладва деградация на услугата в една зона на наличност. Екипът за клиентска поддръжка започва да получава обаждания от корпоративни клиенти, които питат защо платежните файлове се забавят.

Все още никой не знае дали това е кибератака, отказ на оперативната устойчивост, недостъпност при доставчик, инцидент, свързан със защитата на личните данни, или всички тези неща едновременно.

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

Точно тук финансовите субекти откриват разликата между това да имат план за реагиране при инциденти (IRP) и това да имат подлежащ на одит оперативен модел за докладване на инциденти по DORA.

Докладването на инциденти по DORA през 2026 г. изисква повече от бърза ескалация. То изисква защитима верига от откриване до класификация, от класификация до докладване към надзорния орган, от докладване до отстраняване и от отстраняване до извлечени поуки. ISO/IEC 27001:2022 предоставя структурата на системата за управление. Контролите от Приложение A на ISO/IEC 27002:2022 предоставят практическите очаквания към контролите. Политиките на Clarysec, 30-стъпковата пътна карта и ръководството за междурегулаторно съответствие превръщат тези очаквания във внедряване, подкрепено с доказателства.

Защо докладването на инциденти по DORA се проваля под натиск

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

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

Докато организацията постигне съгласие по класификацията, срокът за докладване вече е под натиск.

Членове 17–21 на DORA създават структурирано очакване за управление, класификация, докладване, съдържание на докладите и надзорна обработка на инциденти, свързани с ИКТ. За финансовите субекти практическото изискване е ясно: да наблюдават, управляват, журналират, класифицират, докладват, актуализират и извличат поуки от инциденти, свързани с ИКТ, по начин, който може да бъде реконструиран впоследствие.

Политиката за реагиране при инциденти [IRP] на Clarysec включва DORA директно в референтната рамка:

EU DORA (2022/2554): Article 17: Изисквания за докладване на ИКТ инциденти от финансови институции до компетентните органи.

Същата политика свързва управлението на инциденти с контроли 5.25–5.27 на ISO/IEC 27002:2022, като обхваща отговорностите за оценка на инциденти, реагиране, комуникация и подобрение.

За по-малки финтех дружества и регулирани субекти с ограничени ресурси Политиката за реагиране при инциденти — SME [IRP-SME] на Clarysec прави задължението приложимо на практика, като подчертава, че DORA изисква от финансовите субекти да класифицират, докладват и проследяват инциденти и прекъсвания, свързани с ИКТ.

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

ISO/IEC 27001:2022 като команден център за инциденти по DORA

Зряла система за управление на информационната сигурност (СУИС) по ISO/IEC 27001:2022 не трябва да се превръща в още един силоз за съответствие, разположен до DORA. Тя трябва да бъде командният център за докладване на инциденти по DORA.

СУИС вече изисква собственост върху риска, избор на контроли, вътрешен одит, преглед от ръководството, документирана информация, непрекъснато подобрение и доказателства за функциониране на контролите. DORA добавя секторно специфичен натиск за докладване, но ISO/IEC 27001:2022 дава управленската структура, чрез която процесът става повторяем.

Zenith Blueprint: 30-стъпкова пътна карта за одитори [ZB] на Clarysec засилва тази интеграция в стъпка 13 — планиране на третирането на риска и Декларация за приложимост. Blueprint препоръчва съпоставяне на контролите с рискове и клаузи за проследимост, включително добавяне на препратка към контрол от Приложение A към рисковете и отбелязване кога контролите подпомагат GDPR, NIS2 или DORA.

За инцидента със сетълмента на плащания при Сара записът в регистъра на риска може да бъде:

„Прекъсване или компрометиране на платформата за обработка на плащания.“

Съпоставените контроли от Приложение A на ISO/IEC 27001:2022 биха включвали 5.24, 5.25, 5.26, 5.27, 5.28, 6.8, 8.15 и 8.16, с бележка по DORA за класификация и докладване на съществени инциденти, свързани с ИКТ.

След това Zenith Controls: ръководство за междурегулаторно съответствие [ZC] на Clarysec действа като компас за междурегулаторно съответствие. В Zenith Controls Clarysec съпоставя контролите на ISO/IEC 27002:2022 с други контроли по ISO/IEC 27001:2022, свързани стандарти, одитни очаквания и регулации като DORA, GDPR и NIS2. То не създава отделни „Zenith контроли“. То показва как съществуващите ISO контроли функционират заедно и как се тестват.

Работният поток за докладване по DORA може да се разглежда като верига от контроли:

Не можете да докладвате това, което не сте открили. Не можете да класифицирате това, което не сте оценили. Не можете да обосновете решение за докладване без записи. Не можете да подобрявате без преглед след инцидент.

Контрол 6.8: часовникът по DORA започва от хората

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

Затова контрол 6.8 от Приложение A на ISO/IEC 27001:2022, докладване на събития по информационната сигурност, е съществен за DORA. Той превръща докладването в отговорност на персонала, а не само във функция на операциите по сигурността.

В Zenith Blueprint, стъпка 16, „Контроли за персонала II“, Clarysec посочва:

Ефективната система за реагиране при инциденти започва не с инструменти, а с хора.

Стъпка 16 препоръчва ясни канали за докладване, обучение за повишаване на осведомеността, култура без търсене на вина, триаж, поверителност и периодични симулации. Най-полезното практическо послание е просто:

„При съмнение — докладвайте.“

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

В Zenith Controls 6.8 е съпоставен като откриващ контрол, който подпомага поверителност, цялостност и наличност. Той се свързва с 5.24, защото каналите за докладване трябва да бъдат част от плана за инциденти. Подхранва 5.25, защото събитията могат да бъдат оценени само ако са докладвани. Задейства 5.26, защото формалното реагиране започва след оценяване на докладите.

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

Практическо внедряване от Clarysec е едностраничен инструктаж „Как да докладваме ИКТ инцидент“. Той следва да включва:

• Какво да се докладва, включително недостъпност на услуги, подозрителни имейли, изгубени устройства, необичайно поведение на системи, подозирано компрометиране на доставчик, неоторизиран достъп, изтичане на данни и влошаване на услугата с въздействие върху клиенти.
• Как да се докладва, чрез наблюдавана пощенска кутия, категория в билетна система, гореща линия, канал за сътрудничество или SOC портал.
• Какво да се включи, например време, система, потребител, бизнес процес, наблюдавано въздействие, екранни снимки, ако е безопасно, и дали може да са засегнати клиенти или лични данни.
• Какво да не се прави, включително да не се изтриват журнали, да не се рестартират критични системи, освен ако не е указано, да не се контактува външно с клиенти без одобрение и да не се разследва извън рамките на ролята.
• Какво следва, включително триаж, класификация, ескалация, реагиране, запазване на доказателства и възможна регулаторна оценка.

Целта не е всеки служител да стане разследващ. Целта е всеки служител да бъде надежден източник на сигнал.

Контрол 5.25: точката за решение по класификацията на DORA

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

Zenith Blueprint, стъпка 23, обяснява практическото предизвикателство:

Не всяка аномалия е бедствие. Не всяко предупреждение означава компрометиране.

След това описва целта на 5.25 като:

разграничаване на безвредното от вредното и знание какво изисква ескалация.

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

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

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

Clarysec адресира това, като вгражда класификацията по DORA в модела за сериозност на инциденти. В корпоративната Политика за реагиране при инциденти клауза 5.3.1 включва ясен пример за Ниво 1:

Ниво 1: Критично (напр. потвърдено нарушение на сигурността на данните, ransomware епидемия, компрометиране на продукционна система)

За по-малки организации Политиката за реагиране при инциденти — SME добавя стегнато оперативно очакване:

Управителят (GM), с входна информация от ИТ доставчика, трябва да класифицира всички инциденти по степен на сериозност в рамките на един час от уведомяването.

Тази едночасова цел за класификация е силна, защото налага управленска дисциплина. По-малък регулиран субект може да няма 24/7 SOC, но все пак може да определи кой класифицира, кой консултира и колко бързо трябва да бъде взето решението.

Запис за триаж на инцидент от DORA към ISO

За да бъде класификацията защитима, създайте запис за триаж на инцидент по DORA във вашата билетна система, GRC платформа или система за управление на инциденти. Записът следва да се създава за всяко потенциално съществено ИКТ събитие, дори ако по-късно бъде понижено по сериозност.

Добавете бележка към решението:

„Въз основа на прекъсване на платежна услуга, засягащо критичен бизнес процес, неизяснена първопричина и потенциално въздействие върху клиенти, събитието се ескалира като потенциален съществен инцидент, свързан с ИКТ. Функциите по съответствие и правни въпроси да оценят изискванията за регулаторно уведомяване. Започнато е запазване на доказателства.“

Този единствен запис подпомага проследяването по член 17 на DORA, класификацията по член 18, решенията за докладване по член 19, оценката по 5.25 от Приложение A на ISO/IEC 27001:2022, докладването по 6.8, реагирането по 5.26 и обработването на доказателства по 5.28.

Контроли 5.24 и 5.26: планиране, роли и реагиране

Когато възникне инцидент по DORA, планът за реагиране трябва вече да отговаря на неудобните въпроси.

Кой има правомощия да класифицира? Кой контактува с компетентния орган? Кой одобрява първоначалното уведомяване? Кой комуникира с клиенти? Кой контактува с външния доставчик на ИКТ услуги? Кой решава дали инцидентът задейства и уведомяване по GDPR? Кой запазва доказателства? Кой е собственик на окончателния доклад?

Контрол 5.24 от Приложение A на ISO/IEC 27001:2022, планиране и подготовка за управление на инциденти по информационната сигурност, отговаря на тези въпроси преди кризата. Контрол 5.26, реагиране при инциденти по информационната сигурност, гарантира, че планът се превръща в контролирани действия по време на инцидента.

В Zenith Controls 5.24 е свързан с членове 17–21 на DORA, защото въвежда в действие документирано, тествано и преглеждано реагиране при инциденти, включително вътрешна ескалация, външно регулаторно уведомяване, комуникация със заинтересовани страни и извлечени поуки.

ISO/IEC 27035-1:2023 подпомага това, като разширява управлението на инциденти отвъд процедурите за реагиране към политика, планиране, способности, взаимоотношения, механизми за подкрепа, осведоменост, обучение и редовно тестване. ISO/IEC 27035-2:2023 допълнително детайлизира процеса за управление на инциденти от подготовката до извлечените поуки.

Zenith Blueprint, стъпка 23, дава пряка инструкция за внедряване:

Уверете се, че разполагате с актуален План за реагиране при инциденти (5.24), който обхваща подготовка, ескалация, реагиране и комуникация.

Готовият за DORA план за реагиране при инциденти следва да дефинира:

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

Политиката за реагиране при инциденти — SME също свързва сроковете за реагиране с правните изисквания:

Сроковете за реагиране, включително възстановяване на данни и задължения за уведомяване, трябва да бъдат документирани и съгласувани с правните изисквания, например 72-часовото изискване за уведомяване при нарушение на сигурността на личните данни по GDPR.

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

Контроли 8.15 и 8.16: журналите правят доклада защитим

Докладването на инциденти по DORA зависи от факти. Фактите зависят от журналиране и мониторинг.

В сценария със сетълмента на плащания Сара трябва да знае кога е започнала деградацията, кои системи са били засегнати, дали са използвани привилегировани акаунти, дали данни са напуснали средата, дали прекъсването при облачния доставчик съответства на вътрешната телеметрия и кога възстановяването е приключило.

Контрол 8.15, журналиране, и 8.16, дейности по мониторинг, от Приложение A на ISO/IEC 27001:2022 подкрепят тази доказателствена база. В Zenith Controls и двата се свързват с 5.24, защото планирането на реагиране при инциденти трябва да включва използваеми журнални данни и способност за мониторинг. Контрол 8.16 се свързва и с 5.25, защото предупрежденията трябва да преминават триаж до решения.

Политиката за журналиране и мониторинг — SME [LMP-SME] на Clarysec включва практическо изискване за ескалация:

Предупрежденията с висок приоритет трябва да бъдат ескалирани към GM и Координатора по поверителност в рамките на 24 часа

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

Готовият за DORA модел за журналиране следва да включва:

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

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

Контрол 5.28: събиране на доказателства и верига на съхранение

При съществен инцидент, свързан с ИКТ, доказателствата служат за три цели: техническо разследване, регулаторна отчетност и правна обоснованост.

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

Политиката за събиране на доказателства и форензика [ECF] на Clarysec посочва:

Журнал на веригата на съхранение трябва да придружава всички физически или цифрови доказателства от момента на придобиване до архивиране или предаване и трябва да документира:

SME версията, Политика за събиране на доказателства и форензика — SME [ECF-SME], запазва изискването просто:

Всеки елемент от цифрови доказателства трябва да бъде регистриран с:

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

ISO/IEC 27006-1:2024 засилва това одитно очакване, като подчертава процедурите за идентифициране, събиране и запазване на доказателства от инциденти по информационната сигурност. За DORA същият набор от доказателства може да подкрепи първоначалното уведомяване, междинните актуализации, окончателния доклад, прегледа след инцидент и въпросите от надзорния орган.

Практически контролен списък с доказателства за инциденти, свързани с DORA, следва да включва:

• Билет за инцидент и бележки от триаж.
• Хронология на откриване, ескалация, класификация, докладване, ограничаване, възстановяване и закриване.
• SIEM предупреждения и корелирани журнали.
• Артефакти от крайни точки и сървъри.
• Журнали за идентичност и привилегирован достъп.
• Обобщения на мрежовия трафик.
• Статус от облачния доставчик и одитни журнали.
• Комуникации с доставчици и изявления за инцидента.
• Записи за въздействието върху бизнеса, включително клиенти, услуги, транзакции и престой.
• Проекти и подадени регулаторни уведомления.
• Решения и одобрения от ръководството.
• Анализ на първопричината.
• Извлечени поуки и коригиращи действия.

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

Контрол 5.27: извлечени поуки и непрекъснато подобрение

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

Контрол 5.27 от Приложение A на ISO/IEC 27001:2022, извличане на поуки от инциденти по информационната сигурност, свързва докладването по DORA с цикъла на непрекъснато подобрение по ISO/IEC 27001:2022. В Zenith Controls 5.24 е свързан с 5.27, защото управлението на инциденти е непълно без анализ на първопричината, извлечени поуки и подобрение на контролите.

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

Шаблонът за извлечени поуки следва да обхваща:

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

Това също захранва прегледа от ръководството по ISO/IEC 27001:2022. Тенденции при инцидентите следва да се преглеждат от ръководството, а не да остават скрити в технически прегледи след инцидент.

Междурегулаторно съответствие: DORA, GDPR, NIS2, NIST и COBIT 2019

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

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

Zenith Controls помага да се намали тази сложност, като съпоставя контролите на ISO/IEC 27002:2022 между рамки. Например:

От гледна точка на NIST същият модел подпомага резултатите Detect, Respond и Recover. От гледна точка на COBIT 2019 и одита по ISACA въпросът е управлението: дали управлението на инциденти, непрекъсваемостта на дейността, рискът, съответствието, отговорностите на доставчици и мониторингът на резултатността са контролирани.

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

Как одиторите ще тестват вашия процес за инциденти по DORA

Готовият за DORA процес за докладване на инциденти трябва да издържа на различни одитни гледни точки.

Одитор по ISO/IEC 27001:2022 ще провери дали СУИС е избрала и внедрила релевантните контроли от Приложение A, дали Декларацията за приложимост подкрепя тези контроли, дали съществуват записи за инциденти и дали вътрешният одит и прегледът от ръководството включват резултатността при инциденти.

Zenith Controls цитира одитната методология ISO/IEC 19011:2018 за 5.24, 5.25 и 6.8. За 5.24 одиторите проверяват плана за реагиране при инциденти за типове инциденти, класификации по сериозност, възложени роли, списъци с контакти, пътища за ескалация, инструкции за регулаторно докладване и комуникационни отговорности. За 5.25 те проверяват дали съществуват документирани критерии за класификация, например матрици за сериозност или дървета за решения, базирани на въздействието върху системи, чувствителността на данните и продължителността. За 6.8 те оценяват механизмите за докладване, показателите за време до докладване и доказателствата, че докладваните събития се журналират, триажират и разрешават.

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

Одитор по защита на личните данни ще се фокусира върху това дали е оценен рискът от нарушение на сигурността на личните данни и дали са задействани задълженията по член 33 и член 34 на GDPR. BS EN 17926:2023 е релевантен тук, защото добавя отговорности при инциденти, свързани със защитата на личните данни, критерии за уведомяване, срокове и съгласуване с очакванията за разкриване пред надзорния орган.

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

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

Преди следващото настолно упражнение, вътрешен одит или надзорен преглед тествайте организацията си спрямо този контролен списък:

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

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

Изградете модел за докладване на инциденти по DORA, готов за доказване

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

Clarysec може да ви помогне да изградите този оперативен модел.

Започнете, като съпоставите рисковете от инциденти и Декларацията за приложимост чрез Zenith Blueprint: 30-стъпкова пътна карта за одитори. След това съгласувайте контролите за инциденти с Zenith Controls: ръководство за междурегулаторно съответствие. Приведете процеса в действие с Политиката за реагиране при инциденти, Политиката за реагиране при инциденти — SME, Политиката за журналиране и мониторинг — SME, Политиката за събиране на доказателства и форензика и Политиката за събиране на доказателства и форензика — SME на Clarysec.

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