Я не считаю исключение из требований безопасности признаком незрелости.

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

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

Expiration date сама по себе ничего не устраняет.

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

Есть и более серьёзная проблема: исключения обычно рассматриваются отдельно.

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

В каждом отдельном случае риск может выглядеть приемлемым.

Но вместе эти отклонения способны сформировать критический attack path, которого нет ни в одной строке реестра.

Поэтому security exceptions нужно управлять как портфелем: - связывать исключения по активам, идентичностям и зависимостям; - анализировать концентрацию residual risk; - выявлять повторяющиеся причины; - проверять реальную эффективность компенсирующих мер; - отделять просроченную запись от исключения без финансирования; - эскалировать повторные продления; - превращать системные проблемы в архитектурные программы.

Отдельно стоит вопрос о владельце.

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

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

Моя позиция:

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

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