DORA в Австрії/ЄС: Хто підпадає під дію та 10 кроків до мінімальної відповідності

Автор: Команда NEXORA Дата: грудень 2025 Час читання: прибл. 12 хвилин

Короткий опис

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

Для осіб, які приймають рішення:

• Хто підпадає під дію: DORA застосовується з 17 січня 2025 року до майже всіх фінансових установ, що перебувають під наглядом у ЄС (банки, платіжні установи, установи електронних грошей, страхові компанії, інвестиційні фірми, постачальники криптопослуг тощо), а також опосередковано до їхніх постачальників ІКТ-послуг. Постачальники, класифіковані як «критичні сторонні постачальники ІКТ», підпадають під європейську систему нагляду з боку ESA.

• Мінімальна відповідність: Функціональна базова система включає: задокументовану політику ІКТ-ризиків та інтеграцію в загальне управління ризиками, визначений процес управління інцидентами з чіткими каналами звітності, повний реєстр аутсорсингу/ІКТ (Register of Information), чіткі ролі та відповідальність на рівні керівництва, регулярні тести стійкості, а також процеси належної перевірки та моніторингу для сторонніх постачальників ІКТ.

• Часова шкала: DORA застосовується безпосередньо в усіх державах-членах ЄС з 17 січня 2025 року. В Австрії повний Register of Information вперше необхідно було подати до FMA до 31 березня 2025 року (згідно з поточною комунікацією FMA, станом на грудень 2024 року). Постійна відповідність означає безперервне оновлення всіх артефактів, щорічні перегляди та адаптацію до нових RTS/ITS ESA.

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

• Наслідки невідповідності: Недостатнє впровадження може призвести до наглядових заходів, зокрема: вимоги планів покращення, інспекцій на місці (спільно з OeNB/FMA), адміністративних санкцій, репутаційних ризиків, а також операційних збоїв через невирішені залежності від ІКТ. Відсутність доказів ІКТ-стійкості може також негативно вплинути на ділові відносини із замовниками.

1. Контекст та чому ця тема актуальна зараз (AT/ЄС)

Регламент (ЄС) 2022/2554 – Закон про цифрову операційну стійкість (DORA) безпосередньо застосовується в усіх державах-членах ЄС з 17 січня 2025 року. DORA закриває центральну прогалину в європейському праві фінансового нагляду: якщо після фінансової кризи 2008 року зміцнювалася переважно фінансова стійкість (капітал, ліквідність), ризики, пов'язані з ІКТ, залишалися закріпленими у фрагментованих національних нормах. З посиленням цифровізації фінансового сектору – використання хмарних технологій, послуг на основі API, аутсорсингу критичних функцій – операційна стійкість до кіберзагроз та ІТ-збоїв стала системною проблемою.

DORA гармонізує вимоги до цифрової операційної стійкості на рівні ЄС і вперше безпосередньо інтегрує сторонніх постачальників ІКТ у систему нагляду. Для австрійських установ це означає: FMA (Управління фінансового ринку) контролює дотримання DORA в тісній співпраці з OeNB (Національний банк Австрії). FMA працює, зокрема, з опитуваннями щодо цифрового ландшафту та залежностей від ІКТ в Австрії; деталі випливають із поточних публікацій FMA та форматів нагляду.

Актуальність для 2025 року: Компанії повинні не лише продемонструвати формальну відповідність, але й встановити суттєві процеси. Нагляд перевіряє не «паперову відповідність», а очікує доказового впровадження в управлінні, тестуванні, управлінні інцидентами та нагляді за третіми сторонами.

2. Хто підпадає під дію? (Сфера застосування)

Фінансові установи згідно зі ст. 2 DORA

DORA застосовується згідно зі статтею 2 до широкого спектру фінансових установ («financial entities»), зокрема:

• Кредитні установи (ст. 2 п. 1 літ. a) – наприклад, банки, будівельно-ощадні каси

• Платіжні установи та установи електронних грошей (літ. b–c) – також FinTech з платіжною ліцензією

• Інвестиційні фірми (літ. d)

• Постачальники послуг криптоактивів (CASP) згідно з регламентом MiCA (літ. e)

• Центральні контрагенти (CCP), центральні депозитарії цінних паперів (CSD), торговельні майданчики (літ. f–h)

• Керуючі інвестиційними фондами (AIFM, UCITS-ManCos) (літ. i–j)

• Страхові та перестрахові компанії, страхові посередники (літ. k–m)

• Установи професійного пенсійного забезпечення (IORP) (літ. n)

• Рейтингові агентства, адміністратори критичних бенчмарків, постачальники краудфандингових послуг, служби надання даних (літ. o–s)

• Реєстри сек'юритизації (літ. t)

Принцип пропорційності: DORA передбачає (обмежену) пропорційність (ст. 4). Мікропідприємства («microenterprises»: <10 працівників, <2 млн євро обороту/балансу) мають полегшені вимоги, але залишаються в сфері застосування. Торговельні майданчики, CCP, CSD, TR виключені з пропорційності.

Постачальники ІКТ-послуг: звичайні та «критичні»

DORA стосується постачальників ІКТ-послуг опосередковано та безпосередньо:

Опосередковано: Усі сторонні постачальники ІКТ («ICT third-party service providers»), які надають ІКТ-послуги фінансовим установам, залучаються до відповідності DORA через договірні зобов'язання фінансових установ (ст. 28, 30):

• Права аудиту для фінансових установ та наглядових органів

• Вимоги до безпеки та стійкості

• Зобов'язання щодо звітності про інциденти

• Стратегії виходу, повернення даних, сумісність

Безпосередньо – «Критичні сторонні постачальники ІКТ»: Постачальники, класифіковані ESA (EBA, ESMA, EIOPA) як критичні, підпадають під європейську систему нагляду (ст. 31 і далі). Критерії класифікації як «критичних» (ст. 31 п. 2) включають:

• Системне значення (скільки фінансових установ використовують постачальника?)

• Системний вплив у разі збою

• Відсутність простих альтернатив (ризик концентрації/залежності)

ESA визначатимуть критичних сторонніх постачальників ІКТ на основі встановлених критеріїв (станом на грудень 2024 року: перші призначення очікуються на 2025 рік). Для цих постачальників провідний наглядовий орган (один з ESA) здійснює наглядові заходи: запити інформації, інспекції, рекомендації щодо зменшення ризиків. Однак фінансові установи завжди залишаються головними відповідальними за управління ризиками третіх сторін.

Практичні приклади

Приклад 1 – Австрійський банк з хмарним аутсорсингом: Середній австрійський банк (кредитна установа згідно з CRR/CRD) передає свої основні банківські системи та обробку платежів двом постачальникам хмарних послуг. Банк є фінансовою установою DORA. Він повинен:

• Вести обох постачальників хмарних послуг у реєстрі ІКТ (з усіма полями DORA/FMA, включаючи критичність, суб-аутсорсинг)

• Перевірити договори на наявність положень DORA (права аудиту, вихід, безпека)

• Провести належну перевірку та здійснювати постійний моніторинг

• Якщо один із постачальників хмарних послуг буде визначений як «критичний», банк повинен інтегрувати рекомендації провідного наглядового органу у своє управління третіми сторонами.

Приклад 2 – FinTech платіжна установа з SaaS-системою: Платіжна установа, ліцензована в Австрії (згідно з ZaDiG 2018 / PSD2), використовує SaaS-систему спеціалізованого постачальника. Платіжна установа є фінансовою установою DORA. SaaS-постачальник надає «критичну або важливу функцію» (обробка платежів). Платіжна установа повинна:

• Визначити політику ІКТ-ризиків та стратегію тестування

• Вести SaaS-постачальника в реєстрі, документувати належну перевірку

• Забезпечити договірні положення про вихід та сумісність

• Повідомляти про серйозні ІКТ-інциденти (наприклад, збій SaaS-системи) згідно зі ст. 19 до FMA.

Не фінансова установа, але підпадає під дію: Чистий постачальник програмного забезпечення (наприклад, виробник Core-Banking-SaaS) без власної фінансової ліцензії не є фінансовою установою DORA. Однак якщо він класифікується багатьма банками як критичний і відповідає критеріям «критичної третьої сторони ІКТ», він підпадає під нагляд ESA.

3. Що означає «мінімальна відповідність»? (Визначення + цільовий образ)

Визначення

«Мінімальна відповідність» – це найменший послідовний та доказовий набір елементів управління, політик, процесів, реєстрів та артефактів, за допомогою якого фінансова установа може продемонструвати наглядовим органам, внутрішнім/зовнішнім аудиторам та зацікавленим сторонам, що базові вимоги DORA впроваджуються серйозно, систематично та пропорційно.

