Представим ситуацию: критичная цифровая услуга недоступна, клиенты не могут проводить операции, зависимые системы начинают отказывать.

Но признаков атаки пока нет.

Кто должен управлять ситуацией — IT, ИБ или business continuity?

На мой взгляд, сама постановка вопроса указывает на проблему.

Во многих компаниях процесс выбирают исходя из причины инцидента: — атака — работает ИБ; — технологический отказ — работает IT; — серьёзное влияние на бизнес — подключается business continuity.

Но в первые минуты причина обычно неизвестна.

Пока SOC исключает компрометацию, IT проверяет изменения, а разработка анализирует логи, бизнес уже несёт потери.

Июльский сбой CrowdStrike 2024 года хорошо показал слабость классификации по источнику. Некорректное обновление конфигурации привело к отказам миллионов Windows-устройств и нарушило работу критичных организаций. Атаки не было, но масштаб воздействия оказался глобальным. (crowdstrike.com)

Именно поэтому я бы разделял два понятия:

Причина инцидента определяет техническую тактику.

Влияние инцидента определяет уровень управления.

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

Это не попытка назвать любую аварию киберинцидентом.

Это признание того, что цифровая устойчивость охватывает не только злонамеренные события. DORA, например, строит operational resilience вокруг способности продолжать предоставление услуг во время ICT-disruption и классифицирует инциденты по их воздействию: продолжительности, масштабу, количеству затронутых клиентов и состоянию данных. (EUR-Lex)

Зрелая модель, на мой взгляд, должна включать:

Единую классификацию крупных цифровых инцидентов по service impact.

Общего crisis commander для ИБ, IT и business continuity.

Параллельные потоки восстановления и forensics.

Общие правила executive-коммуникации.

Единый post-incident review.

Учения не только по атакам, но и по ошибочным обновлениям, отказам облаков и каскадным сбоям поставщиков.

World Economic Forum в отчёте 2026 года отмечает, что и локальная ошибка, и целевая атака способны вызвать глобальные каскадные последствия в современной взаимосвязанной цифровой экосистеме. (World Economic Forum)

Моя позиция проста:

Cyber resilience не должна начинаться с доказательства атаки. Когда критичная цифровая услуга недоступна, организация уже находится в кризисе. Сначала нужно ограничить воздействие и восстановить управляемость. Причину можно и нужно устанавливать параллельно. Как это устроено в вашей компании: кризисный штаб подключается по масштабу последствий или только после подтверждения кибератаки?