Отчётность об инцидентах по DORA и NIS2: звонок до того, как истечёт срок

Содержание

• Что на самом деле требуют сроки отчётности
• Почему срок отчётности на самом деле — задача разбудить человека
• Дают ли выходные дополнительное время?
• Как поставить звонящий телефон перед процессом отчётности
• Шаг 1 — Заведите канал со звонком только под инциденты, подлежащие отчётности
• Шаг 2 — Направьте стек обнаружения на этот вебхук
• Шаг 3 — Используйте условия, чтобы звонили только правдоподобные кандидаты
• Шаг 4 — Перехватите системы, которые умеют только письма
• Шаг 5 — Подпишите на тот же канал тех, кто отвечает за срок
• Шаг 6 — Проверьте это с включённым «Не беспокоить»
• Чего Echobell не делает
• Частые вопросы
• Делает ли использование Echobell нас соответствующими DORA или NIS2?
• Когда именно начинается 4-часовой отсчёт по DORA?
• Должно ли раннее предупреждение по NIS2 содержать полные детали инцидента?
• Наш мониторинг и так шлёт письма дежурному инженеру. Разве этого мало?
• Могут ли комплаенс и инженеры получить одно и то же оповещение?
• Действительно ли звонок пробьётся через «Не беспокоить»?
• Это только для iOS?
• Какие данные класть в тело вебхука?
• Читайте также

Любой срок отчётности об инцидентах в ЕС начинает отсчитываться от того, что заметила машина, и продолжает идти, пока ваша команда спит. Если оповещение, запускающее отсчёт, приходит беззвучным push-уведомлением в 02:40 в воскресенье, вы сожгли четверть своего окна отчётности по DORA ещё до того, как его прочитал хоть один человек. Это руководство показывает, как поставить настоящий звонящий телефон перед вашим процессом отчётности с помощью Echobell — чтобы отсчёт и ваша реакция начинались примерно одновременно.

Масштаб теперь измерен, а не оценён на глаз. 3 июня 2026 года три европейских надзорных органа опубликовали первый общеевропейский обзор серьёзных инцидентов, связанных с ИКТ, о которых отчитывались в рамках DORA: 3383 серьёзных инцидента за 2025 год, в среднем 0,18 на одну поднадзорную финансовую организацию, причём около трети имели трансграничные последствия (EBA, ESMA). Деталь, которая должна определять вашу схему оповещений: только 10 % были связаны с кибербезопасностью. Основными причинами стали системные сбои и внешние события.

Иначе говоря, регуляторный отсчёт запускают в подавляющем большинстве случаев скучные события: неудачный деплой, отвалившаяся зависимость, сбой у провайдера. Ровно то, что ваш мониторинг и так ловит в три часа ночи — и доставляет на телефон, где включено «Не беспокоить».

Что на самом деле требуют сроки отчётности

Три режима, три разных стартовых выстрела — и все они идут по реальным часам. Вот что говорят действующие тексты.

Сроки DORA заданы Делегированным регламентом Комиссии (ЕС) 2025/301 — регуляторным техническим стандартом о содержании и сроках отчётности об инцидентах, опубликованным 20 февраля 2025 года в дополнение к Регламенту (ЕС) 2022/2554 (Европейская комиссия, текст статьи 5). Сам DORA применяется с 17 января 2025 года (ESMA).

Сроки NIS2 указаны в статье 23(4) Директивы (ЕС) 2022/2555; государства-члены должны были перенести её в национальное право до 17 октября 2024 года (Европейская комиссия). Срок SEC следует из правил раскрытия информации о кибербезопасности, принятых 26 июля 2023 года (SEC).

Почему срок отчётности на самом деле — задача разбудить человека

Потому что ни один из этих отсчётов не привязан к вашему рабочему времени. DORA считает от классификации и от момента, когда организации стало известно об инциденте. NIS2 считает от момента, когда стало известно. SEC — от признания инцидента существенным. Считается ли конкретный момент «осведомлённостью» — юридическая оценка, которую делает ваша функция комплаенса, но ни один из этих текстов не обнуляет отсчёт из-за того, что первый человек, до которого дошло оповещение, в этот момент спал.

Посчитайте самый жёсткий путь DORA в обратную сторону. У вас есть 4 часа с момента, когда инцидент классифицирован как серьёзный, а классификация невозможна, пока на него не посмотрит человек. Обнаружение в 02:40, подтверждение только в 08:00, ещё 90 минут разбора до классификации — и первичное уведомление уходит около 11:00. Это внутри внешней границы в 24 часа, но больше восьми часов из 24-часового потолка потрачены на сон. Сократите разрыв до подтверждения — и у каждого следующего шага появится запас.

