DORA

Резюме

DORA не е поредният документ за „киберхигиена". Регламент (ЕС) 2022/2554 променя логиката, по която финансовите институции в Европейския съюз доказват, че системите им ще издържат — не при идеален сценарий, а при реален инцидент. Регламентът е в сила от 17 януари 2025 г. и за разлика от директива не изисква национално транспониране: прилага се директно, с еднакви правила за банка в София, застраховател във Франкфурт или инвестиционен посредник в Дъблин. Надзорът у нас се упражнява основно от БНБ и КФН, в зависимост от сектора, в който оперира институцията.

За управленските екипи на банки, застрахователи, инвестиционни посредници, платежни и електронно-парични институции, доставчици на услуги, свързани с крипто-активи, и агенции за кредитен рейтинг това означава едно просто, но неудобно нещо: съответствието вече не се доказва с политика на хартия, а с демонстрирана способност системата да устои, да съобщи и да се възстанови. DORA изгражда тази способност върху пет стълба — управление на ИКТ риска, класификация и докладване на инциденти, тестване на оперативната устойчивост (включително напреднало тестване чрез симулирани атаки за най-значимите институции), управление на риска от доставчици на трети страни и споделяне на информация за киберзаплахи между участниците на пазара.

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

Бизнес ползи

Съответствието с DORA носи стойност отвъд избягването на надзорни мерки. Изградената правилно рамка става оперативен актив — намалява времето за възстановяване след инцидент, дава преговорна позиция спрямо доставчици и изгражда доверие пред партньори, инвеститори и клиенти.

• Намален оперативен риск — систематизираното управление на ИКТ риска открива слабостите, преди те да прераснат в прекъсване на услуга или загуба на данни.
• По-бързо възстановяване след инцидент — ясни процедури за класификация, ескалация и докладване съкращават времето между откриване и овладяване на проблема.
• По-силна позиция при преговори с доставчици — регистърът на ИКТ договори и стандартизираните клаузи дават на институцията лост при договаряне на условия с облачни и технологични партньори.
• По-ниска зависимост от единични доставчици — картографирането на концентрационния риск разкрива критични точки на отказ, които иначе остават невидими до момента на срив.
• Доверие пред регулатора и пазара — демонстрираната зрялост при надзорни проверки съкращава цикъла на комуникация с БНБ или КФН и намалява риска от предписания и санкции.
• Подготвеност за реален инцидент, не само за одит — тестовете на устойчивостта създават практически опит, който политиките сами по себе си не дават.
• Основа за бъдещ растеж — институция с работеща рамка за ИКТ риск интегрира по-лесно нови продукти, партньорства и технологии, без всеки път да презастроява основите.

Обхват

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

• Кредитни институции (банки) и инвестиционни посредници.
• Застрахователи, презастрахователи и застрахователни посредници.
• Платежни институции и институции за електронни пари.
• Доставчици на услуги, свързани с крипто-активи, и емитенти на токени, обезпечени с активи.
• Управляващи дружества, инвестиционни фондове и пенсионноосигурителни дружества.
• Агенции за кредитен рейтинг и одиторски дружества, доколкото попадат в обхвата на регламента.
• Критични доставчици на ИКТ услуги на трети страни — облачни платформи, доставчици на софтуер, центрове за данни — доколкото обслужват финансови институции в обхват на DORA.

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

Методология

Подходът ни към DORA е поетапен, защото регламентът изисква едновременно документална, техническа и договорна работа — а бързането в която и да е от тях създава пропуски, които излизат наяве точно при надзорна проверка или реален инцидент.

Фаза 1: Анализ на текущото състояние и картографиране на пропуските. Преглеждаме съществуващата рамка за управление на ИКТ риска, политиките за непрекъснатост на дейността, регистъра на доставчици и историята на инцидентите. Сравняваме резултата с изискванията на петте стълба на DORA и излизаме с конкретен списък от пропуски, приоритизиран по риск и по регулаторна тежест.

Фаза 2: Изграждане на рамката за управление на ИКТ риска. Разработваме или коригираме политиките, ролите и отговорностите, включително ясно разпределение на отговорността на ниво управителен орган — DORA поставя изрично изискване управлението и надзорът на ИКТ риска да са ангажимент на висшето ръководство, не само на ИТ отдела.

Фаза 3: Процедури за инциденти и програма за тестване. Изграждаме процеса за класификация, ескалация и докладване на съществени ИКТ инциденти в сроковете, изисквани от регламента, и проектираме програма за тестване на устойчивостта — от базови сценарии до, при нужда, тестове от типа „насочено тестване чрез симулирана заплаха" (TLPT) за институциите, попадащи в обхвата на това по-строго изискване.

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

