С 1 марта 2026 года Приказ ФСТЭК России от 11.04.2025 № 117 заменяет Приказ № 17 и меняет саму модель защиты государственных информационных систем. Документ зарегистрирован в Минюсте 16 июня 2025 года, времени на подготовку остаётся меньше пяти месяцев. Главное смещение – от разовой аттестации «прошли проверку и живём дальше» к режиму постоянного контроля, мониторинга и регулярной отчётности. Если ваша организация эксплуатирует ГИС, иную ИС госоргана, ГУП или госучреждения, переделывать придётся не бумаги, а процессы.

От аттестации к непрерывному контролю

Раньше защищённость подтверждали в одной точке – на аттестации. Теперь регулятор требует цикл: планирование, реализация, регулярная оценка и непрерывное совершенствование системы защиты. Оценку защищённости нужно проводить не реже чем раз в полгода и считать конкретные показатели – уровень защищённости системы и зрелость процессов. Это уже не «галочка», а измеримая величина, которую придётся доказывать данными, а не отчётами.

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

Сроки устранения уязвимостей и ответственность подрядчиков

№ 117 вводит жёсткие сроки реагирования. Критические уязвимости нужно закрывать за 24 часа, уязвимости высокой степени опасности – за 7 календарных дней. По неизвестным уязвимостям предусмотрено направление сведений в ФСТЭК. На практике это означает: процесс управления уязвимостями должен работать круглосуточно, а не от сканирования к сканированию.

Расширился и периметр. Требования теперь распространяются не только на операторов ГИС, но и на организации, получающие данные из государственных систем. Подрядчики, имеющие доступ к таким данным, обязаны выполнять требования по защите, закреплённые в договорах, – но конечную ответственность несёт оператор системы. Поэтому условия безопасности нужно прописывать в контрактах с интеграторами и поставщиками ПО заранее, а не после первого инцидента.

Отдельный фронт – новые классы систем. Если вы внедряете ИИ-агентов или LLM-сценарии в контуре ГИС, модель угроз придётся расширять: про специфику таких рисков мы писали в статье про безопасность ИИ-агентов.

Что сделать до 1 марта 2026

Порядок действий понятен и его лучше начать сейчас:

  • провести аудит и переклассифицировать системы по уровню защищённости;
  • актуализировать модель угроз с учётом новых классов ИС и подрядного доступа;
  • развернуть мониторинг и процесс управления уязвимостями со сроками 24 часа / 7 дней;
  • настроить полугодовую оценку с расчётом показателей защищённости и зрелости;
  • закрепить требования безопасности в договорах с подрядчиками.

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

Вывод

№ 117 – это переход от защиты «на момент проверки» к защите как непрерывному процессу с измеримыми метриками и жёсткими сроками. Чем раньше вы перестроите процессы, тем дешевле обойдётся соответствие. Привести ГИС и прикладные системы к новым требованиям можно поэтапно – от аудита и модели угроз до мониторинга и доработки ПО.