
Глава V на DORA, членове 28 до 44, урежда ИКТ риска от трети страни. Тя се разделя на две. Раздел I, членове 28 до 30, е това, което финансовите субекти трябва да направят: регистърът, преддоговорната оценка, оценката на концентрацията, задължителните договорни клаузи и стратегиите за изход. Раздел II, членове 31 до 44, е рамката за надзор върху критичните доставчици на ИКТ услуги от трети страни, което е страната на надзорните органи в тази уредба. Глава V е частта от DORA, която струва най-много и обикновено се започва последна. Регистърът изглежда като инвентаризация, поради което се планира като такава, и остава лесен точно до момента, в който трябва да картографирате веригите на подизпълнение през доставчици, които никога не е трябвало да казват това на никого.
Това ръководство обхваща Раздел I и трите технически стандарта под него: Регламент за изпълнение (ЕС) 2024/2956 за шаблоните на регистъра, Делегиран регламент (ЕС) 2024/1773 за политиката относно ИКТ услугите, поддържащи критични или важни функции, и Делегиран регламент (ЕС) 2025/532 за подизпълнението.
Едно уточнение, което си струва да се направи рано, защото е често срещано объркване. Article 28(9) възлага технически стандарти за изпълнение, които станаха шаблоните на регистъра в ITS (ЕС) 2024/2956. Article 28(10) възлага регулаторни технически стандарти относно съдържанието на политиката за трети страни, които станаха Делегиран регламент (ЕС) 2024/1773. Това са различни инструменти, които вършат различна работа, а регистър, изграден спрямо грешния от тях, няма да се експортира.
Глава V, Раздел I
Какво изисква DORA за ИКТ риска от трети страни
Article 28(1) задава рамката: финансовите субекти “управляват риска от трети страни, свързан с ИКТ, като неразделна част от ИКТ риска в рамките на своята рамка за управление на ИКТ риска”. Това е изречението, което спира тази област да бъде самостоятелна програма за доставчици. Задълженията след това се разпростират върху целия жизнен цикъл на ИКТ услугата.
Стратегията и политиката (чл. 28(2))
Субектите, различни от микропредприятия и от посочените в чл. 16(1), трябва да приемат и редовно преразглеждат стратегия за ИКТ риска от трети страни, включително политика за използването на ИКТ услуги, поддържащи критични или важни функции. Ръководният орган “редовно преразглежда рисковете, установени във връзка с договорните споразумения за използване на ИКТ услуги, поддържащи критични или важни функции”. Съдържанието на тази политика е определено от RTS (ЕС) 2024/1773.
Регистърът (чл. 28(3))
Поддържайте и актуализирайте, на ниво субект и на подконсолидирано и консолидирано ниво, регистър на информацията, обхващащ всички договорни споразумения за използване на ИКТ услуги, предоставяни от доставчици на ИКТ услуги от трети страни, като разграничавате тези, които поддържат критични или важни функции, от останалите.
Преди да подпишете (чл. 28(4))
Преценете дали споразумението обхваща критична или важна функция; преценете дали са изпълнени надзорните условия за сключване на договор; идентифицирайте и оценете всички относими рискове, включително дали споразумението би засилило ИКТ концентрационния риск по чл. 29; извършете надлежна проверка на потенциалния доставчик; и идентифицирайте и оценете конфликтите на интереси.
Стандарти за сигурност (чл. 28(5))
Можете да сключвате договори само с доставчици, които спазват подходящи стандарти за информационна сигурност. Когато споразумението засяга критични или важни функции, преди сключването му трябва надлежно да вземете предвид използването от доставчика на “най-актуалните и най-висококачествени стандарти за информационна сигурност”.
Одитни права, които се упражняват (чл. 28(6))
Наличието на одитни права не е достатъчно. Трябва предварително да определите, на рискова основа, честотата на одитите и проверките и областите, които ще бъдат одитирани. Когато споразумението е технически сложно, трябва да проверите, че одиторите притежават уменията реално да извършат одита.
Прекратяване и изход (чл. 28(7), 28(8))
Договорите трябва да могат да бъдат прекратени в четирите обстоятелства, изброени в чл. 28(7). За ИКТ услугите, поддържащи критични или важни функции, трябва да имате стратегии за изход, които са изчерпателни, документирани, достатъчно тествани и периодично преразглеждани.
Какво реално казва Article 28(3), че докладвате и на кого
Годишното задължение за докладване е към вашия компетентен орган, не директно към ЕНО, и е по-тясно от пълния регистър: субектите “докладват най-малко веднъж годишно на компетентните органи за броя на новите споразумения за използване на ИКТ услуги, категориите доставчици на ИКТ услуги от трети страни, вида на договорните споразумения и предоставяните ИКТ услуги и функции”. Отделно от това трябва да предоставите пълния регистър или определени негови раздели на компетентния орган при поискване и трябва своевременно да го информирате за всяко планирано договорно споразумение за ИКТ услуги, поддържащи критични или важни функции, както и когато дадена функция стане критична или важна.
Article 30
Договорните клаузи: девет плюс шест
Article 30 е разпоредбата с най-големи оперативни последици в Глава V, а броят на клаузите често се съобщава погрешно. Няма единен списък с “14 клаузи”. Има два списъка.
Article 30(1) идва първи и лесно се пропуска: правата и задълженията на двете страни трябва да бъдат “ясно разпределени и изложени в писмена форма”, а “пълният договор включва споразуменията за нивото на обслужване и се документира в един писмен документ”, наличен на хартия или в изтегляем, траен и достъпен формат. Договор, разпръснат между неподписана поръчка, уеб страница с условия и PDF с описание на услугата, вече е констатация, която чака да се случи.
Article 30(2): деветте елемента, които всеки ИКТ договор трябва да съдържа
| Чл. 30(2) | Елемент | Какво трябва да съдържа |
|---|---|---|
| (a) | Описание на функциите и ИКТ услугите и позицията за подизпълнение | Ясно и пълно описание на всички функции и ИКТ услуги, с посочване дали е разрешено подизпълнение на ИКТ услуга, поддържаща критична или важна функция, или на съществени части от нея, и ако да, при какви условия. |
| (b) | Места на предоставяне и на обработване на данни | Регионите или държавите, в които се предоставят договорените или подизпълнените функции и ИКТ услуги и в които се обработват данни, включително мястото на съхранение, плюс изискване към доставчика да ви уведоми предварително, ако планира да ги промени. |
| (c) | Разпоредби за защита на данните | Разпоредби за наличността, автентичността, целостта и поверителността във връзка със защитата на данните, включително личните данни. |
| (d) | Достъп, възстановяване и връщане на данни | Разпоредби, осигуряващи достъп до, възстановяване и връщане на лични и нелични данни в лесно достъпен формат в случай на несъстоятелност, преструктуриране или прекратяване на дейността на доставчика, или при прекратяване на договора. |
| (e) | Описания на нивото на обслужване | Описания на нивото на обслужване, включително техните актуализации и изменения. |
| (f) | Съдействие при инциденти без или с предварително договорена цена | Задължението на доставчика да ви съдейства без допълнителна цена или на предварително определена цена, когато настъпи ИКТ инцидент, свързан с услугата. |
| (g) | Сътрудничество с органите | Задължението на доставчика да сътрудничи изцяло на вашите компетентни органи и органи за преструктуриране, включително на лицата, назначени от тях. |
| (h) | Права за прекратяване и срокове за предизвестие | Права за прекратяване и свързаните с тях минимални срокове за предизвестие в съответствие с очакванията на компетентните органи и органите за преструктуриране. |
| (i) | Участие във вашето обучение по сигурност | Условията за участие на доставчика във вашите програми за осведоменост по ИКТ сигурност и в обученията по цифрова оперативна устойчивост, в съответствие с Article 13(6). |
Article 30(3): още шест елемента, когато услугата поддържа критична или важна функция
Те се добавят към деветте по-горе.
| Чл. 30(3) | Елемент | Какво трябва да съдържа |
|---|---|---|
| (a) | Пълни описания на нивото на обслужване с количествени цели | Пълни описания на нивото на обслужване с точни количествени и качествени цели за изпълнение, за да можете да наблюдавате ефективно и да предприемате коригиращи действия без ненужно забавяне, когато договорените нива не са постигнати. |
| (b) | Срокове за предизвестие и задължения на доставчика за докладване | Срокове за предизвестие и задължения за докладване, включително уведомяване за всяко развитие, което може съществено да засегне способността на доставчика да предоставя услугата съгласно договорените нива на обслужване. |
| (c) | Планове за непредвидени обстоятелства и мерки за сигурност | Изисквания доставчикът да въведе и тества планове за непрекъснатост на дейността и да разполага с мерки, инструменти и политики за ИКТ сигурност, осигуряващи подходящо ниво на сигурност. |
| (d) | Участие в TLPT | Задължението на доставчика да участва и да сътрудничи изцяло във вашето тестване за проникване, водено от заплахи, по членове 26 и 27. |
| (e) | Права за текущо наблюдение | Правото да наблюдавате изпълнението текущо: неограничени права на достъп, проверка и одит от вас, от назначена трета страна и от компетентния орган; правото да правите копия на относима документация на място; правото да договорите алтернативни нива на увереност, когато са засегнати правата на други клиенти; сътрудничество от доставчика по време на проверки на място; и подробности за обхвата, процедурите и честотата. Микропредприятията могат да се съгласят да делегират тези права на независима трета страна, назначена от доставчика. |
| (f) | Стратегии за изход със задължителен преходен период | Стратегии за изход, и по-специално задължителен подходящ преходен период, през който доставчикът продължава да предоставя услугата, което ви позволява да мигрирате към друг доставчик или да прехвърлите услугата вътрешно. |
Article 30(4) добавя по-меко изискване, което си струва да знаете: при преговори субектите и доставчиците “обмислят използването на стандартни договорни клаузи, разработени от публични органи за конкретни услуги”. Очаквайте истинската битка да е около Article 30(3)(e). Неограничените права на достъп, проверка и одит са това, на което големите доставчици се противопоставят най-силно, а стандартният им отговор е обединен одитен доклад и въпросник. Текстът предвижда част от това, като допуска алтернативни нива на увереност, когато са засегнати правата на други клиенти, така че решете предварително кои алтернативи ще приемете и защо. Влизането в тези преговори с шаблон, който не можете да обясните, е начинът да приемете каквото ви предложат.
Проследявайте клаузите по договор, не по програма
Единицата на съответствие тук е отделното договорно споразумение. Петнадесет елемента, оценени като налични, липсващи или частични, спрямо всяко споразумение в обхвата. Тази решетка е единственото нещо, което ви показва размера на изоставането в отстраняването и кое подновяване на договор да приоритизирате. Няма да ви кажем какъв дял от договорите обикновено не покриват изискванията: нямаме публикувани данни за това и, доколкото можем да установим, никой друг също няма.
Последователност на изграждане
Изграждане на регистъра
Регистърът е релационен модел на данни, чиято форма се задава от 15-те официални шаблона в Регламент за изпълнение (ЕС) 2024/2956, вървящи от B_01.01 до B_99.01. Изградете първо модела на данните и полетата ще последват. Разглеждаме самите шаблони в ръководството за 15-те официални шаблона. Ето последователността, която ви води от нула до попълнен регистър.