«Мінімальна» не означає «недостатня», а скоріше:

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

• Фокус на суті, а не на обсязі

• Пропорційно до розміру, складності та профілю ризику компанії

• Масштабовано: Мінімальна система є основою для майбутнього підвищення рівня зрілості.

Цільовий образ мінімальної відповідності

Мінімальна система зазвичай включає:

• Система управління ІКТ-ризиками

• Задокументована політика ІКТ-ризиків (інтегрована в загальне управління ризиками)

• Інвентаризація ІКТ- та інформаційних активів

• Методологія оцінки ризиків (включаючи застарілі системи, ризики концентрації)

• Розподіл ролей та відповідальності (керівний орган, CISO/відповідальні за ІКТ, контрольні функції)

• Визначена політика безперервності бізнесу ІКТ та плани відновлення

• Управління інцидентами та звітність

• Процес класифікації ІКТ-інцидентів (відповідно до делегованого регламенту (ЄС) 2024/1772)

• Визначення «серйозного ІКТ-інциденту» з чіткими порогами

• Внутрішні шляхи ескалації, ролі (наприклад, CISO, команда реагування на інциденти)

• Інтерфейс для повідомлення FMA (початкове повідомлення, проміжний/остаточний звіт згідно з делегованим регламентом (ЄС) 2025/301)

• Процес добровільного повідомлення про значні кіберзагрози

• Тестування та стійкість

• Стратегія тестування, що охоплює різні типи тестів:

• Оцінка вразливостей, тести на проникнення

• Тестування на основі сценаріїв

• За необхідності тестування на проникнення на основі загроз (TLPT) згідно зі ст. 26 для значних установ (щонайменше кожні 3 роки)

• Задокументовані результати тестів та плани усунення недоліків

• Процес перегляду результатів тестування на рівні керівництва

• Управління ризиками третіх сторін

• Політика ризиків сторонніх постачальників ІКТ (стратегія згідно зі ст. 28 DORA)

• Повний Register of Information (реєстр аутсорсингу/ІКТ) згідно з регламентом про впровадження (ЄС) 2024/2956, включаючи:

• Усіх сторонніх постачальників ІКТ (також суб-аутсорсинг)

• Класифікацію за критичністю

• Деталі договору, SLA, положення про вихід

• Процес належної перевірки перед укладенням договору

• Постійний моніторинг (KPI, дотримання SLA, звіти про інциденти від сторонніх постачальників)

• Стратегія виходу та плани на випадок непередбачених обставин для критичних домовленостей про аутсорсинг

• Управління та ролі

• Відповідальність керівного органу: Формальне затвердження політики ІКТ-ризиків, стратегії DORA, бюджету, плану тестування

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

• Лінії звітності: регулярні управлінські звіти про ІКТ-ризики, інциденти, тестування, моніторинг третіх сторін

• Обізнаність та навчання: Програми навчання для співробітників, керівництва та (де доречно) сторонніх постачальників ІКТ

• Укладення договорів та нагляд за постачальниками

• Шаблони договорів/стандартні положення для ІКТ-послуг, що інтегрують вимоги DORA (див. нижче розділ «Укладення договорів»)

• Процеси для переговорів, моніторингу та адаптації договорів

• Документація та докази

• Пакет доказів: Структурований набір підтверджувальних документів для внутрішньої/зовнішньої перевірки та нагляду (див. артефакт для завантаження нижче)

• Управління змінами для політик та процесів

• Постійне вдосконалення: Уроки, отримані з інцидентів, тестів, аудитів

Важливо: Мінімальна система – це не статична ціль, а відправна точка. Компанії повинні регулярно (щонайменше щорічно) переглядати свою систему, адаптувати її до регуляторних оновлень (нові RTS/ITS) та розвивати в рамках моделей зрілості.

4. Дорожня карта «10 кроків» до мінімальної відповідності

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

Крок 1: З'ясувати сферу застосування та ролі

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

Типові докази/артефакти:

• Статут проєкту DORA з визначенням сфери застосування

• Матриця зацікавлених сторін (ролі, відповідальність, RACI)

• Список компаній, на які поширюється дія (у групах)

• Логіка консолідації для звітів (наприклад, рівень групи)

Поширені помилки:

• Сфера застосування визначена занадто вузько (наприклад, лише ІТ, а не операційний ризик, закупівлі, юридичний відділ)

• Керівний орган не залучений на ранньому етапі

• Нечіткі обов'язки між материнською компанією та дочірніми підприємствами

---

Крок 2: Формально закріпити управління та відповідальність керівного органу

Мета кроку: Забезпечити, щоб керівний орган (правління/керівництво) формально взяв на себе відповідальність за ІКТ-ризик та DORA, як вимагається у ст. 5 DORA.

Типові докази/артефакти:

• Рішення правління/керівництва щодо стратегії DORA

• Організаційний посібник/регламент з обов'язками DORA

• Планування ресурсів (бюджет, персонал) для впровадження DORA

• Шляхи ескалації для серйозних інцидентів (CISO → керівний орган)

Поширені помилки:

• Керівний орган розглядає DORA як «ІТ-тему» без власної відповідальності

• Відсутнє чітке призначення на відділ правління/керівника

• Відсутня документація рішень керівного органу

---

Крок 3: Провести аналіз прогалин

Мета кроку: Порівняти існуючу систему управління ІКТ-ризиками, безпеки та аутсорсингу з вимогами DORA. Визначити, що вже є (наприклад, з ISO 27001, настанов EBA щодо аутсорсингу, NIS2) і де існують прогалини.

Типові докази/артефакти:

• Звіт про аналіз прогалин (вимоги DORA проти фактичного стану)

• Пріоритизований список заходів з відповідальними та термінами

• Зіставлення існуючих політик/процесів зі статтями DORA

• Реєстр ризиків для виявлених прогалин

Поширені помилки:

• Аналіз на рівні документів без перевірки практики («паперовий комплаєнс»)

• Відсутність пріоритезації за ризиками та релевантністю для нагляду

• Відсутність залучення бізнес-підрозділів та профільних відділів (тільки ІТ)

---

Крок 4: Визначення/оновлення політики та методології управління ІКТ-ризиками

Мета кроку: Адаптація існуючої політики ІКТ-ризиків або створення нової політики відповідно до ст. 6 DORA. Інтеграція в загальну систему управління ризиками.

Типові докази/артефакти:

• Політика управління ІКТ-ризиками (затверджена органом управління), що охоплює:

• Категорії ризиків (наприклад, кіберризики, доступність систем, цілісність даних, треті сторони)

• Методологія оцінки ризиків (ймовірність/вплив)

• Апетит до ризику/толерантність

• Ролі та відповідальність

• Механізми ескалації

• Безперервний моніторинг та звітність

• Інвентаризація активів (ІКТ- та інформаційні активи)

• Реєстр ризиків (ІКТ-ризики)

Поширені помилки:

• Політика занадто загальна і не адаптована до фактичного ІКТ-ландшафту

• Відсутність інтеграції з існуючими фреймворками ризиків (операційний ризик, комплаєнс-ризик)

• Відсутність зв'язку з безперервністю бізнесу та аварійним відновленням

---

Крок 5: Налаштування процесу управління інцидентами та звітності про інциденти

Мета кроку: Встановлення процесу виявлення, класифікації, реагування, відновлення та звітності про ІКТ-інциденти. Створення інтерфейсу для звітності перед FMA відповідно до ст. 19 DORA.

Типові докази/артефакти:

• Політика управління інцидентами з:

• Критеріями класифікації інцидентів (відповідно до Делегованого регламенту (ЄС) 2024/1772)

• Визначенням «значного інциденту, пов'язаного з ІКТ» та порогових значень

• Шляхами ескалації (внутрішніми та зовнішніми)

• Ролями (команда реагування на інциденти, CISO, комунікації)

• Процедура звітності про інциденти (вкл. часові межі, шаблони відповідно до Імплементаційного регламенту (ЄС) 2025/302)

• Журнал інцидентів/система тікетів (також для незначних інцидентів)

• Тестовий запуск процесу звітності (наприклад, настільні вправи)

Поширені помилки:

• Порогові значення для «значних» інцидентів незрозумілі або встановлені занадто високо

• Відсутність взаємодії між управлінням ІТ-інцидентами та комплаєнсом/ризиками

• Шлях звітності до FMA не протестований або не задокументований

