Entenda como a criptografia protege dados pessoais, onde aplicá-la e quais controles, evidências e testes ajudam sua empresa na adequação à LGPD.

Um cliente preenche o formulário da Alfa Clima, pequena empresa fictícia de manutenção, e seus dados seguem para um CRM em nuvem. Depois, o cadastro aparece no notebook da equipe comercial, entra no backup e, algumas vezes, é exportado para uma planilha. Cada passagem cria uma exposição diferente: interceptação durante a transmissão, acesso indevido ao sistema, perda de equipamento, compartilhamento incorreto ou recuperação inadequada de uma cópia antiga.

A Encryption, ou criptografia, pode tornar parte dessas informações ilegível para quem não dispõe da chave e das permissões adequadas. Isso não significa que todo dado precise ser cifrado da mesma maneira nem que a ativação de um recurso encerre a análise. A proteção depende do fluxo real, da arquitetura, da gestão de chaves, dos acessos e do momento em que o conteúdo precisa ser aberto para uso.

Este guia apresenta um caminho prático para diferenciar a criptografia de controles relacionados, mapear os pontos de exposição, classificar prioridades, avaliar fornecedores e manter evidências. O objetivo não é prescrever uma tecnologia universal, mas ajudar a empresa a tomar decisões proporcionais ao risco e compatíveis com suas responsabilidades de proteção de dados.

Principais pontos

• A criptografia reduz a possibilidade de leitura indevida, mas não impede sozinha a perda, a alteração ou o uso abusivo de dados pessoais.
• A LGPD exige medidas de segurança adequadas ao contexto e ao risco, sem estabelecer uma obrigação geral de criptografar toda operação.
• Criptografia, hashing, codificação, tokenização, anonimização e proteção por senha têm finalidades e efeitos diferentes.
• Um mapa verificável deve registrar dado, origem, destino, responsável, proteção atual e impacto de uma possível exposição.
• Chaves, credenciais, permissões e testes de restauração determinam se a proteção continuará funcionando durante um incidente.
• Prazos de implantação, revisões e testes devem ser definidos conforme risco, criticidade e capacidade operacional, e não tratados como padrões universais.
• Consentimento e legítimo interesse são bases legais distintas, e nenhuma delas pode ser substituída por criptografia.
• A avaliação de fornecedores deve combinar requisitos mínimos, evidências técnicas, responsabilidades contratuais e critérios claros de aprovação.

O que é Encryption e como a criptografia protege os dados

Encryption é o termo em inglês para criptografia. O processo recebe um dado legível, aplica um algoritmo com uma chave criptográfica e produz um dado cifrado. Sem a chave e o mecanismo autorizados, o conteúdo tende a permanecer incompreensível. Na Alfa Clima, uma planilha aberta pode ser lida por quem obtiver uma cópia; se o arquivo estiver adequadamente cifrado, a simples posse da cópia não deveria revelar seu conteúdo.

Na criptografia simétrica, a mesma chave costuma ser empregada para cifrar e decifrar. Na assimétrica, usam-se chaves relacionadas com funções distintas. Sistemas empresariais frequentemente combinam os dois modelos e podem adotar criptografia de envelope: uma chave cifra o dado, enquanto outra chave, administrada por um serviço de gerenciamento de chaves ou KMS, protege a primeira. A escolha depende da arquitetura e deve ser feita com apoio técnico competente.

Criptografia não é sinônimo de hashing. Um hash produz um resumo de tamanho definido e é projetado para não permitir a recuperação direta do valor original. Ele pode ser usado, por exemplo, na verificação de integridade e, com técnicas adequadas, no armazenamento de senhas. Já a criptografia é reversível para quem possui autorização e chave. Por isso, simplesmente cifrar senhas para depois recuperá-las não equivale às práticas específicas normalmente exigidas para seu armazenamento seguro.

Também não se deve confundir criptografia com codificação, que apenas representa dados em outro formato e pode ser revertida sem segredo; com tokenização, que substitui um valor por um token e mantém a correspondência em um sistema controlado; ou com anonimização, que busca impedir a associação razoável com uma pessoa. Um arquivo protegido por senha pode usar criptografia, mas a presença de uma senha, por si só, não comprova algoritmo adequado, configuração segura, controle de tentativas ou boa gestão da credencial.

