Приказ ФСТЭК № 117: что проверить владельцу ГИС и подрядчику

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

С 1 марта 2026 года действуют новые Требования о защите информации, содержащейся в государственных информационных системах (ГИС), а также в иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений и муниципальных информационных системах — они утверждены приказом ФСТЭК России от 11.04.2025 № 117 и заменили собой приказ № 17 от 2013 года и ряд связанных документов[1]. Главное отличие от предыдущего порядка — переход от разовой аттестации к постоянному, измеряемому процессу: организация обязана считать показатель защищённости (Кзи) не реже раза в полгода, оценивать зрелость процессов ИБ, устранять критические уязвимости за 24 часа, а высокие — за 7 дней, и отдельно прописывать ответственность подрядчиков, у которых есть доступ к системе[16]. Если ваша организация — оператор ГИС, интегратор, подключаемый внешний сервис или подрядчик с доступом к такой системе, приказ № 117 касается вас напрямую, и до ввода системы в эксплуатацию должен быть готов определённый комплект документов, а не просто закупленный набор средств защиты.

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

Кому и почему это важно уже сейчас

Раньше можно было один раз пройти аттестацию ГИС и спокойно жить с полученным аттестатом соответствия до следующей плановой проверки. Приказ № 117 меняет саму логику: защита должна не просто существовать, а адаптироваться под меняющуюся инфраструктуру и актуальные угрозы, а её эффективность — регулярно подтверждаться цифрами и отчётностью перед регулятором[8]. Это не просто ужесточение техтребований — это переход к процессному управлению информационной безопасностью с конкретными сроками, показателями и зонами ответственности, в том числе для подрядчиков[5].

Для рынка закупок и интеграции это означает: ТЗ на разработку или доработку ГИС, которое не учитывает новые требования, приведёт либо к невозможности пройти аттестацию, либо к дорогостоящей переделке уже после того, как система формально запущена.

Подпадает ли ваша система под требования приказа № 117

Требования распространяются на несколько категорий систем[7]:

• государственные информационные системы (ГИС) — для них по-прежнему обязательна аттестация;
• иные информационные системы государственных органов, государственных унитарных предприятий и государственных учреждений — аттестация для них не обязательна, но обязательна реализация всех предусмотренных приказом мер защиты, включая сертифицированные средства защиты информации, эксплуатационную документацию и контроль соответствия[2];
• муниципальные информационные системы — в приказе № 117 они упомянуты наравне с государственными, тогда как в приказе № 17 их статус был прописан менее чётко[10].

Отдельный и часто болезненный вопрос — внешние (сторонние) информационные системы, которые подключаются к ГИС и обмениваются с ней данными. В проекте приказа регулятор изначально предлагал жёстко распространить требования на все системы, передающие конфиденциальную информацию в ГИС, даже если их оператор не является государственным органом. От такого подхода в итоговой редакции отказались: теперь решение о том, предъявлять ли требования приказа № 117 к сторонней ИС (вплоть до требования об аттестации по тому же классу защищённости), принимает оператор головной ГИС самостоятельно[11]. Это значит: если вы разрабатываете или предоставляете внешний сервис, интегрируемый с ГИС, конкретные требования к вашей системе нужно уточнять непосредственно у оператора ГИС — единого стандарта «для всех подключаемых систем» приказ не задаёт.

Действующие аттестаты соответствия, полученные до вступления приказа в силу, сохраняют силу — повторная аттестация для уже аттестованных систем не требуется автоматически[6]. Отдельно ФСТЭК выпустила информационное сообщение от 12.03.2026 № 240/22/1492 с разъяснением порядка перехода: для договоров с подрядчиками, заключённых до 1 марта 2026 года, допускается завершить работы по прежним требованиям приказа № 17[21].

Как определить границу защищаемой системы

Приказ № 117 требует связывать конкретные меры защиты не с абстрактным «периметром», а с реальной архитектурой: классом защищённости системы, моделью угроз, составом обрабатываемой информации, ролями пользователей, внешними подключениями, применяемыми технологиями и подрядчиками, которые к системе допущены[8]. Практически это означает, что перед определением границы системы нужно провести её обследование: зафиксировать, что именно защищается, какие угрозы актуальны, и какой состав и сроки реализации мер защиты из этого следуют[14].

