Требования к системе защиты персональных данных: вердикт экспертов

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

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

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

Классификация ИСПДн: четыре уровня как регуляторный каркас

Постановление № 1119 устанавливает четыре уровня защищённости персональных данных: УЗ-1, УЗ-2, УЗ-3 и УЗ-4. Уровень определяют с учётом типа актуальных угроз, категории данных и количества субъектов, чьи данные обрабатываются в информационной системе.

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

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

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

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

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

В этой таблице намеренно нет упрощённой формулы вроде «специальные данные — значит УЗ-1». Один и тот же вид данных не позволяет определить уровень без анализа типа угроз и остальных условий. И наоборот: небольшое число субъектов не означает автоматического перехода к низшему уровню.

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

Архитектура мер по Приказу ФСТЭК № 21: от регламентов до технических средств

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

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

• УПД — управление доступом субъектов доступа к объектам доступа.
• РСБ — регистрация событий безопасности.
• АВЗ — антивирусная защита.
• ОЦЛ — обеспечение целостности информационной системы и информации.
• ОДТ — обеспечение доступности персональных данных.
• ЗТС — защита технических средств и информационных систем.
• ЗИС — защита информационной системы и её компонентов от атак, направленных на отказ в обслуживании.
• ЗСВ — защита среды виртуализации.
• ЗНИ — защита машинных носителей информации.
• ЗСИ — защита среды функционирования информационной системы.

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

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

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

Приказ № 21 задаёт группы мер и требования к их применению, а не список брендов, которые оператор обязан купить.

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

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

Пороговые значения и критерии: что означает число субъектов

Число субъектов — один из факторов классификации, а не самостоятельный переключатель между уровнями. В Постановлении № 1119 предусмотрены пороговые значения, но результат зависит от того, какие данные обрабатываются и какой тип угроз актуален. Поэтому утверждение, что все системы выше 100 000 субъектов попадают в определённые уровни, неверно без проверки остальных условий.

Для классификации последовательно отвечают на несколько вопросов:

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

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

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

4. Как устроена система? Состав компонентов, удалённый доступ, интеграции, среды разработки и эксплуатации требуют анализа при оценке угроз и выборе мер. Но сами по себе эти обстоятельства не подменяют установленную матрицу уровней.

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

Стандарты безопасности персональных данных 2025 года — это не одна универсальная таблица с готовым перечнем продуктов. Оператору приходится соотносить закон, Постановление № 1119, Приказ № 21 и требования, применимые к его отрасли и конкретной обработке. Например, финансовой организации могут одновременно предъявляться отдельные требования регулятора отрасли. Они не отменяют базовую обязанность разобраться с обработкой персональных данных, но и не должны смешиваться с общими правилами определения УЗ.

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

Регуляторные изменения 2026 года: оценка уровня зрелости

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

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

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

Смежные отраслевые требования тоже требуют аккуратного чтения. Банк России ужесточает требования к банковским приложениям и вводит обязательное возмещение украденных средств — это отдельный пласт регулирования для кредитно-финансовых организаций. Его нельзя автоматически переносить на всех операторов персональных данных или считать заменой требованиям ФЗ-152 и Приказа № 21.

Периодический аудит и контроль эффективности

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

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

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

Результат контроля полезен, если из него понятно, что делать дальше. Обычно проверяют:

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

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

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

Что система защиты требует от оператора

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

Затем оператор обосновывает уровень защищённости и актуальные угрозы, после чего выбирает применимые меры по Приказу № 21. В зависимости от ситуации это может включать:

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

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

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

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