С 1 марта 2026 года вступил в силу приказ ФСТЭК России № 117, который кардинально пересматривает подходы к защите информации в государственном секторе. Документ заменил действовавшее с 2013 года постановление № 17, и изменения оказались гораздо глубже, чем предполагалось изначально.

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

Расширение границ или  кто подпадает под регулирование

Прежние требования распространялись только на государственные информационные системы (ГИС). Теперь зона ответственности значительно шире. Приказ № 117 охватывает:

• информационные системы государственных органов всех уровней - федеральных и региональных;
• системы государственных унитарных предприятий и учреждений;
• муниципальные информационные системы.

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

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

От статичных чек-листов к процессной модели

Самое существенное изменение - смена философии. Приказ № 17 предлагал фиксированный набор мер для каждого класса защищенности. Фактически это был чек-лист: определили класс, взяли меры из таблицы, внедрили. Приказ № 117 эту логику полностью меняет.

Теперь упор делается на процессную модель управления безопасностью. Документ выделяет 18 процессов, которые необходимо выстроить в организации. Это не просто «поставить средство защиты», а реализовывать конкретные мероприятия и доказывать их эффективность на постоянной основе.

Ключевые принципы построения системы защиты сформулированы следующим образом:

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

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

Новая классификация: не территория, а назначение

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

Отдельно стоит отметить: все системы, обрабатывающие информацию «Для служебного пользования» (ДСП), автоматически получают первый класс защищенности. Это серьезное ужесточение, которое затронет значительное количество организаций.

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

17 мер защиты: что добавилось

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

• Защита виртуализации и облачных вычислений - ранее для этих технологий в нормативных актах не были определены базовые меры;
• Защита технологий контейнерных сред и их оркестрации - актуально для организаций, использующих современные платформы развертывания приложений;
• Защита сервисов электронной почты - выделена в отдельную категорию;
• Защита веб-технологий;
• Защита программных интерфейсов взаимодействия приложений (API);
• Защита мобильных устройств;
• Защита технологий интернета вещей (IoT).

Для конечных устройств акцент смещается с традиционных антивирусов на решения класса EDR (поведенческий анализ, реагирование на инциденты).

Усиленная аутентификация

Одно из ключевых требований, которое затронет практически всех, - модернизация систем аутентификации. Приказ обязывает использовать строгую аутентификацию для привилегированного доступа. В случаях, когда это технически невозможно, требуется усиленная многофакторная аутентификация (MFA).

Это касается не только внутренних систем, но и удаленного доступа, включая мобильные устройства. Организациям придется внедрять решения на основе аппаратных токенов или одноразовых паролей (OTP). Для многих это означает пересмотр подходов к управлению доступом и, как следствие, дополнительные бюджетные затраты.

Искусственный интеллект: 

Впервые в регулировании защиты информации государственного сектора уделено внимание вопросам безопасности при использовании искусственного интеллекта. Приказ № 117 устанавливает требования к применению ИИ-систем в государственных информационных системах.

Согласно документу, при использовании искусственного интеллекта должны применяться доверенные технологии ИИ или их компоненты. Кроме того, введены ограничения на использование недоверенных ИИ-технологий, обязательный контроль корректности ответов нейросетей (так называемые «галлюцинации») и фильтрация пользовательских запросов.

Важное уточнение: для обработки информации ограниченного доступа запрещено использование облачных ИИ-сервисов. Это означает, что все решения должны разворачиваться в закрытом контуре организации.

ФСТЭК разрабатывает отдельный стандарт по безопасной разработке систем искусственного интеллекта в дополнение к ГОСТ Р 56939-2024. Документ должен учесть специфические риски машинного обучения: «галлюцинации» моделей, утечки данных через промпты, отравление обучающих выборок и состязательные атаки.

Безопасная разработка

Если организация самостоятельно разрабатывает программное обеспечение для использования в информационных системах, необходимо учитывать меры, предусмотренные ГОСТ Р 56939-2024. При привлечении подрядчиков требования к безопасной разработке должны быть включены в техническое задание.

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

Поставщики обязаны защищать собственную инфраструктуру и использовать отечественные инструменты анализа уязвимостей и качества кода. Цепочки поставок (Software Supply Chain Attacks) в последние годы стали одним из ключевых каналов проникновения, и регулятор это учитывает.

Отчетность и контроль

