Штраф до 20 млн евро или 4% мирового годового оборота по GDPR возникает не потому, что компания не нажала кнопку «удалить». Риск появляется, когда бизнес не может доказать, какие сведения были удалены, на каком основании часть информации сохранена и почему копии остались у подрядчика. Решая, как удалить данные пользователя автоматически, нельзя сводить задачу к SQL-запросу или настройке срока жизни записи.
Для SaaS-платформы, маркетплейса, агрегатора цен или дата-брокера удаление — это управляемый процесс на пересечении права, продуктовой архитектуры и договоров. Он должен учитывать запрос субъекта, срок хранения, резервные копии, журналы событий, антифрод-проверки и передачу данных внешним сервисам. Автоматизация без этой карты нередко уничтожает нужные доказательства или, наоборот, оставляет персональные данные в скрытых контурах.
Когда автоматическое удаление становится обязанностью
GDPR не устанавливает единый срок хранения для всех категорий сведений. Статья 5(1)(e) требует соблюдать принцип ограничения срока хранения: персональные данные нельзя держать дольше, чем это необходимо для заявленной цели. Статья 17 закрепляет право на стирание, но одновременно предусматривает исключения — например, когда обработка нужна для исполнения юридической обязанности или защиты правовых требований.
В российском регулировании аналогичная логика следует из ФЗ-152. При достижении цели обработки оператор обязан прекратить обработку и уничтожить персональные данные, если иное не предусмотрено законом или договором. Статья 21 ФЗ-152 задает обязанность уточнить, заблокировать или уничтожить данные в предусмотренных ситуациях. Для международной группы компаний одного общего правила недостаточно: сроки и основания нужно сопоставлять по каждой юрисдикции и каждому виду записи.
В США запросы на удаление регулируются, в частности, CCPA. Право потребителя не является абсолютным: закон допускает сохранение информации для завершения операции, безопасности, выполнения юридической обязанности, исправления ошибок и некоторых других целей. Поэтому обещание «удаляем все мгновенно» может быть столь же опасным, как и бессрочное хранение.
Сначала разделите данные по целям и срокам
Корректная автоматизация начинается с реестра обработки. Команде необходимо видеть не абстрактную таблицу клиентов, а жизненный цикл каждой категории сведений: от формы регистрации и API до витрины аналитики, системы рассылок и архива резервных копий.
Практически полезно закрепить для каждой категории четыре параметра: цель обработки, правовое основание, срок хранения и действие по окончании срока. Контакт для ответа на запрос может храниться до закрытия обращения. История оплаты — столько, сколько требует применимое бухгалтерское и налоговое регулирование. Технический лог, который нужен для расследования инцидента, может иметь отдельный, короткий период хранения.
Для парсинг-агентства особенно рискованны «сырые» выгрузки. Если в собранной базе оказались имена, рабочие адреса, номера телефонов или идентификаторы аккаунтов, ее нельзя хранить «на всякий случай». Нужно определить, допустимы ли сбор и дальнейшая обработка, требуется ли минимизация либо обезличивание, кому доступна исходная выгрузка и когда она должна быть уничтожена.
Не путайте удаление аккаунта и удаление сведений
Удаление учетной записи в интерфейсе не означает уничтожение всей связанной информации. Запись может сохраниться в CRM, биллинге, очереди задач, журнале доступа, облачном хранилище или у процессора данных. Пользователь видит закрытый профиль, а компания продолжает обрабатывать его идентификаторы — именно такие расхождения обычно обнаруживаются при аудите или разборе жалобы.
Одновременно удалять абсолютно все записи бывает неправильно. Например, сервису может потребоваться сохранить минимальный набор сведений о выполненном требовании, факте отзыва согласия или ограничении доступа. Этот набор должен быть отделен от активного профиля, доступен ограниченному кругу лиц и иметь собственный срок хранения.
Постройте сценарии удаления, а не одну кнопку
Рабочая модель обычно включает несколько независимых триггеров. Первый — запрос субъекта через личный кабинет, форму или службу поддержки. Второй — окончание установленного срока хранения. Третий — отзыв согласия, если именно согласие было основанием обработки. Четвертый — решение компании удалить незаконно собранный или избыточный массив после внутреннего аудита.
Каждый триггер должен запускать не прямое стирание, а маршрут проверки. Система сопоставляет запрос с идентификатором пользователя, определяет применимую юрисдикцию, проверяет наличие законного основания для сохранения части данных и формирует задачу для зависимых систем. Такой подход снижает риск удалить записи по ошибочному или мошенническому запросу.
Техническая команда обычно реализует политику хранения через планировщик, правила жизненного цикла в хранилищах и сервис оркестрации задач. Но право определяет логику этой политики. Если инженер задаст единый срок в 90 дней для всех таблиц без матрицы хранения, компания не сможет объяснить этот выбор регулятору, инвестору или контрагенту.
Учитывайте резервные копии и неизменяемые журналы
Резервная копия не дает права бессрочно хранить удаленные записи. При этом немедленное редактирование всех бэкапов может быть технически непропорциональным и даже нарушить целостность системы. Практичное решение — исключить удаленную запись из активной обработки, ограничить восстановление бэкапа и гарантировать ее исчезновение при плановой ротации резервных копий.
Этот порядок нужно закрепить в политике хранения. В ней указывают максимальный срок существования резервной копии, запрет на возврат удаленных профилей в рабочую среду без повторного применения правил удаления и порядок документирования восстановления. Если срок ротации составляет 30 дней, нельзя в Privacy Policy создавать ожидание полного уничтожения во всех системах «немедленно».
Отдельного внимания требуют журналы безопасности. Они часто содержат IP-адреса, идентификаторы сессий, адреса электронной почты и действия пользователя. Их следует минимизировать, разграничить доступ и удалять по самостоятельному графику. Неизменяемый журнал допустим как доказательство, но не как формальный предлог для вечного хранения полного профиля.
Передайте обязательства подрядчикам
Если персональные данные передаются облачному провайдеру, CRM, платежному сервису, колл-центру или исполнителю рассылок, автоматизация должна охватывать и их. По статье 28 GDPR контролер обязан использовать процессоров, предоставляющих достаточные гарантии, а договор обработки данных должен регулировать действия с информацией после прекращения услуг.
В договоре и DPA следует определить, кто получает команду на удаление, в какой срок подрядчик подтверждает исполнение, какие данные могут быть возвращены вместо уничтожения и как обрабатываются резервные копии. Формулировка «поставщик соблюдает применимое право» не заменяет операционный механизм. Для крупной SaaS-инфраструктуры полезен реестр субподрядчиков и периодическая сверка фактических потоков с договорной схемой.
Риск особенно высок у e-commerce агрегаторов и сервисов веб-скрапинга. Сведения могут одновременно находиться в исходной выгрузке, нормализованной базе, карточке товара, модуле качества и экспортированном отчете клиента. Запрос на удаление или установленный срок должны затронуть каждый идентифицируемый экземпляр, кроме четко обоснованных исключений.
Докажите, что удаление состоялось
У регулятора, клиента или аудитора возникнет не теоретический вопрос, а конкретный: «Покажите, что вы сделали после запроса». Поэтому процессу нужен журнал удаления. Он фиксирует дату поступления требования, способ идентификации заявителя, примененную политику, перечень систем, исключения, дату исполнения и ответ пользователю.
Не стоит сохранять в таком журнале больше, чем нужно. Часто достаточно внутреннего идентификатора, хеша обращения, статуса и ссылки на основание хранения. Сам журнал также содержит потенциально персональные сведения и должен иметь срок хранения.
Полезно тестировать процесс не только в документах. Проведите контрольный сценарий: создайте тестовую учетную запись, сформируйте запрос, проверьте основную базу, поисковые индексы, экспортные очереди, аналитику, CRM и бэкапы после ротации. Если в одном из контуров запись возвращается, автоматизированное удаление существует только на схеме.
Ошибки, которые создают претензии
Наиболее частая ошибка — одинаковый срок для всех данных и всех рынков. Вторая — удаление только в пользовательском интерфейсе. Третья — отсутствие исключений для юридических требований и защиты от мошенничества. Четвертая — отсутствие договора с подрядчиком о возврате или уничтожении информации.
Не менее опасна автоматизация без процесса обработки запросов. Запросы могут быть неполными, повторными или поступать от лица, не подтвердившего полномочия. Нужны каналы приема, разумная верификация, правила коммуникации и эскалация для спорных случаев. Это защищает и права субъекта, и компанию от ошибочного раскрытия либо уничтожения записей.
Автоматическое удаление персональных данных — часть более широкой системы контроля, а не отдельная функция базы данных. Правильно настроенный процесс уменьшает объем юридических рисков, облегчает выход на рынки ЕС и США и делает проверяемыми заявления в Privacy Policy.
Дата-юристы Data Lawyer Agency проводят аудит сроков хранения, схем передачи данных и договоров с процессорами, а затем помогают перевести требования GDPR, CCPA и ФЗ-152 в работающий регламент для продуктовой и инженерной команды. Начните с проверки реальных потоков данных до того, как запрос субъекта или инцидент превратится в спор с регулятором.