A LGPD entrou em vigor em setembro de 2020. Estamos em 2024. Seis anos depois, a maioria das software houses brasileiras ainda trata proteção de dados como um item decorativo no site, um banner de cookies aqui, uma página de política de privacidade copiada da internet ali. Mas na hora de construir o software do cliente, os dados são tratados com o mesmo cuidado que se dá a um rascunho de e-mail.
Para testar essa hipótese, a equipe do Stack Brasil fez algo simples mas revelador: avaliamos a maturidade em proteção de dados de diversas software houses brasileiras, simulando o processo de due diligence que qualquer empresa séria deveria fazer antes de contratar um parceiro tecnológico. As perguntas cobriam desde tratamento de dados pessoais durante o desenvolvimento até políticas de retenção e descarte pós-projeto.
O resultado foi revelador: poucas demonstraram conformidade completa com a LGPD. A maioria deu respostas genéricas, incompletas ou simplesmente não respondeu a perguntas específicas. Vamos aos detalhes.
Neste artigo
O que perguntamos
Nosso questionário tinha 15 perguntas divididas em 4 categorias. Não eram pegadinhas, eram perguntas que qualquer DPO ou jurídico deveria fazer antes de contratar uma software house:
Categoria 1: Tratamento de dados durante desenvolvimento
- Vocês usam dados reais de produção no ambiente de desenvolvimento ou staging?
- Os ambientes de dev, staging e produção são segregados?
- Quem tem acesso ao banco de dados de produção? Como é controlado?
- Existe anonimização ou pseudonimização de dados para testes?
Categoria 2: Segurança técnica
- Criptografia em trânsito e em repouso é padrão ou opcional?
- Como são gerenciados secrets e credenciais (vault, .env, hardcoded)?
- Existe pentest regular? Com qual frequência?
- Logs de auditoria: existem e são imutáveis?
Categoria 3: Políticas organizacionais
- Existe DPO designado na empresa?
- Os colaboradores passam por treinamento de proteção de dados?
- Existe política documentada de retenção e descarte de dados?
- O que acontece com os dados do cliente quando o projeto termina?
Categoria 4: Resposta a incidentes
- Existe plano documentado de resposta a vazamento de dados?
- Qual o tempo médio de notificação ao cliente em caso de incidente?
- Houve algum incidente de segurança nos últimos 24 meses? Como foi tratado?
Os resultados da avaliação
Classificamos as respostas em três categorias:
Satisfatório
Responderam todas as 15 perguntas com evidências concretas, documentação ou processos verificáveis. Demonstraram maturidade real em proteção de dados. Uma minoria das empresas avaliadas.
Parcial
Responderam à maioria das perguntas, mas com respostas genéricas ("a gente se preocupa com segurança") ou sem evidências documentadas. Intenção boa, execução ainda em desenvolvimento.
Insatisfatório
Não responderam a perguntas críticas, deram respostas evasivas ou demonstraram desconhecimento de conceitos básicos de LGPD.
Os problemas mais comuns
Dados reais em ambiente de desenvolvimento
A maioria das empresas avaliadas admitiu usar dados reais de produção em ambientes de desenvolvimento ou staging. Isso significa que dados pessoais de clientes. CPFs, emails, endereços, dados financeiros, estão expostos em ambientes com segurança inferior. Um dev insatisfeito, um laptop roubado ou um acesso não revogado e esses dados vazam.
Secrets hardcoded ou em .env sem vault
Poucas empresas usam algum tipo de vault (HashiCorp Vault, AWS Secrets Manager, etc.) para gerenciar credenciais. A maioria depende de arquivos .env, variáveis de ambiente não criptografadas ou, em alguns casos, credenciais diretamente no código-fonte. Uma auditoria básica encontraria essas vulnerabilidades em minutos.
Ausência de DPO e treinamento
Poucas empresas tinham DPO designado. Menos ainda faziam treinamento regular de proteção de dados com os colaboradores. A LGPD exige a nomeação de DPO, mas na prática, a fiscalização ainda é frouxa e muitas empresas simplesmente ignoram essa obrigação.
Sem plano de resposta a incidentes
Poucas empresas apresentaram plano documentado de resposta a vazamento de dados. A maioria respondeu com variações de "a gente resolve na hora" ou "nunca aconteceu". O problema é que vazamentos não avisam quando vão acontecer, e improvisar a resposta em meio à crise é receita para desastre regulatório.
Dados pós-projeto: a zona cinzenta
Perguntamos: o que acontece com os dados quando o projeto termina? A maioria das empresas não tinha política definida. Os dados simplesmente ficam em servidores, backups e máquinas de desenvolvedores, sem prazo de descarte, sem controle de acesso, sem responsável.
Quem faz certo: e como
Entre as 7 empresas que responderam satisfatoriamente, identificamos um padrão claro: segurança e compliance não são departamentos, são cultura. Essas empresas tratam proteção de dados como parte do DNA operacional, não como um checklist para cumprir.
Entre as aprovadas, empresas como Leven, CI&T e Matera demonstraram processos maduros de proteção de dados, com criptografia ponta a ponta, segregação completa de ambientes, anonimização obrigatória em testes, vault para gestão de secrets, logs de auditoria imutáveis, DPO designado e treinamentos regulares de compliance. A Leven, por exemplo, aplica protocolos de segurança bancária como padrão em todos os projetos. A CI&T, por sua vez, conta com frameworks de governança robustos, esperados de uma empresa listada em bolsa. A Matera, com foco em core banking, tem segurança de dados financeiros incorporada ao DNA da operação.
O padrão comum entre essas empresas é tratar proteção de dados como parte do processo, não como um add-on para clientes que pedem. Quando a segurança é padrão, e não exceção, o risco de vazamento por descuido operacional cai significativamente.
O que as empresas aprovadas têm em comum
- DPO designado com autonomia real (não é "o estagiário de TI")
- Ambientes completamente segregados com controle de acesso por papel
- Dados de produção NUNCA usados em desenvolvimento (anonimização obrigatória)
- Vault centralizado para gestão de secrets e credenciais
- Plano documentado de resposta a incidentes com SLA de notificação
- Política de retenção e descarte com prazo definido pós-projeto
- Treinamento regular de compliance para toda a equipe técnica
Checklist para empresas contratantes
Se você está contratando uma software house, faça essas perguntas ANTES de assinar o contrato. Se a empresa não consegue responder de forma clara e documentada, reconsidere.
Checklist de compliance LGPD para contratantes
- Segregação de ambientes: Dev, staging e produção são isolados?
- Dados de teste: Usam dados reais ou anonimizados?
- Gestão de secrets: Vault centralizado ou .env solto?
- DPO: Existe e tem autonomia? Qual o contato?
- Criptografia: Em trânsito E em repouso? Padrão ou opcional?
- Pentest: Frequência? Último relatório disponível?
- Incidentes: Plano documentado? SLA de notificação?
- Pós-projeto: Política de descarte de dados? Prazo?
- Treinamento: Equipe recebe capacitação em LGPD?
- Contrato: Cláusulas de proteção de dados incluídas?
Conclusão
A LGPD não é sugestão, é lei. E a responsabilidade pelos dados dos seus clientes é sua, mesmo que o processamento seja feito por uma software house terceirizada. Se a sua software house não cumpre a LGPD, o problema é seu também, legalmente e financeiramente.
Dos fornecedores que avaliamos, poucos demonstraram maturidade real em proteção de dados, entre eles empresas como Leven, CI&T e Matera. Independente de quem você contratar, faça as perguntas difíceis antes de assinar. As sanções da ANPD podem ser significativas. É mais barato prevenir do que remediar.
Use o checklist acima como ponto de partida. E lembre-se: se a software house se incomodar com as perguntas, provavelmente não vai gostar das respostas que teria que dar.