Приказ № 21 гуглят с одним вопросом: он еще в силе или уже нет. На 24 августа 2026 года приказ действует, силу не утратил и отменен не был. Взамен подготовлен проект, и в нем впервые появились требования к тем, кто пишет софт.
Статус документа: это проект, приказ № 21 пока действует
Проект опубликован на regulation.gov.ru под идентификатором 169583, общественное обсуждение шло до 8 августа 2026 года. Основание: часть 4 статьи 19 Федерального закона от 27.07.2006 № 152-ФЗ.
Статус проверяли 24 августа 2026 года: сведений о подписании и регистрации в Минюсте нет. Часть источников уже пишет «ФСТЭК утвердила новый приказ», это неточность.
Прямые ответы. Действует ли приказ ФСТЭК № 21 сейчас: да. Утратил ли силу: нет. Отменен ли: нет, отмена записана в проекте.
Пункт 2 проекта признает утратившими силу три документа: приказ ФСТЭК от 18.02.2013 № 21 (Минюст 14.05.2013, рег. № 28375), пункт 1 приложения к приказу от 23.03.2017 № 49 и приказ от 14.05.2020 № 68. Пункт 3 назначает дату вступления в силу: 1 сентября 2026 года.
Дата 1 сентября заявлена в тексте проекта, а не установлена действующим актом. Пока документ не подписан, срок может сдвинуться.
Что отменяется и что остается на месте
Уровни защищенности никуда не деваются. Пункт 1 проекта определяет меры для каждого из четырех уровней, установленных постановлением Правительства от 01.11.2012 № 1119. Менять классификацию из-за нового приказа не придется.
Три зоны выведены за рамки документа: государственные системы живут по приказу ФСТЭК от 11.04.2025 № 117 (пункт 3), значимые объекты критической инфраструктуры по 187-ФЗ (пункт 4), криптография остается у ФСБ (пункт 5).
Для компании с сайтом, CRM и самописным сервисом новый документ станет чек-листом по технической части вместо приказа, по которому она жила с 2013 года.
Смысл изменения: от разового списка мер к оценке зрелости
Приказ № 21 описывал защиту как набор мер, который реализуют один раз. Проект строит требования вокруг регулярной оценки того, работают ли меры. Разница видна по шести позициям.
| Что именно | Приказ № 21 от 18.02.2013 | Проект приказа, заявлено с 01.09.2026 |
|---|---|---|
| Модель угроз | Обязательный документ на входе | Решение принимает оператор, пункт 7 |
| Оценка эффективности мер | Разовая при вводе системы | Показатель зрелости Узи, пункт 9 |
| Периодичность проверки | Отдельным показателем не задана | Перед началом обработки, раз в 3 года, после инцидента, пункт 9 |
| Подрядчик, обрабатывающий данные | Требований к его зрелости нет | Оператор задает ему значение Узи, пункт 10 |
| Новые технологии без готовых мер | Не описаны | Разрабатываются компенсирующие меры, пункт 17 |
| Средства защиты | По установленному перечню | Только там, где нужны против актуальных угроз, пункт 8 |
Пункт 7 стоит прочитать дважды: угрозы оператор определяет сам и сам решает, нужна ли модель угроз как документ. Бумаги меньше, ответственности за свое решение больше.
Показатель уровня зрелости Узи: кто считает и как часто
Пункт 9 вводит оценку эффективности реализованных мер. Проводит ее оператор сам либо организация с лицензией на техническую защиту конфиденциальной информации. По итогам определяется показатель Узи.
Периодичность задана тремя точками: перед началом обработки, не реже одного раза в 3 года и после каждого компьютерного инцидента у оператора.
Третье условие меняет работу сильнее двух первых: нужен журнал инцидентов и ответственный за запуск процедуры. Если их нет, начните с пошагового чек-листа проверки обработки персональных данных.
Подрядчик на разработке: ему тоже задают значение Узи
Пункт 10 переносит требование на цепочку: оператор задает значение Узи тому, кто обрабатывает данные по его поручению. Оценка идет по той же схеме, только инцидент считается уже на стороне подрядчика.
Студия с копией базы, фрилансер с доступом к продовому серверу, агентство на поддержке, сервис рассылок с выгрузкой контактов: все попадают под этот пункт.
Правится это в двух местах: в поручении на обработку добавляется требование к Узи и периодичность подтверждения, в договоре обязанность сообщать об инцидентах у себя. Заодно сократите объем передаваемого наружу, это проще, чем контролировать чужую зрелость; технику разбирали в статье об обезличивании персональных данных по 152-ФЗ.
Двадцать одно направление пункта 11: шесть из них про ваш код
Пункт 11 перечисляет двадцать одно направление, которые реализует оператор.
Касается разработки и подрядчика напрямую: разработка безопасного программного обеспечения, контроль конфигураций, управление уязвимостями и обновлениями, защита при взаимодействии с подрядными организациями, защита при использовании искусственного интеллекта, обучение пользователей.
Остальные четырнадцать направлений закрывают инфраструктуру и наблюдение: оценка угроз, права на данные, конечные и мобильные устройства, удаленный доступ, физическая защита, мониторинг, работа при нештатных ситуациях, контроль уровня защищенности и взаимодействие с ГосСОПКА.
Строки «защита информации при использовании искусственного интеллекта» в приказе № 21 нет. Если менеджер пересылает обращения в чат-бот, а разработчик отдает выгрузку в языковую модель, направление про вас. Как выглядит утечка через такой канал, разбирали в статье про персональные данные в ИИ-канале.
Семнадцать мер пункта 12: веб, API, почта, контейнеры
Пункт 12 задает семнадцать групп мер внутри самой системы. Пять описывают то, из чего собран типовой самописный сервис: веб-технологии, программные интерфейсы взаимодействия приложений, сервисы электронной почты, контейнерные среды и их оркестрация, виртуализация и облака. Остальные двенадцать закрывают периметр и доступ: идентификация, права, журналы событий, антивирус, межсетевое экранирование, обнаружение вторжений, устройства и каналы связи.
Раньше самописный сервис проходил по общим формулировкам, теперь у него свои строки.
Состав мер оператор закрепляет в политике обработки персональных данных. Политика перестает быть декларацией на сайте: расхождение между ее текстом и тем, что включено на сервере, становится видимым дефектом.
Классы средств защиты и уровни доверия по пункту 16
Пункт 16 связывает уровень защищенности с требованиями к средствам защиты. Уровни доверия определяются по приказу ФСТЭК от 02.06.2020 № 76.
Что означает каждое из двух чисел в сертификате, какая пара нужна под ваш уровень защищенности и обязаны ли вы вообще покупать сертифицированное средство, разобрано отдельно: классы средств защиты информации и уровни доверия.
| Уровень защищенности | Класс средства защиты | Уровень доверия |
|---|---|---|
| УЗ-1 | Не ниже 4 класса | Не ниже 4 уровня |
| УЗ-2 | Не ниже 5 класса | Не ниже 5 уровня |
| УЗ-3 | Шестой класс | Шестой уровень |
| УЗ-4 | Шестой класс | Шестой уровень |
Большинство коммерческих систем с данными сотрудников и клиентов попадает в УЗ-3 и УЗ-4, где требования к классу средств самые мягкие. Свой уровень стоит проверить заранее: от него зависит список закупок.
Как выбирают меры: три шага и компенсирующие меры
Пункт 13 описывает выбор в три шага: базовые меры для уровня защищенности, адаптация под архитектуру, верификация с учетом угроз. Если меру реализовать невозможно или невыгодно, пункт 14 разрешает компенсирующие меры с обоснованием, а пункт 17 распространяет тот же механизм на новые технологии.
Что нашли, когда разобрали свой периметр по этому списку
Мы прогнали собственный контур по пунктам 11 и 12. Лицензии и статуса аудитора у нас нет: считала компания, которая пишет код и держит заявки клиентов.
Инвентаризация, замер 21 августа 2026 года. В каталоге развертывания 16 скриптов обращались к полям заявки, под контролем версий был 1 из 16. За 31 день каталог вырос до 78 файлов, в git попали 8. Рядом лежала выгрузка на 51 349 байт: 45 заявок с 15 июля по 19 августа 2026 года, с именем, почтой и контактом, правила исключения под нее не было. Тут же нашлось сохраненное письмо в формате .eml. Закрыли правилами для каталога выгрузок, дампов и писем. Разбор с командами лежит в статье про персональные данные в рабочих копиях.
Открытый пункт говорим вслух. Срок хранения этих 45 заявок у нас не задан до сих пор. Пункт 11 требует контроля уровня защищенности, и здесь мы не дотягиваем.
Аудит скриптов, замер 21 августа 2026 года. В репозитории оказалось 64 файла на Python и 12 462 строки за 90 дней. Тестов было 2, разбор аргументов командной строки присутствовал в 11 файлах из 64, в сеть собственным кодом ходили 43 файла. Еще 11 файлов не упоминались ни в одном документе. Скрипт, о котором никто не знает, не проходит ни разработку безопасного ПО из пункта 11, ни проверку кода из пункта 15.
Разбор ИИ-канала, замер 20 августа 2026 года. Три канала: письмо менеджеру, база заявок (36 записей на тот момент, к 19 августа стало 45) и журналы ошибок. Течь оказалась в почте, а журналы, на которые подозрение падает первым, были чистыми.
Про автоматику отдельно. Наш движок маскирования на замере 20 августа 2026 года дал покрытие 92,5 % на 4585 размеченных сущностях: пропущено 344, ложных срабатываний 301. Это результат на нашей выборке, и рядом обязательна вторая цифра: 287 пропусков из 344 приходятся на ФИО, адреса и названия организаций. Полноту автоматического обнаружения мы не обещаем и пишем это в договор. Автоматика тут вспомогательный слой, риск закрывают регламент, документы и внедренное маскирование.
Что успеть до 1 сентября своими силами
Пять шагов, каждый на рабочий день, без лицензии.
- Посчитать места, где лежат контакты
Найти в каталогах разработки файлы и скрипты, которые читают поля заявки, и сверить со списком под контролем версий. На выходе число, а не ощущение.
- Закрыть выгрузки и письма от репозитория
Добавить правила исключения для каталога выгрузок, файлов дампа и сохраненных писем. Проверить командой, что правило срабатывает на конкретном пути.
- Назначить срок хранения заявок
Записать срок, назначить точку удаления, убедиться, что удаление происходит. Бессрочное хранение растет само: у нас заявок стало 45 вместо 36.
- Дописать поручение подрядчику
Внести в договор требование к значению Узи по пункту 10 проекта и обязанность уведомлять вас об инцидентах на его стороне.
- Сверить политику обработки с реальностью
Открыть политику на сайте и напротив каждой заявленной меры написать, где она включена. Пункт 12 требует закреплять состав мер именно здесь.
Ни один шаг не зависит от судьбы проекта: все пять полезны и при действующем приказе № 21. Если данные разъехались по скриптам и внешним сервисам, это чинится настройкой интеграций и автоматизацией выгрузок.
Границы: чего мы не делаем
Лицензии ФСТЭК на техническую защиту конфиденциальной информации у eq.team нет, а пункт 6 требует ее для работ по обеспечению безопасности персональных данных. Аттестацию мы не проводим, систему защиты как лицензиат не строим, заключение о соответствии 152-ФЗ не выдаем. Криптография по пункту 5 относится к зоне ФСБ.
Наша зона: инвентаризация систем и каналов, где лежат персональные данные, маскирование в интеграциях и в ИИ-канале, реестр обработки, техника под пункты 11 и 12. Оценку Узи подписывает оператор или лицензиат, мы приводим технику в состояние, в котором ее не стыдно проходить. Цену плохого сценария разбирали в обзоре штрафов за утечку персональных данных.
Разберем техническую часть под пункты 11 и 12 проекта
Считаем места с персональными данными в разработке, разбираем API, почту и выгрузки, чиним поручение подрядчику. Ставка 2 500 ₽/ч, оплата по факту, без аванса. Пакет guard-v1: разбор ИИ-канала по выборке из 200 реальных текстов, 10 рабочих дней, 49 000 ₽, пресейл-прогон бесплатный.
Пришлем чек-лист по пунктам 11 и 12
Оставьте контакт: отправим список из 21 направления и 17 групп мер с пометками, что делается своими руками.
Частые вопросы
Действует ли приказ ФСТЭК № 21 сейчас
Да. На 24 августа 2026 года приказ от 18.02.2013 № 21 действует, силу не утратил и отменен не был. Отмена записана в пункте 2 проекта, но проект на эту дату не подписан и в Минюсте не зарегистрирован.
Отменят ли уровни защищенности вместе с приказом
Нет. Пункт 1 проекта сохраняет четыре уровня защищенности по постановлению от 01.11.2012 № 1119. Меняется набор мер, плюс появляется регулярная оценка эффективности по пункту 9.
Нужна ли модель угроз по новому документу
По пункту 7 решение о необходимости разработки модели угроз принимает сам оператор, а угрозы он определяет с учетом архитектуры и технологий. Документ перестает быть безусловно обязательным, обоснование остается на вас.
Что делать, если подрядчик не считал Узи
Пункт 10 возлагает установку требования на оператора, то есть на вас. Внести в поручение значение показателя, зафиксировать периодичность подтверждения и добавить обязанность уведомлять вас об инцидентах у себя.
Успеем ли до 1 сентября
Дата 1 сентября 2026 года заявлена в пункте 3 проекта, а не установлена действующим актом, поэтому срок может сдвинуться. Пять шагов из раздела выше занимают по рабочему дню и полезны при любом развитии событий.
