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

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

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

Защита станет непрерывным процессом.

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

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

Он должен характеризовать достаточность и эффективность реализованных мер.

Усилится контроль подрядчиков.

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

Регулирование охватит современную инфраструктуру.

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

ИИ выделен в самостоятельное направление защиты.

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

Выбор мер потребуется обосновывать.

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

Возрастёт значение доказательств.

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

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

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

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

Четыре уровня защищённости — первый, второй, третий и четвёртый — также сохраняются. Они устанавливаются постановлением Правительства РФ № 1119 в зависимости от типа актуальных угроз, категорий персональных данных, количества субъектов и иных условий.

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

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

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

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

Приказ № 21 был принят в 2013 году. За прошедшее время корпоративная инфраструктура радикально изменилась.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для государственных информационных систем и иных систем государственного сектора проект предусматривает применение постановления № 1119 и приказа ФСТЭК № 117. Если ИСПДн является значимым объектом критической информационной инфраструктуры, дополнительно применяются требования Федерального закона № 187-ФЗ и принятых на его основании актов.

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

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

Что принципиально изменится

1. Отказ от готовой таблицы мер

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

В проекте выбор мер предлагается проводить в три стадии.

Определение базовых мер

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

Адаптация к системе

Базовый набор сопоставляется с архитектурой, технологиями и особенностями функционирования конкретной ИСПДн.

Верификация против угроз

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

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

2. Показатель уровня зрелости Узи

Наиболее существенное нововведение проекта — показатель уровня зрелости Узи. Он должен характеризовать достаточность и эффективность реализованных мер.

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

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

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

3. Новая модель контроля подрядчиков

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

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

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

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

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

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

5. Инцидент запускает переоценку всей системы

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

6. Форма модели угроз становится гибче

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

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

7. Компенсирующие меры получают большее значение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Спорные и неясные положения проекта

Состав мер предлагается закреплять в политике

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

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

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

Не определена методика Узи

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

Взаимодействие с ГосСОПКА сформулировано широко

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

В тексте имеются технические несоответствия

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

Срок подготовки может оказаться коротким

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Критические

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

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

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

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

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

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

Окончательная методика Узи, формат раскрытия мер в политике и специальные механизмы взаимодействия с ГосСОПКА.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Нормативная основа

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

Проект нового приказа ФСТЭК России — карточка проекта нормативного акта и материалы общественного обсуждения.

Федеральный закон от 27 июля 2006 года № 152-ФЗ «О персональных данных» .

Постановление Правительства РФ от 1 ноября 2012 года № 1119 — требования к защите персональных данных и уровни защищённости.

Приказ ФСТЭК России от 18 февраля 2013 года № 21 — действующий порядок до вступления в силу нового акта.

Методический документ ФСТЭК России от 12 апреля 2026 года — подходы к процессам защиты и оценке зрелости.

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

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

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

Когда новые требования вступят в силу?

В тексте проекта указано 1 сентября 2026 года. Эта дата пока является предлагаемой и может измениться.

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

Нет. Уровни установлены постановлением Правительства РФ № 1119. Меняется порядок подбора, адаптации и обоснования мер.

Будет ли модель угроз обязательна?

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

Нужно ли всем получать лицензию ФСТЭК?

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

Придётся ли всем покупать сертифицированные средства?

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

Распространяются ли требования на малый бизнес?

Размер бизнеса не является общим основанием освобождения. Но сложность и состав мер должны соответствовать системе, объёму данных, уровню защищённости и угрозам.

Что такое Узи?

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

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

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

Относится ли использование публичной нейросети к сфере проекта?

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

Итоговый вывод

Проект нового приказа ФСТЭК означает переход от табличного соответствия к доказуемому управлению безопасностью персональных данных.

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

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

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

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

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

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

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

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