Приказ ФСТЭК № 117: новые требования к защите информации

С 1 марта 2026 года в России вступает в силу Приказ ФСТЭК № 117 — обновлённые требования к защите информации в государственных и муниципальных системах. Это не просто уточнение старых правил: в 117-м появились метрики вместо одноразовой аттестации, ужесточился контроль за подрядчиками, а требования теперь охватывают облачные сервисы, мобильные устройства и удалённый доступ. Разбираем, что нового, кого это касается и как готовиться.

Коротко о главном

Приказ ФСТЭК № 117 от 11 апреля 2025 г. устанавливает требования к защите информации в государственных информационных системах (ГИС), системах государственных органов, унитарных предприятий, учреждений и муниципальных системах. Вступает в силу 1 марта 2026 года и заменяет Приказ ФСТЭК № 106 от 2019 года.

Главное отличие — отход от одноразовой аттестации к постоянному мониторингу. Теперь организации рассчитывают коэффициент защиты информации (KZI) каждые полгода и индекс зрелости (PZI) каждые два года. Требования расширены на подрядчиков, облачные сервисы, IoT и мобильные устройства. Полсотни критических требований, среди них — управление уязвимостями за 24 часа и мультифакторная аутентификация для администраторов.

Старые аттестаты до 1 марта 2026 остаются в силе; переаттестация не требуется, но систему нужно привести в соответствие с новыми требованиями в течение переходного периода.

В этой статье

Что такое Приказ ФСТЭК № 117
Кому он применяется
Когда вступает в силу и как готовиться
Основные организационные требования
Технические требования к системам
Управление уязвимостями и обновлениями
Метрики и отчётность вместо аттестации
Требования к подрядчикам

Что такое Приказ ФСТЭК № 117 и почему он нужен

Приказ — это нормативный документ ФСТЭК, который устанавливает, как должны быть защищены информационные системы государства. До 2026 года действовал Приказ № 106 от 2019 года, и за эти годы реальность изменилась: облачные сервисы стали нормой, половина работников работает удалённо, в системы встроены мобильные приложения и IoT-устройства. Старые требования уже не покрывали все риски.

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

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

Лайфхак: если ваша организация разрабатывает или поддерживает государственные системы, начните подготовку к 117-му уже сейчас — до марта 2026. Самый частый затык при внедрении нового стандарта — спешка в последние недели. За полгода можно спокойно аудировать архитектуру, обновить процессы и подготовить инструменты мониторинга. Три месяца до сроков — это уже авральный режим.

Кому применяется Приказ № 117

Требования касаются трёх категорий организаций:

Государственные информационные системы (ГИС). Системы федеральных органов, регионов, муниципалитетов. Это ЗАГС, пенсионный фонд, налоговая, судебная система, больницы — всё, что ведётся на государственные деньги и хранит данные граждан. Подробнее о требованиях к государственным ИС.
Системы унитарных предприятий и государственных учреждений. Компании с государственным капиталом и учреждения вроде вузов, научных центров, больниц под государством.
Муниципальные системы. Когда нет иных требований (например, они не попали под другой федеральный закон типа 152-ФЗ о персональных данных).

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

Важно для подрядчиков: если вы разрабатываете, тестируете, внедряете или поддерживаете такую систему, вы тоже подпадаете под требования. Это основное изменение в 117-м — раньше подрядчиков в приказе упоминали скупо.

Когда вступает в силу и как готовиться

Приказ издан 11 апреля 2025 года, опубликован в официальном реестре 16 июня 2025 года и вступает в силу 1 марта 2026 года. С этой даты все государственные системы должны соответствовать новым требованиям.

Что происходит со старыми аттестатами? Они остаются в силе до своего истечения, но система уже должна работать в соответствии с новыми требованиями 117. То есть переаттестация — не условие жизни системы, но привести её в соответствие нужно.

Переходный период: от публикации приказа (июнь 2025) до вступления в силу (март 2026) — это примерно 9 месяцев. Руководству и ИБ-отделам нужно:

Провести аудит текущей архитектуры системы на соответствие новым требованиям
Выявить критические пробелы (например, нет мультифакторной аутентификации для администраторов)
Выстроить новые процессы мониторинга и отчётности
Обновить контракты с подрядчиками
Внедрить инструменты для сбора метрик (KZI, PZI)

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

Нужна система мониторинга безопасности для соответствия новым требованиям? Аудит и оценка защищённости — поможем привести информационную систему в соответствие с 117-м приказом.

Основные организационные требования

117-й не просто говорит: «защитите систему». Он требует видимой организационной структуры и процессов. Вот что обязательно:

Политика безопасности информации. Письменный документ, где описаны принципы защиты, роли и обязанности, процессы реагирования на инциденты. Это не теория; политика должна работать в реальных сценариях.
Назначенный ответственный за информационную безопасность. Не обязательно штатная единица, но ответственность должна быть чётко возложена — по приказу или в положении структурного подразделения.
Структурное подразделение или хотя бы группа людей, занимающихся защитой информации. Для больших систем — это отдел, для небольших — специалист или внешняя компания, которая мониторит на контрактной основе. Важно: контроль должен быть постоянным, не разовым.
Персонал со специальным образованием. Минимум 30% сотрудников, работающих с безопасностью, должны иметь реальное образование или переподготовку по информационной безопасности. Это не просто сертификат, а документ об окончании образовательной программы.
Управление уязвимостями и обновлениями. Формальный процесс: как выявляются уязвимости, кто их отслеживает, в какие сроки ставятся патчи (для критических — в течение 24 часов).
Контроль физического доступа. Кто может войти в серверную, кому выданы ключи карты, логируется ли вход-выход. Мелко на уровне отделения, но обязательно.

Предупреждение от бывалого: главный затык при внедрении 117 — руководство думает, что можно нанять ИБ-специалиста в день икс и всё будет хорошо. Этого не будет. Требование про 30% персонала со специальным образованием звучит просто, но значит: если у вас пять человек в отделе защиты, то три-четыре должны иметь реальный диплом или свидетельство о переподготовке. Переподготовку можно пройти за три месяца, но нужно это делать заранее, а не неделю до дедлайна.

Технические требования к системам

Организационная часть — это основа, но тело требований — технические меры. Вот ключевые:

Аутентификация и управление доступом. Каждого пользователя нужно идентифицировать (по логину-паролю или биометрике), для администраторов обязательна мультифакторная аутентификация. Система должна знать, кто и когда заходил, при каких IP-адресах, с каких устройств.
Разграничение прав доступа. Каждый сотрудник должен видеть только то, что нужно для его работы. Оператор загса не видит медицинские карты, регистратор — не видит финансовые данные. Если что-то может быть изменено, система логирует, кто это сделал и когда.
Защита конечных устройств. Компьютеры, ноутбуки, телефоны, с которых работают с системой, должны быть защищены. Антивирус, firewall, контроль съёмных носителей — всё это входит. Особенно важно для мобильных устройств и удалённого доступа, которых в 117-м много.
Криптография и шифрование. Передача данных по сети — только по защищённым каналам (HTTPS, VPN). Конфиденциальные данные на диске — зашифрованы. Ключи хранятся в защищённом хранилище, а не в коде или на скорую руку.
Мониторинг и логирование. Система постоянно следит за попытками несанкционированного доступа, аномалиями в работе, необычными паттернами. Все события логируются с указанием пользователя, времени и источника. Логи не должны стираться без аудита.
Резервное копирование и восстановление. Данные копируются регулярно (минимум раз в сутки для критичных), копии хранятся отдельно (не на одном сервере). Проводятся регулярные тесты восстановления из копии — на бумаге не считается.

Управление уязвимостями и обновлениями

Одно из самых жёстких требований 117 — это SLA по уязвимостям. Раньше говорили: «следите за пятнами», теперь говорят: «критические уязвимости должны быть закрыты в течение 24 часов».

Как это работает на практике:

Шаг 1: Выявление. Система сканируется на уязвимости (автоматическими сканерами), специалисты смотрят консультативные рассылки ФСТЭК и CVE, исходящие от поставщиков ПО. Найденная уязвимость регистрируется в трекере.
Шаг 2: Классификация. Критическая ли это уязвимость (она даёт полный контроль над системой) или средняя (частичный доступ)? Высокая уязвимость в СУБД, через которую можно слить все данные, — критическая. Небольшой недостаток в UI, через который ничего не украдёшь, — низкая.
Шаг 3: Скоростное закрытие. Критические уязвимости закрываются патчем или обновлением в течение 24 часов. Это может быть обновление ПО, применение конфигурационного патча, временное отключение уязвимой функции. Высокие — в течение недели. Средние и низкие — в течение месяца, когда выходит плановое обновление.
Шаг 4: Отчётность. Все закрытые уязвимости должны быть задокументированы. Это входит в метрику безопасности (KZI), которую передают регулятору каждые полгода.