Стъпка 1
Опишете всяко споразумение за ИКТ услуга от трета страна
Регистърът обхваща “всички договорни споразумения за използване на ИКТ услуги, предоставяни от доставчици на ИКТ услуги от трети страни” (чл. 28(3)), което е по-широко от това, което думата “аутсорсинг” подсказва. Започнете от записите на отдел Доставки и Задължения към доставчици, инвентарите на софтуерни активи и логовете за достъп. Две категории редовно се пропускат: вътрешногруповите ИКТ доставчици, които регистърът обработва чрез собствените си вътрешногрупови шаблони, и безплатният или закупеният извън отдел Доставки от бизнес линиите SaaS. Съгласуването на Доставки, Задължения към доставчици и софтуера, който хората реално използват, е упражнение по преследване на хора и е бавно. Дайте му седмици календарно време и го дайте на човек, достатъчно старши, за да попита една бизнес линия защо държи договор, който финансовият отдел никога не е виждал.
Източник: чл. 28(3)
Стъпка 2
Решете кои функции са критични или важни и запишете защо
Article 3(22) я определя като “функция, чието нарушаване би засегнало съществено финансовите резултати на финансов субект или стабилността или непрекъснатостта на неговите услуги и дейности, или чието преустановено, дефектно или неуспешно изпълнение би засегнало съществено продължаващото спазване от финансовия субект на условията и задълженията по неговия лиценз или на другите му задължения съгласно приложимото право в областта на финансовите услуги”. Това определяне движи почти всичко останало: кои договори се нуждаят от допълнителните клаузи по Article 30(3), кои споразумения се нуждаят от стратегия за изход и кои се нуждаят от преддоговорната оценка на концентрацията.
Източник: чл. 3(22), чл. 28(3)
Стъпка 3
Опишете договорното споразумение, клауза по клауза
Article 30(1) изисква правата и задълженията на двете страни да бъдат “ясно разпределени и изложени в писмена форма” в един писмен документ, който включва споразуменията за нивото на обслужване. След това проверете договора спрямо деветте елемента в Article 30(2) и, ако услугата поддържа критична или важна функция, спрямо шестте допълнителни елемента в Article 30(3). Проследявайте всеки елемент като наличен, липсващ или частичен. Този статус по клаузи е артефактът, който ви показва къде реално се намира изоставането ви в отстраняването.
Източник: чл. 30(1), 30(2), 30(3)
Стъпка 4
Картографирайте веригата на подизпълнение за критичните или важните функции
Когато доставчик може да възложи на подизпълнител услуга, поддържаща критична или важна функция, Делегиран регламент (ЕС) 2025/532 определя какво трябва да установите, преди да подпишете, какво трябва да казва договорът и какво се случва, когато веригата се промени. Това е частта с най-много ново задължение и има собствен раздел по-долу.
Източник: чл. 30(2)(a), 30(5); RTS (ЕС) 2025/532
Стъпка 5
Проведете преддоговорната оценка на концентрацията
Article 29(1) не е упражнение по годишно отчитане. Той действа, когато сте на път да подпишете: като част от идентифицирането на риска, изисквано от Article 28(4)(c), трябва да вземете предвид дали предвижданото споразумение би означавало сключване на договор с доставчик, който не е лесно заменим, или наличие на множество споразумения за критични или важни функции с един и същ доставчик или с тясно свързани доставчици. След това трябва да “претеглите ползите и разходите на алтернативните решения”.
Източник: чл. 28(4)(c), чл. 29(1)
Article 29
Концентрационният риск е преддоговорен тест
Article 29 е озаглавен “Предварителна оценка на ИКТ концентрационния риск на ниво субект” и заглавието носи целия смисъл. Той се задейства от Article 28(4)(c), който стои под заглавието “Преди сключване на договорно споразумение”. Това е контролна точка във вашия процес по доставки. Не е нещо, което правите веднъж годишно с електронна таблица през декември. Поставянето му преди подписа е правилният дизайн и неудобният. Отдел Доставки носи контролната точка, а оценката трябва да приключи със скоростта, с която се движи една търговска сделка. Вградете я в работния процес за одобрение като задължителна стъпка, защото оценка, написана след договарянето на сделката, се чете точно като такава.
Ето какво текстът ви казва да претеглите.

