ФСТЭК: изменения 2026 – отмена Приказа №21 и новый приказ о персональных данных

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

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

Контекст реформы: почему регулятор отказывается от прежних правил

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

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

Фундаментальный сдвиг: отмена приложений и введение показателя «УЗИ»

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

Теперь документ опирается на логику, аналогичную 117-му приказу для государственных информационных систем. В нем зафиксированы лишь общие векторы работы, а итоговый комплект технических решений и глубина их настройки зависят от конкретной модели угроз компании, а также требований смежного законодательства – нормативных актов по критической информационной инфраструктуре (187-ФЗ), стандартов для ГИС и правил ФСБ России по применению криптографии.

Обязательный расчет уровня зрелости

Ключевым механизмом контроля становится показатель «Узи», определяющий реальную достаточность и применимость внедренных мер безопасности. Оценивать его операторы обязаны по следующему регламенту:

• стартовая оценка: строго до запуска процессов обработки информации;

• плановый аудит: не реже одного раза в три года;

• внеплановая проверка: сразу после каждого зафиксированного инцидента или утечки.

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

Новые технологические контуры: от контейнеров и API до искусственного интеллекта

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

1. Искусственный интеллект: прописаны отдельный блок правил и обязательные меры безопасности при обработке сведений с помощью нейросетей и алгоритмов машинного обучения.

2. Безопасная разработка ПО: процессы DevSecOps и регулярный анализ кода становятся обязательным условием для систем первого и второго уровней защищенности.

3. Контейнерные среды и оркестрация: вводятся требования по изоляции контейнеров, защите инфраструктуры Kubernetes и постоянному контролю целостности исполняемых образов.

4. Защита API: устанавливается автоматический контроль схем входящих и исходящих запросов с немедленной блокировкой любых отклонений.

5. Контроль подрядчиков: формализуются технические каналы доступа и условия работы внешних сервисных организаций и вендоров.

6. ГосСОПКА: закрепляется обязанность непрерывного технического взаимодействия с государственной системой обнаружения и ликвидации последствий компьютерных атак.

Перечень задач и механизмы защиты информационной инфраструктуры

Чтобы соответствовать обновленным правилам, операторам предстоит сформировать сквозной процесс безопасности, закрывающий следующие ключевые задачи:

• Постоянный мониторинг и выявление актуальных угроз;

• Систематическое управление уязвимостями, конфигурациями и установкой обновлений;

• Защита сведений при хранении, передаче и обработке;

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

• Организация непрерывного мониторинга событий ИБ и защита от DDoS-атак;

• Физическая безопасность оборудования и обеспечение отказоустойчивости при авариях;

• Повышение осведомленности пользователей и регулярное обучение персонала.

Для выполнения этих задач операторы могут применять широкий спектр технологий: системы идентификации и аутентификации (IAM/PAM), регистрацию событий (SIEM), средства защиты виртуализации и облаков, межсетевые экраны нового поколения (NGFW), WAF для защиты веб-сервисов и API, антивирусные комплексы, решения для обнаружения вторжений, а также зашифрованные каналы связи.

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

Что это означает для рынка и как бизнесу подготовиться к вступлению правил в силу

Планируемая дата вступления нового регламента в силу – 1 сентября 2026 года. Переход на риск-ориентированную модель кардинально изменит отечественный рынок средств защиты информации. Направления, которые раньше считались факультативными (сканирование контейнеров, проверка кода, глубокий анализ трафика API), становятся обязательным стандартом. Это даст мощный стимул отечественным разработчикам создавать комплексные платформы вместо точечных утилит.

Бизнесу предстоит не просто подкорректировать отдельные параметры, а фактически пересобрать всю архитектуру защиты. Чтобы подготовиться к изменениям без суеты, ИТ- и ИБ-департаментам стоит заранее выполнить пять шагов:

1. Пересмотреть модель угроз: переписать документ с учетом реального стека – микросервисов, API, облаков и внешних интеграций.

2. Внедрить анализ кода: интегрировать инструменты SAST/DAST в CI/CD-пайплайны разработки.

3. Защитить API и контейнеры: перенастроить WAF для фильтрации запросов к интерфейсам и внедрить сканеры образов контейнеров.

4. Разработать методику оценки «Узи»: заранее определить порядок расчета уровня зрелости и подготовить регламенты инцидентного реагирования.

5. Отладить интеграцию с ГосСОПКА: проверить каналы связи и техническую готовность к передаче карточек инцидентов.