Habilidade de Engenharia GDPR

Referência acionável de GDPR para engenheiros, arquitetos, DevOps e líderes técnicos. Inspirado pelas orientações para desenvolvedores da CNIL e pelos Artigos 5, 25, 32, 33, 35 do GDPR.

Regra de Ouro: Colete menos. Armazene menos. Exponha menos. Retenha menos.

Para mergulhos profundos, leia os arquivos de referência em references/:

• references/data-rights.md — endpoints de direitos do usuário, fluxo de trabalho DSR, RoPA
• references/security.md — criptografia, hashing, segredos, anonimização
• references/operations.md — nuvem, CI/CD, resposta a incidentes, padrões de arquitetura

1. Princípios Fundamentais do GDPR (Artigo 5)

2. Privacidade por Design e por Padrão

DEVE

• Adicionar CreatedAt, RetentionExpiresAt a cada tabela que contenha dados pessoais no momento da criação.
• Definir como desativada toda coleta de dados opcional por padrão. Os usuários optam por participar; eles nunca optam por sair de uma configuração ativada por padrão.
• Realizar uma DPIA antes de construir processamentos de alto risco (biometria, dados de saúde, perfilamento em larga escala, monitoramento sistemático).
• Atualizar a RoPA com cada novo recurso que introduza uma atividade de processamento.
• Assinar um DPA com cada sub-processador antes que os dados fluam para eles.

NÃO DEVE

• Lançar um novo recurso de coleta de dados sem uma base legal documentada.
• Ativar análises, rastreamento ou telemetria por padrão sem consentimento explícito.
• Armazenar dados pessoais em um sistema não listado na RoPA.

3. Minimização de Dados

DEVE

• Mapear cada campo DTO/modelo para uma necessidade de negócio concreta. Remover campos não documentados.
• Usar DTOs separados para criar, ler e atualizar — nunca reutilizar o mesmo objeto.
• Retornar apenas o que o chamador está autorizado a ver — usar projeções de resposta.
• Mascarar valores sensíveis na borda: retornar ****1234 para números de cartão, nunca o valor completo.
• Excluir campos sensíveis (data de nascimento, RG, saúde) das projeções padrão de lista/pesquisa.

NÃO DEVE

• Registrar corpos completos de requisição/resposta se eles puderem conter dados pessoais.
• Incluir dados pessoais em segmentos de caminho de URL ou parâmetros de consulta (logs de CDN, histórico do navegador).
• Coletar dateOfBirth, RG ou dados de saúde sem uma base legal explícita.

4. Limitação da Finalidade

DEVE

• Documentar a finalidade de cada atividade de processamento em comentários de código e na RoPA.
• Obter uma nova base legal ou realizar uma análise de compatibilidade antes de reutilizar dados para uma finalidade secundária.

NÃO DEVE

• Compartilhar dados pessoais coletados para entrega de serviços com redes de publicidade sem consentimento explícito.
• Usar o conteúdo de tickets de suporte para treinar modelos de ML sem uma base legal separada e aviso ao usuário.

5. Limitação e Retenção de Armazenamento

DEVE

• Cada tabela que contenha dados pessoais DEVE ter um período de retenção definido.
• Aplicar a retenção automaticamente por meio de um job agendado (Hangfire, cron) — nunca um processo manual.
• Anonimizar ou excluir dados quando a retenção expirar — nunca deixar dados expirados silenciosamente em produção.

Padrões recomendados

DEVERIA

• Adicionar coluna RetentionExpiresAt — calcular no momento da inserção.
• Usar exclusão lógica (DeletedAt) com exclusão física agendada após a janela de solicitação de apagamento (30 dias).

NÃO DEVE

• Reter dados pessoais indefinidamente "caso se tornem úteis mais tarde".

6. Regras de Design de API

DEVE

• NÃO incluir dados pessoais em caminhos de URL ou parâmetros de consulta.
  • GET /users/{userId}
• Autenticar todos os endpoints que retornam ou aceitam dados pessoais.
• Extrair a identidade do usuário atuante do JWT — nunca do corpo da requisição.

…