Данные клиента в бэкапах: как учитывать запрос на удаление

Запрос на удаление персональных данных нельзя закрыть одной очисткой карточки клиента: нужно учесть резервные копии и последующее восстановление. Сначала определите применимое основание и объём действий, затем проверьте технические возможности конкретной системы копирования. Обычное расписание ротации архива само по себе не делает ожидание удаления законным.

Разделите решение о данных и операцию над архивом

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

Основания обработки перечислены в статье 6 закона о персональных данных, а обязанности по уточнению, блокированию и уничтожению — в статье 21. Последствия зависят от обстоятельств и применимых оснований; нельзя назначить всем запросам один срок только по настройке резервного копирования. Правовое решение для конкретного случая должен подтвердить ответственный специалист.

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

Карта данных после очистки рабочей базы

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

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

Что разрешает конкретный продукт резервного копирования

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

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

Рассмотрите доступные варианты вместе с ответственным за данные и администратором: предусмотренная обработка архива, пересоздание согласованного набора или изменение архитектуры копирования. Выбор должен учитывать и решение по запросу, и восстановление остальных необходимых данных. Нельзя считать достаточным обещание «когда-нибудь затрётся» без установленного порядка и контроля.

Восстановление не должно отменять уже принятое решение

Учебный пример: запись обработали по утверждённому запросу, а после сбоя восстановили более раннюю копию всей системы. Старое состояние может снова попасть в рабочую базу. Поэтому план восстановления должен учитывать решения, принятые после даты копии. Эта проверка нужна до открытия восстановленной системы пользователям и возобновления интеграций.

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

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

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

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

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

Что изменить в регламенте заранее

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

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