Com a sanção da LGPD, estabeleceu-se um marco regulatório legal para abrigar toda uma gama de direitos e obrigações relativas à proteção dos dados pessoais dos indivíduos. Dentre os princípios preconizados pela lei, atentamos para a responsabilidade e prestação de contas por parte dos agentes de processamento de dados (controladores e operadores). Uma das principais ferramentas para evidenciar tanto para os cidadãos quanto ao poder público a aderência à lei consiste no Relatório de Impacto à Proteção de Dados Pessoais (doravante RIPD).

A definição do mesmo encontra-se no artigo 5º, XVII da lei:

Art. 5º Para os fins desta Lei, considera-se:

XVII - relatório de impacto à proteção de dados pessoais: documentação do controlador que contém a descrição dos processos de tratamento de dados pessoais que podem gerar riscos às liberdades civis e aos direitos fundamentais, bem como medidas, salvaguardas e mecanismos de mitigação de risco.

Por sua vez, o artigo 38 esclarece o âmbito de aplicação do relatório, bem como, de modo extremamente sucinto, os elementos básicos que devem compô-lo:

Art. 38. A autoridade nacional poderá determinar ao controlador que elabore relatório de impacto à proteção de dados pessoais, inclusive de dados sensíveis, referente a suas operações de tratamento de dados, nos termos de regulamento, observados os segredos comercial e industrial.

Parágrafo único. Observado o disposto no caput deste artigo, o relatório deverá conter, no mínimo, a descrição dos tipos de dados coletados, a metodologia utilizada para a coleta e para a garantia da segurança das informações e a análise do controlador com relação a medidas, salvaguardas e mecanismos de mitigação de risco adotados.

+JOTA: Assine o JOTA e não deixe de ler nenhum destaque!

Considerando que o mens legis no tocante a necessidade, abrangência (parcialmente) e elementos constitutivos deste relatório inspira-se no GDPR (General Data Protection Regulation) da União Europeia, em nossa opinião o diploma legal pátrio findou por carecer de maiores esclarecimentos e definições quanto a ao escopo e formatação do referido relatório, em contraposição ao diploma legal europeu.

Resulta do art. 38 da LGPD que a autoridade nacional terá poderes para impor um DPIA a um controlador, caso este não o tenha realizado. Ter-se-á que analisar se essa falta de DPIA que a autoridade nacional considera essencial para o processamento de dados poderá levar a consequências por não cumprimento, por parte do controlador, desse mesmo DPIA, quer da parte da autoridade nacional quer da parte dos titulares de dados envolvidos nesse processamento de dados.

Tendo em conta a obrigatoriedade do DPIA para operações de tratamento, é nossa opinião que a falta de um DPIA essencial é razão suficiente para a aplicação de uma multa administrativa ou de processo ou processos judiciais contra o controlador, por não fundamnetar o processamento de dados devidamente, conforme requer a LGPD. No entanto, exige-se da autoridade nacional uma ponderação relativamente ao DPIA, analisando, nomeadamente, o grau de risco para o titular de dados que a falta do relatório de impacto implicou. Para além disso, mesmo sem a formalização de um, poderá o controlador ter implementado medidas técnicas e organizacionais suficientes para mitigar o risco. Parece-nos que ambos os fatores referidos, entre outros (e.g. a falta de DPIAs ser caso único ou um entre vários, a fundamentação do controlador para não realizar o mesmo, etc.) terão de ser tidos em consideração, não sendo a multa administrativa automática pelo simples fato de o relatório de impacto não ter sido feito.

Outro ponto que nos parece importante referir é quanto a amplitude do DPIA da LGPD, quando comparado com o do GDPR. No LGPD, de forma diferente do GDPR, o risco não é tido em consideração para a realização do DPIA. Parece-nos, no entanto, inadequada a interpretação literal do artigo, que faria com que todas as atividades de tratamento tivessem de ter um DPIA associado.Ainda relativamente a este assunto, levanta-nos questões relativamente à salvaguarda do LGPD relativamente a “segredos comercial e industrial” na realização de DPIAs.

