Обезличивание персональных данных: как сделать и зачем

Обезличивание персональных данных: что это и кого касается

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

Тема стала заметнее в последние пару лет, потому что государство начало отдельно регулировать оборот уже обезличенных массивов - об этом дальше расскажу подробно, когда дойдем до поправок 2024 года. Но для владельца сайта или небольшой компании смысл проще: если данные обезличены правильно, требования 152-ФЗ к результату этой процедуры не применяются, и часть обязанностей - собирать согласия, следить за сроками хранения, уведомлять Роскомнадзор - для этого конкретного массива снимается.

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

Почему удаление ФИО - это не обезличивание

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

Персональные данные - это не только ФИО. Если в записи остаются телефон, email, адрес доставки, IP-адрес или история покупок, человека почти всегда можно опознать по совокупности этих признаков и без имени. Классический пример: отчет клиники без фамилий, но с датой рождения, почтовым индексом и диагнозом - реальный человек вычисляется за несколько минут сопоставлением с открытыми источниками. В мировой практике анализа данных это называют повторной идентификацией, и именно ее риск проверяющие оценивают в первую очередь, когда решают, действительно ли данные обезличены.

Вторая причина - таблица соответствия. Если где-то в компании хранится файл, который связывает удаленное ФИО с оставшимся идентификатором (например, порядковым номером клиента), связь формально не разорвана, а спрятана. Это называется псевдонимизацией, а не обезличиванием: тот, у кого есть доступ к таблице соответствия, восстанавливает личность человека за одно действие. Такой файл сам становится персональными данными с повышенными требованиями к защите, а вся база в целом продолжает подчиняться 152-ФЗ в полном объеме.

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

Данные, которые обезличивать не нужно: они и так не персональные

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

Разница важна практически. Если данные никогда не были персональными, оператору не нужно ничего обезличивать и документировать процедуру перехода - достаточно с самого начала не собирать лишние идентификаторы. А вот если система сначала собирает полный набор данных (например, IP-адрес, идентификатор браузера, точное время визита) и только потом усредняет их для отчета, то до момента усреднения это были персональные данные, и требования 152-ФЗ действовали все то время, пока такой набор существовал в детализированном виде - в том числе требования к основаниям обработки и срокам хранения этой промежуточной версии.

Методы обезличивания персональных данных: какие признает регулятор

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

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

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

Когда обезличивание снимает требования 152-ФЗ, а когда нет

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

Обезличивание снимает требования 152-ФЗ, если выполняются одновременно несколько условий:

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

Обезличивание не снимает требований закона, если:

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

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

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

Обезличенные данные и закон: что изменил 233-ФЗ

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

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

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

Для владельца небольшого сайта или регионального бизнеса участие в этой системе, как правило, не актуально - механизм рассчитан на операторов, которые накапливают действительно крупные массивы данных, и на случаи, когда передача обезличенных данных происходит по решению уполномоченных органов. Но знать о законе стоит по другой причине: он подтверждает, что регулятор относится к обезличиванию не как к формальной отписке, а как к процедуре с проверяемыми результатами, у которой появляется собственная инфраструктура. Использовать обезличивание как способ снять с себя часть обязанностей по 152-ФЗ и при этом делать это на глаз, без документированной методики, становится рискованнее год от года.

Где на сайте и в бизнес-процессах уместно обезличивание

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

Веб-аналитика и счетчики. IP-адрес - персональные данные, и передача полного IP в системы аналитики требует тех же оснований, что и любая другая обработка. Анонимизация последнего октета IP или использование соответствующих настроек счетчика - рабочий пример обобщения на практике; подробно о том, как это настроить в популярном счетчике, писали в материале про Яндекс.Метрику и анонимизацию IP по 152-ФЗ.

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

Архивы после достижения цели обработки. Когда цель обработки достигнута (например, заказ выполнен и гарантийный срок истек), закон требует уничтожить или обезличить данные, если для них не осталось другого законного основания хранить. Если статистика по заказам все еще нужна для отчетности, разумный вариант - не уничтожать записи целиком, а обезличить их и оставить в этом виде. Это же касается резервных копий: вопрос, что можно, а что нельзя хранить в бэкапах, разбирали отдельно в материале про хранение резервных копий персональных данных.

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

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

Типичные ошибки: когда обезличенные данные обезличенными не являются

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

• в массиве остался внутренний ID, который совпадает с ID в основной базе клиентов - связь восстанавливается одним запросом на соединение таблиц;
• обезличили основную таблицу, но забыли про логи веб-сервера или переписку в системе поддержки, где те же люди остались в открытом виде;
• заменили ФИО на код, но оставили в свободном текстовом поле комментарий менеджера с именем клиента;
• исходная и обезличенная версии базы хранятся в одном облачном хранилище с одинаковым доступом для сотрудников - разделения по факту нет;
• в данных остался редкий набор признаков (уникальная должность плюс город плюс возраст), которого достаточно для опознания человека без прямых идентификаторов;
• не задокументировано, каким методом и когда обезличивали конкретный массив - если статус данных понадобится подтвердить на проверке, подтверждать нечем.

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

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

1. Составить перечень массивов персональных данных на сайте и в CRM: клиентская база, лог заказов, база подписчиков рассылки, данные из форм обратной связи.
2. Для каждого массива определить срок и цель хранения - без этого невозможно понять, когда наступает момент обезличивать или уничтожать данные.
3. Выбрать метод обезличивания под конкретную задачу из таблицы выше, а не один универсальный на все случаи сразу.
4. Зафиксировать процедуру письменно: какой массив, каким методом, когда обезличен, кто отвечает за таблицы соответствия, если они временно нужны.
5. Проверить, что исходные данные после обезличивания действительно удалены из всех мест, включая резервные копии и логи, а не только из рабочей базы.

Решение о том, что конкретный массив действительно обезличен и требования 152-ФЗ к нему больше не относятся, не стоит принимать по умолчанию силами того же сотрудника, который делал выгрузку. Это управленческое решение с юридическими последствиями: если оператор ошибется и назовет обезличенным то, что таковым не является, отвечать придется как за обычные персональные данные, только с дополнительным отягчающим обстоятельством - компания уже была уверена, что проблемы нет, и не приняла никаких защитных мер. В компаниях, где назначен ответственный за организацию обработки персональных данных, это его прямая зона - зафиксировать критерии и подписать акт о переводе конкретного массива в категорию обезличенных. Там, где отдельного ответственного нет, решение стоит хотя бы задокументировать и не оставлять на уровне устной договоренности между разработчиком и маркетологом.

Этот порядок работает вместе с общей проверкой сайта на соответствие закону, а не вместо нее: обезличивание закрывает один конкретный узел обработки данных, а не всю картину целиком. Полный перечень того, что проверяют по 152-ФЗ на сайте, есть в материале аудит сайта на соответствие ФЗ-152: 30-пунктовый чек-лист.

Итог: обезличивание как инструмент, а не отписка

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

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