DORA: від класичної ІТ-безпеки до підтвердженої стійкості критично важливих наскрізних сервісів — включаючи ланцюжок постачання ІКТ та сторонніх постачальників.

Автор: NEXORA Unternehmensberatung GmbH Дата: січень 2026 року Час читання: прибл. 13 хвилин

Вступ та цільова аудиторія

З прийняттям Акта про цифрову операційну стійкість (DORA, Регламент (ЄС) 2022/2554) ЄС створив єдину базу для цифрової операційної стійкості фінансових установ. Окрім класичних компонентів, таких як управління ризиками ІКТ, звітність про інциденти, тестування та обмін інформацією, DORA вперше запроваджує загальноєвропейський нагляд за критично важливими сторонніми постачальниками ІКТ-послуг. Ця стаття орієнтована на членів правління, керівників, директорів із ризиків (CRO), директорів із інформаційних технологій (CIO), директорів із інформаційної безпеки (CISO) та відповідальних за аутсорсинг у банках, інвестиційних фірмах, платіжних установах, установах електронних грошей, страхових компаніях, пенсійних фондах, постачальниках криптопослуг, а також фінтех-компаніях, що працюють у ЄС. Вона висвітлює, що насправді змінюється на практиці завдяки DORA та новій системі нагляду за критично важливими сторонніми постачальниками ІКТ-послуг («критично важливими провайдерами»), включаючи нову співпрацю між ЄС та Великою Британією.

1. DORA — це більше, ніж «черговий комплаєнс-проєкт»

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

Ключове зрушення: від «у нас є ІТ-безпека та політики» до «ми можемо довести, що наші критичні наскрізні сервіси є стійкими» — включаючи людей, процеси, дані, постачальників, BCP/DR та відновлення у визначені RTO/RPO. На регуляторному рівні ризики ІКТ та аутсорсинг більше не розглядаються як допоміжні теми, а як основні ризики, що безпосередньо впливають на бізнес-модель, планування капіталу та управління.

2. Критично важливі сторонні постачальники ІКТ-послуг: кого це стосується — і чому навіть без прямого договору?

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

Класифікація як «критично важливого стороннього постачальника ІКТ-послуг» здійснюється Спільним комітетом європейських наглядових органів на основі гармонізованих критеріїв (зокрема, ризиків концентрації, системної важливості, можливості заміни, транскордонного значення). Для кожного критично важливого постачальника Комітет призначає провідний наглядовий орган (Lead Overseer — EBA, ESMA або EIOPA), орієнтуючись на найбільшу частку клієнтів за підсумком балансу.

Чому це реально стосується фінансових установ

• Тиск на контракти та управління зверху вниз: якщо постачальник (або субпідрядник у ланцюжку) класифікується як критично важливий, вимоги щодо прав на аудит, обов'язків інформування, тестування, прозорості інцидентів та субаутсорсингу фактично стають «наближеними до наглядових» — навіть якщо вони мають бути формально закріплені в B2B-контракті.

• Рішення щодо архітектури та сорсингу стають об'єктом нагляду: моделі з одним постачальником, відсутність портативності, пропрієтарні залежності та неперевірені плани виходу стають значно помітнішими під час перевірок і можуть бути безпосередньо оскаржені.

• Опосередковане охоплення («непрямий ланцюжок»): навіть якщо прямого договору з гіперскейлером немає (наприклад, SaaS через інтегратора), залишається відповідальність за розуміння ланцюжка ризиків, відображення прав контролю та забезпечення відповідності мінімальним вимогам DORA вздовж усього ланцюжка постачання.

3. Як працює новий нагляд за критично важливими постачальниками

Система нагляду за критично важливими сторонніми постачальниками ІКТ-послуг доповнює класичний нагляд за фінансовими установами «макропоглядом» на центральні ІКТ-вузли.

Ключові елементи:

• Класифікація та провідний наглядовий орган (Lead Overseer): Спільний комітет ESA готує класифікацію та призначення критично важливих постачальників і визначає провідний наглядовий орган для кожного з них.

• Завдання провідного наглядового органу: оцінка структур управління, безпеки та ризиків, запит інформації та документів, проведення розслідувань та перевірок на місцях, надання рекомендацій та заходів щодо усунення недоліків.

• Наслідки та витрати: якщо рекомендації не виконуються, національні органи нагляду можуть зобов'язати піднаглядні фінансові установи призупинити або припинити співпрацю з критично важливими постачальниками; витрати на нагляд несуть самі критично важливі постачальники.

Важливо для фінансових установ: прямий нагляд за критично важливими постачальниками не замінює власне управління ризиками сторонніх ІКТ-послуг, а створює додатковий потік інформації та наглядові імпульси («зверху вниз»), які необхідно враховувати у власному управлінні.

4. Від політики до «доказової бази»: чого конкретно очікує нагляд зараз

Багато вимог DORA вже були відомі через настанови EBA, ЄЦБ або національні очікування. Новим є рівень стандартизації — наприклад, через технічні стандарти щодо реєстрів аутсорсингу — та чітке очікування, що компанії можуть регулярно та документально підтверджувати ефективність контролю.

Три сфери, у яких командам потрібно реально посилити роботу:

4.1 Карта сервісів замість списку систем

