Наличие регламента реагирования ещё не означает, что компания готова к инциденту.

Более того, иногда подробный и согласованный IR-план создаёт опасное чувство завершённости: документ утверждён, роли назначены, значит, вопрос закрыт.

До первого серьёзного инцидента.

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

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

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

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

Причём сценарий не должен быть удобным.

Пусть ключевой руководитель окажется недоступен. Резервная копия — под сомнением. Подрядчик — вне SLA. Информация об инциденте — уже в публичном поле. А технически правильная изоляция системы — создаёт серьёзные бизнес-потери.

Именно в таких условиях становятся видны реальные разрывы: неясные полномочия; несовместимые приоритеты; неизвестные зависимости; неработающие каналы коммуникации; нереалистичные RTO; отсутствие владельца остаточного риска.

Новая зона риска — использование AI.

Компании уже подключают GenAI к корпоративным данным и дают AI-агентам доступ к системам, но часто не знают, как расследовать выполненные ими действия. Что делать, если агент выполнил опасную операцию? Как быстро отозвать его полномочия? Где находится полная история prompts, tool calls и изменений? Как определить, какие решения были приняты на основании скомпрометированной базы знаний? Если ответы не определены и не проверены, AI-система не включена в Incident Response — даже если её внедрение официально одобрено.

Моя позиция: IR-план — это только гипотеза о поведении организации. Доказательством готовности может быть лишь практика: учения, технические проверки, реальные полномочия и устранение выявленных разрывов. Если после учения не меняются процессы, архитектура, договоры и ответственность, оно было проведено ради отчёта. Как вы оцениваете готовность к инцидентам: по наличию документов или по способности компании принять тяжёлое решение за первые 30–60 минут?