Фаза 5: Валидиране, обучение и предаване. Провеждаме вътрешен преглед на цялата рамка, обучаваме отговорните екипи да я поддържат самостоятелно и предаваме документацията във вид, готов за представяне пред БНБ, КФН или вътрешен одит. При желание от страна на клиента остава наличен и след приключване на проекта за периодични прегледи и актуализации.

Резултати

Излизате от ангажимента с работеща, документирана и защитима рамка за оперативна устойчивост — не с папка политики, които никой не отваря след одита.

• Актуализирана рамка за управление на ИКТ риска, одобрена и разбрана от управителния орган на институцията.
• Процедури за класификация, ескалация и докладване на съществени ИКТ инциденти, съответстващи на сроковете по DORA.
• Програма за тестване на оперативната устойчивост, съобразена с профила на риска и размера на институцията.
• Пълен регистър на информацията за договорните отношения с ИКТ доставчици на трети страни.
• Прегледани и, при необходимост, предоговорени договори с критични доставчици, съдържащи изискваните договорни клаузи.
• Оценка на концентрационния риск при доставчици и план за намаляване на зависимостта от единични точки на отказ.
• Готовност за надзорна проверка от страна на БНБ или КФН, включително документация, съответстваща на изискванията за доказване на съответствие.

Често задавани въпроси

Имаме сертификат по ISO 27001 — това достатъчно ли е за DORA?

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

Трябва ли ни задължително TLPT (Threat-Led Penetration Testing)?

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

Какво точно прави един ИКТ доставчик „критичен" по смисъла на DORA?

Статутът „критичен" се определя не от самата институция, а чрез процес на надзор на европейско ниво, който отчита фактори като степента на зависимост на финансовия сектор от доставчика, заменяемостта му, броя институции, които го използват, и потенциалното системно въздействие при прекъсване на услугата му. На практика големи облачни доставчици и определени технологични платформи попадат в тази категория. За институциите обаче практическото значение е по-широко — независимо от официалния статут, всеки доставчик с висока степен на зависимост трябва да бъде картографиран, оценен за концентрационен риск и обвързан с договорните клаузи, изисквани от регламента.

Каква е разликата между DORA и NIS2 — не се ли препокриват?

Двата регламента действително имат обща логика — управление на риска, докладване на инциденти, отговорност на ръководството — но обхватът и приложението им се различават. NIS2 е директива с по-широк секторен обхват (енергетика, здравеопазване, транспорт, дигитална инфраструктура и други), която изисква национално транспониране и оставя известна гъвкавост на държавите членки. DORA е регламент, специфичен за финансовия сектор, директно приложим без транспониране, с по-детайлни и технически конкретни изисквания — включително по отношение на тестването и договорните отношения с доставчици. За финансова институция, която формално попада и в двата обхвата, DORA действа като специализиран регламент (lex specialis) — прилагат се неговите по-строги и по-конкретни изисквания. Не е нужно да изграждате две паралелни рамки.

От кога тече отговорността — регламентът вече в сила ли е?

Да. DORA се прилага от 17 януари 2025 г. и за институциите, попадащи в обхвата му, задълженията не са в преходен период — те са текущи. Ако към момента нямате изградена рамка, покриваща петте стълба на регламента, това вече представлява пропуск, който подлежи на установяване при надзорна проверка. Приоритетът в такъв случай е бързо картографиране на най-съществените пропуски — управление на инциденти и договорни клаузи с доставчици обикновено носят най-непосредствен риск — преди по-дългосрочна работа по цялостната рамка.

Кой в организацията носи отговорност за DORA — ИТ отделът или ръководството?

Регламентът е изричен по този въпрос: управителният орган на институцията носи пряка отговорност за одобряването, надзора и периодичния преглед на рамката за управление на ИКТ риска. Това не е делегируемо изцяло на ИТ или информационна сигурност. На практика това означава, че документацията, отчетността и обучението трябва да бъдат структурирани така, че членовете на управителния орган да разбират реалния рисков профил на институцията и да могат да го защитят пред регулатор — не просто да подпишат политика, изготвена от друг отдел. Част от нашия ангажимент включва именно подготовка на управленския екип за тази роля.

Отнася ли се DORA за по-малки застрахователни агенти и небанкови финансови посредници?

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

Следващата стъпка

Ако все още не сте сигурни доколко текущата ви организация покрива петте стълба на DORA, това несигурност само по себе си е сигнал — регламентът е в сила и надзорните органи вече го прилагат на практика, не на теория. Колкото по-рано картографирате пропуските, толкова по-контролиран е процесът на затварянето им, вместо да реагирате под натиска на предстояща проверка или на реален инцидент.

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