Como fazer RIPD: quais informações levantar antes de elaborar o relatório

Um RIPD não começa no editor de texto. Ele começa muito antes, quando a organização reúne informações suficientes para entender o tratamento que será avaliado. Sem esse trabalho, o relatório pode virar uma descrição genérica, preenchida com respostas copiadas de políticas internas e sem conexão com o funcionamento real dos sistemas. O resultado parece completo, mas não ajuda a identificar riscos, escolher salvaguardas ou decidir se o projeto deve avançar.

Por isso, quem pesquisa como fazer RIPD deve começar por um levantamento estruturado. É preciso saber qual projeto está em análise, quais operações acontecem desde a coleta até a eliminação, quais dados e titulares participam, qual é a finalidade, qual hipótese legal foi considerada, quem acessa as informações, com quem elas são compartilhadas, quais ameaças existem e quais medidas já estão implementadas. Só então o relatório consegue refletir o risco do tratamento e propor melhorias realistas.

O RIPD documenta processos de tratamento que podem gerar alto risco às liberdades civis e aos direitos fundamentais dos titulares, descrevendo também medidas, salvaguardas e mecanismos de mitigação. A ANPD recomenda que ele seja elaborado antes do início do tratamento quando essa possibilidade de alto risco existir. A análise deve considerar o caso concreto, e não apenas marcar uma lista fixa de critérios.

Alguns sinais justificam uma investigação mais cuidadosa: grande volume de titulares, dados sensíveis, crianças ou outros públicos vulneráveis, tecnologias emergentes, monitoramento de áreas acessíveis ao público, decisões automatizadas com efeitos relevantes, perfilamento, compartilhamentos extensos ou combinação de bases. O uso de legítimo interesse também pode levar à elaboração de RIPD quando houver solicitação da autoridade ou quando a governança identificar riscos significativos.

O primeiro levantamento deve responder qual projeto, produto, processo ou mudança motivou o RIPD. Dê um nome claro ao escopo e explique por que ele está sendo avaliado agora. Pode ser a implantação de um sistema de reconhecimento facial, a criação de um programa de prevenção a fraude, a migração de um CRM, a oferta de um serviço de saúde digital ou a integração de dados entre empresas.

Esse recorte evita dois erros opostos. O primeiro é criar um RIPD tão amplo que ninguém consegue identificar quais riscos pertencem a qual atividade. O segundo é analisar apenas uma tela do sistema e esquecer integrações, fornecedores, rotinas manuais e usos posteriores. O escopo deve ser suficientemente específico para permitir uma avaliação, mas amplo o bastante para representar o ciclo de vida do tratamento.

O RIPD é responsabilidade do controlador, mas nenhuma área conhece sozinha todos os detalhes do tratamento. O DPO ou encarregado pode coordenar o trabalho, porém precisa ouvir quem desenhou o produto, opera o processo, administra os sistemas, gerencia contratos, trata incidentes e conhece os riscos do negócio. O jurídico interpreta requisitos; a segurança descreve ameaças e controles; a área de negócio explica a finalidade; e tecnologia mostra o fluxo técnico.

O RIPD precisa contar a história dos dados. Descreva onde ocorre a coleta, como ela é realizada, quais validações acontecem, onde os dados são armazenados, quem consulta, quais análises são feitas, quais decisões resultam do tratamento, com quem há compartilhamento e como ocorre o descarte. Não se limite ao fluxo ideal desenhado no projeto. Registre também planilhas auxiliares, exportações, acessos manuais, integrações temporárias e cópias criadas para testes.

Liste os tipos de dados de forma completa. Nome, e-mail e documento podem parecer suficientes no primeiro desenho, mas o risco muda quando entram localização, comportamento, saúde, biometria, dados financeiros, voz, imagem ou inferências produzidas pelo sistema. Identifique também as categorias de titulares: clientes, empregados, candidatos, pacientes, visitantes, dependentes, crianças, idosos, fornecedores ou pessoas que não têm relação direta com a organização.

A origem é especialmente importante quando os dados vêm de terceiros, fontes públicas, corretores de informação, parceiros ou bases antigas. Pergunte o que foi informado ao titular, se a organização pode demonstrar a procedência, se a finalidade original é compatível e se há algum limite para o reuso. Um RIPD que conhece apenas o banco de dados, mas não sabe como as informações foram obtidas, começa com uma lacuna relevante.

