Cookies, localStorage, fingerprinting: что считается персональными данными и как это отражать в документах

Подробный разбор для операторов, разработчиков и специалистов по ИБ — от правовой природы до чек-листов

Почему обычные технические данные стали юридическим полем минирования

До 2018 года большинство владельцев сайтов воспринимали cookies как сугубо техническую деталь: маленький текстовый файлик, который браузер хранит у себя и отправляет обратно на сервер при каждом запросе. Потом пришёл GDPR, за ним последовали многочисленные штрафы регуляторов, и оказалось, что этот «маленький файлик» может стать основанием для многомиллионных санкций.

В России аналогичная трансформация идёт поступательно. С 2022 по 2025 год Государственная Дума приняла серию поправок к 152-ФЗ, последовательно ужесточая ответственность и расширяя трактовку понятия «обработка персональных данных». Роскомнадзор с 1 июля 2025 года запустил автоматическую проверку сайтов на базе искусственного интеллекта — алгоритм анализирует наличие документов, внешних подключений, передачу данных за рубеж и регистрацию оператора [17].

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

Эта статья — попытка разобраться без лишней воды: что именно является персональными данными в контексте cookies, localStorage и fingerprinting, как это соотносится с российским правом и что конкретно писать в юридических документах.

Что такое персональные данные: российский закон vs. европейский GDPR

Определение в 152-ФЗ

Российский закон №152-ФЗ «О персональных данных» даёт в ст. 3 следующее определение: персональные данные — это «любая информация, относящаяся к прямо или косвенно определённому или определяемому физическому лицу (субъекту персональных данных)» [1].

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

Закон выделяет несколько категорий данных с различающимся режимом обработки:

1. Специальные категории (ст. 10) — расовая, национальная принадлежность, политические взгляды, состояние здоровья, биометрия и т. д. Требуют письменного согласия субъекта. Важно: если маркетинговая система по поведенческим данным и демографии строит выводы о политических взглядах или состоянии здоровья пользователя, она начинает работать со специальными категориями ПДн [11].
2. Биометрические данные (ст. 11) — физиологические и биологические характеристики, позволяющие установить личность. К биометрике относят изображение лица и запись голоса [1]. Некоторые виды fingerprinting (рендеринг-паттерны, специфичные для конкретного устройства) теоретически могут быть квалифицированы как биометрические по аналогии.
3. Общедоступные данные — опубликованные самим субъектом. Это узкое исключение с осторожной практикой применения [10].
4. Иные персональные данные — всё остальное: электронная почта, номер телефона, история покупок, поведенческие паттерны.

Определение в GDPR и концепция идентифицируемости

GDPR (Регламент ЕС 2016/679) в Recital 30 прямо указывает, что физические лица могут быть ассоциированы с онлайн-идентификаторами — IP-адресами, идентификаторами cookies и иными метками, — которые в сочетании с другой информацией, получаемой серверами, позволяют создавать профили пользователей и идентифицировать их [2].

