Saiba quando iniciar uma PIA, como escolher o nível de análise e como mapear dados, classificar riscos, definir medidas e documentar decisões antes de mudar um tratamento.
Adotar um CRM em nuvem parece uma decisão comercial simples, mas a mudança pode centralizar históricos de compra, contatos, preferências e registros de atendimento. Sem análise prévia, a empresa pode descobrir tarde demais que migrou campos desnecessários, concedeu acessos amplos ou conectou ferramentas com finalidades incompatíveis. Uma Privacy Impact Assessment (PIA) permite examinar esses efeitos enquanto contratos, configurações e processos ainda podem ser alterados.
Considere uma pequena distribuidora que pretende colocar o CRM em operação em prazo curto. A equipe precisa decidir quais dados migrar, quem terá acesso, quais integrações serão ativadas e por quanto tempo os registros permanecerão disponíveis. A PIA organiza essas decisões, evidencia possíveis impactos para clientes, leads e funcionários e mostra quando uma análise simplificada já não é suficiente. Ela não serve apenas para produzir um documento: seu propósito é melhorar a decisão antes que o tratamento se consolide.
Principais pontos
- A PIA reduz incertezas quando é realizada antes da contratação, do lançamento ou de uma mudança relevante no tratamento.
- PIA, DPIA e RIPD podem compartilhar métodos, mas diferem quanto à finalidade, ao grau de formalidade, ao contexto de uso e aos requisitos aplicáveis.
- Riscos à privacidade incluem coleta excessiva, uso inesperado, retenção prolongada e restrições aos direitos, não apenas vazamentos.
- Uma avaliação enxuta precisa relacionar cada risco a evidências, medidas, responsáveis, prazos e uma decisão verificável.
- Consentimento e legítimo interesse não são escolhas automáticas; a base legal deve ser definida conforme a finalidade, o contexto e os requisitos da LGPD.
O que é uma Privacy Impact Assessment e qual problema ela resolve
Uma Privacy Impact Assessment é um processo estruturado para examinar como uma atividade, sistema, produto, fornecedor ou mudança operacional pode afetar a privacidade das pessoas. O trabalho deve começar, sempre que possível, durante o planejamento. Seu resultado apoia uma decisão prática: prosseguir, impor condições, reduzir o tratamento, escolher outra solução, suspender a iniciativa ou encaminhá-la para avaliação aprofundada.
No caso da distribuidora, a PIA não se limita a perguntar se o CRM possui criptografia. Ela verifica se todos os campos são necessários, de onde os dados serão obtidos, quem poderá consultá-los, se o fornecedor pretende tratá-los para finalidades próprias, como os titulares serão informados e se o descarte funciona. Privacidade não é sinônimo de segurança da informação: um banco de dados tecnicamente protegido ainda pode gerar impactos se guardar informações em excesso, impedir o exercício de direitos ou sustentar um uso incompatível com a expectativa legítima das pessoas.
A avaliação também deve observar consequências que não dependem de um incidente de segurança. Uma classificação incorreta pode excluir um cliente de uma condição comercial; uma anotação livre pode expor informação íntima a funcionários sem necessidade; uma integração pode replicar contatos para um serviço do qual a pessoa nunca ouviu falar. A PIA torna essas relações visíveis e permite escolher controles adequados a cada problema.
O processo não oferece garantia automática de conformidade. Sua qualidade depende do escopo, das evidências disponíveis, da participação de quem conhece a operação e da autoridade concedida para mudar o projeto. Uma PIA útil expõe premissas e incertezas. Um formulário preenchido apenas para aprovar uma decisão já tomada tende a esconder justamente os pontos que exigem discussão.
PIA, DPIA e RIPD: nomes próximos, funções diferentes
PIA é uma expressão abrangente, usada em diferentes metodologias para avaliações de impacto à privacidade. Ela pode incluir aspectos que ultrapassam a proteção de dados pessoais, como efeitos de vigilância, perda de autonomia ou mudanças na relação entre uma organização e seu público. Seu formato e grau de formalidade variam conforme a governança adotada. Por isso, chamar um questionário interno de PIA não demonstra, por si só, que houve análise suficiente.
DPIA, sigla de Data Protection Impact Assessment, costuma designar uma avaliação estruturada de impactos relacionados ao tratamento de dados pessoais, especialmente em contextos de maior risco. A expressão é associada a regimes e metodologias estrangeiros e não constitui a denominação adotada pela LGPD para o relatório regulado no Brasil. Uma organização brasileira pode usar uma metodologia de DPIA como referência interna, mas deve verificar separadamente quais obrigações jurídicas se aplicam ao tratamento.
RIPD é o Relatório de Impacto à Proteção de Dados Pessoais definido pelo artigo 5º, inciso XVII, da LGPD. A definição legal menciona documentação do controlador que descreve processos de tratamento capazes de gerar riscos às liberdades civis e aos direitos fundamentais, bem como medidas, salvaguardas e mecanismos de mitigação. O artigo 38 prevê que a ANPD pode determinar ao controlador a elaboração do relatório, inclusive em relação a dados sensíveis, observados os segredos comercial e industrial.
As referências aos artigos 5º, XVII, e 38 são essenciais, mas não esgotam o tema. O artigo 10, parágrafo 3º, também prevê a possibilidade de a ANPD solicitar RIPD quando o tratamento estiver fundamentado no legítimo interesse. Outras disposições da LGPD, regulamentações, orientações e determinações da Autoridade podem influenciar escopo, conteúdo ou oportunidade do documento. Portanto, antes de afirmar que uma PIA interna atende a uma obrigação formal, é necessário conferir a [LGPD](https://www.planalto.gov.br/ccivil03/ato2015-2018/2018/lei/l13709.htm), as publicações vigentes no [portal oficial da ANPD](https://www.gov.br/anpd/pt-br) e as particularidades do caso.
Na prática, os instrumentos podem compartilhar inventário de dados, análise de necessidade, consulta a áreas internas, avaliação de riscos e plano de tratamento. A diferença operacional está na finalidade atribuída ao trabalho e no padrão que o documento precisa cumprir. Uma PIA pode funcionar como prevenção interna; uma DPIA pode representar uma metodologia aprofundada; e o RIPD precisa ser compatível com a definição e com os requisitos jurídicos ou regulatórios aplicáveis.
| Instrumento | Finalidade | Conteúdo mínimo operacional | Grau de formalidade | Circunstâncias de uso |
|---|---|---|---|---|
| PIA | Antecipar impactos à privacidade e apoiar decisões internas | Escopo, fluxo de dados, pessoas afetadas, impactos, medidas, responsáveis e decisão | Variável, conforme a metodologia e o risco | Planejamento de produtos, sistemas, fornecedores, integrações ou mudanças relevantes |
| DPIA | Aprofundar impactos do tratamento de dados e demonstrar avaliação estruturada | Descrição detalhada do tratamento, necessidade, proporcionalidade, riscos, consultas, controles e risco residual | Em geral, mais elevado e sujeito à metodologia ou ao regime jurídico adotado | Tratamentos complexos ou de maior risco e contextos em que a metodologia ou a legislação aplicável a exija |
| RIPD | Documentar o tratamento e a mitigação de riscos conforme a LGPD e os requisitos aplicáveis | Ao menos a descrição dos processos capazes de gerar riscos e das medidas, salvaguardas e mecanismos de mitigação, sem prejuízo de requisitos adicionais | Formal, por ser documento definido na LGPD e passível de solicitação pela ANPD | Quando exigido pela LGPD, por regulamentação, orientação ou determinação aplicável, inclusive nos casos em que a ANPD o solicite |
Quando vale a pena iniciar uma PIA
A triagem deve ser proporcional à mudança. Comprar uma cadeira para o escritório não exige uma PIA; integrar o CRM a uma plataforma que recebe contatos, históricos e preferências pode exigir. O melhor momento é o planejamento, quando contratos, campos, permissões e arquitetura ainda podem ser alterados sem interromper uma operação ativa.
Os sinais de atenção justificam uma triagem, mas não funcionam como limiares legais isolados. Para uma PME, uma regra interna simples pode separar três resultados: encerrar a triagem com justificativa, realizar uma PIA enxuta ou encaminhar o caso para avaliação aprofundada. Esses critérios devem ser adaptados à atividade, e não apresentados como classificação oficial da ANPD.
A triagem pode ser encerrada quando a iniciativa não envolve dados pessoais ou quando a alteração é estritamente técnica, não amplia categorias, finalidades, acessos, compartilhamentos, retenção ou consequências para titulares. Ainda assim, convém registrar em poucas linhas o motivo da dispensa. A ausência de registro dificulta demonstrar posteriormente que a decisão foi consciente.
A PIA enxuta é adequada quando há tratamento de dados pessoais ou mudança material, mas o fluxo é delimitado, os titulares e destinatários são conhecidos, os controles podem ser verificados e não aparecem indicadores fortes de impacto grave. Já a avaliação aprofundada deve ser considerada quando um único fator crítico estiver presente ou quando vários fatores moderados se combinarem. Se houver dúvida razoável sobre a gravidade, a escolha prudente é escalar.
Um sistema existente também merece nova análise quando muda a finalidade, o público, o período de retenção, a base legal, a lógica de decisão ou a rede de destinatários. Se a distribuidora passar a usar o histórico do CRM para criar perfis comerciais ou alimentar uma ferramenta externa, a avaliação original deve ser reaberta, ainda que o fornecedor principal permaneça o mesmo.
- Novas categorias de dados, dados sensíveis ou aumento material do volume e do alcance.
- Monitoramento sistemático, perfilização ou decisões capazes de produzir efeitos relevantes para a pessoa.
- Compartilhamento com novos fornecedores, parceiros, empresas do grupo ou destinatários no exterior.
- Tratamento de dados de crianças, adolescentes ou pessoas em situação de vulnerabilidade.
- Alteração de finalidade, base legal, retenção, permissões, fontes ou integrações.
- Dificuldade de informar os titulares, permitir oposição quando cabível ou atender outros direitos.
- Tecnologia nova para a organização, fluxo difícil de explicar ou impossibilidade de testar controles.
- Impacto potencialmente grave ou combinação de diversos sinais moderados.
| Resultado da triagem | Critérios práticos | Providência |
|---|---|---|
| Dispensar a PIA | Não há dados pessoais ou não existe mudança material em finalidade, categorias, acesso, compartilhamento, retenção ou impacto | Registrar a justificativa da triagem e os fatos verificados |
| Fazer PIA enxuta | Fluxo delimitado, impacto previsível, controles verificáveis e ausência de fator crítico | Aplicar as sete etapas, tratar riscos e submeter a decisão ao responsável pelo projeto |
| Encaminhar para avaliação aprofundada | Dado sensível em contexto relevante, público vulnerável, monitoramento amplo, perfilização com efeitos, tecnologia complexa, grande dificuldade para exercer direitos ou possível impacto grave | Ampliar participantes, evidências e revisão jurídica; avaliar a necessidade de DPIA estruturada ou RIPD |
| Suspender até esclarecer | Faltam informações essenciais sobre fornecedor, finalidade, reutilização, destinatários ou funcionamento do controle | Não aprovar o tratamento antes de obter e validar as informações |
Como conduzir uma PIA enxuta em sete etapas
Comece delimitando a iniciativa e a decisão que precisa ser tomada. Avaliar todos os dados da empresa cria um escopo impossível de verificar. No exemplo, o recorte abrange a migração de contatos, o uso comercial, a integração com e-mail, os acessos das equipes e o descarte no CRM.
As sete etapas abaixo formam um ciclo único: definir, mapear, justificar, consultar, identificar impactos, tratar riscos e decidir. O registro produzido em uma etapa deve sustentar a seguinte. Se a finalidade não estiver clara, por exemplo, não será possível avaliar necessidade, base legal ou compatibilidade de uma integração.
Um prazo interno de 10 dias úteis pode ser adotado para esse projeto simples se for compatível com o volume de trabalho, a disponibilidade dos participantes e a necessidade de correções. Trata-se apenas de um exemplo de planejamento, não de prazo previsto na LGPD nem de padrão aplicável a toda PIA. Projetos sensíveis, incompletos ou complexos devem receber o tempo necessário para uma análise responsável.
A base legal exige avaliação própria. O consentimento não deve ser escolhido apenas por parecer uma opção mais segura, e o legítimo interesse não autoriza qualquer uso comercial. Conforme os artigos 7º, IX, e 10 da LGPD e as orientações da ANPD, a análise de legítimo interesse deve verificar a finalidade legítima, considerar situações concretas, utilizar somente os dados estritamente necessários e adotar medidas que assegurem transparência e proteção aos direitos e liberdades fundamentais. A metodologia de balanceamento indicada pela ANPD organiza a análise em finalidade, necessidade, balanceamento e salvaguardas. As legítimas expectativas dos titulares integram o exame do contexto e do balanceamento, mas não substituem os demais requisitos.
A decisão final não deve ficar dispersa em e-mails. Ela precisa declarar se a iniciativa foi aprovada, aprovada com condições, devolvida para redesenho, suspensa ou encaminhada para avaliação aprofundada. A aprovação condicional só deve produzir efeitos depois que as condições impeditivas forem verificadas ou quando houver uma justificativa expressa para a implantação em fases.
- Defina a iniciativa, o escopo, o responsável e a decisão que a avaliação apoiará.
- Mapeie origem, categorias de dados, titulares, sistemas, acessos, compartilhamentos, retenção e descarte.
- Registre finalidades, necessidade, base legal em análise, contexto e premissas.
- Consulte as áreas que conhecem o projeto, a tecnologia, o fornecedor e o contato com titulares.
- Identifique eventos e consequências possíveis para as pessoas, não apenas perdas empresariais.
- Avalie os riscos e associe medidas, evidências esperadas, responsáveis e prazos.
- Registre a decisão final, o risco residual, as condições de aprovação e os gatilhos de revisão.
| Etapa | Registro de exemplo |
|---|---|
| 1. Escopo | Migrar contatos ativos para o CRM e decidir se o lançamento pode ocorrer com integração de e-mail |
| 2. Mapeamento | Dados vêm do sistema comercial; incluem identificação, contato e histórico de atendimento; acesso por vendas e suporte; fornecedor armazena a base |
| 3. Finalidade e necessidade | Finalidade: administrar relacionamento e atendimento; campos de identificação e contato são necessários; campo livre de observações será limitado |
| 4. Consulta | Vendas confirmou o uso diário; suporte identificou anotações excessivas; TI validou perfis de acesso; compras solicitou esclarecimentos ao fornecedor |
| 5. Impactos | Permissão genérica pode permitir consulta fora da carteira; texto livre pode registrar informação desnecessária; integração total pode ampliar compartilhamento |
| 6. Tratamento | Criar perfis separados, restringir texto livre, enviar à integração apenas atributos necessários e obter evidências de configuração antes do lançamento |
| 7. Decisão | Aprovar com condições; responsável: gerente do projeto; lançamento depende da validação dos perfis e da integração; reabrir a PIA se houver perfilização ou novo destinatário |
Como analisar riscos sem olhar apenas para vazamentos
Uma análise consistente separa evento, consequência e condição de ocorrência. Um vendedor consultar contatos fora de sua carteira é o evento; constrangimento, fraude, uso inesperado ou perda de controle podem ser consequências. Permissões genéricas, contas compartilhadas e ausência de registros de acesso tornam o evento mais provável.
A probabilidade deve refletir evidências observáveis, como exposição do fluxo, histórico de falhas, quantidade de usuários, facilidade de abuso e existência de barreiras testadas. A gravidade deve considerar natureza dos dados, quantidade e vulnerabilidade das pessoas, duração do efeito, possibilidade de discriminação, fraude ou dano reputacional e dificuldade de reversão. Volume elevado pode ampliar o alcance, mas um único registro também pode causar impacto grave dependendo do conteúdo e do contexto.
Uma escala qualitativa de três níveis ajuda uma PME a comparar situações sem fingir precisão científica. O resultado inicial deve ser calculado antes das medidas adicionais; depois, a equipe estima o risco residual considerando apenas controles implementados ou cuja implantação seja condição verificável para a aprovação. Promessas futuras sem responsável e evidência não devem reduzir a classificação.
No CRM, restringir permissões reduz consultas indevidas, mas não corrige coleta excessiva. Para esse segundo problema, a medida pode ser retirar campos obrigatórios, bloquear determinados usos de texto livre ou limitar integrações. Cada risco exige um controle ligado à sua causa, e não uma lista genérica de segurança.
Como regra interna ilustrativa, resultados residuais de 1 ou 2 podem ser aceitos pelo responsável do processo com justificativa; resultados 3 ou 4 exigem tratamento, prazo e aprovação de nível compatível; resultados 6 ou 9 devem ser escalados e não devem ser aceitos rotineiramente. Além disso, qualquer risco de gravidade alta merece escalonamento mesmo quando a probabilidade estimada for baixa. Esses limiares não são determinados pela LGPD ou pela ANPD e precisam ser ajustados ao contexto da organização.
Uma regra de descarte após seis meses de inatividade pode ser justificável em determinado processo, desde que a finalidade, as obrigações de conservação e a operação permitam esse período. Não se trata de prazo geral imposto pela LGPD. Medidas preventivas devem entrar no produto e no processo, em abordagem relacionada ao [Privacy by Design](/privacy-by-design).
| Elemento | Nível 1 | Nível 2 | Nível 3 |
|---|---|---|---|
| Probabilidade | Baixa: depende de condições incomuns, há barreiras testadas e poucos pontos de exposição | Média: pode ocorrer no uso normal, há controles parciais ou vários usuários e integrações | Alta: já ocorreu, é fácil de executar ou faltam barreiras efetivas |
| Gravidade | Baixa: efeito limitado, reversível e sem consequência material previsível | Média: constrangimento, perda de controle ou dificuldade relevante, mas reparável | Alta: possível fraude, discriminação, exposição sensível, efeito duradouro ou difícil reversão |
| Matriz P × G | 1 a 2: registrar e monitorar | 3 a 4: tratar e obter aprovação | 6 a 9: escalar, aprofundar e considerar suspensão |
| Exemplo antes do controle | Não aplicável | Consulta indevida: probabilidade 2 e gravidade 2, resultado 4 | Não aplicável |
| Exemplo residual | Após perfis separados e teste de acesso: probabilidade 1 e gravidade 2, resultado 2 | Aceitação documentada pelo responsável, com monitoramento | Escalar se o controle não puder ser comprovado |
O que registrar para que a PIA continue útil
O registro precisa permitir que outra pessoa compreenda o que foi examinado, quais premissas sustentaram a decisão e o que ainda falta executar. Frases genéricas copiadas de um modelo não demonstram a análise. Evidências podem incluir mapas internos, testes de configuração, cláusulas contratuais, respostas do fornecedor, registros de consulta e atas de decisão, preservados conforme as regras documentais da empresa.
A rastreabilidade surge quando o mesmo identificador acompanha risco, evidência, medida, responsável, prazo e decisão. Assim, uma revisão futura não precisa reconstruir o raciocínio a partir de mensagens dispersas. O registro também deve distinguir medida planejada de medida implementada: somente a segunda, acompanhada de evidência adequada, pode justificar a redução do risco residual.
No exemplo abaixo, o prazo de exclusão em até 30 dias após uma solicitação válida ou evento contratualmente definido é apenas uma condição desenhada para o CRM hipotético. Sua adequação depende da natureza da solicitação, das hipóteses legais de conservação, das limitações técnicas e das obrigações aplicáveis. Ele não representa prazo universal da LGPD para exclusão de dados.
Defina ainda gatilhos de revisão. Para o CRM, uma checagem após seis meses pode ser escolhida como medida interna para confirmar permissões, minimização e descarte. Esse intervalo também é contextual, não uma exigência legal. Incidente, nova integração, alteração de finalidade, ampliação do público ou mudança importante no fornecedor exigem revisão antecipada.
- Escopo, responsável, participantes, versão e data da análise.
- Fluxo de dados, finalidades, base legal em análise e fontes consultadas.
- Riscos, critérios de classificação e evidências consideradas.
- Medidas, responsáveis, prazos, dependências e prova de implementação.
- Riscos residuais, decisão, aprovador e justificativa.
- Condições de validade e eventos que exigem atualização.
| ID | Risco | Evidência | Medida | Responsável | Prazo contextual | Risco residual | Decisão |
|---|---|---|---|---|---|---|---|
| CRM-03 | Contas com o mesmo perfil permitem consulta de clientes fora da carteira | Teste de homologação mostrou acesso integral por usuário de vendas | Criar perfis por função, restringir carteira e repetir o teste com evidência | Coordenação de TI | Antes da entrada em produção | Baixo, se o novo teste confirmar a restrição | Aprovação condicionada; sem evidência do teste, suspender o lançamento |
Erros que transformam a PIA em mera formalidade
Realizar a avaliação somente depois da assinatura do contrato reduz a capacidade de negociação. A correção é inserir a PIA nos pontos de aprovação de compras e projetos. Se o CRM já tiver sido contratado, a empresa ainda pode avaliar o tratamento, mas talvez dependa de aditivos, reconfigurações ou migração para corrigir problemas.
Olhar apenas para multas e danos empresariais apaga a perspectiva dos titulares. A descrição deve mostrar consequências como fraude, discriminação, uso inesperado, constrangimento, perda de autonomia ou dificuldade para excluir e corrigir dados. Impacto para pessoas é diferente de custo financeiro para a organização, embora ambos possam decorrer do mesmo evento.
Copiar uma finalidade genérica, como melhorar serviços, também enfraquece a análise. A finalidade deve permitir compreender o que a organização pretende fazer e por que determinados dados são necessários. Se a equipe não consegue explicar a finalidade em linguagem concreta, tampouco conseguirá avaliar compatibilidade, transparência ou base legal.
Delegar tudo a um responsável isolado produz respostas incompletas. TI conhece integrações; atendimento sabe quais informações entram nos campos; compras conhece o fornecedor; o encarregado pode orientar sobre proteção de dados; e a liderança possui autoridade para mudar o projeto. Uma reunião breve e preparada pode revelar divergências que um questionário individual não captura, mas a duração deve ser definida conforme a complexidade, sem presumir que um tempo fixo seja suficiente.
Tratar controles prometidos como se já estivessem implementados reduz artificialmente o risco. A PIA deve registrar a situação atual, a mudança planejada e a evidência necessária para encerrar a pendência. Quando uma condição é essencial, o lançamento precisa depender de sua verificação.
Aceitar risco sem justificativa, responsável ou autoridade também esvazia o processo. A correção é transformar a aceitação em decisão rastreável, com condições de acompanhamento. Se ocorrer incidente ou mudança relevante antes da revisão planejada, a PIA deve ser reaberta, e não arquivada como tarefa definitivamente concluída.
Perguntas frequentes
A Privacy Impact Assessment é obrigatória pela LGPD?
A LGPD não determina que toda iniciativa passe por uma avaliação denominada PIA. A lei define o RIPD e prevê situações em que a ANPD pode solicitá-lo. A necessidade de uma PIA interna depende do tratamento, dos riscos, da governança da organização e das obrigações jurídicas ou regulatórias aplicáveis.
PIA e Relatório de Impacto à Proteção de Dados Pessoais são a mesma coisa?
Não automaticamente. PIA é uma expressão ampla para avaliações de impacto à privacidade. O RIPD é um documento definido pela LGPD. Uma PIA pode fornecer parte ou todos os insumos necessários, mas seu conteúdo deve ser conferido à luz da lei, das orientações vigentes da ANPD e de eventual determinação aplicável.
Os artigos 5º, XVII, e 38 são suficientes para analisar juridicamente o RIPD?
Eles são referências centrais, mas não devem ser lidos de forma isolada. O artigo 10, parágrafo 3º, trata da possibilidade de solicitação de RIPD em operações baseadas no legítimo interesse. Outros dispositivos da LGPD, regulamentações, orientações e determinações da ANPD também podem ser relevantes conforme o caso.
Quem deve participar da elaboração de uma PIA em uma pequena empresa?
Devem participar pessoas que conheçam a finalidade, o fluxo, a tecnologia, o fornecedor e o contato com titulares. Isso pode incluir liderança, TI, atendimento, marketing, compras, jurídico e encarregado. A composição varia, mas a autoridade necessária para aprovar mudanças ou suspender o projeto precisa estar representada.
É necessário fazer uma PIA para cada novo fornecedor de tecnologia?
Não como regra automática. Faça uma triagem considerando quais dados o fornecedor receberá, qual será sua função, quais integrações e acessos existirão, como ocorrerão retenção e descarte e quais impactos podem atingir os titulares. Serviços sem tratamento relevante podem exigir apenas verificações proporcionais.
Quando uma PIA simplificada deve evoluir para uma DPIA ou um RIPD?
O aprofundamento é indicado quando surgem impactos potencialmente graves, tratamento complexo, públicos vulneráveis, perfilização com efeitos relevantes, monitoramento amplo, ausência de informações essenciais ou riscos residuais elevados. A necessidade de RIPD deve ser verificada segundo a LGPD, as orientações vigentes da ANPD e eventual solicitação ou determinação aplicável.
O legítimo interesse exige considerar as expectativas das pessoas?
As expectativas legítimas dos titulares são relevantes para o exame do contexto e do balanceamento, mas não constituem o único critério. A análise deve abranger finalidade legítima, necessidade, balanceamento entre interesses e direitos e adoção de salvaguardas, além de transparência e uso apenas dos dados estritamente necessários, conforme a LGPD e as orientações da ANPD.
Com que frequência uma PIA precisa ser revisada?
Não existe intervalo universal para toda PIA. A periodicidade deve refletir o risco e a velocidade de mudança do tratamento. A revisão deve ser antecipada diante de incidente, nova finalidade, novo fornecedor, nova integração, ampliação do público, mudança de base legal ou alteração relevante na retenção.
Os prazos de 10 dias úteis, 30 dias e seis meses são exigidos pela LGPD?
Não. Neste guia, 10 dias úteis para conduzir uma análise simples, 30 dias para determinada rotina de exclusão e seis meses para uma revisão programada são apenas exemplos contextuais de governança. A adequação de qualquer prazo depende da finalidade, do risco, das obrigações legais, das hipóteses de conservação e da capacidade operacional.
Conclusão
Uma PIA útil começa com uma iniciativa real e um recorte controlável. Selecione um sistema, integração ou mudança prevista, descreva o fluxo de dados e identifique como as pessoas podem ser afetadas. Em seguida, classifique os riscos com critérios observáveis e vincule cada risco concreto a evidência, medida, responsável, prazo e decisão.
No caso do CRM, esse trabalho pode alterar campos, acessos, integrações, contratos e regras de descarte antes da entrada em produção. A decisão final deve informar claramente o que foi aprovado, quais condições permanecem abertas, quem assumiu a responsabilidade e quando a análise será reaberta.
A Privacy Impact Assessment (PIA) não substitui automaticamente uma avaliação aprofundada nem o RIPD previsto na LGPD. Quando houver possível impacto grave, tratamento complexo, público vulnerável, monitoramento relevante ou risco residual elevado, a organização deve escalar o caso, ampliar as evidências e verificar as orientações vigentes da ANPD. O valor do processo está em tornar escolhas de privacidade compreensíveis, proporcionais e verificáveis, sem apresentar um diagnóstico interno como garantia de conformidade.
