DORA — Digital Operational Resilience Act — повністю застосовується з 17 січня 2025 року до кожної фінансової установи Європейського Союзу. Якщо ви банк, інвестиційна фірма, страхова компанія, платіжна установа, установа електронних грошей, CCP, CSD, торговельний майданчик або критичний ІКТ-провайдер будь-кого з них — ви в зоні дії.
Текст щільний, а супровідні RTS / ITS — ще щільніші. Ця стаття — польовий гід для керівника ІКТ і безпеки, а не для юрисконсульта. Ми виходимо з того, що ви прочитали DORA хоча б раз, і зосереджуємося на тому, що змінюється операційно та що промацуватиме ваша перша перевірка ESMA / EBA / EIOPA.
Що насправді змінив січень 2025-го
Три суттєві зрушення всередині операційної моделі безпеки:
- ІКТ-ризик став питанням рівня ради директорів із документованим переглядом щонайменше раз на рік. Рамка управління ризиками DORA — не опція і не «файл CISO»: її має затвердити керівний орган.
- Тестування стійкості виросло з «ми проводимо пентести» до структурованої програми. Значущі установи мають проводити threat-led penetration testing (TLPT) щонайменше раз на три роки, з обсягом і сценаріями, затвердженими регулятором.
- Звітування про інциденти консолідувалося. Попередня мозаїка шаблонів EBA / ESMA / EIOPA згортається в процес за статтею 17 DORA, з порогами класифікації та єдиним таймлайном звітування.
Стаття 9 — рамка управління ІКТ-ризиками на практиці
Стаття 9 вимагає «надійної, всеосяжної та добре задокументованої рамки управління ІКТ-ризиками». На практиці регулятор промацує:
- Документовану рамку, прямо затверджену керівним органом, із графіком перегляду.
- Реєстр ІКТ-активів, повʼязаний із бізнес-процесами, з оцінкою критичності. Методологія оцінювання має бути задокументована; «критичний / важливий / некритичний» без обґрунтування відхиляється.
- Безперервну ідентифікацію ІКТ-ризиків із документованими планами обробки та прийняттям залишкового ризику.
- Спроможність виявлення, що тестується щонайменше раз на рік, із документованими метриками (MTTD, MTTR, частка хибних спрацювань).
- Заходи захисту та запобігання, пропорційні профілю ризику, задокументовані та переглянуті.
- Цілі відновлення — RTO і RPO — задокументовані для кожного критичного сервісу та тестовані щонайменше раз на рік.
Найбільша прогалина, яку ми бачимо на ранніх перевірках DORA: реєстр ІКТ-ризиків, не повʼязаний із каталогом бізнес-процесів. Саме цей звʼязок робить пріоритезацію захищуваною.
TLPT — тест, через який усі хвилюються
Threat-Led Penetration Testing — зобовʼязання за статтею 25 DORA, про яке найбільше розмов у кулуарах. Суть:
- Обовʼязковий для «значущих» фінансових установ — поріг визначено в RTS, і фактично це «ви системні для фінансової системи ЄС» або працюєте в критичному кластері.
- Проводиться щонайменше раз на три роки, з обсягом, узгодженим із регулятором, на основі фази таргетування, керованої розвідкою загроз.
- Методологія узгоджена з рамкою TIBER-EU Європейського центрального банку. Якщо ви проходили TIBER-проєкт — ви проходили TLPT.
- Виконується зовнішніми тестувальниками, схваленими регулятором, із незалежним провайдером розвідки загроз для фази таргетування.
- Результати подаються регулятору разом із планом усунення та термінами.
TLPT — це не «прокачаний» red team. Це регуляторна вправа, яка за сумісництвом є red team. Результати, взаємодія з регулятором та очікування щодо документації відрізняються від вправи, яку команда безпеки купувала роками.
Звітування про інциденти за статтею 17 — новий спільний процес
Звітування про значні ІКТ-інциденти консолідується в єдиний процес за статтею 17. Пороги класифікації мають значення:
- Кількість постраждалих клієнтів.
- Кількість зачеплених транзакцій — за обсягом і вартістю.
- Репутаційний вплив.
- Тривалість збою.
- Географічне поширення (транскордонність запускає повідомлення між регуляторами).
- Втрати даних (звʼязок із зобовʼязаннями за статтею 33 GDPR).
Логіку класифікації треба задокументувати в IR-політиці. Регулятор її прочитає і перевірить, чи послідовно пороги застосовувалися до нещодавніх інцидентів.
Стаття 28 — ризики третіх сторін
Стаття 28 покладає на фінансову установу відповідальність за безпеку її критичних сторонніх ІКТ-провайдерів. Дві операційні зміни:
- Реєстр контрактних домовленостей з усіма сторонніми ІКТ-провайдерами, з позначеними критичними. Реєстр надається регулятору на запит.
- Передконтрактна due diligence та постійна оцінка критичних провайдерів — ці зобовʼязання не можна закрити, просто прийнявши SOC 2 Type II звіт провайдера.
На що дивитиметься перша перевірка
За досвідом установ, які ми супроводжували через їхню першу перевірку епохи DORA:
- Рамковий документ DORA, підписаний керівним органом.
- Звʼязок активів і бізнес-процесів; реєстр ризиків, що з нього випливає.
- Угода про обсяг TLPT і звіт про тест (якщо запланований).
- Вибірка інцидентів за останні 12 місяців і застосування порогів статті 17.
- Реєстр третіх сторін і найсвіжіша оцінка трьох головних критичних провайдерів.
- KPI: MTTD, MTTR, фактичні RTO/RPO проти цільових, дотримання SLA усунення вразливостей.
Де тут Sandline
Ми проводимо TLPT-вправи за методологією, узгодженою з TIBER-EU, програми управління вразливостями, що дають докази за статтею 9, та ретейнери реагування на інциденти, звірені з шаблонами статті 17. Ми не ваша юридична фірма і не писатимемо ваш рамковий документ DORA; ми виконуємо технічну роботу та готуємо пакет доказів, який хоче бачити регулятор.