DORA за финансовия сектор — дигитална оперативна устойчивост
Регламент (ЕС) 2022/2554 (DORA) се прилага изцяло от 17 януари 2025 г. и обхваща над 20 категории финансови субекти. Ако вашата организация попада във финансовия сектор — от банки и застрахователи до крипто-доставчици и облачни платформи — DORA вече е задължителен. Глобите достигат 2% от глобалния оборот. Това ръководство покрива всички ключови изисквания.
Съдържание
Какво е DORA
DORA (Digital Operational Resilience Act) е Регламент (ЕС) 2022/2554 на Европейския парламент и на Съвета от 14 декември 2022 г. относно дигиталната оперативна устойчивост на финансовия сектор. Регламентът влиза в сила на 16 януари 2023 г., а се прилага изцяло от 17 януари 2025 г.
Като регламент (за разлика от директива), DORA се прилага директно във всички държави-членки на ЕС, включително България — без нужда от транспониране в националното законодателство. Това означава, че задълженията вече са в сила и подлежат на прилагане от компетентните органи.
Защо DORA?
Преди DORA финансовата индустрия в ЕС нямаше единна рамка за управление на ICT рисковете. Всяка държава имаше различни правила, а някои нямаха никакви. Атаките срещу финансови институции се увеличиха с над 300% между 2020 и 2024 г., което наложи хоризонтално законодателство на ниво ЕС.
DORA обхваща пет основни стълба:
- Управление на ICT рисковете
- Докладване на ICT инциденти
- Тестване на дигиталната оперативна устойчивост
- Управление на рисковете от ICT доставчици трети страни
- Споделяне на информация за киберзаплахи
Кого засяга DORA
DORA обхваща над 20 категории финансови субекти, както и критичните ICT доставчици, които ги обслужват. Ето пълният списък:
| Категория субект | Примери |
|---|---|
| Кредитни институции | Банки, спестовни каси |
| Застрахователни и презастрахователни предприятия | Животозастраховане, общо застраховане |
| Инвестиционни посредници | Брокерски къщи, управляващи дружества |
| Доставчици на услуги за крипто-активи (CASP) | Крипто-борси, попечители |
| Платежни институции | ePay, Stripe (лицензирани в ЕС) |
| Институции за електронни пари | E-money издатели |
| Доставчици на услуги за колективно финансиране | Crowdfunding платформи |
| Агенции за кредитен рейтинг | Fitch, Moody's (ЕС структури) |
| Централни контрагенти (CCP) | Клирингови къщи |
| Централни депозитари на ценни книжа | ЦДАД |
| Места на търговия | БФБ, MTF, OTF |
| Институции за професионално пенсионно осигуряване | Пенсионни фондове |
| Администратори на бенчмаркове | SOFIBOR, EURIBOR администратори |
| Репозиторитории на транзакции | Trade repositories |
| Критични ICT доставчици трети страни (CTPP) | Облачни доставчици, core banking системи, SaaS платформи |
Внимание: ICT доставчиците също са обхванати
Ако вашата компания предоставя ICT услуги на финансови институции — облачен хостинг, софтуер, анализ на данни, сигурност — вие може да бъдете определени като критичен ICT доставчик трета страна (CTPP) и да подлежите на пряк надзор от Европейските надзорни органи (ESAs).
ICT Risk Management (чл. 6–16)
Членове 6 до 16 от DORA изискват всяка финансова институция да създаде цялостна рамка за управление на ICT рисковете. Рамката трябва да бъде документирана, одитирана и преглеждана поне веднъж годишно.
Изисквания към рамката
- Идентификация — пълен инвентаризационен регистър на всички ICT активи, системи и зависимости
- Защита и превенция — политики за сигурност, контрол на достъпа, криптиране, patch management
- Откриване — мониторинг на аномалии, системи за ранно предупреждение
- Реагиране и възстановяване — планове за непрекъсваемост (BCP), планове за възстановяване при бедствие (DRP)
- Обучение — задължителни програми за повишаване на осведомеността на персонала по ICT сигурност
- Комуникация — планове за кризисна комуникация, включително с компетентните органи и обществеността
Управителният орган (борд на директорите) носи крайна отговорност за рамката за управление на ICT рисковете. Той трябва да одобрява стратегията, да определя толерантността към рискове и да получава редовни доклади.
Годишен преглед и одит
ICT рамката подлежи на преглед поне веднъж годишно, както и след всеки значителен ICT инцидент. Вътрешният одит (или независим външен одит) трябва да оценява ефективността на рамката. Резултатите се докладват на управителния орган.
Чл. 16: Опростена рамка за микропредприятия
DORA предвижда опростена ICT рамка за микропредприятия (под 10 служители и под 2 млн. евро оборот). Те не са задължени да имат пълна рамка по чл. 6–15, но трябва да прилагат базови мерки за ICT сигурност, пропорционални на размера и рисковия им профил. Задълженията за докладване на инциденти остават непроменени.
Докладване на ICT инциденти
DORA въвежда стандартизирана тристепенна процедура за докладване на значителни ICT инциденти. Тя е по-детайлна и по-кратка от сроковете по GDPR и NIS2.
Трите фази на докладване
| Фаза | Срок | Съдържание |
|---|---|---|
| Първоначално уведомление | До 4 часа от класификацията (макс. 24 часа от инцидента) | Естество на инцидента, засегнати системи, първоначална оценка на въздействието |
| Междинен доклад | До 72 часа | Актуализация на въздействието, предприети мерки, статус на възстановяването |
| Финален доклад | До 1 месец | Причини (root cause analysis), пълно въздействие, научени уроци, предприети коригиращи мерки |
Сравнение на сроковете за докладване
| Регулация | Първо уведомление | Междинен доклад | Финален доклад | Компетентен орган |
|---|---|---|---|---|
| DORA | 4h (макс. 24h) | 72h | 1 месец | Финансов регулатор (БНБ / КФН) |
| GDPR | 72 часа | — | — | КЗЛД |
| NIS2 | 24 часа (ранно предупреждение) | 72h | 1 месец | CERT Bulgaria / секторен орган |
Паралелно докладване
Ако ICT инцидент е свързан и с нарушение на лични данни (data breach), организацията трябва да докладва паралелно — на финансовия регулатор по DORA и на КЗЛД по GDPR. Сроковете текат независимо. Прочетете нашата статия за реакция при теч на лични данни в първите 72 часа.
Тестване на дигиталната устойчивост (чл. 24–27)
DORA въвежда задължително тестване на дигиталната устойчивост на две нива: базово тестване (ежегодно) и напреднало тестване — Threat-Led Penetration Testing (TLPT) на всеки 3 години.
Базово тестване (ежегодно)
- Vulnerability assessments и мрежови сканирания
- Тестове на софтуерна сигурност (включително open source)
- Gap анализ спрямо рамката по чл. 6–15
- Тестове за съвместимост и performance
- Тестове на физическата сигурност
- Прегледи на source code (при наличие)
- Scenario-based тестове (включително DDoS симулации)
TLPT — напреднало тестване (на всеки 3 години)
Системно важните финансови институции трябва да провеждат Threat-Led Penetration Testing (TLPT) на всеки три години. Това е red team тестване, базирано на реалистични сценарии за заплахи.
Threat Intelligence
Независим доставчик на threat intelligence подготвя специфични за организацията сценарии за заплахи.
Red Teaming
Външен тестващ екип (сертифициран) симулира реални атаки по сценариите, без предварително предупреждение на оперативните екипи.
Purple Teaming (задължително)
Задължителна фаза, в която red team и blue team работят заедно за споделяне на намерените уязвимости и подобряване на защитите.
Доклад и ремедиация
Финален доклад до компетентния орган. План за ремедиация с конкретни срокове. Тестващият екип потвърждава изпълнението.
Изисквания към външния тестващ екип
- Независимост от тестваната организация
- Доказан опит в TLPT / red teaming
- Професионална застраховка
- Акредитация или сертификация (CREST, TIBER-EU, или еквивалент)
- Строги NDA и етични правила
TLPT RTS — юни 2025
Регулаторните технически стандарти (RTS) за TLPT бяха публикувани от ESAs през юни 2025 г., като конкретизират методологията, изискванията към тестващите екипи и формата на докладите. Те заменят досегашните TIBER-EU рамки.
Управление на ICT доставчици (чл. 28–44)
Членове 28–44 от DORA въвеждат най-детайлните изисквания в ЕС за управление на рисковете от ICT доставчици трети страни. Те надхвърлят значително изискванията на чл. 28 от GDPR за договори за обработка на лични данни.
Договорни изисквания
Всеки договор с ICT доставчик трета страна трябва да съдържа минимум:
- Ясно описание на предоставяните услуги и SLA (service level agreements)
- Локации за обработка на данни — къде се съхраняват и обработват данните
- Достъп и одитни права — право на финансовата институция да провежда одити (включително on-site)
- Подизпълнители — изисквания за одобрение при промяна на подизпълнители
- Exit стратегия — преходни периоди и съдействие при прекратяване на договора
- Задължения при инциденти — уведомяване, съдействие, достъп до логове
- Непрекъсваемост — гаранции за непрекъсваемост на услугата и disaster recovery
Сравнение: DORA чл. 28–44 vs GDPR чл. 28
| Изискване | DORA | GDPR |
|---|---|---|
| Описание на услугите | Детайлно, с SLA | Общо описание |
| Локации на данни | Задължително | По преценка |
| Одитни права | Задължителни, включително on-site | Право на одит (чл. 28(3)(h)) |
| Подизпълнители | Предварително одобрение | Общо/специфично съгласие |
| Exit стратегия | Задължителна, с преходен период | Не е изрично |
| Уведомяване при инциденти | Задължително, с конкретни срокове | Без забавяне (чл. 33(2)) |
| Регистър на доставчиците | Задължителен — подава се до регулатора | В регистъра по чл. 30 |
Критични ICT доставчици (CTPP)
Европейските надзорни органи (EBA, ESMA, EIOPA) могат да определят даден ICT доставчик като критичен (CTPP), ако той обслужва голям брой финансови институции или предоставя трудно заменими услуги. Критичните доставчици подлежат на пряк надзор от ЕС, включително инспекции на място и задължителни препоръки.
Регистър на ICT доставчиците
Всяка финансова институция е длъжна да поддържа пълен регистър на всички договорни отношения с ICT доставчици. Регистърът се подава до компетентния орган (БНБ или КФН) и трябва да включва информация за критичността на услугите, зависимостите и концентрационния риск.
DORA vs NIS2 vs GDPR
DORA, NIS2 и GDPR имат различен фокус, но се припокриват в редица области. Ключовият принцип е, че DORA е lex specialis за финансовия сектор — когато DORA и NIS2 се припокриват, DORA има предимство.
| Параметър | DORA | NIS2 | GDPR |
|---|---|---|---|
| Тип акт | Регламент (директно) | Директива (транспониране) | Регламент (директно) |
| Обхват | Финансов сектор + ICT доставчици | 18+ сектора (вкл. финансов) | Всички обработващи лични данни |
| Фокус | ICT оперативна устойчивост | Киберсигурност (мрежи и информационни системи) | Защита на лични данни |
| Lex specialis | Да — за финанси | Общ режим | Общ режим (данни) |
| Първо уведомление | 4h (макс. 24h) | 24h (ранно предупреждение) | 72h (data breach) |
| Финален доклад | 1 месец | 1 месец | — |
| Тестване | Ежегодно + TLPT на 3 години | По преценка на държавата | DPIA (за обработка с висок риск) |
| Доставчици | Детайлни изисквания + пряк надзор на CTPP | Общи изисквания за supply chain | Договор по чл. 28 |
| Глоби | До 2% оборот + лични санкции | До 10 млн. EUR / 2% оборот | До 20 млн. EUR / 4% оборот |
| Компетентен орган (БГ) | БНБ / КФН | Секторни органи / CERT | КЗЛД |
Lex specialis принцип (чл. 1(2) DORA)
Когато финансова институция попада едновременно под DORA и NIS2, DORA има предимство по въпросите на ICT risk management, incident reporting и тестване. Институцията прилага DORA, а не NIS2 в тези области. GDPR обаче продължава да се прилага паралелно по въпросите за защита на личните данни.
DORA в България
Макар DORA да не изисква транспониране, България прие на 8 юли 2025 г. допълнителен закон, който определя националните компетентни органи и специфичните процедури за прилагане.
Компетентни органи
| Орган | Обхват |
|---|---|
| Българска народна банка (БНБ) | Банки, кредитни институции, платежни институции, институции за електронни пари |
| Комисия за финансов надзор (КФН) | Застрахователи, инвестиционни посредници, пенсионни фондове, управляващи дружества, CASP, crowdfunding платформи |
Персонална отговорност на ръководството
Националният закон предвижда персонална отговорност на членовете на управителните органи при неспазване на DORA. Това включва:
- Административни глоби на физически лица от ръководството
- Временно отстраняване от управленска позиция (до 1 година)
- Публично оповестяване на имената на отговорните лица
- Забрана за заемане на ръководна длъжност във финансова институция
Лична отговорност — нов стандарт
За разлика от GDPR, където глобите се налагат предимно на организацията, DORA изрично предвижда лични санкции за членовете на ръководството. Това означава, че CEO, CFO и CTO носят лична отговорност за неадекватна ICT рамка.
Глоби и санкции
DORA предвижда строг санкционен режим, който варира в зависимост от типа субект:
За финансови институции
- До 2% от общия годишен глобален оборот (или до 1% от дневния оборот за всеки ден на продължаващо нарушение — дневни глоби)
- За физически лица от ръководството — до 1 000 000 EUR
- Публично оповестяване на нарушенията (naming and shaming)
- Временна забрана за извършване на определени дейности
За критични ICT доставчици (CTPP)
- До 5 000 000 EUR (или 1% от среднодневния глобален оборот за всеки ден на нарушение)
- Задължителни препоръки за отстраняване на нарушения
- Временна забрана за предоставяне на услуги на финансови институции в ЕС
- Публично оповестяване
Фактори за определяне на глобата
| Утежняващ фактор | Смекчаващ фактор |
|---|---|
| Продължителност и тежест на нарушението | Бързо предприемане на коригиращи мерки |
| Системни слабости в управлението | Ефективно сътрудничество с регулатора |
| Умишлено действие или груба небрежност | Първо нарушение |
| Предишни нарушения | Доброволно уведомяване |
| Отказ от сътрудничество | Инвестиции в подобряване на ICT рамката |
„DORA превръща ICT устойчивостта от технически въпрос в стратегически приоритет на борда на директорите. Персоналната отговорност на ръководството е сигнал, че ЕС не приема оправдания от типа «IT отделът се занимава с това».“
Често задавани въпроси
Прилага ли се DORA директно в България?
Да. DORA е регламент на ЕС (Regulation 2022/2554), което означава, че се прилага директно без необходимост от транспониране. В България БНБ и КФН са определени като компетентни органи съгласно закона от 8 юли 2025 г.
Какви са сроковете за докладване на ICT инциденти?
DORA предвижда три фази: първоначално уведомление до 4 часа от класификацията (максимум 24 часа от инцидента), междинен доклад до 72 часа и финален доклад до 1 месец. При теч на лични данни се докладва паралелно и на КЗЛД по GDPR. Вижте пълното ръководство за реакция при теч на данни.
Трябва ли малките финансови институции да спазват DORA?
Да, но с облекчения. Чл. 16 предвижда опростена рамка за ICT рисковете за микропредприятия (под 10 служители и под 2 млн. EUR оборот). Задълженията за докладване на инциденти и управление на доставчици се прилагат за всички. За по-широк контекст вижте нашата статия за GDPR одит за бизнеса.
Каква е връзката между DORA и GDPR?
DORA и GDPR се допълват. DORA покрива оперативната устойчивост на ICT системите, а GDPR — защитата на личните данни. При data breach, който е и ICT инцидент, се прилагат двата режима паралелно с различни срокове и органи. Договорните изисквания на DORA (чл. 28–44) допълват изискванията на чл. 28 от GDPR за договори за обработка.
Тази статия отразява правното положение към 23 март 2026 г. Информацията е с информативен характер и не представлява правна консултация. За конкретен правен съвет, моля свържете се с нас.
GDPR + DORA съответствие за финансови институции
Нашият екип от юристи и IT специалисти предлага цялостно решение за привеждане в съответствие с DORA и GDPR — от gap анализ до внедряване на ICT рамка.
- Gap анализ спрямо DORA и изготвяне на пътна карта
- ICT рамка за управление на рисковете (чл. 6–16)
- Преглед и актуализация на договори с ICT доставчици
- Процедури за докладване на инциденти (DORA + GDPR)
- Подготовка за TLPT и координация с тестващи екипи
- Пълен GDPR одит и DPA с доставчици
Получавайте нови статии директно в пощата си
Практически анализи по GDPR и киберсигурност. Без спам.
Можете да се отпишете по всяко време. Политика за поверителност