• Відсутність процесів для «добровільного повідомлення» про кіберзагрози

---

Крок 6: Встановлення концепції тестування та стійкості

Мета кроку: Визначення стратегії та плану регулярного тестування ІКТ-систем і процесів (ст. 24-26 DORA), пропорційно профілю ризику.

Типові докази/артефакти:

• Стратегія/план тестування ІКТ, що охоплює:

• Типи тестів (сканування вразливостей, тести на проникнення, тести на основі сценаріїв, за потреби TLPT)

• Частоту та обсяг

• Ролі (внутрішні/зовнішні тестувальники)

• Процес усунення недоліків

• Звіти про тестування та плани усунення недоліків (також історичні)

• Для значущих інституцій: план TLPT відповідно до Делегованого регламенту (ЄС) 2025/1190, фреймворк TIBER-EU (кожні 3 роки)

• Вправи Purple Teaming (при TLPT)

Поширені помилки:

• Тестування зводиться до «тесту на проникнення раз на рік» без систематичної стратегії

• Плани усунення недоліків не виконуються або не відстежуються

• Відсутність інтеграції результатів тестування в реєстр ризиків та звітність керівництву

• Вимоги TLPT ігноруються (якщо застосовно)

---

Крок 7: Впровадження управління ризиками третіх сторін

Мета кроку: Стратегія та процеси управління ризиками сторонніх постачальників ІКТ протягом усього життєвого циклу (ст. 28 DORA): належна обачність, укладання контрактів, моніторинг, вихід.

Типові докази/артефакти:

• Політика ризиків третіх сторін ІКТ (відповідно до ст. 28 DORA), що охоплює:

• Критерії класифікації критичності

• Вимоги до належної обачності (залежно від критичності)

• Механізми моніторингу

• Вимоги до стратегії виходу

• Управління суб-аутсорсингом

• Контрольні списки та звіти про належну обачність (для кожного постачальника)

• Безперервний моніторинг (KPI, відстеження SLA, звіти про інциденти)

• Плани виходу та заходи на випадок непередбачених обставин для критичних постачальників

Поширені помилки:

• Належна обачність є суто формальною («поставити галочку в анкеті») без суттєвої оцінки

• Відсутність безперервного моніторингу після укладання договору

• Стратегії виходу є теоретичними, але не протестованими

• Субаутсорсинг не фіксується та не контролюється

---

Крок 8: Створення реєстру аутсорсингу/ІКТ та реєстру інформації

Мета кроку: Встановлення повного, актуального та узгодженого реєстру всіх сторонніх постачальників ІКТ відповідно до ст. 28 п. 2 DORA та Імплементаційного регламенту (ЄС) 2024/2956.

Типові докази/артефакти:

• Реєстр інформації (Excel/база даних/інструмент GRC), що охоплює всі поля згідно з ITS:

• Постачальник (назва, LEI, місцезнаходження)

• Опис ІКТ-послуг

• Класифікація (критична/важлива функція, суб-аутсорсинг)

• Дані договору (початок, кінець, SLA)

• Критичність та ризик концентрації

• Місця зберігання даних

• Положення про вихід

• Права на аудит

• Процес безперервного оновлення (принаймні щорічно, при змінах — негайно)

• Відповідальність за ведення реєстру

• Перша звітність до FMA в Австрії (термін 31.03.2025, далі щорічно)

Поширені помилки:

• Реєстр неповний (наприклад, відсутні дрібні постачальники, суб-аутсорсинг)

• Класифікація (критична/важлива) є непослідовною або не задокументованою

• Відсутність чіткого розподілу відповідальності за ведення реєстру

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

---

Крок 9: Адаптація управління контрактами/стандартних застережень

Мета кроку: Адаптація шаблонів контрактів та стандартних застережень для ІКТ-послуг відповідно до ст. 30 DORA для відображення вимог DORA (права на аудит, безпека, вихід тощо).

Типові докази/артефакти:

• Стандартні договірні застереження (шаблон/плейбук) для ІКТ-послуг, що охоплюють:

• Обсяг послуг та критичність

• Вимоги до безпеки та стійкості (вкл. такі стандарти, як ISO 27001, відповідність NIS2)

• Права на аудит, інформацію та доступ (для фінансових установ та наглядових органів)

• Зобов'язання щодо звітності про інциденти (часові межі, формати)

• Положення про суб-аутсорсинг (схвалення, контроль)

• Стратегія виходу, повернення даних, інтероперабельність, перехідні послуги

• Підтвердження страхування, відповідальність

• Плейбук для переговорів (як вести переговори з постачальниками, які мають стандартні умови)

• Інвентаризація контрактів (які старі контракти потребують адаптації)

Поширені помилки:

• Стандартні застереження існують, але не використовуються в реальних контрактах

• Відсутність диференційованих наборів застережень залежно від критичності

• Положення про вихід є розпливчастими або непрактичними

• Відсутність процесів для регулярного перегляду контрактів

---

Крок 10: Навчання, обізнаність, звітність та безперервне вдосконалення

Мета кроку: Забезпечення розуміння вимог DORA всіма відповідними працівниками (вкл. керівництво, ІТ, ризики, закупівлі). Встановлення управлінської звітності та процесу вивчення уроків.

Типові докази/артефакти:

• План навчання (обізнаність про DORA для всіх, специфічні тренінги для окремих ролей)

• Навчальні матеріали та підтвердження участі

• Управлінські звіти (наприклад, щоквартальні):

• Дашборд ІКТ-ризиків

• Статистика інцидентів

• Прогрес тестування

• Результати моніторингу третіх сторін

• Прогрес виконання заходів (дорожня карта DORA)

• Процес вивчення уроків (після інцидентів, тестів, аудитів)

• Щорічний огляд відповідності DORA (аналіз розривів, оновлення політик)

Поширені помилки:

• Навчання є суто формальним («пройти електронний курс»), без реальної обізнаності

• Управлінська звітність занадто детальна або занадто поверхнева

• Відсутність структурованого аналізу вивчених уроків

• Безперервне вдосконалення не відбувається (налаштування залишаються статичними)

5. Основні сфери DORA в мінімальному налаштуванні (детально)

5.1 Управління ІКТ-ризиками (Розділ II, ст. 5-16 DORA)

Регуляторна вимога: DORA зобов'язує фінансові установи встановити комплексну систему управління ІКТ-ризиками (ст. 6), інтегровану в загальну систему управління ризиками. Орган управління несе повну відповідальність (ст. 5). Конкретні вимоги включають:

• Управління та ролі (орган управління, CISO, функція контролю ІКТ-ризиків)

• Політика, стратегія та толерантність до ІКТ-ризиків

• Інвентаризація активів та оцінка ризиків

• Заходи захисту та запобігання

• Виявлення та моніторинг

• Реагування та відновлення (вкл. безперервність бізнесу)

• Стратегії резервного копіювання та резервування

• Управління вразливостями

• Безперервний моніторинг та адаптація

Мінімальне налаштування:

• Політика управління ІКТ-ризиками (затверджена органом управління), що охоплює вищезазначені пункти

• Інвентаризація активів (ІКТ- та інформаційні активи) з класифікацією ризиків

• Реєстр ризиків (ІКТ-ризики) з оцінкою (ймовірність/вплив), заходами, відповідальними

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

• Інтеграція: ІКТ-ризики є частиною системи операційних ризиків і звітуються в комітетах з ризиків, аудиту та правлінню

• Звітність: принаймні щорічний звіт про ІКТ-ризики органу управління

Типові помилки:

• Політика є копією стандартного шаблону без адаптації до фактичного ІКТ-ландшафту

• Інвентаризація активів неповна (наприклад, відсутні застарілі системи)

• Реєстр ризиків є статичним і не оновлюється

• Відсутність зв'язку між ІКТ-ризиками та впливом на бізнес

• CISO не має достатніх ресурсів або можливостей ескалації

5.2 Управління інцидентами/Звітність (Розділ III, ст. 17-23 DORA)

Регуляторна вимога: Фінансові установи повинні мати процеси виявлення, управління та реагування на ІКТ-інциденти (ст. 17). Значні інциденти, пов'язані з ІКТ, повинні бути повідомлені відповідному наглядовому органу (FMA) (ст. 19):

Примітка: Наведені часові межі базуються на відповідних делегованих актах (RTS/ITS) і можуть бути змінені майбутніми адаптаціями.

• Первинне повідомлення (протягом 4 годин після виявлення, відповідно до Делегованого регламенту (ЄС) 2025/301)

• Проміжний звіт (при суттєвих змінах статусу)

