RIPD: como elaborar o relatório de impacto da LGPD

O que é o RIPD e por que ele existe

O Relatório de Impacto à Proteção de Dados Pessoais (RIPD) é o documento previsto no artigo 5º, inciso XVII, da LGPD que descreve os processos de tratamento de dados pessoais capazes de gerar riscos às liberdades civis e aos direitos fundamentais dos titulares. Ele é o equivalente brasileiro do DPIA (Data Protection Impact Assessment) do GDPR europeu, e cumpre a mesma função: forçar a organização a mapear, antes de operar, o que pode dar errado com os dados que ela coleta.

Na prática, o RIPD é a peça que transforma a conformidade de discurso em evidência. Quando a ANPD questiona uma empresa sobre determinada operação — uma câmera com reconhecimento facial na recepção, um sistema de score de crédito, uma base de saúde ocupacional — o RIPD é o documento que demonstra que a decisão foi tomada de forma fundamentada, com medidas de mitigação proporcionais ao risco identificado. Sem ele, a defesa da empresa vira palavra contra palavra.

Vale destacar um ponto que gera confusão frequente: o RIPD não é o mesmo que o inventário de dados (ROPA, ou registro de operações de tratamento, previsto no artigo 37). O inventário é uma lista abrangente de tudo que a empresa trata. O RIPD é um mergulho profundo em um tratamento específico de alto risco. Um alimenta o outro — é a partir do inventário que se identificam quais operações merecem um RIPD dedicado.

Quando o RIPD é obrigatório

A LGPD não traz uma lista fechada de hipóteses obrigatórias, o que é uma das maiores fontes de dúvida entre encarregados de dados no Brasil. O artigo 38 diz que a autoridade nacional "poderá determinar ao controlador que elabore relatório de impacto" — ou seja, há uma obrigação sob demanda. Já o artigo 10, §3º, prevê o RIPD quando o tratamento se baseia em legítimo interesse e a ANPD solicita. E o artigo 5º, XVII, o define de forma genérica.

Essa aparente flexibilidade não deve ser lida como opcionalidade. A ANPD já sinalizou, em guias orientativos e no Regulamento de Comunicação de Incidentes, que espera RIPD elaborado previamente em cenários de risco elevado. Na prática consolidada do mercado, e seguindo a orientação análoga do EDPB europeu, considere o RIPD necessário quando o tratamento envolver ao menos dois dos critérios abaixo:

• Dados sensíveis ou de alto impacto — saúde, biometria, origem racial, convicção religiosa, opinião política, filiação sindical, vida sexual, dados genéticos.
• Dados de crianças e adolescentes — tratamento no melhor interesse do menor exige cuidado reforçado (art. 14).
• Monitoramento sistemático — CFTV com analytics, rastreamento de frota, monitoramento de produtividade de colaboradores, geolocalização contínua.
• Decisões automatizadas com efeito jurídico — score de crédito, triagem automática de currículos, precificação dinâmica individualizada, aprovação de sinistro por algoritmo.
• Tratamento em larga escala — volume de titulares, abrangência geográfica, duração e permanência da operação.
• Cruzamento ou enriquecimento de bases — combinação de dados de origens distintas para gerar novos perfis.
• Uso de tecnologia inovadora — IA generativa sobre base de clientes, reconhecimento facial, IoT em ambiente corporativo.
• Transferência internacional — especialmente para países sem grau adequado de proteção reconhecido.

Uma regra prática útil: se o tratamento é daqueles que você hesitaria em explicar publicamente ao titular, ele provavelmente demanda RIPD. O relatório serve justamente para responder à pergunta "por que fazemos isso e como controlamos o dano possível".

Estrutura do documento: o que precisa constar

Não existe formulário oficial imposto pela ANPD, mas o artigo 38, parágrafo único, define o conteúdo mínimo: descrição dos tipos de dados coletados, metodologia utilizada para coleta e garantia da segurança das informações, e a análise do controlador quanto às medidas, salvaguardas e mecanismos de mitigação de risco adotados. A partir desse mínimo legal, um RIPD defensável costuma organizar-se em blocos.

1. Identificação e contexto — quem é o controlador, quem é o operador, quem é o encarregado (DPO), data de elaboração, versão, área responsável pelo processo e sistema envolvido.
2. Descrição do tratamento — finalidade específica (nunca genérica como "melhorar a experiência"), natureza dos dados, categorias de titulares, volume estimado, ciclo de vida do dado do momento da coleta até o descarte, prazo de retenção e sua justificativa.
3. Base legal e necessidade — qual das dez hipóteses do artigo 7º (ou das oito do artigo 11, para dados sensíveis) fundamenta o tratamento, e a demonstração de que a finalidade não poderia ser atingida por meio menos invasivo. Esse teste de necessidade e proporcionalidade é o coração do RIPD.
4. Fluxo de dados — diagrama ou descrição de origem, sistemas de armazenamento, integrações, compartilhamentos com terceiros, subprocessadores e localização física dos servidores.
5. Identificação de riscos — ameaças concretas ao titular, não à empresa: acesso indevido, vazamento, uso para finalidade diversa, discriminação algorítmica, perda de disponibilidade em contexto crítico, reidentificação de dado pseudonimizado.
6. Avaliação de risco — probabilidade × impacto, com escala definida e critério declarado, produzindo risco inerente antes dos controles.
7. Medidas de mitigação — controles técnicos e organizacionais aplicados, com responsável e prazo, resultando no risco residual.
8. Conclusão e aprovação — parecer do encarregado, decisão de prosseguir, prosseguir com condições ou não prosseguir, e assinatura da alta direção.

