Регламент DORA — Закон про цифрову операційну стійкість — це закон ЄС про кіберстійкість фінансового сектору. Він визначає, як фінансові установи мають управляти кібербезпекою та IT-ризиками. Простими словами, кожен банк, платіжна компанія, інвестиційна фірма, страховик і криптобіржа в ЄС повинні бути здатні продовжувати роботу під час злому, збою хмарного сервісу чи невдалого оновлення ПЗ, а також контролювати IT-постачальників, від яких вони залежать.
Цей посібник написано для людей без юридичної або IT-підготовки. Він пояснює, на кого поширюється DORA, що вона вимагає, у які строки слід повідомляти про інцидент, чим вона відрізняється від NIS2 і GDPR, які передбачено санкції, що вимоги DORA означають для fintech і криптокомпаній, а також містить короткий чекліст відповідності DORA.
Що таке DORA простими словами?
DORA — іноді її називають EU DORA або DORA Act — це Регламент (ЄС) 2022/2554 про цифрову операційну стійкість фінансового сектору. «Цифрова операційна стійкість» звучить складно, але означає одне: чи може ваша компанія й надалі обслуговувати клієнтів, коли виникають проблеми з її IT? Зловмисник отримує доступ, оновлення не спрацьовує, постачальник вимикається — чи проходять платежі, чи можуть клієнти увійти до системи, чи залишаються їхні дані захищеними? DORA перетворює це питання з доброї практики на юридичний обов’язок.
До DORA кожна країна ЄС і кожна частина фінансового сектору мали власні правила IT-безпеки та форми повідомлень про інциденти. DORA замінює цю мозаїку єдиним звідником правил для всього фінансового сектору ЄС. Оскільки це регламент, а не директива, він застосовується дослівно в кожній державі-члені — для його запуску не потрібен національний закон.
Строк для виконання вимог DORA вже минув. Дворічний період підготовки після ухвалення завершився, усі обов’язки за DORA набрали чинності, а національні фінансові регулятори їх перевіряють. Система DORA спирається на п’ять складових, кожну з яких пояснено далі:
- управління ICT-ризиками — письмовий план IT-ризиків, за який відповідає орган управління (рада директорів);
- управління та повідомлення про ICT-інциденти — виявлення, фіксація й повідомлення наглядовому органу про IT-інциденти;
- тестування цифрової операційної стійкості — від регулярного сканування вразливостей до повних симуляцій атак «червоної команди»;
- управління ризиками ICT-третіх осіб — контроль IT-постачальників, від яких залежить фірма, із реєстром усіх таких постачальників;
- обмін інформацією — добровільний обмін даними про загрози між фінансовими суб’єктами.
Результати, а не технології
DORA не вказує, яке ПЗ чи якого постачальника використовувати. Вона встановлює результати: бути стійкими, виявляти проблеми, швидко відновлюватися, контролювати постачальників. Рада директорів відповідає за підтвердження досягнення цих результатів, а директори мають підтримувати свої знання про IT-ризики в актуальному стані (регламент прямо згадує навчання). Передати все IT-відділу та забути про це — саме те, що забороняє DORA.
Пояснення ключових термінів DORA
Кілька визначених термінів трапляються в кожній статті регламенту DORA, кожній наглядовій формі та кожному договорі з постачальником. Знаючи їх, решту тексту читати значно легше.
| Фінансовий суб’єкт | Термін регламенту для ліцензованої фінансової фірми — будь-якого з двадцяти типів, перелічених у статті 2. Якщо ви маєте одну з цих ліцензій, DORA стосується вас. |
|---|---|
| Постачальник ICT-послуг третьої сторони | Будь-яка компанія, що надає IT фінансовому суб’єкту: хмарний хостинг, ПЗ, потоки даних, керовану безпеку, обробку платежів. |
| Критичний постачальник ICT-послуг третьої сторони (CTPP) | Дуже великий постачальник — наприклад, велика хмарна платформа, — якого органи ЄС визначили для прямого нагляду Головним наглядачем, оскільки від нього залежить багато фірм. |
| Критична або важлива функція | Бізнес-функція, припинення якої серйозно зашкодило б фінансам фірми, порушило б її юридичні обов’язки або перервало ліцензовані послуги. Типові приклади — платежі та рахунки клієнтів. |
| Значний ICT-інцидент | IT-інцидент, достатньо масштабний за кількістю постраждалих клієнтів, тривалістю, втраченими даними чи сумою коштів, щоб вимагати обов’язкового повідомлення наглядовому органу. |
| Тестування на проникнення на основі загроз (TLPT) | Поглиблене тестування, під час якого етичні хакери атакують робочі системи так, як це зробив би реальний зловмисник. Потрібне щонайменше раз на три роки для фірм, визначених наглядовим органом; він може вимагати його частіше. |
| Реєстр інформації | Структурований перелік усіх IT-договорів фірми, який підтримується актуальним і надсилається наглядовому органу щонайменше раз на рік. |
| Регуляторні технічні стандарти (RTS) | Детальні правила «як це робити» — шаблони, пороги й методи, — які органи ЄС видають для конкретизації регламенту. |
На кого поширюється DORA?
Сфера дії DORA встановлена статтею 2, яка перелічує двадцять категорій фінансових суб’єктів. Якщо фінансова установа має одну з цих ліцензій будь-де в ЄС, вона охоплена регламентом — незалежно від розміру, — якщо не діє конкретний виняток. Основні групи наведено нижче.
| Сектор | Хто охоплений | Варто знати |
|---|---|---|
| Банківські та платіжні послуги | Банки, платіжні установи, установи електронних грошей, надавачі послуг з інформації про рахунки | Емітенти токенів електронних грошей за MiCA охоплені, оскільки мають бути банками або установами електронних грошей |
| Інвестиції та фонди | Інвестиційні фірми, керуючі фондами (AIFMs і UCITS), торговельні майданчики, центральні контрагенти, центральні депозитарії цінних паперів | Малі та невзаємопов’язані інвестиційні фірми застосовують полегшений режим |
| Криптоактиви | Надавачі послуг з криптоактивами та емітенти токенів, прив’язаних до активів | Обидва мають дозвіл за MiCA; охоплюються з дня видачі ліцензії |
| Страхування та пенсії | Страховики, перестраховики, страхові посередники, професійні пенсійні фонди | Мікро-, малі та середні посередники звільнені |
| Ринкові дані та інфраструктура | Кредитні рейтингові агентства, надавачі даних для звітності, репозиторії угод і сек’юритизації, адміністратори критично важливих бенчмарків | За кількома з них нагляд здійснюється безпосередньо на рівні ЄС |
| Інші | Краудфандингові платформи, постачальники ICT-послуг третьої сторони | Нижче пояснено, як охоплюються IT-постачальники |
А як щодо самих IT-компаній? Хмарні платформи, дата-центри, постачальники ПЗ і компанії з керованої безпеки не є фінансовими суб’єктами, але DORA поширюється на них двома шляхами. По-перше, кожен фінансовий суб’єкт має включити до договорів із ними умови у стилі DORA, тож постачальник, який відмовляється, ризикує втратити клієнта. По-друге, найбільших постачальників — великих хмарних, дата-центрових, телекомунікаційних і фінансових програмних компаній — визначають критичними постачальниками ICT-послуг третьої сторони та безпосередньо наглядають на рівні ЄС; перелік оновлюють щороку.
Чи поширюється DORA на компанії поза ЄС? Безпосередньо — лише на фірми, ліцензовані в ЄС, включно з дочірніми компаніями та філіями британських, американських чи азійських груп у ЄС. Опосередковано вона охоплює будь-якого іноземного постачальника, який обслуговує фінансову фірму ЄС, оскільки обов’язкові договірні положення діють незалежно від місця його реєстрації. Постачальник поза ЄС, визначений критичним, має створити дочірню компанію в ЄС протягом дванадцяти місяців.
Нарешті, DORA пропорційна: обов’язки зростають разом із розміром і складністю фінансової установи. Мікропідприємства — менше десяти працівників і менш як два мільйони євро обороту або балансу — звільняються від кількох вимог, зокрема TLPT та деяких обов’язків щодо управління і звітності. Визначена група менших фірм, як-от малі та невзаємопов’язані інвестиційні фірми й окремі звільнені платіжні установи та установи електронних грошей, застосовує спрощену систему управління ICT-ризиками за статтею 16. Малий розмір не виводить ліцензовану фірму з-під DORA; він лише зменшує навантаження.
Вимоги DORA: пояснення п’яти складових
Вимоги відповідності DORA поділяються на п’ять груп. Разом вони утворюють один цикл — запобігати, виявляти, реагувати, відновлюватися, навчатися — і регулятор очікує докази на кожному етапі.
Система управління ICT-ризиками (статті 5–16)
Простими словами: знайте, яке IT у вас є, що з ним може піти не так, і майте письмовий план його захисту та відновлення. Система повинна містити перелік IT-активів і залежностей, описувати, як фірма запобігає проблемам і виявляє їх, як реагує та відновлюється, а також як вчиться на інцидентах. Її переглядають щонайменше раз на рік і після кожного значного інциденту. Орган управління її затверджує, визначає прийнятний рівень ризику та виділяє бюджет. Критичні функції мають бути відображені, резервні копії мають фактично тестуватися, а план безперервності IT має доповнювати загальний план безперервності діяльності фірми.
Повідомлення про інциденти: строки 4 години, 72 години та один місяць
Кожен ICT-інцидент потрібно зафіксувати й класифікувати за однаковими в ЄС критеріями: скільки клієнтів постраждало, наскільки постраждала репутація фірми, як довго тривав інцидент, як далеко він поширився, які дані втрачено, наскільки критичною була послуга та які кошти були під загрозою. Інцидент, що перевищує пороги, є «значним» і про нього потрібно повідомити наглядовому органу в три етапи: перше повідомлення протягом чотирьох годин після рішення визнати його значним (і не пізніше 24 годин від моменту, коли фірма дізналася про нього), проміжний звіт протягом 72 годин після першого повідомлення та остаточний звіт протягом місяця після проміжного. Клієнтів, чиї кошти або дані постраждали, слід повідомити без зволікань. Про серйозні кіберзагрози, які ще не стали інцидентами, можна повідомляти добровільно.
Тестування стійкості та тестування на проникнення на основі загроз (TLPT)
Тестування цифрової операційної стійкості — це щорічна програма: кожна система, що підтримує критичну або важливу функцію, має проходити сканування вразливостей, аналіз прогалин, перевірку вихідного коду, сценарні й навантажувальні тести та тести на проникнення. Фірми, яких наглядовий орган вважає значущими через їхній розмір або наслідки збою, додатково мають проводити TLPT щонайменше раз на три роки. Це контрольована атака на робочі системи кваліфікованими етичними хакерами за визнаною методологією. Мікропідприємства та фірми зі спрощеним режимом звільнені від TLPT і тестуються за легшим графіком на основі ризику.
Ризик третіх осіб, аутсорсинг і реєстр інформації
Передача IT на аутсорсинг — хмарному постачальнику чи будь-кому іншому — не передає відповідальність. Управління ризиками ICT-третіх осіб починається з письмової стратегії ризиків постачальників; фірма повинна перевіряти їх до підписання договору, уникати надмірної залежності від одного постачальника та вести реєстр інформації — структурований перелік усіх IT-договорів, який подається наглядовому органу щонайменше раз на рік. Самі договори мають містити фіксований набір положень: що являє собою послуга й який рівень обіцяно, де зберігаються дані, право на перевірку й аудит, обов’язок допомагати під час інцидентів, умови припинення договору та порядок переходу до іншого постачальника за потреби. Фірма несе повну відповідальність навіть тоді, коли постачальник є критичним і наглядається на рівні ЄС.
Обмін інформацією про кіберзагрози
Фінансові суб’єкти можуть обмінюватися даними про загрози — моделями атак, індикаторами компрометації — у межах довірених груп. Ніхто не зобов’язаний долучатися, але фірма, яка це робить, має повідомити свого наглядового органу, а обмін повинен дотримуватися правил конфіденційності та захисту даних.
DORA проти NIS2 і GDPR: як узгоджуються правила
Три закони ЄС перетинаються щодо кіберстійкості та повідомлення про інциденти, і багато фінансових установ підпадають під дію більш ніж одного з них. Таблиця показує, кого охоплює кожен із них і чим відрізняються строки повідомлення.
| Аспект | DORA | Директива NIS2 | GDPR |
|---|---|---|---|
| Кого охоплює | Фінансові фірми та їхні IT-постачальники | Критично важливі та важливі суб’єкти у вісімнадцяти критичних секторах, зокрема банківському | Усіх, хто обробляє персональні дані |
| Що захищає | Безперервність фінансових послуг та їхнього IT | Безпеку мереж та інформації критичних секторів | Персональні дані фізичних осіб |
| Строк першого повідомлення | Протягом 4 годин після класифікації, максимум 24 години від виявлення | Раннє попередження протягом 24 годин | Протягом 72 годин органу захисту даних |
| Подальші звіти | Проміжний — через 72 години; остаточний — протягом одного місяця | Повідомлення через 72 години; остаточний звіт — протягом одного місяця | Поетапно, у міру встановлення фактів |
| Правова форма | Регламент — застосовується безпосередньо | Директива — кожна країна ухвалює власний закон | Регламент — застосовується безпосередньо |
| Взаємодія | Спеціальний закон: має перевагу над NIS2 для фінансових фірм | Застосовується до фінансових фірм лише там, де DORA не встановлює правил | Діє паралельно; один інцидент може спричинити обидва обов’язки |
На практиці фінансова фірма повідомляє про IT-інциденти своєму фінансовому наглядовому органу, а не національному агентству кібербезпеки. GDPR діє паралельно: якщо кібератака розкриває дані клієнтів, фірма повідомляє про неї двічі — за DORA фінансовому наглядовому органу та за GDPR органу захисту даних — за двома окремими строками.
DORA і криптовалюта: що це означає для CASPs та емітентів токенів
Для криптобізнесу регламент DORA та система MiCA працюють у парі. MiCA визначає, хто може надавати криптопослуги або випускати токени в ЄС; DORA визначає, як має функціонувати технологія, що лежить в основі цих послуг. Надавач послуг з криптоактивами, уповноважений за MiCA, є фінансовим суб’єктом за DORA з моменту видачі ліцензії, як і кожен емітент токенів, прив’язаних до активів. Сама MiCA відсилає до DORA щодо IT і вимог безпеки, тому кожен наглядовий орган читає їх разом.
На практиці стійкість перевіряють уже під час процесу ліцензування, а не лише після нього. Коли наглядовий орган розглядає заявку CASP, система IT-ризиків, план безперервності діяльності, процедури щодо інцидентів та механізми аутсорсингу входять до пакета документів, а DORA є критерієм їх оцінки. Криптобіржа або кастодіан не можуть отримати чи зберегти ліцензію, якщо план стійкості існує лише на папері.
Криптофірми також мають IT-залежності, яких не має банк: зберігання приватних ключів, постачальників блокчейн-вузлів, інфраструктуру сторонніх гаманців, компоненти смартконтрактів і ринки, що торгують цілодобово без вікна для технічного обслуговування. За DORA кожне з них є IT-активом або відносинами з постачальником, які потрібно перелічити, класифікувати, оформити договором і протестувати. Так неліцензовані постачальники хостингу, управління ключами чи блокчейн-інфраструктури також виконують DORA: через договори зі своїми клієнтами.
Штрафи, санкції та покарання DORA за недотримання
Єдиної загальноєвропейської таблиці санкцій DORA немає. Натомість стаття 50 доручає кожній державі-члену встановити «ефективні, пропорційні та стримувальні» покарання й надає наглядовим органам повноваження вимагати документи, проводити перевірки, наказувати усунути порушення та публікувати попередження. Їх застосовує національний компетентний орган кожної держави-члена відповідно до галузевого ліцензійного законодавства, тому банк, платіжна компанія та криптобіржа стикаються із санкційною шкалою свого сектору.
Можливо, ви бачили «штраф DORA» у розмірі одного відсотка середнього щоденного світового обороту. Ця цифра реальна, але стосується іншого: це щоденне покарання, яке Європейські наглядові органи можуть накласти на критичного постачальника ICT-послуг третьої сторони, що ігнорує наглядове рішення, строком до шести місяців. Це не штраф для банків чи криптокомпаній. «2% річного обороту», які іноді згадують поряд із ним, також не містяться в DORA: це положення NIS2, де воно є мінімальною межею для критично важливих суб’єктів. Для фінансової фірми реалістичні наслідки такі:
- наглядові заходи — накази усунути недоліки, обмеження діяльності та, у тяжких випадках, призупинення або втрата ліцензії;
- адміністративні штрафи за національним законодавством сектору;
- особиста відповідальність членів ради директорів, оскільки DORA покладає на неї відповідальність за IT-систему;
- кримінальна відповідальність у країнах, які вирішили її запровадити, що дозволяє стаття 52;
- репутаційні та комерційні збитки — втрата клієнтів, банків-партнерів та інвесторів.
Ризик для ліцензії фірм, уповноважених за MiCA
Для надавача послуг з криптоактивами найбільший ризик — це сама ліцензія. Належне IT-управління є умовою отримання ліцензії MiCA, тому повторні порушення DORA можуть розглядатися як невідповідність умовам авторизації, а не лише як одноразове порушення вимог.
Хто наглядає за DORA? Регулятори на національному рівні та рівні ЄС
Щоденний нагляд за DORA здійснює регулятор, який уже ліцензує фірму, — центральний банк або орган фінансового нагляду її держави-члена походження. Цей компетентний орган отримує повідомлення про інциденти та реєстри інформації, вирішує, хто має проводити TLPT, і перевіряє систему IT-ризиків у межах звичайного нагляду. Більшість із них публікують на своїх вебсайтах рекомендації DORA, шаблони та строки.
На рівні ЄС роботу ділять три органи: Європейське управління з цінних паперів і ринків, Європейський банківський орган і EIOPA, орган зі страхування та пенсій. Вони розробляють технічні стандарти, що уточнюють деталі, і спільно визначають критичних постачальників ICT-послуг третьої сторони; кожного з них наглядає один із цих трьох органів як Головний наглядач.
Чекліст відповідності DORA: як виконати вимоги
Незалежно від того, чи подає фірма заявку на ліцензію, чи вже перебуває під наглядом, однаковий набір документів підтверджує відповідність DORA під час аудиту. Практичний початок для плану впровадження DORA або аналізу прогалин:
- Підтвердьте свою сферу: до якої категорії статті 2 ви належите та чи застосовується спрощений режим або виняток для мікропідприємства.
- Відобразіть кожен IT-актив, систему й потік даних, що підтримує критичну або важливу функцію.
- Ухваліть політику управління ICT-ризиками, затверджену радою директорів, із визначеними відповідальними особами та щорічним переглядом.
- Запровадьте класифікацію інцидентів, журнал інцидентів і шаблони повідомлень, що відповідають установленим строкам.
- Складіть щорічний календар тестування та перевірте, чи включив вас наглядовий орган до списку TLPT.
- Складіть реєстр інформації про всіх IT-постачальників та оновіть їхні договори обов’язковими положеннями.
- Перевірте ризик концентрації та підготуйте плани виходу для постачальників, що підтримують критичні функції.
- Тестуйте резервні копії, відновлення та план безперервності IT щонайменше раз на рік.
- Навчайте раду директорів і зберігайте підтвердження проведення навчання.
Eesti Firma консультує fintech і криптокомпанії щодо юридичної сторони DORA: визначає застосовні обов’язки, узгоджує IT-систему з вимогами ліцензування MiCA, перевіряє договори з постачальниками та готує документи, які очікує побачити наглядовий орган. Зверніться до нас, щоб обговорити, як регламент застосовується до вашого бізнесу.
Поширені запитання про DORA
DORA означає Digital Operational Resilience Act — регламент ЄС з єдиними правилами управління ICT-ризиками, повідомлення про інциденти, тестування стійкості та ризиків третіх осіб для фінансового сектору. Він безпосередньо застосовується в усіх державах-членах і повністю набрав чинності.
На двадцять категорій ліцензованих у ЄС фінансових установ — банки, платіжні установи й установи електронних грошей, інвестиційні фірми, керуючих фондами, страховиків, надавачів послуг з криптоактивами та ринкову інфраструктуру — а через договори й нагляд ЄС також на IT-постачальників, які їх обслуговують.
Так. Період підготовки після ухвалення завершився, і всі обов’язки застосовуються повною мірою. Наглядові органи тепер розглядають DORA як частину звичайного ліцензування та перевірок, а не як майбутній проєкт.
Лише на їхні дочірні компанії та філії, ліцензовані в ЄС. Постачальники поза ЄС, які обслуговують фінансові фірми ЄС, опосередковано зобов’язані виконувати вимоги через обов’язкові договірні положення, а критичний постачальник поза ЄС має створити дочірню компанію в ЄС протягом дванадцяти місяців.
NIS2 — загальна директива з кібербезпеки для критичних секторів; DORA — спеціальний регламент для фінансового сектору. Якщо можуть застосовуватися обидві, DORA має пріоритет щодо управління IT-ризиками та повідомлення про інциденти, а фінансові фірми звітують своєму фінансовому наглядовому органу, а не національному агентству кібербезпеки.
Так. Надавачі послуг з криптоактивами та емітенти токенів, прив’язаних до активів, ліцензовані за MiCA, є фінансовими суб’єктами за DORA. Емітенти токенів електронних грошей охоплені як банки або установи електронних грошей. Неліцензовані постачальники цим фірмам виконують DORA опосередковано через умови договорів.
У три етапи: перше повідомлення протягом чотирьох годин після класифікації інциденту як значного й не пізніше 24 годин після його виявлення, проміжний звіт протягом 72 годин після першого та остаточний звіт протягом місяця після проміжного.
Санкції для фінансових фірм встановлюються національним правом за статтею 50 та застосовуються національним наглядовим органом: від наказів усунути проблеми й штрафів до втрати ліцензії. Один відсоток щоденного світового обороту — це покарання для критичних постачальників ICT-послуг третьої сторони під наглядом ЄС, а не для фінансових фірм.
Так, але пропорційно. Мікропідприємства звільняються від TLPT, фіксованої щорічної вимоги тестування та деяких обов’язків управління, а визначена група менших фірм застосовує спрощену систему управління ICT-ризиками. Малий розмір не виводить ліцензовану фірму зі сфери дії.
