Научете
Искам да съм честен с вас за нещо още в началото: няма нито един документ от EBA, ESMA или EIOPA, който да ви казва на едно място всичко, което трябва да знаете за DORA Register of Information. Изискванията са разпръснати из основния текст на DORA, съвместните технически стандарти, ITS относно регистрите на информацията, документацията на xBRL таксономията, специфичните указания за портала на всеки NCA и поредица от въпроси и отговори, публикувани от ESAs в отговор на въпроси от индустрията, някои от които изясняват неща, които оригиналните текстове оставиха действително двусмислени.
Това ръководство е документът, за който ми се искаше да съществува, когато екипите по съответствие започнаха работа по първите си подавания. То събира всичко на едно място: какво всъщност представлява Register of Information, кой трябва да го подава, какви данни влизат във всеки от неговите 15 официални образеца, как образците се свързват помежду си, как изглежда процесът по подаване от начало до край и как изглежда целогодишната поддръжка, след като първото ви подаване е зад гърба ви.
Докато свършите с четенето, ще имате пълен мисловен модел на RoI, достатъчен не само да попълните образец, а и да разберете защо съществува всяко поле, какво се опитва да види регулаторът и къде са капаните за екипите, които минават през това за първи път.
КорекцияКоригирано на 13 юли 2026 г.: по-ранно обобщение от B00 до B14 беше заменено с официалната структура на образците от B_01.01 до B_99.01 от Регламент за изпълнение (ЕС) 2024/2956 на Комисията.
📋 Какво разглежда това ръководство: Правното основание и целта на Register of Information, кой трябва да подава и на какво ниво, разбивка на модела на данните образец по образец, процесът по подаване и изискванията към формата, задълженията за текуща поддръжка и най-честите грешки, които екипите правят, когато изграждат регистъра си за първи път.
📌 Към раздел
⚡ Накратко
DORA Register of Information е структуриран релационен набор от данни, който обхваща вашите ICT доставчици от трети страни, договорите, услугите и връзките им с вашите критични вътрешни функции. Той трябва да се подава на вашия NCA ежегодно във формат xBRL-CSV. Той представлява конкретен регулаторен отчетен изход, изграден от 15 взаимосвързани образеца, определени в Регламент за изпълнение (ЕС) 2024/2956 на Комисията, а не списък с доставчици, регистър на риска или рамка от контроли. Броят на активните валидационни правила зависи от версията на таксономията и на отчетния пакет; това ръководство беше проверено спрямо версията, отбелязана по-долу. Управлението му в Excel е възможно за малки регистри, но се разпада бързо с нарастването на сложността.
Какво представлява DORA Register of Information?
Register of Information (RoI) е едно от централните оперативни изисквания на Digital Operational Resilience Act. Той е дефиниран в Article 28(3) от DORA, с подробни технически спецификации, определени в Implementing Technical Standards (ITS) относно регистрите на информацията, публикувани съвместно от EBA, ESMA и EIOPA.
В основата си RoI е изчерпателен структуриран запис на всеки ICT доставчик на услуги от трета страна, на който разчита вашата организация, както и прецизно съпоставяне на това какво правят тези доставчици, кои договори уреждат отношенията и кои от вашите вътрешни бизнес функции зависят от техните услуги. Регулаторите използват тези данни за две основни цели: да разберат концентрацията на риск в цялата финансова система (ако един облачен доставчик се срине, кои институции са засегнати и колко тежко?) и да оценят оперативната устойчивост и управлението на риска от трети страни на отделните институции.
Не по-малко важно е да се разбере какво RoI не е. RoI не е:
- Регистър на риска от доставчици - той не съдържа рискови оценки, рискови рейтинги или мерки за смекчаване на риска за всеки доставчик. Това е отделно задължение по DORA.
- Система за управление на договори - той съдържа конкретни структурирани полета с данни за договорите, но не е хранилище на документи за самите договори.
- Рамка от контроли за съответствие - той не проследява дали сте внедрили изискваните контроли за ICT сигурност. Това е вашата рамка за управление на риска за ICT по Articles 5-15.
- Еднократен одитен артефакт - той е жив регистър, който трябва да се поддържа непрекъснато и да се актуализира в определени срокове при всяка съществена промяна.
⚠️ Често срещано погрешно схващане
Много екипи по съответствие първоначално подхождат към RoI като към разширение на съществуващата си програма за управление на риска от трети страни, тоест по същество като структуриран експорт на техния регистър на доставчиците. Това води до проблеми. RoI има специфичен релационен модел на данните със задължителни полета и зависимости между таблиците, които не се съпоставят чисто върху списъци с доставчици, изградени за целите на вътрешното управление на риска. Правилното изграждане на RoI изисква да се тръгне от модела на данните на DORA, вместо от съществуващите ви данни за доставчици.
Кой трябва да подава и на какво ниво?
Article 28(3) от DORA изисква всички финансови субекти в обхвата на регламента да поддържат и подават Register of Information. Пълният списък на субектите в обхвата е определен в Article 2(1) и включва:
🏦 Кредитни институции
💳 Платежни институции
📈 Инвестиционни посредници
🪙 Доставчици на услуги за криптоактиви
🛡️ Застрахователни предприятия
📊 Централни контрагенти
🏛️ Регистри на трансакции
📋 Управляващи дружества
Микропредприятията, определени в правото на ЕС като субекти с по-малко от 10 служители и годишен оборот под 2 милиона евро, се ползват от разпоредбите за пропорционалност в цялата DORA. Как пропорционалността се прилага към Register of Information зависи от вашия тип субект, затова проверете указанията на ESAs за пропорционалността и инструкциите на вашия NCA за вашия конкретен случай, преди да решите какво трябва да подадете.
Индивидуални, подконсолидирани и консолидирани подавания
За финансовите групи ITS определя три възможни нива на подаване. Разбирането кое от тях се отнася за вашата структура е съществено, преди да започнете да изграждате регистъра си, защото отговорът определя обхвата на данните, които трябва да съберете, и как субектите в групата се отнасят един към друг в модела на данните.
| Ниво на подаване | Кой подава | Какво обхваща | Ключови съображения |
|---|---|---|---|
| Индивидуално | Всяко юридическо лице в обхвата | Само ICT договореностите на този субект | Изискване по подразбиране за всички субекти в обхвата; самостоятелните дружества винаги подават на това ниво |
| Подконсолидирано | Предприятие майка на подгрупа | ICT договореностите на субектите от подгрупата, взети заедно | Прилага се, когато предприятието майка на подгрупата само по себе си е финансов субект в обхвата; данните трябва да се агрегират през всички дъщерни дружества в обхвата |
| Консолидирано | Крайното предприятие майка в ЕС | Всички субекти в обхвата в цялата група | Най-сложното: изисква хармонизирано събиране на данни през всички юрисдикции и типове субекти в групата; всеки субект е изброен в образеца за обхвата на консолидацията (B_01.02), който отразява ролята му в структурата на групата |
Групите може да се наложи да произведат и трите нива едновременно: индивидуални подавания от всеки субект, подконсолидирани подавания от предприятията майки на подгрупите и консолидирано подаване от крайното предприятие майка в ЕС. Всяко подаване трябва да бъде свързан, вътрешно последователен пакет от данни, който преминава валидацията самостоятелно.
Моделът на данните: 15-те образеца, обяснени
Изтегляне: DORA Register of Information: 15-те официални образеца (CSV) - код, официално име, предназначение, група, първичен ключ и ключови връзки за всеки образец, приведени в съответствие с Регламент за изпълнение (ЕС) 2024/2956 на Комисията.
Моделът на данните на RoI е сърцето на изискването и частта, която повечето ръководства и образци обясняват най-зле. Правилното му разбиране, тоест не само какво съдържа всеки образец, но и как образците се свързват помежду си, е това, което отличава екипите, които изграждат регистъра правилно от първия път, от екипите, които прекарват месеци в цикъл от повторни подавания.
Отделете един ден за модела, преди да съберете дори едно поле. Това е малка схема, която може да се научи, а щом можете да нарисувате връзките на бяла дъска, останалата част от регистъра се превръща във въвеждане на данни. Екипите, които прескачат тази стъпка, събират данните, които случайно имат, вместо данните, които образците искат, и после ги събират отново.
Отделете един ден за модела, преди да съберете дори едно поле. Това е малка схема, която може да се научи, а щом можете да нарисувате връзките на бяла дъска, останалата част от регистъра се превръща във въвеждане на данни. Екипите, които прескачат тази стъпка, събират данните, които случайно имат, вместо данните, които образците искат, и после ги събират отново.
Гръбнакът на модела на данните е наборът от договорености, които имате с ICT доставчици на услуги от трети страни. Всяка договореност носи уникален референтен номер и този референтен номер е ключът, който свързва останалите образци. Около този гръбнак записвате кой е подписал всяка договореност, кои от вашите субекти използват услугите, доставчиците зад услугите и техните вериги на доставки, функциите, които услугите поддържат, и оценките, които сте направили за услугите, поддържащи критични или важни функции.
Регистърът е изграден от 15 официални образеца, определени в Регламент за изпълнение (ЕС) 2024/2956 на Комисията. Кодовете им вървят от B_01.01 до B_99.01 и са организирани в групи, определени от числото след B_: 01 (субект и обхват), 02 (договорености), 03 (подписали страни), 04 (субекти, използващи услугите), 05 (доставчици и верига на доставки), 06 (функции), 07 (оценки) и 99 (определения).
| Образец | Официално име | Предназначение | Група |
|---|---|---|---|
| B_01.01 | Субект, поддържащ регистъра | Идентифицира финансовия субект, отговорен за поддържането на регистъра. | Субект и обхват |
| B_01.02 | Списък на субектите в обхвата на консолидацията | Изброява всички субекти в обхвата на групата. | Субект и обхват |
| B_01.03 | Списък на клоновете | Изброява клоновете на субектите в обхвата. | Субект и обхват |
| B_02.01 | Договорености - обща информация | Изброява всяка договореност с ICT трета страна, всяка с уникален референтен номер. | Договорености |
| B_02.02 | Договорености - специфична информация | Отразява услугите и функциите, които всяка договореност поддържа, и нейните условия (прекратяване, приложимо право, място на съхранение, наличие на план за излизане и подобни). | Договорености |
| B_02.03 | Вътрешногрупови договорености | Свързва вътрешногруповите договорености със свързаните договори с външни доставчици. | Договорености |
| B_03.01 | Субекти, подписващи договореността | Отразява подписалите страни от страна на финансовия субект по всяка договореност. | Подписали страни |
| B_03.02 | ICT доставчици на услуги от трети страни, подписващи договореността | Отразява подписалите страни от страна на доставчика по всяка договореност. | Подписали страни |
| B_03.03 | Финансови субекти, предоставящи ICT услуги | Отразява вътрешногруповите субекти, които предоставят ICT услуги в рамките на групата. | Подписали страни |
| B_04.01 | Субекти, използващи ICT услугите | Отразява кои субекти в обхвата действително използват всяка ICT услуга. | Субекти, използващи услугите |
| B_05.01 | ICT доставчици на услуги от трети страни | Пълна идентификация и данни за всеки доставчик (наименование, LEI, държава и подобни). | Доставчици и верига на доставки |
| B_05.02 | Вериги на доставки на ICT услуги | Отразява отношенията между доставчиците и ранга или йерархията на подизпълнението зад всяка услуга. | Доставчици и верига на доставки |
| B_06.01 | Идентификация на функциите | Специфичната за субекта таксономия на функциите, която класифицира поддържаните от ICT функции и тяхната критичност. | Функции |
| B_07.01 | Оценки на ICT услугите, поддържащи критични или важни функции | Отразява оценките, направени за услугите, които поддържат критични или важни функции. | Оценки |
| B_99.01 | Определения | Вътрешна терминология и определения на стойности от затворени списъци, предоставени от субекта. | Определения |
Как се свързват образците
Референтният номер на всяка договореност (B_02.01) е първичният ключ, който държи регистъра заедно. Специфичната информация за тази договореност (B_02.02) виси на същия референтен номер, както и записите за подписалите страни (B_03.01 за вашата страна, B_03.02 за страната на доставчика и B_03.03 за вътрешногруповите доставчици) и записът за това кои субекти използват услугите (B_04.01). Всяка услуга се предоставя от доставчик, идентифициран в B_05.01, а веригата от подизпълнители зад нея е изложена в B_05.02. Функциите, които вашата организация изпълнява, са каталогизирани в B_06.01, а оценките за услугите, поддържащи критични или важни функции, стоят в B_07.01. B_01.01 идентифицира субекта, поддържащ регистъра, B_01.02 и B_01.03 описват обхвата на групата и клоновете, а B_99.01 съдържа определенията, на които разчитате.
Всяка препратка в тази верига трябва да се разрешава. Една-единствена скъсана връзка, например договореност в B_02.02, чийто референтен номер няма съответствие в B_02.01, или оценка в B_07.01, сочеща към доставчик, който липсва в B_05.01, проваля цялото подаване на етапа на валидацията.
Ключови понятия: критичност, подвъзлагане и функции
Три понятия в модела на данните на RoI заслужават допълнително внимание, защото те са тези, които екипите бъркат най-често, и защото сгрешаването им засяга не само вашето подаване, но и цялостната ви позиция по съответствието.
Критични или важни функции (CIF)
Понятието "критични или важни функции" по DORA е дефинирано в Article 3(22) и се свързва пряко с насоките на EBA относно възлагането на дейности. Една функция е критична или важна, когато нейното прекъсване би влошило съществено финансовите резултати на субекта или стабилността или непрекъснатостта на неговите услуги или дейности.
На практика това означава, че вашата организация трябва да направи и документира формална оценка на всяка бизнес функция спрямо тези критерии. RoI отразява резултата от тези оценки в образеца за функциите (B_06.01). Честите грешки включват: прилагане на етикета за критичност твърде тясно (подценяване кои функции се квалифицират и оттам подценяване на вашата ICT зависимост), прилагането му твърде широко (свръхкласифициране на функции, което създава ненужен отчетен обхват) или пропуск да се документира методологията на оценяване зад всяка класификация, която регулаторите ще поискат.
Вериги на подвъзлагане
Article 28(2) изисква финансовите субекти да идентифицират и документират договореностите за подвъзлагане, тоест ситуациите, в които вашият пряк ICT доставчик подвъзлага част от услугата на друга страна. Образецът за веригата на доставки (B_05.02) улавя това, като отразява ранга на подизпълнение зад всяка услуга. На практика това означава, че трябва да знаете не само кои са вашите доставчици, но и кои са техните доставчици, поне за договореностите, поддържащи критични или важни функции.
Това е една от най-слабо попълнените части на първите подавания на RoI, по очевидна причина: събирането на данни за подвъзлагането изисква вашите преки доставчици да разкрият информация за своите вериги на доставки, която може да не са склонни да споделят. Вашият лост тук е договорен: Article 30(2)(a) изисква договореността да посочва дали подизпълнението на ICT услуга, поддържаща критична или важна функция, е разрешено и ако да, при какви условия, а Делегиран регламент (ЕС) 2025/532 на Комисията определя какво трябва да обхващат тези условия. Article 30(2)(h), който понякога се цитира за това, се отнася до правата за прекратяване и сроковете за предизвестие, а не до разкриването на веригата на доставки. Упражняването на правото все пак отнема време и понякога поражда спорове. Започването на това упражнение по събиране на данни рано, в идеалния случай 6 месеца преди първото ви подаване, е силно препоръчително.
Задайте очаквания и вътрешно. Регистърът е лесен, докато не стигнете до подвъзлагането, в който момент той спира да бъде проблем с данни и се превръща в проблем с управлението на взаимоотношенията. Големите доставчици отговарят със стандартен пакет и дълга опашка. Малките доставчици често не познават собствените си четвърти страни достатъчно добре, за да отговорят изобщо. Заложете в бюджета месеци на преследване вместо дни на въвеждане на данни и заложете задължението за разкриване във всеки договор, който подновявате междувременно.
Задайте очаквания и вътрешно. Регистърът е лесен, докато не стигнете до подвъзлагането, в който момент той спира да бъде проблем с данни и се превръща в проблем с управлението на взаимоотношенията. Големите доставчици отговарят със стандартен пакет и дълга опашка. Малките доставчици често не познават собствените си четвърти страни достатъчно добре, за да отговорят изобщо. Заложете в бюджета месеци на преследване вместо дни на въвеждане на данни и заложете задължението за разкриване във всеки договор, който подновявате междувременно.
Веригата доставчик - договор - услуга - функция
Най-важното структурно понятие в RoI е, че всяка ICT договореност трябва да бъде проследима от доставчика чак до вътрешната функция. Това отразява действителната аналитична цел на регулатора: да разбере за всяка дадена бизнес функция точно от кои външни страни зависите и през какви договорни отношения. Ако тази верига е скъсана някъде във вашите данни, регистърът се проваля в предназначението си дори когато преминава техническата валидация.
Процесът по подаване
Формат
RoI трябва да се подава във формат xBRL-CSV, структуриран машинно четим формат, определен от стандарта на XBRL International и профилиран за DORA от ESAs. Вашето подаване е ZIP архив, съдържащ по един CSV файл за всяка таблица в модела на данните. Всеки CSV файл трябва да отговаря на XBRL таксономията, която ESAs публикуват и актуализират. Таксономията определя имената на полетата, типовете данни, контролираните списъци със стойности и ограниченията за връзките между таблиците.
Няма разпоредба за подаване във формат Excel, PDF или какъвто и да е друг формат. Порталите на NCA приемат единствено ZIP архива с xBRL-CSV. Това е едно от най-въздействащите практически изисквания на DORA: то означава, че организациите, които поддържат регистъра си в Excel, трябва да минат през процес по конвертиране и валидиране, който въвежда значителен риск от грешка на етапа на експортиране.
Срокове и крайни дати
Годишният срок за подаване варира според NCA. Повечето NCA са определили срокове в първото тримесечие на всяка календарна година, с референтна дата 31 декември на предходната година, което означава, че вашият регистър трябва да отразява състоянието на вашите ICT договорености към 31 декември. Проверете техническите указания на вашия конкретен NCA за точния срок за подаване, приложим за вашия тип субект и юрисдикция.
Ключовата оперативна последица: не можете да започнете да изграждате регистъра през януари за срок през март, ако процесите ви по събиране на данни вече не са в движение. Само данните за подвъзлагането могат да отнемат месеци за събиране. Организациите, които третират RoI като упражнение в края на годината, редовно се оказват или подаващи непълни данни, или искащи удължаване.
Срок в първото тримесечие спрямо референтна дата 31 декември звучи щедро, докато не преброите стъпките: събиране, съгласуване, получаване на потвърждение от бизнеса за критичността, изграждане на пакета, провал на валидацията, поправка, повторно подаване. Оскъдният ресурс е вниманието на другите хора, а на границата между годините те имат най-малко от него, за да ви го дадат.
Срок в първото тримесечие спрямо референтна дата 31 декември звучи щедро, докато не преброите стъпките: събиране, съгласуване, получаване на потвърждение от бизнеса за критичността, изграждане на пакета, провал на валидацията, поправка, повторно подаване. Оскъдният ресурс е вниманието на другите хора, а на границата между годините те имат най-малко от него, за да ви го дадат.
Порталът на NCA
NCA на всяка държава членка на ЕС управлява собствен портал за подаване. Порталът изисква регистрация, а подаванията се правят от оправомощени потребители, чиято самоличност е обвързана с отчитащия се субект. Когато подадете, порталът изпълнява своята валидационна последователност: проверка на пакета, съответствие с таксономията, референтна цялост, контролирани стойности и бизнес правила, и връща или потвърждение за приемане, или файл с обратна връзка, съдържащ кодове на грешки за всеки провал.
Задължения за целогодишна поддръжка
Това е аспектът на RoI, който изненадва най-много екипите по съответствие, особено онези, свикнали съответствието да е основно дейност към определен момент, обвързана с одитните цикли. RoI е нещо повече от документ, който изграждате веднъж годишно и после архивирате. Той е жив регистър с непрекъснати задължения за поддръжка.
Решението тук е организационно, вместо техническо, и то е най-ценното решение в цялото упражнение: направете регистъра задължителна стъпка при подписването на договор. Ако отделът по доставки не може да затвори нов ICT договор, докато полетата в регистъра не са попълнени, поддръжката спира да бъде проект и се превръща в навик. Всеки друг подход зависи от това някой да си спомни.
Решението тук е организационно, вместо техническо, и то е най-ценното решение в цялото упражнение: направете регистъра задължителна стъпка при подписването на договор. Ако отделът по доставки не може да затвори нов ICT договор, докато полетата в регистъра не са попълнени, поддръжката спира да бъде проект и се превръща в навик. Всеки друг подход зависи от това някой да си спомни.
Article 28(3) изисква финансовите субекти да уведомяват своя NCA при настъпване на съществени промени в ICT договореностите. ITS определя сроковете за актуализиране на регистъра след съществени промени, а "съществена" е дефинирана по-широко, отколкото много екипи по съответствие първоначално допускат. Следните събития изискват актуализации на регистъра:
| Задействащо събитие | Засегнати образци | Срок за актуализация |
|---|---|---|
| Подписан нов договор с ICT трета страна | B_02.01, B_02.02, B_05.01; често B_03.0x, B_04.01, B_07.01 | Веднага щом е разумно практически възможно; най-късно преди следващото годишно подаване |
| Прекратен или предоговорен съществуващ договор | B_02.01, B_02.02, плюс свързаните записи за подписали страни, употреба и оценки | Веднага щом е практически възможно след датата на влизане в сила |
| ICT доставчик сменя наименованието си или е придобит | B_05.01 (и всяка актуализация на LEI) | След уведомление от доставчика или актуализация в публичен регистър |
| Смяна на подизпълнител по съществуваща договореност | B_05.02 | При уведомление от основния доставчик |
| Промяна в класификацията на вътрешна функция | B_06.01, B_07.01 (и специфичната информация в B_02.02) | След приключване на вътрешната оценка |
| Промяна в мястото на съхранение на данните | B_02.02 | При уведомление от доставчика |
Практическата последица е, че RoI трябва да бъде притежаван от някого, или от някаква функция, който е свързан с процесите по управление на жизнения цикъл на договорите и по доставки в организацията през цялата година. Екип по съответствие, който докосва регистъра само веднъж годишно, редовно ще установява, че той вече не отразява действителността, когато дойде време за подаване, и че наваксването в седмиците преди срока е трескаво, склонно към грешки и често непълно.
Чести грешки при първо подаване
Екипите, които изграждат първия си Register of Information, редовно се сблъскват с един и същ набор от структурни грешки. Ето най-съществените от тях и как да ги избегнете.
Ако предприемете действие само по една от тях, нека това бъде първата. Изборът на вашата система на запис е решение, което вземате веднъж, между другото, през първата седмица, и с което после живеете през цялата програма.
Ако предприемете действие само по една от тях, нека това бъде първата. Изборът на вашата система на запис е решение, което вземате веднъж, между другото, през първата седмица, и с което после живеете през цялата програма.
❌
Започване с Excel образеца на ESA като ваша система на запис
Excel образецът на ESA е помощно средство за събиране на данни. Листовете му не са свързани, идентификаторите му не се налагат и той не осигурява валидация спрямо правилата на EBA. Използването му като основен инструмент за регистър с какъвто и да е значителен размер води до грешки при външните ключове, непоследователни идентификатори и болезнен ръчен процес по конвертиране в момента на подаване.
❌
Смесване на "доставчик" с "ICT доставчик на услуги от трета страна"
Вашият вътрешен списък с доставчици почти сигурно съдържа доставчици, които остават извън определението на DORA за ICT доставчици на услуги от трети страни, и може да пропуска някои, които попадат в него. DORA се фокусира конкретно върху ICT услугите: ИТ инфраструктура, софтуер, услуги за данни и анализи и подобни. Офис консумативи, изпълнители по почистване и професионални консултантски услуги остават извън определението за ICT доставчици. Съпоставянето от вашия регистър на доставчиците без прилагане на конкретните критерии на DORA води или до свръхобхват (излишна работа), или до недостатъчен обхват (непълно подаване).
❌
Оставяне на образеца за веригата на доставки (B_05.02) почти празен
Огромното мнозинство от облачни доставчици, софтуерни доставчици и доставчици на управлявани услуги разчитат на подизпълнители поне за част от доставката си: центрове за данни, мрежови доставчици, подобработващи лица. Празен или почти празен образец за веригата на доставки ще привлече вниманието на NCA, защото е неправдоподобен за която и да е организация с повече от шепа ICT доставчици. Започнете рано да събирате информация за подвъзлагането от доставчиците и направете правото си на тези данни изрично в новите и предоговаряните договори.
❌
Третиране на оценката на критичността като двоично отмятане на кутийка
Класифицирането на функции като критични или некритични без документиран, методичен процес на оценяване само по себе си е пропуск в управлението, отделен от каквото и да сложите в регистъра. Регулаторите ще питат как сте направили определянето. Ако отговорът е "погледнахме списъка и използвахме преценката си", това едва ли ще удовлетвори надзорен преглед. Оценката следва да бъде документирана, последователна и обвързана с определена методология, която препраща към критериите на DORA. Не позволявайте обаче това да се превърне в поредица от работни срещи, която върви цяло тримесечие. Критериите са достатъчно широки, за да могат разумни хора да не се съгласят в граничните случаи, а надзорният орган търси защитим метод, вместо перфектен отговор. Съгласувайте метода, прилагайте го последователно, запишете защо всяка гранична функция е попаднала там, където е попаднала, и продължете напред. Не позволявайте обаче това да се превърне в поредица от работни срещи, която върви цяло тримесечие. Критериите са достатъчно широки, за да могат разумни хора да не се съгласят в граничните случаи, а надзорният орган търси защитим метод, вместо перфектен отговор. Съгласувайте метода, прилагайте го последователно, запишете защо всяка гранична функция е попаднала там, където е попаднала, и продължете напред.
❌
Непроверяване на версията на таксономията преди експортиране
DORA xBRL таксономията е версионирана, а ESAs са публикували актуализации след първоначалното издание. Подаването на пакет, изграден спрямо по-стара версия на таксономията, причинява провали на валидацията, които могат да бъдат трудни за диагностициране. Винаги потвърждавайте коя версия на таксономията порталът на вашия NCA приема в момента и проверявайте за актуализации в седмиците преди датата на подаването ви.
Инструменти и подходи
Има три широки подхода, които организациите използват за изграждане и поддържане на Register of Information. Всеки има различен рисков профил, а правилният избор зависи от размера и сложността на вашия регистър.
| Подход | Най-подходящ за | Ключови рискове |
|---|---|---|
| Excel образец на ESA + ръчно конвертиране към xBRL-CSV | Субекти с <30 доставчици и прости структури | Грешки при външните ключове, повреден формат на датите, печатни грешки в контролираните стойности, липса на валидация преди подаване |
| Обща GRC платформа с наслагване на рамката DORA | Субекти с нужди по няколко рамки, които могат да приемат ръчни заобиколни решения при експорта на RoI | Липса на вграден xBRL-CSV експорт; моделът на данните на RoI не се налага; специфичната за ICT структура изисква ръчно пресъздаване |
| Специално създадена платформа за DORA RoI | Всеки субект с 30+ доставчици, структура с няколко субекта или предишни отхвърляния на подавания | Време за избор на доставчик и въвеждане в експлоатация; интеграция със съществуващите източници на данни за доставчици |
Аргументът за специално създадена платформа става убедителен бързо, щом излезете отвъд малък и прост регистър. Конкретните функции, които имат най-голямо значение за RoI, са: наложена референтна цялост между таблиците, автоматизирана валидация на LEI спрямо GLEIF, твърди ограничения върху полетата с контролирани стойности, xBRL-CSV експорт, който изпълнява текущите валидационни правила на EBA преди пакетирането, и управление на одитната следа за актуализациите, направени през годината. Това са възможностите, които отличават регистър, изграден за подаване, от регистър, който изглежда пълен, докато порталът на NCA не ви каже обратното.
Изградете своя Register of Information върху модел на данните, който няма да се счупи.
Модулът за RoI на Venvera налага релационната структура, валидира спрямо текущия набор от правила на EBA преди експорт и произвежда директно готов за подаване xBRL-CSV пакет, без Excel, без ръчно конвертиране, без цикли от повторни подавания.
Вижте Venvera в действие → Venvera.comУправлявате повече от едно юридическо лице? Вижте как Venvera се справя със софтуер за съответствие за групи от дружества: напишете политиките веднъж при предприятието майка и оставете всяко дъщерно дружество да ги докаже със собствени доказателства.
Често задавани въпроси
Колко често трябва да се подава DORA Register of Information?
RoI се подава ежегодно, с референтна дата 31 декември на предходната отчетна година. NCA могат да определят конкретни срокове за подаване, обикновено през първото тримесечие на следващата година, които могат да варират според юрисдикцията и типа субект. Проверете публикуваните указания на вашия NCA за точния срок, приложим за вас.
Трябва ли всички 15 образеца да бъдат попълнени за всяко подаване?
Не всички образци носят данни за всеки субект. Някои са относими само при определени обстоятелства, например вътрешногруповите образци (B_02.03 и B_03.03) се прилагат само за групи, а образецът за оценките (B_07.01) се попълва за услуги, които поддържат критични или важни функции. Всеки изискван файл на образец обаче трябва да присъства в ZIP архива дори когато не съдържа редове с данни; празен изискван файл се различава от липсващ, а липсващ файл причинява провал при пакетирането.
Каква е разликата между "доставчик" и "подизпълнител" в RoI?
Доставчик е ICT доставчик на услуги от трета страна, с когото вашата организация има пряко договорно отношение; всеки доставчик се идентифицира в B_05.01. Подизпълнител е страна, която вашият пряк доставчик използва, за да достави част от услугата към вас, при липса на пряко договорно отношение с вашата организация; подизпълнителите се появяват в образеца за веригата на доставки (B_05.02), който отразява ранга на подизпълнение зад всяка услуга. И двете трябва да бъдат документирани в RoI, но стоят в различни образци и се улавят чрез различни полета.
Какво става, ако открием грешка в подадения си регистър след срока?
Следва да се свържете с вашия NCA и да подадете коригирана версия възможно най-скоро. Изискването на DORA е за точен и актуален регистър; подаването на неправилна версия и оставянето ѝ некоригирана е по-лош изход от подаването на корекция впоследствие. NCA обикновено предпочитат субектите, които проактивно откриват и коригират грешки, пред онези, които допускат неточни данни да останат.
Замества ли DORA Register of Information някакви съществуващи задължения за отчитане?
RoI е специфичен за DORA и не замества задължения за отчитане по други регулаторни рамки. Данните, събрани за RoI, обаче често се препокриват с данни, нужни за други цели: оценки на риска от доставчици, картографиране на данните по GDPR, уведомления за възлагане на дейности и документация за непрекъснатост на дейността. Организациите, които изграждат RoI правилно, установяват, че той се превръща в ценен актив от данни за тези съседни задължения.
Написано от екипа по съответствие на Venvera. Venvera е специално създадена платформа за съответствие с DORA за европейски финансови субекти. Последна актуализация: юли 2026 г. Прегледано спрямо Регламент за изпълнение (ЕС) 2024/2956 на Комисията; конкретната версия на xBRL таксономията и на отчетния пакет в сила, както и наборът ѝ от валидационни правила, следва да бъдат потвърдени с вашия NCA преди всяко подаване.
