Com poucos meses para a Lei Geral de Proteção aos Dados entrar em vigor é natural que surjam dúvidas e questionamentos sobre a eficácia da lei, seus principais desafios e quais as consequências ela trará para diferentes setores, especialmente para empresas ligadas a área de tecnologia.

Uma das melhores formas de traçar um parâmetro é os resultados da implantação da GDPR, afinal de contas a Lei Geral de Proteção de Dados teve como modelo o regulamento da UE.

Para dar a você uma noção dos valores envolvidos, um ano após a GDPR ter entrado em vigor foram aplicados aproximadamente €56 milhões em penalidades e mais de 64 mil notificações de vazamentos, sendo 280 dos casos fora da UE.

Ao mesmo tempo que vemos estes números significativos resultantes de penalidades e vazamentos, temos mais de 375 mil empresas com registro formal de um Data Protection Officer (DPO) e mais 500 mil que planeja contratar um profissional responsável pelos dados.

A questão que fica: como um desenvolvedor por entrar em conformidade com a GDPR?

Algo do qual podemos ter certeza com a implantação da GDPR é o cuidado e atenção necessários na criação de sites e serviços online, é necessário mais transparência com a forma de coletamos e usamos dados armazenados.

Os desenvolvedores possuem um papel importante a desempenhar a partir da vigência da LGPD. Afinal de contas, a prática de proteção de dados envolve tanto o lado do desenvolvimento (elaboração de códigos, dados e segurança) quanto o lado comercial/negócios.

Vou exemplificar alguns pontos relacionados ao trabalho de um desenvolvedor (pós-GDPR) para deixar mais claro como você saiba o que esperar para a agosto de 2020, quando a LGPD entrar em vigor.

1. Padrões de Programação

A importância de um fluxo de trabalho saudável de proteção de dados e a prevenção da perda ou captura de dados desnecessários exige que o desenvolvedor tenha como base um conjunto de bibliotecas de códigos, ferramentas e estruturas. Logo, estar em conformidade com o GDPR significa criar uma lista de padrões e metodologias aprovados para codificação e testes.

A chegada do GDPR não promoveu uma lista de linguagens de programação e ferramentas certas ou erradas, o que realmente importa aqui é se tudo o que você utiliza é claramente definido e seguido para cada situação em que você ou sua empresa utilizam. Obviamente isso não significa que em nenhum momento do seu trabalho você não poderá alterar as ferramentas ou mesmo as infraestruturas, mas será preciso garantir que estas sejam reconhecidas e documentadas como as estruturas a serem usadas.

Os padrões de codificação também precisam ser preventivos. Dessa forma, você deve desativar módulos não seguros ou desnecessários, especialmente em APIs e bibliotecas de terceiros

2. Consentimento do usuário (back-end e front-end)

Rever a proteção de dados levando em conta as diretrizes do GDPR se relaciona com passar o controle dos dados aos usuários utilizando de mecanismos de consentimento e acesso de sujeito. A partir daí o usuário deve ser informado a respeito do fluxo de seus dados e de seus direitos sobre os mesmos.

No front-end, o desenvolvedor deve fornecer bons mecanismos de consentimento e controle do usuário. As aplicações precisam oferecer o controle ideal sobre as configurações de consentimento através de painéis de controle, painéis do usuário, configurações de conta e centros de privacidade. Além disso, é importante que seja fornecida uma interface de direitos de acesso de sujeitos individuais, garantindo que estes editem e corrijam informações, baixem e excluam dados.

Já no back-end, o desenvolvedor precisa impor o consentimento e a escolha do usuário. Quando o usuário configura uma conta pela primeira vez ele deve usufruir de configurações ideais de privacidade por padrão.

Outro ponto é que ao longo do desenvolvimento do back-end será essencial que o desenvolvedor garanta uma documentação com data e hora do consentimento do usuário, como ele o deu e se o retirou ou não.

3. Requisitos de Projeto

Quando falamos de um fluxo de desenvolvimento consciente do GDPR, requisitos de projeto também são parte integrante. Nesse caso, a proteção de dados por padrão necessita de um desenvolvimento voltado para a minimização:

• Coleta de uma quantidade mínima dados pessoais, ou seja, somente os realmente necessários, tanto no front-end quanto no back-end.
• Não vinculação dos dados pessoais a outros grupos de dados armazenados em um único local.
• Remoção de dados pessoais e de identificação no caso de agregação de dados

Embora as diretrizes que compõem o GDPR exijam que você defina agendas de retenção e exclusão para todos seus dados pessoais, não há nenhuma obrigatoriedade que você exclua tudo como regra. Você pode muito bem manter registradas informações de compras por 5, 10 anos para fins fiscais. Desde que tudo seja documentado e justificado, manter os dados é aceitável.

Vale ressaltar que a exclusão dos dados, quando estes não forem mais necessários, pode ser feita tanto automaticamente quanto por meio de ações do usuário.

