DORA в България: какво точно изисква регламентът от банки, платежни институции, инвестиционни посредници, застрахователи и CASP по МиКА през 2026 г.

• Кредитни институции (банки) - 18 банки с лиценз в България плюс клонове на ЕС банки. Надзор: БНБ.
• Платежни институции и дружества за електронни пари - около 30 лицензирани субекта. Надзор: БНБ.
• Инвестиционни посредници по ЗПФИ. Надзор: КФН.
• Управляващи дружества и фондове (UCITS, AIF). Надзор: КФН.
• Застрахователи и презастрахователи. Надзор: КФН.
• Пенсионноосигурителни дружества. Надзор: КФН.
• Доставчици на услуги по криптоактиви (CASP) по Регламент МиКА - регистър при БНБ, надзор по координация с ЕЦБ.
• Доставчици на услуги по краудфъндинг (ECSP). Надзор: КФН.
• Централни регистри на ценни книжа, централни контрагенти, борси. Надзор: КФН + БНБ за платежни и сетълмент системи.

Стълб 1. Управление на ИКТ риска (чл. 5-16)

Управителният съвет носи крайната отговорност за ИКТ риска и одобрява писмено рамката за управлението му. Определя се контролна функция, отделена от ежедневната ИТ дейност. Подготвят се политика за информационна сигурност, опис и класификация на активите и функциите, правила за криптиране, достъп и мрежова защита, както и процедури за откриване на заплахи, реакция и възстановяване. За критичните функции се предвижда денонощно наблюдение. Необходими са и анализ на инцидентите, подобряване на мерките, планове за непрекъснатост и възстановяване с цели RTO/RPO и обучение на служителите и управителния съвет. За подготовката на управителния съвет предлагаме обучение по DORA за членове на управителни съвети в нашата BlueTeam Academy. Курсът е на английски.

Стълб 2. Управление, класификация и докладване на ИКТ инциденти (чл. 17-23)

Процес за откриване, класификация и реакция при ИКТ инциденти. Класификацията използва критериите от Делегиран регламент (ЕС) 2024/1772 - брой засегнати клиенти, географски обхват, продължителност, финансова загуба, репутационна щета, икономически и социален ефект. Значителните инциденти се докладват към БНБ или КФН по образец и в три етапа: първоначално уведомление в рамките на 4 часа от класификацията (и не по-късно от 24 часа от момента на узнаване), междинен доклад до 72 часа, окончателен доклад до един месец. Регистър на всички инциденти - не само значителните - се поддържа постоянно и подлежи на проверка. Сериозни киберзаплахи без реализиран инцидент също се докладват доброволно по чл. 19 ал. 2.

Стълб 3. Тестване на дигиталната оперативна устойчивост (чл. 24-27)

Годишната програма за тестване се съобразява с размера и сложността на организацията. Тя обхваща оценки на уязвимости, мрежови тестове, анализ на изходния код на критични приложения, проверки по сценарии, тестове на физическата сигурност и производителността, проверка на инструментите за откриване на заплахи и цялостни тестове на BCP/DRP. Проверките се извършват независимо; вътрешен екип може да ги изпълнява, ако функциите са разделени. За значителните финансови институции, които отговарят на критериите по чл. 24, ал. 3, допълнително се прилагат тестове за проникване, основани на разузнаване за заплахите (TLPT), на всеки 3 години по методологията TIBER-EU и под надзора на БНБ/КФН. БНБ работи по адаптирането на TIBER-EU за българския пазар.

Стълб 4. Управление на ИКТ риска от трети страни (чл. 28-30)

Управителният съвет одобрява стратегия и политика за ИКТ риска, свързан с външни доставчици. Всички договори за ИКТ услуги се вписват в регистъра по чл. 28, ал. 3 в определения формат и се докладват ежегодно на БНБ/КФН. Новите доставчици се проверяват предварително. Всички договори трябва да съдържат клаузите по чл. 30, а за критични или важни функции се предвиждат допълнителни условия: план за прекратяване и прехвърляне на услугата, ограничения за подизпълнители, одит на място, достъп до помещенията и системите и местонахождение на данните. Изпълнението на доставчиците се следи текущо, а зависимостта от ограничен брой доставчици се управлява като отделен риск.

Стълб 5. Споделяне на информация и оперативен надзор на критичните ИКТ доставчици (чл. 31-44, 45)

На равнище ЕС действа режим за определяне на критичните външни доставчици на ИКТ услуги (CTPP) и за прекия им надзор от водещ надзорен орган. Финансовите институции трябва да знаят кои техни доставчици могат да попаднат в тази категория, включително AWS, Microsoft Azure, Google Cloud и големи SaaS платформи, и да поддържат план за прехвърляне на услугите. Член 45 насърчава доброволния обмен на информация за киберзаплахи между финансовите организации. В България се очаква това да става основно чрез CERT-FS на БНБ и FS-ISAC.

Реалистична цена на TLPT за българска банка

Пълният цикъл по TIBER-EU за средно голяма банка струва от 163 613,40 до 296 549,29 евро само за външния екип. Това включва разузнаване за заплахите, определяне на обхвата, изпълнение на сценариите и докладване. Допълнително са необходими около 600-1000 човекочаса от ръководителя по сигурността, възложителите и контролния екип (White Team). За институциите в обхвата на TLPT това трябва да е отделен разход в бюджета за първата година. При текущото управление на програмата DORA модулът на Venvera държи регистъра на информацията, сроковете за докладване и доказателствата от тестването на едно място.