O in fine do art. 38 nos permite interpretar como um requisito relativamente aos DPIAs solicitados pela autoridade nacional. Tal interpretação levaria à conclusão de que o DPIA solicitado pela autoridade nacional teria de ser comunicado a essa autoridade. Porque, de outro modo, sendo documentos essencialmente internos, e disponibilizados à autoridade nacional apenas em caso de uma investigação, não se alcança o objetivo da especificação relativamente à propriedade intelectual da empresa.

Ainda, tal menção parece-nos fazer entender que a mesma implica que um DPIA solicitado pela autoridade de controle terá de ser aprovado ou rejeitado por esta. Só assim se vislumbra a necessidade de respeito pelas regras da propriedade intelectual da empresa. Mas, com os responsáveis da autoridade de controle obrigados ao sigilo profissional, como se espera, não nos parece que o in fine acrescente à questão nesse caso específico, a não ser tornar difusa a questão da responsabilidade de aprovação dos DPIAs exigidos pela autoridade de controle.

Por outro lado, já tal fará sentido se o requisito for genérico. Interpretando o in fine do art. 38 como sendo um requisito geral para todos os DPIAs, tal poderá tornar estes elaborados com a defesa da propriedade intelectual da empresa, inauditáveis, com as empresas a escudarem-se na propriedade intelectual para não divulgar as medidas organizacionais e técnicas aplicadas.

Desta forma, muito embora com a edição da Medida Provisória nº 869 em dezembro de 2018 que criou a Autoridade Nacional de Proteção de Dados, vetada quando da sanção da Lei nº 13.709 (LGPD), espere-se uma melhor definição, dentre outras questões, às relativas a um detalhamento e orientações mais claras quanto à metodologia a ser utilizada quando da confecção do relatório bem como sugestões de frameworks para o documento, na ausência destas, lançamos mão das existentes para elaboração de um DPIA (Data Protection Impact Assessment), o equivalente ao nosso RIPD no âmbito do GDPR.

O propósito de um DPIA não é eliminar todos os riscos, mas sim minimizar a existência destes, bem como verificar se os riscos remanescentes são justificáveis. De acordo com as orientações existentes relativas ao DPIA, este pode ser dedicado a apenas a uma única operação de processamento, bem como a um grupo de operações, desde que similares. Igualmente, também é possível que um grupo de controladores formulem conjuntamente um DPIA.

Para além de uma demanda legal, um DPIA gera uma série de benefícios que ao próprio negócio, uma vez que a sua metodologia pode implicar em revisões de processos, alinhando assim a organização a uma visão mais abrangente de compliance, trazendo a reboque a possibilidade de gerar ganhos financeiros e de reputação perante seus clientes. Nunca é demais lembrar que tanto a LGPD quanto o GDPR são leis voltadas para os indivíduos, não para as empresas per se. O que se observa, porém, é que o fato de ao se adequarem a elas, pela via natural, mudanças organizacionais ocorrem e com elas, uma otimização nos sistemas de controle e consequentemente toda uma melhoria nos aspectos organizacionais. Mais do que um custo, a conformidade em LGPD/GDPR, como é da natureza do compliance, é uma oportunidade de alavancar negócios. Em última análise, mais um meio de manter-se competitivo.

Antes de fazermos um resumo sobre as principais etapas que integram a elaboração de um DPIA, convém esclarecer que o mesmo, muito embora seja até mesmo por autoridades nacionais de proteção de dados europeias (como a francesa CNIL) tratado como um sinônimo de um PIA (Privacy Impact Assessment), tal fato não traduz perfeitamente a realidade, do ponto de vista técnico stricto sensu. Muito embora suas bases possam ter uma origem comum, o PIA, além de já tratar-se de um conceito bem estabelecido, em contraposição ao recém-criado DPIA através do disposto no artigo 35 do GDPR de 2016, aquele trata de uma avaliação mais abrangente com relação aos impactos em todas as dimensões da privacidade.