Замість простого інвентарного списку систем органи нагляду очікують сервісного підходу: критично важливі функції/сервіси (наприклад, «миттєві платежі SEPA», «криптокастоді», «онбординг/KYC») з наскрізними потоками, RTO/RPO, класифікацією даних та чіткою структурою власників. Ці карти сервісів мають наочно демонструвати, які сторонні постачальники ІКТ-послуг залучені на кожному етапі — включаючи ланцюжки субпідрядників.

4.2 Обробка інцидентів як реальний операційний процес

DORA вимагає більшого, ніж просто визначені пороги звітності. Очікуються:

• працездатні інструкції (runbooks) із чіткими ролями та шляхами ескалації,

• моделі тріажу, які структуровано фіксують також інциденти сторонніх постачальників,

• каскади комунікації (внутрішні, клієнти, нагляд) та

• послідовний аналіз після інцидентів (post-mortems) із засвоєними уроками та підтвердженими покращеннями.

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

4.3 Тести на стійкість, які «мають бути відчутними»

Тести на стійкість згідно з DORA не повинні перетворюватися на формальність. Настільні вправи (tabletop), технічні тести (включаючи сценарії відмови із переходом на резерв за межами постачальника) та реалістичні збої — наприклад, вихід із ладу провайдера ідентифікації в піковий час — мають бути сплановані, проведені та пов'язані з чіткими заходами. Нагляд цікавиться не лише планом тестування, а й усім ланцюжком: результатами, рішеннями, станом впровадження та повторними тестами.

5. Ризик сторонніх сторін: нові мінімальні компоненти в контрактах та управлінні

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

Типові сфери для доопрацювання на практиці:

• Чіткість щодо критично важливих/важливих функцій: які сервіси до них належать, які постачальники від них залежать, як це відображено в контрактах та SLA.

• Права на аудит та інформацію (включаючи субпідрядників): права на перевірки на місцях, доступ до релевантної інформації, участь у тестах та симуляціях інцидентів, що можуть бути реалізовані також щодо субпідрядників.

• Вимірювані SLA/SLO та положення про інциденти: визначені часові рамки для повідомлень, мінімальний зміст (вплив, причини, заходи), доступ до інформації про першопричини принаймні на абстрактному рівні.

• Управління субаутсорсингом: прозорість щодо субпідрядників, механізми згоди/повідомлення, контроль ланцюжка вздовж усього ланцюжка постачання ІКТ.

• Стратегія виходу: портативність даних та робочих навантажень, допомога при переході, сценарії виходу, що піддаються тестуванню (наприклад, настільні вправи), та реалістичні припущення щодо витрат.

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

6. Транскордонна складність та «зачіпка» у вигляді Меморандуму про взаєморозуміння між ЄС та Великою Британією

Багато релевантних постачальників ІКТ, сервісів безпеки та підрозділів з надання послуг всередині груп базуються або працюють у кількох юрисдикціях (ЄС, Велика Британія, США, Азійсько-Тихоокеанський регіон). DORA — це право ЄС, але ланцюжки створення вартості та даних є глобальними.

14 січня 2026 року європейські наглядові органи (EBA, EIOPA, ESMA) та британські регулятори (BoE, PRA, FCA) підписали Меморандум про взаєморозуміння (MoU) щодо співпраці у сфері нагляду за критично важливими сторонніми постачальниками ІКТ-послуг або критично важливими третіми сторонами (CTP). MoU створює основу для обміну інформацією, узгодження наглядових дій та координації в ситуаціях інцидентів (наприклад, масштабних кібератак або відключень електроенергії).

Для чого MoU корисний на практиці, а для чого — ні:

• Корисний: він зменшує тертя між відомствами, полегшує послідовний нагляд за транскордонними структурами та може обмежити подвійні перевірки.

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

Прагматичний наслідок: транскордонні питання не повинні розглядатися як «другорядні юридичні деталі». Вони мають бути частиною дизайну постачальників та архітектури: які дані де зберігаються, хто може надати яку інформацію під час інциденту і наскільки швидко міграція реально можлива в найгіршому сценарії.

7. «Що мені робити завтра?» — план дій на 30/60/90 днів

Щоб перейти від аналізу до впровадження, добре зарекомендував себе поетапний підхід.

30 днів

• Визначити критично важливі сервіси (не лише системи), призначити власників сервісів, встановити цільові RTO/RPO.

• Скласти карту постачальників: прямі постачальники плюс основні субпідрядники, включаючи прив'язку до критично важливих сервісів.

• Швидка перевірка топ-10 контрактів: аудит/інформація, положення про інциденти, субаутсорсинг, застереження про вихід — де є очевидні прогалини.

60 днів

• Операціоналізувати процеси обробки інцидентів: інструкції (runbooks), матриця комунікацій, перші тести/настільні вправи із залученням ключових постачальників.

• Створити план тестування на стійкість: сценарії за межами постачальника, включаючи залежності від критично важливих та потенційно критично важливих постачальників.

• Запустити план виправлення контрактів: пріоритезація за критичністю, переговорною силою та часовими прогалинами щодо DORA.

90 днів

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

• Впровадити звітність KPI/KRI для ІКТ-ризиків та ефективності постачальників, узгоджену зі звітністю про ризики та управлінням ІТ.

• Сформувати пакети доказів для нагляду (політики, карти сервісів, реєстри аутсорсингу, результати тестів, документація інцидентів, підтвердження усунення недоліків).

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