Акт обезличивания: образец

С 01.09.2025 Роскомнадзор получил право проверять не только факт обезличивания, но и методологию: применённый метод должен соответствовать одному из пяти, установленных подзаконным актом регулятора. Для IT-команды это означает конкретное требование: каждая операция обезличивания — будь то подготовка датасета для ML-модели, передача данных в тестовую среду или архивирование — должна сопровождаться актом. Без него оператор не может доказать ни факт обезличивания, ни его корректность.

Что такое акт обезличивания и зачем он нужен CTO?

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

Акт обезличивания — не просто формальность для проверки РКН. Он решает три практические задачи для технической команды. Первое: снимает обязанность применять требования уровней защищённости УЗ-1..УЗ-4 (ПП РФ №1119) к обезличенному датасету — к нему ФЗ-152 формально не применяется. Второе: позволяет законно использовать данные для обучения ML-моделей без отдельного согласия субъектов. Третье: защищает оператора при инциденте: если утекли обезличенные данные, состав по ч. 12–14 ст. 13.11 КоАП (штраф 3–15 млн ₽) не применяется — при условии, что обезличивание действительно необратимо и задокументировано.

Какие методы обезличивания применяются и как отразить их в акте?

Приказ РКН устанавливает пять методов обезличивания. Выбор метода определяет структуру акта: в нём должны быть указаны именно те параметры, которые позволяют проверить корректность применения конкретного метода.

Введение идентификаторов — замена прямых идентификаторов (ФИО, СНИЛС, телефон) на псевдонимы или суррогатные ключи. В акте фиксируется: таблица соответствия хранится отдельно, доступ к ней ограничен, алгоритм генерации ключей. Это наиболее распространённый метод в SaaS-продуктах при передаче данных между микросервисами.

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

Декомпозиция — разбивка связанного набора данных на несколько несвязанных фрагментов, каждый из которых в отдельности не позволяет идентифицировать субъекта. В акте: схема декомпозиции, расположение фрагментов, правило их связывания (которое также должно храниться отдельно).

Перемешивание — перестановка значений атрибутов между записями так, что связь атрибут–субъект разрывается. В акте: алгоритм перемешивания, seed случайного числа (или описание его хранения), исходный и результирующий объём записей.

Обобщение или агрегация — замена точных значений диапазонами или групповыми характеристиками (например, точный возраст → возрастная группа; конкретный адрес → район). В акте: правила агрегации, пороговые значения, обеспечивающие k-анонимность.

Образец акта обезличивания: обязательные реквизиты

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

Отдельный вопрос — хранение акта. Акт является частью внутренней документации оператора по ст. 18.1 ФЗ-152 и должен храниться в течение срока, обеспечивающего возможность предъявить его при проверке. На практике — не менее трёх лет, поскольку именно этот срок давности установлен для административных правонарушений по ч. 1 ст. 4.5 КоАП применительно к ст. 13.11.

Для SaaS-продуктов с мультиарендной архитектурой акт должен однозначно идентифицировать, данные какого клиента (арендатора) обезличиваются. Если у оператора нет разграничения на уровне документации, инспектор РКН вправе квалифицировать всю обработку как единую — с соответствующим объёмом субъектов и повышенными требованиями к УЗ.

Как обезличивание связано с УЗ-1..УЗ-4 и Приказом ФСТЭК №21?

Уровень защищённости информационной системы определяется по ПП РФ №1119 на основе трёх факторов: категория ПДн (специальные, биометрические, общедоступные, иные), тип угроз (1–3) и количество субъектов (до/свыше 100 000). Обезличенные данные, для которых составлен корректный акт, выводятся из-под этой классификации.

Практическое значение для CTO: если в тестовой среде используются реальные клиентские данные без акта обезличивания, тестовая среда становится ИСПДн с теми же требованиями, что и продуктивная. Это означает обязанность применить меры защиты по Приказу ФСТЭК №21 (109 мер в 15 группах) и организовать контроль их выполнения. Стоимость соответствия тестовой среды требованиям УЗ-3 сопоставима со стоимостью самого продукта в небольшой компании.

При использовании облачной инфраструктуры — в том числе российских облаков — обязанность документировать обезличивание не снимается. Если SaaS-провайдер обрабатывает ПДн по поручению (ст. 6 ч. 3 ФЗ-152), договор поручения должен содержать требования к обезличиванию, а акты составляет лицо, осуществляющее обработку по поручению. Оператор несёт ответственность за соблюдение этих требований подрядчиком.

Как это применяется на практике

Кейс 1. IT-компания (Сибирский ФО, осень 2025) использовала продуктивные данные клиентов для обучения рекомендательной модели. Датасет содержал около 80 000 записей с e-mail и историей покупок. Акты обезличивания не составлялись, метод фактически соответствовал псевдонимизации, но ключ хранился в той же базе. При плановой проверке РКН инспектор квалифицировал датасет как ИСПДн без требуемых мер защиты. CTO инициировал внеплановый аудит, по итогам которого был составлен ретроспективный комплект актов, ключ вынесен в изолированное хранилище, а датасет повторно обезличен методом обобщения. Штраф был выписан по ч. 1 ст. 13.11 — в диапазоне до 300 000 ₽; в арбитражном суде размер снижен с учётом принятых мер.