На этом этапе типична ошибка — определять границу системы «по документам», а не по факту передачи данных. Если сторонний сервис получает доступ к части информационных ресурсов ГИС через API, веб-интерфейс или файловый обмен, эта точка подключения — часть границы, которую нужно защищать и описывать в модели угроз, независимо от того, кому формально принадлежит оборудование на другом конце. Особое внимание приказ уделяет веб-каналу как одному из самых уязвимых участков взаимодействия с внешними пользователями и системами[8].

Что требуется от внешней системы и подрядчика

Новая редакция приказа знаменует переход от изолированной защиты периметра ГИС к обеспечению безопасности всей связанной ИТ-инфраструктуры, а ключевым вектором становится управление рисками цепочки поставок — то есть строгие требования именно к подрядчикам и внешним поставщикам сервисов, а не только к собственной инфраструктуре оператора[20]. Изменение, важное для интеграторов: понятие «уполномоченного лица» из приказа № 17 (стороны, которой ГИС передавала данные на обработку) исчезло — теперь все внешние обработчики информации рассматриваются как подрядные организации с чётко прописанными в договорах обязанностями[10]. Из этого следует несколько практических требований:

• подрядчик должен быть ознакомлен с политикой оператора по защите информации — желательно документально, актом ознакомления или приложением к договору[14];
• в договор или иной документ, регулирующий доступ подрядчика к ГИС, должны быть включены требования по информационной безопасности и ответственность за их нарушение[16];
• если подрядчик участвует в разработке ПО для использования в информационной системе — своей или заказчика — должны быть реализованы меры разделов 4 и 5 ГОСТ Р 56939-2024 (безопасная разработка ПО); приказ прямо не требует включать этот ГОСТ в текст ТЗ, но при аттестации орган по аттестации будет оценивать соответствие требованиям к безопасной разработке, и невыполнение стандарта подрядчиком может помешать пройти аттестацию[5];
• если сторонняя система интегрирована с ГИС, оператор ГИС вправе потребовать, чтобы она была защищена на том же классе защищённости и это было подтверждено аттестатом соответствия[14];
• для систем с компонентами искусственного интеллекта приказ впервые вводит требование, чтобы применяемые ИИ-технологии были доверенными — это отдельный предмет оценки при аттестации[5].

Если планируется применение шифровальных (криптографических) средств, приказ требует параллельного соблюдения требований ФСБ России, а также запрещает применение средств защиты вопреки ограничениям, введённым Указом Президента РФ № 250 от 01.05.2022[10].

Какие документы должны существовать до ввода в эксплуатацию

Практика перехода на новые требования складывается в понятную последовательность этапов создания или модернизации системы защиты[13]:

1. Определение актуальных угроз и класса защищённости системы.
2. Формирование плана мероприятий, бюджета и распределение ответственности.
3. Реализация технических и организационных мер защиты.
4. Подготовка регламентов и доказательств выполнения требований.
5. Внедрение, предварительные испытания, опытная эксплуатация и приёмочные испытания.
6. Аттестационные испытания (для ГИС) и организация последующего контроля.

Подробнее по документообороту при разработке системы защиты: моделирование угроз (модель нарушителя и сценарии атак), формирование требований и ТЗ на подсистему защиты, проектирование (пояснительная записка, рабочая и эксплуатационная документация), внедрение и утверждение организационно-распорядительной документации (ОРД)[11]. Отдельным пакетом идёт отчётная документация по результатам аттестационных испытаний: программа и методики испытаний, протоколы испытаний, заключение по результатам испытаний и, собственно, аттестат соответствия — для ГИС этот пакет обязателен[14].

Важная деталь для негосударственных информационных систем, подключаемых к ГИС: решение о необходимости разработки модели угроз в ходе создания такой системы принимает руководитель оператора этой ИС самостоятельно (пункт 36 Требований) — формально модель угроз для них не обязательна, хотя логика всего приказа построена на том, что защита должна быть привязана именно к актуальным угрозам, поэтому на практике отказ от модели угроз резко снижает шансы объяснить регулятору или заказчику ГИС, почему выбран тот или иной набор мер[14].

Как связать модель угроз с конкретными техническими мерами

