🇪🇺DORA: во что операционная устойчивость обходится держателю EU-лицензии

Что такое DORA и кто в периметре

DORA — Регламент (ЕС) 2022/2554 о цифровой операционной устойчивости финансового сектора — применяется с 17 января 2025 года напрямую во всех странах ЕС, без национальной транспозиции. Регламент пришёл в паре с Директивой (ЕС) 2022/2556, и без неё конструкция не работала бы: директива вычищает разрозненные ICT-нормы из восьми отраслевых директив — UCITS, Solvency II, AIFMD, CRD IV, BRRD, MiFID II, PSD2 и IORP II. Иначе у необанка осталась бы своя норма об инцидентах в PSD2, у управляющей компании — своя в AIFMD, и «единая рамка» распалась бы на восемь несовпадающих. Директива вступила в силу 16 января 2023 года, её транспозиция синхронизирована с датой применения регламента.

В периметре около двадцати категорий: кредитные организации, необанки и EMI, провайдеры услуг информирования о счетах, крипто-провайдеры CASP по MiCA, инвестиционные фирмы, управляющие фондами — включая third-party ManCo, — страховщики и посредники, рейтинговые агентства, торговые площадки, центральные депозитарии, администраторы бенчмарков, платформы краудфандинга. Логика охвата простая: если у вас есть европейская финансовая лицензия, вы почти наверняка внутри. Практический вывод для тех, кто выбирает юрисдикцию по карте лицензий: DORA не зависит от того, где именно в ЕС вы лицензировались — литовский EMI и люксембургский живут по одному тексту.

Пропорциональность встроена в регламент, а не выпрашивается у надзора. Микропредприятие — меньше 10 сотрудников и годовой оборот либо баланс до €2 млн — работает по упрощённой рамке управления ICT-риском (ст. 16) и не проходит threat-led penetration testing. Часть субъектов выведена из-под регламента целиком: страховые посредники, являющиеся микропредприятиями, институты профессиональных пенсий с очень небольшим числом участников, отдельные малые категории. Но «мы маленькие, нас не касается» — опасное чтение: реестр контрактов и отчётность об инцидентах сдают все, кто внутри периметра, включая упрощённый режим.

Смысл конструкции один: держатель европейской лицензии обязан доказуемо переживать сбои ИТ, атаки и падения облачных провайдеров — и вовремя рассказывать о них надзору. В бюджете лицензированного бизнеса DORA — вторая по стоимости постоянная строка комплаенса после AML: она не разовая, растёт вместе с числом ИТ-зависимостей и проверяется уже на входе в лицензию.

Пять столпов: что реально требуют

Регламент разбит на пять блоков обязанностей. Четыре обязательны, пятый — добровольный. Ключевая деталь, которую пропускают чаще всего: рамку управления ICT-риском утверждает и несёт за неё персональную ответственность правление (ст. 5). «Делегировали айтишникам» не работает — надзор спрашивает протокол совета, а не тикет в Jira.

Разница между «критической или важной функцией» и обычной ИТ-услугой — главный водораздел регламента. От неё зависит, нужны ли усиленные договорные положения, аудит-права и exit-план. Классифицировать функции придётся самостоятельно и письменно: надзор проверяет не результат, а обоснование.

Отчётность об инцидентах: пороги и окна

Инцидент становится major по критериям ст. 18: число затронутых клиентов и контрагентов, длительность и время простоя, географический охват, потери данных (доступность, аутентичность, целостность, конфиденциальность), критичность затронутых сервисов и экономический ущерб. Пороги существенности детализирует Делегированный регламент 2024/1772, принятый 13 марта 2024 года и вступивший в силу 15 июля 2024-го. Содержание и сроки самих отчётов задаёт RTS 2025/301.

Двадцать четыре часа — это календарные часы, включая ночь с субботы на воскресенье. Отсюда практическое требование, которое не выводится из текста напрямую: дежурная схема и заранее заполненные шаблоны. Организация, которая начинает искать, кто имеет право подписать уведомление регулятору, в момент инцидента, окно пропускает.

Хорошая новость — дублирование действительно убрали. 17 января 2025 года EBA отозвала руководство об отчётности о крупных инцидентах по PSD2: необанки, EMI, банки и AISP теперь отчитываются один раз по DORA, а не дважды. Исключение осталось узкое — те PSP, что не попали в периметр DORA, вроде почтовых жиро-институтов и кредитных союзов.

Реестр ICT-контрактов: сдача раз в год и качество данных

