Документирование обезличивания

С 2025 года регулирование обезличивания ПДн в России перестало быть формальностью. Приказ РКН закрепил пять методов обезличивания; ст. 13.1 ФЗ-152 (введена ФЗ-233 от 08.08.2024) установила требования к самой процедуре; проверки по индикаторам риска теперь охватывают и IT-компании. Для технического директора, отвечающего за SaaS-архитектуру или ML-инфраструктуру, задача не только выбрать метод, но и правильно задокументировать каждый шаг — от модели угроз до журнала операций. В этом материале разобраны требования к документации, связь с уровнями защищённости по ПП РФ №1119 и Приказом ФСТЭК №21, типовые ошибки и сценарии проверки.

Что требует закон: какие документы нужны CTO?

Ст. 18.1 ФЗ-152 обязывает оператора принять меры для обеспечения соответствия обработки ПДн требованиям закона и зафиксировать их в локальных актах. Обезличивание — одна из таких мер. Это означает, что одного факта применения метода недостаточно: нужен документ, подтверждающий, что метод выбран осознанно, соответствует угрозам и применён к конкретному набору данных.

Ст. 13.1 ФЗ-152, введённая ФЗ-233 от 08.08.2024, отдельно регулирует обезличенные ПДн: они приобрели особый статус, а операции с ними должны соответствовать методам обезличивания, утверждённым РКН. Приказ РКН закрепил пять методов: введение идентификаторов, изменение состава и семантики, декомпозиция, перемешивание, обобщение и агрегация. Каждый метод имеет обязательные параметры применения — без их фиксации обезличивание юридически не состоялось.

Для CTO практически это выглядит так: перед запуском любого процесса, где ПДн обрабатываются в «анонимизированном» виде, необходимо подготовить три группы документов. Первая — организационные акты (регламент обезличивания, приказ о назначении ответственного). Вторая — технические спецификации (описание метода, параметры, алгоритм верификации результата). Третья — операционная документация (журнал операций обезличивания, протокол проверки обратимости).

Как уровень защищённости влияет на состав документации?

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

Приказ ФСТЭК №21 от 18.02.2013 задаёт базовый набор мер по группам (ИАФ, УПД, ОПС, ЗНИ, РСБ и другие). Группа РСБ — регистрация событий безопасности — прямо затрагивает журналирование операций обезличивания. При УЗ-1 и УЗ-2 фиксируются все события, связанные с обработкой ПДн, включая обезличивание; при УЗ-3 — только значимые события по согласованному перечню.

Для SaaS-продуктов с мультиарендной архитектурой уровень защищённости определяется по наиболее высокой категории данных среди всех арендаторов. Если хотя бы один клиент передаёт специальные категории ПДн (ст. 10 ФЗ-152) — система обязана соответствовать УЗ-3 минимум. Это влечёт расширенный состав документации и необходимость применять сертифицированные ФСТЭК средства защиты информации.

Как задокументировать обезличивание для ML: пошаговая логика

Обучение ML-моделей на персональных данных — один из самых частых поводов для вопроса об обезличивании. Позиция РКН: если модель способна восстановить исходные ПДн (прямо или через атаку реидентификации) — данные не считаются обезличенными. Это означает, что технический директор должен не только выбрать метод, но и задокументировать оценку рисков реидентификации.

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

Отдельного внимания требует вопрос логирования как ПДн. Технические журналы (логи серверов, API-трафик, события SIEM) нередко содержат IP-адреса, user-agent, cookie-идентификаторы — то есть сведения, позволяющие идентифицировать субъекта. РКН квалифицирует их как ПДн при наличии возможности сопоставления с иными данными. Это означает, что логи, используемые для обучения моделей или аналитики, также требуют документированного обезличивания перед передачей в ML-среду.

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

Облако в РФ, KII и трансграничные сервисы: где документирование становится критичным?

Требование локализации по ч. 5 ст. 18 ФЗ-152 означает, что запись, систематизация, накопление, хранение, уточнение и извлечение ПДн граждан России должны происходить в базах данных на территории РФ. Это не запрет на облако как таковое — это требование к месту первичного хранения. При использовании иностранных облачных сервисов (AWS, Azure, GCP) вопрос не в том, разрешено ли это принципиально, а в том, как задокументировать, что первичная запись происходит в российской инфраструктуре.

Документация в этом случае включает: схему потоков данных с явным указанием точек первичной записи (data flow diagram с отметками о юрисдикции), договор с российским облачным провайдером или собственным ЦОД, а также описание архитектурного решения, подтверждающего, что иностранный сервис получает данные только после локализации или исключительно обезличенные данные.

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

Как это работает на практике: три сценария для CTO

Сценарий 1. SaaS-продукт, мультиарендность, один клиент передаёт медданные. Технический директор определил УЗ-4 для всей платформы, опираясь на то, что большинство клиентов передаёт только контактные данные. Один арендатор — медицинская организация — передаёт диагнозы. Ситуация: специальные категории ПДн по ст. 10 ФЗ-152 требуют УЗ-3 минимум для всей системы. Документация обезличивания, составленная под УЗ-4, не охватывает требуемых мер. Исход при проверке: предписание об устранении, штраф по ч. 1 ст. 13.11, обязательная пересборка документации. Стратегия: при мультиарендности проводить инвентаризацию категорий ПДн по каждому арендатору ежегодно и фиксировать результат в реестре систем обработки.

