Проект нового приказа ФСТЭК по ИСПДн: от перечня мер к управляемой защите

Действующий приказ № 21 -не только «таблица с галочками»

Сначала важная оговорка. Было бы неверно представлять действующий приказ ФСТЭК России № 21 исключительно как устаревший перечень технических средств.

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

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

Сам приказ № 21 допускает адаптацию, дополнительные и компенсирующие меры. Проблема не в полном отсутствии гибкости, а в том, что основной единицей регулирования остаётся отдельная мера применительно к конкретной ИСПДн.

Новый проект меняет масштаб рассмотрения.

Что предлагает проект

Проект сохраняет связь с уровнями защищённости, установленными постановлением Правительства РФ № 1119, но перестраивает саму систему требований.

В пункте 11 перечислено 21 направление деятельности:

1. выявление и оценка угроз;
2. контроль конфигураций;
3. управление уязвимостями;
4. управление обновлениями;
5. защита информации при её обработке, хранении и обращении;
6. защита конечных устройств;
7. защита мобильных устройств;
8. защита при удалённом доступе;
9. защита при беспроводном доступе;
10. защита при предоставлении расширенного доступа к программам и данным;
11. мониторинг информационной безопасности;
12. разработка безопасного программного обеспечения;
13. физическая защита;
14. непрерывность функционирования;
15. повышение знаний и информированности пользователей;
16. защита при взаимодействии с подрядчиками;
17. защита от атак, направленных на отказ в обслуживании;
18. защита при использовании искусственного интеллекта;
19. реализация мер безопасности персональных данных;
20. контроль уровня защищённости;
21. непрерывное взаимодействие с ГосСОПКА.

Отдельно пункт 12 определяет классы технических мер: идентификацию и аутентификацию, управление доступом, регистрацию событий, защиту облаков и виртуализации, контейнеров, электронной почты, веб-технологий, API, конечных и мобильных устройств, IoT, беспроводных точек доступа, антивирусную защиту, обнаружение вторжений, сегментацию, межсетевое экранирование, защиту от DDoS и защиту сетевого взаимодействия.

Таким образом, в проекте просматриваются два взаимосвязанных уровня:

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

Сам перечень конкретных базовых мер для каждого уровня защищённости в проект приказа не включён. Предполагается, что их состав и содержание будут определяться с использованием методических документов ФСТЭК, а оператор будет адаптировать базовый набор к архитектуре ИСПДн, технологиям, угрозам и возможностям нарушителя.

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

Почему сходство с приказом № 117 неслучайно

Перечень из 21 направления почти дословно воспроизводит пункт 34 приказа № 117.

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

Например, управление уязвимостями -это не просто наличие сканера. Методический документ ФСТЭК от 12 апреля 2026 года требует определять участников, последовательность операций, входные и выходные данные, сроки, порядок приоритизации, устранения, контроля и взаимодействия подразделений.

В приказе № 117 эта деятельность включена в общий управленческий цикл:

планирование → проведение мероприятий и принятие мер → оценка состояния защиты → совершенствование.

Проект по ИСПДн не воспроизводит весь этот цикл дословно, но использует ту же систему направлений и связывает оценку эффективности с показателем уровня зрелости. Поэтому его трудно рассматривать как простое обновление таблицы мер из приказа № 21.

Речь идёт о движении к общей архитектуре регулирования, в которой:

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

Оценка зрелости: общий вектор, но три разных показателя

Именно здесь особенно важно не смешивать терминологию.

Приказ № 117 устанавливает два самостоятельных показателя:

Показатель                               Что характеризует                                             Периодичность по № 117

Кзи                             Текущее состояние защиты информации               Не реже одного раза в шесть                                                              от базового уровня угроз                                                    месяцев  

Пзи                                       Достаточность и эффективность                          Не реже одного раза
                                                проведения мероприятий                                               в два года                                                                                    по защите информации

 Проект по ИСПДн вводит другой показатель -Узи. Он должен характеризовать достаточность и эффективность реализованных мер по обеспечению безопасности персональных данных. Оценку предлагается проводить:

• перед началом обработки персональных данных;
• далее не реже одного раза в три года;
• после компьютерного инцидента, произошедшего у оператора.

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

По назначению Узи ближе к Пзи, но считать их одним показателем нельзя.

Различаются как минимум:

• объект оценки: проведение мероприятий в № 117 и реализованные меры в проекте по ИСПДн;
• периодичность;
• события, запускающие оценку;
• наличие отдельного показателя текущей защищённости;
• порядок отчётности;
• нормативно установленные последствия неудовлетворительного результата.