A criptografia reduz a possibilidade de leitura indevida, mas não apaga o arquivo, não impede necessariamente sua alteração e não bloqueia um usuário autorizado de copiar dados enquanto eles estão abertos. Integridade, disponibilidade, prevenção contra malware, limitação de privilégios e monitoramento continuam necessários.

Por que a criptografia importa na adequação à LGPD

O artigo 46 da Lei nº 13.709/2018 prevê a adoção de medidas de segurança, técnicas e administrativas aptas a proteger dados pessoais contra acessos não autorizados e situações acidentais ou ilícitas. Essa disposição estabelece um dever amplo de segurança, mas não deve ser interpretada isoladamente como uma obrigação geral de criptografar todos os dados, sistemas e operações. O alcance aplicável a cada organização e setor deve ser validado em revisão jurídica, considerando também regulamentações específicas, contratos e características do tratamento.

A decisão prática começa pela pergunta: uma pessoa sem autorização conseguiria ler os dados se interceptasse a comunicação, obtivesse o arquivo, acessasse o backup ou levasse o equipamento? Quanto mais provável e danosa for essa hipótese, mais forte será a justificativa para adotar criptografia, combinada com outros controles. Dados sensíveis, documentos financeiros, credenciais, bases extensas, dispositivos móveis e ambientes acessíveis pela internet normalmente demandam análise prioritária, sem que isso dispense a avaliação concreta.

A empresa também deve considerar quem precisa usar a informação. Se muitos usuários podem abrir o conteúdo, a criptografia de armazenamento não corrige permissões excessivas. Se o principal risco está na transmissão para um fornecedor, a prioridade pode ser proteger o canal e autenticar os pontos da conexão. Se um notebook pode ser perdido, a cifragem integral do disco, associada a bloqueio de tela e gestão do dispositivo, pode reduzir a exposição da cópia local.

Criptografar não determina a base legal do tratamento. Consentimento, legítimo interesse e as demais hipóteses legais possuem requisitos próprios. A medida também não substitui finalidade definida, necessidade, transparência, retenção adequada, atendimento aos titulares, contratos, treinamento ou resposta a incidentes.

A Resolução CD/ANPD nº 15/2024 deve ser aplicada com precisão. A comunicação é exigida quando o incidente de segurança puder acarretar risco ou dano relevante aos titulares, conforme os critérios regulatórios. Nessa hipótese, cabe ao controlador comunicar a ANPD e os titulares afetados no prazo geral de três dias úteis, contado do conhecimento, pelo controlador, de que o incidente afetou dados pessoais, ressalvados prazos específicos previstos em legislação. Antes de iniciar a contagem ou concluir que o caso não é comunicável, a empresa deve registrar fatos, papéis dos agentes e fundamentos, além de buscar revisão jurídica quando houver dúvida.

O operador, por sua vez, deve informar o controlador sem demora injustificada, de modo a permitir a avaliação e o cumprimento das obrigações aplicáveis.

• Criptografar quando a exposição permitir leitura direta de dados com impacto relevante.
• Priorizar canais externos, dispositivos móveis, backups, credenciais e bases sensíveis ou extensas.
• Combinar a criptografia com controle de acesso quando usuários autorizados representarem parte do risco.
• Documentar por que a medida foi adotada, adiada, substituída ou considerada desnecessária.

Onde aplicar criptografia no fluxo dos dados pessoais

O cadastro da Alfa Clima começa como dado em trânsito entre o navegador e o formulário, segue por uma integração e chega ao CRM. Depois, torna-se dado em repouso no banco, no notebook e no backup. Enquanto um atendente consulta o endereço do cliente, o dado está em uso e pode ser exposto por permissões excessivas, extensões maliciosas, captura de tela ou observação do ambiente. A criptografia costuma proteger trânsito e repouso, mas o dado em uso exige controles complementares.