Это не довод в пользу того, чтобы оповещать о большем числе событий. Это довод в пользу того, чтобы один конкретный узкий класс оповещений — те, что реально могут стать подлежащими отчётности, — было физически невозможно проспать. Всё остальное должно молчать. (Если ваша команда уже тонет, сначала разберитесь с усталостью от оповещений, а потом добавляйте более громкий канал.)

Дают ли выходные дополнительное время?

Немного — по DORA, и, скорее всего, не вам. Делегированный регламент (ЕС) 2025/301 позволяет финансовой организации, у которой срок выпадает на выходной день или государственный праздник в её государстве-члене, подать отчёт до полудня следующего рабочего дня. Но та же статья лишает этой отсрочки кредитные организации, центральных контрагентов и операторов торговых площадок, а также организации, которые по NIS2 относятся к существенным или важным. Компетентные органы могут отозвать её и у других системно значимых организаций (статья 5, разбор Advisera).

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

Как поставить звонящий телефон перед процессом отчётности

Echobell делает одну вещь: превращает вебхук или письмо в телефонный звонок — настоящий вызов со звонком и вибрацией, который пробивается через «Фокусирование» и «Не беспокоить» в iOS так же, как звонок от члена семьи (см. как обойти «Фокусирование» в iOS для критических оповещений). Он стоит между системой, которая обнаруживает инцидент, и человеком, который должен запустить отсчёт.

Шаг 1 — Заведите канал со звонком только под инциденты, подлежащие отчётности

Создайте в Echobell канал и задайте тип уведомления Звонок. Именно это заставляет телефон звонить, а не доставлять беззвучный push (типы уведомлений). Дайте каналу имя, не оставляющее сомнений, — «Инцидент, подлежащий отчётности — подъём», — и не используйте его больше ни для чего. Скопируйте URL вебхука из деталей канала; он выглядит как https://hook.echobell.one/t/<channel-token>. Относитесь к нему как к секрету.

Шаг 2 — Направьте стек обнаружения на этот вебхук

Что бы ни заметило инцидент, оно отправляет HTTP-запрос на URL канала. У Echobell есть готовые руководства для Grafana, Prometheus Alertmanager, Uptime Kuma и UptimeRobot; всё остальное, что умеет отправлять JSON методом POST, подключается по руководству по вебхукам. Полезное тело запроса несёт достаточно, чтобы принять первое решение о классификации, не открывая ноутбук:

{
  "title": "Кандидат на отчётность: {{service}}",
  "message": "{{service}} недоступен с {{started_at}} — влияние на клиентов: {{client_impact}}",
  "externalLink": "https://status.internal.example/incident/{{id}}"
}

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

Шаг 3 — Используйте условия, чтобы звонили только правдоподобные кандидаты

Звонок, который срабатывает на каждое предупреждение, перестаёт быть звонком и становится фоновым шумом. Условия в Echobell фильтруют по значениям переменных с логикой И/ИЛИ, поэтому можно потребовать, например, severity == "critical" и client_impact == true, прежде чем канал кому-то позвонит. Всё, что ниже этой планки, направляйте в отдельный канал со срочными или обычными уведомлениями. Канал для инцидентов, подлежащих отчётности, должен звонить несколько раз в год, а не еженедельно.

Шаг 4 — Перехватите системы, которые умеют только письма

Многие ленты статуса вендоров, антифрод-инструменты и сторонние поставщики уведомляют только по email — и по DORA это важно, потому что сбои на стороне поставщика прямо попадают в периметр. У каждого канала Echobell может быть собственный адрес, поэтому правило пересылки превращает такие письма в звонки (триггеры по email, настройка звонка из письма).

Шаг 5 — Подпишите на тот же канал тех, кто отвечает за срок

Инцидент находит инженерия; за срок отвечают комплаенс, дежурный или DPO. Поделитесь каналом — и каждый подписчик выберет свою срочность: дежурный инженер получит звонок, а второй участник — срочное уведомление. Включите «Повторять неудавшийся звонок», чтобы вызов, заблокированный «Фокусированием», был повторён.

Шаг 6 — Проверьте это с включённым «Не беспокоить»

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

Чего Echobell не делает

В регулируемом процессе точность здесь важнее, чем где-либо ещё.

Echobell умеет: превращать вебхук или письмо в звонящий вызов, срочное уведомление или обычный push; пробиваться через «Фокусирование» и «Не беспокоить» в iOS для уведомлений типа «Звонок»; фильтровать с помощью условий и шаблонов; доставлять одно и то же оповещение в общий командный канал.

Echobell не умеет:

• Классифицировать инциденты. У него нет мнения о том, является ли что-то «серьёзным» по DORA, «значительным» по NIS2 или «существенным» по правилам SEC. Это оценочные решения, которые принимают ваши люди по критериям из соответствующих текстов.
• Подавать что-либо и кому-либо. Он не отправляет отчёты ни компетентному органу, ни CSIRT, ни SEC. Он доводит человека до точки, в которой тот может это сделать.
• Служить вашей системой хранения записей или GRC. Эти режимы требуют документации, реестров и доказательств, которых приложение для оповещений не создаёт. Echobell намеренно хранит содержимое и историю уведомлений только на вашем устройстве, а на сервере — лишь аккаунты, каналы и подписки (модель приватности): хорошо для минимизации данных, бесполезно как журнал аудита.
• Идти в комплекте с аттестацией соответствия. К нему не прилагается ни сертификация, ни аудиторский отчёт, ни договорной SLA. Если вы вводите его в регулируемый процесс, пропустите его через собственную процедуру управления рисками сторонних поставщиков ИКТ, как любой другой инструмент, и держите канал, который от него не зависит.
• Гарантировать доставку. Звонок зависит от push-инфраструктуры, сети и заряженного телефона. Считайте его слоем, который резко сокращает время до подтверждения, а не контролем, на который можно сослаться при аудите.

Если говорить честно: ваша регуляторная обязанность не меняется от того, какое приложение звонит вам на телефон. Звонок меняет число часов между тем, как машина что-то заметила, и тем, как человек принял решение, — а при 4-часовом отсчёте эти часы и составляют почти весь бюджет.

Частые вопросы

Делает ли использование Echobell нас соответствующими DORA или NIS2?

Нет. Соответствие зависит от вашего управления, процесса классификации, документации и фактической подачи отчётов компетентному органу или CSIRT. Echobell лишь сокращает разрыв между обнаружением и подтверждением со стороны человека. Это один из входов в процесс, а не сам процесс.

Когда именно начинается 4-часовой отсчёт по DORA?

С классификации. По Делегированному регламенту (ЕС) 2025/301 первичное уведомление должно быть подано в течение четырёх часов после классификации инцидента как серьёзного и в любом случае не позднее 24 часов с момента, когда организации стало о нём известно. Это два отдельных ограничения, и выполнить нужно оба — поэтому быстрое решение о классификации важно ровно настолько же, насколько быстрое оповещение.

Должно ли раннее предупреждение по NIS2 содержать полные детали инцидента?

Нет. Статья 23(4) Директивы (ЕС) 2022/2555 делает 24-часовое раннее предупреждение намеренно предварительным: есть ли подозрение, что инцидент вызван противоправными или злонамеренными действиями, и может ли он иметь трансграничные последствия. Более полная картина нужна в 72-часовом уведомлении, а анализ первопричин — в итоговом отчёте месяцем позже.

Наш мониторинг и так шлёт письма дежурному инженеру. Разве этого мало?

Достаточно, пока кто-то бодрствует и смотрит. Письма и обычные push-уведомления заглушаются режимами «Фокусирование», «Не беспокоить» и расписанием сна — то есть ровно в те ночи и выходные, когда отсчёт наименее снисходителен. Разрыв не в обнаружении, а в подтверждении.

Могут ли комплаенс и инженеры получить одно и то же оповещение?

Да. Поделитесь каналом — и срабатывание получит каждый подписчик, сам выбрав тип уведомления. Типичная схема: дежурный инженер подписан со «Звонком», дежурный по комплаенсу — со «Звонком» на канал инцидентов, подлежащих отчётности, и со «Срочным» на всё остальное.

Действительно ли звонок пробьётся через «Не беспокоить»?

Тип уведомления «Звонок» в Echobell рассчитан на то, чтобы дозваниваться через «Фокусирование» и «Не беспокоить» в iOS, а настройка «Повторять неудавшийся звонок» повторяет вызовы, заблокированные «Фокусированием». Проверьте это на реальном устройстве каждого дежурного, прежде чем на него полагаться: системные настройки и версии различаются.

Это только для iOS?

Нет. Echobell доступен для iOS и для Android в Google Play (см. анонс релиза для Android). Поведение оповещений в виде вызова на разных платформах различается, поэтому тестируйте на тех устройствах, которые ваши дежурные действительно носят с собой.

Какие данные класть в тело вебхука?

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

---

Читайте также

• Сбои в облаках стали нормой: как всё равно получать оповещения
• Оповещения звонком, когда ваш API недоступен
• Прекращение поддержки Opsgenie: отключение в 2027 году и альтернативы
• Как обойти «Фокусирование» в iOS для критических оповещений
• Руководство по интеграции вебхуков
• Руководство по условиям