DORA (Digital Operational Resilience Act, Регламент ЕС 2022/2554) действует с 17 января 2025 года и применяется напрямую без национальной транспозиции. Касается примерно 22 000 финансовых субъектов в ЕС — банков, страховщиков, инвестиционных компаний, криптоплатформ, платёжных учреждений — и принципиально также их ICT third-party providers, включая SaaS-поставщиков ERP/CRM. Пять столпов DORA охватывают управление ICT-рисками, отчётность об инцидентах, тестирование устойчивости, риски третьих сторон и обмен информацией. Санкции могут достигать 1 % дневного оборота на время нарушения.

Эта статья продолжает pillar о безопасности и compliance в cloud ERP. Объясняет, кого DORA касается напрямую, кого — опосредованно через цепочку поставок, и какие конкретные требования должен выполнять SaaS ERP, обслуживающий регулируемые финансовые субъекты.

Почему DORA и чем отличается от других регулирований

До DORA цифровая устойчивость финансовых субъектов регулировалась фрагментированно — руководства EBA для банков, EIOPA для страховщиков, ESMA для инвестиционных компаний. DORA объединяет это в одном регламенте с прямым действием по всему ЕС.

Ключевые новшества:

  • Прямое регулирование ICT third-party. Если вы «критический» ICT-поставщик для финансового сектора, органы ЕС могут надзирать за вами напрямую (через новый Joint Oversight Forum).
  • Threat-led penetration testing (TLPT). Крупные финансовые субъекты обязаны проводить TLPT каждые 3 года.
  • Стандартизированная отчётность об инцидентах с гармонизированными порогами.
  • Register of information — обязательный реестр всех ICT-договорных соглашений.

DORA отличается от NIS2 в двух главных вещах: она секторальная (только финансовый сектор) и строже (lex specialis). Если вы банк, на вас распространяются оба режима, но DORA имеет приоритет.

Кого касается DORA

Прямо регулируемые субъекты

DORA перечисляет в ст. 2 более 20 типов субъектов. Наиболее релевантные для ЕС:

  • Кредитные учреждения (банки)
  • Платёжные учреждения и учреждения электронных денег
  • Инвестиционные компании и брокеры
  • Страховщики и перестраховщики
  • Управляющие компании
  • Поставщики услуг в сфере криптоактивов (CASP согласно MiCA)
  • Биржи и центральные депозитарии
  • Краудфандинговые платформы
  • Аудиторы и консультанты (частично, только отчётность)

Опосредованно через цепочку поставок

DORA вводит концепцию ICT third-party service provider. Если вы оказываете IT-услуги финансовому субъекту — включая SaaS ERP, CRM, облачный хостинг, email, identity provider, мониторинг — ваш клиент применяет к вам требования DORA через договор.

Это означает, что даже если вы не банк, если ваши клиенты — банки/страховщики, фактически вы должны соответствовать DORA на уровне технологии и документации.

Критические ICT-поставщики (CTPP)

Органы ЕС (EBA, EIOPA, ESMA) ежегодно определяют перечень критических ICT third-party providers (CTPP) — как правило, крупных облачных гипермасштабировщиков (AWS, Azure, GCP), имеющих большую долю финансового рынка. Они подлежат прямому надзору европейских органов, включая выездные инспекции и санкции.

Для МСБ SaaS ERP-поставщиков маловероятно попадание в CTPP — однако они регулируются через своих клиентов.

Пять столпов DORA

Столп 1: Фреймворк управления ICT-рисками

Комплексный фреймворк, включающий:

  • Управление (governance) — ответственность на уровне совета директоров, определённые роли.
  • Идентификация — реестр ICT-активов, картирование зависимостей.
  • Защита и предотвращение — политики, технические меры, сегментация.
  • Обнаружение — мониторинг, SIEM, обнаружение аномалий.
  • Реакция и восстановление — реагирование на инциденты, BCP, DRP.
  • Обучение и развитие — анализ после инцидентов, threat intelligence.

Для малых финансовых субъектов существует упрощённый фреймворк, но он всё равно требует формализованной документации.

Столп 2: Управление ICT-инцидентами