Кейс 2. SaaS-провайдер (Центральный ФО, начало 2026) передавал обезличенные данные своих арендаторов в аналитическую подсистему. Договоры поручения обработки не содержали требований к методам обезличивания, акты не составлялись. После жалобы одного из арендаторов в РКН регулятор провёл внеплановую проверку. Поскольку акты отсутствовали, провайдер не смог доказать корректность обезличивания — и обработка была признана ведущейся без надлежащего правового основания. Компания подготовила пакет актов и регламент обезличивания в рамках срочного сопровождения; договоры поручения приведены в соответствие с требованиями ст. 6 ч. 3 ФЗ-152.

Услуги DATUM по теме

• Аудит соответствия 152-ФЗ — проверка документации обезличивания, УЗ и технических мер в 38 пунктах.
• DPIA (оценка воздействия) — идентификация рисков при обработке ПДн для ML и аналитических систем.
• Комплект ОРД под ключ — разработка регламента обезличивания, шаблонов актов, приказов и журналов.

Частые вопросы

1. Какой УЗ выбрать для SaaS?

УЗ определяется по ПП РФ №1119 на пересечении трёх факторов: категория ПДн, тип угроз и число субъектов. Для большинства B2B SaaS-продуктов, обрабатывающих контактные и платёжные данные менее 100 000 субъектов при угрозах 3-го типа, применяется УЗ-3. Если в системе хранятся специальные категории ПДн (здоровье, биометрия) или число субъектов превышает 100 000 — УЗ поднимается до УЗ-2 или УЗ-1. Точный расчёт требует анализа архитектуры системы и реального состава обрабатываемых данных.

2. Можно ли использовать иностранные облака?

С 01.07.2025 требования локализации по ч. 5 ст. 18 ФЗ-152 распространяются на первичный сбор, запись, систематизацию, накопление, хранение, уточнение и извлечение ПДн граждан РФ — все эти операции должны выполняться на серверах в РФ. Использование AWS, Azure или GCP для хранения российских ПДн без зеркалирования на российские серверы нарушает ч. 5 ст. 18. Штраф по ч. 8 ст. 13.11 КоАП — 1–6 млн ₽. Аналитические операции над уже обезличенными данными могут выполняться за рубежом, но акты обезличивания должны быть составлены до передачи.

3. Что такое обезличивание для ML?

Обезличивание для ML — это применение одного или нескольких методов из утверждённого регулятором перечня к датасету, используемому для обучения модели, с целью вывода этого датасета из-под режима персональных данных. На практике наиболее часто применяются обобщение (замена точных значений диапазонами) и введение идентификаторов (псевдонимизация). После обезличивания составляется акт, ключ деанонимизации хранится отдельно, и датасет перестаёт быть ИСПДн — соответственно, к нему не применяются требования УЗ и Приказа ФСТЭК №21. Это снимает значительную часть инфраструктурных ограничений при работе с данными в ML-пайплайне.

4. Кто оператор в мультиарендной SaaS?

В мультиарендной SaaS одновременно действуют два оператора: клиент-арендатор, определяющий цели и состав обработки ПДн своих пользователей, и SaaS-провайдер, осуществляющий обработку по поручению по ст. 6 ч. 3 ФЗ-152. Провайдер является лицом, осуществляющим обработку по поручению, и обязан соблюдать требования, установленные оператором-арендатором в договоре поручения. Если провайдер самостоятельно определяет цели обработки (например, для собственной аналитики), он становится самостоятельным оператором со всеми обязанностями по ст. 18.1, 19, 22 ФЗ-152.

5. Какие СЗИ обязательны?

Перечень обязательных средств защиты информации определяется уровнем защищённости системы. Приказ ФСТЭК №21 от 18.02.2013 устанавливает 15 групп мер (ИАФ, УПД, ОПС, ЗНИ, РСБ, АВЗ, СОВ, АНЗ, ОЦЛ, ОДТ, ЗСВ, ЗТС, ЗИС, УКФ, ОПО); состав базового набора зависит от УЗ. Для УЗ-3 обязательны, в частности: идентификация и аутентификация пользователей, управление доступом, антивирусная защита, регистрация событий безопасности (логирование). Использование несертифицированных СЗИ при обработке ПДн в государственных системах запрещено; для коммерческих операторов требование сертификации носит рекомендательный характер, однако наличие сертифицированных СЗИ учитывается при оценке выполнения мер защиты.

Итог

Акт обезличивания — ключевой документ, позволяющий IT-команде законно использовать данные для ML, тестовых сред и аналитики без применения полного объёма требований 152-ФЗ к ИСПДн. Отсутствие акта превращает любой датасет в ИСПДн со всеми вытекающими требованиями УЗ и Приказа ФСТЭК №21. Корректный акт содержит идентификацию набора данных, применённый метод из утверждённого перечня, параметры применения и подписи ответственных лиц.

DATUM сопровождает IT-компании и SaaS-провайдеров в разработке регламентов обезличивания, шаблонов актов и технической документации, необходимой для прохождения проверки РКН. Практика включает аудит существующих процессов обезличивания, оценку архитектуры ИСПДн с точки зрения требований УЗ-1..УЗ-4 и разработку пакета ОРД под конкретную систему.