DORA изисквания: петте стълба, член 6(4) и регистърът на информацията

Едно разграничение в началото: DORA е регламент, не директива. Прилага се пряко, без да чака транспониране в български закон. Това означава, че текстът, който четете в Регламент (ЕС) 2022/2554, е задължението ви, а националното законодателство урежда основно надзора и санкциите.

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

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

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

Презентация за готовност не отговаря на въпроса кой носи функцията. Отговаря конкретно назначен човек.

Практическият прочит на член 6(4), който използваме при подготовка за надзорен диалог

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

Въпросите са обобщени от подготовка за надзорен диалог. Не са официален въпросник и не са правен съвет.

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

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

Трите места, на които регистърът се къса

1. Веригата от подизпълнители

   Знаете кой е вашият доставчик. Рядко знаете на кого той възлага. При инцидент точно този слой се оказва решаващ и точно него никой не е описал.

2. Определянето на критична или важна функция

   Това не е техническо, а бизнес решение, и трябва да е взето от някого с правомощия, а не подразбрано от ИТ.

3. Плановете за изход

   Изискват се и се проверяват. Изречение „ще мигрираме при нужда" не е план за изход. План е описание колко време отнема, какво струва и кой го изпълнява.

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

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

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

Практическото следствие: ако не сте определени, не купувайте TLPT. Той е значително по-скъп от обикновен тест за проникване, изисква контролен екип от ваша страна и разузнаване за заплахи, и е проектиран за друга цел. В България режимът за атестация на TLPT е в сила от юли 2025 г.

Преди всяко техническо решение стои административният въпрос: под кой орган попадате и каква пропорционалност ви се полага. Отговорът определя обхвата на цялата работа и е половин ден, който спестява месеци в грешна посока.

Микропредприятията имат облекчен режим по редица изисквания, включително по член 6(4). Това не ги изважда от обхвата, а намалява обема. Определението за микропредприятие по DORA се проверява в регламента, а не по общото счетоводно понятие.

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

Обобщение за ориентация. Точните изисквания и разликата за критични функции са в член 30 от регламента. Подробен разбор в отделната статия.

След като регистърът е готов, той започва да отговаря на въпрос, който преди това никой не е могъл да зададе: колко от критичните ви функции зависят от един и същи доставчик, или по-неприятното, от един и същи подизпълнител на различни доставчици.

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

1. Групирайте по доставчик

   Кои критични или важни функции зависят от всеки доставчик поотделно.

2. Групирайте по подизпълнител

   Това е стъпката, която повечето регистри не позволяват, защото липсва веригата.

3. Групирайте по местоположение

   Един регион, един център за данни, една държава. Географията е риск.

4. Оценете сценария на загуба

   Какво спира, ако този доставчик е недостъпен за седмица, и колко струва.

5. Напишете плана за изход

   Срок, разходи, отговорник. Планът за изход е доказателство, не намерение.

Въпросът идва на всяка втора среща, особено от финтех компании. Краткият отговор е, че DORA е lex specialis за финансовия сектор и има предимство пред NIS2 за въпросите, които урежда.

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

1. Статут, надзорник, пропорционалност

   Вид субект, размер, кой орган. Документирано решение, не устна договорка.

2. Контролната функция по член 6(4)

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

3. Рамка и политики за ИКТ риск

   Основата, спрямо която се определя кое е критична функция и кой инцидент е значим.

4. Регистърът, съгласуван с договорите

   Не по памет. Изважда се от деловодството и се сверява ред по ред.

5. Режим за инциденти и учение

   Матрица, шаблони, правомощия, и едно проведено учение със запис.

6. Календар за тестване

   Годишна програма за всички, TLPT само ако сте определени.

7. Тримесечно отчитане

   Съответствието по DORA не е проект със срок, а функция, която работи постоянно.

От кога точно се прилага DORA?

От 17 януари 2025 г. Регламентът се прилага пряко, без да чака национално транспониране, така че надзорните очаквания вече са актуални.

Може ли нашият ИТ доставчик да държи функцията по член 6(4)?

Трудно е да се обоснове. Член 6(4) иска подходящо ниво на независимост, за да се избегнат конфликти на интереси, а доставчик, който оперира вашата среда, би оспорвал собствената си работа. Обикновено функцията се възлага на страна без оперативна отговорност за ИТ.

Имаме ISO 27001. Колко от DORA покрива?

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

Всички ли дължим TLPT?

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

Ние сме ИКТ доставчик, а не финансов субект. Засяга ли ни DORA?

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

Какво се проверява първо при надзорен диалог?

По нашия опит: кой държи функцията по член 6(4), може ли регистърът да бъде представен веднага, и има ли запис, че управителният орган е одобрил рамката. Трите отговора се дават за минути, ако работата е свършена, и не се дават изобщо, ако не е.

Кой държи вашата функция по член 6(4)?

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