Новый приказ ФСТЭК по персональным данным 2026.

Главное за несколько минут

Ключевые выводы на 7 сентября 2026 года:

Статус приказа и статус методики различаются.

Проект замены приказа № 21 нельзя применять как действующий нормативный акт. Методика оценки зрелости от 7 августа 2026 года уже утверждена; её роль определяется вместе с применимыми требованиями ФСТЭК.

Оценка зрелости получила методическую основу.

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

Оценка угроз и проверка эффективности обязательны уже сейчас.

Пункты 3, 6 и 9 приказа № 21 предусматривают учёт актуальных угроз, оценку эффективности не реже одного раза в три года и адаптацию набора мер. Называть эти обязанности новыми неправильно.

Контроль обработчиков уже предусмотрен законом.

Часть 3 статьи 6 Закона № 152-ФЗ требует определить условия поручения, требования к защите, предоставление подтверждающих документов и уведомление оператора об установленных законом инцидентах. Проект дополнительно связывает контроль с показателем зрелости Узи.

В проекте прямо названы ИИ и современные технологии.

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

Проект предусматривает дополнительные основания оценки Узи.

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

Подготовку следует начинать с проверки фактической защиты.

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

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

Что именно предложила ФСТЭК

Разбирается проект приказа, подготовленный ФСТЭК России 24 июля 2026 года: «Об утверждении Состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных». Его положения рассматриваются в этой статье как предлагаемые изменения.

Правовая основа защиты сохраняется: статья 19 Федерального закона от 27 июля 2006 года № 152-ФЗ «О персональных данных» и постановление Правительства РФ от 1 ноября 2012 года № 1119. Четыре уровня защищённости устанавливаются постановлением № 1119; показатель зрелости их не заменяет.

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

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

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

Почему приказ № 21 решили заменить

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

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

Практическое значение изменений — возможность сопоставить требования с фактическими процессами организации: кто управляет доступом, как исправляются уязвимости, какие действия выполняют подрядчики и чем подтверждается результат контроля. Методика от 7 августа 2026 года даёт самостоятельный порядок оценки качества такой деятельности.

На кого распространятся новые требования

Проект адресован операторам и лицам, которые обрабатывают персональные данные по их поручению.

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

Кадровые и зарплатные системы, 1С, CRM и электронный документооборот.

Базы клиентов, заявителей, контрагентов и представителей юридических лиц.

Интернет-магазины, личные кабинеты, сайты с формами обратной связи и программы лояльности.

Мобильные приложения, системы видеонаблюдения, контроля доступа и записи звонков.

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

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

Работодатели

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

Для работодателей особое значение получат кадровые базы, удалённый доступ, личные устройства сотрудников, электронная почта, облачные офисные продукты и передача данных бухгалтерским, кадровым и ИТ-подрядчикам.

Интернет-магазины, маркетплейсы и цифровые сервисы

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

Медицинские организации

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

Банки, финансовые и страховые организации

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

ИТ-компании и разработчики

Для разработчиков, операторов облаков, центров обработки данных, CRM, сервисов рассылки, колл-центров и аналитических платформ проект создаёт двойной эффект. Они сами являются операторами данных своих работников и пользователей, а одновременно обрабатывают данные по поручению клиентов.

Государственный сектор и КИИ

Пункт 3 проекта отдельно отсылает государственные информационные системы, иные информационные системы государственных органов, государственных унитарных предприятий и государственных учреждений к постановлению № 1119 и приказу ФСТЭК России от 11 апреля 2025 года № 117. Его сферу действия необходимо определять самостоятельно; нельзя автоматически приравнивать к этим адресатам любое общество с государственным участием. Для ИСПДн, являющейся значимым объектом КИИ, пункт 4 проекта предусматривает учёт требований, принятых на основании Федерального закона от 26 июля 2017 года № 187-ФЗ, и постановления № 1119.

Использование криптографии

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

Что меняет проект и что уже предусмотрено действующими требованиями

1. Подбор мер: новая детализация при сохранении оценки угроз

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

В действующем приказе № 21 выбор мер также не ограничивается отметками в таблице. Адаптация и уточнение набора уже обязательны. Поэтому пересмотр защиты следует начинать с проверки корректности существующих решений, а не с вывода об их автоматической непригодности.

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

2. Методика оценки зрелости Узи уже утверждена

ФСТЭК России 7 августа 2026 года утвердила «Методику оценки уровня зрелости деятельности в области технической защиты информации в информационных системах и обеспечения безопасности значимых объектов критической информационной инфраструктуры Российской Федерации». Подпункт «д» пункта 4 прямо называет операторов ИСПДн, включая установление требований к зрелости подрядчиков в соответствии с нормативными правовыми актами ФСТЭК.

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

