Вам пришло письмо от Роскомнадзора - или вы просто хотите отдать аналитику подрядчику и не попасть на штраф. Первая мысль обычно такая: убрали ФИО, телефон и e-mail - и это уже «безопасная статистика». Для регулятора и судов так, как правило, не работает.

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

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

Ключевые понятия: что такое 152-ФЗ и кто такой оператор ПДн

Прежде чем разбирать методы, зафиксируем четыре термина. Без них письмо РКН и эта статья читаются как набор аббревиатур.

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

Персональные данные (ПДн) - любая информация, относящаяся к прямо или косвенно определённому либо определяемому физическому лицу (ст. 3 152-ФЗ). Это не только паспорт и телефон. Косвенной определимости достаточно: связка cookie + заказ + адрес, стабильный user_id, точный IP вместе с другими полями.

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

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

Для сайта проверка простая. Убрали ФИО и почту, но оставили user_id, точный IP, связку cookie + заказ + адрес доставки. Человек с доступом к админке, CRM или ключу восстанавливает субъекта за минуты. Набор всё ещё персональные данные.

Обезличивание и анонимизация - не синонимы

В европейских текстах часто говорят об anonymisation: данные навсегда выведены из-под GDPR, повторная идентификация практически нереальна. Ближе к российскому обезличиванию в GDPR стоит псевдонимизация. В 152-ФЗ отдельного термина «анонимизация» нет, и трёхступенчатой шкалы «прямые / обезличенные / анонимные» закон тоже не даёт.

Ниже - рабочая схема для владельца бизнеса, а не классификация из кодекса.

  1. Прямо идентифицирующие сведения. ФИО, паспорт, телефон, e-mail, СНИЛС, точная геолокация, платёжный идентификатор. Фото и голос - тоже ПДн; если они используются, чтобы установить личность, это уже биометрия со специальным режимом ст. 11 152-ФЗ. Cookie, IP, device_id в практике РКН часто квалифицируются как персональные данные, если по ним одним или вместе с другими сведениями можно определить лицо.
  2. Обезличенные данные в смысле 152-ФЗ. Прямые идентификаторы сняты или заменены, но оператор (или тот, у кого есть ключ) может сопоставить запись с человеком. Это по-прежнему зона 152-ФЗ: цели, основания, поручения, защита, сроки, в типичном случае - локализация и правила трансграничной передачи. Методы приказа Роскомнадзора от 05.09.2013 № 996 как раз рассчитаны на обратимость для оператора.
  3. Набор, из которого субъекта нельзя определить даже с учётом доступной дополнительной информации. Нет ключа, нет уникального хвоста, данные сильно агрегированы. Только такой результат может означать, что информация уже не является персональными данными. Это доказываемая позиция, а не ярлык в регламенте. При споре с регулятором обосновывать её придётся вам.

Путать второй и третий уровни - главная причина бесполезных «методик обезличивания». На бумаге «данные обезличены», в SQL - JOIN по внутреннему id, и субъект снова на месте.

Когда владельцу сайта нужно обезличивание

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

Срок хранения истёк. По ч. 7 ст. 5 152-ФЗ хранить данные в идентифицируемом виде можно не дольше, чем требуют цели обработки (если иной срок не задан законом или договором). Когда цель достигнута, персональные данные подлежат уничтожению либо обезличиванию, если федеральный закон не требует иного.

Статистика и исследования. В ч. 1 ст. 6 152-ФЗ есть основание «обработка в статистических или иных исследовательских целях» - и оно работает только при обязательном обезличивании. Это основание нельзя использовать для продвижения товаров и услуг (ст. 15). Если цель - посчитать воронку и средний чек без Ивана Петрова, обезличивание не «хороший тон», а условие законности. Если аналитика идёт в идентифицируемом виде, нужно другое основание: согласие, договор и т.д.

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

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

  • Подрядчик работает для ваших целей - это поручение (ст. 6 152-ФЗ): нужен договор с обязательными условиями закона, за действия подрядчика перед клиентом отвечаете вы. Сырой кабинет с телефонами «для удобства» - это поручение, а не «просто аналитика».
  • Подрядчик забирает данные для своих целей - отдельное основание (часто согласие) либо отказ от передачи.
  • Если субъект подрядчику не нужен (агентству или аудитору воронки достаточно когорт), качественное обезличивание или агрегаты сужают периметр. Пока идентификация реальна, ни поручение, ни основание это не заменяет.

