Что на самом деле такое DSAR

Запрос субъекта данных на доступ (DSAR) — это момент, когда пользователь реализует права, которые GDPR предоставляет ему в отношении его персональных данных. Для мобильного издателя этот «субъект данных» — один из ваших игроков или пользователей, а запрос может поступить по электронной почте, через тикет поддержки, отзыв в магазине приложений или форму внутри приложения. Триггер прост: кто-то хочет узнать, что вы о нём храните — или хочет, чтобы вы что-то с этим сделали.

Важно, что DSAR не обязан упоминать GDPR, использовать слово «DSAR» или следовать какому-либо шаблону. Однострочное сообщение вроде «пришлите мне мои данные» или «удалите мой аккаунт» запускает отсчёт так же твёрдо, как официальное юридическое письмо. Считать действительными только официально выглядящие запросы — быстрый способ пропустить срок.

Права, стоящие за запросом

DSAR объединяют несколько отдельных прав, и одно и то же сообщение может ссылаться более чем на одно. Знание, какое именно, определяет, что вам на самом деле придётся сделать.

• Доступ — пользователь может попросить копию своих персональных данных плюс контекст: что вы собираете, зачем, с кем делитесь и как долго храните.
• Удаление («право быть забытым») — удаление его данных, включая копии, переданные рекламным и аналитическим партнёрам, с узкими юридическими исключениями.
• Переносимость — предоставленные вам данные, возвращённые в структурированном, машиночитаемом формате, таком как JSON или CSV, чтобы их можно было перенести в другое место.
• Исправление — корректировка неточных или неполных данных, например неправильного email или региона.

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

Сроки строгие

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

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

Построение масштабируемого рабочего процесса

Издатели, которые спокойно обрабатывают DSAR, превратили их в повторяемый процесс вместо пожарной тревоги. Работающий процесс выглядит так:

• Приём. Опубликуйте единый объявленный канал — форму внутри приложения или выделенный адрес privacy@ — и направляйте всё через него, чтобы ничего не потерялось в очередях поддержки.
• Проверьте личность. Подтвердите, что запрашивающий владеет аккаунтом, но просите только то, что вам нужно. Требовать скан паспорта для поиска внутриигрового ID — это само по себе проблема соответствия.
• Регистрируйте и ставьте отметку времени. Зафиксируйте дату поступления немедленно; это ваш якорь срока.
• Найдите данные. Поддерживайте карту данных каждого хранилища — вашего бэкенда, журналов сбоев, аналитики, рекламных SDK, CRM —, которое касается данных пользователя, упорядоченную по стабильному идентификатору.
• Выполните & ответьте. Экспортируйте, удалите или исправьте по запросу, распространите удаления на обработчиков и ответьте понятным языком.
• Замкните цикл. Заархивируйте запрос и ваш ответ как доказательство того, что вы действовали вовремя.

Распространённые ловушки

Большинство неудач операционные, а не юридические. Следите за этими:

• Забытые хранилища данных. Рекламные и атрибуционные SDK, push-провайдеры и сборщики отчётов о сбоях — все хранят данные пользователя. Удаление, которое их пропускает, неполное.
• Чрезмерный сбор во время проверки, превращающий запрос о приватности в риск для приватности.
• Восприятие неформальных сообщений как не-запросов и допущение того, что месяц истечёт.
• Нет доказательства согласия. Если пользователь оспаривает, что у вас вообще было законное основание обрабатывать его данные для рекламы, вы должны показать, на что он согласился и когда.

Как CMP делает DSAR управляемыми

Именно здесь ваш слой согласия оправдывает себя. На DSAR гораздо легче ответить, когда вы можете мгновенно показать, на что пользователь согласился, когда и в рамках какого фреймворка. FlexyConsent — сертифицированная Google CMP, поддерживающая IAB TCF 2.3 и Google Consent Mode v2 — хранит для каждого пользователя запись согласия и аудиторский след с отметкой времени. Когда поступает запрос на доступ, эта запись становится готовой частью вашего ответа: принятые цели, задействованные поставщики и версия показанного уведомления. Когда поступает запрос на удаление или возражение, та же запись доказывает, что вы остановили персонализированные рекламные сигналы в нужный момент. Сочетание этой истории согласия с вашей картой данных превращает DSAR из суеты в поиск.

Эта статья — общая информация для издателей и не является юридической консультацией; обратитесь к квалифицированному специалисту по вашей конкретной ситуации.

Ключевые выводы

• Любой запрос — каким бы неформальным он ни был — может быть DSAR, а одномесячный, обычно бесплатный срок начинается в день его поступления.
• Картографируйте каждое хранилище данных, включая рекламные и аналитические SDK, чтобы доступ и удаление были действительно полными.
• Проверяйте личность соразмерно и регистрируйте каждый запрос, чтобы доказать, что ответили вовремя.
• Записи согласия и аудиторский след FlexyConsent дают вам мгновенные, защищаемые доказательства для выполнения запросов на доступ, удаление и возражение.