Реестр информации — самая недооценённая обязанность DORA. Это не список подрядчиков, а структурированный набор связанных таблиц по шаблонам ESAs, с LEI каждого провайдера, кодами функций, признаком критичности, странами обработки данных и цепочкой субподряда.

Насколько это тяжело, показала генеральная репетиция. В dry run ESAs, результаты которого опубликованы 17 декабря 2024 года, реестры сдали почти 1 000 финансовых организаций ЕС. Все 116 проверок качества данных прошли 6,5% — то есть 93,5% сданных реестров содержали хотя бы одну ошибку. Половина остальных отделалась меньше чем пятью замечаниями, но сам разброс объясняет, почему ESAs назвали цель «достижимой», а не «достигнутой».

Дальше пошли боевые циклы. Первый общеевропейский сбор прошёл весной 2025 года: в Люксембурге окно CSSF длилось с 1 по 15 апреля, после чего национальные регуляторы к 30 апреля передали данные ESAs. Второй цикл — с 11 февраля по 31 марта 2026 года со срезом на 31 декабря 2025-го. Сами проверки не изменились, но их стали применять к большему числу полей: файлы, принятые в 2025-м, в 2026-м уже отклонялись. В периметр добавили филиалы компаний из третьих стран.

Реестр — не бюрократия ради бюрократии: именно из него ESAs берут данные для назначения критических провайдеров, и именно по нему надзор видит, у кого концентрация на одном облаке. Ошибки в реестре — первый повод для вопросов, а расхождения между реестрами разных организаций по одному и тому же провайдеру сверяются автоматически.

Статья 30, субподряд и exit-план: что переписывать в договорах

Это самый дорогой раздел регламента, потому что он требует не политики, а переподписания договоров. Статья 30 делит требования на два уровня.

Для любого ICT-договора обязательны: полное описание функций и услуг с указанием, разрешён ли субподряд и на каких условиях; страны оказания услуг, обработки и хранения данных с обязанностью уведомлять об изменении заранее; положения о доступности, аутентичности, целостности и конфиденциальности данных; гарантии доступа, возврата и извлечения данных при банкротстве, реструктуризации или прекращении договора; описания уровней сервиса и их обновления; поддержка при ICT-инциденте без доплаты либо по заранее определённой цене; обязанность полностью сотрудничать с компетентными и resolution-органами; права и сроки расторжения; участие персонала провайдера в программах обучения по цифровой устойчивости.

Для договоров, поддерживающих критическую или важную функцию, добавляется: полные описания уровней сервиса с точными количественными и качественными целевыми показателями; уведомления о событиях, способных существенно повлиять на оказание услуги; обязанность внедрять и тестировать планы непрерывности; участие в TLPT финансовой организации; неограниченные права доступа, инспекции и аудита — для самой организации, назначенного ею третьего лица и компетентного органа; и exit-стратегии с обязательным переходным периодом, в течение которого провайдер продолжает оказывать услугу, пока функция переносится.

Exit-план — то место, где формальный комплаенс ломается на первой же проверке. Реалистичный план не звучит как «переедем в другое облако за две недели». Он состоит из четырёх частей: сценарий деградации (что именно перестаёт работать и какие функции продолжают жить), извлечение данных в пригодном для использования формате с проверенной выгрузкой, идентифицированная альтернатива или собственный резервный контур, и подтверждение, что переход не нарушит регуляторные требования и не остановит обслуживание клиентов. План положено тестировать, а не только держать в папке.

Отдельная история — субподряд. Делегированный регламент 2025/532 опубликован в Официальном журнале 2 июля 2025 года и вступил в силу 22 июля. Путь у него был негладкий: ESAs внесли проект летом 2024-го, а 21 января 2025 года — через четыре дня после того, как DORA начала применяться, — Комиссия проект отклонила. Причина: статья 5 проекта возлагала обязанности по мониторингу всей цепочки субподряда, а это, по мнению Комиссии, выходило за пределы мандата, выданного ESAs статьёй 30(5) DORA, и не было напрямую связано с условиями субподряда. В принятом тексте эта статья отсутствует. Практический эффект: обязанность оценивать и контролировать цепочку под критической функцией никуда не делась — она в самом регламенте, — но детальной методики мониторинга в RTS нет, и надзор будет читать её через общие нормы ст. 28–30. Для многослойных BaaS-конструкций из мира embedded finance и для тех, кто работает под чужой лицензией, это означает необходимость видеть не только своего вендора, но и того, на ком стоит он.

Критические ICT-провайдеры: облако под прямым надзором ЕС

