Что меняет европейский регламент о цифровой операционной устойчивости для команд вне IT: реестр поставщиков, сроки уведомления об инцидентах и кто отвечает за комплаенс, если директора по ИБ нет.
DORA (Digital Operational Resilience Act) — регламент Евросоюза, который с 17 января 2025 года действует для банков, платёжных организаций, организаций электронных денег, инвестиционных компаний и других регулируемых финансовых организаций. Он затрагивает не только ИТ-отдел. Статья 28 требует вести реестр всех договоров с внешними поставщиками ИКТ-услуг. На практике туда попадают платформа маркетинговой автоматизации, аналитика, CRM и любое агентство с доступом к системам, а не только облачная инфраструктура. Статья 19 задаёт жёсткие сроки уведомления об инцидентах, и отсчёт идёт с момента, когда сбой заметил любой сотрудник, в том числе из маркетинга или операций. Статья 30 перечисляет пункты, которые должны быть в договорах с поставщиками. Директор по информационной безопасности (CISO) регламентом по должности не требуется. Но по статье 5 итоговая ответственность лежит на органе управления, поэтому в компании без CISO реестр и отсчёт сроков по инцидентам должен вести назначенный владелец из операций или комплаенса, иначе обязанность останется невыполненной.
DORA — это регламент (ЕС) 2022/2554, опубликованный в Официальном журнале ЕС 27 декабря 2022 года. По статье 64 он применяется с 17 января 2025 года. Регламент касается каждого подразделения финансовой организации, которое работает с ИКТ-системами, а не только службы безопасности. Статья 3(21) определяет ИКТ-услуги так широко, что в них входят облачные платформы, SaaS-сервисы и аналитика данных, а не одни серверы и сети.
ИКТ-услуга по статье 3(21) DORA — это цифровая услуга или услуга по работе с данными, которую на постоянной основе оказывают через ИКТ-систему. Сюда входят облачный хостинг, SaaS-платформы и инструменты аналитики данных. Исключены только традиционные аналоговые телефонные услуги.
По этому определению платформа маркетинговой автоматизации, CRM, аналитический или BI-сервис и большинство агентств с доступом к системам — внешние поставщики ИКТ-услуг. Они стоят в одном ряду с облачными и платёжными поставщиками, которых отдел комплаенса отметит первыми.
DORA распространяется на финансовые организации в смысле статьи 2: кредитные организации, платёжные организации, организации электронных денег, инвестиционные компании, провайдеров услуг с криптоактивами, краудфандинговые платформы и ещё около 15 регулируемых категорий. Лицензированная платёжная организация или организация электронных денег подпадает под DORA напрямую. Технологическая компания, которая просто продаёт программное обеспечение банкам, сама не финансовая организация. Но как только финансовая организация подписывает с ней договор, она становится внешним поставщиком ИКТ-услуг. А небольшое число поставщиков, признанных критически важными для сектора, могут назначить под прямой надзор по статьям 31–44.
Статья 4 вводит принцип соразмерности: требования зависят от размера организации, профиля риска и характера её деятельности. Статья 16 даёт небольшим и слабо связанным с остальной системой инвестиционным компаниям, малым платёжным организациям и организациям электронных денег и некоторым другим мелким субъектам упрощённую систему управления ИКТ-рисками. Определение микропредприятия, на которое она ссылается, охватывает компании с численностью менее 10 человек и годовым оборотом менее 2 млн евро. Обязанность вести реестр и сообщать об инцидентах это не отменяет. Упрощается только объём документации для каждой из них.
Статья 28 обязывает каждую финансовую организацию вести реестр информации по всем договорам с внешними поставщиками ИКТ-услуг: на уровне организации, субконсолидированном и консолидированном. В нём нужно отделять договоры, которые поддерживают критически важную или существенную функцию, от остальных. Платформа маркетинговой автоматизации, аналитика, CRM и агентство с доступом к системам должны стоять в этом реестре рядом с облачной инфраструктурой, потому что статья 3(21) относит к ИКТ-услугам их все.
Сам реестр требует статья 28(3). Кроме того, финансовые организации не реже раза в год сообщают своему надзорному органу о новых ИКТ-соглашениях. По годовому циклу из Имплементационного регламента Комиссии (ЕС) 2024/2956 многие организации подают полный реестр по состоянию на 31 декабря предыдущего года до 30 апреля каждого года.
Общая информация, не юридическая консультация по конкретному случаю.Реестр, который составили один раз и не трогают, перестаёт соответствовать требованию в тот день, когда маркетинг подключает новый аналитический сервис и не говорит об этом владельцу файла. Реестр должен обновляться так же быстро, как идут закупки. Для этого кому-то вне IT придётся сообщать о каждом новом договоре с поставщиком до подписания, а не после.
Статьи 17–19 регулируют управление ИКТ-инцидентами, их классификацию и уведомление о них. Статья 18 вместе с Делегированным регламентом Комиссии (ЕС) 2024/1772 задаёт 6 критериев классификации. Инцидент считается серьёзным, если он достиг порога минимум по 2 из них, при этом обязательный критерий — число затронутых клиентов и операций — должен выполняться в любом случае.
| Отчёт | Срок | Что в нём |
|---|---|---|
| Первичное уведомление | В течение 4 часов после признания инцидента серьёзным, не позднее 24 часов с момента обнаружения | Факт серьёзного инцидента и известный на тот момент масштаб |
| Промежуточный отчёт | В течение 72 часов после первичного уведомления | Обновлённая оценка последствий и ход реагирования |
| Итоговый отчёт | В течение 1 месяца после промежуточного отчёта | Анализ первопричины и итоговые последствия после устранения |
Эти сроки и точное содержание каждого отчёта установлены Делегированным регламентом Комиссии (ЕС) 2025/301, а стандартные формы — Имплементационным регламентом Комиссии (ЕС) 2025/302. Ни один из трёх сроков не ждёт, пока служба безопасности подтвердит первопричину. Допустим, руководитель операционного маркетинга заметил, что перестали работать запись на приём или сбор заявок, потому что взломали поставщика. Именно он запускает отсчёт 4 часов, работает он в IT или нет.
Статья 30 перечисляет, что должно быть в любом договоре с внешним поставщиком ИКТ-услуг. Для поставщика, который поддерживает критически важную или существенную функцию, список длиннее. В типовом договоре на маркетинговую платформу, подписанном до начала действия DORA, редко есть всё это.
| Пункт | Что требует статья 30 |
|---|---|
| Описание услуг | Полное описание функций и ИКТ-услуг, включая условия субаутсорсинга |
| Расположение данных | Где данные будут обрабатываться и храниться и по какому праву |
| Доступность и безопасность | Уровни сервиса с измеримыми целевыми показателями, обязательства по безопасности и защите данных |
| Взаимодействие при инцидентах | Обязанность поставщика уведомлять и помогать при ИКТ-инциденте |
| Права аудита | Неограниченное право доступа, инспекции и аудита для финансовой организации, её представителя и надзорного органа |
| Расторжение и выход | Права на расторжение и, для критических функций, документированная стратегия выхода с переходным периодом |
Если поставщик не принимает пункты об аудите и выходе, комплаенс-владелец не сможет согласовать его ни для одной функции, которая связана с данными клиентов или с клиентским процессом. И неважно, каким мелким этот инструмент кажется маркетологу.
Статья 5 возлагает итоговую ответственность на орган управления: совет директоров или равнозначное руководство. Оно утверждает систему управления ИКТ-рисками и контролирует её, и снять с себя эту ответственность не может, даже если повседневную работу ведёт небольшая команда или внешний консультант. DORA не требует, чтобы в штате был директор по информационной безопасности (CISO). Но кто-то с полномочиями должен отвечать за три вещи: реестр поставщиков по статье 28, классификацию инцидентов и отсчёт сроков уведомления по статьям 18 и 19, проверку пунктов договоров по статье 30.
Если в компании нет отдельной службы безопасности, реестр DORA лучше всего вести руководителю операций, у которого уже есть список поставщиков и дерево KPI. Но орган управления должен закрепить это за ним формально, а не оставить на словах.
За основу для работы с поставщиками можно взять чек-лист аудита операционного маркетинга. Его нужно дополнить полями, специфичными для DORA, которых в обычном списке поставщиков нет: критичность, расположение данных, права аудита, условия выхода.
Скорее всего, начинать с нуля не придётся. Список поставщиков, собранный для операционного маркетинга в финтехе или для финансового отдела, уже закрывает значительную часть реестра по статье 28. Не хватает только полей DORA. Быстрее всего расширить этот список, а не заводить параллельный. После этого каждый действующий договор стоит прогнать через чек-лист по статье 30 выше, до его ближайшего продления.
Это общая информация о регуляторной рамке, которая ещё формируется, а не юридическая консультация по классификации конкретной организации по DORA или её договорам. Объём требований и содержание реестра и договоров с поставщиками должен подтвердить квалифицированный юрист по финансовому праву ЕС. Такой реестр и ритм отчётности мы собираем по практике Marketing-Operational System, как часть более широкого операционного аудита. Работаем рядом с вашими специалистами по комплаенсу и юристами, а не вместо них.
Нет. Регламент действует для финансовых организаций из статьи 2: лицензированных платёжных организаций, организаций электронных денег, инвестиционных компаний и других. Технологический поставщик, который сам не финансовая организация, обычно попадает под регламент косвенно: как внешний поставщик ИКТ-услуг, указанный в реестре и договорах поднадзорной организации.
Как правило, да. Определение ИКТ-услуг в статье 3(21) достаточно широкое, чтобы включить SaaS, облачный хостинг и инструменты аналитики данных. Поэтому платформа маркетинговой автоматизации или аналитический сервис, с которыми заключён договор, обычно попадают в реестр по статье 28.
В течение 4 часов после того, как инцидент признан серьёзным, и не позднее 24 часов с момента обнаружения. Сроки установлены Делегированным регламентом Комиссии (ЕС) 2025/301. Промежуточный отчёт нужно подать в течение 72 часов, итоговый — в течение 1 месяца.
Статья 16 даёт небольшим и слабо связанным с остальной системой организациям упрощённую систему управления ИКТ-рисками, а принцип соразмерности из статьи 4 подгоняет объём документации под размер и риск. Обязанности вести реестр и сообщать об инцидентах остаются.
Эти две модели закрывают разные дыры. Как понять, какая нужна вашей компании, и чем каждая обходится во времени и в контроле.
Финансовый директор на аутсорсе — это человек. Финансовые операции — это система. Компании, которые ищут одно, часто упускают другое, а то и не имеют ни того, ни другого.
Приходящий, временный, советник или встроенная команда: под одним словом прячутся четыре разные схемы. Они отличаются полномочиями, занятостью и выходом, и каждая ломается по-своему.
