Ключевые выводы
- Право на забвение в CDP — это техническая реализация требования 152-ФЗ ст. 14, по которому субъект может потребовать удаления своих ПДн в течение 30 дней
- Корректный workflow удаления состоит из 6 шагов: приём запроса, идентификация, валидация, исполнение, верификация, уведомление
- Главная техническая сложность — каскадное удаление по всем связанным таблицам и кэшам без потери целостности витрин
- Часть данных удалить нельзя по закону (бухгалтерия, налоги, согласия) — нужна категоризация retained_by_law
- В CDP для enterprise нужен отдельный модуль обработки запросов с очередью, аудит-следом и SLA-мониторингом
Право на забвение в CDP реализация — задача, на которой регулярно теряют 20-30% бюджета compliance-проекта. Юристы написали политику, разработчики добавили кнопку «удалить аккаунт» — и все считают, что закон выполнен. До первого реального запроса от субъекта или первой проверки Роскомнадзора.
Эта статья — практическая методичка по технической реализации права на забвение в CDP-контуре. С учётом 152-ФЗ ст. 14, требований к срокам и аудит-следу, и реальных проблем, с которыми сталкиваются enterprise-проекты.
Что требует 152-ФЗ от технической реализации
Право на забвение, или право на отзыв согласия с последующим удалением данных, прописано в 152-ФЗ ст. 14 и ст. 21:
- Субъект может потребовать прекращения обработки и удаления своих ПДн
- Оператор обязан выполнить запрос в течение 30 дней с момента получения
- Удаление должно быть документировано — нужен аудит-след с подтверждением
- Если данные передавались третьим лицам — оператор обязан уведомить их о необходимости удаления
- Часть данных можно удалять не сразу, а после истечения сроков обязательного хранения (бухгалтерский учёт — 5 лет, налоги — 4 года)
На бумаге звучит просто. На практике любой проект CDP содержит данные субъекта в десятках мест: основная БД, реплики, кэши, очереди, бэкапы, логи приложения, аналитический DWH, сегменты в маркетинговых сервисах, файлы экспорта.
Workflow удаления: 6 шагов
Шаг 1: Приём запроса
Каналы приёма: форма на сайте, email, личный кабинет, обращение в саппорт. По 152-ФЗ субъект может направить запрос любым способом, включая письмо в офис компании. Все каналы сводятся в единый workflow с одинаковыми этапами.
Минимальный набор полей запроса:
- ФИО и идентификатор аккаунта (email, телефон)
- Документ, удостоверяющий личность (для верификации)
- Конкретный запрос (полное удаление или удаление по конкретным целям)
- Согласие на обработку запроса для целей его исполнения
Шаг 2: Идентификация субъекта
В CDP-контуре идентификация — нетривиальная задача. У субъекта может быть 5-10 идентификаторов в разных системах: ID в e-com, ID в 1С, телефон, несколько email-адресов, ID в программе лояльности, идентификаторы устройств.
Перед удалением нужно построить полный entity resolution: какие записи в каких системах относятся к этому субъекту. Без этой работы половина данных останется не удалённой.
Шаг 3: Валидация и юридическая проверка
- Проверка подлинности запроса — субъект тот, за кого себя выдаёт
- Проверка применимости — действительно ли можно удалить именно эти данные
- Категоризация данных — какие можно удалить сразу, какие через N лет, какие в принципе нельзя
- Юридическое одобрение исполнения запроса (для крупных операторов — обязательно)
Шаг 4: Исполнение удаления
Технически — самая сложная фаза. Удаление каскадно по всем системам:
- Основная БД CDP — удаление профиля и связанных событий
- Кэши — Redis, Memcached, application-уровень — invalidation всех ключей с этим субъектом
- Очереди — Kafka, RabbitMQ — обработка in-flight событий до удаления
- Аналитический DWH — удаление или обезличивание записей в витринах
- Маркетинговые сервисы — отписка во всех каналах, удаление из сегментов
- Бэкапы — отдельный workflow (см. ниже)
- Логи приложения — обезличивание записей с идентификаторами
- Файлы экспорта — удаление или обезличивание
Шаг 5: Верификация
После технического удаления — проверка, что данные действительно удалены. Это не та же команда, которая удаляла — это compliance или audit-роль с правами read-only.
- Запрос профиля по идентификаторам — должен возвращать «не найден»
- Запрос связанных событий — должен возвращать пустой список
- Проверка маркетинговых сервисов — отписка в email/push/SMS
- Проверка отчётов — субъект не появляется в активных сегментах
Шаг 6: Уведомление и аудит-след
- Уведомление субъекта о факте удаления (email или письмо)
- Уведомление третьих лиц, которым передавались данные
- Запись в аудит-след: кто запросил, кто валидировал, кто исполнил, кто верифицировал, дата и время каждого шага
- Архивирование самого запроса с резолюцией — храним 5+ лет для compliance
Категории данных и разные правила удаления
| Категория | Можно удалить сразу | Условие удаления |
|---|---|---|
| Маркетинговые согласия | Да | — |
| Профиль и предпочтения | Да | — |
| Поведенческие события (просмотры, клики) | Да или обезличить | — |
| История покупок | Нет | 5 лет с момента покупки (бухучёт) |
| Платёжные данные | Нет | 5 лет (налоговый учёт) |
| Согласия (текст и факт дачи) | Нет | 3 года после прекращения обработки |
| Документы (договоры, акты) | Нет | По закону для конкретного типа |
| Записи разговоров с саппортом | Можно | Если нет претензий или судебных разбирательств |
Важно: данные, которые нельзя удалить сразу, должны быть переведены в режим retained_by_law с пометкой о том, когда их можно физически удалить. На вопрос Роскомнадзора «вы удалили данные субъекта?» ответ должен быть «удалили всё, кроме записей, которые обязаны хранить по бухгалтерскому учёту до 2031 года».
Право на забвение в CDP реализация: техническая архитектура
Отдельный модуль consent-management
В CDP enterprise-уровня право на забвение требует выделенного модуля:
- API приёма запросов — REST endpoint /api/v1/forget с авторизацией субъекта
- Очередь обработки — асинхронная, с гарантией at-least-once и dead-letter queue
- Worker'ы исполнения — раздельные для разных типов данных и систем
- Аудит-таблица — append-only с фиксацией каждого шага
- Уведомления — отдельный сервис с retry-логикой
- Dashboard SLA — мониторинг времени исполнения с алертами на просрочку
Каскадное удаление по событийной модели
Если CDP построен на event-driven архитектуре с Kafka или outbox-pattern, удаление становится проще: публикуется событие forget(profile_id), на него подписаны все сервисы и сами обрабатывают своё хранилище. Это распределённый паттерн саги — каждый сервис компенсирует свою часть.
Подробнее об архитектуре event-driven CDP — в материале outbox pattern вместо Kafka в CDP.
Бэкапы и право на забвение
Самая сложная часть — работа с бэкапами. Удалить данные субъекта из ежедневного бэкапа за 2024 год невозможно (это нарушит целостность бэкапа), но и хранить бэкап 5 лет нельзя без обработки.
Стандартное решение:
- Бэкапы храним 30-90 дней (стандартная retention-политика)
- В этот срок при восстановлении из бэкапа — повторное применение журнала forget-запросов
- Долговременные архивы (3+ лет) либо обезличиваются, либо хранятся в формате, позволяющем выборочное удаление
- В политике обработки ПДн явно указываем срок хранения бэкапов и порядок их обработки
Третьи лица и каскадное удаление
Если CDP передаёт данные в маркетинговые сервисы (Mindbox, Altcraft, рекламные сети), при forget-запросе нужно уведомить их о необходимости удалить данные субъекта на их стороне.
- Для каждого третьего лица — отдельный API-endpoint (или email-канал) для forget-уведомлений
- В договоре с третьим лицом — фиксированный SLA на удаление (обычно 7-30 дней)
- Получение подтверждения удаления — обязательно, иначе нет доказательства соответствия 152-ФЗ
- Аудит-след со стороны третьего лица — приложение к собственному аудит-следу
Типовые ошибки при реализации
- Удаление без entity resolution — пропускаются данные в системах, где у субъекта другой идентификатор
- Удаление без проверки удерживаемых данных — удаляют то, что обязаны хранить (нарушение бухгалтерского законодательства)
- Отсутствие аудит-следа — на проверке Роскомнадзора невозможно доказать факт исполнения
- Игнорирование третьих лиц — данные удалены у нас, но остались в маркетинговых сервисах
- Неудаление кэшей — субъект продолжает получать рассылки несколько часов после удаления
- Удаление без верификации — техническая проблема может оставить часть данных, и никто этого не заметит
Стоимость реализации
Разработка модуля consent-management с поддержкой права на забвение в CDP-проекте:
- Базовая реализация (профиль + события + 1-2 третьих лица): 1.5-2.5 млн ₽, 1.5-2 месяца
- Полная реализация (все каналы, верификация, SLA-мониторинг): 4-7 млн ₽, 3-4 месяца
- Adjustments на существующих CDP: 0.8-1.5 млн ₽, 4-6 недель
Это инвестиция, которая закрывает один из основных compliance-рисков. Альтернативная стоимость — штрафы 152-ФЗ от 100 тыс ₽ до 18 млн ₽ за инцидент.
FAQ о праве на забвение в CDP
Можно ли отложить удаление, если данные используются в активной кампании?
Нет. По 152-ФЗ срок исполнения запроса — 30 дней с момента получения. Если данные используются в активной кампании, нужно немедленно прекратить их использование и завершить удаление в установленный срок. Активность кампании — не основание для отказа.
Что делать, если субъект потом снова регистрируется на сайте?
Это новый субъект — повторный сбор согласий, новый профиль, новая история. Связь со старым удалённым профилем не должна прослеживаться (иначе это нарушение акта удаления). Если у вас есть аналитические задачи по «возвращающимся клиентам» — придётся работать с обезличенными данными.
Можно ли вместо удаления использовать обезличивание?
Если данные обезличены настолько, что их нельзя сопоставить с конкретным субъектом — это не ПДн, и хранить можно. Но обезличивание должно быть проведено корректно: удаление прямых идентификаторов (ФИО, телефон, email) недостаточно — нужно учитывать косвенные идентификаторы (адрес, дата рождения, история покупок). Лучше консультироваться с юристом по конкретной модели обезличивания.
Как доказать, что данные действительно удалены?
Через аудит-след: записи в журнале операций, скриншоты пустых ответов на запросы по идентификаторам, выгрузка из логов с пометкой об удалении. Все эти артефакты должны быть готовы для предъявления в течение 1-2 рабочих дней при запросе Роскомнадзора. Если на запрос приходится говорить «дайте 2 недели на подготовку выгрузки» — это уже основание для замечания.
Что делать, если субъект просит удалить только часть данных?
Можно — 152-ФЗ предусматривает выборочный отзыв согласия. Например, субъект может отозвать согласие на маркетинговые рассылки, оставив согласие на обработку для оказания услуг. Технически это требует гранулярной модели согласий: удаление маркетинговых пометок и сегментов без удаления самого профиля.
Что в итоге
Право на забвение в CDP реализация — это не одна функция «удалить аккаунт», а полноценный модуль с workflow, аудит-следом, верификацией и каскадом по всем подсистемам. Корректная реализация требует 1.5-7 млн ₽ инвестиций в зависимости от зрелости архитектуры и возвращает страховку от штрафов 152-ФЗ до 18 млн ₽ за инцидент.
Готовы провести аудит готовности вашего CDP к forget-запросам и предложить план доработки — обсудим в формате 1-часовой консультации.