DORA для українських IT-компаній: що змінюється, якщо ваш клієнт — банк у ЄС

Що таке DORA і кого він стосується

DORA (Digital Operational Resilience Act) це Регламент (ЄС) 2022/2554 про цифрову операційну стійкість фінансового сектору. Він застосовується з 17 січня 2025 року до широкого кола фінансових установ ЄС: банків, платіжних і е-грошових установ, інвестиційних фірм, страховиків, постачальників криптоактивних послуг та інших. Окремий режим прямого нагляду передбачено для критичних постачальників ICT-послуг, яких визначають європейські наглядові органи (ESAs).

Регламент вимагає від фінансових установ керувати ризиками ICT, класифікувати й повідомляти про серйозні інциденти, тестувати стійкість і, що найважливіше для підрядників, керувати ризиками третіх сторін. Саме ця частина, глава V, пояснює, чому вимоги DORA доходять до компаній у Львові, Києві чи Дніпрі.

Чому українська IT-компанія відчує DORA, навіть не будучи в ЄС

Українська компанія, яка не є фінансовою установою ЄС і не визначена критичним постачальником, не несе прямих обов'язків за DORA. Відповідальність лежить на клієнті: фінансова установа залишається повністю відповідальною за дотримання регламенту, навіть якщо передає функції на аутсорсинг. Тому банк перекладає свої обов'язки на постачальника через договір, анкети due diligence і регулярний моніторинг.

На практиці це означає: оновлені рамкові договори та додатки, питання про розташування даних і субпідрядників, запити на звіти про тестування, вимоги повідомляти про інциденти в короткі строки. Для постачальника з третьої країни банк також оцінює юридичні ризики, зокрема можливість виконати договір і забезпечити доступ до даних у разі проблем. Готовність відповісти на ці питання швидко і документально стає конкурентною перевагою.

Стаття 28: загальні принципи роботи з ICT-постачальниками

Стаття 28 зобов'язує фінансову установу мати стратегію щодо ризиків третіх сторін, проводити оцінку до укладення договору і вести реєстр інформації про всі договірні домовленості щодо ICT-послуг. Для вас це означає детальну анкету перед підписанням і регулярні оновлення даних протягом співпраці.

Для послуг, що підтримують критичні або важливі функції, стаття 28 також вимагає стратегій виходу: банк має бути здатен припинити співпрацю без порушення своєї діяльності та якості обслуговування клієнтів. Також визначено підстави для розірвання договору, наприклад суттєве порушення закону чи умов договору або обставини, що впливають на виконання послуг.

• Очікуйте запитів щодо юридичної структури, власників, фінансової стабільності та місць надання послуг.
• Будьте готові пояснити, які послуги ви надаєте і чи підтримують вони критичні або важливі функції клієнта.
• Підготуйте опис того, як клієнт може забрати дані, код і документацію при завершенні договору.

Стаття 29 і субпідряд: концентраційний ризик і ланцюжок постачальників

Стаття 29 вимагає від фінансових установ оцінювати концентраційний ризик ICT, тобто залежність від одного постачальника або від групи пов'язаних постачальників. Окремо регламент звертає увагу на довгі ланцюжки субпідряду і на постачальників із третіх країн, зокрема на питання застосовного права та виконання договору у разі неплатоспроможності.

Для української IT-компанії це означає прозорість щодо субпідрядників. Якщо частину роботи виконують фрилансери, партнерська компанія чи хмарний провайдер, клієнт захоче знати, хто вони, де обробляються дані і як ви контролюєте їхню роботу. Європейські органи підготували окремі технічні стандарти щодо умов субпідряду для критичних або важливих функцій. Точну редакцію та дату застосування перевіряйте на EUR-Lex або уточнюйте в клієнта.

Стаття 30: пункти, які з'являться у вашому договорі

Стаття 30 перелічує обов'язкові умови договору з ICT-постачальником. Частина з них стосується всіх ICT-послуг, а частина додається, якщо послуга підтримує критичну або важливу функцію. Уточнення щодо політики договірних домовленостей містить Делегований регламент (ЄС) 2024/1773.