18 ноября 2025 года ESAs назначили первых 19 критических ICT-провайдеров (CTPP) — среди названных AWS, Microsoft, Google Cloud, Oracle, SAP и Deutsche Telekom. Это гиперскейлеры, операторы дата-центров, инфраструктурные и сетевые провайдеры и специализированные финтех-платформы. Список обновляется ежегодно.

Механика надзора устроена так: у каждого назначенного провайдера появляется Lead Overseer — одна из трёх ESAs, — и совместная проверочная команда из сотрудников ESAs и национальных регуляторов. Команда проводит ежегодные риск-оценки, направляет запросы, ведёт инспекции, в том числе на площадках провайдера, и выпускает рекомендации. Провайдер обязан назначить юридическое лицо в ЕС как точку координации. Надзор оплачивают сами провайдеры: сборы считаются от оборота по делегированному регламенту 2024/1505. Игнорирование рекомендаций Lead Overseer может стоить периодических штрафных платежей до 1% среднего дневного мирового оборота провайдера (ст. 35 DORA).

Для держателя лицензии designation не снимает ничего. Exit-стратегия, тест концентрации и договорные права остаются его обязанностью: ответственность не аутсорсится вместе с сервером, и надзор за AWS со стороны ESAs не является заменой вашему собственному надзору за AWS. Зато переговорная позиция изменилась в лучшую сторону — DORA-аддендумы у гиперскейлеров стали стандартным документом, а не результатом полугодовых переговоров. У небольшой организации появился шанс получить те же условия, что и у крупного банка, просто сославшись на регламент.

Enforcement и цена вопроса

Публичных штрафов именно «за DORA» к августу 2026 года не видно. Санкции отданы национальному праву (ст. 50–52), единого европейского потолка нет, часть стран допускает уголовную ответственность, и режимы у регуляторов разные. Но принуждение уже работает — на входе. Peer review ESMA по Мальте в июле 2025 года зафиксировал, что MFSA выдавала CASP-лицензии без адекватной оценки ICT-рисков, и выводы разослали всем регуляторам ЕС. С тех пор ICT-раздел заявки — полноценный фильтр: слабый DORA-блок останавливает досье так же надёжно, как слабый AML. Как собирается заявка — в гайде «Лицензия CASP по MiCA».

Вторая линия — данные. Реестры сверяются по всему ЕС автоматически, и расхождения превращаются в предписания. Цена несоответствия сегодня — не штраф, а месяцы задержки авторизации, паспортизации или сделки. Это же касается открытия и удержания счетов: контрагенты и корреспонденты всё чаще спрашивают DORA-документацию, и банкинг для лицензированного оператора стал разговором про ICT-устойчивость не в меньшей степени, чем про AML.

Сколько это стоит — вопрос, на который честного публичного ответа нет. Регламент цен не задаёт, официальной методики оценки затрат не публиковалось, а оценки консультантов расходятся на порядок и обычно прилагаются к коммерческому предложению. Считать разумнее не «сколько стоит DORA», а из чего складывается постоянная нагрузка, и каждая её строка выводится из конкретной статьи: выделенная функция контроля третьих сторон и ведение реестра (ст. 28), программа тестирования (ст. 24–25), TLPT раз в три года для назначенных организаций (ст. 26), независимая проверка рамки управления ICT-риском (ст. 6), обучение персонала и правления (ст. 13). Самая недооценённая строка — не тесты, а постоянная функция контроля провайдеров: она не заканчивается никогда и растёт с каждым новым вендором.

Одно распространённое заблуждение стоит снять: oversight fees по регламенту 2024/1505 платят сами критические провайдеры, а не пользующиеся ими финансовые организации. В вашу смету этот сбор не попадает — он попадает в цену облака.

Экономить законно на пропорциональности: упрощённая рамка для микропредприятий, отсутствие TLPT без назначения, аутсорс мониторинга. Но вместе с комплаенс-стеком оператора и AML-пакетом ЕС это фиксированная нагрузка, которая превращает «лицензию про запас» в дорогое хобби — и главный аргумент всерьёз считать аренду чужой лицензии на старте.

Как DORA видна снаружи: анкеты вендоров, сбои и due diligence

Держателю средств DORA не даёт прав напрямую: это надзорный регламент, а не потребительский. Иска из него не выведешь. Но за периметром лицензиата он меняет три практические вещи.

Первое: он объясняет анкеты. Если вы контрагент, вендор или портфельная компания финансовой организации, вопросы про ваш софт, интеграции, местоположение данных и субподрядчиков — это не любопытство, а заполнение чужого реестра информации. Отказ отвечать всё чаще означает отказ в обслуживании.