Заменяемост на доставчика
Article 29(1)(a): дали предвижданото споразумение би означавало “сключване на договор с доставчик на ИКТ услуги от трета страна, който не е лесно заменим”. Заменяемостта е поле в шаблона за оценка на регистъра, така че заключението, до което стигнете тук, трябва да бъде записано.
Множество споразумения с един и същ или свързани доставчици
Article 29(1)(b): дали бихте се озовали в положение да “имате множество договорни споразумения във връзка с предоставянето на ИКТ услуги, поддържащи критични или важни функции, с един и същ доставчик на ИКТ услуги от трета страна или с тясно свързани доставчици на ИКТ услуги от трети страни”. Обърнете внимание на “тясно свързани”: два договора с две дъщерни дружества от една група са една концентрация.
Алтернативите, които сте обмислили
Article 29(1), втора алинея, изисква да “претеглите ползите и разходите на алтернативните решения, например използването на различни доставчици на ИКТ услуги от трети страни”, спрямо бизнес нуждите и целите във вашата стратегия за цифрова устойчивост. Резултатът е документирано сравнение на разгледаните алтернативи.
Местоположение, трети държави и право по несъстоятелност
Article 29(2) изисква за критичните или важните функции да вземете предвид правото по несъстоятелност, което би се приложило при фалит на доставчика, както и всяко ограничение за спешно възстановяване на вашите данни. Когато доставчикът е установен в трета държава, трябва да вземете предвид и спазването на правилата на Съюза за защита на данните и ефективното правоприлагане в тази държава.
Дължина на веригата и вашата способност за наблюдение
Article 29(2), последна алинея: когато споразумението предвижда подизпълнение, трябва да оцените “дали и как потенциално дългите или сложни вериги от подизпълнители могат да засегнат способността им да наблюдават изцяло договорените функции и способността на компетентния орган да упражнява ефективен надзор върху финансовия субект в това отношение”.
Концентрация вътре във веригата
RTS (ЕС) 2025/532, член 1(j), изяснява, че факторите, които претегляте, включват “дали предоставянето на ИКТ услуги, поддържащи критични или важни функции, или на съществени части от тях, е концентрирано в един подизпълнител на доставчик на ИКТ услуги от трета страна или в малък брой такива подизпълнители”. Двама независими доставчици, стъпили върху един и същ подизпълнител, са една зависимост.
Какво го поддържа живо след подписа
Article 28(2) възлага текущото задължение на ръководния орган, който “редовно преразглежда рисковете, установени във връзка с договорните споразумения за използване на ИКТ услуги, поддържащи критични или важни функции”. А RTS (ЕС) 2025/532, член 3(2), изисква субектите, чиито доставчици възлагат на подизпълнители критични или важни услуги, да извършват съответната оценка на риска “периодично” спрямо промените в бизнес средата, включително ИКТ заплахи, ИКТ концентрационни рискове и геополитически рискове. Нито една от двете разпоредби не задава фиксирана годишна честота, така че ако заявите такава в политиката си, това е ваш собствен ангажимент.
RTS (ЕС) 2025/532
Подизпълнение: доставчиците на вашия доставчик
Това е частта от режима с най-много детайли и най-малко осведоменост. DORA Article 30(2)(a) изисква договорът да посочва дали е разрешено подизпълнение на ИКТ услуга, поддържаща критична или важна функция, или на съществени части от нея, и при какви условия. Article 30(5) след това възложи технически стандарт, който да определи какво трябва да установите и оцените. Този стандарт е Делегиран регламент (ЕС) 2025/532 и има три подвижни части.
1. Решението се взема преди да подпишете
Член 3(1) е изричен: финансовият субект “решава, преди да сключи договорно споразумение с доставчик на ИКТ услуги от трета страна, дали този доставчик на ИКТ услуги от трета страна може да възложи на подизпълнител ИКТ услуга, която поддържа критични или важни функции, или съществени части от нея”. Можете да сключите споразумението едва след като сте оценили, че десет условия, букви (a) до (j), са изпълнени. Те включват доставчикът да е в състояние да идентифицира всички подизпълнители, поддържащи критични или важни функции, и да ви уведоми за тях; подизпълнителят да ви предостави на вас и на органите същите права на достъп и проверка, каквито предоставя доставчикът; вие да сте оценили въздействието от отказ на подизпълнител върху вашата устойчивост и финансова стабилност; вие да сте оценили концентрационния риск по Article 29; и вие да сте оценили дали има пречки за упражняването на права на одит и проверка.
Член 3(3) затваря очевидната вратичка: разчитането на собствената оценка на доставчика за неговите подизпълнители “не ограничава крайната отговорност на финансовите субекти да спазват своите правни и регулаторни задължения”.
2. Дванадесет неща, които договорът трябва да определи
Когато подизпълнението на критични или важни услуги е разрешено, член 4(1) изисква договорът да посочи кои услуги подлежат на подизпълнение и при какви условия, както и да определи всичко от следното.
| Чл. 4(1) | Договорът трябва да определи |
|---|---|
| (a) | Доставчикът отговаря за услугите, предоставяни от неговите подизпълнители. |
| (b) | Доставчикът трябва да наблюдава всички подизпълнени ИКТ услуги, поддържащи критични или важни функции, така че задълженията му към вас да се изпълняват непрекъснато. |
| (c) | Задълженията за наблюдение и докладване, които доставчикът дължи на вас по отношение на тези подизпълнители. |
| (d) | Доставчикът трябва да оцени всички рискове, свързани с местоположението на настоящите и потенциалните подизпълнители и на тяхното дружество майка, както и с мястото, от което се предоставя услугата. |
| (e) | Мястото на данните, обработвани или съхранявани от подизпълнителя, когато е относимо. |
| (f) | Доставчикът трябва да определи в собствените си договори с подизпълнителите задълженията за наблюдение и докладване на тези подизпълнители. |
| (g) | Доставчикът трябва да осигури непрекъснатост на услугата по цялата верига от подизпълнители, ако подизпълнител не изпълни задълженията си. |
| (h) | Договорът на доставчика с подизпълнителите му трябва да съдържа изискванията за планове за непрекъснатост на дейността по DORA чл. 30(3)(c) и да определя нивата на обслужване, които подизпълнителите трябва да постигат. |
| (i) | Същият договор трябва да определя стандартите за ИКТ сигурност и всички допълнителни изисквания за сигурност, посочени в DORA чл. 30(3)(c). |
| (j) | Подизпълнителят трябва да предостави на вас и на компетентните органи и органите за преструктуриране същите права на достъп, проверка и одит като в DORA чл. 30(3)(e). |
| (k) | Доставчикът трябва да ви уведоми за всяка съществена промяна в договореностите за подизпълнение. |
| (l) | Имате право да прекратите договора, когато са изпълнени условията в чл. 6 от RTS или в DORA чл. 28(7). |
3. Получавате право на вето върху съществени промени във веригата
Член 5 е разпоредбата, която най-вероятно ще промени поведението на вашите доставчици. Договорът трябва да задължава доставчика да ви информира за всяка планирана съществена промяна в договореностите му за подизпълнение “достатъчно навреме”, за да оцените въздействието върху вашия риск и върху способността на доставчика да изпълнява задълженията си. Договорът трябва да съдържа “разумен срок за предизвестие, в който финансовият субект да одобри промените или да възрази срещу тях”. И след това член 5(3): доставчикът “прилага съществените промени в договореностите си за подизпълнение само след като финансовият субект ги е одобрил или не е възразил срещу тях до края на срока за предизвестие”. Това е най-силният лост, който режимът ви дава, и лесно се пропилява. Прозорецът за одобрение е реален само ако някой отговаря за пощенската кутия, в която пристигат тези уведомления, и може да оцени промяна по графика на доставчика. Решете сега кой е този човек и как изглежда вашият постоянен тест за съществена промяна, или срокът за предизвестие ще изтече, докато имейлът стои непрочетен.
Ако заключите, че промяната надхвърля вашата толерантност към риск, член 5(4) изисква да уведомите доставчика и да възразите преди края на срока за предизвестие. Член 6 след това ви дава право да прекратите договора, когато доставчикът е приложил съществени промени, срещу които сте възразили, приложил ги е преди края на срока за предизвестие без вашето одобрение, или е възложил на подизпълнител критична или важна услуга, която договорът не му е разрешавал изрично да подизпълнява.
Откъде идват данните е трудната част
Задължението минава през договора. Член 3(1)(b) от RTS изисква да сте оценили, преди подписването, че доставчикът “е в състояние да идентифицира всички подизпълнители, които предоставят ИКТ услуги, поддържащи критични или важни функции, или съществени части от тях, да уведоми и информира финансовия субект за тези подизпълнители”. Това е условие на надлежната проверка относно способността на доставчика и е вашият лост. Когато съществуващ договор не го съдържа, член 4(2) от RTS изисква промените, необходими за постигане на съответствие, “да бъдат въведени своевременно и възможно най-скоро”, с документиран планиран график. Публично поддържаните страници с подизпълнители при големите доставчици са полезни за кръстосана проверка, но се променят без предизвестие и не заместват договорното право на уведомяване.
Article 28(8)
Стратегии за изход: четири теста
Стратегии за изход се изискват за ИКТ услугите, поддържащи критични или важни функции. Задължението е по-конкретно от “имайте план за изход” и всяка негова част е проверима.
Изходът трябва да е възможен без три неща да се случат
Article 28(8), втора алинея, изисква субектите да могат да излязат “без прекъсване на своите стопански дейности”, без “ограничаване на спазването на регулаторните изисквания” и без “вреда за непрекъснатостта и качеството на услугите, предоставяни на клиентите”. Това са трите теста, които един план за изход трябва да премине.
Планът трябва да бъде тестван
Article 28(8), трета алинея: “Плановете за изход са изчерпателни, документирани и, в съответствие с критериите, посочени в член 4, параграф 2, достатъчно тествани и периодично преразглеждани.” Нетестван план за изход не отговаря на члена.
Алтернативите и преходните планове трябва да бъдат идентифицирани
Article 28(8), четвърта алинея, изисква да “идентифицирате алтернативни решения и да разработите преходни планове, които им позволяват да премахнат договорените ИКТ услуги и съответните данни от доставчика на ИКТ услуги от трета страна и да ги прехвърлят сигурно и в цялост към алтернативни доставчици или да ги реинтегрират вътрешно”.
Договорът трябва да ви даде преходен период
Article 30(3)(f) изисква договорите за критични или важни функции да съдържат стратегии за изход, включително “установяването на задължителен подходящ преходен период”, през който доставчикът продължава да предоставя услугата. Ако вашият договор няма преходен период, планът ви за изход стъпва върху добрата воля на доставчика. Тестването на изхода е изискването, което най-често тихо се понижава до преглед на хартия, а за голяма зависимост от облак това е разбираемо, защото истинският тест е скъп и разстройващ. Защитимата средна позиция е да упражните частите, които можете, а именно извличането на данни, възстановяването в алтернатива, наръчника и пътя на вземане на решения, и да запишете точно кои части сте оставили нетествани и защо.
Article 28(8) изисква също мерки за непредвидени обстоятелства, които поддържат непрекъснатостта на дейността при настъпване на обстоятелствата, задействащи изхода, и обвързва списъка на задействащите условия с обстоятелствата за прекратяване в Article 28(7): съществено нарушение от доставчика, обстоятелства, установени при наблюдението, които биха могли да променят изпълнението, доказани слабости в управлението на ИКТ риска от доставчика и положението, при което компетентният орган вече не може да упражнява ефективен надзор върху вас заради споразумението.
Член 10 от RTS (ЕС) 2024/1773 урежда изхода и прекратяването като част от политиката относно ИКТ услугите, поддържащи критични или важни функции, така че съдържанието за изход във вашата политика също има определено място.
Инструменти
Къде се вписва Venvera
Всичко това може да се води в електронни таблици и за няколко доставчика често е точно така. Това, което се чупи, е целостта: регистърът е релационен, референцията на едно договорно споразумение е ключ, към който сочат няколко други таблици, а електронната таблица няма как да спре тези референции да се разминат. Venvera покрива редица рамки; DORA е една от тях. Ето възможностите за трети страни, които съществуват в продукта днес.

