Требования соответствия DORA для инженерных команд

Соответствие DORA — это перечень для реализации. Регламент (ЕС) 2022/2554 определяет обязанности, но пороговые значения, временные лимиты и шаблоны, которые внедряет инженерная команда, содержатся в технических стандартах, находящихся под ним. Представьте регламент как строительные нормы, а стандарты — как чертежи: команда, которая читает только нормы, строит то, что не проходит проверку.

Регламент (ЕС) 2022/2554 (DORA) применяется с 17 января 2025 года (статья 64). Он требует от инженерных команд финансовых организаций ЕС предоставления доказательств контроля ИКТ-рисков: актуальной инвентаризации активов и зависимостей, контроля пайплайнов, отчетности об инцидентах в фиксированные сроки, проверенной устойчивости и записей о третьих лицах.

Регламент устанавливает обязанности, а регуляторные технические стандарты (RTS) задают детали реализации. Согласно Delegated Regulation (EU) 2025/301, статье 5(1)(a), первове уведомление должно быть отправлено в течение четырех часов после классификации инцидента как крупного и не позднее 24 часов с момента обнаружения.

Ряд обязанностей, включая дополнительные условия договоров в статье 30(3) и объем TLPT, зависит от того, какие функции являются основными или важными.

Подпадает ли ваша организация под действие статьи 2 и какие национальные сроки применяются — это юридический вопрос для юрисконсульта и вашего компетентного органа. Под «DORA» здесь понимается данный регламент ЕС, а не метрики поставки DevOps.

Хронология DORA: регламент и его технические стандарты

Обязательства DORA применяются с 17 января 2025 года, спустя два года после вступления регламента в силу 16 января 2023 года. Обе даты установлены в Article 64. Технические стандарты вступали в силу в разное время в течение этого периода и после него.

В таблице указано, когда вступил в силу каждый стандарт, с которым работает инженерная команда:

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

Кто должен соблюдать DORA? Область применения и соразмерность

DORA распространяется на финансовые организации и сторонних поставщиков ИКТ-услуг, перечисленных в . Пункты (a) — (t) статьи 2(1) охватывают кредитные организации, платежные учреждения и учреждения электронных денег, инвестиционные фирмы, страховщиков, поставщиков услуг в сфере криптоактивов, торговые площадки и другие.

Статья 2(3) исключает некоторые организации, такие как страховые и перестраховочные посредники, являющиеся микро-, малыми или средними предприятиями, а статья 2(4) позволяет государствам-членам исключать определенные категории кредитных организаций. Относится ли ваша организация к сфере применения — это юридический вопрос для юрисконсульта и вашего компетентного органа.

Программные партнеры охватываются двумя способами. Статья 2(1)(u) перечисляет сторонних поставщиков ИКТ-услуг, а статья 31 устанавливает режим надзора за теми, кого назначают ESA. Большинство партнеров выполняют требования DORA через условия договоров из статьи 30, которые финансовая организация должна включить в свое соглашение с вами.

Статья 4 соразмерно адаптирует обязанности Уровня 1 к размеру, профилю риска и сложности организации. Организации, подпадающие под действие статьи 16, такие как небольшие и невзаимосвязанные инвестиционные фирмы, находятся вне статей с 5 по 15 и следуют упрощенной структуре управления ИКТ-рисками (статья 16(1) ).

Уровень 2 определяет эту структуру в Delegated Regulation (EU) 2024/1774, а руководства Уровня 3 исходят от ESAs (EBA, EIOPA и ESMA).

Наша рекомендация состоит в том, чтобы воспринимать соразмерность как разрешение сократить объем бумажной работы. Она не отменяет работающие системы:

Какие пять групп артефактов создает DORA?

DORA создает пять групп инженерных артефактов. Это инвентаризация ИКТ-активов и зависимостей, средства контроля пайплайнов и логирования, пайплайн инцидентов, программа тестирования, а также данные и договоры сторонних организаций. Регламент, (Уровень 1), устанавливает обязанность. Делегированные регламенты и регламенты по исполнению (Уровень 2) содержат детали, на основе которых вы производите разработку.

Сопоставление глав регламента с тем, что поставляет инженерная команда:

Управление рисками упоминается дважды, потому что инвентаризация и средства контроля пайплайна создаются разными командами. Обмен информацией (статья 45) не создает собственной постоянной группы артефактов.