Uma relação genérica de sistemas não basta. O mapa precisa permitir que outra pessoa confira o caminho do dado, identifique o responsável e entenda a consequência de uma exposição. Cada linha deve representar um fluxo ou uma cópia concreta, incluindo exportações, integrações, anexos, logs e ambientes de teste. O registro deve ser atualizado quando houver mudança de fornecedor, finalidade, destino, acesso ou configuração.

Na Alfa Clima, o formulário pode usar conexão protegida, enquanto a integração com o CRM permanece mal documentada e as exportações são enviadas por e-mail. O mapa torna essa diferença visível e evita concluir que todo o processo está protegido apenas porque o site utiliza HTTPS. Ele também ajuda a verificar se a proteção declarada por um fornecedor alcança bancos, arquivos, réplicas e backups.

Modelo verificável de mapeamento de dados e proteções

Dado e finalidade	Origem	Destino ou cópia	Responsável	Proteção atual	Impacto da exposição
Nome, telefone e endereço para agendamento	Formulário do site	CRM em nuvem	Gestor comercial	Conexão protegida; configuração do armazenamento a confirmar	Contato indevido, fraude ou exposição da rotina do cliente
Cadastro exportado para atendimento	CRM	Notebook e planilha local	Supervisor de atendimento	Disco cifrado; arquivo sem controle próprio identificado	Leitura da base em caso de compartilhamento ou cópia
Cópia do banco para recuperação	CRM	Backup do fornecedor	TI e fornecedor	Criptografia declarada; restauração ainda não testada	Exposição em massa ou indisponibilidade se a recuperação falhar
Dados enviados para prestador	Sistema de gestão	API do parceiro	Gestor do contrato	Canal protegido; autenticação e logs sujeitos a validação	Acesso indevido, alteração ou uso fora da finalidade

Como implementar Encryption de forma proporcional ao risco

A Alfa Clima não precisa começar tentando cifrar tudo ao mesmo tempo. Primeiro, deve classificar os cenários com uma escala compreensível. O impacto pode ser baixo quando a exposição tende a ser limitada, reversível e sem dados de maior criticidade; médio quando pode gerar constrangimento, fraude limitada, interrupção relevante ou atingir várias pessoas; e alto quando envolve dados sensíveis, credenciais, grande volume, risco à segurança física, fraude expressiva ou consequências difíceis de reverter. A probabilidade pode ser baixa, média ou alta conforme exposição à internet, quantidade de usuários, histórico de falhas, mobilidade e eficácia dos controles existentes.

A prioridade resulta da combinação entre impacto e probabilidade. Cenários altos em ambos os eixos exigem tratamento imediato ou suspensão controlada da atividade, enquanto riscos médios podem entrar no ciclo planejado seguinte. Riscos baixos podem ser aceitos temporariamente, desde que a decisão, o responsável, as condições e a data de revisão sejam registrados. Essa escala não substitui uma metodologia formal, mas permite decisões mais consistentes do que expressões vagas como “urgente” ou “importante”.

Um ciclo inicial de 30 dias pode ser útil para uma pequena empresa mapear o formulário, o CRM, os notebooks e os backups, desde que seja apresentado como exemplo de organização, e não como padrão técnico. Um ambiente com dados sensíveis ou falha ativa pode exigir ação em horas ou dias; um projeto estrutural complexo pode precisar de fases mais longas, controles compensatórios e marcos aprovados.

Da mesma forma, um piloto de 5 dias úteis pode servir para testar uma configuração simples em poucos equipamentos, mas não comprova adequação para qualquer sistema. A duração deve considerar criticidade, volume, janela operacional, possibilidade de reversão e participação de profissional qualificado. O piloto precisa verificar se usuários autorizados continuam trabalhando, se a recuperação funciona, se o desempenho permanece aceitável e se os registros permitem demonstrar o resultado.

1. Mapeie o fluxo e valide as lacunas com os responsáveis técnicos e de negócio.
2. Classifique impacto e probabilidade com critérios documentados.
3. Defina tratamento, prazo, responsável, dependências e controle temporário.
4. Implemente primeiro em escopo controlado e mantenha opção de reversão.
5. Teste acesso autorizado, bloqueio indevido, recuperação, desempenho e logs.
6. Registre resultados, exceções, risco residual e data de nova avaliação.