📚
Регистър на ИКТ доставчици и договори
Доставчици, договорни споразумения, клонове, бизнес функции и оценки на риска като свързани записи. Договорите носят референцията на договора, началните и крайните дати, сроковете за предизвестие и от двете страни, приложимото право, държавата на предоставяне, местата на данните и чувствителността на данните.
📋
Проследяване на клаузите по Article 30
Всяко договорно споразумение носи статус по Article 30 за всяка клауза, така че договор с липсващи клаузи е видим като запис в системата. Рисковата оценка на доставчика чете този статус и понижава доставчика, когато наборът от клаузи е непълен.
📈
Анализ на концентрацията
Концентрация на разходите по доставчик с флаг за праг на дела, зависимост на критичните функции от един или няколко доставчика, разбивка по държава и по място на данните, и индекс на Херфиндал-Хиршман върху разходите по доставчици с диапазони.
🔗
Вериги на подизпълнение
Подизпълнителите се записват срещу споразумението, под което стоят, с LEI на поддоставчика, държава, описание на услугата, места на данните, критичност и нивото във веригата.
🚪
Оценки за изход и заменяемост
Рисковите оценки на доставчиците носят оценка и обосновка за заменяемост, дали съществува план за изход, възможност за реинтеграция, въздействие при прекратяване, идентифицирани алтернативни доставчици и датата на следващия преглед. Договорите носят референция към стратегията за изход.
📋
Кампании с въпросници към доставчици
Кампании с въпросници, изпратени до доставчици по шаблони, обозначени с рамка, с статус за всеки доставчик, контакти и оценени отговори.
📊
xBRL-CSV експорт на регистъра
Експорт в структурата на таблиците по ITS (ЕС) 2024/2956 през всичките 15 официални шаблона, от B_01.01 до B_99.01, с оценка за пълнота и валидационни проблеми, показани още преди експорта, докато има време да ги поправите.
🔔
Одитна следа
Промените по записите се логват, което превръща “регистърът се поддържа” от твърдение в нещо, което можете да покажете.

