Пришёл запрос на удаление. Что дальше?

О публикации страницы удаления пишут все. А то, что происходит после того, как ею кто-то воспользовался, и решает, соответствуете ли вы требованиям на самом деле, — и это вопрос процесса, а не хостинга.

Куда должны приходить запросы?

Туда, где человек увидит их в течение нескольких дней, а не в ящик, который вы проверяете, когда что-то сломалось.

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

Практические правила:

• Не личный адрес, который вы можете забросить. Письма в поддержку со страницы магазина приходят всплесками — месяцами ничего, потом сразу серия.
• Туда, где уведомление невозможно пропустить. Для разработчика-одиночки это часто канал в мессенджере, а не email — именно потому, что email — это место, где вещи игнорируют.
• По возможности больше одного маршрута. Если один канал тихо сломается, нужен второй.
• Проверьте это. Отправьте запрос через свою собственную публичную страницу и убедитесь, что он до вас дошёл. Повторяйте после любого изменения страницы.

Сколько у вас времени?

Если кто-либо из ваших пользователей находится в ЕС или Великобритании, действуют сроки GDPR. Статья 12(3) требует ответить без неоправданной задержки и в любом случае в течение одного месяца с момента получения. Для действительно сложных запросов срок можно продлить ещё на два месяца — но сообщить человеку о продлении нужно в течение первого месяца.

Две детали, которые разработчики регулярно упускают:

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

В других режимах регулирования — свои сроки. Если у вас есть пользователи в Калифорнии, Бразилии или других местах с похожими законами, проверьте применимый закон, а не считайте, что месяц покрывает вас везде.

Что именно нужно удалить?

Аккаунт и стоящие за ним персональные данные — и не только в вашей собственной базе данных:

Где находятся данные	Что вы делаете
Ваша основная база данных	Удаляете, а не делаете soft delete и забываете
Резервные копии	Честно указываете в политике, как долго хранятся бэкапы и что срок их хранения истекает
Аналитика / crash reporting	Используете собственный API удаления вендора, если он есть
Email- или CRM-инструменты	Удаляете из списков, куда вы экспортировали данные
Обработчики и субобработчики	Просите их удалить данные и проверяете исполнение — это ваша обязанность, а не их
Логи	Определяете срок хранения и соблюдаете его

Если ваше приложение полагается на поставщиков услуг для обработки пользовательских данных, удаление их с ваших собственных серверов — только половина работы: вы также должны попросить поставщика сделать то же самое.

Что можно сохранить?

Некоторые вещи — по заявленным причинам. Типичные:

• Платёжные и налоговые записи, которые обычно по закону хранятся годами.
• Запись о самом удалении — вы должны иметь возможность показать, что оно произошло.
• Маркеры мошенничества или злоупотреблений, если у вас есть законное основание и вы об этом заявили.
• Анонимизированные агрегированные данные, если их действительно невозможно повторно идентифицировать.

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

Что должно быть в ответе?

Коротко, конкретно, с датой:

Мы получили ваш запрос на удаление 3 марта. Ваш аккаунт и связанные с ним персональные данные удалены. Мы сохранили ваши счета, которые обязаны хранить семь лет в налоговых целях, и запись об этом запросе. Больше ничего не осталось.

Это ответ, соответствующий требованиям. «Готово ✅» — нет, потому что он ничего не подтверждает.

Ведите учёт

Каким бы ни был объём, ведите журнал: кто запросил, когда, что вы удалили, что сохранили и почему, когда ответили. «Мы удалили» — это утверждение; список с датами — доказательство, а доказательства — то, что запросит регулятор спустя долгое время после того, как вы забудете о запросе.

По этой же причине запросы стоит хранить в структурированном виде, а не как разрозненные письма. Папка с ответами — это не журнал.

Одна оговорка ко всему вышесказанному

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

Что здесь делает AppFoyer

Мы размещаем страницу, сохраняем запрос как ваш журнал аудита и уведомляем вас по настроенным вами каналам — email на любом тарифе, Telegram или Slack на платном, через наших собственных бота и приложение, а не через ваши учётные данные. Дашборд хранит каждый запрос с процессом done → archive → delete (выполнено → архив → удаление), так что описанный выше журнал у вас уже есть, а не строится вами.

Две вещи мы не делаем и не будем утверждать, что делаем: мы никогда не связываемся с конечным пользователем и никогда ничего не удаляем в ваших системах — у нас нет к ним доступа. Удаление, ответ и решения о хранении — за вами. Именно этого требование от вас и ждёт, и никакая размещённая страница этого не заменит.

Официальные источники

• Требования Google Play к удалению аккаунтов в приложениях — Справка Google Play
• Right to erasure — Управление комиссара по информации Великобритании (ICO), собственное руководство регулятора
• Статья 12 GDPR и статья 17 — срок и само право