За какво служи регистърът от гледна точка на надзора
Регистърът подпомага собственото управление на риска от трети страни и обобщаването на данни от надзора.
Европейските надзорни органи събират регистрите през националните компетентни органи и използват съвкупността, за да видят от кои доставчици на ИКТ (информационни и комуникационни технологии) услуги зависи реално европейският финансов сектор. Това не е теория за файловия формат. На 18 ноември 2025 г. те публикуваха първия списък с определените критични трети страни доставчици на ИКТ услуги и изрично посочиха, че упражнението е започнало с данни, събрани от регистрите на информацията, поддържани от финансовите субекти.
Използвайте идентификатора и вида, изисквани от образеца. Доставчици юридически лица от ЕС могат да използват валиден активен LEI или EUID; юридически лица извън ЕС използват LEI. За физически лица, действащи в търговско качество, има предвидени алтернативи. Подайте и LEI, и EUID, когато се изискват и са налични. Следвайте актуалния технически пакет на органа, вместо да измисляте колони или формат.
Чл. 28, параграф 3 изисква и нещо, което не е годишният файл. Уведомявате своевременно компетентния надзорен орган за планирано договорно споразумение за ИКТ услуги, които поддържат критична или важна функция, както и когато дадена функция е станала критична или важна. Точно това се пропуска, защото се задейства от събитие и обикновено няма отговорник.
Отделно за малките субекти. Опростената рамка за управление на риска за ИКТ по чл. 16 изключва прилагането на чл. 5 — 15 за малките и невзаимосвързани инвестиционни посредници, за освободените платежни институции и институции за електронни пари и за малките ИППО. Чл. 28 не е в този списък. Регистърът не влиза в облекчението.
Петнадесет образеца и връзките между тях
Структурата е релационна и точно това изненадва хората, на които са казали „попълни една таблица“. Договорно споразумение от един образец се посочва с ключ в друг. Доставчик, идентифициран в една таблица, трябва да е същият доставчик, посочен навсякъде другаде. Оттук идва и най-честият клас грешка: препратка към запис, който не съществува в другия образец. Нищо не изглежда празно при четене — счупена е връзката.
Две правила за обхват си струва да се запомнят, защото пестят работа. Всички преки доставчици влизат. Подизпълнителите влизат само когато реално стоят в основата на ИКТ услуги, поддържащи критични или важни функции, или съществени части от тях — не дължите на надзора карта на целия интернет. Редът във веригата на доставка също е фиксиран: прекият доставчик винаги е ред 1, подизпълнителят винаги е по-висок от 1.
| Блок | Какво съдържа | Обичаен източник във фирмата | Примерен дефект или проверка |
|---|---|---|---|
| B_01.01 — B_01.03 | Субектът, който поддържа регистъра, субектите в обхвата на консолидацията, клоновете | Правен отдел, корпоративен секретар | Пропуснати клонове; изтекъл LEI на самия субект в GLEIF |
| B_02.01 | Договорни отношения: общи номера, вид, валута и годишен разход или прогнозна стойност | Архив на договорите | Номер или разход, несъгласуван с договора и финансовите записи |
| B_02.02 | Специфична информация за ИКТ договорните отношения: дати, предизвестия, право и места; не само за критични функции | Правен отдел и финанси | Дати или места, несъгласувани с договора и информацията от доставчика |
| B_02.03 | Вътрешногрупови договорни споразумения | Групата, дружеството майка | Пропуснати изцяло, защото „това сме ние“ |
| B_03.01 — B_03.03 | Кой подписва: Вашите субекти, доставчикът, субекти, които предоставят услуги на други в групата | Правен отдел | Подписващият субект се бърка със субекта, който ползва услугата |
| B_04.01 | Кои Ваши субекти реално ползват всяка ИКТ услуга | Бизнес отговорниците | Един ред за групата там, където услугата се ползва от три дъщерни дружества |
| B_05.01 | Самата трета страна доставчик на ИКТ услуги | Доставки, управление на доставчици | Един и същ доставчик, вписан три пъти под три имена |
| B_05.02 | Веригата на доставчиците на ИКТ услуги и мястото на всеки в нея | Въпросници до доставчиците | Попълнен ред 1 и нищо зад него при услуги, които очевидно се препродават |
| B_06.01 | Идентифициране на функциите и оценката на критичността | Риск, непрекъснатост на дейността | „Критична“ без записан метод и без дата на оценката |
| B_07.01 | Оценка на ИКТ услуги, поддържащи критични или важни функции | Риск и ИТ | Липсващи изискуеми полета за оценката на услуга за критична или важна функция |
| B_99.01 | Собствени определения и пояснения на субекта, когато са приложими | Обикновено никой | Вътрешни термини, използвани другаде без изискуемото от образеца пояснение |
Къде наистина се бърка
Пилотното упражнение на европейските надзорни органи през 2024 г. установява проблеми с качеството на подадени регистри. Използвайте го като основание да предвидите време за валидация, а не като доказателство, че даден модел на грешки описва всеки актуален регистър.
Идентификатори, които трябва да съвпадат и не съвпадат. LEI се проверява срещу базата на GLEIF, така че неподновен LEI не минава проверката, както и ЕИК, вписан в полето за LEI. После идва по-трудният вариант: подизпълнител три нива по-надолу, когото сте длъжни да идентифицирате, а нямате нито договор с него, нито контакт, нито основание да сте в системите му. Пишете на прекия доставчик и пазите отговора.
Критичност, определена по метод, който никой не е записал. DORA (регламент на ЕС за цифровата оперативна устойчивост на финансовия сектор) дефинира критична или важна функция в чл. 3, точка 22 през ефекта от нейното нарушаване. Делегиран регламент (ЕС) 2024/1773 изисква политиката Ви да установява или да препраща към методика кои ИКТ услуги поддържат такива функции и да казва кога се прави и преразглежда оценката. На практика регистърът често е първото място, където се появява маркировката за критичност — сложена от онзи, който попълва файла, в следобеда преди срока. След това тази маркировка задейства договорни изисквания, планиране на прекратяване или смяна на доставчика и уведомления. Първо напишете метода, дори да е една страница.
Един и същ доставчик, три пъти, под три имена. Наименование по договор, търговско име в ИТ инвентара, каквото пише във фактурата в счетоводството. Съгласувайте по идентификатор и неговия вид, включително допълнителните идентификатори, когато са налични; не обединявайте само по търговско име.
Договори, които съществуват в „Доставки“, но не и в регистъра. SaaS с автоматично подновяване, платен с карта; инструмент, който екипът е взел и е минал през разходите; услуга, дошла като част от по-голяма сделка. Обхватът се определя от това дали е ИКТ услуга, а не от това дали някой я е забелязал.
Пропуснати вътрешногрупови споразумения. За тях има отделен образец. Ако споделеният център на групата поддържа основната Ви платформа, това е ИКТ услуга по договорно споразумение, а общият собственик на капитала не е основание за изключване от обхвата.
Данни в пет системи, за които отговарят четири отдела. Договорите са в правния отдел, разходите — във финансите, реалният списък със системи — в ИТ, отговорността за функциите — в бизнеса, критичността — в риска. Нищо от това не е съгласувано, защото досега нищо не е принуждавало съгласуване. Това е честната причина първият регистър да отнема месеци, а вторият — дни.
Какво може да се използва повторно и какво остава за ръчна обработка
Наистина може да се използва повторно: архивът на договорите дава номера, страни, срокове, предизвестия и приложимо право. Разчетите с доставчици намират споразуменията, които правният отдел никога не е виждал — сверете ги със списъка на договорите и разликата е Вашият отчет за липсващите договори. Инвентарът на активите показва какво реално работи. Анализът на въздействието върху дейността, ако го поддържате за непрекъснатост, вече съдържа функциите и данни, от които може да се определи критичността. Регистърът на обработващите по ОРЗД (Общ регламент относно защитата на данните) се припокрива силно с таблицата на доставчиците и обикновено вече носи вярното юридическо наименование и местоположенията.
Автоматизирайте механичните проверки: LEI спрямо GLEIF, допустими стойности, липсващи ключове и връзки между образците. Отговорните хора продължават да проверяват бизнес смисъла, критичността и връзката услуга–функция. Изискайте липсващите доказателства по веригата чрез прекия доставчик, както е описано в ръководството за доставчик на банка. Инструмент може да съгласува данни; не може да направи необоснована бизнес класификация надеждна.
Самото подаване
Проверете актуалните указания на компетентния орган: обхват, отчетна дата, формат, валидация и краен срок. Годишното събиране не е единствената причина основният регистър да се актуализира.
Съобщението на КФН от 5 март 2026 г. показва разликата между националните и европейските дати: периодът за подаване в реалната среда на европейските надзорни органи е от 25 февруари до 31 март 2026 г.; КФН иска регистрите до 23 март, за да осигури препращането, с корекции към европейските органи до 30 април. Това са исторически дати за конкретния цикъл, а не срокът за следващото Ви подаване.
Пазете подадената версия, резултата от валидацията, потвърждението и корекциите. Определете кой отстранява отхвърлените записи и поддържа изходните данни след подаването.
Какво да направите първо
- Съгласувайте договорите, плащанията и реалния инвентар на услугите. Изследвайте разликите; не всяко плащане само по себе си е договорно отношение за ИКТ услуга.
- Установете идентификаторите на доставчиците и техния вид с доказателства за правилното юридическо лице.
- Одобрете методиката за критичност и я приложете към функциите и услугите.
- Получете нужната информация за подизпълнителите чрез преките доставчици.
- Изпълнете актуалните проверки и прегледайте бизнес смисъла на резултатите.
- Уредете актуализациите и уведомяването при събития, включително планирани отношения за критични или важни функции.
Ръководството за доказателства по DORA свързва регистъра с договори, тестове, решения и планиране на прекратяването или смяната на доставчика.
При отхвърлено подаване практическият пример за валидация показва как да проследите грешката до източника и да запишете корекцията.
При вече съществуващ регистър можете да възложите отделна проверка и корекция на регистъра, с договорени формат, обхват и повторни проверки.
Какво валидацията не показва
Преминатата валидация означава, че файлът Ви е коректно съставен. Тя не казва нищо за това дали управлението на риска от трети страни доставчици на ИКТ услуги е адекватно, а регистър без технически грешки може да съдържа договори с недостатъчни клаузи. Договорните изисквания по чл. 28 и чл. 30, стратегиите за изход и тестването са отделни задължения с отделни доказателства. Дали конкретно споразумение е в обхвата и дали субектът Ви попада в опростената рамка по чл. 16 зависи от лиценза Ви и е въпрос към компетентния надзорен орган и към Вашия юрист. Ако попадате и в националния режим по киберсигурност, взаимодействието е разгледано в основната статия за DORA и NIS2 и в бележката за NIS2 в България.
Ако искате регистърът да бъде направен веднъж, както трябва, и предаден заедно със съгласуването зад него, това е работата по DORA, която вършим за финансовите субекти.
Обща информация, не правен съвет. Какво се отнася за Вас зависи от субекта, дейността, лиценза, размера, груповата структура и националното прилагане.