Оператор (обладатель информации) сам определяет цели защиты информации исходя из ожидаемых негативных последствий; эти негативные события определяются на основе банка данных угроз безопасности информации ФСТЭК России, а задачи защиты информации должны обеспечивать достижение сформулированных целей[3]. То есть цепочка обязательна именно в этом порядке: негативные последствия → актуальные угрозы из БДУ ФСТЭК → задачи защиты → конкретные технические и организационные меры. Даже если формально для конкретной ИС модель угроз не требуется, набор мер защиты, который не привязан ни к одной задокументированной угрозе, при проверке будет выглядеть немотивированным.

Приказ выделяет 17 ключевых базовых мер защиты, из которых 9 учитывают новые технологические аспекты — включая идентификацию и аутентификацию, защиту при использовании контейнерных сред, облачных технологий и компонентов с ИИ[19]. Методический документ ФСТЭК «Состав и содержание мероприятий и мер по защите информации, содержащейся в информационных системах» утверждён 14.04.2026 и распространяется не только на ГИС, но и на иные ИС государственных органов, ГУП и учреждений, а также на ИТ-инфраструктуры, обеспечивающие их работу[14]. До выхода этого документа многие организации ориентировались на предыдущую методику приказа № 17 — теперь актуальную детализацию мер нужно сверять именно по новому методическому документу.

Какие журналы и результаты испытаний хранить

Сами Требования используют формулировки «показатель защищённости» (Кзи) — он характеризует текущее состояние защиты информации от базового уровня угроз — и «показатель уровня зрелости» (Пзи) — он определяет достаточность и эффективность проводимых мероприятий по защите информации; в публикациях встречаются и другие расшифровки этих аббревиатур, но именно такие формулировки закреплены в тексте документа[15]. Помимо базового комплекта аттестационных документов (программа и методики испытаний, протоколы, заключение, аттестат), приказ вводит регулярную, а не разовую отчётность:

• расчёт показателя защищённости (Кзи) — не реже одного раза в 6 месяцев, с уведомлением руководителя оператора не позднее 3 дней с момента выявления несоответствия и направлением результатов во ФСТЭК России не позднее 5 дней после расчёта[14];
• оценка показателя уровня зрелости процессов защиты — по действующей методике этот показатель обязателен к расчёту при привлечении подрядных организаций, при этом направлять результаты его оценки во ФСТЭК больше не требуется — это уточнение внесено позже в изменения к приказу[17];
• итоговый годовой отчёт по результатам мониторинга состояния информационной безопасности[22];
• отчёт по результатам контроля уровня защищённости — раз в 3 года или в течение 5 рабочих дней после инцидента[5];
• журнал (реестр) выявленных уязвимостей со сроками устранения: критические — не более 24 часов, высокие — не более 7 календарных дней, для уязвимостей среднего и низкого уровня сроки устанавливаются внутренними регламентами организации; если выявленной уязвимости нет в банке данных угроз ФСТЭК, информацию о ней нужно направить регулятору в срок не более 5 рабочих дней[7];
• результаты сканирования активов на уязвимости — не реже одного раза в месяц, отдельно для внешнего периметра и для внутренней инфраструктуры[19].

На практике расчёт Кзи выполняется не одним числом, а по группам мер (например, «организация и управление», «защита пользователей», «защита информационных систем», «мониторинг и реагирование»), каждая из которых имеет свой вес в итоговой формуле, — это стоит учитывать при построении внутренней методики оценки и выборе, куда в первую очередь направлять ресурсы при низком итоговом значении показателя[18].

Практический вывод: без автоматизации управления уязвимостями и учёта показателей выдерживать 24-часовой цикл на критические уязвимости и параллельно готовить регулярную отчётность для ФСТЭК вручную крайне сложно — это скорее задача для GRC-системы или иного инструмента мониторинга, чем для таблицы в Excel[12].

Что включить в ТЗ и критерии приёмки подрядчика

Из требований приказа для ТЗ на разработку, интеграцию или сопровождение ГИС имеет смысл заранее зафиксировать:

• обязанность подрядчика соблюдать политику оператора по защите информации и порядок ознакомления с ней;
• условие о применении мер безопасной разработки ПО по разделам 4 и 5 ГОСТ Р 56939-2024, если подрядчик разрабатывает или дорабатывает программный код для системы[22];
• порядок и сроки реагирования подрядчика на выявленные уязвимости в его зоне ответственности, синхронизированные со сроками приказа (24 часа/7 дней);
• обязанность подрядчика передавать заказчику эксплуатационную документацию, результаты тестирования (включая тестирование на проникновение после функциональных испытаний) и материалы, необходимые для аттестации[11];
• ответственность подрядчика и порядок расторжения договора при нарушении требований по защите информации;
• при необходимости — требование к классу защищённости или аттестату соответствия подрядной ИС, если она интегрируется с ГИС и получает доступ к её данным.

Критерии приёмки должны включать не только функциональное тестирование, но и подтверждение прохождения предварительных испытаний, опытной эксплуатации и приёмочных испытаний подсистемы защиты, а для ГИС — успешные аттестационные испытания с положительным заключением[13].

Как организовать управление изменениями после запуска

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

На практике управление изменениями после запуска системы включает:

• регулярный (не реже раза в месяц) пересмотр списка активов и повторное сканирование на уязвимости;
• полугодовой цикл расчёта Кзи с оперативным реагированием на снижение показателя;
• обязательную процедуру дополнительных аттестационных испытаний при существенной модернизации системы — с планированием перехода и, при необходимости, поэтапным планом внедрения новых мер[12];
• уведомление ГосСОПКА об инцидентах информационной безопасности в установленном порядке[9];
• регулярные тренировки сотрудников по действиям при инцидентах и угрозах — эта практика теперь входит в состав аттестационных мероприятий, а не остаётся добровольной инициативой[11].

Ограничения и типичные ошибки

Ещё на этапе публикации самого приказа в его тексте не было детализации конкретных мер защиты — ФСТЭК изначально анонсировала выпуск методических рекомендаций отдельно, и именно от их содержания зависела итоговая сложность и стоимость выполнения требований[4]. На момент подготовки этого материала окончательная детализация состава мер защиты по ряду направлений продолжает уточняться отдельными методическими документами ФСТЭК, которые выходят уже после вступления приказа в силу (например, методический документ по составу мероприятий — от 14.04.2026, методика анализа защищённости — от 25.11.2025)[19]. Это означает, что планы перехода стоит закладывать с запасом на уточнение требований, а не фиксировать окончательную архитектуру защиты до появления актуальной методической базы.

Частые ошибки, которые встречаются в проектах перехода на приказ № 117:

• граница системы определяется «по документам» без учёта фактических точек интеграции с внешними сервисами;
• договоры с действующими подрядчиками не пересматриваются, хотя доступ к ГИС у них уже есть;
• отсутствует модель угроз даже там, где она формально не обязательна, из-за чего сложно обосновать выбранный набор мер при контроле;
• управление уязвимостями ведётся вручную, что делает нереалистичным соблюдение срока 24 часа на критические уязвимости;
• модернизация системы проводится без дополнительных аттестационных испытаний, хотя изменение архитектуры этого требует.

Когда достаточно консультации, а когда нужна разработка или интеграция

Не каждая задача требует полной перестройки системы защиты. Если у оператора уже есть аттестованная ГИС с действующим аттестатом, задача может свестись к точечным доработкам: пересмотру договоров с подрядчиками, настройке журналирования уязвимостей и организации регулярного расчёта показателей. Если же система создаётся заново, существенно меняется архитектура (переход на микросервисы, облачные компоненты, подключение новых внешних сервисов) или ранее защита строилась «для галочки», обычно требуется полноценный цикл: обследование, модель угроз, ТЗ на подсистему защиты, реализация мер и аттестация.

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

Вывод

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

Источники

[1] normativ.kontur.ru — Приказ ФСТЭК РФ от 11.04.2025 N 117 (редакция от 11.04.2025) — https://normativ.kontur.ru/document?moduleId=1&documentId=500478

[2] anti-malware.ru — Обзор законодательства в сфере информационной безопасности за 2025 год — https://www.anti-malware.ru/analytics/Technology_Analysis/Information-Security-Legislation-2025

[3] fstec.ru — Требования, утверждённые приказом ФСТЭК России от 11 апреля 2025 г. № 117 — https://fstec.ru/dokumenty/vse-dokumenty/spetsialnye-normativnye-dokumenty/trebovaniya-utverzhdeny-prikazom-fstek-rossii-ot-11-aprelya-2025-g-n-117

