Регулирование в сфере ИБ меняется постоянно, но приказ №117 ФСТЭК России кардинально отличается от предыдущих. Разбираем суть изменений и переводим их на практическую плоскость для бизнеса вместе с Максимом Куртиным, директором департамента информационной безопасности «Группы Астра».
До апреля 2025 года рынок информационной безопасности жил в рамках трех документов и у каждого была своя зона ответственности. Приказ №21 ФСТЭК России отвечал за защиту информационных систем персональных данных (ИСПДн), приказ №239 защищал критическую информационную инфраструктуру (КИИ), а приказ №17 — государственные информационные системы (ГИС).
Три приказа, три периметра, понятные границы.
Потом ФСТЭК России выпустил приказ №117 от 11 апреля 2025 года. Он заменил приказ №17 и расширил периметр регулирования. Раньше под его требования попадали исключительно государственные или муниципальные информационные системы. Теперь требования распространяются как на государственные информационные системы, так и на иные информационные системы государственных органов, государственных унитарных предприятий, государственных учреждений. Если вы разработчик, интегратор, облачный провайдер — неважно, и ваша компания работает с государственной информационной системой по договору, то требования приказа №117 также становятся вашей обязанностью. При этом приказы ФСТЭК России №21 и №239 никуда не делись. Персональные данные и критическая инфраструктура по-прежнему защищаются по своим правилам.
Формально новые требования вступили в силу в марте 2026 года. То есть почти через год после официальной публикации приказа №117. ФСТЭК России выделила столько времени неслучайно: масштаб изменений касался и новых компаний, которые под него теперь попадают, и в целом самого подхода к защите информации.
Раньше структура приказа объединяла описательную часть и конкретные меры защиты в одном документе. Приказ №117 развел эти уровни на два документа — сам приказ и методический документ с мерами защиты.
ФСТЭК России сразу предупредила бизнес, что с марта проверки идут по новому приказу. Но что именно нужно внедрить, чтобы соответствовать, регулятор объяснил только в апреле — документ с мерами защиты вышел на месяц позже.
На фоне всех этих изменений часть требований осталась.
Классификация защищенности прежняя: три класса, К1, К2 и К3. При этом К1 подразумевает самые жесткие требования. Оператор (прим. — то есть компания) все также должен определять нужный класс, исходя из уровня значимости информации (УЗ), обрабатываемой в информационной системе, и ее масштаба (федеральный, региональный, объектовый).
Плюс изменения не коснулись базового принципа использования средств защиты (СЗИ и СКЗИ). А именно — любая мера защиты информации реализуется только с помощью проверенного средства, то есть имеющее сертификат соответствия ФСТЭК России.
И это по сути правильно. Классификация и сертифицированные средства — механизмы, которые бизнес уже отладил за годы работы с ФСТЭК России. Ломать их ради самого факта реформы означало бы создавать хаос там, где его не было. Регулятор перестроил только то, что действительно устарело — сам процесс защиты информационной системы.
Одно из самых кардинальных изменений в требованиях ФСТЭК России к защите информационных систем затрагивает непосредственно процесс контроля.
В старой редакции приказа №17 периодическая отчетность по ИБ-деятельности, конечно, была. Системы первого класса защищенности проверяли не реже раза в год, второго и третьего классов — не реже раза в два года. Аттестат при этом действовал на весь срок эксплуатации системы.
В новом приказе №117 идея контроля вышла на новый уровень — системный. Появились новые вводные.
Показатель защищенности информации (КЗИ) — числовой показатель от 0 до 1, который теперь считают не реже, чем раз в полгода для системы любого класса защищенности.
Другими словами, разница по классам исчезла. Раньше периодичность зависела от класса системы, теперь она одинакова для всех. Как именно считать КЗИ, ФСТЭК России прописала отдельно в методике оценки показателя состояния технической защиты информации, утвержденной 11 ноября 2025 года. Итоговое значение — взвешенная оценка по группам критериев, где провал в одной группе тянет вниз весь показатель.
Хотя шкала идет от 0 до 1, минимально допустимое значение — именно 1. Оно соответствует полному выполнению всех применимых мер защиты с учетом их веса. Значения ниже уже считаются отклонением. От 0,75 до 1 расценивается как низкий уровень, а ниже 0,75 считается критическим. Результаты передаются во ФСТЭК России не позднее 5 рабочих дней после расчета. При значении ниже нормы оператор обязан разработать план мероприятий до следующей плановой оценки.
Показатель уровня зрелости (ПЗИ) — вторая метрика. В отличие от КЗИ, который проверяет техническое выполнение мер, ПЗИ показывает, насколько системно и периодично компания их проводит. Можно закрыть все пункты по КЗИ формально и хаотично без регламентов и процедур, но ПЗИ при этом будет низким, так как сама процедура защиты не отлажена.
Считает его сам оператор не реже, чем раз в два года. В мае 2026 года ФСТЭК России опубликовал проект методики, который предлагает оценивать ПЗИ по 21 направлению деятельности защиты информации. Среди них:
Для каждого направления деятельности используется пятиуровневая шкала оценки, используемая для расчета итогового показателя.
По факту КЗИ и ПЗИ — это два взгляда на одну цель. Регулятор требует от каждой компании выстроить информационную безопасность как управляемую систему: меру внедряют, проверяют на прочность, находят уязвимость или угрозу, устраняют ее и проверяют снова. Весь цикл становится постоянным процессом.
Дальше идет конкретика, из чего состоит эта непрерывность:
По последнему пункту пояснение: отдельного тестового сегмента старый приказ №17 не требовал. Новый же №117, как видим, учитывает и этот вид деятельности.
Также обновленные требования затронули организационную структуру. Впервые в документе появился раздел про обязанности, функции и полномочия ответственного за защиту информации в компании. Оператор обязан создать структурное подразделение по информационной безопасности или назначить специалистов на эти функции. Раньше этот вопрос оставался на усмотрение компании. Теперь — обязанность, прямо прописанная в приказе.
Идентификация компонентов информационной системы — требование, которого не было в приказе №17 от слова совсем. Теперь оператор обязан знать каждый элемент своей системы: компьютеры, сетевое оборудование, программное обеспечение, пользователей. Если на компьютере в сети появляется незнакомое устройство, система не должна позволить ему запуститься и что-либо сделать.
В список обязательных мер добавились еще два пункта по этому же вопросу: защита конечных устройств и защита IoT-устройств. Речь идет о рабочих станциях, ноутбуках и серверах, через которые сотрудники и процессы напрямую взаимодействуют с системой, а также о сенсорах, камерах и контроллерах, подключенных к сети как IoT-устройства.
Как следствие появилось требование к корпоративному удостоверяющему центру. Компания обязана поднять внутри себя собственный центр сертификации, который выпускает сертификаты для идентификации пользователей, устройств и программного обеспечения.
Список мер также расширился за счет конкретных технологий. Например, впервые в приказе появилась защита почтовых серверов. Что, в принципе, логично, потому что количество атак на корпоративные почтовые сервисы с каждым годом растет. Правда, это ударило по рынку, так как сертифицированных средств под новые группы мер физически нет. Потребуется время, чтобы они появились. На этом фоне «Группа Астра» запустила дополнительную сертификацию двух собственных продуктов, RuPost и WorksPad, чтобы у заказчиков появилась возможность их использовать для реализации новых мер приказа №117 ФСТЭК России.
Конечно, не обошлось без ИИ. Приказ запрещает разработчику передавать ИИ-модели защищаемую информацию и требует исключить несанкционированное воздействие ИИ на наборы данных и их параметры. Отдельно контролируется взаимодействие пользователей с сервисами ИИ, а сама информационная система обязана использовать только доверенные ИИ-технологии. Проблема в том, что реестра доверенных технологий ИИ на сегодняшний день не существует. Регулятор ввел требование раньше, чем появился инструмент для его выполнения. Но эта тема требует отдельной статьи, пока что не будем сильно в нее погружаться.
Что со всем этим делать бизнесу?
У бизнеса по новому приказу №117 ФСТЭК России два принципиально разных положения: аттестат уже есть, или его только предстоит получить. Логика действий в этих случаях расходится.
Если аттестат ИС старого образца (по №17 приказу ФСТЭК России) уже действует, менять его в моменте не нужно. ФСТЭК России будет проверять систему по старым правилам до конца срока действия аттестата. Но с оговоркой: конфигурация системы должна оставаться неизменной. Если систему модернизируют или обновляют, аттестацию придется проходить заново, уже по требованиям приказа №117. А когда срок действия старого аттестата все-таки закончится, переход на новые требования произойдет в любом случае. Единственное, что стоит сделать прямо сейчас: начать планировать модернизацию заранее.
Если аттестата нет или систему только разворачивают, выбор на первый взгляд простой: строить защиту самостоятельно или разместиться в уже аттестованной инфраструктуре.
Самостоятельная сборка означает, что все меры приказа №117 компания закрывает с нуля:
Дольше и дороже, но иногда оправдано — например, если нагрузка нестандартная или требования специфичны.
Второй вариант подразумевает переезд в облачную среду. Причем не в публичную, а в защищенную инсталляцию с аттестатом ФСТЭК России по новым требованиям приказа №117. Такой формат уже начали предлагать некоторые облачные провайдеры в России. Astra Cloud тоже готовит запуск защищенного аттестованного решения в ближайшее время.
По существу у такого облака есть готовый слой защиты на уровне инфраструктуры и системного программного обеспечения, который прошел аттестацию. Он закрывает значительную часть мер, требуемых для информационной системы по новым правилам.
После миграции ИС заказчику остается доделать небольшую часть работ самостоятельно или заказать у провайдера как дополнительную услугу — например, защитить виртуальные машины.
Дальше происходит то, что можно назвать двойной аттестацией. Аттестат облака подтверждает защищенность инфраструктуры, но информационная система заказчика проходит собственную аттестацию поверх этого слоя. В таком сценарии процесс движется намного быстрее, чем создание инфраструктуры под требования и переноса туда системы с нуля.
Отдельно стоит сказать про объекты КИИ. Закон диктует, чтобы для них контур оставался внутри собственного периметра компании, третьим лицам туда входа нет. Поэтому защищенное облако здесь не подходит по определению — оно аттестуется по приказам №21 и №117, а требования к КИИ (№239) в этот периметр не входят. Для таких задач нужен частный контур, спроектированный под конкретного заказчика, с СЗИ и СКЗИ в комплекте.
Сегодня практически невозможно найти компанию, которая не подпадает ни под одно нормативное требование. Кто-то обрабатывает персональные данные, кто-то работает с государственными системами, кто-то оказывается субъектом КИИ.
Государству и регулятору действительно важно, чтобы данные были защищены, даже если самой компании кажется, что терять нечего. За нарушением идут проверки, штрафы, отзыв лицензий, приостановка деятельности — и это бьет по бизнесу так же ощутимо, как по репутации и отношениям с клиентами и партнерами.
Не каждая компания способна построить защиту с нуля — это дорого, долго и требует специалистов, которых на рынке и так не хватает. Поэтому логичным решением становится обращение к облачному провайдеру, который уже прошел этот путь сам.
Вопрос в том, как выбрать правильного — того, кто действительно разбирается в информационной безопасности. Есть простой способ это проверить: посмотреть на лицензии. У провайдера должна быть лицензия ФСТЭК России на деятельность по технической защите конфиденциальной информации и лицензия ФСБ России на работы с использованием средств криптографической защиты информации. Без этих двух документов говорить про информационную безопасность не имеет смысла.
Приказ №117 жестче своего предшественника, и в моменте это неудобно для бизнеса. Но именно эта жесткость снижает риск оказаться в ситуации, где о защите вспоминают только после инцидента.