1. „Имаме ISO 27001, значи покриваме DORA“

ISO 27001 покрива по наша оценка около 55-65 на сто от изискванията на DORA. Липсват: регистърът на договорните споразумения по образец, специфичните срокове за докладване на инциденти, задължителните клаузи по чл. 30, стратегиите за прекратяване за критични доставчици, TLPT (където е приложимо), и доказателствата за участие на УС в управлението на ИКТ риска. ISO 27001 е добра основа, но не е DORA.

2. Списък с доставчици в Excel вместо регистър по образец

Регистърът по чл. 28 ал. 3 е структуриран файл в строго определен формат с около 22 задължителни полета на ниво договорно споразумение. Той се подава електронно през канала на БНБ/КФН по образец на Регламент за изпълнение (ЕС) 2024/2956. Excel със 7 колонки „доставчик, услуга, контакт, начало, край, цена, отговорник“ не отговаря на изискването, независимо колко актуален е.

3. „Нашият CIO се занимава с ИКТ риска“

DORA изисква функцията за контрол на ИКТ риска да е отделена от ежедневната ИТ дейност. Директорът по ИТ (CIO), който одобрява архитектурните решения и управлява екипа, не може едновременно да контролира собствените си решения. Необходим е директор по сигурността (CISO) или отговорник за ИКТ риска, който се отчита независимо пред управителния съвет. Малките институции могат да възложат тази функция на външен специалист (vCISO), като възлагането трябва да е документирано.

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

AWS, Microsoft Azure, Google Cloud, Salesforce и големите SaaS доставчици предлагат стандартни анекси по DORA за финансовия сектор. Ако договорът поддържа критична функция, липсата на необходимите допълнителни клаузи може да означава неизпълнение на изискванията. Анексът обикновено е безплатен и трябва да бъде поискан, прегледан и подписан.

5. „24-часовият срок е достатъчен“

Често чуван аргумент: „Имаме общо 24 часа да решим дали инцидентът е значителен и след това още време за уведомление.“ Грешно. След класификацията тръгва нов часовник от 4 часа до първоначалното уведомление. На практика, ако инцидент бъде засечен в 22:00 ч. в петък и класифициран значителен в 02:00 ч. в събота, първоначалното уведомление трябва да тръгне до 06:00 ч. в събота. Нощни и почивни-дневни дежурства не са препоръка - те са оперативна необходимост.

Ние сме платежна институция с 18 служители. Прилага ли се DORA в пълния ѝ обхват?

Не. За микропредприятията — под 10 служители и под 2 млн. евро баланс или оборот — е предвиден облекчен режим по член 16. Платежна институция с 18 служители вероятно не отговаря на този критерий. Принципът на пропорционалност по член 4 позволява мерките да се съобразят с размера, риска и сложността, но изисква обосновано и документирано решение. При финансово-технологичните компании особено внимание изискват API, платежната логика, облачните идентичности и изолацията между клиентските среди; тест за проникване за финтех платформи обхваща именно тези системи и дава констатации, които могат да бъдат възпроизведени и проверени.

Дали БНБ вече реално проверява спазването на DORA?

Да. От втората половина на 2025 г. БНБ и КФН включиха готовността по DORA като отделна точка в надзорните си цикли. От март 2026 г. виждаме целеви искания за регистъра на договорните споразумения, доказателство за процедура за класифициране на инциденти и доказателство за провеждане на годишно тестване. Очаквайте първите формални препоръки за отстраняване по DORA в края на 2026 г., а първите финансови санкции през 2027 г.

Какви глоби могат да се наложат за неспазване на DORA?

DORA не въвежда единна европейска скала за глоби. Санкциите се прилагат по националния режим - в България чрез Закона за БНБ, Закона за кредитните институции, Закона за платежните услуги, Кодекса за застраховането, ЗПФИ, ЗДКИСДПКИ и съответните секторни закони. Размерът зависи от тежестта на нарушението и приложимия секторен закон. Освен фирмената санкция, по Търговския закон членовете на УС могат да носят регресна отговорност при доказана небрежност в управлението.

Използваме AWS за всичко. Те ли носят отговорността по DORA?

Не. Отговорността по DORA остава на финансовата институция и нейния управителен съвет, независимо колко дейности са възложени на външни доставчици. AWS трябва да съдейства, включително по договорните условия и тестовете за устойчивост, но това не заменя вашето управление на ИКТ риска. Определянето на AWS като критичен външен доставчик (CTPP) би довело до отделен европейски надзор над него, без да премахне вашите задължения.

Аз съм CASP по МиКА - DORA приложима ли е към мен?

Да. MiCA и DORA се прилагат паралелно към съответните доставчици на услуги за криптоактиви. Подготовката включва регистър на договорите, управление на ИКТ риска, срокове за докладване и договорни условия с доставчиците на попечителски услуги и блокчейн инфраструктура. Конкретният обхват и изключенията трябва да се проверят за съответната организация.

Допустимо ли е да възложим функцията vCISO на консултантска компания?

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