[4] softline.ru — Приказ ФСТЭК № 117: как выполнить новые требования к защите ГИС — https://softline.ru/about/blog/prikaz-fstek-117-kak-vypolnit-novye-trebovaniya-k-zashchite-gis

[5] bi.zone — Приказ ФСТЭК России № 117: новый этап защиты информации в госсекторе — https://bi.zone/expertise/insights/prikaz-fstek-rossii-117-novyy-etap-zashchity-informatsii-v-gossektore/

[6] angarasecurity.ru — Анализ приказа ФСТЭК России № 117 — https://www.angarasecurity.ru/stati/analiz-prikaza-fstek-rossii-117/

[7] multifactor.ru — Приказ ФСТЭК № 117: что изменилось в требованиях к защите информации — https://multifactor.ru/press-center/prikaz-fstek-117/

[8] rt-solar.ru — Приказ ФСТЭК России № 117: какие требования к веб-каналу важно учесть — https://rt-solar.ru/products/solar_webproxy/blog/6661/

[9] academyit.ru — Приказ 117 ФСТЭК РФ: что изменится с 1 марта 2026 года для организаций — https://academyit.ru/articles/tematika3/prikaz-fstek-117-klyuchevye-trebovaniya-v-2026-godu/

[10] itb.spb.ru — Новый приказ ФСТЭК № 117: кого коснётся, что менять и как не нарушить закон — https://www.itb.spb.ru/about/press/novyy-prikaz-fstek-117-kogo-kosnyetsya-chto-menyat-i-kak-ne-narushit-zakon/

[11] kiberboloid.ru — Приказ ФСТЭК № 117: что изменилось, как подготовиться и не сорвать аттестацию — https://kiberboloid.ru/masterskaya/fstec-changes-preparation-certification/

[12] habr.com — Приказ ФСТЭК России № 117: полный обзор нововведений и практическое руководство по переходу от Приказа № 17 — https://habr.com/ru/articles/1016070/

[13] b-152.ru — Приказ ФСТЭК № 117: подготовка к аттестации и новым требованиям — https://b-152.ru/prikaz-fstek-117-podgotovka-k-attestatsii

[14] xn--90ao1ar.xn--p1ai — Приказ ФСТЭК 117. Ключевые нововведения и разъяснения ФСТЭК — https://xn--90ao1ar.xn--p1ai/attestatsiya_fstek/prikaz-fstec-117/

[15] cisoclub.ru — Приказ ФСТЭК 117: требования о защите информации в ГИС — https://cisoclub.ru/prikaz-fstek-117/

[16] passwork.ru — Приказ ФСТЭК № 117: разбор изменений, Кзи и штрафов — https://passwork.ru/blog/prikaz-fstek-117/

[17] rtmtech.ru — 117 приказ ФСТЭК изменён: новые требования к защите информации и уровню зрелости — https://rtmtech.ru/news/izmeneniya-117-prikaz-fstek-2026/

[18] aiticenter.ru — Расчёт КЗИ по приказу 117 ФСТЭК: требования к защите информации в госсекторе — https://aiticenter.ru/news/otsenka-kzi-po-117mu-prikazu-f/

[19] angarasecurity.ru — Приказ ФСТЭК 117: что изменилось для владельцев КИИ с 1 марта 2026 — https://www.angarasecurity.ru/stati/prikaz-fstek-117-chto-izmenilos-dlya-vladeltsev-kii-s-1-marta-2026/

[20] anti-malware.ru — Новый приказ ФСТЭК №117: ключевые требования для ГИС в 2026 году — https://www.anti-malware.ru/analytics/Technology_Analysis/FSTEC-Order-No-117

[21] itprotect.ru — ФСТЭК разъяснила порядок перехода на приказ № 117 — https://itprotect.ru/mediacenter/news/fstek-razyasneniya-prikaz-117/

[22] indeed-id.ru — Новый приказ ФСТЭК России № 117: обзор и отличия от приказа № 17 — https://indeed-id.ru/blog/novyj-prikaz-fstek-rossii-117-obzor-i-otlichiya-ot-prikaza-17/