Por sua vez, o DPIA surge como um instrumento que tem como foco evidenciar o compliance quanto a práticas previstas numa legislação específica, no caso o GDPR. Em princípio as semelhanças podem induzir a pensar que se tratam de instrumentos iguais, por abordarem aspectos que concernem a privacidade. Porém, o PIA tem uma abrangência maior, por contemplar a análise de impacto a todas as dimensões da privacidade. Por sua vez, o DPIA concentra-se num recorte limitado a atividades de processamento específicas, a saber as que envolvam e que possam vir a comprometer a proteção dos dados pessoais e violação aos direitos do indivíduo.

Feita esta importante distinção, passemos aos aspectos metodológicos para criação de um RIPD/DPIA. Muito embora não sejam exatamente iguais um DPIA e um PIA, por sua natureza e escopo, é possível lançar mão como mera referência da ISO 29134, que estabelece uma metodologia baseada em boas práticas para realização de um Privacy Impact Assessment. Para uma abordagem mais específica, porém, torna-se fortemente recomendado a apreciação da documentação produzida tanto pelo antigo WP29 (agora EDPB – European Data Protection Board), quanto da ICO e CNIL (autoridades de proteção de dados do Reino Unido e França, respectivamente) sobre DPIAs. Para entendimento prévio sobre gestão de risco, recomenda-se complementarmente a leitura da ISO 31000, que descreve os processos envolvidos (comunicação e consulta, estabelecimento de contexto, avaliação de riscos, resposta aos riscos, monitoração e reexame).

É de suma importância, antes de conduzir a elaboração de um RIPD/DPIA, que sejam feitos os seguintes questionamentos:

Foi realizada uma consulta junto aos stakeholders internos com relação aos possíveis riscos relativos a atividade de processamento em análise, bem como os riscos de não-conformidade ante a LGPD e os instrumentos internos de controle (políticas, processos e procedimentos voltados a proteção de dados e privacidade)?
Foram de igual forma consultados os stakeholder externos? Em caso afirmativo, quem, quando e com qual propósito objetivou-se a consulta?
Adicionalmente à identificação dos riscos envolvidos, ambas consultas levaram em consideração medidas de mitigação ou minimização destes riscos?

Uma vez realizado esse levantamento prévio, dá-se início efetivo ao processo de elaboração do relatório.

Para efeitos de melhor compreensão, pode-se dividir um RIPD/DPIA em 3 etapas:

Entendimento da organização e processos envolvidos (Contexto)
Risk Assessment (Processo de avaliação de riscos)
Risk Management (Gerenciamento de riscos)

A partir dessa visão macro, podemos adotar uma estrutura subdividindo as etapas de um Relatório de Impacto em 6 fases, a saber:

Fase 1 – Detalhamento do processamento
Fase 2 - Análise do processamento tendo em conta possíveis relações com terceiros e respectivo contato para colaboração na elaboração das fases seguintes
Fase 3 – Identificação de controles
Fase 4 – Listagem e análise de eventos e ameaças para o titular de dados quanto ao processamento dos dados pessoais
Fase 5 – Produção de relatório com sumário de análise, controles existentes e mitigação de risco, bem como propostas de medidas técnicas e organizacionais apropriadas para mitigar o risco do titular de dados, caso estas não estejam em prática
Fase 6 - Envio para aprovação ou recusa ao DPO

A Fase 1 visa detalhar as atividades de processamento envolvidas e que são objeto do relatório. Essa descrição sistemática das operações deve observar em seu levantamento a natureza, o âmbito, o contexto e as finalidades do tratamento. Os dados pessoais atingidos, os destinatários, as bases legais bem como o prazo de retenção devem ser igualmente detalhadas. Importante observar que essa fase implica no mapeamento/inventário de todos os dados envolvidos, bem como sua classificação e fluxos de processamento, para citar apenas alguns pontos-chave. Em condições ideais, tais processos já foram devidamente implementados.