Chaves, acessos e backups: os controles que sustentam a criptografia

A proteção depende menos de esconder a existência da criptografia e mais de controlar as chaves. Dados, chaves e credenciais administrativas não devem ficar acessíveis ao mesmo conjunto irrestrito de pessoas e sistemas. Essa separação não precisa ser física. Em arquiteturas com KMS e criptografia de envelope, ela pode ser lógica, baseada em identidades, papéis, políticas, registros e permissões que impeçam uma única conta de obter simultaneamente dados e material criptográfico sem controle.

A empresa deve nomear responsáveis por administrar a política, aprovar acessos, executar mudanças e revisar evidências. A rotação de uma chave pode ser acionada por suspeita de comprometimento, mudança de administrador, exigência contratual, falha de algoritmo ou política definida conforme o risco. A revogação deve ocorrer quando uma chave ou credencial não for mais necessária, quando houver desligamento, perda de dispositivo, acesso indevido ou encerramento de fornecedor. Cada evento precisa gerar evidência, como solicitação aprovada, registro do KMS, chamado técnico, log de alteração e validação posterior.

A recuperação requer procedimento diferente da rotina comum. A empresa deve definir quem pode solicitá-la, quem aprova, quais fatores de autenticação são exigidos, onde ficam as cópias de contingência e como o uso excepcional será registrado. Concentrar todo o conhecimento em uma pessoa cria risco de indisponibilidade; distribuir acesso sem aprovação cria risco de exposição. A solução deve equilibrar continuidade e segregação de funções.

Revisões trimestrais de acesso e testes semestrais de restauração podem ser pontos de partida para a Alfa Clima, não frequências universais. Sistemas com dados sensíveis, alta rotatividade de pessoal, mudanças frequentes ou operação crítica podem exigir revisões mensais, por evento ou automatizadas. Ambientes estáveis e de menor impacto podem admitir intervalos maiores, desde que a justificativa seja documentada. Além da periodicidade, demissões, mudanças de função, incidentes, migrações e alterações de fornecedor devem disparar revisões extraordinárias.

Um backup cifrado só cumpre sua função se puder ser restaurado. O teste deve confirmar a disponibilidade da chave, a integridade da cópia, o tempo de recuperação e a possibilidade de acesso pelos responsáveis autorizados. Como evidência, convém guardar data, escopo, participantes, resultado, falhas encontradas, ações corretivas e nova validação.

Como avaliar ferramentas e fornecedores sem depender de jargões

Expressões como “segurança avançada” ou “criptografia de nível militar” não esclarecem a cobertura contratada. A Alfa Clima deve transformar a necessidade em requisitos verificáveis: proteção dos canais externos, cifragem de armazenamento e backups quando indicada pelo risco, contas individuais, autenticação forte para funções privilegiadas, logs, recuperação testável e definição de quem controla as chaves.

A análise deve distinguir recurso disponível de recurso efetivamente incluído, ativado e configurado. Um CRM pode oferecer criptografia apenas em determinado plano, deixar exportações fora da cobertura ou atribuir ao cliente a proteção de integrações. A responsabilidade compartilhada precisa constar do contrato, de anexo técnico ou de matriz vinculada à contratação, com responsáveis por configuração, monitoramento, incidentes, exclusão, devolução dos dados e encerramento.

Como evidência, podem ser solicitados documentos de arquitetura, descrição da gestão de chaves, relatório independente disponível, política de controle de acesso, procedimento de resposta a incidentes, histórico ou evidência de testes de continuidade e instruções de portabilidade e exclusão. Certificações contribuem para a avaliação, mas não provam que o serviço específico, o plano contratado e a configuração da empresa estejam cobertos.

O contrato deve prever dever de cooperação em incidentes, comunicação em tempo compatível com as obrigações do controlador, preservação de registros, uso de suboperadores, localização ou transferência de dados quando aplicável, devolução e exclusão ao término, níveis de serviço relevantes e responsabilidades de cada parte. A revisão jurídica deve adaptar as cláusulas à relação concreta, sem aceitar garantias genéricas que não possam ser verificadas.

