Научете
🕑 12 минути четене
📅 9 март 2026 г.
🏫 Регулаторен анализ
17 януари 2025 г. трябваше да бъде датата, с която приключва подготвителният период. DORA, Регламентът за цифровата оперативна устойчивост (Регламент (ЕС) 2022/2554), започна да се прилага изцяло и от финансовите субекти в целия Европейски съюз се очакваше да изпълняват изискванията му в пълен обем. Посланието на регулаторите беше ясно: без преходен период, без гратисен период, без извинения.
Повече от четиринадесет месеца по-късно картината е отрезвяваща. Европейският банков орган (ЕБО), Европейската централна банка (ЕЦБ) и националните компетентни органи (НКО) започнаха първите кръгове надзорни оценки. Това, което откриват, потвърждава опасенията на много специалисти по съответствие: повечето финансови субекти са постигнали в най-добрия случай повърхностно съответствие. Политиките бяха приети, управленските структури бяха определени, но оперативното съдържание, т.е. инструментите, данните и изпитаните процеси, не беше готово.
Въз основа на надзорни наблюдения, отраслови проучвания и прякия ни опит с десетки финансови субекти в ЕС идентифицирахме пет структурни пропуска в съответствието, които се повтарят отново и отново. Това не са изолирани случаи. Те засягат по-голямата част от институциите, от банките от първа категория до инвестиционните посредници от средния сегмент. Тази статия разглежда подробно всеки пропуск, обяснява защо той продължава да съществува и предлага конкретен път за отстраняването му.
⚠️ Надзорен контекст
Надзорните приоритети на ЕЦБ за 2025 до 2026 г. изрично посочват ИКТ риска и цифровата оперативна устойчивост като ключова област на внимание. Партньорската проверка на ЕБО относно прилагането на DORA е насрочена за третото тримесечие на 2026 г. Националните компетентни органи в 27-те държави членки на ЕС вече издадоха предварителни констатации от проверки на място. Институциите, които не са отстранили тези пропуски, са изправени пред надзорни мерки, и то не на теория, а по определен надзорен график.
📋
Пропуск 1: критичен
Непълен регистър на информацията
Регулаторното изискване
Член 28, параграф 3 от DORA изисква финансовите субекти да поддържат пълен регистър на информацията (Register of Information, RoI), обхващащ всички договорни споразумения за използване на ИКТ услуги, предоставяни от доставчици на ИКТ услуги, трети страни. Техническият стандарт за изпълнение (ТСИ), публикуван от ЕНО през януари 2024 г., определя точния модел на данните: 15 взаимосвързани образеца с над 100 задължителни полета, обхващащи самия субект, доставчиците на ИКТ услуги, договорните споразумения, веригите на подизпълнение, поддържаните стопански функции и оценките на риска.
Какво откриват надзорните органи: Повечето институции са изградили регистър, но данните са непълни, противоречиви или структурно грешни. Най-честите недостатъци са:
- Липсващи вериги на подизпълнение. Член 28, параграф 3, буква а) изисква субектите да идентифицират не само преките си доставчици на ИКТ услуги, но и цялата верига на подизпълнение за критични или важни функции. Повечето банки са документирали само доставчиците от първо ниво. Когато доставчик на облачни услуги възложи на подизпълнител хостинга на данни или мониторинга на сигурността, тази верига остава невидима в регистъра.
- Неправилни или липсващи идентификатори на субекти. ТСИ на ЕНО изисква LEI кодове (когато са налични), видове субекти по класификационните кодове на ЕНО и идентификатори от НКО за регулираните субекти. Много регистри съдържат наименования на дружества като свободен текст без структурирани идентификатори, което прави данните неподходящи за надзорно отчитане.
- Липса на възможност за експорт в xBRL-CSV. ЕНО изискват регистърът да може да се подава във формат xBRL-CSV, структуриран, машинночетим формат, използван от надзорните системи за подаване на отчети. Институциите, изградили регистъра си в Excel или SharePoint, не могат да изготвят валиден регулаторен отчет.
- Пропуски в съпоставянето със стопанските функции. Всяко договорно споразумение трябва да бъде свързано със стопанските функции и критичните или важните функции, които поддържа. Институциите често съпоставят доставчиците на ИКТ услуги с отдели, а не с конкретни стопански функции, както са определени в собствената им рамка за управление на ИКТ риска.
„Регистърът на информацията не е упражнение по документиране. Той е инфраструктурата от данни, на която се основава надзорът върху риска от ИКТ трети страни. Непълните регистри подкопават цялата надзорна рамка.“
Документ за обсъждане на ЕБО относно прилагането на DORA, 2025 г.
Защо пропускът се запазва: Регистърът е измамно сложен. Институциите го възприеха като упражнение по снабдяване (списък на доставчиците), а не като упражнение по архитектура на данните (моделиране на цялата верига на доставки на ИКТ с данни с регулаторно качество). Моделът на данните в ТСИ на ЕНО изисква релационна цялост между 15 таблици, нещо, което електронните таблици не могат да осигурят.
🏗️
Пропуск 2: висок риск
Рискът от концентрация при ИКТ трети страни не е количествено оценен
Регулаторното изискване
Членове 28 до 30 от DORA изискват финансовите субекти да оценяват риска от концентрация, произтичащ от зависимости от ИКТ трети страни. Член 29, параграф 2 изрично изисква субектите да идентифицират и оценяват рисковете, произтичащи от подизпълнението и от ситуации, при които множество критични функции зависят от един и същ доставчик или от малка група доставчици. Субектът трябва да вземе предвид и заменимостта: дали съществуват алтернативни доставчици и дали миграцията е осъществима.
Какво откриват надзорните органи: Анализът на риска от концентрация, когато изобщо съществува, обикновено е качествен и повърхностен. Институциите признават, че зависят силно от малък брой доставчици на облачни услуги (обикновено AWS, Microsoft Azure и Google Cloud), но не са извършили количествения анализ, който DORA изисква:
Единични точки на отказ
Повечето банки не могат да определят кои критични стопански функции биха били засегнати едновременно, ако един доставчик на ИКТ услуги претърпи голямо прекъсване. Съпоставянето между доставчици и стопански функции е непълно.
Оценка на заменимостта
Член 29 изисква анализ на това дали съществуват алтернативни доставчици на ИКТ услуги. Малко институции са документирали осъществимостта на замяната, разходите за миграция или факторите на обвързване с доставчика за критичните си доставчици на ИКТ услуги.
Зависимости между субекти
Рискът от концентрация на ниво група, при който няколко субекта от една финансова група зависят от един и същ доставчик, почти никога не се агрегира. Надзорните органи очакват консолидиран поглед на ниво група.
Пропуски в стратегиите за излизане
DORA изисква документирани планове за излизане за критичните доставчици на ИКТ услуги (член 28, параграф 8). Повечето институции имат общи клаузи за излизане в договорите, но нямат оперативна стратегия за излизане със срокове, разходи и резултати от тестване.
Защо пропускът се запазва: Анализът на риска от концентрация изисква данни, които обхващат снабдяването, ИТ архитектурата, непрекъснатостта на дейността и управлението на риска. В повечето институции тези данни се намират в четири различни системи, притежавани от четири различни отдела. Без единна платформа за ИКТ риска анализът е структурно невъзможен.
🚨
Пропуск 3: критичен
Критериите за класифициране на инциденти не са въведени в практиката
Регулаторното изискване
Членове 17 до 20 от DORA създават цялостна рамка за управление на инциденти, свързани с ИКТ. Член 18 определя конкретни критерии за класифициране, кодифицирани в РТС за класифициране на инциденти, публикувани от ЕНО, които финансовите субекти трябва да прилагат, за да определят дали даден инцидент е „голям“ и следователно подлежи на задължително докладване на НКО. Класифицирането е тест по няколко критерия в седем измерения: въздействие върху клиентите, цялост на данните, критичност на засегнатите услуги, икономическо въздействие, продължителност, географско разпространение и въздействие върху трансакциите.
Какво откриват надзорните органи: Институциите имат политики за управление на инциденти, които се позовават на DORA. Те са актуализирали процедурите си за реагиране при инциденти, за да споменат докладването на НКО. Но самото класифициране, т.е. оперативният механизъм, който определя в реално време дали даден инцидент преминава прага за „голям“, не е вграден в работните процеси:
- Определенията на праговете са неясни. РТС изискват количествени прагове (например процент засегнати клиенти, продължителност в часове, обем неуспешни трансакции). Повечето институции са определили праговете качествено („значителен брой клиенти“) или изобщо не са калибрирали прагове.
- Сроковете за докладване не са автоматизирани. DORA изисква първоначално уведомление в рамките на 4 часа от класифицирането, междинни доклади в рамките на 72 часа и окончателни доклади в рамките на един месец. Тези срокове трябва да се задействат автоматично, щом даден инцидент бъде класифициран като голям. В повечето банки следенето на сроковете е ръчно или изобщо липсва.
- Решението за класифициране се взема ад хок. Вместо системно да прилагат теста по седемте критерия, анализаторите в SOC правят субективни преценки за тежестта. Това води до недостатъчно докладване (избягване на надзорно внимание) или до забавено докладване (защото никой не е сигурен дали праговете са достигнати).
- Липсва агрегиране на повтарящи се инциденти. Член 19, параграф 4 изисква да се докладват повтарящи се инциденти, които поотделно не достигат прага за голям инцидент, но заедно образуват значим модел. Почти никоя институция не е въвела логика за агрегиране.
„Наличието на политика за реагиране при инциденти не е същото като наличието на оперативен капацитет за класифициране на инциденти. Надзорните органи ще проверяват второто, а не първото.“
Надзорен бюлетин на ЕЦБ, наблюдения относно ИКТ риска, 2025 г.
Защо пропускът се запазва: Класифицирането на инциденти по DORA е коренно различно от традиционните модели за тежест, основани на ITIL. Класифицирането по DORA е регулаторен акт с правни последици (задължително докладване, надзорни последващи действия, възможни санкции). Повечето инструменти за управление на инциденти са създадени за ИТ операции, а не за регулаторно съответствие.
🛡️
Пропуск 4: съществен
Пропуски в програмата за тестване на устойчивостта
Регулаторното изискване
Членове 24 до 27 от DORA въвеждат задължителна програма за тестване на цифровата оперативна устойчивост. Член 24 изисква всички финансови субекти да поддържат цялостна програма за тестване, пропорционална на техния размер, като част от рамката им за управление на ИКТ риска. За субектите, определени от НКО като значими, член 26 изисква тестване за проникване въз основа на заплахи (TLPT) най-малко веднъж на всеки три години, провеждано в съответствие с член 26 от DORA и придружаващите го регулаторни технически стандарти.
Какво откриват надзорните органи: Годишните програми за тестване съществуват на хартия, тъй като повечето институции вече са имали сканиране за уязвимости и тестване за проникване. Но изискванията на DORA към програмата за тестване надхвърлят значително досегашната практика:
| Изискване за тестване | Чест пропуск | Стандарт за съответствие |
|---|---|---|
| Одобрение на програмата за тестване от ръководния орган (член 24, параграф 2) | Тестването се планира от ИТ екипа или екипа по сигурност без одобрение от ръководния орган | Ръководният орган официално одобрява ежегодно обхвата, честотата и методологията |
| Определяне на обхвата и провеждане на TLPT (член 26) | Няма програма за TLPT или обхватът на TLPT не покрива всички критични функции | TLPT на всеки 3 години съгласно член 26 от DORA, като обхватът покрива всички идентифицирани критични функции |
| Тестване въз основа на сценарии (член 24, параграф 6) | Само сканиране за уязвимости, без тестове въз основа на сценарии или стрес тестове | Тестове по сценарии за отказ на доставчик на ИКТ услуги, кибератака и загуба на данни |
| Проследяване на отстраняването на констатациите (член 24, параграф 5) | Констатациите се проследяват в електронни таблици, без официален срок за отстраняване или ескалация | Всички констатации се проследяват с отговорник, срок, повторно тестване и докладване на ръководния орган |
| Независимост на външните тестващи (член 26, параграф 8) | Един и същ доставчик извършва одита и TLPT, без проверена независимост | Независими външни тестващи с документирана квалификация и без конфликт на интереси |
| Обхващане на доставчиците на ИКТ услуги (член 24, параграф 4) | Програмата за тестване обхваща само вътрешните системи, услугите на трети страни са изключени | Тестването обхваща ИКТ услугите, предоставяни от трети страни в подкрепа на критични функции |
Защо пропускът се запазва: Разминаването е между тестването на сигурността (техническо упражнение, управлявано от CISO) и тестването на устойчивостта по DORA (упражнение по управление, ръководено от ръководния орган). DORA изисква програмата за тестване да бъде интегрирана в рамката за управление на ИКТ риска, одобрена от ръководния орган, а резултатите ѝ да се връщат обратно в оценките на риска. Повечето институции никога не са свързвали тези процеси.
📜
Пропуск 5: повсеместен
В договорните споразумения липсват задължителните клаузи по член 30
Регулаторното изискване
Член 30 от DORA съдържа подробен списък със задължителни договорни клаузи, които трябва да бъдат включени във всички споразумения с доставчици на ИКТ услуги, трети страни. За доставчиците, които поддържат критични или важни функции, изискванията се разширяват допълнително. Членът изисква най-малко 14 отделни договорни разпоредби, а за доставчиците на критични функции и допълнителен набор от засилени изисквания, обхващащи правата на одит, стратегиите за излизане, контрола върху подизпълнението и ангажиментите за местоположението на данните.
Над 14-те задължителни клаузи, които трябва да присъстват в ИКТ договорите по член 30:
1. Ясно описание на всички ИКТ услуги (член 30, параграф 2, буква а))
2. Местоположения за обработване и съхранение на данни (член 30, параграф 2, буква б))
3. Споразумения за ниво на обслужване с количествени нива на услугата (член 30, параграф 2, буква в))
4. Задължения за докладване на инциденти (член 30, параграф 2, буква г))
5. Разпоредби за непрекъснатост на дейността (член 30, параграф 2, буква д))
6. Права за прекратяване и срокове за предизвестие (член 30, параграф 2, буква е))
7. Достъп до данните, връщане и заличаване (член 30, параграф 2, буква ж))
8. Сътрудничество с компетентните органи (член 30, параграф 2, буква з))
9. Неограничени права на одит и достъп (член 30, параграф 3, буква а))
10. Условия и одобрение на подизпълнението (член 30, параграф 3, буква б))
11. Цялостни стратегии за излизане (член 30, параграф 3, буква г))
12. Участие в тестването на устойчивостта (член 30, параграф 3, буква д))
13. Мерки за сигурност на данните и криптиране (член 30, параграф 2, буква и))
14. Съдействие при преход и миграция (член 30, параграф 3, буква е))
Какво откриват надзорните органи: Пропускът е огромен. Повечето действащи ИКТ договори предхождат DORA и са договорени по регулаторни рамки отпреди DORA (Насоките на ЕБО относно възлагането на дейности на външни изпълнители, местни изисквания на НКО). Програмите за привеждане на договорите в съответствие, т.е. системният процес на изменение на действащите договори с цел включване на клаузите по член 30, или не са започнали, или напредват твърде бавно:
- Договорите с големите хиперскейлъри са най-трудни. Институциите съобщават, че AWS, Microsoft и Google са публикували „допълнения за DORA“, които частично отговарят на член 30, но тези стандартизирани документи често не изпълняват изцяло изискванията на регламента, особено по отношение на неограничените права на одит и одобрението на подизпълнението.
- Няма проследяване клауза по клауза. Повечето институции нямат системен начин да проследяват кои от над 14-те задължителни клаузи присъстват във всеки договор. Оценката се извършва ръчно, договор по договор, от правните екипи, без структуриран резултат под формата на данни.
- Сроковете за подновяване не са синхронизирани. Много ИКТ договори са многогодишни. Институциите изчакват подновяването на договорите, за да въведат клаузите по DORA, и така остават в несъответствие до дати на подновяване, които може да са след 2 до 3 години.
Защо пропускът се запазва: Привеждането на договорите в съответствие в голям мащаб е огромно правно упражнение и упражнение по снабдяване. Една средно голяма банка може да има от 200 до 500 договора с доставчици на ИКТ услуги. Прегледът на всеки договор спрямо над 14 задължителни клаузи, договарянето на изменения с доставчици, които може да се съпротивляват (особено по отношение на правата на одит и контрола върху подизпълнението), и проследяването на програмата за отстраняване изискват специализирани инструменти, а не правен екип и електронна таблица.
✅
Самооценка
Чеклист за оценка на готовността по DORA
Използвайте тази таблица, за да сравните институцията си с петте критични области на пропуски. Бъдете честни: надзорните органи ще бъдат.
| Област на пропуска | ✓ Как изглежда съответствието | ✗ Как изглежда несъответствието |
|---|---|---|
| Регистър на информацията | Пълен регистър с попълнени всички 15 образеца на ЕНО, картографирани вериги на подизпълнение, валидирани LEI кодове, изпитан и подаден експорт в xBRL-CSV | Списък с доставчици в Excel само с наименования на дружества, без видимост върху подизпълнението, без възможност за регулаторен експорт |
| Риск от концентрация | Количествен анализ на зависимостта за всеки критичен доставчик, документирана оценка на заменимостта, изпитани стратегии за излизане, табло, докладвано на ръководния орган | Качествено твърдение, че „зависим от AWS“, без количествен анализ на въздействието, без планове за излизане, без оценка на заменимостта |
| Класифициране на инциденти | Тестът по седемте критерия от член 18 е вграден в работния процес на SOC, калибрирани количествени прагове, автоматизирани срокове за докладване (4 ч./72 ч./1 месец), агрегиране на повтарящи се инциденти | Актуализирана политика за инциденти, която се позовава на DORA, но без оперативен механизъм за класифициране; анализаторите преценяват тежестта субективно |
| Тестване на устойчивостта | Програма за тестване, одобрена от ръководния орган, обхват на TLPT съгласно член 26 от DORA, проведени тестове по сценарии, официално проследени констатации със срокове за отстраняване и повторно тестване | Само годишен тест за проникване и сканиране за уязвимости, без одобрение от ръководния орган, без програма за TLPT, констатации в PDF доклади без проследяване |
| Договори по член 30 | Всички ИКТ договори са прегледани спрямо над 14-те задължителни клаузи, програма за отстраняване със срокове, проследяване клауза по клауза за всеки договор, табло за статуса на преговорите | Договорите предхождат DORA, няма системен преглед на клаузите, изчаква се цикълът на подновяване, допълненията на хиперскейлърите са приети без gap анализ |
⚠️ Оценяване на резултата
Ако институцията ви попада на страната на „несъответствието“ в 3 или повече от тези области, съществува значителен риск от надзорни констатации. Методологията на ЕЦБ за проверки на място на ИКТ риска включва и петте области, а НКО провеждат целеви прегледи, насочени специално към регистъра на информацията и готовността за класифициране на инциденти.
🛠️
Решение
Как инструментът за gap анализ на Venvera затваря тези пропуски
Тези пет пропуска не са случайни. Те имат обща първопричина: институциите управляват съответствието с DORA в несвързани електронни таблици, документи и общи GRC инструменти, които не са създадени за специфичните изисквания на DORA. Venvera е създадена специално, за да реши точно този проблем.
Автоматизирано оценяване на пропуските
Механизмът за gap анализ на Venvera оценява институцията ви по всичките пет стълба на DORA: управление на ИКТ риска (членове 5 до 16), управление на инциденти (членове 17 до 20), тестване на устойчивостта (членове 24 до 27), риск от трети страни (членове 28 до 30) и обмен на информация (член 45). Всеки стълб получава резултат за съответствие въз основа на пълнотата на данните, зрелостта на процесите и качеството на доказателствата.
Отчети, готови за ръководния орган
Създавайте резюмета за ръководството, които превеждат техническите пропуски в съответствието на езика на бизнес риска, разбираем за вашия ръководен орган. Табла по стълбове, линии на тенденциите, показващи напредъка във времето, и сравнение с регулаторни референтни стойности, всичко това с възможност за експорт в PDF за материалите на ръководния орган.
Модул за регистъра на информацията
Изцяло структуриран регистър на информацията, който налага модела на данните от ТСИ на ЕНО. Всички 15 образеца са вградени, с валидиране на LEI, търсене на кодове на субекти на ЕНО, картографиране на веригите на подизпълнение и експорт в xBRL-CSV с едно щракване. Край на акробатиките с електронни таблици: моделът на данните гарантира пълнотата.
Проследяване на отстраняването
Всеки идентифициран пропуск се превръща в проследима задача за отстраняване с отговорник, срок, ниво на приоритет и свързани доказателства. Напредъкът се измерва автоматично с въвеждането на данни и документирането на процесите. Нито един пропуск не се губи в поредица от имейли.
Проследяване на договорните клаузи
Проследявайте покритието на клаузите по член 30 за всеки договор. Всяка от над 14-те задължителни клаузи може да бъде отбелязана като налична, липсваща или частично покрита, с връзки към съответния раздел от договора. Изгледът на таблото показва общия напредък по отстраняването в целия ви портфейл от договори.
Механизъм за класифициране на инциденти
Специфично за DORA класифициране на инциденти, с теста по седемте критерия от член 18, вграден в работния процес. Количествените прагове са конфигурируеми, сроковете за докладване се изчисляват автоматично, а образците за уведомяване на НКО са предварително форматирани. Агрегирането на повтарящи се инциденти е автоматизирано.
Защо специализираното решение има значение
Общите GRC платформи третират DORA като чеклист от контроли. Venvera третира DORA като проблем на архитектурата на данните, защото той е точно такъв. Регистърът на информацията е релационна база данни. Рискът от концентрация изисква графов анализ на зависимостите от доставчици. Класифицирането на инциденти изисква механизъм от правила. Съответствието на договорите изисква проследяване на ниво клауза. Това са инженерни проблеми, а не проблеми на чеклисти.
📅
Времева линия
Надзорният часовник тиктака
Разбирането на надзорния календар е от решаващо значение за приоритизирането на усилията ви по отстраняване. Ето ключовите етапи, които трябва да определят графика ви за затваряне на пропуските:
| Дата | Надзорен етап | Какво означава за вас |
|---|---|---|
| 17 януари 2025 г. | Дата на прилагане на DORA | Пълно съответствие се изисква от тази дата. Без преходен период. |
| 30 април 2025 г. | Първи срок за подаване на регистъра на информацията (при повечето НКО) | Регистърът на информацията е подаден на НКО. Отбелязани са проблеми с качеството на данните. |
| Второ полугодие на 2025 г. до първо полугодие на 2026 г. | Първа вълна проверки на място (ЕЦБ, НКО) | Целеви прегледи на рамките за управление на ИКТ риска, капацитета за реагиране при инциденти и програмите за тестване. |
| Трето тримесечие на 2026 г. | Партньорска проверка на ЕБО относно прилагането на DORA | Оценка в различните юрисдикции. НКО са под натиск да докажат, че прилагат регламента. Очаквайте засилен надзор. |
| 2025 до 2028 г. | Определяне на критичните трети страни доставчици на ИКТ услуги (CTPP) и рамка за надзор | Определени са водещи надзорни органи за критичните доставчици на ИКТ услуги. Пряко отражение върху анализа ви на риска от концентрация и планирането на излизането. |
„DORA не е регламент, който финансовите субекти могат да спазват на хартия с надеждата, че надзорните органи няма да забележат пропуските на практика. Надзорната методология е създадена да проверява оперативното съдържание, а не документалната форма. Субектите, които имат политики, но нямат капацитет, ще бъдат установени в несъответствие.“
Анализ въз основа на надзорните приоритети на Банковия надзор на ЕЦБ и насоките на ЕБО
За тази статия
Този анализ се основава на публично достъпни надзорни публикации на ЕЦБ, ЕБО и националните компетентни органи, съчетани с прекия опит на Venvera в подкрепа на финансови субекти в ЕС при съответствието с DORA. Петте идентифицирани области на пропуски отразяват модели, наблюдавани в множество юрисдикции и видове институции.
DORA gap анализ 2026
пропуски в съответствието с DORA
оценка на готовността по DORA
регистър на информацията
договори по член 30
риск от концентрация при ИКТ
Правна информация: Тази статия е само с информационна цел и не представлява правен или регулаторен съвет. Финансовите субекти следва да се консултират с квалифицирани специалисти по право и съответствие относно конкретните си задължения по DORA. Регулаторните тълкувания може да се различават според юрисдикцията и вида на субекта. Позоваванията на надзорни публикации се основават на публично достъпни документи към март 2026 г.
© 2026 Venvera. Всички права запазени.