Resta evidente, portanto, que aos considerarmos o processo de implementação de compliance em LGPD é no mínimo incorreto afirmar que o primeiro passo para dar início àquele seria a elaboração de um RIPD/DPIA. Tanto do ponto de vista metodológico quanto do ponto de vista prático, o relatório, observado no contexto de uma adequação da empresa à lei a partir do zero, apresenta-se como um output que tem por entrada diversos processos que já devem estar implementados e on-going dentro da organização. Seria como “começar pelo fim”, o que pode mostrar-se algo contraproducente e ineficaz. Numa abordagem mais otimista, prestar-se-ia como um instrumento de avaliação de maturidade organizacional/de processos tão-somente. Entretanto, existem ferramentas e metodologias específicas para este fim, tais como a realização de uma pré-auditoria ou um gap assessment. O relatório não se prestaria como o remédio mais indicado, aprioristicamente.

A Fase 2 implica uma análise às relações com terceiros, nomeadamente joint controllers ou processadores. No GDPR, a colaboração para DPIAs só tem força de Lei para os processadores, pelo que se sugere que num contrato junto a joint controllers se inclua uma cláusula para permitir essa colaboração.

A Fase 3 concentra-se em identificar os controles que já existem. Estes controles são tanto de ordem legal como de tratamento de riscos. Entram nessa categoria, portanto, todas as medidas legais, técnicas, físicas e organizacionais, que consideradas a partir do ponto de vista de assegurar ao indivíduo seus direitos previstos, já existem e como elas se relacionam ao processamento objeto do relatório.

A necessidade e a proporcionalidade do processamento são verificadas, através da avaliação de medidas existentes para este fim, bem como as outras relativas à preservação dos demais direitos alcançados pela lei. Novamente aqui faz-se necessário de que existam tais medidas para que, se necessário, sejam estas adequadas ao processamento analisado, bem como modificações a estas medidas sejam feitas, caso trate-se de uma forma nova de processamento anteriormente não prevista. Tal observação reforça a tese de que o RIPD não se presta a rigor como ferramenta de conformidade sem que sejam atendidas premissas básicas.

A Fase 4 consiste em realizar o processo de avaliação de riscos (risk assessment) a partir do ponto de vista do titular dos direitos. Identificar, analisar e avaliar riscos. Uma metodologia sugerida para garantir a sistematização do modelo de gestão de risco é a ISO 31000, trazendo uma standardização que confere certeza e, ao mesmo tempo, transmite, em caso de investigação, uma forma de demonstração de compreensão e responsabilização da empresa em relação à proteção dos dados baseada numa norma adotada largamente no mercado.

O objetivo da identificação é relacionar as fontes de risco, áreas/direitos impactados, eventos e suas causas, bem como potenciais consequências. Todos os eventos e ameaças relacionadas ao processamento em análise devem ser levantados e documentados. Estes eventos podem ter origem interna ou externa, causa humana ou tecnológica, etc. Assim, a origem, natureza, particularidade, gravidade dos riscos são elencados.

Seguindo o modelo proposto, os próximos passos consistem em analisar e avaliar os riscos identificados. Ao tomar em conta os riscos aos direitos identificados no processamento, faz-se necessário, considerando os potenciais impactos nos direitos e liberdades dos titulares e ameaças aos mesmos, estimar a probabilidade e gravidade de cada um dos riscos.

A Fase 5 tem por objetivo documentar as medidas adotadas para que os riscos identificados, analisados e avaliados sejam devidamente tratados. Este tratamento pode acarretar em evitar, remover, alterar, compartilhar ou reter os riscos levantados.

Nesta fase é gerado o relatório final que resume toda a análise realizada, os controles existentes, os riscos e ameaças aos titulares, endereçando as ações a serem tomadas pela organização para cada risco, ameaça e falha identificada. Durante todo o processo a figura do Encarregado, como 2ª linha de defesa, deve ser consultado para dirimir dúvidas e receber dele eventuais sugestões/críticas/orientações. Uma vez documentado adequadamente, o relatório deverá ser submetido aos principais gerentes das áreas afetadas da organização, para que os mesmos tomem as ações necessárias e validem o documento.