• Фінальний звіт (з аналізом першопричин)

Класифікація здійснюється відповідно до Делегованого регламенту (ЄС) 2024/1772 (критерії: вплив на доступність, цілісність, конфіденційність; кількість постраждалих клієнтів; географічне охоплення; тривалість).

Добровільне повідомлення про значні кіберзагрози можливе (ст. 19 п. 2).

Мінімальне налаштування:

• Політика/процедура управління інцидентами, що охоплює:

• Виявлення інцидентів (інструменти моніторингу, сповіщення)

• Класифікація інцидентів (згідно з критеріями DORA)

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

• Реагування та локалізація

• Відновлення

• Огляд після інциденту (аналіз першопричин, вивчені уроки)

• Процедура звітності про інциденти до FMA:

• Визначені порогові значення для «значних» інцидентів

• Шаблони відповідно до Імплементаційного регламенту (ЄС) 2025/302

• Часові межі (4 год, проміжний, фінальний)

• Відповідальність (хто повідомляє, хто затверджує)

• Журнал інцидентів (усі інциденти, також незначні)

• Комунікація з клієнтами: процес інформування постраждалих клієнтів у разі значних інцидентів (ст. 19 п. 3)

• Тестування: настільні вправи для перевірки реагування на інциденти та звітності

Типові помилки:

• Порогові значення для «значних» інцидентів занадто високі, тому інциденти, що підлягають звітності, не повідомляються

• Реагування на інциденти керується суто ІТ-відділом без залучення ризиків, комплаєнсу та комунікацій

• Відсутність чіткої відповідальності за звітність перед FMA (ІТ вважає, що відповідає комплаєнс, і навпаки)

• Журнал інцидентів неповний або не піддається аналізу

• Відсутність аналізу інцидентів для безперервного вдосконалення

5.3 Тестування/Стійкість (Розділ IV, ст. 24-27 DORA)

Регуляторна вимога: Фінансові установи повинні регулярно проводити тестування своїх ІКТ-систем та операційної стійкості (ст. 24-25):

• Різні типи тестів: оцінка вразливостей, тести на проникнення, тести на основі сценаріїв

• Пропорційно профілю ризику та критичності

Примітка: Наступні частоти тестування та вимоги TLPT базуються на відповідних делегованих актах (RTS/ITS) і можуть бути змінені майбутніми адаптаціями або роз'ясненнями наглядових органів.

Значущі інституції (визначені наглядовим органом відповідно до ст. 26 п. 8 та відповідних RTS щодо тестування на проникнення на основі загроз, Делегований регламент (ЄС) 2025/1190) повинні проводити тестування на проникнення на основі загроз (TLPT) (ст. 26):

• Принаймні кожні 3 роки

• TLPT базується на фреймворку TIBER-EU (або національних імплементаціях)

• TLPT симулює реалістичні сценарії атак (Threat Intelligence, Red Teaming)

• Purple Teaming (співпраця Red Team / Blue Team) є обов'язковим на етапі завершення

• Внутрішні тестувальники дозволені (за певних умов), але кожне третє TLPT має залучати зовнішніх тестувальників

Мінімальне налаштування:

• Стратегія тестування ІКТ, яка визначає різні типи тестів:

• Сканування вразливостей (наприклад, щоквартально автоматизовано)

• Тести на проникнення (наприклад, щорічно для критичних систем)

• Тести на основі сценаріїв (наприклад, симуляція кібератаки, сценарій з шифрувальником)

• Тести безперервності бізнесу/аварійного відновлення (наприклад, щорічно)

• План тестування (частота, обсяг, відповідальність, бюджет)

• Звіти про тестування та плани усунення недоліків (вкл. відстеження заходів)

• Для значущих інституцій: план TLPT відповідно до Делегованого регламенту (ЄС) 2025/1190, вкл.:

• Визначення обсягу (які критичні/важливі функції)

• Вибір зовнішніх/внутрішніх тестувальників

• Координація з органом TLPT (FMA)

• Вправа Purple Teaming

• Усунення недоліків та управлінська звітність

Типові помилки:

• Тестування не є систематичним (ad-hoc тести на проникнення без стратегії)

• Плани усунення недоліків не виконуються або не відстежуються (результати залишаються відкритими)

• Відсутність інтеграції результатів тестування в реєстр ризиків та управлінську звітність

• TLPT помилково сприймається як «звичайний тест на проникнення»

• Відсутність документації про проведення тестів (брак доказів для нагляду)

5.4 Ризики третіх сторін/Нагляд (Розділ V, ст. 28-44 DORA)

Регуляторна вимога: DORA запроваджує комплексні вимоги до управління ризиками сторонніх постачальників ІКТ (ст. 28-30):

• Політика ризиків третіх сторін ІКТ (ст. 28 п. 1), вкл. стратегію, класифікацію ризиків, положення про вихід

• Належна обачність перед укладанням договору (ст. 28 п. 2)

• Безперервний моніторинг (ст. 28 п. 3)

• Реєстр інформації (ст. 28 п. 2) — повний перелік усіх сторонніх постачальників ІКТ

• Договірні вимоги (ст. 30):

• Опис послуг та SLA

• Вимоги до безпеки та стійкості

• Права на аудит, інформацію та доступ (вкл. для наглядових органів)

• Зобов'язання щодо звітності про інциденти

• Положення про суб-аутсорсинг (схвалення, прозорість)

• Стратегія виходу, повернення даних, інтероперабельність, перехідні послуги

• Повідомлення FMA про заплановані контракти на критичні/важливі функції (ст. 28 п. 3 останнє речення) (деталі незрозумілі, потрібні вказівки FMA)

Система нагляду за «критичними сторонніми постачальниками ІКТ» (ст. 31 і далі):

• ESA призначають критичних постачальників (щорічно)

• Провідний наглядовий орган (EBA/ESMA/EIOPA) здійснює нагляд: запити інформації, інспекції, рекомендації

• Фінансові установи повинні інтегрувати рекомендації провідного наглядача (Lead Overseer) у свою систему управління ризиками третіх сторін (ст. 42)

Мінімальне налаштування:

• Політика щодо ризиків ІКТ, пов'язаних із третіми сторонами, що включає:

• Класифікація ризиків (наприклад, критичні / важливі / стандартні, на основі критичності функції, чутливості даних, ризику концентрації або замінності)

• Вимоги щодо належної обачності (due diligence) залежно від класу ризику

• Механізми моніторингу (KPI, відстеження SLA, звіти про інциденти, періодичні перегляди)

• Вимоги до стратегії виходу (план на випадок непередбачуваних обставин, план переходу, тестування)

• Управління субаутсорсингом (прозорість, затвердження, право на контроль)

• Процес належної обачності (due diligence):

• Контрольний список/анкета (безпека, стійкість, фінансова стабільність, комплаєнс, сертифікація)

• Документування результатів належної обачності

• Рішення про прийняття ризику (у разі виявлення ризиків)

• Реєстр інформації (див. крок 8)

• Безперервний моніторинг:

• Відстеження KPI (наприклад, доступність, час реагування)

• Звіти про виконання SLA

• Звіти про інциденти від сторонніх постачальників

• Періодичні перегляди (наприклад, щорічно)

• Управління змінами (у разі змін у постачальника, наприклад, зміна місцезнаходження, субаутсорсинг)

• Стратегія виходу:

• Плани на випадок непередбачуваних обставин для критично важливих постачальників

• План переходу (як перейти до альтернативного варіанту)

• Тестування планів виходу (наприклад, кожні 2 роки)

• Укладання договорів: див. крок 9

Типові помилки:

• Класифікація ризиків є непослідовною або не задокументованою

• Належна обачність (due diligence) є суто формальною (проставлення галочок в анкеті) без ґрунтовного аналізу

• Відсутність безперервного моніторингу (належна обачність проводиться лише під час укладання договору, після чого нічого не робиться)

• Стратегії виходу є теоретичними, не протестованими або непрактичними

• Субаутсорсинг не фіксується та не контролюється

• Відсутність інтеграції ризиків третіх сторін у загальний реєстр ризиків

5.5 Корпоративне управління / ролі / звітність перед керівництвом

Регуляторна вимога: DORA покладає пряму відповідальність на керівний орган (ст. 5):

• Визначення, затвердження та моніторинг усіх домовленостей щодо ризиків ІКТ

• Затвердження політики щодо ризиків ІКТ, плану тестування та бюджету

• Регулярне інформування про ризики ІКТ, інциденти, тестування та моніторинг третіх сторін