В № 117 Кзи и Пзи образуют двухконтурную модель. Один показатель описывает текущее состояние защиты, другой -зрелость деятельности. Результаты направляются во ФСТЭК, а при отклонениях предусматриваются информирование руководителя и план совершенствования.

В проекте по ИСПДн отдельного аналога Кзи нет. Узи остаётся единственным интегральным показателем, а полноценный управленческий контур по результатам оценки пока не раскрыт.

Связь между подходами всё же существует. Опубликованный ФСТЭК проект методики оценки уровня зрелости предполагается применять в том числе операторами ИСПДн и подрядными организациями. Но до утверждения методики и окончательной редакции приказа нельзя утверждать, что Узи будет рассчитываться по тем же правилам, что и Пзи.

Есть и терминологическая проблема: обозначение Узи слишком легко спутать с уровнем защищённости персональных данных по постановлению № 1119. В одном документе могут одновременно использоваться первый, второй, третий или четвёртый уровень защищённости и показатель уровня зрелости Узи. Для практического применения эти понятия придётся очень чётко развести.

Что означает процессный подход на практике

Процесс начинается не с вопроса «какое средство защиты установлено», а с описания управляемой деятельности.

Для каждого направления необходимо определить:

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

Отсюда появляется связанная модель:

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

Это не означает, что каждую организацию заставят внедрить отдельную тяжёлую систему управления. Процессы могут поддерживаться разными инструментами — от реестров и тикет-систем до CMDB, SIEM, VM, GRC и специализированных платформ. Важен не класс продукта сам по себе, а воспроизводимость деятельности и возможность подтвердить её результат.

Разница особенно хорошо видна на практических примерах.

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

Допустим, сканер обнаружил критическую уязвимость на сервере кадровой ИСПДн.

При объектно-техническом подходе результатом может стать отчёт сканера и отметка о том, что контроль защищённости проводится.

В процессной модели должна отработать вся цепочка:

1. Результат связывается с конкретным активом и ИСПДн.
2. Определяется применимость уязвимости с учётом версии ПО и конфигурации.
3. Учитываются критичность актива, обрабатываемые категории ПДн и доступность системы извне.
4. Назначается владелец устранения.
5. Устанавливается срок с учётом критичности и риска.
6. Создаётся и контролируется задача.
7. При невозможности исправления оформляется исключение или компенсирующая мера.
8. После устранения проводится повторная проверка.
9. Результат сохраняется как доказательство.
10. Данные попадают в метрики и оценку зрелости.

Методический документ ФСТЭК по приказу № 117 требует для управления уязвимостями описывать исполнителей операций, продолжительность, входные и выходные данные и схему взаимодействия подразделений. В качестве усиления предусматривается применение систем управления уязвимостями, TI-платформ, CMDB, результатов мониторинга, управления обновлениями и конфигурациями. Доступна также читаемая HTML-версия документа.

Для такого процесса могут использоваться разные классы метрик:

• охват: доля активов ИСПДн, проверенных за установленный период;
• результативность: доля подтверждённых критических уязвимостей, которые устранены;
• оперативность: медианное время устранения и количество просроченных задач;
• качество: доля закрытий, подтверждённых повторным сканированием;
• устойчивость: количество повторно возникающих уязвимостей;
• влияние: число инцидентов, связанных с ранее известными, но не устранёнными уязвимостями.

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

Пример 2. Обработчик ПДн или облачный подрядчик

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

Обычная практика нередко заканчивается договорным пунктом «обеспечить безопасность персональных данных» и однократным запросом сертификатов или анкет.

Процессная модель предполагает:

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

Полезными метриками здесь могут быть:

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

В результате подрядчик перестаёт быть строкой в реестре договоров и становится управляемым элементом системы защиты.

Пример 3. Инцидент как обратная связь для всей системы

Предположим, DLP обнаружила выгрузку работником клиентской базы, а SIEM зафиксировала нетипичную активность его учётной записи.

Если рассматривать инцидент изолированно, служба ИБ расследует действия пользователя, оформляет отчёт и закрывает событие.

При полноценном процессном подходе дополнительно проверяются:

• корректность предоставленных прав;
• актуальность роли работника;
• наличие избыточных привилегий;
• достаточность журналирования;
• качество правил DLP и мониторинга;
• работа процесса пересмотра доступов;
• осведомлённость работника;
• действия непосредственного руководителя;
• необходимость изменения модели угроз и оценки риска;
• наличие аналогичных недостатков в других ИСПДн.

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