Второе: он задаёт рамку ожиданий при сбое. Оператор обязан классифицировать инцидент, уведомить надзор в считаные часы и восстановиться по протестированному плану, а не «как получится». Если сервис лежит третьи сутки, а внятного статуса нет, это само по себе сигнал о качестве рамки.

Третье: он даёт язык для due diligence. Выбирая, где держать операционные остатки, спросите три вещи: как прошла последняя сдача реестра информации, есть ли назначение на TLPT и когда он проводился, и что записано в exit-плане по основному облачному провайдеру. Ответы скажут больше, чем маркетинговый буклет. Особенно это касается сравнения площадок: у литовского EMI и люксембургского обязанности по DORA одинаковые, а вот зрелость их исполнения и надзорная строгость — разные.

Напоминание, которое DORA не отменяет: деньги в EMI не покрыты гарантией вкладов, и операционная устойчивость не заменяет safeguarding. Личная киберзащита семьи — тоже отдельная дисциплина, о ней в материале о кибербезопасности и приватности семьи.

Первый год инцидентов: цифры вместо страшилок

Первый годовой отчёт ESAs об инцидентах, опубликованный 3 июня 2026 года, подводит итог репортинга-2025: 3 383 major-инцидента, в среднем 0,18 на организацию в периметре. Больше 75% дали кредитный и платёжный сектор. 51% — системные сбои, 27% — внешние события, почти треть инцидентов вызвана отказами, приписываемыми третьим сторонам. Кибератаки — лишь 10%, и внутри них около двух третей приходится на DDoS и кражу или искажение данных. Треть инцидентов (1 056) имела трансграничный эффект, около 8% затронули больше десяти стран ЕС. При этом две трети инцидентов не вызвали или почти не вызвали перебоев в обслуживании, а почти 60% затронули меньше тысячи клиентов.

Из этих цифр следует главный вывод о природе регламента: DORA — не «закон про хакеров», а закон про зависимость от чужой инфраструктуры. Падение вашего вендора — ваш отчётный инцидент, и статистика первого года это подтверждает.

Пересечения: NIS2, MiCA, PSD2 и GDPR

Для финансового сектора DORA — lex specialis по отношению к NIS2. Лицензиат живёт по DORA и не отчитывается дважды. Но нефинансовые компании группы — холдинг, ИТ-дочка, сервисная компания — могут попасть под NIS2 самостоятельно, уже по национальным законам транспозиции, и это отдельный проект с отдельными сроками.

С MiCA пересечение прямое: CASP находится в периметре DORA с той же даты, и ICT-раздел лицензионного досье оценивается по DORA, а не по общим словам об информационной безопасности. Для тех, кто заходит под чужой лицензией MiCA, это означает, что принципал будет требовать DORA-совместимые обязательства по договору — он обязан включить вас в свой реестр.

С PSD2 дублирование снято директивой 2022/2556 и отзывом руководства EBA 17 января 2025 года. Впереди PSD3 и PSR: реавторизация EMI в единый PI прогонит ICT-блок через надзор заново, и заявку 2027–2028 годов придётся собирать уже с полноценной DORA-документацией.

С GDPR дублирование, наоборот, сохраняется, и это надо планировать. Уведомление об инциденте по DORA идёт финансовому надзору, уведомление о нарушении персональных данных по ст. 33 GDPR — в орган по защите данных, в течение 72 часов. Один и тот же инцидент может требовать обоих, по разным каналам, в разные сроки и с разным содержанием. Единая процедура реагирования должна разводить эти два потока автоматически.

Наконец, руководства EBA. Руководство по управлению ICT- и security-рисками EBA/GL/2019/04 не отменено целиком, но сужено с 11 февраля 2025 года: оно осталось только в части управления отношениями с пользователями платёжных услуг и только для организаций в периметре DORA. Всё остальное поглощено регламентом. Руководства по аутсорсингу продолжают жить в неICT-части, но ICT-аутсорсинг теперь читается по ст. 28–30 DORA.

Великобритания строит зеркальный контур. Правила о критических третьих сторонах (PS24/16) действуют с 1 января 2025 года, 10 июля 2026-го казначейство назначило первых четырёх — AWS, Google Cloud, Microsoft и Oracle, — а надзор Банка Англии, PRA и FCA начался 13 июля 2026 года. Группа с лицензиями в ЕС и Великобритании живёт в двух режимах одновременно, и договоры с общими вендорами приходится собирать под оба.

Календарь до 2028

Отдельно стоит следить за составом CTPP: список пересматривается ежегодно, и попадание в него вашего ключевого вендора меняет вашу же карту концентрации.