🇪🇺DORA: требования к операционной устойчивости финансовых организаций ЕС

Сфера применения DORA

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

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

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

Финансовая организация должна документировать управление ICT-риском, тестировать устойчивость, сообщать о major incidents и контролировать ICT third-party risk. Публичного универсального ориентира стоимости соблюдения нет; расходы зависят от масштаба, архитектуры, числа поставщиков и критичности функций.

Ключевые параметры режима — одной таблицей; каждый из них раскрыт в разделах ниже.

Пять блоков требований

Регламент разбит на пять блоков обязанностей. Четыре обязательны, пятый — добровольный. Рамку управления ICT-риском (ICT risk management framework) утверждает и несёт за неё персональную ответственность управляющий орган (ст. 5). Операционное выполнение можно делегировать, но ответственность и надзор управляющего органа сохраняются.

Классификация функции как критической или важной (critical/important) определяет объём усиленных договорных и контрольных требований. От неё зависит, нужны ли усиленные договорные положения, аудит-права и exit-план. Классификация и её обоснование должны быть документированы и пересматриваться при изменении услуги или риска.

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

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

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

DORA координирует часть отраслевой отчётности об ICT incidents. 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-план — то место, где формальный комплаенс ломается на первой же проверке. Реалистичный план не звучит как «переедем в другое облако за две недели». Он состоит из четырёх частей:

1. Сценарий деградации: что именно перестаёт работать и какие функции продолжают жить.
2. Извлечение данных в пригодном для использования формате с проверенной выгрузкой.
3. Идентифицированная альтернатива или собственный резервный контур.
4. Подтверждение, что переход не нарушит регуляторные требования и не остановит обслуживание клиентов.

План положено тестировать, а не только держать в папке.

Отдельная история — субподряд. Делегированный регламент 2025/532 опубликован в Официальном журнале 2 июля 2025 года и вступил в силу 22 июля.

Путь у него был негладкий: ESAs внесли проект летом 2024-го, а 21 января 2025 года — через четыре дня после того, как DORA начала применяться, — Комиссия проект отклонила. Причина: статья 5 проекта возлагала обязанности по мониторингу всей цепочки субподряда, а это, по мнению Комиссии, выходило за пределы мандата, выданного ESAs статьёй 30(5) DORA, и не было напрямую связано с условиями субподряда.

В принятом тексте эта статья отсутствует, но мониторинг цепочки из RTS не исчез: ст. 4 принятого регламента требует, чтобы договор обязывал самого ICT-провайдера контролировать все субподрядные услуги под критической функцией и отчитываться о них перед финансовой организацией. Практический эффект иной: собственная обязанность организации оценивать цепочку осталась в самом регламенте (ст. 28–30), а текущий контроль за субподрядчиками RTS возлагает на провайдера через договорные условия.

Для многослойных BaaS-конструкций из мира embedded finance и для тех, кто работает под чужой лицензией, это означает необходимость видеть не только своего вендора, но и того, на ком стоит он.

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

18 ноября 2025 года ESAs назначили первую группу критических ICT-провайдеров (CTPP — critical ICT third-party provider). Сам перечень ESAs публикуют отдельным файлом: в тексте самого релиза ни числа назначенных, ни имён нет, поэтому состав проверяется по перечню, а не по пересказам. Критерии назначения — системная значимость провайдера, его роль в поддержке критических или важных функций и заменимость услуг; в периметр попадают услуги от базовой инфраструктуры до бизнес- и дата-сервисов. Назначение пересматривается ежегодно.

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

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

Правоприменение и цена вопроса

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

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

Сколько это стоит — вопрос, на который честного публичного ответа нет. Регламент цен не задаёт, официальной методики оценки затрат не публиковалось, а оценки консультантов расходятся на порядок и обычно прилагаются к коммерческому предложению. Считать разумнее не «сколько стоит DORA», а из чего складывается постоянная нагрузка, и каждая её строка выводится из конкретной статьи.

Самая недооценённая строка — не тесты, а постоянная функция контроля провайдеров: она не заканчивается никогда и растёт с каждым новым вендором.

Одно распространённое заблуждение стоит снять: 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 на организацию в периметре. Основные причины — системные сбои и внешние события; кибератаки дали лишь 10% случаев, а управление риском третьих сторон отмечено как отдельная точка озабоченности. Около трети инцидентов имели трансграничный эффект — это ESAs связывают с общей инфраструктурой и общими сервисами; прямое влияние на клиентов и транзакции в отчёте оценено как в целом ограниченное.

Из этих цифр следует главный вывод о природе регламента: 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: список пересматривается ежегодно, и попадание в него ключевого вендора меняет карту концентрации самой организации.