Resumo executivo: a LGPD não pede um relatório no fim do projeto — pede decisões de arquitetura no começo. Privacidade e segurança desde a concepção custam pouco quando entram no desenho e custam muito quando viram correção depois da entrega. Este é o roteiro prático para um ciclo de desenvolvimento que já nasce em conformidade.
O que a lei realmente exige do software
O artigo que importa para quem desenvolve. A Lei 13.709/2018 estabelece, no artigo 46, que agentes de tratamento devem adotar medidas de segurança, técnicas e administrativas aptas a proteger os dados pessoais. E no artigo 46, §2º, determina que essas medidas devem ser observadas desde a fase de concepção do produto ou serviço até a sua execução.
Tradução prática. Segurança e privacidade são requisitos funcionais do sistema, na mesma categoria de “precisa emitir nota fiscal”. Não são item de checklist de homologação.
Quem responde. A empresa que decide sobre o tratamento — a contratante — é a controladora. Quem desenvolve e opera por conta dela normalmente atua como operadora. As duas figuras têm responsabilidades, e o contrato precisa deixá-las claras.
Os sete pontos que entram no desenho
1. Mapa de dados pessoais
Antes da primeira linha de código: quais dados pessoais o sistema vai tratar, com qual finalidade, com qual base legal e por quanto tempo. Se a resposta para “por quê” for “pode ser útil depois”, o campo não deveria existir.
2. Minimização
Coletar apenas o necessário para a finalidade declarada. É o controle mais barato e mais eficaz: dado que não existe não vaza, não precisa ser protegido e não precisa ser eliminado depois.
3. Controle de acesso por perfil
Cada perfil enxerga apenas o que precisa. Sistema em que todo usuário autenticado vê tudo é a falha mais comum em software corporativo — e a mais fácil de evitar no desenho, quase impossível de corrigir depois sem retrabalho.
4. Trilha de auditoria
Quem consultou, alterou, exportou e excluiu — com data, hora e identificação. Sem isso, é impossível responder a um incidente ou a um pedido de titular. Registre também as consultas a dados sensíveis, não apenas as alterações.
5. Retenção e eliminação
Todo dado pessoal precisa de prazo. E o sistema precisa ter mecanismo para eliminar ou anonimizar quando o prazo expira ou quando o titular exerce seu direito. Implementar isso depois significa mexer em integridade referencial de um banco em produção.
6. Cifragem e proteção em trânsito e em repouso
Conexão cifrada em todos os trechos, inclusive internos. Dados sensíveis cifrados no banco. Backup cifrado — backup é a cópia mais esquecida e mais exposta.
7. Resposta a incidente
O sistema precisa produzir a informação necessária para avaliar um incidente: o que foi acessado, por quem, quando e quantos titulares foram afetados. Sem log adequado, a empresa não consegue nem dimensionar o problema.
O erro mais comum: dados reais em ambiente de teste
A prática. Copiar a base de produção para homologação ou desenvolvimento “para testar com dado de verdade”. É comum, é confortável e é um dos maiores riscos de vazamento em empresas de médio porte.
Por que é grave. Ambientes de teste costumam ter controle de acesso mais frouxo, backup menos protegido, credenciais compartilhadas e frequentemente ficam expostos na internet para facilitar o acesso da equipe.
O que fazer.
- Anonimizar ou pseudonimizar na cópia — substituir nome, CPF, e-mail e telefone por valores gerados, preservando formato e volume.
- Gerar massa de teste sintética para os cenários que não exigem dado real.
- Quando for tecnicamente inevitável usar dado real, tratar o ambiente com o mesmo rigor da produção — acesso nominal, registro e cifragem.
- Colocar isso em contrato com o fornecedor de desenvolvimento.
Segurança no ciclo de desenvolvimento
Objetivo → Ação → Resultado → Como validar
Objetivo: encontrar falha antes de ela chegar à produção.
Ação: incorporar quatro verificações ao fluxo de trabalho — revisão de código por outra pessoa, análise automática de dependências vulneráveis, verificação de segredos no repositório e teste dos controles de acesso.
Resultado esperado: nenhuma dependência com vulnerabilidade crítica conhecida em produção e nenhuma credencial versionada.
Como validar: relatório da ferramenta de análise a cada entrega, com número de vulnerabilidades por severidade e idade da mais antiga.
As falhas que mais aparecem em software corporativo
- Falha de controle de acesso. Trocar o identificador na URL e ver o registro de outro cliente. É a mais frequente e a mais barata de testar.
- Injeção de SQL. Ainda presente em sistemas que montam consulta por concatenação de texto.
- Credencial no código. Senha de banco ou chave de API versionada no repositório — especialmente grave quando o repositório é público ou compartilhado.
- Dependência desatualizada. Biblioteca com vulnerabilidade conhecida e correção disponível há meses.
- Log com dado pessoal. CPF completo gravado em arquivo de log que ninguém protege.
- Upload sem validação. Arquivo enviado pelo usuário e servido de volta sem verificação de tipo.
Referência de controle. Essas verificações conversam diretamente com o tema de segurança no desenvolvimento tratado na ISO/IEC 27001:2022 — em especial os controles relacionados a codificação segura, separação de ambientes e uso de dados de teste. Adotar a norma inteira não é pré-requisito; adotar a lógica dela, sim.
Direitos do titular: o que o sistema precisa saber fazer
| Direito | O que o sistema precisa ter |
|---|---|
| Confirmação e acesso | Consulta que localiza todos os registros de um titular, inclusive em tabelas secundárias |
| Correção | Fluxo de alteração com registro de quem alterou e quando |
| Eliminação | Rotina que remove ou anonimiza sem quebrar integridade — e que respeita obrigações legais de guarda |
| Portabilidade | Exportação em formato estruturado e legível por máquina |
| Informação sobre compartilhamento | Registro de quais integrações enviaram dados daquele titular a terceiros |
O ponto crítico. Nenhum desses itens é difícil quando previsto no modelo de dados. Todos são caros quando descobertos depois, com o sistema em produção e o prazo legal correndo.
Como a Brazuca Informática trata isso
Requisitos de privacidade na descoberta. O mapa de dados pessoais é produzido junto com o mapa de processo, antes da estimativa. Ele muda escopo e, portanto, muda preço — melhor descobrir antes.
Ambientes separados e massa anonimizada. Desenvolvimento e homologação não recebem cópia de produção sem anonimização. É cláusula, não recomendação.
Log e auditoria como parte da entrega. Trilha de acesso, log estruturado e retenção configurável entram na primeira versão, não em uma fase futura.
Operação com visibilidade. Tentativas de autenticação malsucedidas, acessos administrativos e falhas de integração são monitorados no Zabbix, e o que exige tratamento vira chamado com prazo no GLPI.
Checklist antes de colocar em produção
Doze verificações que cabem em uma tarde e evitam a maior parte dos incidentes evitáveis.
- Todos os acessos são nominais, sem usuário compartilhado.
- Perfis testados: um usuário restrito não alcança dado de outro perfil trocando o identificador na URL.
- Senhas e chaves fora do código, em cofre ou variável de ambiente.
- Conexão cifrada em todos os trechos, inclusive internos.
- Backup configurado e restauração testada ao menos uma vez.
- Log sem CPF, cartão ou dado de saúde em texto claro.
- Dependências sem vulnerabilidade crítica conhecida.
- Ambiente de homologação sem cópia de produção não anonimizada.
- Trilha de auditoria gravando consulta, alteração, exportação e exclusão.
- Prazo de retenção definido para cada base com dado pessoal.
- Rotina de eliminação ou anonimização implementada e testada.
- Plano de resposta a incidente escrito, com responsável nomeado.
Como usar. Transforme em critério de aceite do contrato. O que não está no aceite não é cobrado — e o que não é cobrado costuma não ser feito.
Perguntas frequentes
Preciso de um DPO para desenvolver um sistema? A lei exige que o controlador indique um encarregado. Não é o desenvolvedor — mas o desenvolvedor precisa saber quem é, porque decisões de tratamento passam por ele.
Anonimizar é o mesmo que apagar? Não. Dado anonimizado, de forma irreversível, deixa de ser dado pessoal para efeito da lei. Pseudonimizado ainda é dado pessoal, porque pode ser reidentificado. A diferença muda as obrigações.
Quanto isso encarece o projeto? Quando entra no desenho, o custo é pequeno — é decisão de modelagem e alguns dias de implementação. Quando entra depois, envolve migração de dados, retrabalho de telas e reescrita de consultas.
Sistema interno também precisa? Precisa. Dados de colaboradores são dados pessoais, e ponto de atenção adicional: sistemas internos costumam ter controle de acesso mais frouxo justamente por serem “só internos”.
Riscos e pontos de atenção
- Tratar LGPD como documento. Política de privacidade no site não protege banco de dados.
- Deixar retenção para depois. É o item que mais dá trabalho para incluir em sistema já populado.
- Credencial compartilhada. Acesso nominal é pré-requisito para qualquer trilha de auditoria fazer sentido.
- Backup esquecido. Cifre e controle o acesso ao backup com o mesmo rigor da base principal.
- Integração enviando demais. Cada campo desnecessário trafegado é superfície de risco a mais, sem contrapartida.
- Ausência de plano de incidente. A obrigação de comunicar existe; o prazo corre a partir do conhecimento do fato. Descobrir isso durante o incidente é tarde.
Próximos passos práticos
- Liste os sistemas da empresa que tratam dados pessoais e marque quais têm trilha de auditoria funcionando.
- Verifique se algum ambiente de teste está com cópia de produção sem anonimização. Se estiver, resolva esta semana.
- Para o sistema mais crítico, teste manualmente: um usuário de perfil restrito consegue acessar dado que não deveria trocando o identificador na URL?
- Defina prazo de retenção para as principais bases e verifique se existe rotina que o aplique.
Quer um sistema que já nasce em conformidade? A Brazuca Informática faz desenvolvimento de sistemas corporativos com requisitos de segurança e privacidade desde o desenho, em MT, GO e em todo o Brasil. Fale com nosso time.
Premissas assumidas: as referências à Lei 13.709/2018 são gerais e não substituem orientação jurídica sobre o caso concreto — a definição de bases legais, prazos de retenção e papéis de controlador e operador depende de análise específica; as práticas de segurança citadas seguem padrões consolidados de engenharia e a lógica de controles da ISO/IEC 27001:2022.
Continue na série
- Sustentação de software: o contrato que ninguém quer e todo mundo precisa
- Software sob medida ou de prateleira: como decidir sem se arrepender
- Quanto custa desenvolver um software sob medida (e o que forma o preço)
- Desenvolvimento de sistemas corporativos — Brazuca Informática
Deixe um comentário