По факту: 24-часовое SLA — это не каприз, а требование ответственного подхода. Закрытие критической уязвимости за сутки возможно, если процесс отлажен: есть тестовое окружение, есть план откката, есть люди, которые дежурят. Это требует инвестиций, но такова цена соответствия государственным стандартам.

Метрики и отчётность вместо одноразовой аттестации

Кардинальное отличие 117 от старых приказов — это переход к метрикам вместо проверок на бумаге. Раньше было: аудитор приходит, смотрит документы, ставит галочку, и можно работать три года спокойно. Теперь: постоянно считаете показатели и рассказываете, как вы живёте.

Главные метрики:

KZI — коэффициент защиты информации. Формула, которая учитывает выполнение требований 117. Система ставит оценку от 0 до 100 (или как проценты): насколько система соответствует стандарту. Рассчитывается каждые полгода. Если KZI упал, это сигнал, что что-то пошло не так (например, не закрыли уязвимость в срок).
PZI — индекс зрелости процессов защиты информации. Оценка того, как у вас организованы процессы: есть ли политика, разработана ли процедура, как она внедряется, как контролируется. Рассчитывается раз в два года. Это более «философский» показатель — говорит не о том, что закрыто, а о том, как вы это делаете.

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

Требования к подрядчикам и как готовиться

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

Компаний, разрабатывающих ПО для государства. Если вы пишете код для ГИС, нужно соблюдать стандарты безопасной разработки (GOST R 56939-2024). Это значит: code review, ревью безопасности, контроль зависимостей, тестирование на уязвимости перед выкладкой.
Компаний, внедряющих системы. При установке, настройке и сдаче системы нужно убедиться, что она соответствует требованиям 117. Это закрепляется в акте внедрения: какие требования выполнены, какие отложены на потом, по какому плану они будут реализованы.
Компаний, поддерживающих системы. Если вы дежурный по государственной системе, вы должны мониторить её на соответствие требованиям, закрывать уязвимости в сроки, готовить отчёты по метрикам. Это встраивается в SLA контракта с заказчиком.

Способ подготовки:

Провести аудит текущих систем и проектов на соответствие 117
Обновить внутренние процессы разработки и внедрения
Переподготовить персонал (те самые 30% со специальным образованием)
Обновить контракты с заказчиками: указать новые требования и SLA по их выполнению
Внедрить инструменты автоматизации (сканеры уязвимостей, системы мониторинга, сборка метрик)
Привлечь внешних аудиторов, если нет внутренних сил

Подводные камни и типичные ошибки

Вот что происходит, когда организации внедряют новые стандарты:

Спешка и недоделки к дедлайну. Начинают готовиться за месяц до 1 марта. За месяц не успеть переобучить персонал, внедрить мониторинг и провести тесты. Результат — система как бы соответствует, но на деле падает на первой проверке.
Непонимание про 30% персонала. Нанимают ИБ-консультанта на контрактной основе и считают, что требование выполнено. Нет: 30% — это среди постоянного персонала, реально работающего с безопасностью. Консультант считается, но штатный специалист — обязателен.
Игнорирование требований к подрядчикам. Заказчик думает: «у нас есть требования, пусть подрядчик сам разбирается». Подрядчик не знает, что его требуют к отчётам по метрикам, и потом происходит конфликт. Контракты нужно обновить заранее.
Недооценка 24-часового SLA по критическим уязвимостям. Выходит пятна уязвимостей — и организация ставит их неделю позже. Для 117 это уже нарушение. Нужно заранее подготовить процесс: тестовое окружение, люди в дежурстве, план откката.
Поверхностная политика безопасности. Написали политику галопом, 5 страниц, никто не читал и не применял. На проверке спросят: как вы на практике соблюдаете п.3 политики — и ответить нечего. Политика должна быть рабочим документом, а не архивным.
Отсутствие автоматизации мониторинга. Пытаются вручную собирать данные для KZI и PZI, посчитать вручную. Это неточно, долго, и при проверке обнаруживаются ошибки. Нужны инструменты, которые автоматически снимают данные из систем и считают показатели.

На практике, когда мы прошли подготовку к 117, самый сложный момент был с требованием про образование персонала. Казалось, что можно взять курс на Интернете за неделю. Но требование говорит про реальную переподготовку: аккредитованную программу минимум 36 часов. Она может быть очной или дистанционной, но с аттестацией на конце. Это потребовало планирования за квартал до дедлайна, чтобы все нужные люди прошли курсы вовремя.

Как действовать: чек-лист подготовки

Если вы отвечаете за государственную систему или разрабатываете её для государства, вот пошаговый чек-лист на 2025–2026 годы:

Сентябрь–октябрь 2025:

Прочитайте полный текст Приказа № 117 (он есть на сайте ФСТЭК)
Проведите аудит текущей системы на соответствие 117 (можно внутри, можно привлечь внешнего аудитора)
Создайте список критических пробелов (например, нет МФА для администраторов, нет мониторинга логов)
Оцените бюджет и сроки на внедрение
Начните переподготовку персонала (минимум 30% люди должны закончить курсы по ИБ)

Ноябрь–декабрь 2025:

Внедрите критические техмеры (МФА, мониторинг, управление уязвимостями)
Обновите политику безопасности и процессы
Установите и настройте инструменты для сбора метрик (KZI, PZI)
Проведите первые тесты расчётов метрик
Если вы подрядчик — обновите контракты с заказчиками на соответствие 117

Январь–февраль 2026:

Проведите финальный аудит перед вступлением в силу
Заполните первый отчёт по KZI и PZI
Проведите тренировку команды по новым процессам
Подготовьте документацию (политика, положения, регламенты)

1 марта 2026 и далее:

Система уже соответствует 117
Каждые полгода считаете и передаёте KZI
Каждые два года считаете и передаёте PZI
Постоянно мониторите уязвимости и закрываете критические за 24 часа
Документируете все действия и готовите их для проверки

Что это значит на практике: от теории к делу

Приказ 117 выглядит грозным, но на практике — это просто чек-лист: что должно быть в системе, как это должно работать, как это должно документироваться. Если система была сделана по лучшим практикам, половина требований уже есть.

Например, если у вас есть:

система мониторинга (Zabbix, Prometheus, Grafana)
хранилище логов (ELK, Splunk)
сканер уязвимостей (Qualys, Nessus, OpenVAS)
система управления доступом (Active Directory, FreeIPA)
written security policy

То вы уже на 70% пути к 117-му. Останется: переконфигурировать под требования, внедрить метрики, обучить персонал и переподписать контракты с подрядчиками. Это трудно, но выполнимо.

Часто задаваемые вопросы

Когда вступает в силу Приказ ФСТЭК № 117?

1 марта 2026 года. Приказ издан 11 апреля 2025 года, опубликован 16 июня 2025 года. От публикации до вступления — примерно 9 месяцев, это сроки на подготовку.

Можно ли продолжать работать со старой аттестацией после 1 марта 2026?

Старый аттестат остаётся в силе до его истечения, но сама система уже должна соответствовать новым требованиям 117. Переаттестация не требуется, но привести систему в соответствие — обязательно.

Что такое KZI и PZI, которые упоминаются в 117-м?

KZI (коэффициент защиты информации) — это оценка соответствия системы техническим требованиям 117, от 0 до 100. Считается каждые полгода. PZI (индекс зрелости) — оценка организационных процессов защиты информации, считается каждые два года. Оба показателя передаются в отчётах регулятору вместо одноразовой аттестации.

Что означает требование про 30% персонала со специальным образованием?

Минимум 30% сотрудников структурного подразделения, занимающегося информационной безопасностью, должны иметь документ об окончании аккредитованной образовательной программы по ИБ или переподготовке (минимум 36 часов). Это может быть высшее образование, курсы переподготовки или сертификационные программы. Сертификаты без этого не считаются.

Какой SLA по закрытию уязвимостей требует 117?

Критические уязвимости — 24 часа, высокие — 7 дней, средние и низкие — 30 дней. Это не мягкие рекомендации, а требования приказа, которые должны быть указаны в процессах управления уязвимостями.

Касается ли Приказ № 117 ИСПДн (систем персональных данных)?

Нет. ИСПДн регулируются отдельно по 152-ФЗ и Приказу ФСТЭК № 21. Приказ № 117 касается государственных и муниципальных информационных систем в целом, но если система хранит ПДн, к ней применяются оба требования — и 117, и 21.

Есть ли штрафы за несоответствие Приказу № 117?

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

Итог

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

Для государственных органов и муниципалитетов это означает: нужна команда, нужны инструменты, нужны процессы. Для подрядчиков — переквалификация и переподписание контрактов на новых условиях. Для тех, кто работает с облачными сервисами, мобильными приложениями или удалённым доступом, это — наконец-то признание реальности в требованиях стандарта.

Начните готовиться сейчас: аудит, план, бюджет, люди. До 1 марта 2026 — ещё есть время. После этой даты все системы должны жить по новым правилам. Если начнёте позже — откажетесь в авральном режиме, и тогда поломаются либо требования к качеству, либо график внедрения. Лучше — спокойная подготовка заранее.