• Чіткий опис функцій і послуг, а також умови субпідряду.
• Місця надання послуг і обробки даних, з обов'язком повідомляти про зміну.
• Положення про доступність, цілісність, безпеку і конфіденційність даних, зокрема персональних.
• Забезпечення доступу до даних і їх повернення у разі неплатоспроможності, припинення діяльності чи розірвання договору.
• Описи рівня обслуговування, для критичних функцій з точними кількісними і якісними показниками.
• Допомога клієнту у разі ICT-інциденту без додаткової оплати або за заздалегідь визначеною ціною.
• Співпраця з компетентними органами клієнта, права на розірвання договору і мінімальні строки повідомлення.
• Участь у програмах підвищення обізнаності з безпеки ICT і тренуваннях з операційної стійкості клієнта.
• Для критичних функцій: обов'язок повідомляти про події, що впливають на послуги, плани безперервності бізнесу та їх тестування, участь у тестуванні на проникнення (TLPT), необмежені права доступу, інспекції та аудиту, а також стратегія виходу з перехідним періодом.

Реєстр інформації та повідомлення про інциденти

Кожна фінансова установа веде реєстр інформації про договори з ICT-постачальниками за шаблонами, визначеними Імплементаційним регламентом (ЄС) 2024/2956. До реєстру потрапляють дані про вас як постачальника: ідентифікатори юридичної особи (часто просять LEI), країна, тип послуг, функції, які вони підтримують, субпідрядники в ланцюжку. Регулятори збирають ці реєстри для аналізу, тому клієнт попросить у вас точні та актуальні дані.

Щодо інцидентів: повідомляти регулятора про серйозні ICT-інциденти зобов'язана фінансова установа. Але вона не зможе вкластися в короткі строки, якщо постачальник повідомить її із запізненням. Тому в договорах з'являються жорсткі строки внутрішнього повідомлення, вимоги до змісту звіту і співпраці під час розслідування. Налаштуйте процес так, щоб інцидент у вашій інфраструктурі або коді, що впливає на клієнта, швидко потрапляв до відповідальної людини і далі до клієнта.

Чекліст для аутсорсингової IT-компанії

Наведений перелік допоможе підготуватися до due diligence і перемовин щодо договору. Почніть із клієнтів, для яких ви підтримуєте критичні процеси: платежі, кредитування, обслуговування клієнтів, core banking.

Безкоштовна самооцінка на baltum.ai показує, наскільки ваші процеси відповідають очікуванням DORA, і формує перелік прогалин для роботи.

• Складіть реєстр своїх послуг для фінансових клієнтів і визначте, які з них підтримують критичні або важливі функції.
• Задокументуйте субпідрядників і хмарних провайдерів, місця обробки даних і доступ персоналу до систем клієнта.
• Опишіть процес управління інцидентами з ролями, строками внутрішньої ескалації та шаблоном повідомлення клієнту.
• Підготуйте план безперервності бізнесу з урахуванням відключень електроенергії, зв'язку і релокації команди, і протестуйте його.
• Сформуйте пакет доказів безпеки: політики, результати тестів на проникнення, звіти про резервне копіювання, сертифікати, якщо є (наприклад ISO/IEC 27001).
• Підготуйте план виходу: передача коду, даних, документації та знань, строки перехідного періоду.
• Визначте, як ви забезпечите права клієнта і його регулятора на аудит та інспекції, включно з віддаленим форматом.
• Перевірте стандартні договори юристом, який знає вимоги статті 30.

Як перетворити DORA на перевагу в продажах

Для європейських банків вибір постачальника тепер частково є регуляторним рішенням. Компанія, яка на першій зустрічі показує карту субпідрядників, протестований план безперервності та готовий DORA-додаток до договору, скорочує цикл закупівлі і знижує ризик для клієнта.

Не варто обіцяти більше, ніж ви можете виконати. Необмежені права аудиту чи дуже короткі строки повідомлення про інциденти мають бути реалістичними для вашої команди. Краще узгодити конкретний механізм, ніж підписати пункт, який ви порушите на першому ж інциденті.

Стаття має інформаційний характер і не є юридичною консультацією. baltum.ai — незалежне програмне забезпечення, а не орган із сертифікації.