Рекомендуемые целевые значения по пункту 11 методики:

Уровень защищённости ИСПДн	Целевой показатель по каждому оцениваемому направлению
3-й и 4-й	Рекомендуется не ниже 1
2-й	Рекомендуется не ниже 2
1-й	Рекомендуется не ниже 3

Это именно рекомендации к целевым показателям каждого направления. Их нельзя описывать как автоматически установленные обязательные минимумы для всех операторов или как новые уровни защищённости. Целевые значения определяются оператором с учётом пункта 15 методики и применимого регулирования.

Оценка может быть внутренней или внешней. Для внешней оценки пункт 6 методики предусматривает привлечение организации с соответствующей лицензией. Методика не устанавливает универсальную обязанность приобретать отдельный «сертификат Узи».

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

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

Часть 3 статьи 6 Закона № 152-ФЗ уже требует включать в поручение на обработку перечни данных и операций, цели обработки, обязанности по конфиденциальности и безопасности, требования к защите, предоставление подтверждающих документов по запросу оператора и уведомление о предусмотренных законом инцидентах. Общая фраза «соблюдать законодательство о персональных данных» не заменяет эти условия.

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

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

Уведомления об инциденте: при выявлении факта неправомерной или случайной передачи, предоставления, распространения либо доступа к персональным данным, повлёкшего нарушение прав субъектов, часть 3.1 статьи 21 Закона № 152-ФЗ предусматривает уведомление Роскомнадзора в течение 24 часов и сообщение о результатах внутреннего расследования в течение 72 часов с момента выявления инцидента в предусмотренном законом порядке. Это не последовательные сроки «24 плюс 72». Срок первичного сообщения подрядчика следует согласовать так, чтобы оператор мог выполнить обе обязанности; например, в пределах нескольких часов.

4. Современная технологическая инфраструктура

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

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

5. Оценка после компьютерного инцидента

В пунктах 9 и 10 проекта компьютерный инцидент назван отдельным основанием оценки Узи у оператора или обработчика. Представлять этот проектируемый порядок как уже введённую всеобщую обязанность некорректно.

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

6. Форма документирования угроз

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

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

7. Компенсирующие меры предусмотрены и действующим приказом

Пункт 10 приказа № 21 уже допускает разработку компенсирующих мер при невозможности технической реализации отдельных выбранных мер, а также с учётом экономической целесообразности. Пункт 14 проекта сохраняет этот подход. Обоснование применения компенсирующих мер также требуется уже сейчас.

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

8. Безопасная разработка программного обеспечения

Для актуальных угроз первого и второго типов пункт 15 проекта предусматривает дополнительные меры: проверку программного обеспечения, включая код, на уязвимости и недекларированные возможности, а также применение программного обеспечения, разработанного с учётом мер безопасной разработки. В проекте приведена ссылка на ГОСТ Р 56939-2024.

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

9. Средства защиты и оценка соответствия

Пункт 8 проекта, как и пункт 4 приказа № 21, связывает применение средств, прошедших оценку соответствия, с необходимостью нейтрализации актуальных угроз. Пункт 16 проекта устанавливает требования к классам и уровням доверия при использовании сертифицированных средств. Дополнительные обязательные условия могут следовать из другого применимого регулирования.

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

Искусственный интеллект и персональные данные

По сравнению с приказом № 21 проект прямо выделяет защиту информации при использовании искусственного интеллекта как самостоятельное направление. Использование ИИ включено также в перечень направлений оценки по методике от 7 августа 2026 года.

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

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

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

Минимальный контур управления ИИ

Реестр официальных и самостоятельно используемых сотрудниками ИИ-систем.

Владелец каждого сценария и описание допустимой цели применения.

Перечень передаваемых данных и правовое основание обработки.

Место размещения инфраструктуры, порядок хранения запросов и ответов.

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

Управление доступом, обезличивание, минимизация и запрет передачи избыточных сведений.

Контроль входных и выходных данных, журналирование критичных операций и порядок реагирования на утечку.

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

Обязательно ли привлекать лицензиата ФСТЭК

Нет. Проект не требует от каждого оператора передавать всю работу внешней организации.

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

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

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

Правовой контур

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

Технический контур

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

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

Какие вопросы требуют проверки по окончательному акту

Состав мер в политике обработки данных

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

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

Порядок обязательного применения Узи

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