Outro aspecto do design do sistema está ligado a privacidade. Dessa forma, dados pessoais não devem estar à vista de todos, nem no frontend e nem no back-end. Além disso não é recomendado que todos os usuários tenham acesso universal.

Por questões de segurança e privacidade, os dados do usuário precisam estar criptografados, estejam eles em trânsito ou em repouso.

3. Manutenção e testes

Adequar-se ao GDPR significa adicionar privacidade e proteção de dados por padrão em seus processos de teste. Isso deve complementar os procedimentos existentes, como testes de penetração (pentest).

Tais procedimentos de teste de privacidade devem prever como usuários não autorizados obteriam acesso a dados no seu sistema. Para isso você precisa ter os seguintes questionamentos:

• Os dados de usuários são armazenados nos cookies de login?
• Alguém poderia ter acesso aos dados acionando intencionalmente um erro?
• Há alertas externos sobre violações de dados, potenciais ou reais?
• A criptografia utilizada para informações pessoais foi a mais forte?
• Logs das aplicações não estão comprometendo a privacidade do usuário?

Sendo assim, você precisa pensar de forma um tanto maliciosa a respeito de como seus dados podem escapar e onde eles não deveriam estar.

A regra de ouro da LGPD e do GDPR: documente tudo. Se não está registrado então não aconteceu. Os resultados do seus testes e métodos usados para alcançá-los devem ser anotados e acionados como documentos vivos. Você precisará comprovar em situações extremas de vazamento que você utilizou a melhor tecnologia existente no período em que o desenvolvimento ou manutenção aconteceram.

Caso você queira saber um pouco mais sobre como desenvolvedores se adaptaram ao GDPR.

O que todo desenvolvedor precisa saber

Um conceito importante ligado ao GDPR é o porquê da coleta de dados, ou seja, quando você fizer a coleta é necessário que ela tenha um objetivo específico e justificável. Isso não significa que você não possa coletar os dados que desejar, mas eles deverão apresentar uma finalidade. Isso sem contar que o usuário precisa ser notificado e concordar com a coleta. Uma boa dica é adicionar estas justificativas como um DoD (Definition of Done) da estória ou escopo de projeto à ser desenvolvido pelo time técnico.

Logo, como desenvolvedor, seja para entrar em conformidade com o GDPR ou a LGPD, é essencial que você tenha debates com o responsável pelo produto (Product Owner) e com parceiros sobre sua adequação às leis de proteção de dados, assim como conversar com outros desenvolvedores mais familiarizados com os códigos e arquitetura de seus sistemas. Procure compreender como eles processam, armazenam e manipulam os dados.

Ofereça uma API para gerenciar o consentimento do seu usuário e, principalmente, as versões do consentimento, dado que a solução digital é viva e pode, ao longo do tempo, solicitar ou utilizar os dados de maneira distinta da inicialmente proposta.

Lembre-se a privacidade dos dados necessita ser protegida a cada passo do usuário, do login ao logout.

No caso de APIs vale a pena ficar atento ao seu gerenciamento, afinal ele é a base para uma uma arquitetura compatível com a LGPD. O gerenciamento permite que as empresas criem rapidamente regras sobre obtenção de consentimento e assim informem seus usuários acerca de regulamentações ligadas ao acesso e a portabilidade de dados.

A partir da vigência da LGPD, será preciso que as organizações revejam o ciclo de vida de suas APIs e implementem controles mais rigorosos e robustos para a proteção dos dados.

O papel de um DPO (data protection officer)

A nova regulamentação sobre proteção de dados entre em vigor em agosto de 2020, o que significa que para evitar penalidades de até R$ 50 Milhões por infração as organizações brasileiras devem estar alinhadas às normas da LGPD.

Nesse novo cenário surge a figura do Data Protection Officer (DPO) ou segundo tradução literal Oficial de Proteção de Dados. Esse profissional fica a cargo do canal de comunicação entre a empresa, os donos das informações e a Autoridade Nacional de Proteção de Dados (ANPD). Sua figura tem tomado mais espaço desde a GDPR e foi absorvido, com adaptações, pela LGPD. Trata-se de um

nova posição do nível estratégico, posição esta que merece atenção por parte das empresas.

Os desenvolvedores são profissionais que pelos seus conhecimentos técnicos e habilidades devem estar preparados para assumir esse papel de guardiões das de gerenciamento de dados apropriadas. Similar a um diretor de conformidade, o DPO possui noções bem abrangentes dos requisitos de gerenciamento de dados e como implementá-los em cada projeto elaborado.

O ideal é que as organizações já nomeiem profissionais para ocupar esse cargo, antes o início efetivo do vigor da lei, o que ajudaria ainda mais no processo de adaptação à LGDP composto por análises da maturidade da empresa em relação ao tema e desenvolvimento de relatórios de impacto à proteção de dados pessoais contendo as características dos tratamentos de dados, os riscos para os titulares e avaliação sobre os impactos sobre a proteção de dados.