Entenda as principais definições da LGPD: dado pessoal, sensível, titular, tratamento, controlador, operador, encarregado, anonimização e aplicação técnica.
Confira!
A Lei Geral de Proteção de Dados Pessoais (LGPD), Lei nº 13.709/2018, estabelece regras para o tratamento de dados pessoais no Brasil e define conceitos que precisam ser entendidos antes de qualquer discussão sobre adequação, segurança ou privacidade. Termos como dado pessoal, dado sensível, tratamento, titular, controlador, operador, encarregado e anonimização têm significado jurídico próprio e não devem ser usados como sinônimos.
Para sistemas de engenharia, essas definições aparecem em situações como videomonitoramento, controle de acesso, biometria, gestão de visitantes, redes, aplicações corporativas e plataformas em nuvem. Uma câmera, um leitor biométrico ou um VMS não “cumpre a LGPD” isoladamente; o tratamento ocorre dentro de processos, finalidades, responsabilidades e controles definidos pela organização.
Este conteúdo é uma referência técnica e conceitual. Ele não substitui análise jurídica do caso concreto. O objetivo é explicar as principais definições da LGPD e mostrar como elas se conectam à arquitetura e à operação de sistemas que tratam dados pessoais.
O que é dado pessoal
A LGPD define dado pessoal como informação relacionada a pessoa natural identificada ou identificável.
Isso inclui informações que identificam diretamente alguém e também dados que, combinados com outros elementos, permitam identificar uma pessoa.
Exemplos podem incluir:
- nome;
- CPF;
- endereço;
- e-mail pessoal;
- telefone;
- matrícula associada a pessoa;
- imagem identificável;
- identificadores digitais vinculáveis a indivíduo.
O contexto importa.
Um dado aparentemente neutro pode se tornar pessoal quando associado a outros registros.
Pessoa natural
A LGPD protege dados de pessoas naturais.
Dados exclusivamente de pessoas jurídicas não são, por si só, dados pessoais.
Entretanto, registros empresariais podem conter dados de empregados, representantes, clientes e fornecedores.
Dado pessoal sensível
A LGPD cria uma categoria específica de dados pessoais sensíveis.
Ela abrange dados sobre:
- origem racial ou étnica;
- convicção religiosa;
- opinião política;
- filiação sindical;
- filiação a organização religiosa, filosófica ou política;
- saúde;
- vida sexual;
- dado genético;
- dado biométrico vinculado a pessoa natural.
Esses dados recebem tratamento jurídico diferenciado.
Biometria
Biometria merece atenção especial em sistemas de controle de acesso.
Impressão digital, face, íris, veias ou palma podem constituir dados biométricos quando vinculados a uma pessoa.
O artigo Cadastro biométrico no controle de acesso aprofunda enrollment, qualidade e segurança.
Dado anonimizado
A LGPD define dado anonimizado como dado relativo a titular que não possa ser identificado, considerando meios técnicos razoáveis e disponíveis no momento do tratamento.
Anonimização busca impedir associação direta ou indireta ao indivíduo.
Ela não deve ser confundida com simples remoção de nome.
Se outros elementos permitem reidentificação, o processo pode ser insuficiente.
Anonimização
Anonimização é o uso de meios técnicos razoáveis e disponíveis para retirar a possibilidade de associação do dado a uma pessoa.
A robustez depende de:
- contexto;
- volume de dados;
- atributos remanescentes;
- capacidade técnica disponível;
- possibilidade de cruzamento.
A avaliação precisa considerar risco de reidentificação.
Pseudonimização
Pseudonimização reduz a associação direta ao titular, substituindo identificadores por outros elementos.
Diferentemente da anonimização efetiva, pode existir informação adicional capaz de restabelecer a associação.
Assim, dados pseudonimizados continuam exigindo tratamento compatível com sua natureza.
Titular
Titular é a pessoa natural a quem os dados pessoais se referem.
Exemplos:
- colaborador;
- cliente;
- visitante;
- prestador;
- candidato;
- usuário;
- cidadão.
O titular não é necessariamente o proprietário do sistema ou do banco.
Ele é a pessoa a quem os dados dizem respeito.
Tratamento
A LGPD utiliza tratamento em sentido amplo.
Inclui operações como:
- coleta;
- produção;
- recepção;
- classificação;
- utilização;
- acesso;
- reprodução;
- transmissão;
- distribuição;
- processamento;
- arquivamento;
- armazenamento;
- eliminação;
- avaliação;
- controle;
- modificação;
- comunicação;
- transferência;
- difusão;
- extração.
Isso significa que “tratar dados” não é apenas coletar.
Armazenar, consultar, transmitir e excluir também fazem parte do ciclo.
Ciclo de vida do dado
Em sistemas técnicos, é útil enxergar tratamento como ciclo.
Exemplo em controle de acesso:
- cadastro;
- validação;
- armazenamento;
- uso para autenticação;
- geração de logs;
- consulta;
- retenção;
- exclusão.
Cada etapa pode possuir requisitos diferentes.
Controlador
O controlador é a pessoa natural ou jurídica, pública ou privada, a quem competem as decisões referentes ao tratamento de dados pessoais.
Ele define elementos como:
- finalidade;
- meios principais;
- regras;
- retenção;
- compartilhamento;
- critérios de tratamento.
Em uma organização, o controlador não deve ser confundido automaticamente com o fornecedor do software.
Operador
O operador realiza o tratamento em nome do controlador.
Ele executa operações conforme instruções e relação estabelecida.
Um fornecedor pode atuar como operador quando processa dados para o controlador.
A classificação depende da função concreta, não apenas do nome do contrato.
Agentes de tratamento
A LGPD utiliza a expressão agentes de tratamento para controlador e operador.
Esses papéis possuem responsabilidades distintas.
Em arquiteturas com múltiplos fornecedores, é importante mapear quem decide e quem executa cada tratamento.
Isso é especialmente relevante em:
- SaaS;
- cloud;
- VMS hospedado;
- controle de acesso gerenciado;
- analytics de vídeo;
- serviços de suporte.
Encarregado
O encarregado atua como canal de comunicação entre controlador, titulares e ANPD, conforme a legislação e regulamentação aplicável.
A função não deve ser confundida com administrador de sistema.
O encarregado pode interagir com áreas como:
- jurídico;
- segurança;
- TI;
- engenharia;
- compliance;
- atendimento.
A implementação técnica precisa fornecer informações e evidências para esses processos.
ANPD
A Autoridade Nacional de Proteção de Dados é o órgão responsável por zelar, implementar e fiscalizar o cumprimento da LGPD em todo o território nacional.
A ANPD também publica:
- regulamentos;
- orientações;
- guias;
- decisões;
- materiais educativos.
Para temas regulatórios, fontes oficiais da ANPD devem prevalecer sobre resumos genéricos.
Banco de dados
A LGPD define banco de dados como conjunto estruturado de dados pessoais, estabelecido em um ou mais locais, em suporte eletrônico ou físico.
Isso inclui bancos tradicionais e também estruturas organizadas que permitam localizar registros pessoais.
Exemplos:
- cadastro de visitantes;
- base de usuários;
- diretório;
- registros biométricos;
- históricos associados a pessoas.
Consentimento
Consentimento é manifestação livre, informada e inequívoca pela qual o titular concorda com tratamento de seus dados para finalidade determinada.
Consentimento é uma das bases legais previstas na LGPD.
Não é a única.
Portanto, “ter LGPD” não significa obter consentimento para tudo.
A escolha da base legal exige análise jurídica do tratamento.
Bases legais
A LGPD estabelece hipóteses que podem autorizar tratamento.
Elas variam conforme natureza do dado e contexto.
Para dados pessoais em geral, a lei prevê diferentes bases legais.
Para dados sensíveis, há regras específicas.
Sistemas de engenharia não devem “escolher” base legal por configuração técnica.
Essa decisão pertence ao processo de governança e análise jurídica da organização.
Finalidade
O princípio da finalidade exige que o tratamento ocorra para propósitos legítimos, específicos, explícitos e informados ao titular, conforme a lei.
Do ponto de vista técnico, isso influencia quais dados realmente precisam ser coletados.
Exemplo:
se o objetivo de um sistema é controlar acesso físico, deve ser avaliado se todos os campos solicitados no cadastro são necessários para essa finalidade.
Adequação
Adequação relaciona o tratamento às finalidades informadas.
Um sistema pode coletar dados tecnicamente disponíveis, mas isso não significa que todo uso posterior seja adequado à finalidade original.
Arquitetura e processos precisam limitar usos indevidos.
Necessidade
O princípio da necessidade orienta limitação do tratamento ao mínimo necessário.
Em engenharia, isso pode se traduzir em perguntas como:
- precisamos desse campo?
- precisamos guardar essa imagem por tanto tempo?
- precisamos exportar esse dado para outro sistema?
- precisamos de biometria ou outro fator é suficiente?
A resposta jurídica depende do caso, mas o sistema deve permitir aplicar a decisão.
Livre acesso
Titulares possuem direitos de acesso a informações sobre tratamento conforme a LGPD.
Do ponto de vista técnico, dados precisam ser localizáveis e rastreáveis.
Sistemas sem inventário ou integração podem dificultar atendimento.
Qualidade dos dados
A LGPD prevê qualidade dos dados como princípio.
Dados inexatos podem gerar:
- bloqueio indevido;
- acesso incorreto;
- falhas de cadastro;
- decisões equivocadas.
Processos de atualização e correção precisam existir.
Transparência
Transparência envolve fornecer informações claras e acessíveis sobre tratamento.
A arquitetura técnica deve ser conhecida o suficiente para que a organização consiga explicar:
- o que coleta;
- onde armazena;
- com quem compartilha;
- por quanto tempo;
- quais sistemas participam.
Sem inventário, a transparência fica comprometida.
Segurança
A LGPD prevê segurança como princípio e exige medidas técnicas e administrativas aptas a proteger dados pessoais contra acessos não autorizados e situações acidentais ou ilícitas.
Do ponto de vista de engenharia, isso envolve controles como:
- autenticação;
- segmentação;
- criptografia;
- hardening;
- logging;
- backup;
- gestão de vulnerabilidades;
- controle de privilégios.
O controle adequado depende do risco.
Prevenção
Prevenção busca adoção de medidas para evitar danos decorrentes do tratamento.
Isso desloca segurança para antes do incidente.
Em projetos, requisitos de proteção precisam ser definidos ainda na arquitetura.
Corrigir depois da implantação tende a ser mais caro e menos eficaz.
Não discriminação
Dados pessoais não devem ser tratados para fins discriminatórios ilícitos ou abusivos.
Esse princípio é especialmente relevante em sistemas de:
- analytics;
- biometria;
- decisão automatizada;
- scoring;
- classificação de pessoas.
A engenharia precisa entender limitações do algoritmo e do uso pretendido.
Responsabilização e prestação de contas
A organização precisa ser capaz de demonstrar medidas eficazes de conformidade.
Isso aumenta a importância de evidências.
Exemplos técnicos:
- logs;
- relatórios de acesso;
- versões;
- testes;
- backups;
- controles;
- documentação de arquitetura;
- registros de mudança.
Segurança sem evidência é difícil de demonstrar.
Direitos dos titulares
A LGPD prevê direitos dos titulares.
Entre eles, conforme hipóteses legais:
- confirmação de tratamento;
- acesso;
- correção;
- anonimização;
- bloqueio;
- eliminação;
- portabilidade;
- informação sobre compartilhamento;
- revogação do consentimento.
A aplicação concreta depende da situação.
Sistemas precisam permitir que a organização cumpra decisões válidas sobre esses direitos.
Eliminação
Eliminar dados não significa apenas apagar uma tela.
Pode envolver:
- banco principal;
- backups;
- caches;
- replicas;
- exports;
- logs;
- storage de terceiros.
A política precisa considerar arquitetura inteira.
Retenção
Retenção define quanto tempo um dado permanece armazenado.
Não existe um prazo universal para todos os tratamentos.
O prazo depende da finalidade, obrigação aplicável e contexto.
A decisão deve ser formalizada pela organização.
O sistema precisa permitir aplicar a política.
Compartilhamento
Dados podem circular entre sistemas e fornecedores.
Exemplos:
- VMS;
- cloud;
- controle de acesso;
- RH;
- ERP;
- visitante;
- analytics.
Mapear integrações é essencial para saber onde o dado está.
Transferência internacional
Quando dados são transferidos para outro país ou organismo internacional, existem regras específicas.
Cloud e SaaS podem envolver infraestrutura global.
A localização dos dados e subprocessadores precisa ser compreendida antes da contratação.
Dados públicos
O fato de um dado ser publicamente acessível não elimina automaticamente as regras da LGPD.
Finalidade, boa-fé e contexto continuam relevantes.
A organização deve evitar a premissa de que “está na internet, então pode usar livremente”.
Dados de crianças e adolescentes
A LGPD possui regras específicas para tratamento de dados de crianças e adolescentes.
Sistemas em escolas, saúde, eventos e controle de acesso podem lidar com esse público.
O projeto técnico precisa suportar a política definida pela organização.
Decisões automatizadas
Sistemas automatizados podem tratar dados para produzir decisões.
Exemplos:
- antifraude;
- biometria;
- analytics;
- scoring.
A arquitetura deve registrar entradas, regras e resultados de forma compatível com governança.
Perfilização
Combinar dados para criar perfis pode aumentar impacto de privacidade.
Quanto mais fontes integradas, maior a capacidade de inferência.
Integrações devem ser avaliadas em conjunto, não isoladamente.
LGPD e videomonitoramento
Imagens de pessoas identificadas ou identificáveis podem constituir dados pessoais.
Videomonitoramento envolve:
- captura;
- transmissão;
- gravação;
- visualização;
- exportação;
- exclusão.
Cada etapa integra o tratamento.
O projeto precisa permitir políticas de acesso e retenção.
VMS e proteção de dados
O VMS controla grande parte do ciclo do vídeo.
O artigo VMS detalha usuários, auditoria, storage e exportação.
Recursos importantes para governança incluem:
- RBAC;
- logs;
- exportação controlada;
- retenção;
- autenticação;
- trilha de auditoria.
Projeto de CFTV e requisitos de privacidade
Requisitos de privacidade definidos pela organização precisam ser convertidos em retenção, perfis de acesso, logging, segurança, storage e critérios de aceite do sistema.
O Projeto de CFTV IP e Videomonitoramento pode incorporar requisitos técnicos de acesso, retenção, segmentação, registro e segurança definidos pela organização.
Isso não substitui análise jurídica.
O projeto transforma requisitos aprovados em arquitetura verificável.
LGPD e controle de acesso
Sistemas de controle de acesso tratam:
- identidade;
- credenciais;
- horários;
- portas;
- eventos;
- visitantes;
- biometria em alguns casos.
O artigo Gestão de visitantes integrada ao controle de acesso aprofunda cadastro e operação.
Biometria em controle de acesso
Como dado biométrico pode ser sensível, seu uso exige atenção adicional.
Alternativas podem incluir:
- cartão;
- PIN;
- QR Code;
- mobile credential.
A decisão de usar biometria deve derivar de requisito, risco e análise jurídica.
Projeto de controle de acesso
Em sistemas com biometria, credenciais, visitantes e eventos, a arquitetura precisa aplicar tecnicamente os requisitos aprovados para coleta, acesso, integração e retenção.
O Projeto de Controle de Acesso pode definir arquitetura, credenciais, servidores, integrações e controles técnicos conforme requisitos aprovados.
É importante separar:
- decisão jurídica sobre tratamento;
- implementação técnica do sistema.
LGPD e cloud
SaaS e cloud podem atuar como parte do tratamento.
É necessário conhecer:
- região;
- subprocessadores;
- backups;
- logs;
- identidades;
- exportação;
- eliminação.
O artigo Computação em Nuvem aprofunda responsabilidade compartilhada e arquitetura.
LGPD e redes
A rede transporta dados pessoais.
Segmentação e segurança reduzem exposição.
Exemplos:
- VLAN;
- firewall;
- VPN;
- 802.1X;
- logs;
- controle administrativo.
A rede não determina base legal, mas implementa controles de segurança.
Privacy by design
Privacy by design busca incorporar proteção de dados desde a concepção.
Em engenharia, isso significa transformar requisitos de privacidade em decisões de arquitetura.
Exemplos:
- minimizar coleta;
- reduzir retenção;
- segregar dados;
- controlar acesso;
- registrar ações;
- proteger integrações.
A análise precisa ocorrer antes da compra.
Privacy by default
Configurações padrão deveriam preservar apenas o necessário para a finalidade definida.
Isso evita que recursos excessivos sejam habilitados apenas porque o produto oferece.
Em sistemas complexos, defaults precisam ser revisados.
Inventário de dados
Antes de proteger dados, a organização precisa saber onde estão.
Inventário pode relacionar:
- sistema;
- categoria de dado;
- finalidade;
- owner;
- integração;
- storage;
- retenção;
- acesso.
Sem inventário, controles ficam incompletos.
Mapeamento de fluxo
Data flow mostra como dados circulam.
Exemplo:
- visitante cadastra;
- recepção valida;
- sistema grava;
- controlador envia evento;
- VMS correlaciona câmera;
- relatório é exportado.
Esse mapa evidencia múltiplos sistemas.
Controle de acesso lógico
Usuários devem receber privilégios compatíveis com função.
Modelos incluem RBAC.
É importante evitar contas compartilhadas.
Cada ação relevante deve ser atribuível a uma identidade.
Logging e auditoria
Logs ajudam a demonstrar:
- quem acessou;
- quando;
- o que alterou;
- o que exportou.
Eles próprios podem conter dados pessoais.
Portanto, também precisam de proteção e retenção definida.
Criptografia
Criptografia protege dados em trânsito ou repouso.
Ela não substitui controle de acesso.
Se um usuário autorizado indevidamente possui acesso, a criptografia pode não impedir uso impróprio.
Os controles precisam ser combinados.
Backup
Backups também contêm dados pessoais.
Eles precisam seguir:
- segurança;
- retenção;
- acesso;
- recuperação;
- descarte.
Políticas de eliminação precisam considerar cópias de segurança.
Ambientes de teste
Copiar dados de produção para homologação amplia superfície de exposição.
Quando possível, usar:
- dados sintéticos;
- dados minimizados;
- anonimização adequada.
Se dados reais forem necessários, controles precisam permanecer equivalentes.
Fornecedores
Contratações devem mapear quem terá acesso aos dados.
Questões técnicas incluem:
- suporte remoto;
- contas administrativas;
- logs;
- cloud;
- subprocessadores;
- backup.
Responsabilidades jurídicas devem constar em instrumentos adequados.
Requisitos técnicos em contratação
Termos técnicos podem exigir:
- criptografia;
- MFA;
- logs;
- exportação;
- APIs;
- backup;
- segregação;
- atualização;
- vulnerabilidades;
- descarte seguro.
Esses requisitos devem derivar da análise de risco e governança.
Design Review
A revisão técnica pode verificar se redes, integrações, logs, backup, controles de acesso e documentação estão coerentes com os requisitos de proteção definidos para o projeto.
O Design Review em Projetos de Engenharia pode verificar se controles técnicos definidos no projeto estão coerentes entre sistemas, redes, integrações e documentação.
Ele não substitui auditoria jurídica de LGPD.
Seu papel é revisar a implementação de engenharia.
Segurança por camadas
A proteção de dados depende de múltiplas camadas.
Exemplo em videomonitoramento:
- câmera;
- switch;
- firewall;
- VMS;
- servidor;
- storage;
- cliente;
- identidade.
Uma única senha forte não protege toda a cadeia.
Gestão de vulnerabilidades
Sistemas que tratam dados precisam de ciclo de atualização.
Itens:
- inventário;
- advisory;
- patch;
- teste;
- rollout;
- evidência.
Versões sem suporte aumentam risco.
Incidente de segurança
Incidentes podem envolver:
- acesso indevido;
- perda;
- alteração;
- exposição;
- indisponibilidade.
A resposta precisa integrar áreas técnicas e responsáveis de governança.
Procedimentos devem existir antes do incidente.
Evidências técnicas
Durante investigação podem ser necessários:
- logs;
- timeline;
- versões;
- IPs;
- configurações;
- acessos;
- eventos.
Sincronização de tempo é essencial.
Sem evidência, a análise perde qualidade.
RIPD
Relatório de Impacto à Proteção de Dados Pessoais é instrumento previsto na LGPD.
Sua necessidade e conteúdo devem ser avaliados segundo a legislação e orientações aplicáveis.
A engenharia pode fornecer insumos como:
- arquitetura;
- fluxos;
- sistemas;
- controles;
- riscos;
- integrações.
A análise jurídica e de privacidade permanece com os responsáveis competentes.
Minimização técnica
Minimização pode ser implementada por:
- campos opcionais;
- desativação de analytics não necessários;
- mascaramento;
- retenção menor;
- menor resolução quando adequada;
- restrição de exportação.
A técnica deve seguir requisito aprovado.
Mascaramento de privacidade
Câmeras podem aplicar privacy masks.
Elas ocultam áreas que não precisam ser observadas.
Exemplos:
- janelas;
- propriedades adjacentes;
- áreas fora do escopo.
A configuração precisa ser validada para não prejudicar o objetivo de segurança.
Retenção de vídeo
Retenção não deve ser escolhida apenas pela capacidade do disco.
Ela precisa ser definida pela organização conforme finalidade, riscos e obrigações.
Depois, o storage é dimensionado para cumprir esse requisito.
A ordem importa: requisito primeiro, capacidade depois.
Exportação de vídeo
Exportar vídeo cria nova cópia.
O processo deve controlar:
- quem exporta;
- finalidade;
- destino;
- integridade;
- retenção.
VMSs com trilha de auditoria facilitam governança.
Dados biométricos em templates
Sistemas biométricos podem armazenar templates em vez da imagem original.
Isso não elimina automaticamente a natureza sensível do dado.
Arquitetura, proteção e finalidade continuam relevantes.
Cancelamento de credenciais
Quando uma pessoa deixa a organização, credenciais precisam ser revogadas.
Também pode ser necessário revisar:
- conta;
- biometria;
- cartões;
- logs;
- retenção.
Desativar acesso não é igual a eliminar todos os dados.
Qualidade e atualização cadastral
Cadastros incorretos podem causar acesso indevido.
Processos precisam prever:
- correção;
- atualização;
- recertificação.
Dados pessoais não devem ser mantidos desatualizados sem necessidade.
Matriz de responsabilidades
Uma matriz pode relacionar:
- processo;
- dado;
- sistema;
- controlador;
- operador;
- owner técnico;
- fornecedor;
- retenção.
Isso conecta governança e tecnologia.
Baseline de configuração
Sistemas críticos devem possuir baseline.
Ela registra:
- versão;
- integrações;
- usuários;
- regras;
- criptografia;
- logs;
- retenção;
- backups.
Mudanças posteriores ficam rastreáveis.
Critérios de aceite técnico
No comissionamento, controles podem ser testados.
Exemplos:
- perfil de usuário;
- log de exportação;
- retenção;
- segregação;
- backup;
- restauração;
- acesso remoto;
- revogação.
O aceite comprova implementação do requisito técnico.
Erros recorrentes
| Erro | Consequência |
| achar que LGPD = consentimento | interpretação incompleta |
| tratar toda informação como sensível | classificação incorreta |
| confundir controlador com fornecedor | responsabilidades obscuras |
| coletar campos sem finalidade | excesso de dados |
| retenção sem política | armazenamento indefinido |
| conta compartilhada | baixa rastreabilidade |
| ignorar backups | cópias não governadas |
| considerar produto “LGPD compliant” isoladamente | falsa sensação de conformidade |
Registro das operações de tratamento
Organizações precisam conhecer quais operações realizam com dados pessoais. Um registro estruturado pode relacionar finalidade, categorias de dados, sistemas, destinatários, retenção e responsáveis.
Do ponto de vista técnico, esse mapeamento ajuda a localizar bases, integrações e cópias que precisam de controles.
Controle de acesso baseado em função
RBAC permite limitar acesso conforme função. Operador, supervisor, auditor e administrador não precisam possuir os mesmos privilégios.
Essa segregação reduz exposição e melhora prestação de contas porque cada papel executa apenas operações necessárias.
Recertificação periódica de acessos
Permissões acumulam-se ao longo do tempo. Mudança de cargo ou saída de fornecedor pode deixar acessos antigos ativos.
Revisões periódicas de usuários e perfis ajudam a confirmar que privilégios continuam necessários.
Descarte seguro
Eliminar dados também envolve mídias e equipamentos. Discos, cartões SD, appliances e dispositivos substituídos podem conter informações pessoais.
Processos de descarte precisam prever sanitização ou destruição adequada conforme criticidade e tecnologia.
Gestão de terceiros e suporte remoto
Integradores e fabricantes podem acessar sistemas para suporte. Esse acesso deve ser autorizado, limitado, registrado e revogado quando não for mais necessário.
Contas genéricas permanentes de fornecedor reduzem rastreabilidade e devem ser evitadas quando a plataforma permite identidades individuais.
Classificação de sistemas por exposição
Sistemas que tratam dados pessoais podem possuir níveis diferentes de exposição. Uma aplicação interna sem acesso externo e um portal público enfrentam superfícies de risco distintas.
Classificar criticidade e exposição ajuda a definir autenticação, monitoramento, segmentação e prioridade de correção de vulnerabilidades.
Rastreabilidade entre requisito e controle técnico
Requisitos de privacidade e segurança precisam ser ligados aos controles que os implementam. Se existe requisito de retenção, deve ser possível identificar qual configuração de banco, VMS ou storage o cumpre.
Essa rastreabilidade facilita auditoria e mudança porque mostra quais controles precisam ser revistos quando a finalidade, processo ou sistema muda.
Governança de retenção e revisão periódica
Políticas de retenção precisam ser revistas quando processos, finalidade, contratos ou sistemas mudam. Manter dados indefinidamente apenas porque existe capacidade de storage aumenta exposição e dificulta governança.
A revisão deve envolver responsáveis de negócio, jurídico, privacidade, segurança e áreas técnicas conforme o contexto.
Handover de sistemas que tratam dados pessoais
Na entrega de um sistema, a equipe responsável precisa receber inventário, perfis, logs, backups, integrações, procedimentos de acesso e documentação de retenção. Sem isso, controles definidos no projeto podem se perder durante a operação.
Essa transição técnica não substitui governança jurídica, mas é necessária para manter os controles implementados ao longo do ciclo de vida.
Como fechamento técnico, a organização precisa conseguir relacionar cada sistema que trata dados pessoais às finalidades, responsáveis, integrações, controles e políticas aplicáveis. Essa rastreabilidade permite que decisões jurídicas e de privacidade sejam efetivamente refletidas em configuração, operação e documentação.
Também é importante revisar a arquitetura quando o tratamento muda. Novos analytics, integrações, fornecedores, serviços em nuvem ou formas de autenticação podem ampliar categorias de dados, fluxos e riscos. A mudança técnica deve ser acompanhada pela governança responsável pelo tratamento.
Na prática, a engenharia contribui mantendo inventário, logs, segregação, retenção configurável, backups, controle de acesso e evidências de funcionamento. Esses elementos não definem conformidade jurídica sozinhos, mas tornam os requisitos aprovados verificáveis e sustentáveis durante o ciclo de vida do sistema.
Uma arquitetura madura também precisa preservar evidências de que os controles definidos foram efetivamente implementados. Inventários, diagramas, registros de acesso, configurações de retenção, backups e testes ajudam a demonstrar o estado técnico do sistema em determinado momento.
Quando processos ou sistemas mudam, essa baseline deve ser atualizada. Sem revisão contínua, controles inicialmente adequados podem deixar de representar o tratamento real, criando lacunas entre governança, documentação e operação.
Essa rastreabilidade técnica sustenta a governança ao longo do tempo.
Esse controle contínuo reduz a distância entre a arquitetura documentada e o tratamento efetivamente realizado.
Considerações finais
As definições da LGPD estruturam qualquer discussão sobre proteção de dados.
Dado pessoal, dado sensível, titular, tratamento, controlador, operador, encarregado e anonimização possuem significados específicos.
Em sistemas de engenharia, a função técnica é transformar requisitos aprovados em controles verificáveis: autenticação, segregação, retenção, logging, criptografia, backup, rastreabilidade e gestão de acesso.
A conformidade não pertence a um único produto. Ela depende de processos, pessoas, bases jurídicas, contratos e arquitetura técnica funcionando de forma coordenada.
Referências técnicas
[1] Presidência da República. Lei nº 13.709, de 14 de agosto de 2018 — Lei Geral de Proteção de Dados Pessoais. Disponível em: https://www.planalto.gov.br/ccivil_03/_ato2015-2018/2018/lei/l13709.htm.
[2] Autoridade Nacional de Proteção de Dados. Portal da ANPD. Disponível em: https://www.gov.br/anpd/pt-br.
[3] Autoridade Nacional de Proteção de Dados. Guia Orientativo para Definições dos Agentes de Tratamento de Dados Pessoais e do Encarregado. Disponível em: https://www.gov.br/anpd/pt-br/documentos-e-publicacoes/2021.05.27GuiaAgentesdeTratamento_Final.pdf.
Perguntas frequentes
É informação relacionada a pessoa natural identificada ou identificável.
É a categoria prevista na LGPD que inclui, entre outros, dados sobre saúde, vida sexual, origem racial ou étnica, convicção religiosa e dado biométrico vinculado a pessoa.
O controlador toma as decisões sobre o tratamento; o operador trata dados em nome do controlador.
Não. Consentimento é uma das bases legais previstas na LGPD; existem outras hipóteses de tratamento.
Sim, quando relacionada a pessoa natural identificada ou identificável.
A conformidade depende do contexto de tratamento, processos, responsabilidades e controles; não apenas de um produto isolado.
