Ограничение Сроков Хранения — Передовая Правоприменения 2026 Года для Аналитики
Регуляторы перестали спрашивать, законно ли вы собрали данные, и начали спрашивать, когда вы их удалили. После штрафа CNIL в 42 млн евро для Free и проверки удаления данных со стороны EDPB цель аудита — хранение данных аналитики.
Раньше дорогой вопрос GDPR звучал так: есть ли у вас законное основание для сбора этих данных. В 2026 году он превратился в: почему это всё ещё в вашей базе данных. Два правоприменительных события переместили хранение из сноски в документации на передовую, и системы аналитики оказались прямо в зоне поражения.
Два решения, изменившие цель
13 января 2026 года CNIL оштрафовала Free Mobile на 27 миллионов евро, а Free — на 15 миллионов. Большинство публикаций сосредоточилось на утечке 2024 года, раскрывшей 24 миллиона абонентских договоров, но решение также прямо ссылалось на статью 5(1)(e) — ограничение сроков хранения. Free Mobile хранила данные по 2,8 миллиона договоров, расторгнутых более десяти лет назад, без обоснования. Данные были собраны законно. Незаконным было их хранение.
Месяц спустя EDPB опубликовал результаты своей скоординированной правоприменительной акции 2025 года. Тридцать два органа по защите данных проверили 764 контролёра на практику удаления и обнаружили два системных недостатка: отсутствие внутренней классификации данных и отсутствие автоматического удаления в самих ИТ-системах. Задокументированную политику хранения, которую технически ничто не обеспечивает, сочли отягчающим, а не смягчающим фактором.
Сигнал однозначен. Регуляторы теперь исходят из того, что сбор состоялся; они проверяют удаление.
Почему аналитика — очевидное место для проверки
Ограничение сроков хранения по статье 5(1)(e) гласит, что персональные данные нельзя хранить в идентифицируемой форме дольше, чем требует цель. Большинство стеков аналитики тихо нарушают это.
Типичная таблица событий хранит по строке на каждое взаимодействие, привязанной к стабильному идентификатору — ID куки, ID устройства, хешированный e-mail — с временной меткой и без срока истечения. Схема спроектирована так, чтобы хранить всё вечно, чтобы оставалось возможным «вдруг мы захотим это запросить позже». Это именно то хранение на всякий случай, за которое CNIL наказала.
Проблема усугубляется тем, что персональными данными строку делает именно идентификатор. Пока user_id = a91f... можно сопоставить с человеком на протяжении месяцев событий, каждая из этих строк попадает в сферу действия, каждая подпадает под запросы на доступ и удаление, и каждая является обязательством в случае утечки. Хранение — это не затраты на дисковое пространство. Это риск, измеряемый временем.
Минимизация при записи лучше удаления при чтении
Долговечное решение — это не более совершенный cron-задание, очищающее старые строки. Это модель данных, в которой идентифицируемая форма вообще никогда не сохраняется.
Модель идентичности Monoid построена вокруг этого. Посетитель представлен только ежедневным хешем:
SHA-256(IP | UA | SALT_SECRET | YYYY-MM-DD)
Сырые IP и User-Agent существуют только в памяти Worker ровно столько, сколько нужно для вычисления этого хеша; D1 хранит хеш, а не сырые значения. Поскольку дата является входным параметром, хеш одного и того же посетителя меняется каждую полночь. Нет стабильного межсуточного идентификатора для хранения, поэтому межсессионный профиль, на который нацелено ограничение сроков хранения, не может накопиться — не по политике, а по конструкции.
Это минимизация данных при записи. Вы не удаляете связь позже, потому что вы её никогда не записывали. Запрос на удаление становится тривиальным, когда нет долговечного ключа, по которому нужно стирать.
Хранение, которое вы действительно можете доказать
Ограничению сроков хранения всё же нужна внешняя граница, и защищаемая граница — короткая и применяемая, а не длинная и декларативная. Monoid хранит данные о просмотрах страниц не дольше 730 дней. Два года — это намеренный потолок для анализа трендов, и удаление — это реальная операция над таблицей, а не строка в PDF-документе с политикой. Вывод EDPB был в том, что политики без применения — это та брешь, которую используют расследования; хранение, которое действительно выполняется, её закрывает.
Комбинация важнее любой из половин. Ежедневно меняющиеся хеши означают, что данные уже агрегированы по форме ещё до того, как хранение вообще вступает в силу. Очистка на 730 дней означает, что даже этот агрегированный сигнал имеет жёсткий, доказуемый конец.
Как оценить любую аналитику, на которую вы полагаетесь
Какая бы аналитика ни стояла за вашим сайтом, три проверки напрямую соответствуют тому, что проверяли регуляторы:
- Найдите каждое поле, связывающее запись с человеком во времени. Стабильный user ID, постоянное значение куки, сырой IP, fingerprint. Каждое из них превращает лог событий в сохраняемый профиль — поэтому спросите, хранит ли используемая вами аналитика хоть одно из них вообще.
- Спросите, когда применяется хранение — при приёме данных или на ежеквартальном обзоре. Минимизация, которая происходит по мере записи данных, превосходит задание на удаление, о запуске которого кому-то нужно помнить. Самый сильный ответ — это модель, в которой идентифицируемая форма вообще никогда не сохранялась.
- Спросите, доказуемо ли удаление. Если поставщик не может указать на жёсткую границу хранения, которая действительно выполняется, у него есть политика, а не контроль — и проверка EDPB только что подсказала, что из двух влечёт штраф.
Самые дешёвые для защиты в ходе аудита данные — это данные, которые вы никогда не хранили в идентифицируемой форме. Ограничение сроков хранения больше не является пунктом для перефразирования в политике конфиденциальности; это то, что измерит следующее расследование, и архитектура, которая на это отвечает, — это та, у которой никогда не было профиля для удаления.
Comments
Loading comments…