LGPD Segurança Backend Compliance

LGPD e desenvolvimento de software: o que todo dev e gestor precisa saber

Como a LGPD afeta sistemas, bancos de dados e APIs. Conceitos essenciais, obrigações técnicas, Privacy by Design e checklist prático para adequação.

N
Neryx Digital Architects
11 de dezembro de 2025
9 min de leitura
150 profissionais leram
Categoria: Arquitetura Público: Times de engenharia e produto Etapa: Decisão

A Lei Geral de Proteção de Dados (Lei nº 13.709/2018) entrou em vigor em setembro de 2020, mas ainda hoje muitas empresas tratam a adequação como um problema jurídico — e ignoram o impacto direto que a lei tem sobre arquitetura de sistemas, banco de dados, APIs e processos de desenvolvimento.

Este artigo é um guia técnico e prático: o que a LGPD exige dos seus sistemas, como implementar as obrigações no código e o que pode acontecer se você não fizer nada.

O que é a LGPD, em termos técnicos

A LGPD regulamenta o tratamento de dados pessoais — qualquer informação que identifique ou possa identificar uma pessoa natural. Isso inclui nome, CPF, e-mail, telefone, endereço IP, cookies, dados de localização, histórico de compras, dados biométricos e muito mais.

A lei define alguns papéis importantes que toda empresa de tecnologia precisa entender:

  • Titular: a pessoa a quem os dados pertencem.
  • Controlador: quem decide o que fazer com os dados (geralmente a empresa que oferece o produto).
  • Operador: quem processa os dados por conta do controlador (ex: uma software house que desenvolve o sistema, um serviço de cloud, um provedor de e-mail marketing).
  • DPO (Data Protection Officer): pessoa indicada pelo controlador para ser o ponto de contato com a ANPD e os titulares.

Se você desenvolve um sistema que processa dados de clientes de terceiros, você é operador. Se você tem um produto próprio com usuários, você é controlador. Em muitos casos, você é os dois.

As bases legais para tratamento de dados

O erro mais comum é achar que "pedir consentimento" resolve tudo. A LGPD define dez bases legais para tratar dados — o consentimento é apenas uma delas. As mais relevantes para sistemas:

  • Consentimento — o titular deu permissão explícita, informada e inequívoca.
  • Execução de contrato — dados necessários para cumprir um contrato com o titular (ex: endereço para entrega).
  • Interesse legítimo — uso necessário para finalidades legítimas do controlador, desde que não prejudique o titular.
  • Obrigação legal — quando a lei exige o dado (ex: nota fiscal, obrigações fiscais).
  • Proteção ao crédito — análise de risco financeiro, com limites.

Para cada categoria de dado que seu sistema coleta, é preciso identificar qual base legal justifica esse tratamento — e isso deve estar documentado no seu mapeamento de dados (ROPA — Record of Processing Activities).

Direitos dos titulares que seu sistema precisa suportar

A LGPD garante direitos que os usuários podem exercer a qualquer momento — e seu sistema precisa ser capaz de atendê-los:

  • Acesso: o titular pode pedir todos os dados que você tem sobre ele.
  • Correção: pode pedir para corrigir dados incompletos ou incorretos.
  • Exclusão: pode pedir a eliminação dos dados (o "direito ao esquecimento").
  • Portabilidade: pode pedir os dados em formato estruturado para transferir a outro serviço.
  • Revogação de consentimento: pode retirar o consentimento dado anteriormente a qualquer momento.
  • Oposição: pode se opor ao tratamento de dados baseado em interesse legítimo.

Na prática, isso significa que seu banco de dados precisa suportar buscas por user_id em todas as tabelas que armazenam dados pessoais, e seu sistema precisa ter um fluxo de exclusão que percorra todas essas tabelas — ou anonimize os dados de forma irreversível.

Privacy by Design: construir privacidade desde o início

O princípio do Privacy by Design (artigo 46 da LGPD) exige que a proteção de dados seja considerada desde a fase de projeto do sistema, não como camada adicional depois.

Na prática, isso se traduz em algumas decisões de arquitetura:

Minimização de dados

Colete apenas o que é estritamente necessário para a finalidade declarada. Se você não precisa da data de nascimento completa, colete só o ano. Se não precisa do CPF para o cadastro básico, não peça. Dados que não existem não podem vazar.

Separação de dados por sensibilidade

-- Separe dados de identificação de dados de comportamento
CREATE TABLE users (
    id          UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    email       TEXT NOT NULL UNIQUE,
    created_at  TIMESTAMPTZ NOT NULL DEFAULT NOW()
);

— Dados sensíveis em tabela separada, com acesso restrito CREATE TABLE user_pii ( user_id UUID PRIMARY KEY REFERENCES users(id), full_name TEXT, cpf TEXT, — armazenar criptografado phone TEXT, updated_at TIMESTAMPTZ NOT NULL DEFAULT NOW() );

— Dados de comportamento sem PII direta CREATE TABLE user_events ( id BIGSERIAL PRIMARY KEY, user_id UUID NOT NULL REFERENCES users(id), event_type TEXT NOT NULL, metadata JSONB, created_at TIMESTAMPTZ NOT NULL DEFAULT NOW() );

Pseudonimização

Substitua identificadores diretos por tokens ou hashes em contextos onde o dado completo não é necessário. Logs de analytics, por exemplo, não precisam do e-mail real — um hash SHA-256 do e-mail serve para correlacionar eventos do mesmo usuário sem expor o dado original.

-- Exemplo em C#: pseudonimizar e-mail para logs de analytics
using System.Security.Cryptography;
using System.Text;

public static string PseudonymizeEmail(string email)
{
    var bytes = SHA256.HashData(Encoding.UTF8.GetBytes(email.ToLowerInvariant()));
    return Convert.ToHexString(bytes)[..16]; // 16 chars suficientes para correlação
}

Audit log para dados pessoais

Toda operação que acessa, modifica ou exclui dados pessoais deve ser registrada. Isso é necessário tanto para demonstrar conformidade com a ANPD quanto para detectar acessos indevidos.

CREATE TABLE data_access_audit (
    id           BIGSERIAL PRIMARY KEY,
    user_id      UUID,           -- titular cujo dado foi acessado
    accessed_by  UUID NOT NULL,  -- quem acessou (funcionário, sistema)
    action       TEXT NOT NULL,  -- 'read', 'update', 'delete', 'export'
    table_name   TEXT NOT NULL,
    legal_basis  TEXT NOT NULL,  -- base legal do tratamento
    ip_address   INET,
    created_at   TIMESTAMPTZ NOT NULL DEFAULT NOW()
);

Criptografia: o mínimo aceitável

A LGPD não define algoritmos específicos, mas a ANPD e as melhores práticas de mercado estabelecem:

  • Dados em trânsito: TLS 1.2 no mínimo, preferencialmente TLS 1.3. Sem HTTP para qualquer endpoint que processe dados pessoais.
  • Dados em repouso: criptografia de disco (AWS: EBS encryption, RDS encryption at rest). Para campos especialmente sensíveis (CPF, dados bancários), criptografia em nível de coluna com chaves gerenciadas separadamente do banco.
  • Senhas: bcrypt, Argon2 ou PBKDF2. Nunca MD5, SHA-1 ou SHA-256 direto para senhas.
  • Backups: criptografados com a mesma política dos dados em produção.

Gerenciamento de consentimento

Quando o consentimento for a base legal escolhida, o sistema precisa:

  • Registrar o momento exato em que o consentimento foi dado (timestamp).
  • Registrar a versão da política de privacidade que estava vigente naquele momento.
  • Oferecer mecanismo fácil de revogação — tão simples quanto o mecanismo de consentimento.
  • Processar a revogação em tempo razoável (a LGPD não define prazo exato, mas a prática de mercado é até 15 dias).