Сценарий 2. ML-модель обучена на клиентских данных без документированного обезличивания. Компания использовала агрегированные выборки для обучения рекомендательной системы, считая их анонимными. Документации — ни регламента, ни журнала операций, ни протокола верификации — нет. РКН при внеплановой проверке (инициированной жалобой субъекта) запросил доказательства обезличивания. Доказательств нет. Исход: протокол по ч. 1 ст. 13.11 за отсутствие мер защиты, параллельно — вопрос о наличии правового основания для обработки. Стратегия: до запуска любого ML-пайплайна на реальных данных — регламент обезличивания, журнал операций и протокол верификации как обязательные артефакты DevSecOps.

Сценарий 3. Подрядчик-аналитик работает с обезличенными данными без договора-поручения. CTO передал датасет внешней DS-команде для построения модели оттока. Договор — обычный NDA без условий о ПДн. Впоследствии выяснилось, что подрядчик реидентифицировал часть записей для проверки качества модели. Ситуация: оператор несёт ответственность за действия подрядчика (принцип ВС РФ о субподрядной ответственности оператора). Исход: штраф по ч. 2 ст. 13.11 за обработку без надлежащего основания — от 300 000 до 700 000 ₽. Стратегия: договор-поручение с явным запретом реидентификации, техническими ограничениями на доступ к таблицам соответствия и обязательством немедленного уведомления оператора при обнаружении возможности реидентификации.

Кейс 1. IT-компания (Сибирский ФО, начало 2025 года), разрабатывающая аналитическую платформу для ритейла, прошла проверку РКН по индикатору риска (отсутствие обновлённого уведомления). В ходе проверки инспектор запросил документацию по обезличиванию данных для демо-среды. Регламент существовал в виде внутренней вики-страницы — без подписи, без утверждения приказом. Компания получила предписание об устранении и штраф в диапазоне нескольких десятков тысяч рублей по ч. 3 ст. 13.11 (непубликация политики содержала и раздел об обезличивании). После сопровождения DATUM был оформлен полный пакет ОРД, регламент утверждён приказом, журнал операций переведён в структурированный формат с хранением в SIEM. ⚠️ Конкретный номер дела и точная дата — менеджер уточняет при публикации.

Кейс 2. SaaS-провайдер (Северо-Западный ФО, осень 2025 года), предоставляющий HR-аналитику, использовал иностранный облачный сервис для первичной агрегации данных. После вступления в силу ужесточённых требований к локализации (ФЗ-233 от 08.08.2024, с 01.07.2025) технический директор провёл собственный аудит потоков данных и выявил, что первичная запись происходит на серверах за рубежом. Компания самостоятельно уведомила РКН об изменении архитектуры и подала обновлённое уведомление по ст. 22 ФЗ-152. Превентивная документация и добровольное уведомление позволили избежать штрафа по ч. 8 ст. 13.11 (от 1 000 000 до 6 000 000 ₽). ⚠️ Конкретный номер дела и точная дата — менеджер уточняет при публикации.

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

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

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

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

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

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

Прямого запрета на использование иностранных облачных сервисов в ФЗ-152 нет. Требование ч. 5 ст. 18 ФЗ-152 — первичные операции записи, систематизации, накопления, хранения, уточнения и извлечения ПДн граждан России должны происходить в базах данных на территории РФ. Иностранный сервис допустим для последующей обработки, аналитики или резервного копирования при условии, что первичная локализация подтверждена документально: схемой потоков данных, договором с российским провайдером и архитектурным описанием. Нарушение требования локализации грозит штрафом по ч. 8 ст. 13.11 КоАП — от 1 000 000 до 6 000 000 ₽.

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

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

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

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

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

Состав обязательных средств защиты информации определяется по Приказу ФСТЭК №21 в зависимости от уровня защищённости ИСПДн (УЗ-1..4 по ПП РФ №1119). Применение сертифицированных ФСТЭК СЗИ обязательно при УЗ-1 и УЗ-2; для УЗ-3 и УЗ-4 требования мягче, но базовый набор мер — антивирусная защита (АВЗ), управление доступом (УПД), регистрация событий (РСБ) — остаётся обязательным. Факт применения СЗИ и их соответствие требованиям фиксируются в плане защиты ИСПДн и подтверждаются сертификатами; при проверке ФСТЭК или РКН эти документы предъявляются в первую очередь.

Итог

Документирование обезличивания — не отдельная задача для юридического отдела, а часть технической архитектуры: регламент, журнал операций и протокол верификации должны создаваться параллельно с разработкой пайплайна. Уровень защищённости по ПП РФ №1119, требования Приказа ФСТЭК №21 и методы обезличивания, утверждённые РКН, задают рамку — но конкретный состав документов определяется архитектурой конкретной системы. Отсутствие любого из ключевых документов при проверке РКН создаёт основание для штрафа от 150 000 ₽ по ч. 1 ст. 13.11 КоАП, а в случае нарушения локализации — до 6 000 000 ₽ по ч. 8.

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