Публичные витрины, демо, обучение моделей. Выгрузка за периметр учёта субъектов требует правового основания. Если по выгрузке человека ещё можно вычислить, это обработка ПДн; при уходе за рубеж добавляются правила трансграничной передачи. Не полагайтесь на то, что любая «нейронка» автоматически выводит набор из-под 152-ФЗ.

Типичные точки риска у коммерческого сайта одни и те же: веб-аналитика, CRM-выгрузки, ретаргетинг, запись сессий, чат-логи, голосовые роботы, кабинеты подрядчиков, «успешные кейсы» с реальными заказами.

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

Методы обезличивания по методике Роскомнадзора

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

Введение идентификаторов

Прямой идентификатор заменяют кодом, токеном, хешем, синтетическим id. «Иванов И.И.» становится u_918203. Телефон становится токеном платёжного провайдера.

Метод работает только если:

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

Хеш от e-mail без соли и без секрета - не обезличивание. Это перекрашенный e-mail: его подбирают по таблицам и утечкам соседних сервисов.

Изменение состава или семантики

Из записи убирают поля, которые прямо указывают на человека, либо огрубляют их. Дата рождения 14.03.1987 превращается в «1985-1989». Адрес «ул. Ленина, д. 12, кв. 47» - в «город N, Центральный район». Точные координаты - в сетку. Конкретный шаг сетки закон не задаёт: 1×1 км в малом населённом пункте может по-прежнему идентифицировать.

Ловушка - уникальный хвост. В маленьком городе женщина 47 лет, трое детей, заказ на 186 400 рублей 12 января - и без ФИО субъект вычисляется. Чем меньше выборка и чем больше редких признаков, тем бесполезнее «убрали ФИО». Специальные категории (ст. 10 152-ФЗ: здоровье, раса, политические взгляды и др.) так не «обезвреживаются»: пока субъект определяем, действует специальный режим.

Декомпозиция

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

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

Перемешивание

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

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

Почему обезличенные данные всё ещё надо защищать

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

Что не исчезает автоматически:

  • Основание и цель. Аналитика, улучшение сервиса, обучение модели - разные цели (ст. 5). Нельзя взять согласие «на оказание услуги» и кормить той же карточкой дата-сайентистов, если эта цель не была задана.
  • Учёт и поручения. Подрядчик с доступом к ключу или сырым логам обрабатывает ПДн по поручению. Нужен договор по ст. 6, а не «доступ к Метрике по почте».
  • Меры защиты. Ключ, словарь, сырой бэкап, админка, дамп логов - это персональные данные в чистом виде. Их режим не слабее, чем у основной базы (ст. 18.1, 19).
  • Сроки. Обезличенный архив «на всякий случай лет на десять» без цели - нарушение принципа ограничения обработки.
  • Права человека. Субъект может требовать сведения об обработке, уточнения, прекращения (ст. 14, 20, 21). Если вы технически в силах снова найти его запись, отказ «у нас только статистика» выглядит слабо.
  • Локализация. Ч. 5 ст. 18 не отключается ярлыком «уже без фамилий», пока данные остаются персональными.
  • Трансграничная передача. Выгрузка «без фамилий» в иностранный облачный notebook не выводит операцию из ст. 12, если идентификация ещё реальна. С 1 марта 2023 г. правила существенно переписаны - сверяйтесь с актуальной редакцией, а не с практикой «до реформы».