CREATE TABLE consent_records (
    id              UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    user_id         UUID NOT NULL REFERENCES users(id),
    purpose         TEXT NOT NULL,   -- 'marketing', 'analytics', 'third_party_sharing'
    granted         BOOLEAN NOT NULL,
    policy_version  TEXT NOT NULL,
    ip_address      INET,
    user_agent      TEXT,
    created_at      TIMESTAMPTZ NOT NULL DEFAULT NOW(),
    revoked_at      TIMESTAMPTZ
);

Resposta a incidentes de segurança

A LGPD exige que incidentes de segurança que possam acarretar risco ou dano aos titulares sejam comunicados à ANPD e aos titulares afetados em prazo razoável (a regulamentação da ANPD estabelece 2 dias úteis para comunicação inicial). Isso significa que você precisa:

  • Ter um plano de resposta a incidentes documentado antes de precisar dele.
  • Saber exatamente quais dados você tem, onde estão e quais titulares seriam afetados — o que exige um mapeamento de dados atualizado.
  • Ter logs suficientes para determinar o escopo do vazamento.

As multas são reais

Desde agosto de 2021, a ANPD tem competência para aplicar sanções. As penalidades incluem:

  • Advertência com prazo para adoção de medidas corretivas.
  • Multa simples de até 2% do faturamento no Brasil, limitada a R$ 50 milhões por infração.
  • Multa diária (enquanto a infração persistir).
  • Publicização da infração — dano reputacional considerável.
  • Bloqueio ou eliminação dos dados pessoais tratados em desconformidade.
  • Suspensão parcial ou total do banco de dados.

Checklist técnico de adequação

[ ] Mapeamento de dados (ROPA): todas as categorias de dados, finalidade e base legal
[ ] Política de privacidade atualizada e acessível no site
[ ] Consentimento registrado com timestamp e versão da política
[ ] Mecanismo de revogação de consentimento implementado
[ ] Fluxo de exclusão de dados (percorre todas as tabelas com PII)
[ ] Fluxo de exportação de dados (portabilidade)
[ ] Criptografia em trânsito: TLS em todos os endpoints
[ ] Criptografia em repouso: disco, banco e backups
[ ] Campos sensíveis (CPF, dados bancários) criptografados em nível de coluna
[ ] Audit log de acesso a dados pessoais
[ ] Retenção de dados: política e rotina de exclusão automática após prazo
[ ] Acesso mínimo necessário: profissionais acessam apenas dados que precisam
[ ] DPO indicado e canal de atendimento ao titular publicado
[ ] Plano de resposta a incidentes documentado
[ ] Treinamento de equipe sobre LGPD e boas práticas

Por onde começar

Se seu sistema já está em produção e você ainda não fez a adequação, o caminho mais prático é:

  1. Mapeamento: inventariar todos os dados pessoais que o sistema coleta, onde ficam armazenados e para que são usados.
  2. Priorização por risco: focar primeiro nos dados mais sensíveis (CPF, dados de saúde, dados financeiros) e nos fluxos com maior volume de titulares.
  3. Quick wins: TLS em todos os endpoints, criptografia de disco, política de senhas com bcrypt — todos implementáveis sem refatoração major.
  4. Direitos dos titulares: implementar o fluxo de exclusão e exportação é o que mais aparece em auditorias.
  5. Documentação: a ANPD pode pedir evidências de conformidade — tenha o ROPA e os registros de consentimento organizados.

Conclusão

A LGPD não é apenas um problema jurídico — ela afeta diretamente como você projeta bancos de dados, APIs e fluxos de usuário. Empresas que tratam a adequação como tarefa de arquitetura (e não como checklist de último minuto) terminam com sistemas mais seguros, menos propensos a vazamentos e mais confiáveis para os clientes.

Se você precisa avaliar a conformidade LGPD do seu sistema ou quer implementar as adequações técnicas de forma estruturada, a Neryx pode ajudar com uma revisão técnica inicial sem custo.

Quer sair do modo reativo e priorizar o que mais importa?

O diagnóstico de maturidade ajuda a transformar sintomas operacionais em um plano mais claro de evolução.

Avaliar maturidade

Newsletter

Receba artigos como este no seu e-mail

Conteúdo técnico sobre arquitetura de software, .NET, IA e gestão de produto. Sem spam.