Apesar da LGPD, ao contrário do GDPR, não especificar as situações onde se faz mandatório RIPD, o legislador previu que para os casos onde a base legal para o tratamento for o interesse legítimo, observe-se o seguinte:

Art. 10. Para os fins desta Lei, considera-se: O legítimo interesse do controlador somente poderá fundamentar tratamento de dados pessoais para finalidades legítimas, consideradas a partir de situações concretas, que incluem, mas não se limitam a:

I - apoio e promoção de atividades do controlador; e

II - proteção, em relação ao titular, do exercício regular de seus direitos ou prestação de serviços que o beneficiem, respeitadas as legítimas expectativas dele e os direitos e liberdades fundamentais, nos termos desta Lei.

§ 1º Quando o tratamento for baseado no legítimo interesse do controlador, somente os dados pessoais estritamente necessários para a finalidade pretendida poderão ser tratados.

§ 2º O controlador deverá adotar medidas para garantir a transparência do tratamento de dados baseado em seu legítimo interesse.

§ 3º A autoridade nacional poderá solicitar ao controlador relatório de impacto à proteção de dados pessoais, quando o tratamento tiver como fundamento seu interesse legítimo, observados os segredos comercial e industrial. (grifo nosso)

A Fase 6 consiste no envio do relatório ao DPO, para sua análise. O DPO fará uma análise ao DPIA e concluirá se está de acordo com o que é exigido ou se, por outro lado, há riscos que não foram corretamente mitigados ou riscos que não constam do relatório. Não havendo nada legalmente que obrigue o DPO a fundamentar a sua decisão, é boa prática que a recusa do DPO tem de ser fundamentada.

A questão mais pertinente, nestes casos, é quando o DPO rejeita o DPIA. Hipoteticamente, podemos olhar para uma empresa cujo DPO rejeitou um DPIA. A rejeição do DPO de um DPIA não é vinculativa mas deve ser tida em alta consideração, dada a especificidade do cargo. A direção da empresa, após analisar o DPIA, a opinião do DPO e os fundamentos da recusa, pode decidir avançar com o processamento de dados, mesmo com a rejeição do DPIA pelo DPO. No entanto, terá de fundamentar a sua decisão, visto que, em caso de investigação, ter-se-á de analisar se o risco corrido pela empresa era razoável ou negligente, colocando propositadamente em causa os direitos dos titulares de dados em seu benefício.

Outra questão coloca-se no caso do DPO aprovar o DPIA com reservas. Por exemplo, considera que o risco está convenientemente mitigado mas que a empresa pode mitigar esse risco consideravelmente com diversas e determinadas medidas técnicas e/ou organizacionais. Não sendo a forma mais comum de responder a um DPIA, não se vislumbra qualquer razão legal para que um DPO cumpra a sua função de monitorização de forma preemptiva, assinalando soluções que o DPIA não toma em consideração.

A propósito da menção feita anteriormente ao artigo 10, § 3º, a mesma é específica a um relatório idêntico ao ser gerado em qualquer outra situação onde haja riscos aos direitos dos titulares. No âmbito do GDPR porém, tem sido considerado unanimenete a necessidade de uma avaliação que fundamente o interesse legítimo, o LIA (Legitimate Interests Assessment).

Apesar de tratar-se de uma base legal mais flexível, o interesse legítimo não pode ser assumido como o mais apropriado por mera conveniência. O propósito do LIA é evitar que o. controlador utilize o legítimo interesse de forma arbitrária e não fundamentada, sem ter em ponderação os interesses dos titulares de dados.

A responsabilidade adicional ao agente de tratamento decorrente da utilização dessa base legal é inerente, portanto conduzir uma avaliação como um LIA pode ajudar bastante a decidir pelo legítimo interesse. Um LIA basicamente coloca de forma estruturada e documentada o teste em três partes que se recomenda ao avaliar a adequação do interesse legítimo, a saber:

Propósito (ou Purpose Test)
Necessidade (ou Necessity Test)
Balanceamento (ou Balancing Test)