Взаимодействие с ГосСОПКА

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

Внутренние ссылки проекта

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

Указанная в проекте дата уже прошла

В пункте 3 проекта указано 1 сентября 2026 года. На 7 сентября 2026 года официально опубликованный акт о замене приказа № 21 в проверенных источниках не выявлен. Поэтому эту дату нельзя указывать как подтверждённый срок начала новых обязанностей. Для изменения действующего порядка нужны реквизиты принятого акта и проверка условий его вступления в силу.

Какие риски возникают для бизнеса

Проект приказа и методика зрелости сами по себе не устанавливают новые составы административных правонарушений или размеры штрафов. Ответственность определяется, в частности, статьёй 13.11 КоАП РФ, а её применение зависит от установленного состава нарушения.

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

Административные штрафы за нарушения обработки данных и неуведомление об инциденте.

Штрафы, зависящие от количества субъектов и идентификаторов, затронутых утечкой.

Оборотная ответственность при повторной утечке.

Требования субъектов о компенсации морального вреда и убытков.

Регрессные споры с подрядчиками и расторжение договоров.

Отказ крупных заказчиков от поставщика, не способного подтвердить зрелость защиты.

Остановка продукта, ограничения доступа к системам и репутационный ущерб.

Трудовая, корпоративная и в отдельных случаях уголовно-правовая оценка действий руководителей и сотрудников.

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

Что должен сделать генеральный директор

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

Назначить владельца проекта

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

Утвердить объём обследования

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

Получить карту критических разрывов

Разделить нарушения действующего закона, очевидные угрозы и меры, зависящие от финальной редакции.

Проверить готовность к инциденту

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

Установить порядок принятия риска

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

Что должна сделать юридическая служба

Юристам необходимо выйти за пределы проверки согласий и политики конфиденциальности.

Сопоставить цели и правовые основания обработки с фактическими процессами.

Проверить уведомление Роскомнадзора, категории субъектов и данных.

Пересмотреть поручения на обработку, трансграничную передачу, сроки хранения и уничтожения.

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

Разработать правила использования ИИ и передачи данных в облачные сервисы.

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

Определить применимые обязанности по взаимодействию с Роскомнадзором, ФСТЭК и ГосСОПКА и закрепить ответственных.

Что должны сделать ИТ и информационная безопасность

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

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

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

Облачные ресурсы, мобильные устройства, контейнеры, оркестраторы и программные интерфейсы.

Журналы событий, резервное копирование, восстановление и средства обнаружения атак.

Управление обновлениями, уязвимостями, конфигурациями и изменениями.

Критичные зависимости, точки передачи данных подрядчикам и используемые ИИ-компоненты.

Результат должен позволять сопоставить каждый риск с конкретной мерой и доказательством её работы.

Что должны изменить закупки и договорная работа

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

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

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

План подготовки бизнеса

Зафиксировать статус регулирования

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

Провести инвентаризацию

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

Перепроверить уровни защищённости

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

Актуализировать угрозы

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

Провести оценку разрывов

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

Провести пилотную оценку зрелости

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

Пересмотреть подрядчиков

Классифицировать их по критичности, провести углублённую проверку облачных провайдеров, кадровых сервисов, колл-центров, разработчиков и операторов ИИ.

Создать реестр ИИ

Выявить официальные и теневые сценарии использования и определить допустимость передачи персональных данных.

Проверить реагирование на инциденты

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

Актуализировать документы

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

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

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

Инвентаризация систем, данных, подрядчиков и ИИ-сервисов.

Проверка уведомления Роскомнадзора, целей и оснований обработки.

Определение уровней защищённости и актуализация угроз.

Устранение критических уязвимостей и ограничение избыточного доступа.

Многофакторная аутентификация для критичных и удалённых доступов.

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

Резервное копирование и практическая проверка восстановления.

Учения, обучение работников и сбор доказательств фактической работы мер.

Чего пока делать не следует

Объявлять, что новый приказ уже вступил в силу.

Отменять действующие документы по приказу № 21.

Закупать полный набор новых средств без анализа угроз и архитектуры.

Заказывать «обязательную сертификацию Узи» без проверки правового основания: утверждённая методика предусматривает оценку, а не универсальную обязанность получать такой сертификат.

Публиковать детальную архитектуру защиты в открытой политике.

Автоматически отказываться от действующей модели угроз.

Обещать гарантированное соответствие будущему приказу.

Как определить приоритет расходов

Критические

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

Обязательные сейчас

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

Подготовительные

