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

1. Проверявайте решенията, а не запаметяването на регламента

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

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

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

Упражнението по-долу е измислен учебен материал. То не заменя технически тестове за възстановяване, пълна програма за изпитване на устойчивостта или тестване за проникване, основано на заплахи. Продължителността от 90 минути е предложен формат, а не регулаторен минимум.

2. Разделете класификацията, спешността и ескалацията към органа

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

Подробните правила за класификация са в Делегиран регламент (ЕС) 2024/1772. Член 8 съчетава засягане на критични услуги с определени условия за същественост; не всеки технически срив автоматично е съществен инцидент. Правилата разглеждат и повтарящи се инциденти. Използвайте одобрен формуляр за оценка с действителните критерии и прагове, вместо импровизиран цветен индикатор по време на срещата.

За упражнението определете участник от „Съответствие“ или „Риск“, който да отговаря за предложената класификация и подкрепящите факти. Ръководителят на инцидента отговаря за оперативните приоритети. Оправомощено лице отговаря за подготовката и подаването на уведомлението. Реалното ви разпределение може да е различно; запишете го преди първата ситуационна актуализация.

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

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

3. Упражнете сроковете за докладване с конкретен пример

Следващото обобщение се отнася до докладване на съществени инциденти, свързани с ИКТ, по член 5 от Делегиран регламент (ЕС) 2025/301. При реален инцидент използвайте правния текст и процеса на вашия компетентен орган.

В измисления пример узнаването е във вторник в 09:00, а класифицирането като съществен — в 10:00. Обичайният краен срок за първоначално уведомяване е 14:00 във вторник, при задължение за подаване възможно най-рано. Ако уведомлението е подадено във вторник в 11:30, срокът от 72 часа за междинния доклад изтича в петък в 11:30. Следващ актуализиран междинен доклад променя отправната точка за едномесечния срок на окончателния доклад. Един месец не означава автоматично 30 дни.

Няма общо спиране на сроковете през почивните дни. Когато е приложим, член 5, параграф 4 допуска подаване до обяд на следващия работен ден, ако срокът изтича в почивен или официален празничен ден в държавата членка на докладващия субект. Параграф 5 изключва първоначалните и междинните подавания на кредитни институции, централни контрагенти, оператори на места за търговия и други финансови субекти, определени като съществени или важни по NIS2. По параграф 6 органите могат да изключат и други значими или системни субекти след уведомяването им; решението се прилага за инциденти, докладвани след уведомяването. Проверете приложимостта, преди да разчитате на облекчението.

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

4. Подгответе участниците и правилата

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

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

Разделяйте времето на упражнението от времето в сценария. Петминутна дискусия може да представлява час от измисления инцидент, но водещият трябва да обяви преместването напред. Обозначете всяко съобщение и проект с „УПРАЖНЕНИЕ“. Не изпращайте учебни уведомления до регулатор, клиент или доставчик без предварително уговорено участие. Използвайте безопасен симулиран канал.

Измисленият финансов субект предоставя платежна услуга чрез външна платформа за обработка. Във вторник в 09:00 оперативният екип узнава за неуспешно обработване на плащания. Причината е неясна. За упражнението организацията е оценила поддържаната функция като критична или важна. Участниците все пак трябва да приложат критериите за съществен инцидент; етикетът на функцията сам по себе си не решава класификацията.

5. Използвайте тази 90-минутна програма

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

Ако решение се отлага, протоколистът записва кой ще се върне с какво доказателство и до кога. „Ще включим правния екип“ не е завършено действие, ако няма конкретен контакт, въпрос и налично време. Същият стандарт важи за „обаждаме се на доставчика“ и „активираме плана за възстановяване“.

6. Използвайте три ситуации с реален управленски избор

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

В 09:15 по сценария неуспешните плащания се увеличават. Доставчикът признава проблем в платформата, но не дава прогноза за възстановяване. Някои клиенти опитват повторно, което създава възможен проблем при съгласуването на записите. Оперативният екип може временно да ограничи обработката, но това ще прекъсне и клиенти, които в момента може да не са засегнати.

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

Втора ситуация: класификацията е потвърдена, но обичайният подаващ отсъства

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

Поискайте участниците да посочат канала за докладване и да попълнят учебно първоначално уведомление с наличната информация. Запишете неизвестните честно и определете кой ще ги изясни. Кога изтича първоначалният срок? Кой подава? Кой потвърждава получаването? Може ли организацията да действа без следващо планово заседание? Използвайте Регламент за изпълнение (ЕС) 2025/302 за образците и процедурите; дневникът на упражнението не заменя регулаторния формуляр.

Трета ситуация: доставчикът обявява възстановяване, но увереността е непълна

В 11:15 по сценария доставчикът съобщава, че обработката е възстановена. Вътрешната проверка още не е потвърдила правилното обработване на дублираните опити. Важен клиент иска публично уверение, че няма засегнати записи. Отговорникът за услугата предлага незабавно отваряне, а ръководителят на инцидента иска допълнителна проверка.

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

7. Водете дневник, който показва обосновката

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

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

8. Превърнете наблюденията в проверими последващи действия

Започнете обсъждането с наблюдения: кое решение се забави, кой факт не можеше да бъде получен и кой процес не беше демонстриран? Избягвайте общи заключения като „комуникацията беше лоша“ без пример. Попитайте кои решения биха се променили, ако инцидентът беше започнал извън работно време или беше засегнал обичайните средства за съвместна работа.

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

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

9. Свържете обучението със следващия повторен тест

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

Използвайте ръководството за изискванията за обучение по DORA, за да свържете упражнението с продължаващото учене на управителния орган. DORA обучение за управителни органи и ръководители на BlueTeam Academy въвежда управленските понятия за ръководства на финансови субекти в обхвата на DORA. Въвеждащ курс или запис за присъствие не установява съответствие на организацията. Свържете основата с контекста на собствените услуги, наблюдаваните решения и проверените подобрения.