Отдельно про веб-аналитику. Счётчик, который видит IP, cookie, User-Agent, referrer, id пользователя в CRM и события корзины, в практике регулятора обрабатывает персональные данные. Подпись в футере «данные обезличены средствами счётчика» ничего не доказывает. Смотрите фактические настройки: передача user_id, вебвизор, карты кликов, сопоставление с телефоном из формы.

Типовые ошибки обезличивания

Ошибка 1. Удалили ФИО и телефон, оставили уникальный внутренний id, который светится в письмах, в URL личного кабинета и в колл-центре.

Ошибка 2. Хеш от паспорта, СНИЛС или почты без соли/секрета и без отдельного хранения. Это псевдоним, который подбирается обратно.

Ошибка 3. Выгрузка для «нейронки» с полным текстом обращений в поддержку. В чате человек сам пишет ФИО, номер заказа, адрес, симптомы, имя ребёнка. Поля в CSV вроде бы чистые, тело сообщения - нет. Если в тексте есть сведения о здоровье или данные несовершеннолетнего, дополнительно смотрите ст. 10 152-ФЗ.

Ошибка 4. Маскирование на экране и полный дамп в бэкапе. Сотрудник видит +7 *** ***-**-21, админ БД видит исходник. Для регулятора важен не интерфейс, а контур хранения и доступа.

Ошибка 5. Публикация «реальных кейсов». «Женщина 34 лет из Одинцово купила курс за 79 000 после консультации 3 марта» при 40 чеках в месяц. Соседи и журналист собирают субъекта без всякого SQL.

Ошибка 6. Один и тот же токен во всех системах. Платёжный id = id в аналитике = id в партнёрской программе = id в открытом API. Цепочка склеивается через внешнего игрока, которого вы не контролируете.

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

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

Как выстроить процесс, который переживает проверку

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

Инвентаризация полей. Пройдитесь не по «анкете в CRM», а по реальному потоку: формы, касса, коллтрекинг, чат, аналитика, рекламные пиксели, логи авторизации, мобильное приложение, 1С, рассылка. Персональными данными могут быть голос, изображение, IMEI, стабильный MAC, поведенческий профиль - если информация относится к определяемому лицу.

Классификация идентификаторов (практическая, не из текста закона):

  • прямые: ФИО, документы, контакты, точный адрес, фото лица;
  • квази-идентификаторы: дата рождения, должность, редкий диагноз, VIN, точная сумма + дата + город;
  • технические: cookie, device_id, IP, fingerprint;
  • ключи связи: user_id, order_id, crm_id.

Прямые убираете или токенизируете. Квази-идентификаторы огрубляете, пока строка не перестанет быть уникальной в реальной выборке. Технические либо не пишете в аналитическую витрину, либо режете точность (сеть /24 для IP, день вместо миллисекунд - инженерный приём, а не требование закона).

Разделение контуров. Боевая карточка клиента, ключ токенизации, аналитическая витрина, песочница для разработки - разные доступы, разные резервные копии, разные подрядчики. Разработчик с копией продакшена на личном ноутбуке обесценивает любую методику.

Запрет обратной сборки. Прямо напишите в локальном акте и в договоре с подрядчиком: запрещено сопоставлять витрину с CRM, подмешивать внешние базы, дехешировать, обогащать по телефону. Без запрета «обезличенный» набор снова станет персональным за один JOIN.

Проверка качества. До передачи посчитайте уникальность строк. Если связка «город + возраст + дата заказа + сумма» даёт 1-2 человека, огрубляйте дальше или режьте хвост. Для малых выборок честный ответ часто такой: этот отчёт нельзя строить на микроданных, только на агрегатах.

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

Согласие и политика на сайте. Пользователь должен понимать, что вы собираете, зачем, кто ещё обрабатывает данные, уходит ли что-то в аналитику и рекламу. Обезличивание не заменяет прозрачность. Отдельного «закона о cookie» по модели ePrivacy в РФ нет, но счётчики, пиксели, запись сессий и передача user_id в рекламный кабинет всё равно описываются, имеют основание и не должны расходиться с кодом. Для продвижения смотрите ст. 15 152-ФЗ.

