O que é realmente um DSAR

Um pedido de acesso do titular dos dados (DSAR) é o momento em que um utilizador exerce os direitos que o RGPD lhe concede sobre os seus dados pessoais. Para um publisher móvel, esse “titular dos dados” é um dos seus jogadores ou utilizadores, e o pedido pode chegar por e-mail, ticket de suporte, avaliação na loja de aplicações ou formulário dentro da app. O gatilho é simples: alguém quer saber o que tem sobre ele — ou quer que atue sobre isso.

É fundamental perceber que um DSAR não precisa de mencionar o RGPD, usar a palavra “DSAR” nem seguir qualquer modelo. Uma mensagem de uma só linha como “envie-me os meus dados” ou “elimine a minha conta” aciona o relógio com a mesma firmeza que uma carta jurídica formal. Tratar como válidos apenas os pedidos com aparência formal é uma forma rápida de falhar um prazo.

Os direitos por trás do pedido

Os DSAR agrupam vários direitos distintos, e a mesma mensagem pode invocar mais do que um. Saber qual é qual determina o que tem efetivamente de fazer.

• Acesso — o utilizador pode pedir uma cópia dos seus dados pessoais mais o contexto: o que recolhe, porquê, com quem os partilha e durante quanto tempo os conserva.
• Apagamento (“direito a ser esquecido”) — eliminação dos seus dados, incluindo as cópias entregues a parceiros de publicidade e de análise, sujeita a exceções legais muito restritas.
• Portabilidade — os dados que ele lhe forneceu, devolvidos num formato estruturado e legível por máquina como JSON ou CSV, para que possam ser transferidos para outro lugar.
• Retificação — correção de dados inexatos ou incompletos, por exemplo um e-mail ou uma região errados.

Direitos relacionados — a oposição ao tratamento e a limitação — costumam acompanhar estes, especialmente em torno da personalização publicitária, onde um utilizador pode retirar o consentimento em vez de eliminar totalmente a sua conta.

Os prazos são rigorosos

Tem de responder sem demora indevida e no prazo de um mês de calendário a contar da receção do pedido. O relógio começa no dia em que o pedido chega, não no dia em que alguém da sua equipa repara nele. Pode prolongar por mais dois meses em pedidos genuinamente complexos, mas apenas se informar o utilizador dentro desse primeiro mês e explicar porquê.

As respostas são normalmente gratuitas. Só pode cobrar uma taxa razoável ou recusar quando um pedido for manifestamente infundado ou excessivo, e o ónus de o provar recai sobre si. Para a maioria dos publishers, o pressuposto seguro é: gratuito e dentro de trinta dias. Falhar o prazo é exatamente o tipo de lapso que os reguladores apontam ao avaliar coimas.

Criar um fluxo de trabalho escalável

Os publishers que lidam com os DSAR com calma transformaram-nos num processo repetível em vez de um exercício de combate a incêndios. Um fluxo de trabalho viável tem este aspeto:

• Receção. Publique um único canal divulgado — um formulário dentro da app ou um endereço dedicado privacy@ — e encaminhe tudo por ele para que nada se perca nas filas de suporte.
• Verifique a identidade. Confirme que quem pede é o titular da conta, mas peça apenas o necessário. Exigir a digitalização de um passaporte para procurar um ID dentro do jogo é, em si, um problema de conformidade.
• Registe e marque a data. Anote a data de chegada de imediato; é o seu ponto de referência para o prazo.
• Localize os dados. Mantenha um mapa de dados de cada repositório — o seu backend, registos de falhas, análise, SDK de publicidade, CRM — que toque dados de utilizador, indexado por um identificador estável.
• Satisfaça e responda. Exporte, elimine ou corrija conforme pedido, propague os apagamentos aos subcontratantes e responda em linguagem clara.
• Feche o ciclo. Arquive o pedido e a sua resposta como prova de que atuou a tempo.

Erros comuns

A maioria das falhas é operacional, não jurídica. Esteja atento a estas:

• Repositórios de dados esquecidos. Os SDK de publicidade e de atribuição, os fornecedores de notificações push e os relatores de falhas armazenam todos dados de utilizador. Um apagamento que os ignore está incompleto.
• Recolha excessiva durante a verificação, transformando um pedido de privacidade num risco de privacidade.
• Tratar mensagens informais como não-pedidos e deixar o mês expirar.
• Falta de prova de consentimento. Se um utilizador contestar que alguma vez teve um fundamento legal para tratar os seus dados para publicidade, precisa de mostrar a que ele consentiu e quando.

Como um CMP torna os DSAR geríveis

É aqui que a sua camada de consentimento prova o seu valor. Um DSAR é muito mais fácil de responder quando consegue mostrar instantaneamente a que um utilizador consentiu, quando e sob que enquadramento. O FlexyConsent — uma CMP certificada pela Google que suporta IAB TCF 2.4 e Google Consent Mode v2 — guarda no seu website um registo de consentimento com data e hora para cada visitante, sob uma chave aleatória. Quando chega um pedido de acesso, esse registo faz parte da sua resposta: o domínio, a decisão (aceite, rejeitada ou parcialmente aceite), onde foi tomada e se o Global Privacy Control foi aplicado; com essa chave pode descarregá-lo ou apagá-lo. Juntar esse histórico de consentimento ao seu mapa de dados transforma um DSAR de uma correria numa simples consulta.

Este artigo é informação geral para publishers e não constitui aconselhamento jurídico; consulte um profissional qualificado para a sua situação específica.

Principais conclusões

• Qualquer pedido — por mais informal que seja — pode ser um DSAR, e o prazo de um mês, normalmente gratuito, começa no dia em que chega.
• Mapeie cada repositório de dados, incluindo os SDK de publicidade e análise, para que o acesso e o apagamento sejam realmente completos.
• Verifique a identidade de forma proporcional e registe cada pedido para provar que respondeu a tempo.
• Os registos de consentimento do FlexyConsent ajudam-no a responder a pedidos de acesso e apagamento no seu website: pode descarregar ou apagar um registo através da sua chave.