Удаление данных по GDPR в SaaS: что делать с резервными копиями, логами и данными у подрядчиков

Пользователь удаляет аккаунт в SaaS-продукте. Его профиль исчезает из интерфейса, но адрес электронной почты остается в журнале ошибок, файл — в резервной копии, а история обращений — в системе поддержки. Для продукта аккаунт удален, с точки зрения обработки данных история еще не закончилась.

Здесь и возникает практическая сложность права на удаление по GDPR. SaaS хранит сведения в нескольких системах ради разных целей, а часть копий технически нельзя изменить так же просто, как строку в основной базе. Компания должна определить, какие данные действительно подлежат удалению, где они находятся и как исключить их возвращение после восстановления системы.

Удалить аккаунт и выполнить запрос на удаление — разные действия

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

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

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

Для запросов субъектов данных GDPR предусматривает ответ без неоправданной задержки, как правило, в течение месяца. При сложном запросе срок ответа может быть продлен при соблюдении установленных условий и уведомлении заявителя. Поэтому процесс удаления должен позволять не только выполнить действия, но и вовремя объяснить человеку результат и пределы удаления.

Где остаются данные после удаления профиля

Первый технический шаг — поиск всех копий и производных записей, связанных с пользователем. В SaaS это могут быть:

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

Этот перечень не означает, что каждую запись удаляют одинаковым способом. Он нужен, чтобы данные не продолжали использоваться в системе, которую забыли включить в процесс.

Полезно проверить и непрямые идентификаторы. После удаления адреса электронной почты человек может оставаться узнаваемым по ID аккаунта, номеру обращения, IP-адресу или содержимому загруженного файла. Простая замена имени на случайный код не всегда делает запись анонимной.

Что делать с резервными копиями

Резервная копия нужна для восстановления продукта после сбоя или атаки. В некоторых архитектурах удалить из нее запись одного пользователя без изменения всего снимка невозможно либо такое изменение нарушит целостность копии. Однако правило «бэкапы не затрагиваем» не решает вопрос GDPR.

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

Самая важная проверка — возврат данных после восстановления. Допустим, профиль пользователя удалили 10 апреля, а 15 апреля восстановили базу из снимка за 8 апреля. Если восстановленный продукт сразу станет доступен пользователям, удаленный профиль появится вновь. Поэтому процедура восстановления должна включать применение записанных после создания копии удалений и проверку результата до возвращения системы в обычную работу.

В 2026 году EDPB отдельно отметил проблему компаний, у которых нет процедуры обработки запросов на удаление при работе с резервными копиями. Подход зависит от архитектуры и рисков, но полагаться только на автоматическую ротацию копий без учета уже полученных запросов недостаточно для надежного процесса.

Можно ли оставить данные в логах

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

Сначала нужно выяснить, что именно попадает в журнал. Для диагностики ошибки может хватить времени события, технического кода и ограниченного идентификатора. Адрес электронной почты, полный текст запроса, токен доступа или содержимое пользовательского документа могут оказаться лишними. Лучшее решение в таком случае — изменить логирование, чтобы новые персональные сведения туда не попадали.

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

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

Как организовать удаление у подрядчиков

Поставщик SaaS может пользоваться внешним хостингом, аналитикой, сервисом поддержки и инструментами рассылок. Для каждого из них нужно знать, какие данные передаются и кто может инициировать их удаление.

Если подрядчик обрабатывает данные по поручению SaaS-компании, запрос на удаление должен доходить до него через предусмотренный договором и технической интеграцией процесс. Это может быть API, административная панель или обращение в поддержку поставщика. Важен проверяемый результат: команда должна понимать, принят ли запрос, какие данные удалены и распространяется ли действие на копии поставщика.

Не всякий внешний получатель действует только по инструкциям SaaS-компании. Например, некоторые платежные или иные независимые сервисы могут хранить часть сведений для собственных правовых обязанностей. Обещать пользователю, что компания «удалила все данные у всех партнеров», в такой ситуации нельзя. Следует точно установить характер передачи и сообщить о выполненных действиях без преувеличений.

Отдельный риск возникает при прекращении договора с крупным корпоративным клиентом. Его данные могут находиться сразу у нескольких субподрядчиков, а период возврата и удаления определен в соглашении с клиентом. Команде нужна процедура, которая охватывает всю эту цепочку, а не только отключение доступа к основному аккаунту.

Как выглядит рабочий процесс удаления

Удобно рассматривать запрос как последовательность действий с ответственными и подтверждением результата:

1. Уточнить предмет запроса. Определить человека или аккаунт, убедиться в полномочиях заявителя, понять, относится ли запрос к данным пользователя, корпоративного клиента или к обоим случаям.
2. Разделить данные по основаниям хранения. Установить, что можно удалить сейчас, что должно временно сохраниться и почему. Решение принимают по конкретным категориям данных, а не по аккаунту целиком.
3. Удалить данные из активного контура. Помимо основной базы, проверить файлы, индексы, кеши, очереди и производные наборы данных. Повторный запуск отложенной задачи не должен восстановить удаленную запись.
4. Запустить действия во внешних системах. Передать запрос соответствующим подрядчикам и зафиксировать статус исполнения; при необходимости уведомить иных получателей данных.
5. Обработать резервные копии и проверить восстановление. Установить, когда копии будут заменены, и убедиться, что восстановленная система повторно применяет удаления.
6. Ответить заявителю. Сообщить, что сделано, какие сведения продолжают храниться на конкретном основании и как компания обращается с данными в резервных копиях.

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

Что проверить в продукте до первого запроса

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

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

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