CISO / відповідальні за ІКТ (ст. 6, п. 9): фінансові установи повинні призначати відповідальних за ІКТ осіб із достатніми повноваженнями, ресурсами та прямим доступом до керівного органу.

Функція контролю ризиків ІКТ (ст. 6, п. 4): незалежна функція контролю ризиків ІКТ (за певних умов може бути поєднана з роллю CISO).

Мінімальне налаштування:

• Відповідальність керівного органу:

• Формальне затвердження стратегії/дорожньої карти DORA (рішення правління / рішення керівництва)

• Затвердження політики щодо ризиків ІКТ, плану тестування та політики щодо ризиків третіх сторін

• Бюджет на впровадження DORA (персонал, інструменти, зовнішні консультанти, тестування)

• Визначення толерантності до ризиків ІКТ / порогових значень

• Визначення ролей:

• CISO/відповідальні за ІКТ: чітка посадова інструкція, ресурси, можливості ескалації

• Функція контролю ризиків ІКТ: може бути поєднана з CISO, за умови забезпечення незалежності (ст. 6 абз. 4)

• Команда реагування на інциденти: визначені ролі (керівник, ІТ, комунікації, юридичний відділ, ризики)

• Команда з управління третіми сторонами: закупівлі, ризики, ІТ, юридичний відділ

• Лінії звітності:

• Регулярні управлінські звіти (наприклад, щоквартальні):

• Дашборд ризиків ІКТ (основні ризики, заходи, тренди)

• Статистика інцидентів (кількість, класифікація, серйозні інциденти)

• Прогрес тестування (план vs факт, результати, усунення недоліків)

• Моніторинг третіх сторін (нові постачальники, оцінка ризиків, ризик концентрації)

• Статус відповідності DORA (дорожня карта, відкриті заходи)

• Ad-hoc звітність: негайне інформування органу управління у разі серйозних інцидентів

Типові помилки:

• Орган управління не залучений по суті (розглядає DORA як ІТ-проєкт)

• CISO/відповідальні за ІКТ не мають достатніх ресурсів або повноважень

• Звітність занадто детальна (технічні подробиці) або занадто поверхнева (відсутні рекомендації до дій)

• Відсутність чіткої ескалації при серйозних інцидентах або критичних ризиках

6. Укладання договорів та нагляд за постачальниками: що має бути у контрактах/SLA

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

• Обсяг послуг та рівень сервісу:

• Чіткий опис послуг ІКТ

• Угоди про рівень послуг (Service Level Agreements — доступність, продуктивність, час реагування)

• Критичність функції/послуги

• Вимоги до безпеки та стійкості:

• Стандарти безпеки (наприклад, ISO 27001, SOC2, відповідність NIS2)

• Шифрування, контроль доступу, моніторинг

• Безперервність бізнесу/аварійне відновлення (RTO/RPO)

• Стратегії резервного копіювання та тестування

• Права на аудит, інформацію та доступ:

• Право фінансової установи на проведення аудитів/інспекцій (на місці або дистанційно)

• Право наглядових органів (FMA) на проведення аудитів/інспекцій у стороннього постачальника послуг ІКТ (ст. 30 абз. 3 літ. e DORA)

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

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

• Зобов'язання щодо повідомлення про інциденти:

• Сторонній постачальник послуг ІКТ повинен негайно повідомляти про інциденти, що стосуються фінансової установи

• Часові межі (наприклад, протягом 2 годин після виявлення)

• Формати (наприклад, шаблон звіту про інцидент)

• Суб-аутсорсинг:

• Суб-аутсорсинг лише за згодою фінансової установи

• Прозорість щодо субпідрядників (реєстр)

• Право наскрізного контролю субпідрядників (права на аудит)

• Місця зберігання даних та захист даних:

• Чітка домовленість про те, де зберігаються дані (пріоритет ЄС/ЄЕЗ)

• Відповідність GDPR (Угода про обробку даних)

• Портативність даних та інтероперабельність

• Стратегія виходу, повернення даних, перехідні послуги:

• Застереження про вихід: можливість чергового та позачергового розірвання договору

• Повернення даних: процес та терміни повернення всіх даних (структурованих, машиночитних)

• Інтероперабельність: стандарти для легкого перенесення даних/послуг до інших постачальників

• Перехідні послуги: сторонній постачальник послуг ІКТ продовжує надавати послуги протягом перехідного періоду (наприклад, 6–12 місяців)

• Тестування виходу: регулярна перевірка плану виходу (наприклад, кожні 2 роки)

• Страхування та відповідальність:

• Підтвердження достатнього страхового покриття (кіберризики, професійна відповідальність)

• Положення про відповідальність (ліміти, виключення)

• Управління змінами:

• Сторонній постачальник послуг ІКТ повинен своєчасно повідомляти про заплановані зміни (наприклад, зміна локації, технічні оновлення, суб-аутсорсинг)

• Обов'язкове погодження суттєвих змін

• Термін дії договору та продовження:

• Належні терміни повідомлення про розірвання (мінімум 6–12 місяців для критичних послуг)

• Регулярний перегляд договорів (наприклад, кожні 2–3 роки)

Практична порада: у випадку стандартних договорів великих хмарних провайдерів (наприклад, AWS, Azure, Google Cloud) індивідуальні переговори часто є складними. Фінансові установи повинні:

• Узгодити аддендум/додатковий лист, що охоплює вимоги DORA

• Використовувати альтернативні запевнення (наприклад, SOC2 Type II, ISO 27001, атестації постачальників щодо DORA)

• Звертати увагу на рекомендації ESA, якщо постачальник визначений як «критичний»

7. Типові питання перевірки/аудиту (у стилі чек-листа)

Наступний список містить питання, які можуть поставити внутрішній аудит, зовнішні аудитори або орган нагляду (FMA). Вони слугують як внутрішній контрольний список:

• Управління (Governance):

• Чи офіційно затвердив орган управління стратегію/дорожню карту DORA (рішення правління)?

• Чи чітко визначені та доведені до відома ролі та обов'язки щодо ризиків ІКТ та DORA?

• Чи є CISO/відповідальний за ІКТ з достатніми ресурсами та прямим доступом до органу управління?

• Управління ризиками ІКТ:

• Чи існує задокументована політика управління ризиками ІКТ, інтегрована в загальну систему управління ризиками?

• Чи ведеться та регулярно оновлюється повний інвентар активів (активи ІКТ та інформаційні активи)?

• Як оцінюються ризики ІКТ (методологія, критерії) та як вони фіксуються в реєстрі ризиків?

• Чи регулярно (мінімум щорічно) звітується органу управління про ризики ІКТ?

• Управління інцидентами:

• Чи існує задокументований процес управління інцидентами з чіткими шляхами ескалації?

• Як ви визначаєте «серйозний інцидент, пов'язаний з ІКТ»? Які порогові значення ви використовуєте?

• Чи був уже протестований процес звітування до FMA (ст. 19) (наприклад, настільні вправи)?

• Чи фіксуються та аналізуються всі інциденти ІКТ (навіть несерйозні) у журналі?

• Тестування:

• Чи існує стратегія тестування ІКТ, що охоплює різні типи тестів (на вразливості, на проникнення, на основі сценаріїв)?

• Як часто проводиться тестування? Чи відповідає періодичність рівню ризику?

• Чи документуються результати тестів та плани усунення недоліків, і чи відстежується їх виконання?

• Якщо застосовно: чи заплановано/проведено TLPT згідно зі ст. 26 DORA?

• Ризики третіх сторін:

• Чи існує політика щодо ризиків третіх сторін у сфері ІКТ з чіткою стратегією та класифікацією ризиків?

• Як проводиться комплексна перевірка (due diligence) нових сторонніх постачальників послуг ІКТ? Чи задокументований цей процес?

• Чи існує система безперервного моніторингу сторонніх постачальників послуг ІКТ (KPI, відстеження SLA)?

• Чи визначені та протестовані стратегії виходу для критичних сторонніх постачальників послуг ІКТ?

• Реєстр інформації (Register of Information):

• Чи є Реєстр інформації повним (усі сторонні постачальники послуг ІКТ, включаючи суб-аутсорсинг)?

• Як ви забезпечуєте актуальність реєстру (процес, відповідальність)?

• Чи був реєстр вчасно (в Австрії: до 31.03.2025) переданий до FMA?

• Чи заповнені всі необхідні поля згідно з Імплементаційним регламентом (ЄС) 2024/2956?

• Укладання договорів:

• Чи містять ваші договори зі сторонніми постачальниками послуг ІКТ елементи, передбачені ст. 30 DORA (права на аудит, вихід, безпека)?

• Як ви працюєте зі стандартними договорами великих постачальників (наприклад, хмарних провайдерів)?

• Чи є інвентар договорів та процес для регулярного перегляду контрактів?

• Управлінська звітність:

• Чи регулярно орган управління отримує звіти про ризики ІКТ, інциденти, тестування, моніторинг третіх сторін?

• Як рекомендації до дій та ескалації доводяться до відома керівництва?

• Навчання та обізнаність:

• Чи пройшли всі відповідні співробітники (ІТ, ризики, закупівлі, менеджмент) навчання щодо вимог DORA?

• Чи існує регулярний план навчання?

• Безперервне вдосконалення:

• Чи існує процес засвоєння уроків (lessons learned) після інцидентів, тестів, аудитів?

• Як забезпечується безперервне вдосконалення відповідності DORA (щорічні перегляди, оновлення політик)?

• Документація та докази:

• Чи всі відповідні докази (політики, процеси, звіти, протоколи зустрічей) структуровані та доступні?

• Чи змогли б ви протягом 2 тижнів зібрати пакет доказів DORA для органу нагляду?

• Нагляд за «критичними сторонніми постачальниками послуг ІКТ»:

• Якщо ви користуєтеся послугами критичних сторонніх постачальників послуг ІКТ, визначених ESA як такі: як ви інтегруєте рекомендації провідного наглядового органу у ваше управління третіми сторонами?

Що робити далі? – 3 варіанти

Варіант 1: Самоперевірка (внутрішня)

Порядок дій: Використовуйте дорожню карту з 10 кроків та аудиторські питання з цієї статті для проведення внутрішнього скринінгу:

• Опрацюйте кожен крок і перевірте, чи наявні та актуальні типові артефакти.

• Задокументуйте прогалини у списку заходів (включаючи пріоритет, відповідальність, дедлайн).

• Представте результати органу управління з рекомендаціями до дій.

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

Часові межі: 2–4 тижні (залежно від розміру та складності).

Варіант 2: Воркшоп (внутрішній або із зовнішнім супроводом)

Порядок дій: Проведіть цілеспрямований воркшоп з готовності до DORA (1–2 дні), в ідеалі з крос-функціональною командою (ІТ, ризики, комплаєнс, закупівлі, юридичний відділ):

• Уточнення обсягу та ролей: кого це стосується, хто відповідальний?

• Gap-аналіз: де ми зараз, чого не вистачає?

• Пріоритезація: які заходи є терміновими (мінімальне налаштування), які — середньостроковими (підвищення рівня зрілості)?

• Дорожня карта та таймлайн: коли і що має бути готове?

• Ресурси та бюджет: які внутрішні/зовнішні ресурси нам потрібні?

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

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

Часові межі: 1–2 дні воркшопу + 1 тиждень на доопрацювання (документація, презентація для менеджменту).

Варіант 3: Впровадження (покрокова реалізація)

Порядок дій: Запустіть проєкт із впровадження DORA (внутрішній або із зовнішньою підтримкою):

• Налаштування проєкту: керівництво проєкту, керівний комітет (з представництвом органу управління), робочі групи (управління, інциденти, тестування, треті сторони)

• Покрокова реалізація 10 кроків (див. вище):

• Створення/оновлення політик

• Визначення та впровадження процесів

• Створення/доповнення реєстру

• Адаптація договорів

• Проведення тестування

• Проведення навчання

• Звітність: регулярне оновлення статусу для органу управління

• Go-Live: офіційне введення в експлуатацію мінімального налаштування

• Після Go-Live: безперервне вдосконалення, щорічні перегляди

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

Часові межі: 6–12 місяців (залежно від початкової ситуації та ресурсів).

9. FAQ (6–8 питань)

П1: Чи поширюється DORA на мій фінтех / мою страхову компанію / мою платіжну установу?

В: DORA поширюється майже на всі піднаглядні фінансові установи в ЄС (див. ст. 2 DORA). Конкретно:

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

• Страхові компанії: так, усі страхові та перестрахові компанії, а також страхові посередники.

• Платіжні установи: так, усі платіжні установи та установи електронних грошей (згідно з PSD2/EMD2).

Єдині винятки: певні мікропідприємства (10 співробітників, 2 млн євро обороту/балансу) мають спрощені вимоги, але залишаються в межах дії регламенту. Держави-члени можуть також виключати певні малі установи згідно з CRD (ст. 2 абз. 5 пп. 4-23 Директиви 2013/36/EU), але це необов'язково.

П2: Чи поширюється DORA також на чистих постачальників послуг ІКТ без фінансової ліцензії?

В: Так, але опосередковано, а (для критичних постачальників) — безпосередньо:

Опосередковано: усі постачальники послуг ІКТ, які надають послуги фінансовим установам, залучаються до відповідності DORA через договірні зобов'язання (ст. 28, 30):

• Фінансові установи повинні вимагати від своїх сторонніх постачальників послуг ІКТ певних положень щодо безпеки, аудиту та виходу.

• Сторонні постачальники послуг ІКТ повинні виконувати ці договірні вимоги, щоб зберегти фінансові установи як клієнтів.

Безпосередньо: сторонні постачальники послуг ІКТ, визначені ESA як «критичні сторонні постачальники послуг ІКТ», підпадають під європейську структуру нагляду (ст. 31 і далі):

• Провідний наглядовий орган (EBA/ESMA/EIOPA) може запитувати інформацію, проводити інспекції, надавати рекомендації.

• Відсутність обов'язкового ліцензування, але фактичний нагляд.

Практична порада: постачальники послуг ІКТ повинні готуватися до вимог DORA шляхом:

• Розробки шаблонів договорів, що відповідають вимогам DORA

• Отримання сертифікатів (ISO 27001, SOC2)

• Забезпечення прозорості щодо суб-аутсорсингу та місць зберігання даних

П3: Які документи мені потрібні для мінімального налаштування відповідності DORA?

В: Основні документи мінімального налаштування:

• Політика управління ризиками ІКТ (затверджена органом управління)

• Політика/процедура управління інцидентами (включаючи процес звітування до FMA)

• Стратегія/план тестування ІКТ

• Політика щодо ризиків третіх сторін у сфері ІКТ

• Реєстр інформації (повний, актуальний)

• Шаблони договорів (із застереженнями DORA)

• Інвентар активів (активи ІКТ та інформаційні активи)

• Реєстр ризиків (ризики ІКТ)

• Управлінські звіти (ризики ІКТ, інциденти, тестування, треті сторони)

• Підтвердження навчання (обізнаність щодо DORA)

• Пакет доказів (структурована документація всіх підтверджень)

Примітка: документи не обов'язково мають бути об'ємними, але повинні бути змістовними та практичними (без «паперового комплаєнсу»).

П4: Скільки часу зазвичай займає впровадження мінімального налаштування DORA?

В: Тривалість сильно залежить від початкової ситуації:

• Компанії з хорошим управлінням ризиками ІКТ (наприклад, ISO 27001, Керівні принципи EBA щодо аутсорсингу): 3–6 місяців для специфічних адаптацій під DORA (заповнення реєстру, адаптація політик, налаштування процесу звітування до FMA).

• Компанії з фрагментованим налаштуванням: 6–12 місяців для суттєвих змін (нові політики, редизайн процесів, впровадження інструментів, адаптація договорів).

• Компанії без структурованого управління ризиками ІКТ: 12–18 місяців (побудова з нуля).

Критичні фактори швидкості:

• Наявність внутрішніх ресурсів (персонал, бюджет)

• Залученість керівництва

• Складність ІКТ-ландшафту та структури аутсорсингу

• Необхідність адаптації старих договорів

Практична порада: почніть із найбільш термінових елементів (Реєстр інформації, процес звітування про інциденти, рішення органу управління) і просувайтеся крок за кроком.

П5: Чим DORA відрізняється від існуючих правил аутсорсингу та національних вимог (наприклад, мінімальних стандартів FMA)?

В: DORA гармонізує та розширює існуючі правила:

Спільні риси:

• DORA базується на Керівних принципах EBA щодо аутсорсингу (EBA/GL/2019/02) і переймає багато принципів (комплексна перевірка, моніторинг, стратегії виходу).

• Національні вимоги (наприклад, мінімальні стандарти FMA щодо управління аутсорсингом) значною мірою інтегровані в DORA.

Відмінності/розширення:

• Ширша сфера застосування: DORA діє для всіх фінансових установ у всьому ЄС (не лише для банків), включаючи страхові компанії, платіжні установи, криптосервіси.

• Фокус на ІКТ: DORA всебічно охоплює усі ризики ІКТ (не лише аутсорсинг), включаючи управління інцидентами, тестування, стійкість.

• Прямий нагляд за критичними сторонніми постачальниками послуг ІКТ: DORA вперше запроваджує прямий нагляд за критичними постачальниками ІКТ з боку ESA (раніше лише опосередковано через фінансові установи).

• Стандартизовані процеси звітування: DORA запроваджує єдині для всього ЄС шаблони та терміни для звітування про серйозні інциденти.

• Вимоги до тестування: DORA визначає чіткі вимоги до тестування, включаючи TLPT для значущих установ.

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

• Розширити сферу застосування (усі послуги ІКТ, а не лише аутсорсинг)

• Доповнити реєстр (усі сторонні постачальники послуг ІКТ, включаючи суб-аутсорсинг)

• Адаптувати процес звітування про інциденти (нові шаблони, терміни)

• Розширити стратегію тестування (за потреби TLPT).

П6: Що таке «серйозний інцидент, пов'язаний з ІКТ» і як його розпізнати?

В: «Серйозний інцидент, пов'язаний з ІКТ» — це інцидент ІКТ, який перевищує певні порогові значення і тому повинен бути повідомлений наглядовому органу (FMA) (ст. 19 DORA).

Критерії класифікації згідно з Делегованим регламентом (ЄС) 2024/1772 (ст. 18 DORA):

• Вплив на доступність, цілісність, конфіденційність даних або послуг

• Кількість постраждалих клієнтів/контрагентів (включаючи значущість)

• Географічне охоплення впливу

• Тривалість збою

• Критичність задіяних послуг (наприклад, платіжні операції, торгова платформа)

Приклади «серйозних» інцидентів:

• Збій платформи онлайн-банкінгу для >100 000 клієнтів протягом >4 годин

• Витік даних із доступом до персональних даних >10 000 клієнтів

• Атака програм-вимагачів (ransomware), що порушує критичні бізнес-процеси

• Збій обробки платежів із суттєвими фінансовими наслідками

Практична порада:

• Визначте чіткі порогові значення для вашої компанії (на основі критеріїв DORA та профілю ризику)

• Задокументуйте логіку класифікації в Політиці управління інцидентами

• Проведіть навчання команди реагування на інциденти та менеджменту, щоб швидко розпізнавати «серйозні» випадки

• У разі сумнівів (особливо в перші місяці після початку застосування DORA): краще повідомити (початкове повідомлення) і пізніше скоригувати, ніж не повідомляти взагалі.

П7: Що станеться, якщо я не виконуватиму вимоги DORA?

В: Можливі наслідки невідповідності:

• Наглядові заходи:

• FMA може вимагати плани вдосконалення з дедлайнами

• Інспекції на місцях (спільно з OeNB) для перевірки стійкості ІКТ

• Розпорядження щодо виправлення специфічних моментів (наприклад, доповнення реєстру, адаптація договорів)

• Адміністративні санкції:

• DORA дозволяє накладати грошові штрафи за порушення (розмір варіюється залежно від порушення та держави-члена)

• Оприлюднення санкцій (репутаційна шкода)

• Операційні наслідки:

• Нез'ясовані залежності в ІКТ можуть призвести до операційних збоїв (відмова критичних послуг, втрата даних)

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

• Бізнес-наслідки:

• Репутаційні ризики: клієнти та партнери втрачають довіру при виявленні недоліків у комплаєнсі

• Ділові відносини: фінансові установи, які самі повинні відповідати DORA, можуть розривати або не продовжувати договори з невідповідними сторонніми постачальниками послуг ІКТ

• Особисті наслідки:

• Орган управління може бути притягнутий до відповідальності (ст. 51 DORA: санкції також проти фізичних осіб)

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

П8: Чи потрібно мені оновлювати Реєстр інформації щорічно?

В: Так, але не тільки щорічно:

• Перше звітування: в Австрії повний реєстр мав бути вперше переданий до FMA до 31 березня 2025 року (згідно з поточною комунікацією FMA станом на грудень 2024 року; ст. 28 абз. 9 DORA, Імплементаційний регламент (ЄС) 2024/2956). В інших державах-членах ЄС національні терміни можуть відрізнятися.

• Щорічне оновлення: після цього реєстр необхідно оновлювати щорічно (станом на 31 березня) та передавати до FMA.

• Ad-hoc оновлення: при суттєвих змінах (наприклад, новий критичний сторонній постачальник послуг ІКТ, розірвання важливого договору, значна зміна в суб-аутсорсингу) реєстр слід оновлювати негайно (внутрішній обов'язок, повідомлення до FMA згідно з обов'язком повідомлення у ст. 28 абз. 3 останнє речення — деталі уточнюються, потрібні роз'яснення FMA).

Практична порада:

• Впровадьте процес безперервного оновлення (а не лише раз на рік «все разом»)

• Визначте чітку відповідальність (хто веде реєстр, хто затверджує зміни)

• Використовуйте інструмент GRC або базу даних замість Excel для забезпечення узгодженості та відстежуваності

10. Пакет для завантаження

A) Мінімальне налаштування відповідності DORA — чек-лист із 10 кроків (1 сторінка):

Примітка: цей чек-лист є орієнтовною структурою. Він не є юридичною консультацією. Адаптуйте чек-лист до вашого специфічного профілю ризику та початкової ситуації.

B) Пакет доказів DORA — зразок змісту (структурований):

Цей зміст показує, як може бути структурований типовий пакет доказів DORA. Він слугує шаблоном для внутрішньої документації та підготовки до аудитів/перевірок наглядових органів.

1. Управління та організація

1.1 Ролі та обов'язки DORA