Стандартизированный процесс:

СрокДействие
4 часа с момента классификацииПервичное уведомление компетентного органа
72 часаПромежуточный отчёт
1 месяцФинальный отчёт

Классификация инцидента как major осуществляется по критериям: количество затронутых клиентов, финансовый ущерб, прерывание критических услуг, географический масштаб. RTS точно определяют пороги.

Столп 3: Тестирование цифровой операционной устойчивости

Два типа тестов:

  1. Стандартные тесты (ежегодно) — оценки уязвимостей, проверки исходного кода, penetration testing, сценарное тестирование.
  2. TLPT (Threat-Led Penetration Testing) — только для крупных субъектов, раз в 3 года. Реалистичная red-team атака по методологии TIBER-EU.

ICT-поставщики, используемые регулируемыми субъектами, обязаны предоставлять тестовые среды и содействовать при тестировании.

Столп 4: Управление рисками ICT третьих сторон

Самый сложный и амбициозный столп. Требует:

  • Register of information — полный перечень всех ICT-соглашений.
  • Pre-contractual assessment — due diligence перед заключением договора.
  • Договорные требования — явные DORA-клаузулы в договорах.
  • Exit strategies — определённый план для прекращения сотрудничества с ICT-поставщиком.
  • Мониторинг концентрационного риска — отслеживание зависимости от одного поставщика.

Договор с ICT-поставщиком согласно ст. 30 должен содержать как минимум:

  • Описание услуг и SLA
  • Местонахождение обработки данных (для критических функций — ЕС)
  • Стандарты безопасности
  • Право аудита поставщика
  • Правила субаутсорсинга
  • Отчётность об инцидентах клиенту
  • Условия прекращения и поддержка при выходе
  • Сотрудничество с регуляторами
  • Положения на случай несостоятельности

Столп 5: Обмен информацией

Добровольный, но поддерживаемый — финансовые субъекты могут обмениваться threat intelligence в рамках ISAC/ISAO сообществ.

Практический чеклист для SaaS ERP-поставщика, ориентированного на финансовый сектор

А) Архитектура и инфраструктура

  • Исключительно EU-хостинг (никаких данных вне ЕС для критических функций)
  • Multi-region deployment с автоматическим failover
  • RTO < 4 часа, RPO < 1 час (для критических финансовых услуг)
  • Air-gapped бэкапы (immutable, ransomware-resistant)
  • Сетевая сегментация (production vs. staging vs. management)
  • Шифрование at rest и in transit (AES-256, TLS 1.3)
  • Hardware Security Modules (HSM) для управления ключами
  • Privileged Access Management (PAM) для административных учётных записей

Б) Безопасность приложения

  • MFA обязательно для всех пользователей
  • Поддержка SSO (SAML 2.0, OIDC)
  • Role-based access control с детализированными правами
  • Session management (timeout, повторная аутентификация для чувствительных операций)
  • Input validation и output encoding (OWASP Top 10)
  • API security (rate limiting, OAuth 2.0, ротация API-ключей)
  • Vulnerability scanning в CI/CD pipeline
  • Проверка исходного кода регулярно

В) Мониторинг и реагирование на инциденты

  • Интеграция SIEM (возможность экспорта логов клиенту)
  • Аудит-лог для всех изменений (immutable, ретенция мин. 12 мес.)
  • Real-time обнаружение аномалий
  • Команда реагирования на инциденты 24/7 (или SLA с внешней службой)
  • Уведомление клиента об инциденте в течение 4 часов
  • Форензическая способность при post-incident анализе

Г) Документация и сертификации

  • Сертификация ISO 27001 (минимум)
  • SOC 2 Type II (в идеале для международного контекста)
  • Отчёт penetration test (ежегодно, внешний)
  • DPA согласно GDPR ст. 28
  • DORA-compliant шаблоны договоров с клаузулами из ст. 30
  • Sub-processor list с процессом предварительного согласования
  • Документация BCP и DRP (предоставляется клиенту)
  • Регулярный DR-тест (мин. 2× в год, задокументированный)