Именно поэтому требование проекта оценивать Узи после инцидента выглядит логично: инцидент становится сигналом о возможной несостоятельности одной или нескольких частей системы защиты.

Однако текущая формулировка слишком широка. Она говорит о компьютерном инциденте, произошедшем «у оператора», но не устанавливает его связь с конкретной ИСПДн. Буквально причиной полной переоценки может стать любой инцидент в организации. В итоговом тексте желательно определить критерии релевантности и объём внеплановой оценки.

Пример 4. ИИ, API, контейнеры и жизненный цикл

Допустим, кадровое подразделение решает использовать внешний ИИ-сервис для анализа резюме, а интеграция выполняется через API из приложения, работающего в контейнерной среде.

Здесь нельзя закрыть требования одной настройкой межсетевого экрана. Необходимо последовательно установить:

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

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

Нельзя автоматически считать, что вся эта детализация уже стала обязательной для любой ИСПДн. Окончательная применимость будет зависеть от утверждённого приказа и методических документов. Но направление развития требований видно достаточно отчётливо.

Пункт 18 проекта дополнительно требует учитывать меры защиты на стадиях жизненного цикла ИСПДн. Для описанного сервиса это означает:

требования к защите → оценка угроз → проектирование → безопасная разработка → проверка компонентов → испытания → разрешение на ввод → мониторинг эксплуатации → контроль изменений → безопасный вывод из эксплуатации.

Почему это хорошее направление

Первое преимущество -постоянство.

Уязвимости, конфигурации, сотрудники, подрядчики и технологии меняются быстрее, чем пересматривается комплект документов. Защита, оценённая три года назад, ничего не говорит о текущей конфигурации облака, новом API или фактически выданных привилегиях.

Второе —распределение ответственности.

Управление уязвимостями нельзя полностью возложить на ИБ: исправления выполняет ИТ или разработка, приоритет определяет владелец системы, простой согласует бизнес, а риск принимает руководство. Аналогично процессы доступа, подрядчиков, обучения и реагирования проходят через несколько подразделений.

Третье —доказуемость.

Вместо утверждения «процесс выполняется» появляются связанные данные:

актив → требование → ответственный → операция → задача → срок → результат → доказательство → метрика.

Четвёртое —возможность совершенствования.

Инцидент, аудит, изменение архитектуры или ухудшение метрики становятся событиями, которые запускают пересмотр защиты, а не просто попадают в архив.

Эта логика давно применяется в международных подходах. ISO/IEC 27001:2022 строит систему менеджмента вокруг её установления, реализации, поддержания и постоянного улучшения. NIST Cybersecurity Framework 2.0 использует текущие и целевые профили и уровни от частичного до адаптивного управления, подчёркивая непрерывный характер управления киберриском.

Но показатель зрелости сам по себе ещё не гарантирует реальную безопасность

Зрелость полезна только тогда, когда она подтверждается данными.

NIST SP 800-55 различает несколько типов показателей:

1. реализация — что фактически внедрено;
2. результативность — работает ли это и достигается ли требуемый результат;
3. эффективность — насколько своевременно и рационально работает процесс;
4. влияние — как деятельность воздействует на риск, задачи организации и возможные потери.

Например:

• «сканер установлен» — факт реализации;
• «95% активов действительно проверяются» — охват;
• «критические уязвимости устраняются в установленный срок» — результативность и оперативность;
• «сократилось количество инцидентов из-за известных уязвимостей» — влияние.

Исследования также показывают ограничения моделей зрелости. Систематический обзор в Information & Computer Security отмечает большое количество моделей при недостатке их практической валидации. В обзоре IEEE Access выявлены десятки различающихся моделей, но не обнаружена единая универсальная конструкция, одинаково подходящая организациям разных типов и размеров.

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

Что в проекте требует уточнения

Направление я оцениваю положительно, но к опубликованной редакции остаются существенные вопросы.

1. Размещение состава мер в политике обработки ПДн

Пункт 12 предлагает устанавливать состав мер в политике в отношении обработки персональных данных.

При этом часть 2 статьи 18.1 закона № 152-ФЗ требует обеспечить неограниченный доступ к политике и сведениям о реализуемых требованиях к защите.

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

2. Любой компьютерный инцидент как триггер

Проект не связывает внеплановую оценку с соответствующей ИСПДн, обрабатываемыми персональными данными или отказом конкретного процесса.