Матрица зрелости, реестр ИИ, классификация подрядчиков, карта современных технологий и новые шаблоны доказательств.

Зависящие от финального текста

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

Проверочный список для руководителя

Организация находится в зоне повышенного риска, если хотя бы на несколько вопросов нет подтверждённого ответа.

Известны ли все информационные системы, где находятся персональные данные?

Совпадает ли реальная обработка с уведомлением Роскомнадзора?

Определён ли уровень защищённости каждой ИСПДн?

Актуальны ли угрозы и описание архитектуры?

Известны ли все внешние обработчики и субподрядчики?

Предусмотрено ли их уведомление об инциденте в течение нескольких часов?

Можно ли получить доказательства принятых подрядчиком мер?

Контролируются ли привилегированные учётные записи?

Есть ли реестр облачных и ИИ-сервисов?

Проверяются ли уязвимости, обновления и конфигурации?

Сохраняются ли журналы, достаточные для расследования?

Отделены ли резервные копии от основной среды?

Проводились ли практические учения по утечке?

Можно ли направить первичное уведомление в пределах 24 часов и результаты внутреннего расследования в пределах 72 часов при наличии оснований по части 3.1 статьи 21 Закона № 152-ФЗ?

Есть ли у руководства достоверная картина остаточных рисков?

Часто задаваемые вопросы

Новый приказ ФСТЭК уже вступил в силу?

При проверке на 7 сентября 2026 года официально опубликованный приказ о замене приказа № 21 в проверенных источниках не выявлен. Разбираемый документ от 24 июля 2026 года представлен как проект. Указание в нём даты 1 сентября само по себе не подтверждает вступления в силу.

Что изменилось после публикации статьи в июле?

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

Методика Узи отменила приказ № 21?

Нет. Методика определяет порядок оценки зрелости. Она не является приказом об отмене приказа № 21 и не вводит автоматически все положения проекта его замены. Конкретные обязанности определяются по действующим для системы нормативным актам.

Отменят ли четыре уровня защищённости?

Проект их не отменяет. Уровни установлены постановлением Правительства РФ № 1119. Зрелость деятельности по защите и уровень защищённости ИСПДн — разные показатели.

Какие значения зрелости предусмотрены для ИСПДн?

Пункт 11 методики от 7 августа 2026 года рекомендует целевое значение по каждому оцениваемому направлению не ниже 1 для ИСПДн 3-го и 4-го уровней защищённости, не ниже 2 для 2-го уровня и не ниже 3 для 1-го уровня. Эти рекомендации нельзя автоматически называть обязательными минимумами для всех операторов.

Оценка эффективности раз в три года — новое требование?

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

Можно ли отказаться от модели угроз?

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

Нужно ли всем получать лицензию или сертификат Узи?

Универсальной обязанности получать лицензию только из-за статуса оператора персональных данных нет. Методика допускает внутреннюю оценку и предусматривает требования к лицензии при внешней оценке. Всеобщая обязательная сертификация Узи в ней не установлена; специальные виды работ требуют отдельной проверки.

Придётся ли заменить всё ПО на сертифицированное?

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

Нужно ли проверять обработчиков до нового приказа?

Да. Часть 3 статьи 6 Закона № 152-ФЗ уже регулирует условия поручения, требования к защите, подтверждающие документы и уведомления об инцидентах. Проект дополнительно предусматривает требования к Узи и основания его оценки.

Распространяется ли регулирование на малый бизнес и ИИ-сервисы?

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

Как подготовить обоснованное решение

На 7 сентября 2026 года основное подтверждённое обновление — утверждённая 7 августа методика оценки зрелости. Она позволяет предметно оценивать качество процессов защиты и согласовывать требования к подрядчикам. Рассматриваемый текст замены приказа № 21 следует анализировать как проект, пока его принятие и вступление в силу не подтверждены надлежащими реквизитами.

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

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

Подготовить компанию к новым требованиям ФСТЭК

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

Обсудить задачу

Материал актуализирован 7 сентября 2026 года на основе доступных текстов действующих актов, проекта от 24 июля 2026 года и методики ФСТЭК от 7 августа 2026 года. Положения проекта изложены как предлагаемые изменения. Прямую актуальную карточку проекта на портале общественного обсуждения при проверке получить не удалось; отсутствие выявленной официальной публикации не является подтверждением отсутствия любых последующих процедурных действий. Применимость требований определяется для конкретной информационной системы. Материал не является индивидуальным юридическим заключением, публичной офертой или гарантией результата.

Новый приказ ФСТЭК по персональным данным 2026. Обзор проекта.