Д) Взаимодействие с клиентом и регулятором

  • Клиент имеет право аудита (закреплено в договоре)
  • Содействие при TLPT — тестовые среды, взаимодействие red-team
  • Exit support — экспорт данных, передача знаний (определённые SLA)
  • Сотрудничество с регуляторами — готовность к прямым запросам EBA/ESMA
  • Положения на случай несостоятельности — непрерывность услуги при банкротстве поставщика

Modulario и DORA

Modulario не предназначен прежде всего для регулируемых финансовых субъектов (банков, страховщиков) — акцент на МСБ в нефинансовых секторах. Однако в сегменте fintech, платёжных услуг и инвестиционного консультирования мы осуществляем развёртывания, которые должны быть DORA-compatible.

Наши DORA-релевантные возможности:

  • Исключительно EU-хостинг (Frankfurt + другие EU-регионы, multi-region)
  • Сертификация ISO 27001
  • Аудит-лог в каждом модуле
  • Стандартизированный DPA + публичный sub-processor list
  • Поддержка MFA/SSO (TOTP, WebAuthn, SAML, OIDC)
  • API security с OAuth 2.0 и rate limiting
  • BCP/DRP с RTO < 8h и RPO < 1h (для стандартных развёртываний; для DORA-критических по запросу)
  • Exit support — полный экспорт данных в стандартных форматах

Для регулируемых субъектов предоставляем DORA-compliant шаблоны договоров и специфические SLA. Подробно на странице Безопасность и в pillar о безопасности cloud ERP.

Санкции и личная ответственность

DORA не устанавливает фиксированный максимум единой суммой, но даёт регуляторам право налагать:

  • Периодические штрафные платежи — до 1 % дневного мирового оборота на время нарушения (макс. 6 месяцев).
  • Административные санкции по национальному законодательству.
  • Public reprimands — публичное обозначение.
  • Отзыв лицензии при критических нарушениях.

Для критических ICT third-party providers (CTPP) ESA может налагать periodic penalty payment до 1 % дневного оборота напрямую.

Личная ответственность: высшее руководство финансового субъекта несёт конечную ответственность за соответствие DORA.

Взаимосвязь DORA, NIS2 и GDPR

АспектDORANIS2GDPR
ТипРегламентДирективаРегламент
СекторФинансовый18 секторовВсе
Lex specialisДа (для финансового)НетНет
Прямое действиеДаНет (транспозиция)Да
ICT third-partyПрямой надзорЧерез supply chainЧерез DPA
Сроки отчётности4ч / 72ч / 1 мес.24ч / 72ч / 1 мес.72ч
Максимальные санкции1 % дневного оборота10 млн EUR / 2 %20 млн EUR / 4 %

Банк в ЕС подпадает под все три одновременно. DORA для него первична для IT-операций, NIS2 для более широкого кибер-фреймворка, GDPR для персональных данных клиентов.

Часто задаваемые вопросы

Мы небольшая fintech-компания с 8 сотрудниками, оказываем платёжные услуги. Касается ли нас DORA? Да. DORA не устанавливает пороги по размеру так строго, как NIS2. Платёжное учреждение явно перечислено в ст. 2. Для малых субъектов существует упрощённый фреймворк (пропорциональность), но базовые требования применяются. Планируйте не менее 2–4 месяцев на compliance.

Наш поставщик ERP не соответствует DORA. Можем ли мы его использовать? Для некритических функций — да, для критических — нет. DORA требует классификации ICT-функций по критичности и использования только DORA-совместимых поставщиков для критических. Если ваш ERP содержит core banking данные или realtime payment processing, он должен быть DORA-ready.

В чём разница между DORA и TIBER-EU? TIBER-EU — фреймворк для threat-led penetration testing от ЕЦБ, используемый до DORA добровольно. DORA TLPT (ст. 26) принял его как референсную методологию и сделал обязательным для крупных финансовых субъектов.

Как часто нужно обновлять реестр ICT-договоров? Register of information (RoI) необходимо обновлять непрерывно (при каждом изменении договора) и отчитываться национальному регулятору в стандартизированном формате минимум ежегодно. RTS определяет точный формат (XBRL).