Колонка Уровня 2 — это то место, где принимаются решения по реализации. Руководство Уровня 3 выглядит скудным по сравнению с ней. Какие именно технические стандарты являются обязательными для конкретной организации и в какой форме — это вопрос к юрисконсульту и компетентному органу.

Что должно содержаться в инвентаризации ИКТ?

ИКТ-инвентаризация должна содержать поля из статьи 4(2)(b) для каждого актива, а также его связи с поддерживаемыми им бизнес-функциями. Эти поля заданы .

Эта статья Уровня 2 требует учета связей и взаимозависимостей между ИКТ-активами и бизнес-функциями, использующими каждый из них. Она также требует наличия полей для каждого актива, указанных в таблице ниже. Статья 8(1) предоставляет классификацию, на которую ссылается учетная запись.

Каждое поле уже существует где-то в вашем стеке поставки:

Чтобы инвентаризация не устаревала, генерируйте ее как результат работы пайплайна. Читайте состояние Terraform и API облачных аккаунтов (AWS Config, Azure Resource Graph, GCP Cloud Asset Inventory), а затем объединяйте метаданные развертывания. Прекращайте деплой при отсутствии обязательного тега и запускайте запланированное задание, которое сопоставляет инвентаризацию со списками учетных записей и помечает неуправляемые ресурсы.

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

Применимы два предостережения. Облачные API не видят SaaS-продукты, локальные хосты или мейнфреймы, поэтому для них требуется фид CMDB или проверенная запись вручную.

Организации, не являющиеся микропредприятиями, также должны хранить информацию, необходимую для конкретной оценки ИКТ-рисков устаревших систем (статья 4(2)(c) со ссылкой на статью 8(7)).

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

Какие средства контроля относятся к пайплайну поставки?

К пайплайну поставки относятся три средства контроля: управление изменениями, логирование и тестирование восстановления. Обязанности изложены в статьях 9, 10 и 12 . , регуляторные технические стандарты (RTS) по инструментам управления ИКТ-рисками, предоставляют детали Уровня 2.

Таблица переводит каждый элемент контроля в задачу для реализации, место в пайплайне и оставляемые им свидетельства:

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

Логи SaaS и облака — это первое место, где это ломается. Управляемые сервисы различаются тем, что они выгружают, как долго они это хранят и находятся ли журналы аудита за более высоким уровнем лицензирования или за запросом API. Сравните выгрузку и сроки хранения каждого сервиса со сроком хранения, установленным для поддерживаемой им функции. Зафиксируйте пробелы в инвентаризации и поднимите их в условиях договора.

Восстановление разбивает следующее. Зеленая задача резервного копирования доказывает, что копия существует. Тест восстановления доказывает, что копия возвращается. Если никто не запускает его по расписанию, файл доказательств по Статье 12 не содержит датированных измерений по отношению к вашим RTO и RPO.

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

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

Сроки и классификация инцидентов крупного масштаба по DORA

Классификация инцидентов крупного масштаба подчиняется Делегированному регламенту (ЕС) 2024/1772, а отсчет времени для отчетности регулируется Делегированным регламентом (ЕС) 2025/301. Одна запись об инциденте должна обеспечивать оба процесса.

устанавливает обязанности в Статьях с 17 по 19. Пороговые значения и таймеры относятся к Уровню 2. Технические стандарты регулирования (RTS) классификации — это Delegated Regulation (EU) 2024/1772, а содержание и временные ограничения содержатся в . Шаблон — это Implementing Regulation (EU) 2025/302.

Практический пример. Предположим, платежной службой пользуются 400 000 клиентов. Во время сбоя 43 000 клиентов не могут завершить платеж. Эти цифры являются предположениями для наглядности, а не наблюдаемыми данными.

Статья 1(1) Делегированного регламента (ЕС) 2024/1772 учитывает клиентов, которые не смогли воспользоваться услугой или понесли ущерб, а также третьих лиц — бенефициаров, указанных в договоре. Статья 9(1)(a) считается выполненной, когда это число превышает 10% всех клиентов, использующих затронутую услугу.