Разумнее определить:

• критерии значимости и релевантности инцидента;
• связь с ИСПДн;
• процессы и меры, подлежащие переоценке;
• условия полной или частичной оценки Узи.

3. Непрерывное взаимодействие с ГосСОПКА

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

Для исключения расширительного толкования область применимости необходимо обозначить прямо.

4. Недостаточно раскрытый цикл улучшения

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

В приказе № 117 эти элементы присутствуют. Без них оценка Узи рискует остаться периодическим измерением без обязательного управленческого продолжения.

5. Зависимость от ещё не завершённой методики

Практическое значение Узи невозможно окончательно оценить без утверждённых критериев, весов, профилей, требований к доказательствам и правил оценки обработчиков.

Особенно важно понять, оценивает ли Узи только состояние реализованных мер либо фактически станет оценкой зрелости процессов, как это предполагает название показателя и общий методический вектор ФСТЭК.

6. Терминология

Обозначение Узи легко спутать с уровнем защищённости персональных данных. В окончательной редакции желательно терминологически развести зрелость деятельности, эффективность мер и установленный постановлением № 1119 уровень защищённости ИСПДн.

7. Технические и редакционные ошибки

В проекте есть ошибочные перекрёстные ссылки.

Например:

• пункт 15 говорит о мерах, указанных в пункте 8, хотя перечень мер находится в пункте 12;
• пункт 17 направляет к пункту 10 по вопросу компенсирующих мер, хотя соответствующие положения находятся в пункте 14.

Есть и отдельные грамматические пропуски. Вероятно, они будут исправлены по итогам обсуждения, но пока документ требует внимательной редакционной доработки.

8. Переходный период

Проект предусматривает вступление приказа в силу с 1 сентября 2026 года, тогда как общественное обсуждение завершается 8 августа.

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

Для настолько существенного изменения логики регулирования необходим реалистичный переходный период либо поэтапное введение отдельных требований.

Об этом мы говорили в Ханты-Мансийске

18 июня 2026 года на Международном IT-форуме в Ханты-Мансийске я выступал с докладом «Киберустойчивость: как перейти от формального исполнения регуляторных требований к управляемой защите».

Один из основных тезисов состоял именно в необходимости вести цельный процесс управления системой ИБ: связывать активы, требования, риски, ответственных, средства защиты, задачи, доказательства и метрики, а не автоматизировать отдельные несвязанные пункты НПА.

На том же круглом столе представитель Управления ФСТЭК России по УрФО рассказал о работе по гармонизации приказов № 117, № 21 и № 239.

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

Что можно делать уже сейчас

До утверждения документа не стоит формально перестраивать систему защиты под каждую проектную формулировку или закупать средства только из-за их появления в перечне.

Но подготовительную работу можно начинать:

1. Провести инвентаризацию ИСПДн, активов, технологий и обработчиков.
2. Сопоставить 21 направление проекта с фактически существующими процессами.
3. Определить владельцев и участников процессов, включая ИТ, HR, юристов, закупки и бизнес.
4. Установить, какие данные и доказательства уже формируются средствами защиты и информационными системами.
5. Выбрать несколько процессов для пилотного измерения — например, управление уязвимостями, доступами и подрядчиками.
6. Проверить использование облаков, API, контейнеров, IoT и ИИ, включая несанкционированные сервисы.
7. Выделить пробелы, которые требуют не покупки нового продукта, а изменения порядка взаимодействия и ответственности.
8. Подготовить замечания к проекту по инцидентам, политике, ГосСОПКА, методике зрелости, редакционным ошибкам и переходному периоду.

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

Вместо вывода

Главное изменение проекта — не отдельное появление ИИ, API или контейнеров. Это необходимые, но частные дополнения.

Гораздо важнее общий переход:

от перечня разрозненных мер — к системе процессов;
от наличия СЗИ — к доказуемой результативности;
от периодической проверки — к событийной переоценке;
от деклараций подрядчика — к контролю его зрелости;
от отчёта о состоянии — к циклу постоянного совершенствования.

До полноценного процессного регулирования по модели приказа № 117 проект пока не доходит. В нём не хватает явно закреплённого управленческого цикла, требований к корректирующим мероприятиям и окончательной методики оценки. Кроме того, Узи нельзя автоматически приравнивать ни к Кзи, ни к Пзи.

Но направление уже просматривается достаточно чётко: ФСТЭК постепенно формирует общую процессно-зрелостную архитектуру для разных контуров регулирования.

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