После крупного киберинцидента внимание закономерно направлено на CISO, IT, SOC и команду, в которой произошла ошибка.

Кто не установил обновление? Почему не сработал контроль? Кто открыл доступ? Почему инцидент не обнаружили раньше?

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

Я считаю, что полноценный board-level review должен включать ещё один объект анализа — решения самого руководства.

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

Какие инвестиции откладывались?

Какие архитектурные зависимости принимались?

Какие security exceptions продлевались без пересмотра?

Почему ранние сигналы не изменили дорожную карту?

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

Технический root cause может показать, что атакующий использовал устаревший компонент. Governance review должен объяснить, почему компонент оставался в критичном контуре, почему модернизация проигрывала другим инициативам и кто фактически владел остаточным риском.

Здесь легко уйти в две крайности.

Первая — найти виноватого, уволить несколько сотрудников и объявить проблему решённой.

Вторая — назвать всё системной ошибкой и тем самым освободить конкретных руководителей от ответственности.

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

Corrective action plan также нельзя превращать в конкурс количества задач.

После инцидента нужны три типа изменений: - немедленные меры стабилизации; - среднесрочная архитектурная remediation; - изменение operating model.

Последний уровень самый сложный. Он требует пересмотреть порядок принятия риска, инвестиционные критерии, decision rights и участие ИБ в продуктовых и архитектурных решениях.

Каждое существенное действие должно иметь не только исполнителя, но и executive owner. Кроме того, нужны ресурс, срок, evidence и независимая проверка.

Покупка нового средства защиты не подтверждает снижение риска.

Утверждённая политика не подтверждает изменение практики. Закрытое замечание не подтверждает устойчивость критичного сервиса.

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

Для меня главный результат post-incident review — не список lessons learned.

Это изменение профиля риска, ответственности и приоритетов компании.

Если совет после инцидента рассматривает только ошибки операционных команд, но не качество собственных решений, review остаётся неполным.

Должен ли совет директоров включать свои прежние решения в предмет post-incident review — или это создаст лишнюю политизацию расследования?