43 000 / 400 000 = 10,75%, поэтому критерий выполнен. При 38 000 затронутых клиентов доля составляет 9,5%, и этот критерий не выполняется, хотя остальные критерии все еще оцениваются. Статья 8 того же акта определяет, как критерии объединяются для вынесения общего решения о крупном инциденте. Если точное количество неизвестно, Статья 1(5) требует оценки на основе сопоставимых контрольных периодов.

Теперь перейдем к таймеру, используя Статью 5 Делегированного регламента (ЕС) 2025/301:

Статья 5(1)(a) требует первичного уведомления как можно раньше, в течение четырех часов с момента классификации инцидента как крупного и не позднее 24 часов с момента обнаружения.

Если организация классифицирует инцидент как крупный только по истечении 24 часов, Статья 5(2) по-прежнему требует первичного уведомления в течение четырех часов с момента классификации. При классификации во вторник в 20:00 оно должно быть отправлено в среду в 00:00. Промежуточный отчет должен быть представлен в течение 72 часов с момента первичного уведомления, а окончательный отчет — не позднее чем через месяц после последнего промежуточного отчета (Статья 5(1)(b) и (c)).

Выходные и праздничные дни имеют свои правила. Согласно Статье 5(4), срок, приходящийся на такой день, может быть перенесен на полдень следующего рабочего дня, но Статья 5(5) отменяет эту возможность для первичного уведомления и промежуточного отчета кредитных организаций, центральных контрагентов, операторов торговых площадок и организаций, которые являются существенными или важными в соответствии с NIS2. Для ваших таймеров требуется тип организации и календарь праздников, а не только часы.

Из этого вытекают три инженерных следствия:

• Сохраняйте время обнаружения и время классификации в виде отдельных полей и запускайте от них два таймера.
• Автоматически вычисляйте долю затронутых клиентов на основе количества клиентов сервиса, чтобы классификация не ждала ручного подсчета.
• Сопоставьте поля записей с шаблоном Приложения I Имплементационного регламента (ЕС) 2025/302 и отправьте их через защищенный канал, предоставляемый вашим компетентным органом (Статья 4(1)).

Статья 5(3) Делегированного регламента (ЕС) 2025/301 требует, чтобы о пропущенном сроке сообщалось в компетентный орган с указанием причин до истечения самого срока. Какой орган и какой канал применяются — это вопрос к юрисконсульту и вашему надзорному органу.

Требования DORA к тестированию на проникновение на основе анализа угроз (TLPT)

Программа тестирования устойчивости DORA представляет собой набор тестов по Статье 25, выполняемых по графику, плюс тестирование на проникновение на основе анализа угроз (TLPT) для отдельных организаций. Обязанности изложены в Статьях 24–27 . Статья 24(6) требует проведения тестирования по меньшей мере раз в год для ИКТ-систем, поддерживающих критически важные или важные функции.

Статья 25(1) перечисляет базовые тесты, но не указывает, где они выполняются. Наше предлагаемое сопоставление с инженерным конвейером:

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

Когда применяется TLPT

TLPT применяется только в том случае, если это требуется вашим органом по TLPT. Статья 26(1) устанавливает трехлетний цикл для таких организаций.

Статья 2 Delegated Regulation (EU) 2025/1190 устанавливает логику отбора. Орган взвешивает влияние, системный характер и профиль ИКТ-рисков, а также по умолчанию назначает некоторые типы организаций, включая центральные депозитарии ценных бумаг и центральные контрагенты. Орган банковской группы может по-прежнему добавлять организации или освобождать их от требований, поэтому уточните свой статус у юрисконсульта и компетентного органа.

Базовый тест на проникновение — это не TLPT. TLPT следует реальным данным об угрозах, выполняется на работающих производственных системах, поддерживающих критически важные или важные функции, и входит в структуру TIBER-EU ЕЦБ. Если в сферу охвата входят системы стороннего поставщика ИКТ-услуг, условия договора по Статье 30 должны обязывать его принимать участие.

Запуск TLPT на рабочей среде

Рабочая среда — главная угроза: красная команда (red team), которая повреждает данные или вызывает сбой, бьет по реальным клиентам. Статья 26 требует средств контроля рисков для предотвращения такого воздействия. Мы рекомендуем согласовывать их с командой контроля до начала активной фазы:

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