A aprovação exige atendimento aos requisitos obrigatórios ou um plano formal para lacunas aceitas, com prazo, responsável e controle compensatório. A reprovação é justificável quando o fornecedor não informa onde os dados e backups ficam protegidos, não define papéis sobre chaves e incidentes, impede exportação ou exclusão compatível, recusa evidências proporcionais ao risco ou apresenta contradição relevante entre proposta, documentação e contrato.

Critérios mínimos para aprovar ou reprovar um fornecedor

Critério	Requisito mínimo	Evidência esperada	Sinal de reprovação
Cobertura	Identificar proteção de trânsito, repouso, backups, exportações e integrações	Arquitetura, manual de configuração e escopo contratual	Resposta genérica sem delimitar sistemas, planos ou exceções
Chaves e acessos	Definir administrador, permissões, recuperação, rotação e revogação	Matriz de papéis, política e registros disponíveis	Uma conta compartilhada ou ausência de processo de recuperação
Incidentes	Notificar e cooperar em tempo compatível com a avaliação do controlador	Procedimento, contatos, prazos contratuais e forma de preservar logs	Comunicação sem prazo, canal ou responsável definido
Continuidade	Manter restauração testável e objetivos compatíveis com o negócio	Relatórios de teste, descrição de backups e plano de continuidade	Fornecedor não demonstra como recupera dados cifrados
Encerramento	Permitir devolução e exclusão verificável dos dados	Cláusula contratual e procedimento de saída	Dependência sem portabilidade ou exclusão sem confirmação

Erros comuns que reduzem ou anulam a proteção

Um problema recorrente é tratar a criptografia como selo de segurança, sem verificar o cenário que ela cobre. A Alfa Clima pode proteger o banco de dados e continuar vulnerável porque contas administrativas são compartilhadas, sessões permanecem abertas ou um usuário legítimo consulta informações além de sua função. Nesses casos, o conteúdo é decifrado pelo próprio sistema e apresentado a uma pessoa que não deveria recebê-lo.

Outro erro é presumir que HTTPS protege todo o ciclo de vida. Ele protege a comunicação entre pontos compatíveis, desde que corretamente configurado e validado, mas não mantém automaticamente o conteúdo cifrado depois que chega ao CRM. Também não controla consultas internas, impressão, captura de tela ou reaproveitamento do dado por uma integração.

Configurações padrão merecem verificação. Um recurso pode existir e estar desativado, proteger apenas novos arquivos ou depender de uma chave armazenada na conta do mesmo administrador. A evidência relevante não é uma caixa marcada na interface, mas a combinação entre configuração, teste, registro e responsabilidade definida.

Também é incorreto considerar um arquivo cifrado como anônimo. Se a organização ou outra parte consegue recuperar ou relacionar as informações por meios razoáveis, os dados continuam pessoais. A criptografia não autoriza coleta excessiva, retenção indefinida ou uso incompatível com a finalidade informada.

Por fim, a empresa não deve prometer segurança absoluta. Algoritmos, produtos e arquiteturas mudam, credenciais podem ser comprometidas e usuários autorizados podem agir incorretamente. O objetivo é reduzir riscos de forma demonstrável, detectar desvios, responder a eventos e revisar controles quando o contexto se alterar.

• Conceder a usuários mais capacidade de decifrar dados do que suas funções exigem.
• Confundir disponibilidade do recurso com ativação e cobertura comprovadas.
• Usar senha fraca ou compartilhada como único controle de um arquivo.
• Tratar conexão protegida como solução para armazenamento e uso interno.
• Presumir que dados cifrados deixaram de ser dados pessoais.
• Manter exceções sem responsável, prazo, controle compensatório ou revisão.

Perguntas frequentes

Encryption e criptografia são a mesma coisa?

Sim. Encryption é o termo em inglês para criptografia, processo que transforma conteúdo legível em dado cifrado recuperável mediante chave e mecanismo autorizados.

A criptografia é obrigatória para cumprir a LGPD?

A LGPD exige medidas de segurança adequadas ao contexto e ao risco, mas não estabelece criptografia universal nem um algoritmo único. A necessidade deve ser avaliada em cada operação e pode depender de normas setoriais, contratos e revisão jurídica.

