DORA чл. 30: 12-те задължителни клаузи в договора с ИКТ доставчик (практически разбор за БГ финансовия сектор)
Alexander Sverdlov
Анализатор по сигурността
Ключови изводи
- DORA чл. 30 въвежда две групи договорни клаузи: задължителни за всички договори с ИКТ доставчик (ал. 2) и засилени за договори с доставчик, който подпомага критични или важни функции (ал. 3).
- Терминът "критична или важна функция" не е по преценка на доставчика. Дефинира се от финансовия субект в рамките на собствения му ИКТ риск процес и трябва да е записан в Регистъра на договорните споразумения по ал. 3.
- Право на одит на място, проактивно докладване на инциденти в рамките на срока на финансовия субект (24/72ч), exit план с осигурена непрекъсваемост, sub-outsourcing забележки и участие в TLPT за системно значими са петте най-често оспорвани клаузи в БГ договори. Всяка от тях е императивна, не само по препоръка.
- БНБ и КФН вече искат, при тематична надзорна проверка, всички договори с критични ИКТ доставчици в стандартизирана извадка. Липсата на чл. 30 клауза в действащ договор е самостоятелно нарушение, дори ако не е настъпил инцидент.
- Cloud договорите от чужбина (AWS, Microsoft, Google, Oracle, Salesforce) трябва да се предоговорят чрез DORA анекс. Всички четирима големи доставчика вече публикуват такъв анекс. Самият анекс не е достатъчен - изисква се изрично подписване и проверка дали покрива и засилените клаузи по ал. 3.
- 60-дневен преглед на портфолиото от договори е реалистична първа стъпка. Цена за външен правен и кибер преглед на 30 договора с критични доставчици: 18-42 хил. лв. Цена на нарушение, открито при надзорна проверка: до 2% от годишния оборот плюс репутационна щета.
През февруари ни се обади правен директор на платежна институция със седалище в София. На бюрото му стояха 47 договора с ИКТ доставчици, наследени от вече шест години оперативна дейност. Преди две седмици БНБ е направила тематична проверка по DORA готовност и е поискала всички договори с доставчици, които подпомагат "критични функции" - по дефиниция на самата платежна институция.
Институцията нямаше дефиниран процес да определи кой доставчик подпомага критична функция. Нямаше регистър по чл. 28 ал. 3. От 47-те договора, само 9 съдържаха клауза за право на одит. Три съдържаха exit клауза, и тя беше срочна, не безусловна. Нито един договор не споменаваше TLPT или докладване на инциденти в срок, съвместим със 72-часовия срок на самата институция към БНБ.
БНБ им даде 90 дни да представят план за предоговаряне с приоритет на критичните доставчици и допълнителни 90 дни за самото предоговаряне. Това е реалистичен срок само ако сте започнали миналата година. Те не бяха.
Тази статия е сборът от работата ни по 12 подобни проекта за български финансови субекти през последните 14 месеца - банки от средната група, платежни институции, инвестиционни посредници, една управляваща компания, един CASP по МиКА. Тя описва задължителните клаузи в DORA чл. 30, специфики за български контекст, червените флагове в стандартните анекси на големите cloud доставчици, и реалистичен 60-дневен план.
Контекст
Анатомия на чл. 30: задължителни и засилени клаузи
DORA чл. 30 е разделен на две алинеи с различно тегло. Ал. 2 изброява клаузите, които всеки договор с ИКТ доставчик трябва да съдържа - независимо от критичността. Ал. 3 описва допълнителните клаузи, които задължително присъстват, когато доставчикът подпомага критична или важна функция на финансовия субект. Ал. 4 указва, че при доставчик от трета страна (извън ЕС, ЕИП) важат същите изисквания плюс юрисдикционни клаузи.
Първият въпрос, който задаваме в проекта, винаги е: "Кой решава кой доставчик подпомага критична или важна функция?" Отговорът, който очакваме, е "ние, чрез нашия ИКТ риск процес, документирано в регистъра по чл. 28 ал. 3". В над 70 на сто от случаите отговорът е "не сме мислили за това", което е първият знак, че работата всъщност не е започнала.
Детайл
12-те клаузи: какво точно изисква всяка
Клауза 1. Ясно и пълно описание на ИКТ услугата. Не "cloud услуги по AWS Customer Agreement". Изброени услуги по име (RDS, S3, EC2, KMS, Lambda и пр.), region(s), AZ-broj, версии или service tiers, и какво точно обработват от данните на финансовия субект. Документ от 4-8 страници в анекс А.
Клауза 2. Локации на обработка и съхранение. Конкретни географски региони, не "globally". За критични функции с лични данни на български клиенти: или ЕС/ЕИП юрисдикция или изрично документиран механизъм за прехвърляне по GDPR чл. 46 (SCC, BCR, сертифициран DPF). Право на финансовия субект да забрани миграцията в нов регион без писмено съгласие.
Клауза 3. Защита на данните и поверителност. Не "съответствие с GDPR" в общи приказки. Конкретни технически и организационни мерки: криптиране в покой (минимум AES-256), криптиране при пренос (минимум TLS 1.2, препоръчително 1.3), управление на ключове (KMS), сегментация, мониторинг, контрол на достъпа. Обикновено приложение Б на договора.
Клауза 4. Достъп и поправка на лични данни. Срок за изпълнение на искания по чл. 15-22 GDPR. БНБ практика: до 5 работни дни за подпомагане на финансовия субект да отговори на правен срок от 30 дни към субекта на данни.
Клауза 5. SLA с измерими показатели. Налично време (uptime) с дефиниция на "downtime" (включително планова поддръжка); време за реакция и време за разрешаване по приоритет на инцидента; критерии за грешка; компенсации (service credits). За критични функции - SLA, който не позволява downtime над 4 часа в общ годишен период без активиран DR.
Клауза 6. Сътрудничество с надзорния орган. Доставчикът се задължава да предостави информация и достъп на компетентния орган (БНБ или КФН за български финансови субекти) при поискване. Включва ESA (EBA, ESMA, EIOPA) при операции на ниво ЕС. Включва Lead Overseer на критичен ИКТ доставчик от трета страна, ако се прилага.
Клауза 7. Прекратяване с осигурена непрекъсваемост. Право на едностранно прекратяване от страна на финансовия субект при определени условия (нарушение, регулаторно разпореждане, промяна в собствеността на доставчика). За критични функции: преходен период минимум 6 месеца, по време на който доставчикът продължава да изпълнява услугата на текущите условия, докато финансовият субект мигрира.
Клауза 8. Обучения и осведоменост за сигурност. Доставчикът обучава своя персонал, който има достъп до системи на финансовия субект, в политики и процедури по сигурност съвместими с тези на финансовия субект. Документирано доказателство веднъж годишно.
Клауза 9 (засилена). Право на достъп, проверка и одит на място. Това е клаузата, която cloud доставчиците най-често ограничават. DORA изисква безусловно право, но позволява разумни ограничения за защита на данните на други клиенти, конфиденциалност и оперативни рискове. Приемливо: одиторски пул, общи стандартизирани одити (CSA STAR, ISO 27001, SOC 2 Type II) плюс право на одит на място по искане на регулатора. Неприемливо: "одит само чрез предоставени SOC 2 доклади". БНБ ясно е дала пример, че SOC 2 само не покрива тази клауза.
Клауза 10 (засилена). Срокове за докладване на инциденти. Договорът трябва да задължава доставчика да докладва ИКТ инциденти, които касаят финансовия субект, в срок, който позволява на финансовия субект да изпълни своите регулаторни срокове по чл. 19 DORA: 24 часа за класификация, 4 часа за първоначално уведомление след класификация, 72 часа за междинен доклад. На практика това значи доставчикът ще има 2-6 часа за първоначално уведомление към финансовия субект, в зависимост от вида на инцидента.
Клауза 11 (засилена). Участие в TLPT тестове. Threat-Led Penetration Testing по чл. 26 DORA се прилага за системно значими институции (определят се от компетентния орган). Доставчикът се задължава да участва, ако TLPT тестът обхваща системи, които той подпомага. БНБ е посочила (юли 2025) кои са системно значими в България: 4-те най-големи банки + БИСЕРА + БОРИКА. Ако вашата компания не е в този списък, клаузата може да е условна ("при бъдеща обхватна промяна").
Клауза 12 (засилена). Exit стратегия и непрекъсваемост. Документиран план за миграция (от страната на финансовия субект) и техническо съдействие (от страна на доставчика) при прекратяване. Минимум: износ на данни в стандартен открит формат, без допълнителна такса; запазване на данните за период минимум 3 месеца след прекратяване; пълно изтриване с доказателство (cryptographic erasure attestation); съдействие при идентифициране на алтернативен доставчик.
Sub-outsourcing - същинският тест
Чл. 30 ал. 3 буква (f) изисква доставчикът да уведомява финансовия субект за всяко sub-outsourcing на критични дейности и да получава одобрение преди промяна. Това е клаузата, която AWS DORA анекс е смекчил най-силно - те се задължават да уведомят, но не да получават одобрение. Решението: да се добави изрично право на финансовия субект да прекрати договора при sub-outsourcing към доставчик, който не е приемлив по риск процеса. Това е приемлив компромис.
Чек-лист
Бърз тест: преглеждате ли договор или го пишете отначало
В работата ни с български финансови субекти типично откриваме, че договорите написани преди 2023 г. покриват 3-5 от 12-те клаузи; договорите от 2024 г. на български доставчици покриват 6-8; договорите с големите cloud доставчици (AWS, Microsoft, Google) с DORA анекс покриват 9-11. Никой не покрива всички 12 от първа версия. Това не е катастрофа - това е нормално. Целта на проекта не е перфекция, а документиран процес за прегъоговаряне с приоритети.
Класификация
Как да решите кой доставчик подпомага "критична или важна функция"
DORA не дава готов списък. Дефиницията се конструира от чл. 3 (т. 22 - критична или важна функция) и от EBA/EIOPA/ESMA Joint Guidelines on outsourcing. На практика въпросите за български финансов субект са: "Ако този доставчик спре да работи в продължение на 4 часа, ще се отрази ли на договорено ниво на услуга към наш клиент или регулатор?" Ако отговорът е "да", доставчикът подпомага критична или важна функция.
Решетката не е изчерпателна, но в практиката ни е достатъчна да отдели реалните 15-20 на сто от доставчиците, които изискват пълните клаузи на ал. 3, от останалите 80-85 на сто, при които ал. 2 е достатъчна. Класификацията се документира в регистъра по чл. 28 ал. 3 и се преглежда най-малко веднъж годишно.
Внимание
Червени флагове в стандартните DORA анекси на cloud доставчиците
AWS, Microsoft, Google и Oracle публикуваха стандартни DORA анекси през 2024 и началото на 2025. Тези анекси са приемливи в общия случай, но имат специфики, които изискват българско правно внимание.
1. "Pooled audit" вместо индивидуален одит
Анексите често предлагат участие в груповия одит, координиран от ECB или ESA. Това е приемливо за индивидуалния клиент, но не отменя правото на компетентния орган (БНБ или КФН) да поиска индивидуален одит при тематична проверка. Добавете изрична клауза, че pooled audit не изключва индивидуално право на надзорния орган.
2. "Without prejudice to AWS Customer Agreement"
AWS DORA анексът се прилага "без да нарушава" основния customer agreement. Това означава, че при противоречие може да се претендира предимство на основния договор. Добавете в българската версия клауза, че при противоречие DORA анексът има предимство. Microsoft Online Services DPA вече има подобна клауза, AWS - не.
3. Sub-outsourcing уведомление без одобрение
Стандартните анекси изискват само уведомление за sub-outsourcing на критични дейности. Чл. 30 ал. 3 буква (f) изисква и одобрение. Реалистичен компромис, който приемаме при преговори: уведомление 60 дни предварително плюс право на едностранно прекратяване от страна на финансовия субект, ако новият sub-processor не е приемлив.
4. Срокове за докладване "промптно"
Стандартни анекси често ползват думата "промптно" (без часов срок). Това не работи с 4-часовия срок за първоначално уведомление по чл. 19 DORA. Добавете изрично: "не по-късно от 2 часа след установяване на инцидент с потенциално регулаторно значение за финансовия субект".
5. Exit план без техническа спецификация
"Reasonable assistance at standard rates" не е exit план. Добавете изрично: списък на форматите за износ (Parquet, CSV, JSON, native database backups), времеви срокове, че износът е безплатен или на капов разход (не "почасова работа на инженери"), и cryptographic erasure attestation при изтриване.
План
60-дневен план за преглед и предоговаряне на портфолиото
Цената не е малка, но е по-малка от глобата по чл. 50 DORA (до 2 на сто от годишния оборот за нарушение на чл. 28-30) и значително по-малка от оперативния разход при принудително прекратяване на договор с критичен доставчик по разпореждане на регулатора.
Как Атлант Сикюрити помага
DORA чл. 30 преглед на портфолиото от договори
Извършваме пълен преглед и подпомагане при предоговарянето на договори с ИКТ доставчици по DORA чл. 30 за български банки, платежни институции, инвестиционни посредници, застрахователи, пенсионни дружества и CASP по МиКА. Резултатът е попълнен регистър по чл. 28 ал. 3, документиран gap анализ на всеки договор, и преговорни позиции за критичните доставчици, готови за изпращане.
- Фиксирана цена, обхватът се пише преди подписване на договор
- Старши консултанти само, никога стажанти
- Преглед на правни и технически клаузи в един екип
- Предаваме документация, готова за БНБ или КФН проверка
- Плащане поетапно, не предварително
Често задавани въпроси
Въпроси, които ни задават всяка седмица
Може ли DORA анексът на AWS / Microsoft / Google да се ползва без промени?
В общия случай покрива клаузите по ал. 2 и значителна част от ал. 3, но винаги добавяме поне 4-6 български специфики: предимство на DORA анекса при противоречие с основния customer agreement, право на сътрудничество с БНБ или КФН, изричен срок за докладване на инциденти (не "промптно"), и техническа спецификация на exit плана. Без тези добавки анексът оставя експозиция при надзорна проверка.
Колко са глобите по чл. 50 DORA?
До 2 на сто от общия годишен оборот за нарушения на чл. 28-30, до 1 на сто за по-леки нарушения. Глобите се налагат от компетентния орган (БНБ или КФН). За критичен ИКТ доставчик от трета страна, ESA може да наложи периодична санкция до 1 на сто от средния дневен оборот в световен мащаб. Глобите се суматизират с тези по GDPR, ако нарушението обхваща и лични данни.
Колко често се преглежда регистърът по чл. 28 ал. 3?
Минимум веднъж годишно и при всяко добавяне на нов доставчик, прекратяване на договор, преструктуриране на услуга или промяна в класификацията на критичност. БНБ и КФН могат да изискат регистъра по образец на Регламент за изпълнение (ЕС) 2024/2956 на годишна база. Подаването е чрез системите на регулатора (за БНБ - чрез единната платформа за надзорно докладване).
Прилага ли се DORA чл. 30 за доставчик, при който не съхраняваме данни на клиенти?
Да. DORA не ограничава приложното поле до доставчици, които съхраняват клиентски данни. Прилага се за всеки ИКТ доставчик, който подпомага функция на финансовия субект, включително вътрешни системи, ERP, HR, счетоводен софтуер, мониторинг, развойна среда. Класификацията дали функцията е критична или важна е отделен въпрос. Регистърът обхваща всички договори, не само тези с обработка на лични данни.
Какво се случва, ако доставчикът откаже да предоговори по DORA?
При критична функция, нямате избор - DORA задължава финансовия субект да има клаузите по ал. 3 в действащ договор. Опциите са: (1) преговори с допускане на компромиси, които не нарушават съществения смисъл на клаузата (sub-outsourcing с уведомление вместо одобрение е приемлив компромис); (2) при невъзможност, миграция към друг доставчик в рамките на разумен срок, документирана в exit план; (3) ако критичност не може да се избегне и доставчикът е монополист, документиран риск с компенсиращи контроли и уведомление на компетентния орган. Третата опция е изключение, не правило.
Има ли облекчение по принципа на пропорционалност за малки финансови субекти?
Чл. 4 DORA въвежда принципа на пропорционалност за микропредприятия (по чл. 2 ал. 3 на Препоръка 2003/361/ЕО - под 10 служители и под 2 млн. евро годишен баланс). Те имат опростен режим за някои изисквания, но не и за чл. 30 договорни клаузи. Задължителните клаузи по ал. 2 и засилените по ал. 3 се прилагат еднакво за всички финансови субекти, независимо от размера. Само честотата на одитите, обемът на документацията и сложността на тестванията се мащабират пропорционално.
DORA чл. 30 не е документ, който се решава с един "DORA анекс". Това е процес: класификация на доставчиците по критичност, попълнен и поддържан регистър, документиран gap анализ срещу 12-те клаузи, преговорни позиции за критичните доставчици, и квартален преглед. Първата итерация е тежка - 60 до 90 дни за средно голяма институция. Следващите итерации са рутина.
БНБ и КФН са настроени да гледат портфолиото на договорите при следващата тематична проверка. Имате ли документиран процес или не - това е въпросът, на който ще трябва да отговорите. Документираният процес с пропуски е значително по-добра позиция от липсата на процес. Целта на тази статия е да ви даде структурата, по която документираният процес се изгражда.
Имате тематична проверка по DORA в близкия хоризонт? Запишете 30-минутна консултация или пишете на alexander@atlantsecurity.com.
Александър Свердлов
Основател на Atlant Security. Автор на 2 книги за информационна сигурност, лектор по киберсигурност на най-големите конференции по киберсигурност в Азия и панелист на конференция на ООН. Бивш член на екипа за консултации по сигурността на Microsoft, външен консултант по киберсигурност в Емиратската корпорация за ядрена енергия.