Тестеры предоставляют отчет о тестировании красной команды в течение 4 недель после завершения активного тестирования (Статья 12(2) Делегированного регламента (ЕС) 2025/1190). После того как орган по TLPT подтверждает завершение отчетов красной и синей команд, Статья 12(7) дает организации 8 недель на предоставление резюме выводов, а Статья 13(1) дает еще 8 недель с момента этого уведомления для планов устранения последствий.

Что требуют данные и договоры третьих лиц?

Данные третьих лиц означают реестр информации о каждом договоре об ИКТ-услугах и условия договора по Статье 30 в каждом контракте. Условия содержатся в , причем их больше, если услуга поддерживает критически важную или важную функцию.

Требования к реестру информации DORA

Статья 28(3) требует ведения реестра на уровне организации, а также субконсолидированных и консолидированных реестров для групп. Шаблоны устанавливаются Implementing Regulation (EU) 2024/2956. В них финансовая организация и ее провайдеры идентифицируются по кодам LEI (код юридического лица), поэтому вашим основным данным о поставщиках необходимы эти поля. Сроки подачи устанавливаются вашим компетентным органом.

Реестр подпитывает две другие обязанности. Статья 29 запрашивает предварительную оценку риска концентрации ИКТ, и входными данными для нее служит запрос, показывающий множество функций у одного провайдера. Статья 28(8) требует стратегий выхода для услуг, поддерживающих критически важные или важные функции.

Записи устаревают тремя способами: в контракт вносятся поправки, меняется субподрядчик или рабочая нагрузка перемещается в другой регион. Инженерный отдел обычно является единственной командой, которая знает провайдера, субподрядчика и регион для каждой функции. Юридический отдел знает условия контракта, и ни одна из сторон не видит изменений другой.

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

Условия контракта, которые должен поддерживать программный партнер

Программный партнер, предоставляющий ИКТ-услуги финансовой организации, является сторонним поставщиком ИКТ-услуг в соответствии с DORA. Условия Статьи 30 описывают то, что он должен обеспечивать в повседневной работе.

Статья 30(2) применяется к каждому контракту на оказание ИКТ-услуг. Она требует, среди прочего:

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

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

Эти условия действуют только в том случае, если схема предоставления услуг может служить доказательством для каждого из них. Netguru создает программное обеспечение для банков, платежных компаний и финтехов и имеет сертификат ISO 27001; таблица ниже отражает то, что мы ожидаем увидеть от любого партнера, включая нас самих:

Список субподрядчиков имеет значение не только для контракта, поскольку он поступает в реестр информации организации. Для услуг, поддерживающих критически важные или важные функции, Delegated Regulation (EU) 2025/532 определяет, что организация должна оценить перед тем, как разрешить привлечение субподрядчиков.

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

Требуется ли инженерная работа для обмена информацией (Статья 45)?

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

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

Эти данные в основном уже собираются. Пункт (l) Статьи 3 перечисляет индикаторы компрометации в качестве содержимого промежуточного отчета. Пометьте эти поля как доступные для совместного использования в записи об инциденте и не включайте поля клиентов и транзакций в экспорт. Сведения о том, как DORA соотносятся с NYDFS, PCI DSS и другими режимами, см. в нашем руководстве по перекрестному регулированию кибербезопасности для финансовых услуг.

Инженерный контрольный список DORA: артефакт, стандарт, владелец, свидетельство

Инженерный контрольный список DORA сопоставляет каждую Статью и технический стандарт с создаваемым ими артефактом, владеющей им командой и доказательствами, которые может запросить проверяющий орган. Таблица ниже является нашей рабочей версией. Столбец «Владелец» — это наше предложение; столбцы со Статьей и стандартом соответствуют и его актам Уровня 2.

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

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

Часто задаваемые вопросы о соблюдении требований DORA

Каковы 5 столпов регулирования DORA?

Пятью столпами DORA являются управление ИКТ-рисками, управление инцидентами и отчетность по ним, тестирование на устойчивость, риски от третьих лиц в сфере ИКТ и обмен информацией. Они соответствуют Главам II–VI . Термин «столпы» является сокращением, а не текстом закона, и большая часть деталей реализации содержится в технических стандартах Уровня 2.

Что значит соответствовать требованиям DORA?