Para cada finalidade, registre a hipótese legal considerada e a justificativa. Não use uma única base para todas as operações de um sistema. A mesma plataforma pode tratar dados para executar um contrato, cumprir obrigação legal, prevenir fraude, atender uma solicitação do titular e enviar marketing. Cada finalidade precisa ser analisada separadamente, inclusive quanto à necessidade, transparência, retenção e compartilhamento.

Mapeie os sistemas que participam do tratamento e os papéis de cada fornecedor. Inclua aplicações principais, bancos de dados, ferramentas de analytics, serviços de comunicação, ambientes de backup, dispositivos, integrações e arquivos manuais. Identifique quem decide a finalidade, quem executa instruções e se existe outro controlador com objetivo próprio. Essa distinção ajuda a compreender responsabilidades, contratos, acessos e pontos de exposição.

O risco do RIPD não é apenas a possibilidade de um ataque técnico. Avalie perda de confidencialidade, integridade ou disponibilidade, mas também uso incompatível, acesso excessivo, retenção indevida, discriminação, erro de perfil, vigilância desproporcional, reidentificação, impedimento de direitos e decisões automatizadas sem contestação. Para cada risco, estime probabilidade e impacto sobre os titulares, explicando os critérios usados.

As evidências podem incluir diagramas de arquitetura, inventário de ativos, contratos, registros de acesso, testes de segurança, procedimentos de atendimento, indicadores, reclamações, avaliações de fornecedores, políticas de retenção e resultados de auditorias. O objetivo não é anexar documentos sem critério, mas permitir que outra pessoa entenda de onde vieram as informações e por que o risco foi classificado daquela forma.

Depois de identificar os riscos, reúna as medidas que já existem e as ações que ainda precisam ser executadas. Diferencie controle implementado de promessa futura. Criptografia, segregação de acesso, minimização, pseudonimização, monitoramento, treinamento, revisão humana, retenção limitada, resposta a incidentes e canal de direitos podem aparecer em conjunto, mas precisam estar vinculados ao risco que reduzem.

Antes de finalizar, registre quem revisou o levantamento e quais opiniões foram consideradas. O DPO, o jurídico, a segurança e a área de negócio podem enxergar riscos diferentes. Divergências não precisam ser escondidas: documentar uma discordância e a razão da decisão adotada fortalece a prestação de contas. Também é importante indicar se o tratamento foi aprovado, aprovado com condições, adiado até a implementação de medidas ou rejeitado.

Grande parte do trabalho preparatório do RIPD já existe na rotina de governança: o Mapeamento de Dados registra tratamentos, sistemas, finalidades, bases legais, titulares, operadores e retenção; a gestão de riscos organiza ameaças e impactos; os controles de segurança mostram salvaguardas; e os responsáveis conhecem as pendências. O problema é quando essas informações ficam espalhadas em planilhas, e-mails, contratos e documentos que não se relacionam.

Com a funcionalidade de RIPD e DPIA da LGPD Cloud, a equipe pode reunir os elementos do levantamento em torno do projeto ou tratamento correspondente. Isso facilita consultar o fluxo de dados, relacionar riscos e medidas, registrar responsáveis e acompanhar a evolução das ações. Quando houver uma nova versão do sistema, um fornecedor diferente ou um risco agravado, a revisão parte do contexto existente, em vez de repetir todo o levantamento sem histórico.

Saber como fazer RIPD não é apenas conhecer a estrutura final do documento. É saber quais perguntas fazer antes de escrevê-lo. Um relatório útil depende de informações confiáveis sobre projeto, fluxo, dados, titulares, finalidade, base legal, sistemas, fornecedores, riscos, medidas e responsáveis. Quanto melhor for esse levantamento, mais realista será a análise de impacto e mais fácil será decidir o que precisa ser ajustado.

A LGPD Cloud apoia essa preparação ao reunir informações de tratamento, riscos e salvaguardas em um contexto único, relacionando o RIPD à atividade correspondente e preservando o histórico para futuras revisões. Assim, o relatório deixa de ser um arquivo isolado produzido no fim do projeto e passa a fazer parte da governança contínua. Fale com a LGPD Cloud para entender como organizar esse fluxo.

Consulte as perguntas e respostas da ANPD sobre RIPD e o texto compilado da LGPD, especialmente os artigos 5º, inciso XVII, 6º, 10, 38 e 50. A aplicação ao caso concreto deve considerar regulamentações setoriais, orientações atualizadas e avaliação profissional.