Inicialmente, considera-se o propósito do processamento, o que se espera obter através dele; quem beneficia-se do processamento e de que forma; se existem benefícios públicos advindos e de que forma eles se dariam; o quão importantes seriam esses benefícios, etc.

Superado isso, avalia-se a real necessidade do processamento baseado em interesse legítimo: esse processamento de fato auxilia no propósito almejado? Ele é indispensável? Não haveria outra base legal possível de se utilizar para alcançar o mesmo propósito? Há proporcionalidade entre o propósito e a necessidade?

Por fim, considera-se o impacto nos interesses, direitos e liberdades dos titulares da utilização desta base legal e são identificadas formas de mitigação do risco a esses direitos e liberdades. Do ponto de vista prático, quando olhamos para o GDPR, um DPIA não é substituído por um LIA, mas este auxilia bastante para checar a viabilidade de se utilizar como base legal o interesse legítimo, servindo de base ao mesmo quando estão em causa processamentos que colocam direitos dos titulares de dados em risco de forma agravada. Rejeitado um LIA, não se vislumbra como se poderá avançar com o interesse legítimo como base legal.

Por último, deve-se ter em consideração que o LIA terá de ser aprovado ou rejeitado pelo DPO, com as mesmas nuances referidas supra em relação aos DPIAs.

A propósito da diferença suscitada pelo LIA entre a lei brasileira e a europeia, observa-se que no GDPR o DPIA é mandatório quando o tratamento de dados for “suscetível de implicar um elevado risco para os direitos e liberdades das pessoas singulares” (GDPR, artigo 35.º, n.º 1).

Por outro lado, na LGPD, a abrangência não encontra premissas, ou seja, potencialmente todas as atividades de processamento, independente do grau de risco que apresentem aos direitos dos titulares, podem vir a ser demandadas pela futura autoridade de serem passíveis de RIPD por parte dos agentes de tratamento.

Ora, é fato que nossa realidade empresarial não tem ainda como foco o compliance, e dentro do universo da governança corporativa, a gestão de risco é antes uma exceção do que uma regra entre as empresas nacionais. Com o advento da LGPD e com ela a demanda legal quanto a existência deste mesmo compliance através de controles baseados em boas práticas, é seguro dizer que no futuro tenhamos uma mudança significativa na cultura organizacional pátria. Porém, talvez não tenha sido a melhor solução deixar de modo tão “aberto” a possível necessidade de termos RIPD para todas e quaisquer situações.

Isto posto, partindo do pressuposto de que “quem pode o mais, pode o menos”, segue à guisa de recomendação para a futura e tão necessária autoridade nacional que sejam adotados os mesmos critérios do GDPR quanto a necessidade de um RIPD. Além de estarmos assim mais alinhados com a legislação que tão grande inspiração deu à LGPD, estaríamos também dando uma maior possibilidade à ANPD em tratar os casos mais críticos como devem ser tratados: prioritariamente. Ademais, por tratar-se de um órgão recém criado, e como qualquer outro, com recursos limitados, e ainda por cima num país onde não temos uma cultura como a europeia (que já dispõe de regulação na área desde a década de 90, com a Diretiva que foi substituída pelo GDPR), existe uma tendência que tenhamos uma quantidade muito grande de demandas a autoridade, em especial nos momentos iniciais de vigência da lei.

Por tratar-se de uma abordagem nova no país de garantia aos direitos relativos à privacidade e proteção de dados pessoais, extremamente bem vinda, corre-se no entanto o risco de que, não atendendo a demanda supracitada, a ANPD venha a perder de alguma forma credibilidade e, dessa forma, tornar-se “mais uma agência”. E isto podendo vir a ocorrer justamente quando conquistamos a duras penas um patamar elevado de segurança jurídica com o advento da LGPD seria lamentável. Assim sendo, não podemos correr o risco de termos uma das suas principais ferramentas inovadoras, a autoridade nacional, desgastada já de saída.

Das etapas de elaboração de um DPIA

Propósito de um Data Protection Impact Assessment não é eliminar todos os riscos, mas minimizar a existência destes