Соответствовать требованиям DORA означает выполнять обязательства Регламента (ЕС) 2022/2554 и его технических стандартов, а также располагать доказательствами, которые ваш компетентный орган может проверить. Эти доказательства включают инвентаризационный список ИКТ-активов, журналы и записи об инцидентах. Программное обеспечение помогает только в том случае, если оно создает эти артефакты. Мы не ранжируем здесь поставщиков, поскольку правильный выбор зависит от типа вашей организации и существующего стека. Вместо этого проверьте любой инструмент по четырем критериям: - Таймер инцидента: он отдельно фиксирует момент обнаружения и момент классификации. , Статья 5(1), устанавливает сроки относительно обоих моментов, а Статья 5(2) касается поздней классификации. - Формат отчета: он экспортирует первоначальные, промежуточные и окончательные отчеты в шаблоне Приложения I, требуемом Статьей 1(1) . - Пороги классификации: он позволяет настраивать критерии из Статьи 9 , такие как 10-процентный порог клиентов и порог экономического воздействия в 100 000 евро. - Проверяемый экспорт: описи, журналы и реестры контрактов покидают инструмент в форме, которую орган может прочитать без вашего поставщика. В качестве правила принятия решений отказывайтесь от любого инструмента, который не проходит первые два прогона, поскольку пропущенные дедлайны и неправильно сформированные отчеты — это сбои, которые проверяющий орган видит в первую очередь. Проведите тестовый инцидент через каждый выбранный инструмент перед покупкой. Дополнительные сведения о методах оценки см. в руководстве по выбору программного обеспечения для обеспечения соответствия требованиям для финансовых компаний.

Каковы требования нормативных актов DORA?

DORA требует четырех вещей: управления ИКТ-рисками, отчетности об инцидентах, тестирования на устойчивость и контроля третьих лиц. Подробно закон требует наличия системы управления ИКТ-рисками, за которую отвечает руководящий орган (Статья 5), отчетности о серьезных инцидентах (Статья 19), тестирования на устойчивость, включая TLPT (Статья 26), и контроля третьих лиц с условиями контрактов (Статьи 28–30). Сроки отчетности указаны в Делегированном регламенте (ЕС) 2025/301, Статья 5(1). Первоначальное уведомление должно быть отправлено в течение четырех часов с момента классификации и не позднее чем через 24 часа после обнаружения. Промежуточный отчет должен быть представлен в течение 72 часов с момента отправки первоначального уведомления, а окончательный отчет — в течение одного месяца после промежуточного отчета.

На кого распространяется регулирование DORA?

DORA распространяется на 21 категорию, перечисленную в Статье 2(1), начиная с кредитных и платежных учреждений и заканчивая страховщиками, поставщиками услуг криптоактивов и сторонними поставщиками ИКТ-услуг. Статья 2(3) исключает некоторые организации, такие как определенные управляющие фондами альтернативных инвестиций (пункт (a)), а Статья 4 соразмерно распределяет обязанности в зависимости от размера и риска. Относится ли конкретная фирма к сфере действия закона — это юридический вопрос.

Что такое регламент DORA простыми словами?

DORA — это регламент ЕС, требующий от финансовых организаций противостоять сбоям в сфере ИКТ, реагировать на них и восстанавливаться после них в рамках единого свода правил для сектора. Он не связан с метриками DevOps DORA. Для инженерных команд он превращает обеспечение отказоустойчивости в артефакты: инвентарные списки, журналы, отчеты об инцидентах, отчеты о тестировании и условия договоров.

Когда DORA вступил в силу?

DORA применяется с 17 января 2025 года в соответствии со статьей 64 Регламента (ЕС) 2022/2554. Регламент вступил в силу раньше, 16 января 2023 года, что дало финансовым организациям два года на подготовку. Каждый акт Уровня 2 имеет собственную дату вступления в силу, поэтому проверяйте тот акт, на основе которого вы строите работу.

С чего начать

Начните с двух артефактов, от которых зависят все остальные: инвентарного списка ИКТ-активов и зависимостей, а также журнала инцидентов, в котором время обнаружения и время классификации хранятся раздельно. Реестр информации, настройки журналирования и объем тестирования считываются из инвентарного списка, а отсчет времени для отчетности — из журнала инцидентов.

Если вы планируете эту работу для платформы финансовых услуг, наша команда по кибербезопасности может совместно с вами сопоставить ваши системы с приведенным выше контрольным списком. Расскажите нам, что вы создаете, и мы вместе определим объем работ.