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

> Пять столпов, реестры ICT-контрактов, надзор за облаками и TLPT: что DORA реально требует от банка, EMI и CASP — и во что это обходится.

Author: Ксения Воронова — юрист, Family Office (https://wiki.private.law/authors/voronova)
Last modified: 2026-08-14T13:12:00.000Z
Canonical: https://wiki.private.law/dora-eu
Topics: banking
Jurisdictions: eu
Product tags: compliance, banking, crypto
Semantic tags: compliance, banking, crypto

---

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

DORA — [Регламент \(ЕС\) 2022/2554](https://eur-lex.europa.eu/eli/reg/2022/2554/oj) о цифровой операционной устойчивости финансового сектора — применяется с 17 января 2025 года напрямую во всех странах ЕС, без национальной транспозиции. Регламент пришёл в паре с [Директивой \(ЕС\) 2022/2556](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022L2556), и без неё конструкция не работала бы: директива вычищает разрозненные ICT-нормы из восьми отраслевых директив — UCITS, Solvency II, AIFMD, CRD IV, BRRD, MiFID II, PSD2 и IORP II. Иначе у необанка осталась бы своя норма об инцидентах в PSD2, у управляющей компании — своя в AIFMD, и «единая рамка» распалась бы на восемь несовпадающих. Директива вступила в силу 16 января 2023 года, её транспозиция синхронизирована с датой применения регламента.

В периметре около двадцати категорий: кредитные организации, необанки и EMI, провайдеры услуг информирования о счетах, крипто-провайдеры CASP по MiCA, инвестиционные фирмы, управляющие фондами — включая [third-party ManCo](https://wiki.private.law/third-party-manco-eu), — страховщики и посредники, рейтинговые агентства, торговые площадки, центральные депозитарии, администраторы бенчмарков, платформы краудфандинга. Логика охвата простая: если у вас есть европейская финансовая лицензия, вы почти наверняка внутри. Практический вывод для тех, кто выбирает юрисдикцию по [карте лицензий](https://wiki.private.law/fintech-license-map): DORA не зависит от того, где именно в ЕС вы лицензировались — литовский EMI и люксембургский живут по одному тексту.

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

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

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

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

| **Столп** | **Что физически должно существовать** | **Периодичность** | **Статьи DORA** |
| --- | --- | --- | --- |
| Управление ICT-риском | Рамка, утверждённая правлением; реестр ИТ-активов и зависимостей; карта критических и важных функций; политики непрерывности и планы восстановления; независимая проверка рамки | Пересмотр не реже раза в год и после каждого крупного инцидента | ст. 5–16 |
| Отчётность об инцидентах | Процедура классификации по единым порогам; шаблоны первичного, промежуточного и финального отчётов; канал в национальный надзор; журнал всех инцидентов, включая не-major | По событию плюс ежегодная агрегированная отчётность | ст. 17–23 |
| Тестирование устойчивости | Программа тестирования: сканирование уязвимостей, тесты сценариев, тесты непрерывности и восстановления; для назначенных организаций — TLPT с привлечением аккредитованных тестировщиков | Базовая программа — ежегодно; TLPT — не реже раза в три года | ст. 24–27 |
| Риск третьих сторон | Реестр информации по всем ICT-контрактам; договорные положения ст. 30; due diligence до подписания; оценка концентрации; документированные exit-стратегии | Реестр — ежегодная сдача; стратегия и оценка — ежегодный пересмотр | ст. 28–30 |
| Обмен информацией об угрозах | Соглашение об обмене индикаторами компрометации в доверенном сообществе; уведомление надзора об участии | Добровольно | ст. 45 |

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

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

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

| **Отчёт** | **Срок** | **Отсчёт от** |
| --- | --- | --- |
| Первичное уведомление | 4 часа с момента классификации инцидента как major, но не позднее 24 часов с момента обнаружения | обнаружение и классификация |
| Промежуточный отчёт | 72 часа | первичное уведомление |
| Обновление промежуточного отчёта | без задержки при существенном изменении статуса или восстановлении обычной работы | по событию |
| Финальный отчёт | не позднее 1 месяца | последний промежуточный отчёт |
| Уведомление о значимой киберугрозе | добровольно, фиксированного окна нет | — |

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

Хорошая новость — дублирование действительно убрали. 17 января 2025 года EBA [отозвала руководство об отчётности о крупных инцидентах по PSD2](https://www.eba.europa.eu/publications-and-media/press-releases/eba-repeals-guidelines-major-incident-reporting-under-revised-payment-services-directive): необанки, EMI, банки и AISP теперь отчитываются один раз по DORA, а не дважды. Исключение осталось узкое — те PSP, что не попали в периметр DORA, вроде почтовых жиро-институтов и кредитных союзов.

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

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

Насколько это тяжело, показала генеральная репетиция. В [dry run ESAs](https://www.eba.europa.eu/publications-and-media/press-releases/esas-dry-run-exercise-shows-goal-reporting-registers-information-under-digital-operational), результаты которого опубликованы 17 декабря 2024 года, реестры сдали почти 1 000 финансовых организаций ЕС. Все 116 проверок качества данных прошли **6,5%** — то есть 93,5% сданных реестров содержали хотя бы одну ошибку. Половина остальных отделалась меньше чем пятью замечаниями, но сам разброс объясняет, почему ESAs назвали цель «достижимой», а не «достигнутой».

Дальше пошли боевые циклы. Первый общеевропейский сбор прошёл весной 2025 года: в Люксембурге [окно CSSF](https://www.cssf.lu/en/2025/04/dora-submission-timeframe-for-register-of-information-edesk-portal-open-as-of-1-april-2025/) длилось с 1 по 15 апреля, после чего национальные регуляторы к 30 апреля передали данные ESAs. Второй цикл — [с 11 февраля по 31 марта 2026 года](https://www.cssf.lu/en/2026/02/dora-submission-timeframe-for-register-of-information-edesk-portal-open-as-of-11-february-2026/) со срезом на 31 декабря 2025-го. Сами проверки не изменились, но их стали применять к большему числу полей: файлы, принятые в 2025-м, в 2026-м уже отклонялись. В периметр добавили филиалы компаний из третьих стран.

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

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

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

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

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

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

Отдельная история — субподряд. [Делегированный регламент 2025/532](https://eur-lex.europa.eu/eli/reg_del/2025/532/oj) опубликован в Официальном журнале 2 июля 2025 года и вступил в силу 22 июля. Путь у него был негладкий: ESAs внесли проект летом 2024-го, а 21 января 2025 года — через четыре дня после того, как DORA начала применяться, — Комиссия проект отклонила. Причина: статья 5 проекта возлагала обязанности по мониторингу всей цепочки субподряда, а это, по мнению Комиссии, выходило за пределы мандата, выданного ESAs статьёй 30\(5\) DORA, и не было напрямую связано с условиями субподряда. В принятом тексте эта статья отсутствует. Практический эффект: обязанность оценивать и контролировать цепочку под критической функцией никуда не делась — она в самом регламенте, — но детальной методики мониторинга в RTS нет, и надзор будет читать её через общие нормы ст. 28–30. Для многослойных BaaS-конструкций из мира [embedded finance](https://wiki.private.law/embedded-finance) и для тех, кто работает [под чужой лицензией](https://wiki.private.law/license-for-rent), это означает необходимость видеть не только своего вендора, но и того, на ком стоит он.

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

18 ноября 2025 года ESAs [назначили первых 19 критических ICT-провайдеров](https://www.eiopa.europa.eu/european-supervisory-authorities-designate-critical-ict-third-party-providers-under-digital-2025-11-18_en) \(CTPP\) — среди названных AWS, Microsoft, Google Cloud, Oracle, SAP и Deutsche Telekom. Это гиперскейлеры, операторы дата-центров, инфраструктурные и сетевые провайдеры и специализированные финтех-платформы. Список обновляется ежегодно.

Механика надзора устроена так: у каждого назначенного провайдера появляется Lead Overseer — одна из трёх ESAs, — и совместная проверочная команда из сотрудников ESAs и национальных регуляторов. Команда проводит ежегодные риск-оценки, направляет запросы, ведёт инспекции, в том числе на площадках провайдера, и выпускает рекомендации. Провайдер обязан назначить юридическое лицо в ЕС как точку координации. Надзор оплачивают сами провайдеры: [сборы считаются от оборота](https://eur-lex.europa.eu/eli/reg_del/2024/1505/oj) по делегированному регламенту 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»](https://wiki.private.law/casp-license-guide).

Вторая линия — данные. Реестры сверяются по всему ЕС автоматически, и расхождения превращаются в предписания. Цена несоответствия сегодня — не штраф, а месяцы задержки авторизации, паспортизации или сделки. Это же касается открытия и удержания счетов: контрагенты и корреспонденты всё чаще спрашивают DORA-документацию, и [банкинг для лицензированного оператора](https://wiki.private.law/banking-for-msb) стал разговором про ICT-устойчивость не в меньшей степени, чем про AML.

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

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

Экономить законно на пропорциональности: упрощённая рамка для микропредприятий, отсутствие TLPT без назначения, аутсорс мониторинга. Но вместе с [комплаенс-стеком оператора](https://wiki.private.law/compliance-stack) и [AML-пакетом ЕС](https://wiki.private.law/eu-aml-package) это фиксированная нагрузка, которая превращает «лицензию про запас» в дорогое хобби — и главный аргумент всерьёз считать аренду чужой лицензии на старте.

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

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

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

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

Третье: он даёт язык для due diligence. Выбирая, где держать операционные остатки, спросите три вещи: как прошла последняя сдача реестра информации, есть ли назначение на TLPT и когда он проводился, и что записано в exit-плане по основному облачному провайдеру. Ответы скажут больше, чем маркетинговый буклет. Особенно это касается сравнения площадок: у [литовского EMI](https://wiki.private.law/emi-license-lithuania) и [люксембургского](https://wiki.private.law/emi-license-luxembourg) обязанности по DORA одинаковые, а вот зрелость их исполнения и надзорная строгость — разные.

Напоминание, которое DORA не отменяет: деньги в EMI не покрыты гарантией вкладов, и операционная устойчивость не заменяет safeguarding. Личная киберзащита семьи — тоже отдельная дисциплина, о ней в материале о [кибербезопасности и приватности семьи](https://wiki.private.law/family-cybersecurity).

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

[Первый годовой отчёт ESAs](https://www.esma.europa.eu/press-news/esma-news/esas-publish-first-report-dora-major-ict-related-incidents) об инцидентах, опубликованный 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](https://eur-lex.europa.eu/eli/dir/2022/2555/oj). Лицензиат живёт по DORA и не отчитывается дважды. Но нефинансовые компании группы — холдинг, ИТ-дочка, сервисная компания — могут попасть под NIS2 самостоятельно, уже по национальным законам транспозиции, и это отдельный проект с отдельными сроками.

С MiCA пересечение прямое: CASP находится в периметре DORA с той же даты, и ICT-раздел лицензионного досье оценивается по DORA, а не по общим словам об информационной безопасности. Для тех, кто заходит [под чужой лицензией MiCA](https://wiki.private.law/white-label-casp), это означает, что принципал будет требовать DORA-совместимые обязательства по договору — он обязан включить вас в свой реестр.

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

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

Наконец, руководства EBA. Руководство по управлению ICT- и security-рисками EBA/GL/2019/04 не отменено целиком, но [сужено с 11 февраля 2025 года](https://www.eba.europa.eu/publications-and-media/press-releases/eba-amends-its-guidelines-ict-and-security-risk-management-measures-context-dora-application): оно осталось только в части управления отношениями с пользователями платёжных услуг и только для организаций в периметре DORA. Всё остальное поглощено регламентом. Руководства по аутсорсингу продолжают жить в неICT-части, но ICT-аутсорсинг теперь читается по ст. 28–30 DORA.

Великобритания строит зеркальный контур. Правила о критических третьих сторонах \([PS24/16](https://www.fca.org.uk/publications/policy-statements/ps24-16-operational-resilience-critical-third-parties-uk-financial-sector)\) действуют с 1 января 2025 года, 10 июля 2026-го казначейство назначило первых четырёх — AWS, Google Cloud, Microsoft и Oracle, — а [надзор Банка Англии, PRA и FCA](https://www.bankofengland.co.uk/news/2026/july/uk-financial-regulators-to-begin-overseeing-critical-third-parties-announced-by-hmt) начался 13 июля 2026 года. Группа с лицензиями в ЕС и Великобритании живёт в двух режимах одновременно, и договоры с общими вендорами приходится собирать под оба.

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

| **Дата** | **Веха** |
| --- | --- |
| 16 января 2023 | Директива \(ЕС\) 2022/2556 вступила в силу |
| 15 июля 2024 | Вступил в силу RTS 2024/1772 о классификации инцидентов |
| 17 декабря 2024 | ESAs опубликовали итоги dry run по реестрам: 6,5% без ошибок |
| 17 января 2025 | DORA применяется; EBA отозвала руководство по отчётности об инцидентах PSD2 |
| 21 января 2025 | Комиссия отклонила проект RTS о субподряде |
| 11 февраля 2025 | EBA сузила руководство EBA/GL/2019/04 по ICT- и security-рискам |
| 1–15 апреля 2025 | Первая боевая сдача реестра информации \(окно CSSF\) |
| 2 и 22 июля 2025 | Публикация и вступление в силу RTS о субподряде 2025/532 |
| 18 ноября 2025 | ESAs назначили первых 19 критических ICT-провайдеров |
| 17 января 2026 | Срок обзора Комиссии по требованиям к аудиторам \(ст. 58\) |
| 11 февраля — 31 марта 2026 | Вторая сдача реестра, срез на 31 декабря 2025 |
| 3 июня 2026 | Первый годовой отчёт ESAs об инцидентах |
| 13 июля 2026 | Великобритания: начало надзора за критическими третьими сторонами |
| 2027 и далее | Ежегодная сдача реестра; ежегодное обновление списка CTPP |
| 17 января 2028 | Общий обзор DORA: критерии назначения CTPP, добровольность уведомлений о киберугрозах, надзор за провайдерами из третьих стран, работа Joint Oversight Network |
| ≈2028–2029 | Реавторизация EMI в PI по PSD3: ICT-блок проверяется заново |

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

> 🍓 DORA не спрашивает, случаются ли у вас сбои, — она спрашивает, управляете ли вы ими доказуемо: реестр зависимостей, отчёт в срок, протестированное восстановление, договор с правами аудита и работающий exit-план. Ответственность за провайдера не аутсорсится вместе с сервером: назначение AWS критическим провайдером не снимает с вас ни одной обязанности. Ключевые окна — 4 часа с классификации и 24 часа с обнаружения инцидента, ежегодная сдача реестра в феврале–марте и TLPT раз в три года для назначенных. Публичных штрафов пока нет, но рычаг работает на входе: слабый ICT-раздел тормозит лицензию, паспортизацию и сделку. До 17 января 2028 года Комиссия пересмотрит режим целиком — расширения периметра вероятнее сужения.

## Q/A

### **Мы микропредприятие с EMI-лицензией — что из DORA обязательно**

Упрощённая рамка по ст. 16: базовое управление ICT-риском, отчётность об инцидентах и реестр контрактов сдаются в любом случае, TLPT не требуется. Порог микропредприятия — меньше 10 сотрудников и оборот либо баланс до €2 млн; при его превышении вы автоматически переезжаете в полный режим, и переезд лучше готовить заранее. Сбор реестров 2026 года охватил всех, включая филиалы компаний из третьих стран, так что «нас не заметят» — плохая стратегия.

### **Наш продукт целиком на AWS — это теперь проблема**

Нет. Designation критического провайдера не запрещает им пользоваться и не переносит ответственность на ESAs: надзор за самим AWS они ведут, надзор за вашей зависимостью от AWS — по-прежнему вы. Ваши обязанности прежние: договор с полным набором условий ст. 30, включая неограниченные права аудита и участие в TLPT, документированная оценка концентрации и протестированный exit-план. Плюс с 2025 года — прослеживание цепочки субподряда под критической функцией.

### **Какие договоры придётся переписать в первую очередь**

Те, что поддерживают критические или важные функции: облако, core banking, процессинг, KYC/AML-вендор, поставщик карточного процессинга, хостинг. Для них нужен полный набор ст. 30\(3\) — количественные SLA, права доступа и аудита для вас и для регулятора, обязанность участвовать в TLPT, планы непрерывности и exit-положения с переходным периодом. Остальные ICT-договоры обходятся набором ст. 30\(2\), но в реестр попадают все без исключения.

### **Штрафов ещё нет — можно отложить до 2027 года**

Рычаг уже действует: реестры сверяются автоматически, слабый ICT-раздел тормозит лицензии и паспортизацию, а первый major-инцидент без корректной отчётности превращается в надзорное дело. Санкции отданы национальному праву, единого потолка нет, и часть стран допускает уголовную ответственность. Проверять ретроспективно будут записи 2025–2026 годов — то есть те, которые создаются или не создаются прямо сейчас.

---

## FAQ

### Какие договоры придётся переписать в первую очередь

Те, что поддерживают критические или важные функции: облако, core banking, процессинг, KYC/AML-вендор, поставщик карточного процессинга, хостинг. Для них нужен полный набор ст. 30(3) — количественные SLA, права доступа и аудита для вас и для регулятора, обязанность участвовать в TLPT, планы непрерывности и exit-положения с переходным периодом. Остальные ICT-договоры обходятся набором ст. 30(2), но в реестр попадают все без исключения.

---

## Factual claims

- DORA — Регламент (ЕС) 2022/2554 о цифровой операционной устойчивости финансового сектора — применяется с 17 января 2025 года напрямую во всех странах ЕС, без национальной транспозиции.
- 18 ноября 2025 года ESAs назначили первых 19 критических ICT-провайдеров (CTPP) — среди названных AWS, Microsoft, Google Cloud, Oracle, SAP и Deutsche Telekom.
- Публичных штрафов именно «за DORA» к августу 2026 года не видно.
- Одно распространённое заблуждение стоит снять: oversight fees по регламенту 2024/1505 платят сами критические провайдеры, а не пользующиеся ими финансовые организации.
- Экономить законно на пропорциональности: упрощённая рамка для микропредприятий, отсутствие TLPT без назначения, аутсорс мониторинга.
- Первый годовой отчёт ESAs об инцидентах, опубликованный 3 июня 2026 года, подводит итог репортинга-2025: 3 383 major-инцидента, в среднем 0,18 на организацию в периметре.
- Из этих цифр следует главный вывод о природе регламента: DORA — не «закон про хакеров», а закон про зависимость от чужой инфраструктуры.
- Для финансового сектора DORA — lex specialis по отношению к NIS2.