Почему компании не готовы к инцидентам, даже если у них есть регламенты

Во многих компаниях на вопрос о готовности к киберинциденту отвечают одинаково:

— У нас есть утверждённый план реагирования.

— Ответственные назначены.

— Контакты собраны.

— Резервное копирование настроено.

— SOC знает, кого уведомлять.

На бумаге организация готова.

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

Проблема не в том, что регламент был плохо написан. Проблема в том, что его приняли за доказательство готовности.

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

Incident Response Plan описывает предполагаемый порядок действий. Но инцидент почти никогда не развивается строго по этому порядку.

В реальности одновременно возникают технические, управленческие и бизнес-вопросы:

В регламенте можно перечислить роли. Но нельзя заранее гарантировать, что их владельцы смогут договориться в условиях неполной информации.

Именно поэтому в актуальной редакции NIST SP 800-61 Revision 3 реагирование рассматривается не как изолированный процесс SOC или CERT, а как часть общей системы управления киберрисками. Подготовка, реагирование, восстановление и извлечение уроков должны быть связаны с управлением, архитектурой, активами и бизнес-процессами. (csrc.nist.gov⁠)

Это важный сдвиг: Incident Response перестаёт быть задачей только ИБ и становится проверкой управляемости всей организации.

Во многих организациях учения проходят внутри SOC или департамента ИБ. Аналитики разбирают алерты, специалисты расследуют цепочку атаки, инженеры блокируют индикаторы компрометации.

Это полезно, но недостаточно.

Кризис возникает не там, где SOC не смог определить хеш вредоносного файла. Он возникает там, где техническое решение начинает влиять на бизнес.

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

Это уже не только Incident Response. Это управление бизнес-кризисом.

Поэтому проверять нужно не отдельные команды, а всю цепочку:

обнаружение → квалификация → эскалация → управленческое решение → локализация → восстановление → коммуникации → разбор последствий.

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

Типовой IR-план часто построен вокруг категорий технической серьёзности: заражение рабочей станции, компрометация учётной записи, вредоносное ПО, DDoS, утечка данных.

Но два технически похожих события могут иметь совершенно разные последствия.

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

Поэтому зрелое реагирование должно начинаться не только с вопроса «что произошло?», но и с вопросов:

Если IR-план не связан с BIA, BCP, Disaster Recovery, архитектурой сервисов и реестром критичных активов, команда реагирования будет определять бизнес-приоритеты непосредственно во время кризиса.

Это слишком поздно.

Назначить ответственных недостаточно. Необходимо заранее определить права на решения.

Например:

В реальном инциденте задержка часто связана не с отсутствием технических данных, а с отсутствием владельца решения.

Каждый ждёт подтверждения от следующего уровня. Руководители получают разные оценки. Время локализации растёт. Следы атаки исчезают. Злоумышленник продолжает перемещаться по инфраструктуре.

Неопределённые полномочия во время инцидента становятся самостоятельной уязвимостью.

GenAI-сервисы и AI-агенты расширяют сценарии, которые необходимо включать в реагирование.

Инцидентом может стать не только взлом модели. Например:

IBM в исследовании 2025 года указывает одновременно на рост использования AI злоумышленниками и на разрыв между внедрением AI и зрелостью управления им. В выборке отчёта 16% исследованных утечек были связаны с применением AI атакующими. (IBM⁠)

Для реагирования это означает, что традиционного плана по компрометации endpoint или учётной записи уже недостаточно.

Организации нужно заранее понимать:

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

Зрелая модель Incident Response строится не вокруг документа, а вокруг регулярно проверяемой операционной способности.

Компания тренирует не абстрактный ransomware, а остановку конкретного критичного процесса, компрометацию конкретного поставщика или потерю доверия к конкретным данным.

У каждого критичного решения есть владелец, заместитель, критерии эскалации и допустимое время принятия.

Необходимы бизнес-владельцы, разработка, архитектура, юридическая функция, PR, HR, закупки, риск-менеджмент, руководство и ключевые подрядчики.

Можно ли реально отключить интеграцию? Доступен ли резервный канал связи? Работают ли аварийные учётные записи? Возможно ли восстановление в заявленный срок? Есть ли контракт с внешними экспертами?

Каждое выявленное отклонение получает владельца, срок устранения и контроль выполнения. Иначе учение превращается в корпоративный театр.

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

Я не считаю количество регламентов показателем зрелости ИБ. Зрелость проявляется в другом: насколько быстро компания способна понять масштаб события, собрать людей с необходимыми полномочиями, принять осознанный риск и восстановить критичные операции, не потеряв контроль над ситуацией.

Киберинцидент редко выявляет одну техническую проблему. Он обнажает качество архитектуры, управления, коммуникаций, контрактов, резервирования и корпоративной культуры.

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

Регламент может подсказать последовательность действий.

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

Подписывайтесь на мой ТГ канал: @ib_decisions