Британский регулятор ICO (Information Commissioner's Office) развивает эту логику дальше: при оценке идентифицируемости нужно учитывать, можно ли онлайн-идентификаторы использовать самостоятельно или в совокупности с другими доступными данными, чтобы отличить одного пользователя от другого, — в том числе путём построения профилей [3].

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

Cookies: от технического файла до персонального идентификатора

Как работают cookies и чем они различаются

Cookies — это небольшие фрагменты текстовых данных, которые веб-сервер отправляет браузеру пользователя, а браузер сохраняет их и автоматически возвращает серверу при каждом последующем запросе к тому же домену. С технической точки зрения cookie — это строка вида ключ=значение с набором атрибутов: Domain, Path, Expires/Max-Age, Secure, HttpOnly, SameSite.

Основные типы cookies:

1. Сессионные (session cookies) — хранятся только до закрытия браузера. Используются для поддержания авторизованной сессии, корзины покупок и т. д.
2. Постоянные (persistent cookies) — сохраняются на определённый срок (дни, месяцы, годы). Используются для запоминания пользователя между визитами, хранения настроек, долгосрочного трекинга.
3. Первичные (first-party cookies) — устанавливаются доменом сайта, который посещает пользователь.
4. Сторонние (third-party cookies) — устанавливаются доменами, которые встроены в страницу (рекламные сети, аналитика, пиксели соцсетей). Именно они стали главным объектом регуляторной атаки.

Дополнительно выделяют функциональные cookies (запоминают язык, регион, тему), аналитические (собирают статистику посещений) и маркетинговые (отслеживают поведение для таргетинга рекламы). Эта классификация важна, потому что правовой режим для разных типов существенно различается [5].

Когда cookie становится ПДн: два критерия

Практика РКН и сложившаяся интерпретация 152-ФЗ формируют два ключевых вопроса, которые нужно задать для каждого конкретного файла cookie [6]:

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

Если ответ хотя бы на один из них «да» — cookie считается персональными данными. Логика такая: сам по себе cookie с идентификатором abc123 — это просто строка. Но если с этим идентификатором у оператора в базе данных связан профиль конкретного пользователя с историей его поведения, то это уже инструмент идентификации, а значит — ПДн [7].

В судебной практике эта позиция не является новой. В деле Vidal-Hall v. Google (2015, Великобритания) суд встал на сторону истцов, которые указывали, что Google без их ведома собирала данные об интернет-трафике с помощью cookies: суд признал, что cookies «не называя прямо субъекта... позволяют выделить его из всей массы пользователей» — и это означает, что критерий идентификации соблюдён [5].

Категории cookies и разный правовой режим

Основной принцип, выработанный как в российской практике, так и в европейском регулировании, следующий:

1. Строго необходимые технические cookies (авторизация, корзина, балансировка нагрузки) — не требуют согласия пользователя. Правовым основанием служит необходимость для исполнения договора с пользователем или законный интерес оператора, непосредственно связанный с функционированием сервиса.
2. Функциональные cookies (язык, регион, настройки интерфейса) — как правило, также не требуют отдельного согласия, поскольку прямо улучшают пользовательский опыт в рамках предоставляемой услуги. Но здесь есть нюансы.
3. Аналитические и статистические cookies — требуют согласия, поскольку не связаны напрямую с предоставлением сервиса и направлены на получение бизнес-выгоды оператора.
4. Маркетинговые и рекламные cookies — требуют согласия в обязательном порядке [4].

Именно в этой плоскости в России сложилась «высокая правовая неопределённость», как характеризует её Михаил Ратушный, DPO Ozon: в отличие от ЕС, в российском праве отсутствует достаточная практика применения законного интереса (п. 7 ч. 1 ст. 6 ФЗ-152) к техническим cookies [4]. На практике это означает, что большинство операторов вынуждены брать согласие на всё — или рисковать.

Позиция Роскомнадзора и судебная практика

Роскомнадзор в своих разъяснениях и правоприменительной практике прямо указывает: если cookie-файлы позволяют идентифицировать пользователя или создают основу для такой идентификации, они подпадают под действие 152-ФЗ [7].

С 2025 года регулятор усилил позицию в части технической локализации: cookie с идентифицирующими данными должны храниться на российских серверах, если они относятся к данным российских граждан [7]. С 1 июля 2025 года вступил в силу полный запрет на хранение ПДн российских граждан в зарубежных базах данных [9].

localStorage и sessionStorage: браузерное хранилище в правовом фокусе

Технические отличия от cookies

localStorage и sessionStorage — это механизмы веб-хранилища (Web Storage API), введённые в HTML5. Они принципиально отличаются от cookies по нескольким параметрам:

1. localStorage сохраняет данные без срока истечения — они остаются в браузере до явного удаления скриптом или самим пользователем.
2. sessionStorage сохраняет данные только на время одной вкладки/сессии: при закрытии вкладки данные удаляются.
3. Оба механизма хранят данные исключительно на стороне клиента и, в отличие от cookies, не отправляются автоматически на сервер при каждом HTTP-запросе. Это снижает нагрузку на сеть, но означает, что сервер получает данные только тогда, когда JavaScript-код явно их извлекает и отправляет.
4. Ёмкость существенно больше, чем у cookies: типичные браузеры выделяют около 5 МБ на домен против ~4 КБ у cookies [16].
5. Политика одного источника (same-origin policy) ограничивает доступ к хранилищу: JavaScript одного домена не может читать localStorage другого.

Правовой статус: молчание закона и практические выводы

Ни 152-ФЗ, ни разъяснения РКН не содержат явных упоминаний localStorage или sessionStorage. Это «молчание закона» некоторые интерпретируют как разрешение хранить в localStorage что угодно без каких-либо ограничений. Такая интерпретация ошибочна по нескольким причинам.

Во-первых, 152-ФЗ регулирует любую обработку персональных данных, а не только cookies. Обработка включает «любое действие (операцию) или совокупность действий с персональными данными, совершаемых с использованием средств автоматизации» (ст. 3 закона) [1]. Запись уникального идентификатора пользователя в localStorage с последующей его передачей на сервер — это обработка ПДн.

Во-вторых, практика веб-разработки прямо указывает на то, что в localStorage нередко сохраняют крайне чувствительные данные: идентификаторы пользователей, JWT-токены (фактически являющиеся удостоверением личности в системе), а иногда и прямые персональные данные [16]. Такая практика уязвима с точки зрения информационной безопасности — XSS-атака позволяет любому стороннему скрипту прочитать содержимое localStorage [16].

В-третьих, специалисты по безопасности формулируют вывод, который соответствует логике 152-ФЗ: не следует хранить конфиденциальные данные в localStorage — к ним относятся идентификаторы пользователей, идентификаторы сессий, JWT, персональная информация [16].

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

Важная техническая оговорка: один распространённый аргумент гласит, что «для localStorage согласие не требуется в отличие от cookies» [5]. Формально это верно в контексте ePrivacy Directive (европейской директивы о конфиденциальности электронных коммуникаций), которая прямо регулирует только cookies и аналогичные технологии хранения. Но ни ePrivacy Directive, ни 152-ФЗ не освобождают от необходимости получать согласие на обработку ПДн, если они хранятся в localStorage. Речь идёт о двух разных уровнях регулирования: ePrivacy/технический уровень и ПДн/содержательный уровень.

Риски безопасности как косвенный регуляторный аргумент

Хранение ПДн в localStorage создаёт не только правовые, но и практические риски, которые регуляторы всё активнее принимают во внимание при оценке соблюдения требований безопасности (ст. 19 152-ФЗ). Поскольку localStorage доступен через JavaScript любому коду, загруженному на странице, уязвимость в одном из десятков подключённых сторонних скриптов может привести к массовому компрометированию идентификаторов пользователей. В контексте новых оборотных штрафов за утечку ПДн, введённых 420-ФЗ с 30 мая 2025 года [8], такой сценарий становится экзистенциальным риском для бизнеса.

Browser fingerprinting: невидимое профилирование без cookies

Что такое браузерный отпечаток и как он формируется

Browser fingerprinting (браузерный фингерпринт, «цифровой отпечаток браузера») — это метод идентификации пользователя путём сбора и анализа характеристик его браузера и устройства без записи каких-либо данных на его компьютер. В отличие от cookies или localStorage, fingerprinting не требует хранилища на стороне клиента: все данные собираются на лету при каждом визите [12].

Механизм работает следующим образом: JavaScript-скрипт (или специальные API браузера) считывает набор атрибутов — версия браузера, операционная система, разрешение экрана, установленные шрифты, часовой пояс, поддерживаемые плагины, язык системы и т. д. Эти атрибуты объединяются и хешируются в «отпечаток» — строку, уникальную для конкретной конфигурации устройства [12].

Исследования показывают, что уникальность такого отпечатка достаточно высока, чтобы с его помощью с высокой вероятностью повторно идентифицировать конкретного пользователя — даже если он очистил cookies, использовал приватный режим браузера или сменил IP-адрес.

Техники: canvas, WebGL, audio, fonts, TLS

Современный фингерпринтинг использует несколько техник, которые могут применяться как по отдельности, так и в комбинации [13]:

1. Canvas fingerprinting — наиболее распространённая техника. Скрипт рисует скрытое изображение с текстом через Canvas API (HTML5), а затем извлекает пиксельный массив с помощью toDataURL(). Из-за различий в GPU, графических драйверах и системных шрифтах одно и то же изображение рендерится с минимальными, но уникальными отличиями на каждом устройстве. MD5-хеш этого пиксельного массива и служит «canvas fingerprint» [15].
2. WebGL fingerprinting — более сложная версия canvas fingerprinting с использованием WebGL API для рендеринга 3D-графики. Различия в видеокартах и драйверах создают уникальные паттерны рендеринга.
3. Audio fingerprinting — скрипт генерирует звуковые данные через Web Audio API и анализирует, как устройство обрабатывает аудиосигнал. Конкретная звуковая карта, версия браузера и архитектура CPU влияют на точные значения звуковых волн, создавая уникальный аудиоотпечаток. Некоторые финансовые учреждения используют audio fingerprinting для выявления несанкционированных входов [13].
4. Font fingerprinting — сайт определяет набор шрифтов, установленных в системе. Каждая ОС и пользователь имеют уникальный набор шрифтов, что создаёт ещё один слой идентификации.
5. TLS fingerprinting — анализ характеристик TLS-рукопожатия (порядок расширений, наборы шифров, версии протоколов) позволяет идентифицировать браузер и операционную систему даже при проксировании трафика.
6. Поведенческий fingerprint — паттерны движения мыши, скорость набора, прокрутки. Применяется в системах антифрода.

Правовой статус fingerprinting в России и за рубежом

Здесь начинается наиболее спорная зона. Ни GDPR, ни CCPA, ни 152-ФЗ не содержат прямых норм о браузерном fingerprinting. Но регуляторы в ЕС и Великобритании последовательно распространяют на него действие законодательства о ПДн через общее определение персональных данных [14].

Позиция ICO (Великобритания) состоит в следующем: поскольку fingerprinting может использоваться для создания профилей отдельных пользователей и отличия одного пользователя от другого, это обработка персональных данных [3]. Аналогичную позицию разделяют немецкие надзорные органы (DSK).

По GDPR ситуация следующая: использование browser fingerprinting для отслеживания посетителей веб-сайта представляет собой «обработку персональных данных», так как GDPR определяет ПДн как любую информацию, которая может быть связана с идентифицируемым физическим лицом [12].

В России ситуация неоднозначна. Прямой позиции РКН по fingerprinting в открытых источниках нет. Однако широкое определение ПДн в ст. 3 152-ФЗ («любая информация, относящаяся к косвенно определяемому физическому лицу») логически охватывает fingerprint, если он используется для идентификации конкретного пользователя. Принцип «если можно идентифицировать — это ПДн» действует и здесь [1].

Аргумент «публичных данных» и его ограниченность

Ряд вендоров в сфере безопасности утверждает, что собираемые при fingerprinting данные «публичны» и не являются ПДн, поскольку пользователь транслирует их открыто в ходе нормального браузинга, а сама технология служит лишь целям безопасности — обнаружению ботов и предотвращению мошенничества [20]. Этот аргумент имеет практическое значение: в ЕС использование fingerprinting для защиты от мошенничества может быть обосновано через «законный интерес» оператора (legitimate interest), тогда как маркетинговое использование — нет [14].

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

Принцип совокупности: когда безобидные данные становятся ПДн

Один из наиболее недооценённых правовых принципов в работе с браузерными данными — это принцип совокупности (combination principle). Ни 152-ФЗ, ни GDPR не требуют, чтобы каждый элемент данных был идентифицирующим сам по себе. Достаточно, чтобы совокупность данных позволяла установить личность пользователя [10].

На практике это означает следующее:

1. IP-адрес + версия браузера + временная метка = не обязательно ПДн в отдельности, но вместе — устойчивый идентификатор пользователя.
2. Canvas hash + screen resolution + timezone = высокоуникальный fingerprint.
3. localStorage-ключ с ID сессии + аналитические события + IP-адрес = полный пользовательский профиль, который явно является ПДн.
4. Cookies от десяти разных рекламных трекеров, которые сторонняя data-платформа сопоставляет между собой = кросс-доменный профиль пользователя, безусловно являющийся ПДн.

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

Требования 2025 года: что изменилось для операторов

Новые штрафы и оборотные санкции (420-ФЗ)

Федеральный закон №420-ФЗ от 30 ноября 2024 года, вступивший в силу с 30 мая 2025 года, кардинально изменил систему санкций [8]:

1. За утечку персональных данных введены оборотные штрафы: до 3% годовой выручки организации, но не менее установленного минимума в зависимости от объёма пострадавших субъектов. Для особо крупных утечек потолок составляет 500 млн рублей [17].
2. Штрафы за нарушение порядка обработки (ст. 13.11 КоАП) выросли до 6 млн рублей.
3. При утечке оператор обязан уведомить РКН в течение 24 часов о предполагаемых причинах и потенциальном вреде, а в течение 72 часов — сообщить о результатах расследования. Несоблюдение сроков уведомления — штраф от 1 до 3 млн рублей [20].

Уголовная ответственность (ст. 272.1 УК)

С декабря 2024 года в Уголовный кодекс РФ введена статья 272.1, устанавливающая уголовную ответственность за незаконное использование, передачу, распространение, сбор и хранение ПДн, полученных незаконным путём, а также за создание ресурсов для их незаконного хранения и распространения [8, 18]. Это качественно новый уровень ответственности, который ранее отсутствовал в российском праве.

Локализация и трансграничная передача

С 1 июля 2025 года вступили в силу поправки в п. 5 ст. 18 152-ФЗ, которые полностью запрещают использование зарубежных баз данных для хранения ПДн российских граждан [9]. Это означает, что не только сами ПДн, но и cookies, идентификаторы и другие данные, позволяющие идентифицировать россиян, не могут первично собираться и храниться за пределами российской инфраструктуры. Передача данных в Яндекс.Метрику, Google Analytics, Meta Pixel, HubSpot и аналогичные зарубежные сервисы — это трансграничная передача, требующая специального правового основания и уведомления РКН.

Автоматическая проверка РКН с 01.07.2025

С 1 июля 2025 года Роскомнадзор запустил систему автоматической проверки сайтов с использованием ИИ. Алгоритм анализирует [17]:

1. Наличие политики конфиденциальности на сайте.
2. Наличие и корректность cookie-баннера.
3. Подключение внешних аналитических систем, которые передают данные за рубеж.
4. Регистрацию оператора в реестре РКН.
5. Соответствие фактической практики сбора данных заявленной политике.

Штраф за несоответствие может достигать 18 млн рублей [17].

Как отражать технические данные в документах оператора

Политика конфиденциальности: обязательные разделы

Политика конфиденциальности (она же «Политика обработки персональных данных», «Privacy Policy») — обязательный публичный документ для любого оператора, собирающего данные через сайт. Согласно 152-ФЗ и практике РКН, документ должен содержать [10, 20]:

1. Наименование и реквизиты оператора — юридическое лицо, ИНН, адрес, контакты.
2. Цели обработки персональных данных — конкретно: аналитика посещений, персонализация рекламы, антифрод, работа корзины и т. д. Обобщённая формулировка «улучшение пользовательского опыта» недостаточна.
3. Виды обрабатываемых данных — перечислить все: IP-адреса, cookies по категориям (технические, аналитические, маркетинговые), данные из localStorage (если применимо), fingerprint (если применяется).
4. Правовые основания обработки для каждой цели.
5. Перечень третьих лиц, которым передаются данные — Яндекс, Google, VK, рекламные сети и т. д.
6. Сроки хранения данных.
7. Меры защиты персональных данных.
8. Права субъектов ПДн и порядок их реализации.
9. Для данных, хранящихся на российских серверах: подтверждение локализации [20].

Ссылка на политику конфиденциальности должна быть постоянно доступна — как правило, в подвале (footer) сайта [20].

Cookie-политика или раздел политики: что конкретно писать

Cookie-политика может быть отдельным документом или разделом политики конфиденциальности. В ней необходимо [6]:

1. Перечислить все используемые cookies по категориям: технические (с указанием конкретного cookie, его срока жизни и назначения), аналитические, маркетинговые.
2. Указать сторонние сервисы, устанавливающие cookies (Яндекс.Метрика, Google Analytics, пиксели социальных сетей, рекламные сети).
3. Описать localStorage и sessionStorage, если в них хранятся идентификаторы.
4. Если применяется fingerprinting — описать его в разделе «иные технологии отслеживания», указать технику (canvas, audio и т. д.) и цель.
5. Объяснить пользователю, как он может управлять cookies (настройки браузера, opt-out от конкретных сервисов).

Согласие на обработку: новые требования с 01.09.2025

С 1 сентября 2025 года обновлены требования к форме согласия на обработку ПДн [17]. Согласие должно быть:

1. Отдельным документом — нельзя встраивать согласие в политику конфиденциальности, пользовательское соглашение или cookie-баннер.
2. Конкретным — должно содержать точный перечень данных, цели обработки, действия с данными.
3. Инициативным — «галочки по умолчанию» запрещены. Пользователь должен самостоятельно проставить согласие.
4. Включать данные об операторе и субъекте [17].

Cookie-баннер сам по себе не является согласием на обработку ПДн — он может служить инструментом получения согласия на использование конкретных категорий cookies, но форма согласия на ПДн должна быть отдельной [17].

Отдельно: продолжение использования сайта не является согласием. Роспотребнадзор в информации от 5 ноября 2020 года о click-wrap соглашениях прямо указал, что молчаливое принятие через продолжение использования является спорным механизмом получения согласия [4]. Для аналитических и маркетинговых cookies согласие должно быть явным.

Реестр обработки ПДн и уведомление РКН

Все операторы, собирающие данные пользователей (в том числе через cookies), обязаны подать уведомление в Роскомнадзор о намерении осуществлять обработку ПДн до начала такой обработки [9]. Непредоставление уведомления — штраф от 100 до 300 тысяч рублей для организаций [9].

Практический чек-лист для разработчика и DPO

Инвентаризация технических данных

1. Провести полную инвентаризацию: перечислить все cookies (первичные и сторонние), все записи в localStorage/sessionStorage, все используемые fingerprinting-скрипты.
2. Для каждого элемента определить: содержит ли он идентификаторы? Передаётся ли на сервер? Используется ли для создания профилей?
3. Зафиксировать все сторонние скрипты и пиксели, устанавливающие cookies или собирающие данные.

Работа с документами

1. Обновить политику конфиденциальности: включить все выявленные категории данных, третьих лиц, цели и сроки [10, 20].
2. Создать или обновить cookie-политику: расписать каждую категорию с конкретными именами cookies, сроками жизни, назначением [6].
3. Настроить cookie-баннер: разделить cookies по категориям (технические, аналитические, маркетинговые), дать пользователю возможность принять только нужные.
4. Отделить согласие на ПДн от cookie-баннера: это два разных юридических инструмента [17].

Технические меры

1. Не хранить ПДн и ссылки на ПДн в localStorage — использовать httpOnly cookies для сессионных токенов [16].
2. Блокировать загрузку аналитических и маркетинговых cookie-скриптов до получения явного согласия.
3. Настроить IP-анонимизацию в аналитических системах (например, anonymize_ip: true в GA).
4. Хранить данные на российских серверах; трансграничную передачу задокументировать [9].
5. Настроить автоматическое удаление данных по истечении сроков хранения.

Организационные меры

1. Подать уведомление в РКН до начала сбора данных [9].
2. Обновлять документацию при каждом добавлении нового сервиса или изменении логики сбора данных.
3. Назначить ответственного за ПДн (DPO или аналог) и ознакомить команду разработки с требованиями.

Ошибки и риски: что делают неправильно

Типичные ошибки операторов в работе с браузерными данными, выявляемые при проверках:

1. Формальный cookie-баннер без реальной блокировки. Баннер показывается, но маркетинговые скрипты загружаются независимо от выбора пользователя. С технической точки зрения это игнорирование выраженного несогласия.
2. Скрытое согласие в тексте политики. Формулировка «продолжая использовать сайт, вы соглашаетесь с политикой» используется как основание для обработки всех данных. Роспотребнадзор и РКН не принимают такое согласие как действительное [4].
3. Копирование чужой политики конфиденциальности. Типичная ошибка: название оператора не изменено, цели обработки не соответствуют реальным, перечень третьих лиц отсутствует или взят из другой компании [20].
4. Несоответствие документов и реальной практики. В политике написано «мы не собираем данные о поведении», а на сайте подключены Яндекс.Метрика, Google Analytics и три рекламных пикселя. РКН при автоматической проверке выявит это несоответствие [17].
5. Fingerprinting без упоминания в документах. Многие компании используют сторонние антифрод-решения, которые применяют fingerprinting. Это обработка данных, которую необходимо отражать в политике конфиденциальности [14].
6. localStorage как «неурегулированная зона». Хранение идентификаторов пользователей в localStorage без отражения в политике [16].
7. Передача данных в зарубежные сервисы без документирования трансграничной передачи. Особенно актуально после 01.07.2025 [9].

Будущее: регулирование ужесточается, технологии не стоят на месте

Несколько тенденций определят пейзаж следующих двух-трёх лет.

Во-первых, уход от third-party cookies. Основные браузеры (Safari, Firefox) уже заблокировали сторонние cookies. Google откладывал этот шаг несколько раз, но движение в этом направлении необратимо. Индустрия ищет замену — и находит её в fingerprinting и cohort-based tracking (Privacy Sandbox). Показательно, что с февраля 2025 года Google разрешил рекламодателям использовать fingerprinting для межустройственного измерения аудитории [13]. Это означает, что fingerprinting в ближайшие годы из нишевой технологии превратится в основную. Регуляторам придётся выработать чёткие нормы.

Во-вторых, ужесточение российского законодательства продолжится. Глава Роскомнадзора Андрей Липов публично говорил о необходимости вводить отраслевые стандарты обработки ПДн [18]. Следует ожидать появления специальных требований для онлайн-сервисов, аналогичных тем, что существуют в ЕС в рамках ePrivacy Regulation.

В-третьих, AI-powered проверки сайтов РКН с 01.07.2025 означают переход от эпизодических ручных проверок к непрерывному автоматическому мониторингу. Это принципиально меняет риск-профиль: ошибки в документации или несоответствие практики политике будут выявляться быстрее, без необходимости жалобы от пользователя или конкурента [17].

В-четвёртых, обезличивание становится важным инструментом. Новая ст. 13.1 152-ФЗ, вступившая в силу с 01.09.2025, создаёт правовую рамку для работы с обезличенными данными: данные, из которых невозможно извлечь ПДн, можно обрабатывать и передавать свободнее [19]. Это открывает возможности для аналитики на основе агрегатов без обработки сырых ПДн.

Заключение: выводы и что делать дальше

Cookies, localStorage и fingerprinting — это не просто технические инструменты разработчика. Это полноценные объекты правового регулирования, причём с 2025 года — объекты жёсткого регулирования с уголовной ответственностью и оборотными штрафами.

Практические выводы:

1. Проверьте, что конкретно собирает ваш сайт прямо сейчас — не то, что написано в политике, а то, что реально происходит в браузере пользователя.
2. Проведите классификацию: технические данные vs. идентифицирующие vs. профильные. Для каждого типа — своё правовое основание.
3. Обновите документацию: политику конфиденциальности, cookie-политику, согласие на ПДн. Убедитесь, что они соответствуют реальной практике.
4. Настройте техническую реализацию: согласие до загрузки скриптов, IP-анонимизация, сроки удаления.
5. Подайте уведомление в РКН, если ещё не сделали этого.
6. Задокументируйте трансграничную передачу данных.

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

Платформа «Пятый фактор»: непрерывный контроль ПДн в корпоративных системах

Описанная в статье проблема — разрыв между тем, что написано в документах, и тем, что реально происходит с данными, — типична не только для браузерного уровня, но и для корпоративной ИТ-инфраструктуры в целом. Разработчики добавляют новые поля в базы данных, подключают новые сервисы, строят интеграции. В какой-то момент реальная «карта ПДн» в компании перестаёт соответствовать тому, что зафиксировано в документации оператора.

Именно эту проблему решает платформа «Пятый фактор» — on-prem система для автоматического обнаружения, инвентаризации и контроля персональных данных в корпоративных системах: БД, хранилищах, почте, AD/LDAP, CRM, 1С, API.

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

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

1. Замечать новые риски (новые поля, интеграции, источники данных) раньше, чем они превращаются в инцидент.
2. Сократить время аудита ПДн с недель до часов.
3. Повысить готовность к проверкам РКН, включая автоматические с 01.07.2025.
4. Вести понятный реестр обработки с указанием владельцев данных, статусов нарушений и согласований.

Подробнее: 5factor.ru

Источники

[1] Федеральный закон «О персональных данных» от 27.07.2006 №152-ФЗ (актуальная редакция) — https://www.consultant.ru/document/cons_doc_LAW_61801/

[2] GDPR Recital 30 — Online Identifiers for Profiling and Identification — https://gdpr-info.eu/recitals/no-30/

[3] ICO — What are identifiers and related factors? — https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/personal-information-what-is-it/what-is-personal-data/what-are-identifiers-and-related-factors/

[4] Право.ру — Файлы cookie и персональные данные: терминология и основания для обработки (М. Ратушный, DPO Ozon) — https://pravo.ru/opinion/250647/

[5] Хабр — Что нужно знать о cookies-файлах, чтобы не нарушить закон — https://habr.com/ru/articles/673418/

[6] b-152.ru — Cookie-файлы как персональные данные: что это значит для бизнеса — https://b-152.ru/cookie-fajly-kak-personalnye-dannye

[7] Qform.biz — Юридические нюансы сбора cookies: как соблюдать 152-ФЗ — https://qform.biz/blog/yuridicheskie-nyuansyi-sbora-cookies-kak-soblyudat-152-fz-besplatnyij-skript

[8] Правовест Аудит — Обработка персональных данных: изменения с 30.05.2025 — https://pravovest-audit.ru/nashi-statii-nalogi-i-buhuchet/izmeneniya-v-obrabotke-personalnykh-dannykh-s-30-maya-2025-goda/

[9] Business.ru — 152-ФЗ о персональных данных в 2025–2026 годах — https://www.business.ru/article/5705-152-fz-o-personalnyh-dannyh-gg

[10] Nubes — Персональные данные в 2025 году: новые правила обработки и защиты для бизнеса — https://nubes.ru/blog/articles/personal-data-2025

[11] КиберЛенинка — Cookie-файлы как объект персональных данных и способ нарушения конфиденциальности — https://cyberleninka.ru/article/n/cookie-fayly-kak-obekt-personalnyh-dannyh-i-sposob-narusheniya-konfidentsialnosti-personalnyh-dannyh

[12] CHEQ — What is Browser Fingerprinting? Is it GDPR Compliant? — https://cheq.ai/blog/what-is-browser-fingerprinting/

[13] Fingerprint.com — Browser Fingerprinting Techniques — https://fingerprint.com/blog/browser-fingerprinting-techniques/

[14] Microanalytics.io — Browser Fingerprinting & GDPR Compliance — https://microanalytics.io/articles/browser-fingerprinting-and-gdpr/

[15] BrowserLeaks — Canvas Fingerprinting — https://browserleaks.com/canvas

[16] Хабр — Почему не стоит использовать localStorage — https://habr.com/ru/post/349164/

[17] Linkodium — Новые требования Роскомнадзора по закону 152-ФЗ (на 30 мая 2025 года) — http://linkodium.com/news/novye-trebovaniya-roskomnadzora-po-zakonu-152-fz-na-30-maya-2025-goda/

[18] PGP Law — Обзор новостей по персональным данным, март 2025 — https://www.pgplaw.ru/analytics-and-brochures/digital-economy-digest/personal-data-digest-15-03-25/

[19] Хабр — Новые правила обезличивания персональных данных с 1 сентября 2025 года — https://habr.com/ru/articles/931348/

[20] adlook.me — Персональные данные на сайте в 2025 году — https://adlook.me/blog/articles/personalnye-dannye-na-sajte/