DORA изисквания за финансови компании в България

На 17 януари 2025 г. DORA започна да се прилага пряко в Европейския съюз. За засегнатите организации това означава, че DORA изисквания за финансови компании вече не са проект за бъдеща подготовка, а оперативен ангажимент към управлението, IT екипа, риска, вътрешния контрол и външните доставчици. Регламентът не се изчерпва с внедряване на нова система за сигурност. Той изисква доказуем модел, с който организацията предотвратява, открива, управлява и възстановява дейността си след ИКТ инцидент.

DORA – Регламентът за цифрова оперативна устойчивост – поставя фокуса върху способността на финансовата организация да предоставя критичните си услуги и при технологичен проблем, кибератака, прекъсване на облачна услуга или отказ на доставчик. Точно тук се срещат киберсигурността, резервното копиране, управлението на доставчиците, вътрешните политики и документацията.

Кои организации попадат в обхвата на DORA

DORA се прилага за широк кръг финансови субекти: кредитни институции, платежни и дружества за електронни пари, инвестиционни посредници, управляващи дружества, застрахователни и презастрахователни компании, пенсионни фондове, определени доставчици на услуги, свързани с криптоактиви, и други изрично посочени категории. Точният обхват зависи от правния статут и лиценза на конкретната организация.

Малките компании не следва автоматично да приемат, че са извън регламента. DORA прилага принципа на пропорционалност – мерките трябва да съответстват на мащаба, рисковия профил и сложността на дейността. Това обаче не е освобождаване от отговорност. По-малката организация може да има по-лека рамка, но тя трябва да е реално въведена, управлявана и проверима.

ИТ доставчиците, които работят с финансовия сектор, също са засегнати. Дори когато не са пряк адресат на всички задължения по DORA, техните договори, нива на обслужване, мерки за защита и възможности за възстановяване ще бъдат предмет на по-строг контрол от страна на финансовите им клиенти.

DORA изисквания за финансови компании: пет управленски области

Регламентът обхваща няколко свързани направления. Най-честата грешка е те да се разглеждат като самостоятелни IT задачи. На практика всяко направление изисква управленско решение, техническо изпълнение, процедура и доказателство, че процесът работи.

1. Управление на ИКТ риска

Ръководният орган носи отговорност за цифровата оперативна устойчивост. Това означава управителите и членовете на управителните структури да познават съществените ИКТ рискове, да одобряват политиките и да получават периодична информация за тяхното състояние. Отговорността не може да бъде прехвърлена изцяло на външен IT доставчик или на един системен администратор.

Практическата основа е актуален регистър на информационните активи: системи, данни, крайни устройства, интеграции, потребители, доставчици и зависимости. За всяка критична услуга трябва да е ясно какво я поддържа, кой има достъп, къде се съхраняват данните и какво би се случило при прекъсване.

Следват анализ на риска, правила за контрол на достъпа, управление на уязвимостите, криптиране, сегментация на мрежата, наблюдение на събитията и управление на промените. Технология без процес оставя пропуск. Същото важи и за политика, която не е подкрепена с конкретни настройки, логове и отговорни лица.

2. Управление и докладване на ИКТ инциденти

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

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

Важен е и последващият анализ. Ако една атака е спряла достъпа до документи или платежна система, организацията трябва да установи не само как да възстанови услугата, а защо контролите не са предотвратили или ограничили проблема. Така регистърът на инцидентите се превръща в инструмент за реално намаляване на риска.

3. Непрекъсваемост, архивиране и възстановяване

Резервното копие само по себе си не доказва оперативна устойчивост. Критичният въпрос е дали данните могат да бъдат възстановени в необходимия срок и дали възстановената система ще работи коректно с останалите приложения, права за достъп и интеграции.

Затова плановете за непрекъсваемост и възстановяване при бедствие трябва да съдържат ясни цели за време за възстановяване и допустима загуба на данни. Те трябва да се базират на бизнес анализ: кои процеси са критични, какъв е приемливият период на прекъсване и какви са последствията за клиентите и регулаторните задължения.

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

4. Тестване на цифровата оперативна устойчивост

DORA изисква периодично тестване, което да потвърждава дали защитата и плановете за реакция работят при реалистични сценарии. Обхватът може да включва проверки за уязвимости, сканирания, тестове за проникване, сценарии за прекъсване, симулации на фишинг и упражнения за реакция при инцидент.

За определени субекти с по-висока системна значимост се предвижда и усъвършенствано тестване чрез контролирано проникване, базирано на анализ на заплахите. То не се прилага еднакво за всяка финансова компания. Независимо от това, всеки засегнат субект трябва да може да покаже, че проверява ключовите си контроли, а не разчита на предположения.

5. Риск от външни ИКТ доставчици

Облачните платформи, доставчиците на софтуер, центровете за данни, външната поддръжка и доставчиците на архивиране са част от оперативната устойчивост на финансовата организация. Затова DORA изисква формализирано управление на риска от трети страни.

Първата стъпка е пълен регистър на ИКТ договорите и услугите. След това трябва да се определи кои доставчици поддържат критични или важни функции. За тях договорите следва да уреждат изискванията за сигурност, местоположението и обработването на данните, уведомяването при инцидент, правата за одит и достъп, условията за подизпълнители, нивата на обслужване и възможностите за прекратяване или миграция.

Тук има реален компромис между удобството на една централизирана платформа и риска от зависимост от един доставчик. Не всяка услуга изисква сложна мултиоблачна архитектура. Но за критичните функции трябва да има реалистичен изходен план, проверени резервни варианти и достатъчно контрол върху данните.

Как да започне подготовката без формален подход

Най-ефективният старт не е закупуването на произволен инструмент, а оценка на текущото състояние. Тя трябва да съпостави наличните технически контроли, договори и вътрешни документи с конкретните изисквания на DORA. Полезният резултат е приоритизиран план с отговорник, срок, бюджет и измерим критерий за завършване.

Практическият план обикновено следва пет последователни действия:

• определяне на обхвата, критичните услуги и отговорните управленски роли;
• инвентаризация на системите, данните, интеграциите и ИКТ доставчиците;
• анализ на пропуските в риска, инцидентите, архивирането, тестовете и договорите;
• внедряване на технически и организационни мерки с актуализирани регистри и процедури;
• периодични тестове, прегледи от ръководството и проследяване на коригиращите действия.

Документацията не трябва да се създава само за проверка. Ако регистърът на активите, планът за възстановяване или процедурата за инциденти не помагат на екипа да вземе решение в напрегнат момент, те не изпълняват основната си функция.

За организации без вътрешен екип с достатъчен капацитет външен партньор може да обедини техническата защита, архивирането, тестовете и compliance документацията. Подходът на Буллсофт е именно такъв: технологичните мерки се свързват с работещи политики, регистри и доказателства за изпълнение, вместо да се оставят като отделни инициативи.

Най-полезната следваща стъпка е да се избере една критична услуга и да се проследи нейният път от данните и потребителите до доставчиците и възстановяването. Там обикновено се вижда дали организацията разполага с действителна оперативна устойчивост, или само с набор от отделни защитни решения.