Criptografar dados torna a empresa automaticamente adequada à LGPD?

Não. A empresa ainda precisa definir base legal, finalidade, necessidade, transparência, retenção, direitos dos titulares, acessos, contratos, treinamento e resposta a incidentes.

Qual é a diferença entre criptografia, hash, codificação, tokenização e anonimização?

A criptografia permite recuperar o conteúdo com chave. O hash produz um resumo projetado para não ser revertido diretamente. A codificação muda a representação sem depender de segredo. A tokenização substitui o valor por um identificador cuja correspondência fica controlada. A anonimização busca impedir associação razoável com uma pessoa.

Proteger um arquivo com senha é o mesmo que criptografá-lo?

Não necessariamente. O recurso pode usar criptografia, mas é preciso verificar algoritmo, configuração, força e gestão da senha, controle de tentativas e processo de recuperação. A simples presença de uma senha não comprova proteção adequada.

HTTPS é suficiente para proteger os dados pessoais de um site?

Não. HTTPS protege a comunicação entre o navegador e o servidor, mas os dados também precisam de controles no sistema, no armazenamento, nas integrações, nos acessos internos e durante o uso.

Dados armazenados na nuvem já ficam criptografados automaticamente?

Depende do serviço, do plano e da configuração. Confirme a cobertura de bancos, arquivos, backups, réplicas, exportações e integrações, além das tarefas atribuídas ao cliente.

Quem deve controlar as chaves de criptografia?

A resposta depende da arquitetura e do risco. A empresa deve saber quem administra, acessa, recupera, rotaciona e revoga as chaves, ainda que um fornecedor execute as operações por meio de KMS.

Dados, chaves e credenciais precisam ficar fisicamente separados?

Não em todos os casos. A separação relevante pode ser lógica, com identidades, permissões, políticas e registros distintos, como ocorre em KMS e criptografia de envelope. O objetivo é impedir acesso irrestrito por uma única conta ou função.

Backups também precisam ser criptografados?

Backups com dados pessoais devem entrar na análise de risco. Quando cifrados, precisam de acesso restrito, gestão de chaves e testes de restauração que confirmem disponibilidade e integridade.

O que acontece se a empresa perder a chave de criptografia?

Os dados podem tornar-se inacessíveis. Recuperação autorizada, responsabilidades definidas, cópias de contingência controladas e testes periódicos reduzem esse risco sem conceder acesso irrestrito.

Dados criptografados deixam de ser considerados dados pessoais?

Em regra, não. Se a organização ou outra parte puder recuperar ou relacionar as informações com meios razoáveis, elas continuam sujeitas às obrigações aplicáveis aos dados pessoais.

Todo incidente com dados pessoais deve ser comunicado em três dias úteis?

Não. Pela Resolução CD/ANPD nº 15/2024, a comunicação se aplica ao incidente que possa acarretar risco ou dano relevante aos titulares. Quando cabível, o prazo geral é contado do conhecimento, pelo controlador, de que o incidente afetou dados pessoais, ressalvadas regras específicas. A caracterização e a contagem devem ser documentadas e submetidas a revisão jurídica em caso de dúvida.

Conclusão

A criptografia produz mais valor quando acompanha o caminho real dos dados e responde a riscos identificados, não quando aparece como uma configuração isolada. Comece por um mapa com origem, destino, responsável, proteção atual e impacto da exposição. Depois, classifique probabilidade e impacto, escolha medidas compatíveis e registre por que cada decisão foi tomada.

A implementação deve incluir gestão de chaves, permissões, recuperação, testes e evidências. Prazos como 30 dias para um ciclo inicial, 5 dias úteis para um piloto, revisão trimestral ou teste semestral podem ajudar a organizar uma pequena empresa, mas precisam ser reduzidos, ampliados ou substituídos conforme criticidade, mudanças e capacidade operacional.

Um diagnóstico de maturidade pode reunir essas informações e mostrar quais lacunas técnicas, contratuais e administrativas exigem prioridade. A adequação à LGPD não se resume à Encryption, mas uma aplicação bem governada da criptografia pode reduzir exposições relevantes e demonstrar decisões de segurança mais consistentes.