Това, което платформата не прави, е да реши кои от вашите функции са критични или важни, нито да договори клаузите по Article 30(3) в договор, който вашият доставчик предпочита да не отваря отново. Тези неща са ваши. Това, което тя прави, е да гарантира, че щом сте взели тези решения, те са записани срещу споразумението, оцеляват през годината и излизат във формата, която регистърът очаква.
Изградете ИКТ регистъра върху модела на данни, който регламентът реално използва.
Доставчици, договори, функции, вериги на подизпълнение и оценки на риска като свързани записи, с проследяване на клаузите по Article 30 и xBRL-CSV експорт, изграден по 15-те официални шаблона.
Заявете демо →Първични източници
- Регламент (ЕС) 2022/2554 (DORA). Член 3(22), определение за критична или важна функция. Глава V, членове 28 до 44. Раздел I: член 28 общи принципи и регистърът, член 29 предварителна оценка на ИКТ концентрационния риск, член 30 ключови договорни разпоредби. Раздел II, членове 31 до 44: рамката за надзор върху критичните доставчици на ИКТ услуги от трети страни.
- Регламент за изпълнение (ЕС) 2024/2956 на Комисията. ITS, определящ стандартните шаблони за регистъра на информацията, по DORA член 28(9). Петнадесет шаблона, от B_01.01 до B_99.01.
- Делегиран регламент (ЕС) 2024/1773 на Комисията. RTS относно подробното съдържание на политиката за използването на ИКТ услуги, поддържащи критични или важни функции, по DORA член 28(10). Обхваща управлението, фазите на жизнения цикъл, предварителната оценка на риска, надлежната проверка, конфликтите на интереси, договорните клаузи, наблюдението, както и изхода и прекратяването.
- Делегиран регламент (ЕС) 2025/532 на Комисията. RTS относно елементите, които финансовият субект трябва да установи и оцени при подизпълнение на ИКТ услуги, поддържащи критични или важни функции, по DORA член 30(5).
- Делегиран регламент (ЕС) 2024/1774 на Комисията. RTS относно инструментите, методите, процесите и политиките за управление на ИКТ риска, което е рамката, вътре в която член 28(1) изисква да стои рискът от трети страни.
Тази статия е само за информация и не представлява правен или регулаторен съвет. Цитатите на членове са проверени спрямо текстовете в Официален вестник на 14 юли 2026 г. Техническите стандарти се изменят с течение на времето, затова потвърдете действащата версия, преди да разчитате на което и да е изискване, посочено тук.



