Научете
КорекцияКоригирано на 14 юли 2026 г. По-ранна версия на тази статия носеше цитати, които не съответстваха на официалните текстове: съпоставяне между главите и RTS, чиито диапазони от членове не отговаряха на структурата на Делегиран регламент (ЕС) 2024/1774, срок за уведомяване за инциденти, посочен като един четиричасов прозорец, и няколко задължения на ръководния орган, приписани на грешни подточки на член 5(2). Всяко цитиране по-долу е повторно проверено спрямо текста в Официален вестник. Твърденията за поведението на надзорните органи, които не можаха да бъдат проследени до публикуван източник, са премахнати изцяло.
Глава II от DORA, членове 5 до 16, изисква всеки финансов субект в обхвата да има рамка за управление на ИКТ риска. Член 6(1) е основното изречение: тя трябва да бъде “надеждна, всеобхватна и добре документирана рамка за управление на ИКТ риска като част от цялостната им система за управление на риска”. Регламентът се прилага от 17 януари 2025 г.
Регламентът задава задълженията. Детайлът стои едно ниво под него, в Делегиран регламент (ЕС) 2024/1774 на Комисията, регулаторните технически стандарти, “определящи инструментите, методите, процесите и политиките за управление на ИКТ риска и опростената рамка за управление на ИКТ риска”, приети по член 15 и член 16(3) от DORA. Членове 2 до 27 от него се прилагат за пълната рамка. Членове 28 до 41 определят опростената рамка за субектите, изброени в член 16(1) от DORA.
Документ на рамка, който цитира само текста от ниво 1, пропуска нивото, на което изискванията всъщност са определени. Тази двустепенна структура е най-подценяваното нещо в DORA. Регламентът се чете така, сякаш добър набор от политики му отговаря. RTS е там, където е реалната работа, и е написан на ниво детайл, което налага промени в самото управление на ИКТ, отвъд начина, по който го описвате. Това ръководство минава през структурата глава по глава и дава за всяка от тях члена, на който тя трябва да отговаря. То не ви казва какво мислят надзорните органи, защото това не е нещо, чийто източник можем да посочим.
📜
Раздел 1
Какво трябва да покрива рамката
Глава II върви от член 5 до член 16. Членове 5 и 6 задават управлението и самата рамка. Членове 7 до 14 задават материалните задължения. Член 15 е мандатът за техническите стандарти, а член 16 отделя опростена рамка за по-малките субекти, които изброява. Документът се нуждае от място за всяко от следните.
Член 5 - Управление и организация
Ръководният орган трябва да “определя, одобрява, контролира и отговаря за прилагането на всички механизми, свързани с рамката за управление на ИКТ риска, посочена в член 6, параграф 1”. Член 5(2) след това изброява девет конкретни задължения, букви (a) до (i).
Член 6 - Рамка за управление на ИКТ риска
Надеждна, всеобхватна и добре документирана рамка. Субектите, различни от микропредприятия, трябва да възложат ИКТ риска на независима контролна функция (6(4)). Рамката се преразглежда най-малко веднъж годишно и след големи инциденти (6(5)), подлежи на вътрешен одит (6(6)) и трябва да съдържа стратегия за цифрова оперативна устойчивост (6(8)).
Член 7 - ИКТ системи, протоколи и инструменти
Системите трябва да бъдат подходящи спрямо мащаба на дейностите, надеждни, с достатъчен капацитет за пиковите обеми и технологично устойчиви при напрегнати пазарни условия.
Член 8 - Идентификация
Идентифицирайте, класифицирайте и документирайте всички поддържани от ИКТ бизнес функции, информационни активи и ИКТ активи, както и техните зависимости. Картографирайте критичните активи и взаимозависимостите (8(4)), идентифицирайте процесите, зависещи от ИКТ трети страни (8(5)), поддържайте инвентари (8(6)) и провеждайте годишна оценка на риска за наследените ИКТ системи (8(7)).
Член 9 - Защита и превенция
Член 9(4) задава шест задължения към рамката, букви (a) до (f): политика за информационна сигурност (a), управление на мрежите и инфраструктурата (b), политики за ограничаване на достъпа (c), силна автентикация и защита на криптографските ключове (d), документирано управление на ИКТ промените (e) и всеобхватни политики за корекции и актуализации (f).
Член 10 - Откриване
Механизми за бързо откриване на аномални дейности, проблеми с производителността на ИКТ мрежите и инциденти, както и за идентифициране на потенциални съществени единични точки на отказ. Механизмите за откриване трябва да позволяват няколко слоя контрол и да определят прагове за известяване (10(2)), и самите те трябва да бъдат редовно тествани.
Член 11 - Реакция и възстановяване
Политика за непрекъснатост на ИКТ дейността, планове за реакция и възстановяване, подлежащи на преглед от независим вътрешен одит (11(3)), анализ на въздействието върху дейността (11(5)) и тестване на плановете най-малко веднъж годишно и при съществени промени (11(6)(a)). Субектите, различни от микропредприятия, се нуждаят от функция за управление на кризи (11(7)).
Член 12 - Резервни копия, възстановяване и възобновяване
Документирани политики за резервни копия, определящи обхвата и минималната честота, системи за възстановяване, физически и логически отделени от източника (12(3)), резервен ИКТ капацитет за субектите, различни от микропредприятия (12(4)), и цели за време и точка на възстановяване, определени за всяка функция (12(6)).
Член 13 - Учене и развитие
Способности за събиране на информация за заплахи и уязвимости, прегледи след големи инциденти (13(2)), включване на поуките от тестването и инцидентите в процеса за оценка на ИКТ риска (13(3)), годишно докладване от висшия ИКТ персонал към ръководния орган (13(5)) и задължителни модули за обучение по осведоменост за ИКТ сигурност и устойчивост (13(6)).
Член 14 - Комуникация
Планове за кризисна комуникация за отговорно оповестяване на големи инциденти и уязвимости, отделни комуникационни политики за вътрешния персонал и за външните заинтересовани страни, и поне едно поименно определено лице, натоварено с публичната и медийната функция.
“Финансовите субекти въвеждат рамка за вътрешно управление и контрол, която осигурява ефективно и разумно управление на ИКТ риска, в съответствие с член 6, параграф 4, за да се постигне високо ниво на цифрова оперативна устойчивост.”
DORA член 5(1). Обърнете внимание на препратката към член 6(4), изискването за независима контролна функция за ИКТ риска. Тя редовно отпада, когато това изречение се цитира, и точно тя е частта с организационни последици.
Това не са независими глави. Идентификацията по член 8 движи защитите по член 9. Откриването по член 10 захранва реакцията по член 11. Член 13(3) затваря кръга, като изисква поуките от тестването и от реалните инциденти да бъдат включвани в процеса за оценка на риска на непрекъсната основа и да формират основата за прегледите на самата рамка. Документ, който не може да покаже тази верига, е купчина политики. Написването на документ, който покрива членове 5 до 16, отнема няколко седмици редакция. Способността да преведете някого през веригата с датирани артефакти на всяка стъпка е година оперативна дисциплина. Планирайте и двете и бъдете ясни пред борда кое от двете го молите да одобри.
⚖️
Раздел 2
Какво добавя RTS отвъд самата DORA
Делегиран регламент (ЕС) 2024/1774 има 42 члена. Член 1 е разпоредбата за пропорционалност. Членове 2 до 27 определят пълната рамка за управление на ИКТ риска. Членове 28 до 41 определят опростената рамка. Таблицата по-долу съпоставя материалния блок, членове 2 до 27, с това, което той изисква, и с члена от DORA, който допълва.
| RTS 2024/1774 | Област | Какво трябва да урежда рамката | Основание в DORA |
|---|---|---|---|
| Чл. 2 | Общи елементи на политиките, процедурите, протоколите и инструментите за ИКТ сигурност | Политиката за ИКТ сигурност трябва да бъде вградена в рамката, съгласувана с целите за информационна сигурност в стратегията за устойчивост, и трябва да посочва датата на официалното си одобрение от ръководния орган. | DORA чл. 9(2) |
| Чл. 3 | Управление на ИКТ риска | Самата процедура за управление на риска: толерантност към риск, критерии за оценка на въздействието, методологията и приемането на остатъчния ИКТ риск от отговорна роля. | DORA чл. 6(1) |
| Чл. 4-5 | Политика и процедура за управление на ИКТ активите | Политиката (чл. 4) и оперативната процедура (чл. 5): класификация на критичността на активите, връзки и взаимозависимости, и третиране на активите, наближаващи края на поддръжката. | DORA чл. 8(1), 8(4), 8(6) |
| Чл. 6-7 | Криптиране и криптографски контроли; управление на криптографските ключове | Криптографска политика, обхващаща данните в покой, при пренос и при използване, и жизнен цикъл на управление на ключовете, обхващащ генериране, подновяване, съхранение, отмяна и унищожаване. | DORA чл. 9(4)(d) |
| Чл. 8-12 | ИКТ операции: политики и процедури, капацитет и производителност, управление на уязвимостите и корекциите, сигурност на данните и системите, логване | Тук живее оперативният детайл: срокове за корекции по критичност, сканиране за уязвимости, планиране на капацитета, както и съхранение на логове и защита от подправяне. | DORA чл. 9(1), 9(4)(f) |
| Чл. 13-14 | Управление на мрежовата сигурност; защита на информацията при пренос | Мрежова сегментация, преглед на мрежовите връзки и правилата на защитната стена, сигурен отдалечен достъп и защита на информацията при пренос. | DORA чл. 9(4)(b) |
| Чл. 15-17 | Управление на ИКТ проекти; придобиване, разработване и поддръжка на системи; управление на ИКТ промените | Управление на проектите и изисквания за сигурност, разделяне на средите за разработка, тестване и продукция, и документирана процедура за промени с одобрение, тестване, връщане назад и обработка на аварийни промени. | DORA чл. 9(4)(e) |
| Чл. 18 | Физическа сигурност и сигурност на средата | Контроли за физически достъп до помещенията, центровете за данни и определените чувствителни зони, защита на средата и сигурно унищожаване на носители. | DORA чл. 9(4)(c) |
| Чл. 19-21 | Политика за човешките ресурси; управление на идентичността; контрол на достъпа | Отговорности за сигурността в трудовите правоотношения, уникални идентичности и политика за контрол на достъпа, обхващаща най-малки привилегии, необходимост да се знае, привилегирован достъп, отдалечен достъп и периодичен преглед на правата за достъп. | DORA чл. 9(4)(c) |
| Чл. 22-23 | Политика за управление на инцидентите, свързани с ИКТ; откриване на аномални дейности | Критерии и спусъци за откриване, ескалация и процесът за управление на инциденти, който свързва откриването със задълженията за докладване в Глава III от DORA. | DORA чл. 10, чл. 17 |
| Чл. 24-26 | Политика за непрекъснатост на ИКТ дейността; тестване на плановете за непрекъснатост; планове за реакция и възстановяване | Компонентите на политиката за непрекъснатост, режимът за тестване на плановете и съдържанието на плановете за реакция и възстановяване, включително целите за възстановяване. | DORA чл. 11, чл. 12 |
| Чл. 27 | Формат и съдържание на доклада за прегледа на рамката за управление на ИКТ риска | Докладът, изискван от член 6(5) от DORA, трябва да бъде подаден в електронен формат с възможност за търсене и трябва да съдържа разделите, изброени в член 27(2). | DORA чл. 6(5) |
Защо номерацията на RTS има значение
Таблицата с препратки обикновено е най-евтиното нещо за проверка в един документ на рамка и разкрива дали текстът е бил изготвен от самия текст или от резюме на текста. Съпоставяне, което праща Глава 4 към “членове 8 до 17 от RTS”, когато защитните контроли всъщност вървят през членове 6 до 21, е самопричинена констатация. Изградете таблицата от текста в Официален вестник и я поддържайте актуална, защото тези стандарти се изменят.
📋
Раздел 3
Структура на документа на рамката
Тази десетглавна структура дава на всяко изискване в Глава II от DORA и на всеки член от RTS място, където да живее. Това е структурен план. Адаптирайте подразделите към вашия размер, сложност и рисков профил и запишете тази адаптация като своя оценка за пропорционалност.
Глава 1
Управление и отговорности
Съответства на: DORA чл. 5, чл. 6(1)-(7) | RTS (ЕС) 2024/1774 чл. 2, чл. 3
- Задължения на ръководния орган, съпоставени едно по едно с член 5(2), букви (a) до (i)
- Контролната функция за ИКТ риска и нейната независимост (чл. 6(4))
- Нивото на толерантност към ИКТ риск, определено като част от стратегията за устойчивост (чл. 6(8)(b))
- Разпределяне на бюджета (чл. 5(2)(g)) и цикълът за преглед на рамката (чл. 6(5))
- Датата на официалното одобрение от ръководния орган, която чл. 2(2)(b) от RTS изисква политиката за сигурност да посочва
Глава 2
Управление и класификация на ИКТ активите
Съответства на: DORA чл. 8(1), 8(4), 8(6) | RTS (ЕС) 2024/1774 чл. 4-5
- Инвентарът на ИКТ активите и информационните активи
- Схемата за класификация и съпоставянето на критичността
- Връзки и взаимозависимости между активите, които чл. 8(4) изисква да картографирате
- Спусъци за актуализиране на инвентара, включително при всяка съществена промяна (чл. 8(3), 8(6))
Глава 3
Методология за идентификация и оценка на риска
Съответства на: DORA чл. 8(2), 8(3), 8(7) | RTS (ЕС) 2024/1774 чл. 3
- Непрекъснато идентифициране на източниците на ИКТ риск, с рискови сценарии, преразглеждани най-малко веднъж годишно (чл. 8(2))
- Оценка на риска при всяка съществена промяна в инфраструктурата, процесите или процедурите (чл. 8(3))
- Годишна специфична оценка на ИКТ риска за всички наследени ИКТ системи (чл. 8(7))
- Приемане на остатъчния риск, записано срещу поименно определена отговорна роля
Глава 4
Контроли за защита и превенция
Съответства на: DORA чл. 9 | RTS (ЕС) 2024/1774 чл. 6-21
- Политика за информационна сигурност (чл. 9(4)(a))
- Управление на мрежите и инфраструктурата, включително възможността мигновено да прекъснете или сегментирате връзките (чл. 9(4)(b); RTS чл. 13-14)
- Ограничаване на физическия и логическия достъп (чл. 9(4)(c); RTS чл. 18-21)
- Силна автентикация и защита на криптографските ключове (чл. 9(4)(d); RTS чл. 6-7)
- Управление на ИКТ промените, одобрено от подходящите управленски нива (чл. 9(4)(e); RTS чл. 15-17)
- Политики за корекции и актуализации (чл. 9(4)(f); RTS чл. 10)
Глава 5
Откриване и наблюдение
Съответства на: DORA чл. 10 | RTS (ЕС) 2024/1774 чл. 12, чл. 23
- Откриване на аномалии с няколко слоя контрол и определени прагове за известяване (чл. 10(2))
- Логване: какво се логва, колко дълго се пази и как се защитава от подправяне (RTS чл. 12)
- Идентифициране на потенциални съществени единични точки на отказ (чл. 10(1))
- Редовно тестване на самите механизми за откриване (чл. 10(1), втора алинея)
Глава 6
Реакция и възстановяване
Съответства на: DORA чл. 11, чл. 12 | RTS (ЕС) 2024/1774 чл. 22, чл. 24-26
- Политиката за непрекъснатост на ИКТ дейността и плановете за реакция и възстановяване (чл. 11(1), 11(3))
- Анализ на въздействието върху дейността с количествени и качествени критерии (чл. 11(5))
- Цели за време и точка на възстановяване, определени за всяка функция (чл. 12(6))
- Функция за управление на кризи (чл. 11(7)) и записи за дейността по време на нарушаване (чл. 11(8))
- Годишно тестване, включително сценарии за кибератаки и превключване към резервен капацитет (чл. 11(6))
Глава 7
Програма за тестване
Съответства на: DORA чл. 24-27 | RTS за TLPT (ЕС) 2025/1190
- Програмата за тестване на устойчивостта като неразделна част от рамката (чл. 24(1))
- Годишно тестване на всички ИКТ системи и приложения, поддържащи критични или важни функции (чл. 24(6))
- Видовете тестове, изброени в чл. 25(1), от сканиране за уязвимости до тестване от край до край и тестване за проникване
- Тестване за проникване, водено от заплахи, за субектите, определени по чл. 26, уредено от Делегиран регламент (ЕС) 2025/1190
- Процедури за приоритизиране, класифициране и отстраняване на всеки проблем, разкрит от тестовете, плюс вътрешна валидация, че са напълно отстранени (чл. 24(5))
Глава 8
Интегриране на риска от трети страни
Съответства на: DORA чл. 28-30 | RTS (ЕС) 2024/1773, RTS (ЕС) 2025/532, ITS (ЕС) 2024/2956
- Стратегията за ИКТ риска от трети страни, включително политиката за ИКТ услугите, поддържащи критични или важни функции (чл. 28(2); RTS (ЕС) 2024/1773)
- Преддоговорната оценка и надлежната проверка в чл. 28(4)
- Предварителната оценка на ИКТ концентрационния риск (чл. 29)
- Подизпълнение на услуги, поддържащи критични или важни функции (чл. 30(2)(a); RTS (ЕС) 2025/532)
- Стратегии за изход и преходни планове (чл. 28(8))
- Регистърът на информацията (чл. 28(3); ITS (ЕС) 2024/2956)
Глава 9
Докладване и комуникация
Съответства на: DORA чл. 14, чл. 17-19 | RTS (ЕС) 2024/1772, RTS (ЕС) 2025/301
- Планове за кризисна комуникация и поименно определеното лице за публичната и медийната функция (чл. 14(1), 14(3))
- Класификация на инцидентите спрямо критериите и праговете на същественост в Делегиран регламент (ЕС) 2024/1772 (чл. 18)
- Сроковете за уведомяване в Делегиран регламент (ЕС) 2025/301, член 5, изложени в Раздел 4 по-долу
- Докладване към ръководния орган: като минимум годишният доклад от висшия ИКТ персонал (чл. 13(5)) и каналите за докладване, изисквани от чл. 5(2)(i)
Глава 10
Преглед и непрекъснато подобрение
Съответства на: DORA чл. 6(5), чл. 13 | RTS (ЕС) 2024/1774 чл. 27
- Четирите спусъка за преглед в чл. 6(5): най-малко веднъж годишно, при големи инциденти, свързани с ИКТ, след надзорни указания и при заключения от тестването на устойчивостта или от одит
- Прегледи след инциденти и четирите въпроса за ефективност в чл. 13(2), букви (a) до (d)
- Връщане на поуките от тестването и инцидентите в процеса за оценка на риска (чл. 13(3))
- Ключови показатели за изпълнение и ключови рискови метрики, които чл. 6(8)(c) изисква стратегията за устойчивост да определя
- Форматът и съдържанието на доклада за прегледа на рамката (RTS чл. 27)
Принципът на пропорционалност, с думите на регламента
“Финансовите субекти прилагат правилата, установени в Глава II, в съответствие с принципа на пропорционалност, като вземат предвид своя размер и цялостен рисков профил, както и естеството, мащаба и сложността на своите услуги, дейности и операции.”
DORA член 4(1). Пропорционалността калибрира дълбочината. Тя не изтрива глави. Член 4(3) добавя, че компетентните органи “вземат предвид прилагането на принципа на пропорционалност от финансовите субекти при преглеждането на съгласуваността на рамката за управление на ИКТ риска” въз основа на докладите, подадени по член 6(5). Самата обосновка подлежи на преглед, затова я запишете. Пропорционалността е най-злоупотребяваната дума в разговорите за DORA. Облекчението е реално и действа върху дълбочината на всеки контрол, докато всяка глава все пак се нуждае от отговор. Написването на обосновката отнема един следобед и премахва една лесна констатация.
🔍
Раздел 4
Шест връзки, които текстът изисква да докажете
Няма да ви казваме кой въпрос задава надзорният орган първо, защото нямаме източник за такова твърдение. Това, което можем да направим, е да посочим местата, където текстът изисква доказуема връзка между две неща, отвъд декларация в политика. Това са частите от една рамка, които най-трудно се дописват впоследствие.
1. Веригата на отчетност пред борда
Член 5(2) не казва “бордът одобрява рамката” и толкова. Той изброява девет задължения, букви (a) до (i), и всяко от тях е въпрос за доказателства. Буква (f) е планът за вътрешен ИКТ одит. Буква (g) е бюджетът. Буква (i) е набор от канали за докладване на корпоративно ниво, обхващащи споразуменията с трети страни, планираните съществени промени по тях и най-малкото големите инциденти, свързани с ИКТ. Ако ръководният орган се появява във вашата рамка само веднъж, в блока за одобрение, документът не покрива член 5(2).
2. Пълнота на инвентара
Член 8(4) изисква да идентифицирате всички информационни и ИКТ активи “включително тези на отдалечени обекти, мрежовите ресурси и хардуерното оборудване”, да картографирате считаните за критични и да картографирате “връзките и взаимозависимостите между различните информационни активи и ИКТ активи”. Списък с активи без картата на зависимостите не удовлетворява члена, а картата на зависимостите е частта, чието изграждане отнема време.
3. Кръгът риск, контрол, тест, риск
Член 13(3) изисква поуките от тестването на устойчивостта, от реалните инциденти и от активирането на плановете за непрекъснатост “да бъдат надлежно включвани на непрекъсната основа в процеса за оценка на ИКТ риска” и тези констатации “да формират основата за подходящи прегледи на съответните компоненти на рамката за управление на ИКТ риска”. Рамка, която описва рисковете в една глава и контролите в друга, без документиран път между тях, не може да докаже това.
4. Тестване на непрекъснатостта, което наистина се е случило
Член 11(6)(a) изисква плановете за непрекъснатост и плановете за реакция и възстановяване да бъдат тествани “най-малко веднъж годишно, както и при всякакви съществени промени в ИКТ системите, поддържащи критични или важни функции”. За субектите, различни от микропредприятия, плановете за тестване трябва да включват сценарии на кибератаки и превключване между основната инфраструктура и резервния капацитет.
5. Часовникът за уведомяване
Сроковете за докладване не са в член 19 от DORA, който ги препраща към техническите стандарти. Те са в член 5 от Делегиран регламент (ЕС) 2025/301, а първоначалният срок има две части. Ако рамката отпечата грешния часовник, наръчникът за реакция при инциденти под нея ще наследи грешката.
6. Концентрационен риск, преди да подпишете
Член 29(1) изисква, когато извършвате идентификацията на риска по член 28(4)(c), да вземете предвид и дали предвижданият договор би довел до ситуациите, изброени в член 29. Това го прави преддоговорна контролна точка в процеса по доставки и рамката трябва да го постави точно там.
Часовникът за уведомяване, изложен правилно
Член 19(4) от DORA изисква първоначално уведомление, междинен доклад и окончателен доклад, но не определя сроковете. Той ги препраща към техническите стандарти. Те са в член 5(1) от Делегиран регламент (ЕС) 2025/301:
- Първоначално уведомление: “възможно най-рано, но във всеки случай в рамките на четири часа от класифицирането на инцидента, свързан с ИКТ, като голям инцидент, свързан с ИКТ, и не по-късно от 24 часа от момента, в който финансовият субект е узнал за инцидента, свързан с ИКТ”. Две части. Четиричасовият часовник тръгва при класификацията. 24-часовият часовник тръгва при узнаването.
- Междинен доклад: “най-късно в рамките на 72 часа от подаването на първоначалното уведомление”, и той се дължи дори когато състоянието или обработката на инцидента не са се променили.
- Окончателен доклад: “не по-късно от един месец след подаването на междинния доклад или, когато е приложимо, след последния актуализиран междинен доклад”. Месецът тече от междинния доклад.
Член 5(4) позволява срок, който изтича през уикенд или официален празник, да се измести до обяд на следващия работен ден, а член 5(5) отнема това облекчение за първоначалното уведомление и междинния доклад от кредитните институции, централните контрагенти, операторите на места за търговия и субектите, определени като съществени или важни по Директива (ЕС) 2022/2555. Рамка, която отпечатва “4 ч. / 72 ч. / 1 месец” и спира дотам, греши на три отделни места. Двучастният първоначален срок е добре замислен. Той спира часовникът да бъде разтяган от бавна класификация, като същевременно оставя място да разберете с какво си имате работа. Това, което иска от вас, е решение за класификация, което може да бъде взето бързо и доказано, а това е процесен проблем.
⚠️
Раздел 5
Списък за проверка на качеството преди одобрение от борда
Всеки ред по-долу е свързан с конкретно изискване в текста. Използвайте го като проверка преди одобрение на собствения си документ. Ако поправите само два реда, поправете цитатите и обосновката за пропорционалност. И двете са евтини, и двете могат да бъдат проверени от някой, който никога не е чувал за вашата фирма, и двете определят как ще бъде прочетен останалият документ. Не твърдим колко чести са тези пропуски, защото нямаме публикувани данни за това.
| Пропуск | Как изглежда | Какво изисква текстът вместо това |
|---|---|---|
| Преповтаряне на регламента | Рамката преразказва члена и спира дотам. Чете се като резюме на DORA. | За всяко изискване посочете кой е отговорен, какъв е процесът, колко често се изпълнява и какъв артефакт произвежда. |
| Липсващ детайл от RTS | Рамката урежда членовете от DORA, но не и членовете на Делегиран регламент (ЕС) 2024/1774, където инструментите, методите, процесите и политиките всъщност са определени. | Съпоставете рамката с членове 2 до 27 от RTS. Всеки от тези членове следва да попадне в поименно определена глава. |
| Цитати, сочещи към грешна разпоредба | Препратки към членове, които изглеждат точни и са грешни. Криптиране, цитирано към чл. 9(4)(b) вместо към 9(4)(d). Задължението за бюджет, цитирано към чл. 5(2)(b) вместо към 5(2)(g). Таблица за съпоставяне с RTS с спретнати диапазони, които не съответстват на RTS. | Проверете всяко цитиране спрямо текста в Официален вестник. Погрешно цитирана рамка кани читателя да допусне, че анализът под нея е направен със същото качество. |
| Няма обосновка за пропорционалност | Субектът разчита на пропорционалността, за да намали контролите, но не записва разсъждения. | Член 4(1) допуска пропорционалност “като се вземат предвид техният размер и цялостен рисков профил, както и естеството, мащабът и сложността на техните услуги, дейности и операции”. Документирайте оценката спрямо тези фактори. Член 4(3) казва, че компетентните органи ще вземат предвид как сте я приложили. |
| Вакуум в управлението | Отговорности, възложени на “организацията” или на “ИТ”, вместо на поименно определени роли, комитети и пътища за ескалация. | Член 5(2)(c) изисква ръководният орган да “определя ясни роли и отговорности за всички функции, свързани с ИКТ”. Използвайте RACI и назовавайте ръководния орган навсякъде, където DORA го прави. |
| Рискът от трети страни е закачен отстрани | ИКТ рискът от трети страни стои в собствена политика без път обратно към рамката. | Член 28(1) изисква субектите да управляват ИКТ риска от трети страни “като неразделна част от ИКТ риска в рамките на своята рамка за управление на ИКТ риска”. Направете препратки към регистъра на рисковете, защитните контроли и плановете за непрекъснатост. |
| Статичен документ | Няма история на версиите, няма доказателства за преглед, няма механизъм за актуализиране по спусъци. | Член 6(5) задава четири спусъка за преглед: най-малко веднъж годишно, при големи инциденти, свързани с ИКТ, след надзорни указания и при заключения, произтичащи от тестването на устойчивостта или от одит. Включете и четирите в таблицата за контрол на версиите. |
| Няма обратна връзка от тестването | Описана е програма за тестване, но нищо не свързва констатациите ѝ обратно с оценката на риска. | Член 24(5) изисква процедури за приоритизиране, класифициране и отстраняване на всички проблеми, разкрити от тестовете, и вътрешни методологии за валидиране, че са напълно отстранени. Член 13(3) изисква поуките да влязат в процеса за оценка на риска. |
| Недефинирани рискови метрики | Рамката споменава наблюдение, но не дефинира индикатори, прагове или спусъци за ескалация. | Член 6(8)(c) изисква стратегията за устойчивост да определя “ясни цели за информационна сигурност, включително ключови показатели за изпълнение и ключови рискови метрики”. Дефинирайте метриките, праговете и кой бива уведомен при преминаване на праг. |
Тестът, който да приложите към всяко изречение
За всяко твърдение в рамката попитайте какъв артефакт доказва, че то се случва. Ако отговорът е никакъв, има два честни варианта: променете твърдението така, че да описва това, което реално правите, или изградете процеса, преди документът да отиде в борда. Рамка, описваща организация, каквато нямате, е по-лоша от по-тънка рамка, описваща организацията, която имате, защото член 6(3) ви задължава да предоставите пълна и актуализирана информация за рамката на компетентния орган при поискване.
🏛️
Раздел 6
Одобрение от борда и управление
Член 5(2) започва с това, че прави ръководния орган отговорен за определянето, одобряването, контрола и прилагането на всички механизми, свързани с рамката. След това изброява девет конкретни задължения. Повечето документи на рамки цитират началното изречение и пропускат списъка. Ето пълния набор, с правилната подточка срещу всяко.
| Задължение на ръководния орган | Източник |
|---|---|
| Да носи крайната отговорност за управлението на ИКТ риска на финансовия субект | Чл. 5(2)(a) |
| Да въведе политики за поддържане на високи стандарти за наличност, автентичност, цялост и поверителност на данните | Чл. 5(2)(b) |
| Да определи ясни роли и отговорности за всички функции, свързани с ИКТ | Чл. 5(2)(c) |
| Да определи и одобри стратегията за цифрова оперативна устойчивост, включително нивото на толерантност към ИКТ риск | Чл. 5(2)(d), с препратка към чл. 6(8) и 6(8)(b) |
| Да одобрява, контролира и периодично преразглежда политиката за непрекъснатост на ИКТ дейността и плановете за реакция и възстановяване в ИКТ | Чл. 5(2)(e), с препратка към чл. 11(1) и 11(3) |
| Да одобрява и периодично преразглежда плановете за вътрешен ИКТ одит, ИКТ одитите и съществените изменения по тях | Чл. 5(2)(f) |
| Да разпределя и периодично преразглежда бюджета за нуждите от цифрова оперативна устойчивост, включително програмите за осведоменост и обучението | Чл. 5(2)(g), с препратка към чл. 13(6) |
| Да одобрява и периодично преразглежда политиката относно договореностите за използване на ИКТ услуги, предоставяни от доставчици на ИКТ услуги от трети страни | Чл. 5(2)(h) |
| Да въведе канали за докладване на корпоративно ниво относно споразуменията с трети страни, планираните съществени промени по тях и най-малкото големите инциденти, свързани с ИКТ | Чл. 5(2)(i), подточки (i) до (iii) |
| Да установи роля или да определи член на висшето ръководство, който да наблюдава договореностите с доставчици на ИКТ услуги от трети страни (субекти, различни от микропредприятия) | Чл. 5(3) |
| Активно да поддържа актуални достатъчни знания и умения, за да разбира и оценява ИКТ риска, включително чрез редовно преминаване на специфично обучение | Чл. 5(4) |
| Да гарантира, че рамката се преразглежда най-малко веднъж годишно, както и при големи инциденти, надзорни указания или заключения от тестване или одит | Чл. 6(5) |
| Да получава докладване от висшия ИКТ персонал, най-малко веднъж годишно, относно констатациите по чл. 13(3), с препоръки | Чл. 13(5) |
Член 5(4) заслужава собствен ред в рамката. Членовете на ръководния орган “активно поддържат актуални достатъчни знания и умения, за да разбират и оценяват ИКТ риска и въздействието му върху дейността на финансовия субект, включително чрез редовно преминаване на специфично обучение, съизмеримо с управлявания ИКТ риск”. Това е задължение на отделни лица и произвежда артефакт: запис за обучение. То е и задължението, което най-често се пропуска тихо, и едно от най-евтините за изпълнение. Кратка годишна сесия за борда, отразена в протокол, с запазени материали, струва на някого една сутрин. Пропускането ѝ оставя пропуск, който проверяващият може да намери без да става от бюрото си.
Календарът за управление на борда си заслужава мястото
Тези задължения са периодични и регламентът го казва. Изразът “одобрява и периодично преразглежда” се повтаря през целия член 5(2). Прегледът на рамката носи четирите спусъка в член 6(5). Висшият ИКТ персонал докладва най-малко веднъж годишно по член 13(5). Приложение, което превръща всяко от тези неща в датирана резултатна точка за борда с поименно определен отговорник, превръща абстрактното задължение в нещо, което корпоративният секретар може да следи, и в протокол, който доказва, че се е случило.
Поставете официален блок за одобрение на първата страница: версия, дата на одобрение, одобряващ орган, дата на следващия преглед. Член 2(2)(b) от RTS изисква политиките за ИКТ сигурност да посочват датата на официалното си одобрение от ръководния орган, така че същата дисциплина се очаква и в слоя точно под рамката.
🔗
Раздел 7
Свързване на рамката с оперативната реалност
Рамката е върховният документ. Тя задава какво и защо. Всичко под нея задава как. Член 6(2) описва рамката като включваща “стратегии, политики, процедури, ИКТ протоколи и инструменти”, което е йерархия от документи, свита в едно изречение.
Препоръчителна йерархия на документите
Ниво 1, рамката за управление на ИКТ риска. Одобрена от борда, стратегическа, преразглеждана по спусъците в член 6(5).
Ниво 2, политики. Информационна сигурност, непрекъснатост на ИКТ дейността, контрол на достъпа, ИКТ риск от трети страни.
Ниво 3, стандарти. Криптография, корекции, логване, мрежова сегментация.
Ниво 4, процедури. Наръчник за реакция при инциденти, процедура за превключване при възстановяване, сертифициране на достъпа, сканиране за уязвимости.
Добавете матрица за съпоставяне на рамката като приложение: всяка глава, подчинените документи, които я прилагат, отговорникът и цикълът за преглед. Тя демонстрира пълнота на една страница и е артефактът, към който посягате, когато член 6(3) бъде задействан и компетентният орган поиска пълна и актуализирана информация за рамката.
⚡
Раздел 8
Къде се вписва Venvera
Venvera е платформа за съответствие, покриваща редица европейски и международни рамки. DORA е една от тях и се обработва по същия начин като останалите: задълженията се моделират, доказателствата живеят срещу тях, а контрол, който отговаря на повече от една рамка, се използва повторно вместо да се изгражда наново. Изброените по-долу възможности са тези, които имат отношение към рамка за управление на ИКТ риска, и всяка съществува в продукта днес.
Шаблон за рамка за управление на ИКТ риска
Шаблон за политика на рамката, съпоставен с членове 5 до 16 от DORA, заедно с още десет шаблона за политики по DORA, покриващи управление на инциденти, тестване на устойчивостта, риск от трети страни, непрекъснатост на дейността, управление на активите, контрол на достъпа, управление на промените, криптиране и обмен на информация.
Оценка на пропуските по DORA
Структурирана оценка на пропуските спрямо DORA, оценена за всяка оценка, захранваща пътна карта за отстраняване, генерирана от отговорите.
Връзка риск-контрол
Рисковете и контролите са свързани записи в един модел. Всеки риск носи свързаните си контроли, оценки за вероятност и въздействие, отговорник, третиране и дата на преглед, което е проследимостта, която член 13(3) очаква да можете да покажете.
Регистър на информацията
Регистърът по член 28(3), изграден върху 15-те официални шаблона от B_01.01 до B_99.01, с оценка за пълнота, валидация преди експорт и xBRL-CSV експортен пакет, изграден по структурата на таблиците на ITS (ЕС) 2024/2956.
Проследяване на сроковете за инциденти
Инцидентите, класифицирани като големи, носят сроковете си за уведомяване като датирани стъпки за отмятане, а значителните инциденти по NIS2 носят собствен отделен часовник.
Регистър за тестване на устойчивостта
Планиране, отделни тестове и констатации, така че програмата за тестване, изисквана от член 24(1), да има запис с история.
Дашборд за борда и KRI пакет
Изглед за борда с оценки по рамките, отворени инциденти, политики и задачи, плюс изтегляем KRI пакет за борда за ритъма на докладване към ръководния орган.
Повторно използване на контроли между рамките
Рамката за управление на ИКТ риска не стои сама. Когато един контрол удовлетворява изискване в повече от една рамка, която поддържате, кръстосаното съпоставяне го пренася, вместо да ви кара да доказвате едно и също два пъти.
Нищо от това не пише рамката вместо вас. Документът трябва да описва вашата организация, вашата толерантност към риск и контролите, които реално прилагате. Това, което една платформа променя, е какво се случва след одобрението: дали рисковете, контролите, тестовете, инцидентите и договореностите с трети страни, които документът описва, са живи записи с отговорници и дати, или папка, която започва да остарява в седмицата, в която бордът я подписва.
Напишете рамката веднъж, след което я поддържайте жива.
Venvera държи регистъра на ИКТ рисковете, контролите, тестовете за устойчивост, инцидентите и регистъра на информацията като свързани записи, така че рамката, която одобрявате, е рамката, която можете да докажете.
Заявете демо →Първични източници
- Регламент (ЕС) 2022/2554 (DORA). Член 4, пропорционалност. Глава II, членове 5 до 16, управление на ИКТ риска. Членове 17 до 23, управление и докладване на инциденти. Членове 24 до 27, тестване на устойчивостта. Членове 28 до 30, ИКТ риск от трети страни. Прилага се от 17 януари 2025 г.
- Делегиран регламент (ЕС) 2024/1774 на Комисията. RTS, определящ инструментите, методите, процесите и политиките за управление на ИКТ риска и опростената рамка за управление на ИКТ риска. Членове 2 до 27, пълна рамка. Членове 28 до 41, опростена рамка.
- Делегиран регламент (ЕС) 2024/1772 на Комисията. RTS относно критериите за класифициране на инцидентите, свързани с ИКТ, и киберзаплахите, праговете на същественост и подробностите на докладите за големи инциденти.
- Делегиран регламент (ЕС) 2025/301 на Комисията. RTS относно съдържанието на докладите и сроковете за първоначалното уведомление и за междинния и окончателния доклад. Член 5 определя цитираните по-горе срокове.
- Делегиран регламент (ЕС) 2024/1773 на Комисията. RTS относно политиката за използването на ИКТ услуги, поддържащи критични или важни функции, по член 28(10) от DORA.
- Делегиран регламент (ЕС) 2025/532 на Комисията. RTS относно подизпълнението на ИКТ услуги, поддържащи критични или важни функции, по член 30(5) от DORA.
- Делегиран регламент (ЕС) 2025/1190 на Комисията. RTS относно тестването за проникване, водено от заплахи, по член 26(11) от DORA.
- Регламент за изпълнение (ЕС) 2024/2956 на Комисията. ITS относно стандартните шаблони за регистъра на информацията, по член 28(9) от DORA. Вижте нашето ръководство за 15-те официални шаблона.
Тази статия е само за информация и не представлява правен или регулаторен съвет. Цитатите на членове са проверени спрямо текстовете в Официален вестник на 14 юли 2026 г. Техническите стандарти се изменят с течение на времето, затова потвърдете действащата версия, преди да разчитате на който и да е срок или изискване, посочено тук.