• Організаційний довідник/регламент (витяг: обов'язки щодо DORA)

• Посадова інструкція CISO/відповідального за ІКТ

• Матриця ролей (RACI) для впровадження DORA

1.2 Рішення органів управління

• Рішення правління/дирекції: затвердження стратегії/дорожньої карти DORA

• Рішення правління/дирекції: затвердження політики управління ризиками ІКТ

• Рішення правління/дирекції: бюджет на впровадження DORA

• Протоколи відповідних управлінських зустрічей (наприклад, комітету з ризиків, аудиторського комітету)

1.3 Плани організації та ескалації

• Шляхи ескалації для серйозних інцидентів ІКТ

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

2. Управління ризиками ІКТ

2.1 Політика

• Політика управління ризиками ІКТ (актуальна версія, затверджена органом управління)

• Історія змін політики (попередні версії, протокол змін)

2.2 Реєстр ризиків

• Реєстр ризиків ІКТ (експорт з Excel/інструменту GRC)

• Методологія оцінки ризиків (опис, критерії, матриця)

2.3 Інвентар активів

• Інвентар активів ІКТ (експорт з Excel/CMDB)

• Інвентар інформаційних активів (класифікація даних)

2.4 Безперервність бізнесу та аварійне відновлення

• Політика безперервності бізнесу ІКТ

• План аварійного відновлення (Disaster Recovery Plan)

• Звіти про тестування BCM/DR (наприклад, щорічні)

2.5 Управлінська звітність

• Управлінські звіти про ризики ІКТ (квартальні звіти, останній звіт)

• Презентації для органу управління (наприклад, дашборд ризиків)

3. Управління інцидентами та звітування

3.1 Політики та процедури

• Політика управління інцидентами

• Процедура звітування про інциденти (вкл. процес звітування до FMA)

3.2 Журнал інцидентів

• Журнал інцидентів (усі інциденти, включаючи несерйозні) (експорт з Excel/системи тікетів)

• Приклади звітів про інциденти (серйозні та несерйозні)

3.3 Повідомлення до FMA

• Огляд усіх повідомлень до FMA (серйозні інциденти, пов'язані з ІКТ)

• Копії початкових повідомлень, проміжних/фінальних звітів

3.4 Тестування та настільні вправи

• Протоколи настільних вправ (тести реагування на інциденти)

• Звіти про засвоєні уроки після інцидентів

4. Тестування та стійкість

4.1 Стратегія тестування

• Стратегія/план тестування ІКТ

• Щорічний календар тестування

4.2 Звіти про тести

• Звіти про сканування вразливостей (наприклад, щоквартальні)

• Звіти про тести на проникнення (наприклад, щорічні)

• Звіти про тести на основі сценаріїв

• (Для значущих установ:) Звіт TLPT та план усунення недоліків

4.3 Відстеження усунення недоліків

• Список відстеження результатів тестів (статус, відповідальність, дедлайн)

5. Ризики третіх сторін та Реєстр інформації

5.1 Політика щодо ризиків третіх сторін

• Політика щодо ризиків третіх сторін у сфері ІКТ (актуальна версія)

5.2 Реєстр інформації

• Реєстр інформації (повний, усі поля згідно з ITS) (експорт з Excel/інструменту GRC)

• Опис процесу ведення реєстру

• Підтвердження повідомлень до FMA в Австрії (31.03.2025, далі щорічно)

5.3 Комплексна перевірка (Due Diligence)

• Чек-лист/шаблон комплексної перевірки

• Приклади звітів про комплексну перевірку (для критичних постачальників)

5.4 Моніторинг

• Дашборд KPI для сторонніх постачальників послуг ІКТ

• Звіти про виконання SLA (приклади)

• Звіти про інциденти від сторонніх постачальників (приклади)

5.5 Стратегії виходу

• Шаблон плану виходу

• Приклади планів виходу (для критичних постачальників)

• Підтвердження тестів плану виходу

5.6 Нагляд за «критичними сторонніми постачальниками послуг ІКТ»

• Список використовуваних критичних постачальників (якщо застосовно)

• Рекомендації провідного наглядового органу (якщо отримані)

• Документація щодо інтеграції рекомендацій в управління третіми сторонами

6. Укладання договорів

6.1 Шаблони договорів

• Стандартні застереження в договорах (шаблон/плейбук) для послуг ІКТ

• Плейбук для переговорів

6.2 Інвентар договорів

• Список усіх договорів ІКТ (вкл. статус щодо відповідності DORA)

• Список пріоритетності для адаптації договорів

6.3 Приклади договорів

• Анонімізовані приклади договорів (відповідні DORA)

7. Навчання та обізнаність

7.1 План навчання

• План навчання щодо DORA (щорічний)

• Навчальні матеріали (презентації, модулі електронного навчання)

7.2 Підтвердження участі

• Списки учасників (анонімізовані або агреговані)

• Сертифікати про навчання (приклади)

7.3 Кампанії з підвищення обізнаності

• Внутрішня комунікація (інформаційні бюлетені, статті в інтранеті) щодо DORA

8. Управлінська звітність та безперервне вдосконалення

8.1 Управлінські звіти

• Квартальні звіти: дашборд ризиків ІКТ, статистика інцидентів, прогрес тестування, моніторинг третіх сторін, статус відповідності DORA

• Презентації для органу управління

8.2 Процес засвоєння уроків

• Опис процесу засвоєння уроків (Lessons Learned)

• Приклади звітів про засвоєні уроки (після інцидентів, тестів, аудитів)

8.3 Щорічні перегляди

• Щорічний звіт про огляд відповідності DORA

• Протоколи оновлення політик

9. Зовнішні аудити та оцінки

9.1 Внутрішній аудит

• Звіти внутрішнього аудиту щодо відповідності DORA (якщо наявні)

9.2 Зовнішні перевірки

• Звіти зовнішніх аудиторів (наприклад, аудиторських компаній, консультантів з безпеки) щодо відповідності DORA (якщо наявні)

9.3 Комунікація з органами нагляду

• Листування з FMA щодо DORA (наприклад, запити, роз'яснення)

10. Документація проєкту

10.1 Проєкт DORA

• Статут проєкту

• План проєкту (дорожня карта, віхи)

• Звіти про статус

10.2 Gap-аналіз

• Звіт про Gap-аналіз (ПЛАН vs ФАКТ)

• Список заходів (пріоритетний, зі статусом)

Примітка: цей зміст є пропозицією. Адаптуйте його до вашої конкретної ситуації, розміру та складності. Не всі пункти є релевантними для всіх компаній (наприклад, TLPT лише для значущих установ згідно з відповідними RTS щодо Threat-Led Penetration Testing).

Ви бажаєте професійно побудувати або оптимізувати ваше налаштування відповідності DORA?

• Безкоштовна 20-хвилинна первинна консультація: обговоріть ваші виклики щодо DORA та отримайте першу оцінку (без зобов'язань).

• Оцінка готовності до DORA (фіксований обсяг): структурований Gap-аналіз на основі 10 кроків та аудиторських питань, із пріоритетним списком заходів та презентацією для менеджменту (тривалість: 2–3 тижні).

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

Зв'яжіться з нами для ні до чого не зобов'язуючої розмови:

Записатися на первинну консультацію

Про NEXORA Unternehmensberatung GmbH:

NEXORA Unternehmensberatung GmbH — це консалтингова бутік-компанія, що базується у Відні та спеціалізується на стратегії, комплаєнсі/RegTech, виході на ринок та цифровій трансформації для фінансових установ та міжнародних компаній в Австрії та ЄС. Наша команда поєднує глибокі знання регуляторного середовища з практичним досвідом впровадження, щоб надавати клієнтам не просто «паперовий комплаєнс», а змістовні, практичні рішення. Ми тісно співпрацюємо з нашими клієнтами для розробки індивідуальних підходів, які відповідають регуляторним вимогам та підвищують операційну ефективність.

Відмова від відповідальності

Ця стаття не є юридичною або податковою консультацією і не може замінити індивідуальну консультацію в конкретному випадку. Зміст базується на поточному стані законодавства (станом на грудень 2025 року) та публічно доступних джерелах. При виникненні конкретних питань щодо відповідності DORA слід звернутися за кваліфікованою професійною порадою (наприклад, до юристів, що спеціалізуються на праві фінансових ринків, або спеціалізованих консультантів). Автори не несуть відповідальності за повноту, правильність або актуальність наданої інформації.

Джерела та корисні посилання

Ця стаття базується виключно на першоджерелах та офіційних документах:

• EUR-Lex — Регламент (ЄС) 2022/2554 (DORA):

https://eur-lex.europa.eu/eli/reg/2022/2554/oj

• Європейські наглядові органи (ESA) — DORA:

• EBA: https://www.eba.europa.eu/regulation-and-policy/digital-operational-resilience-act-dora

• ESMA: https://www.esma.europa.eu/policy-activities/digital-operational-resilience-act-dora

• EIOPA: https://www.eiopa.europa.eu/digital-operational-resilience-act-dora_en

• Делеговані та імплементаційні регламенти (RTS/ITS):

• Делегований регламент Комісії (ЄС) 2024/1772 (Класифікація ІКТ-інцидентів)

• Делегований регламент Комісії (ЄС) 2025/301 (Зміст та терміни звітування про інциденти)

• Імплементаційний регламент Комісії (ЄС) 2025/302 (Шаблони для звітування про інциденти)

• Делегований регламент Комісії (ЄС) 2024/1774 (Система управління ІКТ-ризиками)

• Делегований регламент Комісії (ЄС) 2024/1773 (Політика щодо сторонніх постачальників ІКТ-послуг)

• Імплементаційний регламент Комісії (ЄС) 2024/2956 (Реєстр інформації)

• Делегований регламент Комісії (ЄС) 2025/1190 (TLPT RTS)

• Делегований регламент Комісії (ЄС) 2025/532 (Субпідрядне надання ІКТ-послуг)

• FMA Австрія – Інформація щодо DORA:

• https://www.fma.gv.at/en/cross-sectoral-topics/dora/

• https://www.fma.gv.at/en/cross-sectoral-topics/dora/dora-managing-of-ict-third-party-risk/

• https://www.fma.gv.at/en/cross-sectoral-topics/dora/dora-ict-risk-management/

• https://www.fma.gv.at/en/banks/incoming-platform/reporting-circumstances-under-dora/

• Публікації FMA: «Let's talk about supervision» (випуски, присвячені DORA)

• Структура TIBER-EU (ЄЦБ):

https://www.ecb.europa.eu/paym/cyber-resilience/tiber-eu/html/index.en.html

• ESAs – Посібник з наглядової діяльності:

(Доступний на веб-сайтах ESA, див. вище)

Примітка: Наведені вище посилання були актуальними на момент створення (грудень 2025 року). Будь ласка, регулярно перевіряйте оновлення, оскільки DORA є динамічною нормативною базою, яка постійно доповнюється новими RTS/ITS, керівними принципами та запитаннями й відповідями від ESAs та національних наглядових органів.

Ця стаття слугує орієнтиром для підготовки до дотримання вимог DORA і не замінює індивідуальних юридичних або регуляторних консультацій. Адаптуйте зміст до Вашого конкретного профілю ризиків та організаційної структури.