Научете
Режимът на DORA за докладване на инциденти по замисъл е задължението с най-голям времеви натиск в целия регламент. За голям инцидент, свързан с ИКТ, финансовият субект трябва да подаде първоначално уведомление до националния си компетентен орган (NCA) възможно най-рано и във всеки случай в рамките на 4 часа от класифицирането на инцидента като голям, и не по-късно от 24 часа от момента, в който е узнал за инцидента. Тези срокове са определени в Делегиран регламент (ЕС) 2025/301 на Комисията, който допълва член 19(4) от DORA.
Това създава жестоко тесен прозорец. Но преди часовникът изобщо да тръгне, стои по-труден въпрос: изобщо “голям” ли е този инцидент?
Член 18 от DORA, допълнен от съвместните регулаторни технически стандарти на ЕНО относно класификацията на инцидентите, свързани с ИКТ (Делегиран регламент (ЕС) 2024/1772 на Комисията), установява структуриран многокритериен праг. Класификацията е определена оценка спрямо седем критерия, всеки със прагове на същественост, които решават дали инцидентът пресича линията на “голям”, и с точно правило за комбиниране, което ги свързва.
Грешката тук има последици и в двете посоки. Ако докладвате по-малко от нужното, се сблъсквате с надзорна проверка, разпореждания за отстраняване и репутационни щети. Ако докладвате повече от нужното, заливате своя NCA с шум и изразходвате оскъдни ресурси по време на активен инцидент. Това ръководство ви дава точните критерии, прагове, срокове и логика на решението, директно от регламента, за да класифицирате правилно всеки път.
📈
RTS 2024/1772, членове 1 до 7
7-те критерия за класификация на големи инциденти
Член 18(1) от DORA определя критериите, които финансовите субекти използват, за да класифицират инцидентите, свързани с ИКТ, а членове 1 до 7 от RTS (Делегиран регламент (ЕС) 2024/1772) ги превръщат в седем именувани критерия, като член 9 фиксира праговете на същественост за всеки. Прочетете първо критериите, след това правилото за комбиниране, което решава кое е “голям”. Като прагови тестове, този е добре построен. Входната врата държи дреболиите отвън, правилото за два прага спира един шумен показател да ви завлече във формално подаване, и двете са достатъчно обективни, за да бъдат защитени в разговор с надзорен орган. Слабостта е, че почти всички входни данни зависят от информация, която трябва да съберете, докато инцидентът още тече.
DORA член 18(1)
“Финансовите субекти класифицират инцидентите, свързани с ИКТ, и определят тяхното въздействие въз основа на следните критерии: (a) броя и/или значимостта на засегнатите клиенти или финансови контрагенти и, когато е приложимо, размера или броя на засегнатите трансакции [...] и дали инцидентът, свързан с ИКТ, е причинил репутационно въздействие; (b) продължителността на инцидента, свързан с ИКТ, включително времето на прекъсване на услугата; (c) географския обхват [...]; (d) загубите на данни, които инцидентът, свързан с ИКТ, води до, по отношение на наличността, автентичността, целостта или поверителността на данните; (e) критичността на засегнатите услуги [...]; (f) икономическото въздействие, по-специално преките и непреките разходи и загуби [...].”
RTS ги разделя на седем критерия: отделя репутационното въздействие в собствен критерий и третира критичността на услугите като входна врата. По-долу е окончателната разбивка на всеки критерий с неговия праг на същественост от член 9 на RTS:
| # | Критерий | Праг на същественост (чл. 9 от RTS) | Какво да измервате |
|---|---|---|---|
| 1 | Засегнати клиенти, финансови контрагенти и трансакции | > 10% от клиентите, използващи засегнатата услуга, ИЛИ > 100 000 клиенти; ИЛИ > 30% от финансовите контрагенти; ИЛИ засегнати трансакции > 10% от средния дневен брой или стойност (чл. 9(1)) | Пребройте уникалните клиенти или контрагенти, които не могат да достъпят или използват засегнатата услуга, и оценете стойността на трансакциите, които са се провалили, забавили или обработили неправилно. Трансакциите се отчитат в рамките на този критерий. |
| 2 | Репутационно въздействие | Изпълнен е, когато инцидентът е бил отразен в медиите, е предизвикал повтарящи се оплаквания от клиенти или контрагенти, застрашава способността на субекта да изпълнява регулаторните изисквания или е вероятно да му струва клиенти или контрагенти със съществено бизнес въздействие (чл. 2, чл. 9(2)) | Качествен критерий. Оценете видимостта и последиците, обърнати към клиента. Медийното отразяване или вълна от оплаквания по услуги, обърнати към клиента, е най-ясният сигнал. |
| 3 | Продължителност и прекъсване на услугата | Продължителност на инцидента > 24 часа, ИЛИ прекъсване на услугата > 2 часа за ИКТ услуги, поддържащи критични или важни функции (чл. 9(3)) | Два отделни часовника: обща продължителност на инцидента (праг 24 часа) и прекъсване на услугите, поддържащи критични или важни функции (праг 2 часа). Включете влошената производителност. |
| 4 | Географски обхват | Инцидентът има въздействие в две или повече държави членки (чл. 9(4)) | Преценете дали са засегнати клиенти или операции в повече от една държава членка. Трансграничните платежни системи, клиринговите операции и кореспондентските банкови отношения усилват този критерий. |
| 5 | Загуби на данни | Всяка загуба, засягаща наличността, автентичността, целостта или поверителността на данни, която се отразява неблагоприятно на бизнес целите или на регулаторното съответствие; ИЛИ успешен злонамерен неоторизиран достъп до системи, който може да доведе до загуби на данни (чл. 9(5)(a) и (b)) | Вземете предвид и четирите измерения на данните. Забележете, че втората част, успешен злонамерен неоторизиран достъп, е най-силният единичен спусък в RTS (вижте правилото за комбиниране по-долу). Съпоставете с праговете за нарушение на сигурността на лични данни по GDPR. |
| 6 | Критичност на засегнатите услуги (ВХОДНА ВРАТА) | Изпълнен е, когато инцидентът засяга ИКТ услуги или системи, поддържащи критични или важни функции; ИЛИ засяга лицензирани, регистрирани или поднадзорни финансови услуги; ИЛИ представлява успешен, злонамерен и неоторизиран достъп до мрежови и информационни системи (чл. 6) | Това е основната входна врата. Ако нито една от трите ѝ части не е изпълнена, инцидентът не може да бъде голям, независимо от останалите прагове. Забележете третата част: успешно злонамерено проникване отваря входната врата дори за некритична система. |
| 7 | Икономическо въздействие | Преките и непреките разходи и загуби са надхвърлили или е вероятно да надхвърлят 100 000 EUR (чл. 9(6)) | Сумирайте преките разходи (отстраняване, възстановяване, криминалистика, санкции) и непреките разходи (пропуснати приходи, обезщетения на клиенти, алтернативни разходи). Прагът е плоски 100 000 EUR: няма алтернатива като процент от приходите. Оценете рано, уточнете по-късно. |
Правилото за комбиниране (член 8 от RTS)
Инцидентът е голям, когато е засегнал критични услуги (входната врата по член 6) И когато е налице едно от двете: (i) прагът по член 9(5)(b) е изпълнен, тоест успешен, злонамерен и неоторизиран достъп до мрежови и информационни системи, който може да доведе до загуби на данни; ИЛИ (ii) са изпълнени два или повече от шестте прага на същественост в член 9(1) до (6). С други думи, един обикновен праг сам по себе си не е достатъчен: нужно ви е квалифицирано злонамерено проникване или поне два прага. Икономическото въздействие е един от тези шест прага; то няма особена самостоятелна сила. Това е частта от правилото, която най-често се предава грешно, и обикновено грешката отива в скъпата посока. Фирма, която третира паричната стойност като спусък, ще докладва прекомерно, а прекомерното докладване учи собствените ѝ хора, че процесът е шум. Член 8 добавя и правило за агрегиране: повтарящи се инциденти, които поотделно не са големи, се броят като един голям инцидент, когато настъпват поне два пъти в рамките на 6 месеца, споделят една и съща видима първопричина и заедно изпълняват теста. Субектите оценяват това ежемесечно и то не се прилага за микропредприятия.
⏰
Член 19 и RTS 2025/301
Тристепенният график за докладване
Член 19 от DORA изисква първоначално уведомление и два последващи доклада за всеки голям инцидент, свързан с ИКТ, подадени до съответния NCA. Точните срокове са определени в Делегиран регламент (ЕС) 2025/301 на Комисията, член 5. Всяка фаза има строг часовник и определено съдържание.
Делегиран регламент (ЕС) 2025/301 на Комисията, член 5
Първоначално уведомление: възможно най-рано и във всеки случай в рамките на 4 часа от класифицирането на инцидента като голям, и не по-късно от 24 часа от момента, в който финансовият субект е узнал за инцидента. Междинен доклад: най-късно в рамките на 72 часа от подаването на първоначалното уведомление. Окончателен доклад: не по-късно от един месец след подаването на междинния доклад (или на последния актуализиран междинен доклад).
| Доклад | Краен срок | Изисквано съдържание |
|---|---|---|
| Първоначално уведомление | 4 часа след класификацията (макс. 24 ч. след узнаването) | Идентификация на субекта; дата и час на откриване и на класификация; естество и вид на инцидента; първоначална оценка на засегнатите услуги, клиенти и контрагенти; дали инцидентът е повтарящ се; предварителна оценка на въздействието; предприети незабавни действия; данни за контакт. |
| Междинен доклад | 72 часа след първоначалното уведомление | Актуализирана оценка спрямо критериите и праговете; състояние на ограничаването и възстановяването; предварителна първопричина; актуализирано въздействие върху клиенти и контрагенти; географски обхват; прогнозно икономическо въздействие; засегнати трансакции (обем и стойност); други задействани задължения за уведомяване; актуализиран график за отстраняване. Актуализиран междинен доклад се дължи, след като редовните дейности бъдат възстановени. |
| Окончателен доклад | 1 месец след междинния доклад | Потвърден анализ на първопричината; пълна количествено определена оценка на въздействието; общ икономически разход (пряк и непряк); извлечени поуки и коригиращи действия; промени в рамката за управление на риска в ИКТ; дали инцидентът е разкрил пропуски при доставчик от трета страна; потвърждение за комуникацията с клиентите; одитна следа на предприетите действия. |
Проблемът с “двойния часовник”
Първоначалното уведомление носи два припокриващи се срока: 4 часа от класификацията и 24 часа от узнаването за инцидента. Това ви дава твърд таван от около 20 часа да стигнете до решение за класификация, преди абсолютната граница да поеме контрола. Третирайте класификацията като собствена задача с фиксирано време. Този таван е по-щедър, отколкото звучи на пръв поглед, и въпреки това е грешното нещо, около което да планирате. Класифицирайте рано въз основа на частична информация и после ревизирайте, защото първият доклад е предвиден като предварителен, а изчакването с цел да се защити точността му е начинът, по който субектите подават закъснели и неточни доклади.
Доброволни уведомления
Член 19(2) позволява на финансовите субекти доброволно да уведомят своя NCA за значителни киберзаплахи, които не са довели до голям инцидент. Това е незадължително, но демонстрира зряло управление на риска и може да бъде полезно за ситуации на косъм, които изпълняват теста за значителна заплаха (вижте често задаваните въпроси по-долу).
Какво се случва, когато пропуснете срока
Съгласно член 50 от DORA компетентните органи могат да налагат административни санкции и корективни мерки за нарушения, пропорционални на тежестта и въздействието на несъответствието, а в сериозни случаи могат публично да оповестят пропуска. Освен самата санкция, отбелязването ви като закъснял или недокладващ субект привлича по-близко надзорно внимание, което често струва повече от глобата.
🌳
Рамка за решение
Дърво на решението за класификация
Когато настъпи инцидент, свързан с ИКТ, използвайте това структурирано преминаване, за да стигнете до решение за класификация. Редът има значение: входната врата за критичност се оценява първа, а праговете на същественост се оценяват паралелно, за да се минимизира времето за класификация.
Стъпка 1 - Входна врата: критичност на услугите (член 6)
Изпълнена ли е поне една от трите части на входната врата? (a) инцидентът засяга ИКТ услуги или системи, поддържащи критична или важна функция във вашия анализ на въздействието върху дейността и регистър на информацията; (b) засяга финансови услуги, изискващи лиценз, регистрация или надзор; (c) представлява успешен злонамерен неоторизиран достъп до вашите системи. Ако отговорът е НЕ и за трите → инцидентът не е голям. Регистрирайте го и го управлявайте, но няма задължение за докладване към NCA. Почти всички усилия при тази входна врата се полагат преди инцидента, при решаването кои услуги поддържат критични или важни функции. Свършете тази работа, докато нищо не гори, и входната врата се превръща в справка; оставете я несвършена и ще предоговаряте собствения си анализ на въздействието върху дейността с течащ часовник. Ако отговорът е ДА за която и да е част → преминете към Стъпка 2.
Стъпка 2 - Оценете шестте прага на същественост паралелно
За всеки от шестте прага в член 9(1) до (6) определете дали е изпълнен:
Клиенти / трансакции: >10% или >100 хил. клиенти, >30% контрагенти, или >10% от дневните трансакции?
Репутационен: медийно отразяване, повтарящи се оплаквания или загуба на клиенти?
Продължителност: >24 ч. продължителност, или >2 ч. прекъсване за критични/важни функции?
География: две или повече държави членки?
Загуби на данни: неблагоприятно въздействие върху данни, или злонамерен достъп, който може да причини загуба на данни (9(5)(b))?
Икономически: разходи и загуби > 100 000 EUR?
Стъпка 3 - Приложете правилото за комбиниране (член 8)
При изпълнена входна врата класифицирайте като ГОЛЯМ, ако е налице едно от двете: прагът по член 9(5)(b) е изпълнен (успешен злонамерен неоторизиран достъп, който може да доведе до загуби на данни), ИЛИ са изпълнени два или повече от шестте прага в Стъпка 2. Ако е изпълнен само един обикновен праг и няма квалифициран злонамерен достъп → не е голям (но продължавайте да наблюдавате). Когато класифицирате като голям, 4-часовият часовник за докладване към NCA тръгва сега.
Стъпка 4 - Текуща преоценка
Инцидентите се развиват. Малък инцидент на първия час може да премине втори праг на третия час, докато въздействието се разпространява. Преоценявайте класификацията през целия жизнен цикъл на инцидента. Ако инцидент бъде прекласифициран от неголям в голям, 4-часовият часовник тръгва от момента на прекласификацията, но 24-часовата абсолютна граница продължава да се измерва от момента, в който за първи път сте узнали за инцидента.
📑
Таксономия на инцидентите
Големи спрямо неголеми инциденти спрямо киберзаплахи
DORA разграничава големите инциденти, свързани с ИКТ (задължително докладване към NCA), от другите, неголеми инциденти (регистриране и вътрешно управление), и отделно позволява доброволно уведомяване за значителни киберзаплахи. Разбирането на границите предотвратява както прекомерното докладване, така и опасната недостатъчна класификация.
| Измерение | Голям инцидент | Неголям инцидент | Значителна киберзаплаха |
|---|---|---|---|
| Спусък | Изпълнена входна врата + [9(5)(b) ИЛИ два или повече прага] | Входната врата не е изпълнена или правилото за комбиниране не е удовлетворено | Заплаха, която би могла да се материализира в голям инцидент (чл. 10) - инцидент не е настъпил |
| Докладване към NCA | Да - задължително | Не (регистриране по чл. 17) | Доброволно (чл. 19(2)) |
| График за докладване | 4 ч. / 72 ч. / 1 месец | Само вътрешно SLA | Няма фиксиран регулаторен часовник |
| Ръководен орган | Ескалация по процеса за ИКТ инциденти (чл. 17) | Оперативен екип или екип по риска | Ескалация по управление на риска |
| Уведомяване на клиенти | Изисква се, когато засяга финансовите интереси на клиентите (чл. 19(3)) | По принцип не се изисква | Неприложимо |
| Анализ на първопричината | Задължителен, в окончателния доклад | Очаква се по процеса по чл. 17 | Анализ на заплахата |
| Документация | Пълна одитна следа за надзорен преглед | Вътрешни записи, надзорен достъп | Вътрешни записи |
Защо неголемите инциденти все пак имат значение
Макар неголемите инциденти да не задействат докладване към NCA, те трябва да бъдат записвани и управлявани по вашия процес за управление на инциденти, свързани с ИКТ (член 17). Надзорните органи преглеждат целия ви регистър на инцидентите по време на проверки, а модел от инциденти, записани като неголеми, които е трябвало да бъдат класифицирани като големи, веднага вдига червени флагове. Изградете защитима обосновка за класификацията с времеви печат за всеки инцидент, независимо от изхода.
🏛️
Регулаторна механика
Докладване към NCA: кой, къде и как
Адресатът на докладването е вашият национален NCA, тоест компетентният орган, който е лицензирал или регистрирал финансовия субект. За банките това обикновено е националният банков надзор (например BaFin в Германия, ACPR във Франция, DNB в Нидерландия, Централната банка на Ирландия). За платежните институции това е съответният надзор на платежните услуги. За трансграничните групи NCA по седалище на дружеството майка координира с приемащите надзорни органи.
Формат на докладване
Шаблоните за докладване са предписани от техническите стандарти за изпълнение (Регламент за изпълнение (ЕС) 2025/302 на Комисията). Всяка фаза, първоначална, междинна и окончателна, използва стандартизирана структурирана форма, със свободен текст, който допълва структурираните данни. Подаването става през определения канал за докладване на NCA.
Ясна отговорност
Определете човек, оправомощен да ескалира, класифицира и подава доклади без да чака одобрения от комитет, и предварително назначете заместници за покритие 24/7. При 4-часов часовник неясният отговорник е най-честата причина за пропуснат срок. Назоваването на този човек е кратък разговор и повечето фирми го отлагат с месеци, защото изглежда като въпрос на корпоративно управление. Запишете името и заместниците в наръчника, след което проверете дали заместниците знаят, че са заместници.
Трансгранична координация
За инциденти, относими към други държави членки, NCA по седалище споделя уведомлението със съответните приемащи NCA и с ЕНО (EBA, EIOPA, ESMA), както е посочено в членове 11 и 12 от RTS. Вие докладвате на един NCA; той координира останалото. Отбележете трансграничното измерение в доклада си.
Паралелни задължения за уведомяване
Голям ИКТ инцидент може да задейства и други режими: GDPR (член 33, уведомяване за нарушение в рамките на 72 часа), NIS2 (ако субектът е съществен или важен субект) и PSD2 (за доставчиците на платежни услуги). Всеки има свой график и орган. Картографирайте всички паралелни задължения във вашия процес за реакция при инциденти.
Практичен съвет: подгответе докладите предварително
Попълнете предварително шаблона за първоначално уведомление със статичните данни за субекта (идентификатори, референция към NCA, лицензни данни, имена на ключови контакти, стандартни описания на услуги), така че по време на активен инцидент екипът ви да попълва само специфичните за инцидента полета. Това държи тесния прозорец фокусиран върху ограничаването и оценката, вместо върху попълване на формуляри.
⚠️
Капани, които да избегнете
6 чести грешки при класификация
Това са грешките при класификация, които най-вероятно ще подведат екип по инциденти под времеви натиск, и защо всяка от тях има значение.
Грешка 1: Изчакване на пълни данни за въздействието преди класификация
Екипите отлагат класификацията, докато нямат окончателен брой клиенти, икономически стойности или потвърдена първопричина. Но първоначалното уведомление изрично допуска предварителни данни: то изисква разумна оценка въз основа на наличното. Изчакването на съвършени числа изгаря вашия 4-часов прозорец и рискува да наруши 24-часовата абсолютна граница. Класифицирайте въз основа на най-добрата налична информация, след което уточнете в междинния и окончателния доклад.
Грешка 2: Смесване на “ИКТ инцидент” с “инцидент в киберсигурността”
Обхватът на DORA е по-широк от кибер. Член 3(8) определя “инцидент, свързан с ИКТ” като единично събитие или поредица от свързани събития, непланирани от субекта, което компрометира сигурността на мрежовите и информационните системи и има неблагоприятно въздействие върху наличността, автентичността, целостта или поверителността на данните или върху предоставяните услуги. Това включва хардуерни повреди, софтуерни дефекти, конфигурационни грешки, прекъсвания при облачен доставчик и изчерпване на капацитет, не само рансъмуер и пробиви в данните. Много субекти изобщо не пропускат инфраструктурните инциденти през процеса на класификация. Това е погрешното тълкуване, за което да се тревожите, защото е беззвучно. Нищо не ви предупреждава за класификация, която никога не сте извършили, а отказ по капацитет, който е свалил платежна опашка за един следобед, се чете от надзорен орган точно като пробив, който сте избрали да не докладвате.
Грешка 3: Услугите не са съпоставени с критични или важни функции
Входната врата за критичност (член 6) зависи от това дали засегнатата услуга поддържа критична или важна функция, определена в член 3(22) като такава, чието нарушаване би засегнало съществено финансовите резултати на субекта, или стабилността или непрекъснатостта на неговите услуги, или спазването от него на условията по неговия лиценз. Без окончателно съпоставяне на ИКТ услугите с функциите, изведено от вашия анализ на въздействието върху дейността и регистъра на информацията, оценката на входната врата се превръща в гадаене.
Грешка 4: Третиране на прекъсванията при трети страни като “не наш инцидент”
Когато облачен доставчик, платежен процесор или SaaS доставчик има прекъсване, което засяга вашите услуги, това е вашият инцидент, свързан с ИКТ, за класифициране. Критериите оценяват въздействието върху вашите клиенти, вашите услуги и вашите трансакции. Външната първопричина не ви освобождава от докладване: задълженията за управление на риска от трети страни в DORA изрично предвиждат този сценарий.
Грешка 5: Липса на прекласификация, докато инцидентите се развиват
Инцидент, който започва като малък, може да стане голям, докато каскадните откази се разпространяват. Проблем с производителността на база данни в 09:00 ч. може да засегне само вътрешни системи; до 11:00 ч. обърнатите към клиента API може да изтичат по време в три държави и да прехвърлят втори праг. Екипите, които класифицират веднъж и никога не преоценяват, пропускат прекласификацията и изпускат прозореца за докладване. Вградете контролни точки за преоценка в наръчника си за всеки инцидент, засягащ ИКТ инфраструктура.
Грешка 6: Липса на координация между уведомленията по DORA, GDPR и NIS2
Един инцидент може да задейства докладване по DORA (4 ч. към NCA), GDPR (72 ч. към надзорния орган по защита на данните) и NIS2 (24 ч. ранно предупреждение към CSIRT). Всеки има различни прагове, органи и съдържание. Субектите, които водят тези процеси в отделни силози, неизбежно изпращат противоречива информация до различни регулатори, което е червен флаг, привличащ проверка. Управлявайте всички задължения за уведомяване от един запис за инцидента и една оценка за класификация.
🔍
Приложена класификация
Разработени сценарии: голям или не?
Теорията е чиста; реалността е разхвърляна. Тези четири илюстративни сценария прилагат входната врата и правилото за комбиниране. Всеки преминава през теста на входната врата и броенето на праговете.
| Сценарий | Ключови факти | Анализ по критериите | Класификация |
|---|---|---|---|
| Прекъсване при облачен доставчик засяга онлайн банкирането | Прекъсване в облачен регион, 3,5 часа престой на мобилното и уеб банкирането, засегнати са около 45 000 клиенти на дребно, една държава, разходите за възстановяване и отстраняване са оценени над 100 000 EUR | Входна врата: онлайн банкирането поддържа критична функция. Праг 1: престой 3,5 ч. > 2 ч. Праг 2: икономическо въздействие > 100 000 EUR. Изпълнени са два прага. | ГОЛЯМ |
| Рансъмуер във вътрешната HR система | Рансъмуер криптира системата за HR и заплати, данни на служители вероятно са изнесени, 48 часа за възстановяване, няма въздействие върху клиентите | Входна врата: успешен злонамерен неоторизиран достъп отваря входната врата по член 6(c), макар HR да не е критична функция. Единичен спусък: същият достъп удовлетворява член 9(5)(b). Входната врата плюс 9(5)(b) е достатъчно само по себе си. | ГОЛЯМ |
| Влошаване на обработката на плащания | Обработката на картови плащания работи на 60% капацитет в продължение на 90 минути, забавени са картови трансакции за 2,3 млн. EUR, което е над 10% от средната дневна стойност на трансакциите на процесора, засегнати са клиенти в DE и NL | Входна врата: обработката на плащания е критична. Продължителност: 90 мин. < 2 ч., не е изпълнен. Праг 1: география, 2 държави членки (чл. 9(4)). Праг 2: засегнатите трансакции надхвърлят 10% от средната дневна стойност на трансакциите (чл. 9(1)). Изпълнени са два прага. | ГОЛЯМ |
| DDoS атака срещу маркетинговия сайт | DDoS сваля корпоративния маркетингов сайт за 4 часа; няма въздействие върху търговските, банковите или платежните системи; няма неоторизиран достъп; само маркетинговият сайт | Входна врата: маркетинговият сайт не е критична или важна функция, не е засегната финансова услуга, а DDoS представлява нарушаване на достъпността, което е различно от успешен неоторизиран достъп. Нито една от трите части на входната врата не е изпълнена. | НЕ Е ГОЛЯМ |
Сивата зона
Повечето спорове живеят там, където входната врата е ясно изпълнена, но вторият праг е граничен. Няма регулаторно указание “докладвайте при съмнение”, но надзорните органи очакват документирана и защитима обосновка за всяко решение. Когато тестът за два прага е наистина пределен, много субекти клонят към докладване и понижават в междинния доклад: прекомерно докладване, което бива коригирано, е далеч по-малко вредно от недостатъчно докладване, което NCA открива впоследствие. Каквото и да решите, запишете защо.
⚡
Възможности на платформата
Как Venvera подпомага класификацията на инциденти
Когато разполагате само с 240 минути, не можете да отделите половината от тях, за да установите дали трябва да докладвате. Модулът за инциденти на Venvera, една част от по-широка многорамкова платформа за съответствие, кодира входната врата по член 6, праговете на същественост по член 9, правилото за комбиниране по член 8 и тристепенния график за докладване в структуриран работен процес, така че класификацията е насочвана оценка със записана обосновка.
Насочвана класификация
Въведете параметрите на инцидента (засегнати услуги, продължителност, брой клиенти, географски обхват) и модулът оценява входната врата и шестте прага спрямо правилото за комбиниране от RTS, връщайки препоръка за класификация с регулаторната обосновка зад нея.
Съпоставяне на критичните функции
Предварително конфигурирано съпоставяне между вашите ИКТ услуги, бизнес функции и оценки за критичност от регистъра на информацията означава, че входната врата по член 6 се оценява автоматично според това коя услуга е засегната.
Обратно броене и известия за срокове
От момента на регистриране на инцидента таймери за обратно броене следят 4-часовия прозорец за първоначално уведомление, 72-часовия срок за междинния доклад и едномесечния срок за окончателния доклад, с известия за ескалация при приближаване на всеки срок.
Изготвяне на доклади за NCA
Шаблони за доклади, съобразени с техническите стандарти за изпълнение (Регламент (ЕС) 2025/302). Идентификацията на субекта, статичните данни и съпоставянията на услугите са предварително попълнени; специфичните за инцидента полета са структурирани за бързо попълване и експорт.
Наблюдение за прекласификация
Докато актуализирате параметрите на инцидента по време на активно събитие, модулът преоценява правилото за комбиниране. Ако неголям инцидент премине втори праг, той сигнализира промяната, за да не пропуснете прозореца за докладване.
Многорамкова координация
Един запис за инцидент може да задвижи паралелна оценка по DORA, GDPR и NIS2, като съпоставя прага на всеки режим и следи всеки срок независимо, така че до всеки регулатор стига последователна информация.
Одитна следа на класификацията
Всяко решение за класификация, всяка промяна на параметър и всяка преоценка се логват с времеви печат и потребител, така че когато надзорен орган попита защо даден инцидент е класифициран като неголям, разполагате със защитим запис на разсъжденията.
Структурирана първопричина
Улавяне на първопричината, съобразено с таксономията на инцидентите, която надзорните органи очакват, захранващо вашия окончателен доклад и по-широката ви рамка за управление на ИКТ риска (член 6 от DORA).
Прекарайте прозореца в ограничаване, не във формуляри
Смисълът от кодирането на правилото е прост: да превърне класификацията в насочвана оценка, отнемаща минути, със защитима одитна следа, така че екипът ви да прекара 4-часовия прозорец в ограничаване на инцидента и защита на клиентите, вместо да спори за прагове на конферентен разговор.
Ключови изводи
- Входната врата плюс правилото за комбиниране: инцидентът е голям само когато засяга критични услуги (член 6) И е налице успешен злонамерен неоторизиран достъп (член 9(5)(b)) или са изпълнени два или повече от шестте прага.
- Един праг не е достатъчен: икономическо въздействие над 100 000 EUR само по себе си не прави инцидента голям; то е един от шест прага, а са ви нужни два (или квалифицирано злонамерено проникване).
- 4-часово първоначално уведомление: часовникът тръгва при класификацията, с 24-часова абсолютна граница от момента на узнаването, така че разполагате с най-много около 20 часа за класификация.
- Тристепенно докладване: първоначално (4 ч.), междинно (72 ч.), окончателно (1 месец), със срокове, определени от Делегиран регламент (ЕС) 2025/301.
- Прекъсванията при трети страни се броят: ако вашият доставчик падне и клиентите ви са засегнати, това е вашият инцидент за класифициране и докладване.
- Документирайте всяко решение: записвайте обосновката за класификацията на всеки инцидент, голям или не; вашият регистър на инцидентите се проверява от надзорните органи.
Често задавани въпроси
Какво прави един инцидент, свързан с ИКТ, “голям” по DORA?
Съгласно член 8 от RTS за класификацията (Делегиран регламент (ЕС) 2024/1772) инцидентът е голям, когато е засегнал критични услуги (входната врата за критичност в член 6) и когато е налице едно от двете: прагът по член 9(5)(b) е изпълнен, тоест успешен, злонамерен и неоторизиран достъп до мрежови и информационни системи, който може да доведе до загуби на данни, или са изпълнени два или повече от шестте прага на същественост в член 9(1) до (6). Входната врата сама по себе си не е достатъчна и нито един обикновен праг не е достатъчен самостоятелно.
Какъв е графикът за докладване на инциденти по DORA?
Три фази, със срокове, определени от Делегиран регламент (ЕС) 2025/301, член 5. Първоначалното уведомление се дължи възможно най-рано и в рамките на 4 часа от класифицирането на инцидента като голям, и не по-късно от 24 часа от узнаването за него. Междинният доклад се дължи в рамките на 72 часа от първоначалното уведомление. Окончателният доклад се дължи не по-късно от един месец след междинния доклад.
Самостоятелен спусък ли е стойността от 100 000 EUR за икономическо въздействие?
Не. Прагът за икономическо въздействие в член 9(6) е изпълнен, когато преките и непреките разходи и загуби надхвърлят или е вероятно да надхвърлят 100 000 EUR, но той е само един от шест прага на същественост. Сам по себе си, при изпълнена входна врата, той дава един праг, което не е достатъчно. Нужен ви е втори праг или квалифициран злонамерен неоторизиран достъп по член 9(5)(b). Няма алтернатива като процент от приходите на стойността от 100 000 EUR.
Броят ли се прекъсванията при доставчик от трета страна като наш инцидент?
Да. Ако облачен доставчик, платежен процесор или друга ИКТ трета страна има прекъсване, което засяга вашите услуги, клиенти или трансакции, това е вашият инцидент, свързан с ИКТ, за класифициране и, ако изпълнява теста, за докладване. Критериите за класификация измерват въздействието върху вашите операции; външната първопричина не премахва задължението.
Какво е “значителна киберзаплаха” и трябва ли да се докладва?
Съгласно член 10 от RTS киберзаплахата е значителна, когато взети заедно: тя би могла, ако се материализира, да засегне критични или важни функции на субекта (или на други субекти, доставчици, клиенти или контрагенти); има висока вероятност да се материализира, преценена въз основа на уязвимостите, способностите и намеренията на извършителя на заплахата и постоянството; и, ако се материализира, би могла да изпълни праговете за критичност и същественост за голям инцидент. Докладването на значителна киберзаплаха е доброволно по член 19(2) от DORA.
Първични източници
Това ръководство е изготвено въз основа на регламента и техническите му стандарти: Регламент (ЕС) 2022/2554 (DORA, включително членове 18, 19 и 50); Делегиран регламент (ЕС) 2024/1772 на Комисията (RTS относно класификацията на големите инциденти, свързани с ИКТ, и значителните киберзаплахи, включително членове 1 до 10); Делегиран регламент (ЕС) 2025/301 на Комисията (RTS относно съдържанието и сроковете на докладите за инциденти, член 5); и страниците за DORA на Европейския банков орган за стандартите на ЕНО за докладване на инциденти. Винаги потвърждавайте действащия текст, преди да разчитате на конкретна стойност или срок.
Тази статия е само с информационна цел и не представлява правен или регулаторен съвет. Финансовите субекти следва да се консултират със своите юридически съветници и компетентни органи за насоки, специфични за субекта, относно класификацията и докладването на инциденти по DORA. Последен преглед: юли 2026 г.