Что будет, если сделать вид, что персональных данных больше нет

С начала 2020-х ответственность оператора заметно выросла: неоднократно повышались штрафы по ст. 13.11 КоАП РФ, расширялись составы. По состоянию на 2024-2025 годы в КоАП введены в том числе крупные санкции за утечки, включая оборотные штрафы за повторные утечки. Квалификация «мы же обезличили» не спасёт, если будет установлено, что субъект по-прежнему определяем.

Типовые последствия:

  • предписание Роскомнадзора переделать процесс и документы;
  • административный штраф на юридическое лицо, при повторности - существенно выше;
  • требование прекратить незаконную обработку и уничтожить данные в порядке ст. 21 152-ФЗ;
  • гражданско-правовые требования субъектов (ст. 17, 24), особенно после утечки «анонимного» датасета, который легко склеивается;
  • удар по сделке: покупатель бизнеса или крупный заказчик запрашивает контур ПДн и видит хаос.

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

Практический минимум для владельца сайта

Это чек-лист снижения бытовых рисков, а не закрытый перечень обязанностей 152-ФЗ.

  1. Поймите, какие идентификаторы уходят в Метрику, рекламу, чат, CRM, коллтрекинг.
  2. Отключите передачу user_id, телефона и e-mail туда, где они не нужны для заявленной цели (принцип избыточности, ст. 5).
  3. Закройте вебвизор и карты форм на страницах с паспортными и платёжными данными.
  4. Не копируйте боевую базу в облачные таблицы «для аналитика»: это и утечка контура, и часто трансграничная передача плюс вопрос локализации.
  5. Для отчётов используйте агрегаты: день, канал, устройство, коридор чека - и проверяйте, что ячейка не выделяет человека.
  6. Если подрядчику нужна построчная история - договор поручения по ст. 6, минимум полей, срок, условия о субисполнителях, возврат и уничтожение.
  7. Ключи токенизации не кладите в Git, в корпоративную wiki и в общий чат.
  8. Раз в квартал проверяйте: не появился ли новый скрипт, новый вебхук, новый «удобный» доступ маркетологу.

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

Итог

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

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

Источники: 152-ФЗ (ст. 3, 5, 6, 12, 14, 15, 18, 18.1, 19, 21, 22.1 - в актуальной редакции), приказ Роскомнадзора от 05.09.2013 № 996, методические рекомендации Роскомнадзора по его применению (декабрь 2013 г.), Роскомнадзор, ст. 13.11 КоАП РФ в действующей редакции. Нормы об ответственности и о трансграничной передаче менялись в 2022-2025 годах - перед внедрением сверяйте первоисточник.

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

Если я удалил ФИО и телефон, данные уже не персональные?

Нет, не обязательно. Персональные данные - это любая информация, по которой человека можно определить прямо или косвенно. Внутренний user_id, точный IP, cookie в связке с заказом и адресом доставки часто восстанавливают субъекта за минуты. Обезличивание состоялось только если без дополнительной информации (ключа, логов, соседней таблицы) выйти на человека нельзя.

Я владелец небольшого сайта. Я оператор персональных данных?

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

Можно ли отдать подрядчику выгрузку «без фамилий» без договора поручения?

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

Яндекс.Метрика и рекламные пиксели - это уже обезличивание?

Нет. Подпись в футере «данные обезличены средствами счётчика» сама по себе ничего не доказывает. Если счётчик видит IP, cookie, User-Agent, события корзины и тем более user_id или телефон из формы, в практике регулятора это обработка персональных данных. Смотрите фактические настройки, а не слоган на сайте.

Чем грозит ошибка в обезличивании?

Предписание Роскомнадзора, штраф по ст. 13.11 КоАП РФ (в том числе крупные санкции и оборотные штрафы за повторные утечки - размеры смотрите в актуальной редакции), требование уничтожить данные, иски субъектов. Отговорка «мы же обезличили» не работает, если будет установлено, что человека по набору всё ещё можно определить.

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