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

Политики утверждены. Замечания закрыты. Ответственные назначены. Процедуры выполняются. На дашборде почти всё зелёное.

Но значит ли это, что наиболее опасные сценарии атак действительно контролируются?

Не всегда.

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

Это принципиально разные уровни зрелости.

Например, можно внедрить MFA и выполнить требование. Но не проверить:

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

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

Можно внедрить Secure SDLC, но не проводить threat modeling до принятия архитектурных решений.

Во всех этих случаях контроль формально существует. Риск при этом может оставаться почти неизменным.

На мой взгляд, одна из причин — чрезмерная вера в чек-листы.

Чек-лист отвечает на вопрос: «Что должно быть внедрено?»

Threat modeling отвечает на более содержательный вопрос: «Как именно нас могут атаковать, что будет затронуто и почему существующая защита может не сработать?»

Нужны оба инструмента. Но они не заменяют друг друга.

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

Тогда риск якобы принадлежит бизнесу, но фактически остаётся у службы ИБ — без полномочий на управленческое решение.

Особенно быстро эта модель ломается при внедрении AI-агентов.

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

Но главные вопросы остаются без ответа:

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

Моя позиция состоит не в том, что compliance не нужен.

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

Зрелая ИБ начинается там, где:

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

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

Какая атака всё ещё способна нанести нам неприемлемый ущерб, несмотря на выполненные требования?

Как вы считаете: в большинстве компаний compliance остаётся полезной основой безопасности — или уже слишком часто подменяет реальное управление рисками?