Compliance требует одного. Реальный риск — другого

У функции информационной безопасности почти никогда нет избытка ресурсов.

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

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

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

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

Но compliance нельзя превращать в единственную модель приоритизации программы ИБ.

Представим, что перед CISO стоят две задачи.

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

Вторая — закрыть реальный attack path: например, возможность компрометации привилегированной учётной записи через плохо защищённый внешний сервис. Формального замечания по нему пока нет. Аудитор этот маршрут не проверял. В отчёте регулятора он не указан.

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

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

Так возникает системное смещение: компания финансирует то, что лучше документировано, а не обязательно то, что сильнее влияет на риск.

Ошибочно ставить вопрос так:

Что важнее — выполнить требование или обеспечить безопасность?

Правильный вопрос звучит иначе:

Как одновременно управлять риском нарушения требования и киберриском, который сохраняется в архитектуре?

Это два разных объекта управления.

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

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

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

NIST CSF 2.0 прямо связывает функцию Govern с юридическими и регуляторными обязательствами, риск-толерантностью и согласованием кибербезопасности с потребностями бизнеса. При этом сам Framework не задаёт одинаковую последовательность мер для всех организаций: он предлагает определять приоритеты с учётом бизнес-целей, ресурсов и конкретного контекста риска. (NIST)

Формально одинаковый контроль может давать разный эффект в разных компаниях.

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

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

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

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

Именно здесь появляется понятие marginal effect — дополнительного снижения риска от конкретной инвестиции.

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

В компаниях часто существует подробный план устранения несоответствий:

При этом risk treatment roadmap либо отсутствует, либо представляет собой список технических инициатив без связи с бизнес-сценариями.

В результате руководство видит прогресс compliance, но не видит динамику реального риска.

Зрелая модель предполагает два связанных портфеля.

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

Risk treatment roadmap показывает, какие сценарии могут нарушить бизнес-цели, как меняются их вероятность и влияние, какие меры выбраны и какой остаточный риск принимается.

Эти планы должны использовать общие данные о системах, владельцах, зависимостях и мерах защиты. Но совпадать они не обязаны.

В декабре 2025 года NIST выпустил IR 8286 Rev. 1, усилив связь между киберрисками, корпоративными целями и ERM. Документ отдельно подчёркивает, что руководители должны видеть реальное состояние киберриска, а специалисты, которые его оценивают и обрабатывают, — учитывать стратегические цели предприятия. Серия 8286 предлагает использовать risk registers для приоритизации мер и вынесения киберриска на уровень корпоративного портфеля. (NIST Computer Security Resource Center)

Конфликт между обязательным контролем и более значимым cyber risk нельзя оставлять на уровне отдельного GRC-специалиста, архитектора или владельца системы.

Специалист может определить применимость требования.

Архитектор — оценить технический эффект.

Risk manager — описать сценарий и последствия.

Legal — объяснить юридический риск.

Финансовая функция — оценить доступность ресурсов.

Но решение о том, какой риск компания временно принимает, должно принадлежать руководителю с соответствующими полномочиями и ответственностью за бизнес-результат.

Это особенно важно, если выбор способен повлиять на критические сервисы, клиентов, финансовую устойчивость или выполнение стратегических целей.

Регуляторные модели всё заметнее закрепляют такую ответственность именно за руководством. Например, DORA возлагает на management body финансовой организации конечную ответственность за ICT risk, определение допустимого уровня риска и утверждение необходимых инвестиций. Правила SEC требуют раскрывать роль совета директоров и менеджмента в надзоре за существенными киберрисками. Речь идёт не о том, что совет должен выбирать средства защиты, а о том, что конфликт существенных рисков нельзя скрывать внутри технической функции. (EUR-Lex)

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

На практике она нередко выбирается по принципу удобства:

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

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

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

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

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

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

Не ограничиваться формулировкой «требование выполнено». Показывать, какой актив, процесс или бизнес-сервис защищает контроль и какой сценарий он должен изменить.

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

Compliance roadmap и risk treatment roadmap должны рассматриваться совместно, но сохранять разные цели и метрики.

Для каждой меры нужно определить срок действия, ожидаемый эффект, владельца, ограничения и критерии прекращения.

Если компания не способна одновременно выполнить требование и закрыть более опасный сценарий, это уже не операционная проблема ИБ. Это решение о принятии риска.

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

Compliance — обязательное ограничение программы безопасности, но не полная модель её приоритизации.

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

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

Поэтому зрелая позиция заключается не в выборе между compliance и security.

Она заключается в способности показать руководству оба риска, предложить реалистичные варианты обработки и добиться осознанного решения о ресурсах и residual risk.

Компания может закрыть все замечания аудита и сохранить критический маршрут атаки.

Может выполнить обязательный контроль и не обеспечить восстановление ключевого сервиса.

Может получить зелёный compliance-дашборд и оставить бизнес под неприемлемым риском.

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

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

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