DORA: уроки первого года

Автор: Jonas Osman Abdelghafour.

Полный цикл отчётности об инцидентах в рамках Digital Operational Resilience Act (DORA) выявил чёткую закономерность: связывающим ограничением редко оказывается технология обнаружения. Им становится способность правильно классифицировать инцидент, собрать точные данные о его воздействии и подать отчёт в жёсткие сроки, пока инцидент ещё находится в управлении. Фирмы, испытывавшие трудности, сталкивались с ними по организационным, а не техническим причинам.

Классификация — самая сложная часть

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

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

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

Сроки требуют заранее выстроенного процесса

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

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

Реестр третьих сторон окупает свою стоимость

Реестр информации об ИКТ-договорённостях с третьими сторонами широко воспринимался как обременительный сбор данных. Он становится активом в тот момент, когда в инцидент вовлечён поставщик, потому что сразу отвечает, какие контракты, какие услуги, какая критичность и какие условия выхода применимы. Повторяющиеся проблемы качества данных были предсказуемы: несогласованные идентификаторы контрагентов, цепочки субподряда, зафиксированные только до первого уровня, и оценки критичности, унаследованные, а не проведённые заново.

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

Тестирование, приносящее по-настоящему ценные выводы

Тестирование устойчивости по DORA полезно только тогда, когда сценарии серьёзны и правдоподобны: утрата критичного поставщика, повреждение — а не просто недоступность — данных, а также компрометация самого инструментария, используемого для реагирования. Тестирование на основе анализа угроз (threat-led penetration testing) для фирм, попадающих под его требования, должно быть нацелено на бизнес-услуги, а не только на инфраструктуру. Выводы должны отслеживаться до закрытия с той же дисциплиной, что и результаты валидации, а допущения о времени восстановления, используемые в планировании устойчивости, должны проверяться, а не декларироваться.

Приоритеты на второй год

• Поддерживать карту зависимостей «услуги — активы» как живой элемент контроля с назначенным владельцем.
• Автоматизировать извлечение данных для классификации из систем мониторинга и CRM.
• Делегировать полномочия по подаче отчётов и отрабатывать путь отчётности вне рабочего времени.
• Очистить реестр третьих сторон и проанализировать концентрацию по всему реестру, включая субподрядчиков.
• Тестировать сценарии повреждения данных и утраты поставщика, проверять заявленные сроки восстановления.
• Отчитываться перед советом директоров о состоянии устойчивости в терминах бизнес-услуг, а не количества систем.

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

Основные источники: Регламент (ЕС) 2022/2554 (DORA) и связанные с ним RTS/ITS по классификации инцидентов, отчётности и реестру информации; отчёт EBA об оценке рисков, июнь 2026 г.