O risco que o RIPD mede é o risco ao titular do dado, não o risco de multa para a empresa. Documentos que invertem essa perspectiva costumam ser rejeitados em auditoria — e, pior, deixam de identificar exatamente os danos que deveriam prevenir.

Como conduzir a análise de risco na prática

A etapa que mais trava projetos de RIPD é a avaliação de risco, porque exige transformar uma preocupação abstrata em algo mensurável. O caminho mais estável é adotar uma matriz simples de probabilidade e impacto, com três a cinco níveis, e ancorar cada nível em critérios objetivos escritos antes da avaliação. "Impacto alto" precisa significar algo como "exposição de dado sensível de mais de mil titulares com potencial de discriminação ou dano financeiro direto" — não uma sensação do avaliador.

Para cada risco identificado, registre o cenário completo: qual ameaça, explorando qual vulnerabilidade, atingindo qual ativo, causando qual dano ao titular. Um risco escrito como "vazamento de dados" é inútil. Um risco escrito como "colaborador do RH com acesso amplo à base exporta planilha de exames admissionais para dispositivo pessoal, expondo dado de saúde de 2.400 empregados" permite escolher controle e medir eficácia.

As medidas de mitigação devem então responder diretamente ao cenário descrito. No exemplo acima, os controles pertinentes seriam segregação de perfis com acesso mínimo necessário, DLP bloqueando exportação de planilhas com padrão de CPF, criptografia em repouso, log de acesso com retenção e revisão trimestral de permissões. Cada controle recebe responsável nominal, prazo e forma de verificação. Depois de aplicados, reavalia-se probabilidade e impacto para obter o risco residual.

Se o risco residual permanecer alto mesmo após todas as medidas viáveis, a LGPD prevê o caminho da consulta prévia à ANPD. Na prática brasileira, esse cenário é raro — mas registrar que a hipótese foi considerada e por que foi afastada fortalece muito o documento perante uma fiscalização.

Erros que invalidam o relatório

O primeiro e mais comum é o RIPD-modelo: um documento genérico baixado da internet, preenchido com o nome da empresa e arquivado. Ele não descreve o tratamento real, não reflete os sistemas efetivamente em uso e não sobrevive à primeira pergunta técnica de um fiscal. Um RIPD só tem valor probatório se for reconhecível como retrato da operação concreta.

O segundo é tratar o RIPD como documento estático. Tratamentos mudam: entra um novo fornecedor de nuvem, o RH adota uma ferramenta de triagem por IA, a retenção de logs é ampliada. Cada mudança material exige revisão do relatório. A prática recomendada é revisão anual obrigatória, mais revisão extraordinária a cada alteração relevante de finalidade, base legal, volume, tecnologia ou subprocessador.

O terceiro é a elaboração isolada pelo jurídico. Um RIPD escrito sem TI não sabe onde o dado está armazenado, quem tem acesso privilegiado, se há backup fora do país ou se o log é imutável. Um RIPD escrito sem a área de negócio inventa finalidades que não correspondem ao processo real. O documento precisa nascer de uma conversa entre jurídico, TI, segurança da informação e o dono do processo — com o encarregado costurando as partes.

• Descrever finalidade de forma vaga ("uso interno", "fins administrativos") — inviabiliza o teste de necessidade.
• Omitir subprocessadores e integrações via API, que são hoje a principal superfície de vazamento.
• Listar controles planejados como se estivessem implementados — divergência entre documento e realidade agrava a situação em fiscalização.
• Não definir prazo de retenção nem procedimento de descarte verificável.
• Deixar o relatório sem aprovação formal da alta direção, o que enfraquece a governança.

Da documentação à implementação: o papel da infraestrutura

Um RIPD bem escrito é apenas metade do trabalho. A outra metade é sustentar tecnicamente as medidas que ele promete. Controle de acesso baseado em função, MFA, criptografia em repouso e em trânsito, segmentação de rede, backup com retenção testada e restauração validada, logs centralizados e imutáveis, gestão de vulnerabilidades e resposta a incidente com prazo compatível com a comunicação à ANPD — todos esses itens aparecem como mitigação no papel e precisam existir no ambiente.

É nesse ponto que a conformidade deixa de ser um projeto jurídico e passa a ser um projeto de infraestrutura. Não adianta declarar no RIPD que os dados de saúde ocupacional estão criptografados se o compartilhamento acontece por planilha em pasta de rede aberta. Não adianta prometer detecção de incidente em 24 horas sem monitoramento ativo e alerta. O relatório cria obrigações verificáveis — e é assim que ele deve ser encarado desde a primeira linha.

A Duk Informática & Cloud atua exatamente nessa ponte entre o que a LGPD exige no papel e o que precisa estar rodando no ambiente. Com mais de 18 anos de mercado e 550+ empresas atendidas, a equipe implementa os controles que sustentam um RIPD defensável: hardening de identidade e MFA no Microsoft 365, políticas de DLP e classificação de dados, backup com retenção e teste de restauração, segmentação de rede, monitoramento contínuo e resposta a incidentes com SLA. Como Microsoft Gold Partner, a Duk também apoia a adequação de ambientes híbridos e a documentação técnica que o encarregado precisa anexar ao relatório — do diagrama de fluxo de dados à evidência de que cada controle listado está, de fato, ativo.

Se sua empresa já mapeou tratamentos de risco elevado e precisa converter o RIPD em controles reais, o caminho é começar pela lacuna entre o documento e o ambiente. Um diagnóstico técnico de infraestrutura e segurança mostra, item a item, o que já está coberto e o que ainda é promessa no papel.