Приказ № 117 вводит регулярную отчетность перед ФСТЭК. Срок направления сведений по результатам оценки защищенности, выявленным уязвимостям и инцидентам сокращен до 5 рабочих дней.

Кроме того, вводятся два новых показателя для внутренней оценки:

• Показатель защищенности информации (КЗИ) - оценка от базовых угроз. Рассчитывается не реже одного раза в шесть месяцев.
• Показатель уровня зрелости (ПЗИ) - оценка эффективности мер защиты. Периодичность - не реже одного раза в два года.

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

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

Аттестация: что остается, что меняется

Обязательная аттестация по-прежнему предусмотрена только для государственных информационных систем. Для остальных систем решение принимается оператором самостоятельно.

Все действующие аттестаты соответствия, выданные до 1 марта 2026 года, сохраняют свою силу. Повторной аттестации для действующих систем не требуется. Однако есть важное условие: в случае модернизации системы, изменения ее конфигурации (например, при смене операционной системы) или продления аттестата, аттестовываться нужно будет уже по новым требованиям приказа № 117.

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

Постановление № 171: ужесточение лицензирования СЗКИ

Параллельно с приказом № 117 правительство подготовило проект изменений в постановление № 171, регулирующее лицензирование деятельности по разработке и производству средств защиты конфиденциальной информации (СЗКИ). Изменения существенно ужесточают требования.

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

Требования к персоналу. Закреплены минимальные требования к квалификации и численности специалистов. Руководитель работ должен иметь высшее образование в области ИБ или иное высшее с профпереподготовкой, согласованной с ФСТЭК, и стаж не менее 5 лет. Инженерно-технические работники - высшее образование в области ИБ или иное с профпереподготовкой, стаж не менее 3 лет.

Минимальная численность инженерно-технических работников:

• для разработки технических средств защиты, ТСОИ, контроля эффективности - не менее 5;
• для программных и программно-технических СЗИ - не менее 10.

Импортозамещение. Закреплено требование использовать оборудование и программное обеспечение преимущественно отечественного производства, размещенное на территории РФ, по перечням, устанавливаемым ФСТЭК.

Безопасная разработка. Для разработчиков программных СЗИ вводится требование наличия системы производственного контроля качества и процессов безопасной разработки ПО в соответствии с ГОСТ Р 5639-2024.

Защищенная ИС. Впервые прямо закрепляется требование иметь информационную систему для обработки конфиденциальной информации с использованием сертифицированных средств защиты информации и прошедшую аттестацию.

Грубые нарушения. К грубым нарушениям, влекущим риски приостановки или аннулирования лицензии, теперь относятся несоответствие требованиям к персоналу, отсутствие отечественного оборудования и ПО, отсутствие защищенных ИС, нарушения в процессах безопасной разработки.

Сравнение ключевых требований: Приказ № 17 vs Приказ № 117

Для наглядности основные отличия двух документов представлены в таблице ниже.

Что делать сейчас

Статус документа - проект, общественное обсуждение которого завершилось 19 февраля. Финальная версия может отличаться, но подготовку лучше начинать заранее.

• Изучить 18 процессов. Необходимо сопоставить их с действующими практиками информационной безопасности в организации. Это основа для выстраивания процессной модели.
• Проверить архитектуру систем. Оценить соответствие принципам безопасного проектирования - сегментация, минимальные привилегии, минимизация интерфейсов. Провести инвентаризацию всех информационных систем, обрабатывающих информацию ограниченного доступа.
• Оценить средства защиты. Проверить, насколько применяемые решения способны реализовать требуемые усиления. Особое внимание - системам аутентификации, EDR, средствам защиты виртуализации и облачных сред.
• Обновить внутренние регламенты. Особое внимание - управлению уязвимостями, конфигурациями, обновлениями и мониторингу безопасности. Определить периодичность и методы контроля уровня защищенности.
• Пересмотреть договоры с подрядчиками. Включить требования по безопасной разработке, использованию отечественных инструментов анализа кода, предоставлению аттестатов по модели угроз заказчика.

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

Приказ № 117 не просто замена одного документа другим. Это смена парадигмы: от формального соответствия к управлению рисками, от защиты только ГИС к защите всей государственной ИТ-инфраструктуры, от разовых проверок к непрерывному процессу с регулярной оценкой зрелости. И чем раньше организации начнут адаптацию, тем меньше рисков - как регуляторных, так и технологических - они понесут.