Resposta rápida

Criptografia na ISO 27001 é o controle A.8.24 (era A.10.1 na versão 2013) e pede política formal com algoritmo definido por finalidade. Chave mínima de 128 bits; 56 bits está obsoleto; AES é a referência simétrica. A evidência que falta na maioria das empresas é a matriz de sistema, ferramenta, algoritmo e equipamento — que deve ter acesso restrito, porque revelar a metodologia facilita o atacante. Gestão de chaves cobre geração aleatória, armazenamento seguro, troca de pre-shared key por voz e regra de firewall após fechar a VPN. O erro mais comum em auditoria é cobertura parcial: evidenciar cinco máquinas quando a política diz que todas são criptografadas.

Criptografia é um daqueles controles que quase toda empresa já tem — e quase nenhuma consegue provar. O time de TI sabe fazer, a ferramenta já vem com a função ativada, e ainda assim o requisito vira não conformidade em auditoria por um motivo simples: falta o mapeamento de onde, como e com qual algoritmo a criptografia é usada.

Neste artigo, a consultora Jennifer Dantas, especialista em ISO 27001 e ISO 27701 na Templum, mostra o que a norma exige no controle criptográfico, quais tamanhos de chave já são considerados obsoletos e como montar a evidência que o auditor pede.

Onde o controle criptográfico aparece nas normas

Na ISO/IEC 27001:2022, o uso de criptografia é o controle A.8.24 do Anexo A (na versão 2013 ele era numerado como A.10.1 — referência que ainda aparece em muito material antigo). A ISO/IEC 27002 é a norma que traz os exemplos de como implementar: se você está implementando a 27001, vale ter a 27002 ao lado, porque é ela que dá o direcionamento prático.

Para quem também trata dados pessoais, a ISO/IEC 27701 reforça o tema na seção 6.7, com controles específicos tanto para quem é controlador (Anexo A) quanto para quem é operador (Anexo B) — e há organizações que são as duas coisas, precisando atender aos dois anexos.

E há a camada legal: o artigo 6º da LGPD estabelece o princípio de segurança e prevenção, exigindo medidas técnicas para prevenir danos aos titulares. Criptografia é uma das formas mais diretas de materializar isso.

O desafio real: algoritmo obsoleto é risco, não legado

Usar algoritmo criptográfico obsoleto ou comprovadamente fraco expõe dado sensível e quebra conformidade. O impacto não é teórico: violação de dados pessoais, sanções regulatórias, perda de confiança do cliente e, em casos extremos que o mercado já viu, empresas que não sobreviveram ao incidente.

Tamanho de chave: o que ainda vale e o que não vale mais

  • Mínimo recomendado: 128 bits. É o piso para se considerar seguro hoje.
  • 56 bits está obsoleto. Era comum anos atrás e ainda aparece em ambiente legado — não sustenta mais o padrão de segurança.
  • Combinações são aceitas quando o resultado mantém o nível reconhecido internacionalmente — é o caso do 3DES com chave de 168 bits, ainda encontrado em VPN e ambiente de nuvem.
  • AES é a referência para criptografia simétrica. As cifras em uso devem ser compatíveis com esse padrão, e os algoritmos de assinatura precisam ser validados.

A política de criptografia — e o que ela precisa dizer

A norma exige que a política para uso de controles criptográficos seja definida e implementada formalmente. Não basta o time saber fazer: precisa estar escrito qual algoritmo se usa para cada finalidade — criptografia de disco, criptografia em trânsito, ferramenta por ferramenta.

Um formato que funciona bem em auditoria é uma matriz com quatro colunas:

  • Sistema ou informação protegida
  • Ferramenta utilizada (por exemplo, o Microsoft BitLocker, presente em praticamente todo parque de notebooks)
  • Algoritmo e tamanho de chave (AES 128 ou 256; 3DES 168)
  • Equipamento ou contexto (notebooks, VPN, nuvem)

Recomenda-se revisar essa matriz semestralmente, acompanhando a evolução das práticas.

Atenção: essa matriz é informação classificada

Aqui entra um ponto que muitas empresas erram por excesso de transparência interna. A matriz criptográfica não deve circular por toda a organização. Ela precisa de controle de acesso restrito, dentro da lógica de classificação e rotulagem da informação.

O raciocínio é de risco: se uma máquina for comprometida, quanto menos o atacante souber sobre qual metodologia, algoritmo e ferramenta você usa, mais difícil o trabalho dele. Se a política precisar ficar acessível a mais gente, mantenha a matriz em documento complementar de acesso restrito — a norma não exige que esteja no mesmo arquivo.

Gestão de chaves: o ciclo de vida inteiro

Criptografar é metade do controle. A outra metade é gerenciar as chaves durante todo o ciclo de vida, protegendo contra perda, roubo e comprometimento:

  • Geração aleatória com geradores criptograficamente seguros — vale especialmente para VPNs internas.
  • Armazenamento seguro, com acesso limitado a um número pequeno de responsáveis. Em muitas empresas, uma única pessoa.
  • VPN com clientes: as chaves devem ser geradas em comum acordo, respeitando o padrão de segurança das duas partes.
  • Troca segura: em IPsec, a pre-shared key deve ser trocada por voz, ao telefone, com o setor especializado do cliente — nunca por escrito ou canal digital inseguro. Isso previne vazamento e ainda confirma que você está falando com quem diz ser. A mesma prática vale para certificados digitais.
  • Controle de acesso após o fechamento da VPN: criar regra no firewall para que apenas um grupo de hosts ou uma rede determinada acesse o túnel.
  • Rotação e revogação definidas na política, com segregação entre quem opera e quem administra as chaves.

Transparência com o cliente

Há uma exigência que costuma passar batida: a organização deve informar ao cliente em que circunstâncias usa criptografia para proteger os dados pessoais que trata. Além de cumprir o requisito, isso responde a uma preocupação legítima de quem confia dados a você.

Como o auditor verifica esse controle

O auditor pede a política criptográfica, a gestão de chaves, quais chaves e tamanhos são usados, quais equipamentos estão cobertos — e as evidências constatadas. Depois, ele faz entrevistas.

É nesse ponto que a implementação parcial aparece. Dois erros clássicos:

  • Cobertura incompleta. Se o escopo é a empresa como um todo e a política diz que todos os notebooks têm criptografia de disco, não basta evidenciar cinco máquinas. O auditor vai ao inventário de TI, escolhe uma máquina aleatória e pede para ver. Precisa ter controle interno de verificação, não só metodologia.
  • Política que omite. Documento tecnicamente impecável, mas sem registrar onde a criptografia é usada, com quais ferramentas e em quais situações — especialmente nas conexões com clientes. Omitir não protege: o auditor pergunta a quem executa, e se a resposta divergir do documento, a não conformidade aparece.

A lição prática: quem executa tecnicamente precisa participar da construção do documento. O interlocutor da implementação não precisa ter conhecimento técnico profundo, mas tem de trazer para perto a pessoa de infraestrutura que realmente opera o controle.

Vale dizer: criptografia raramente gera não conformidade. É um controle direto, e o time de TI normalmente já domina a parte técnica. O que se complementa na implementação é justamente o mapeamento e a evidência.

Criptografia na avaliação de fornecedores

O controle criptográfico também deve entrar no questionário de avaliação de fornecedores, na contratação e nas reavaliações periódicas. Fornecedores grandes normalmente já chegam com todo o parâmetro de segurança documentado e comprovável. O risco concentra-se nos fornecedores pequenos — e é ali que a pergunta precisa ser feita.

O movimento é de mão dupla: a exigência de framework e normativo de segurança por parte de clientes vem crescendo, e essa cobrança tende a se intensificar.

Por que isso vale além do certificado

Muita empresa chega à ISO 27001 por pressão de mercado — uma RFP, a exigência de um cliente grande. Legítimo. Mas o controle criptográfico bem implementado é, na prática, um argumento comercial: quando o cliente pergunta "como meus dados ficam seguros com vocês?", você mostra política, matriz, gestão de chaves e padrão internacional em vez de improvisar uma resposta.

E ele opera junto com outros controles. Sem criptografia, um ataque expõe a informação; sem backup e cópia de segurança, não há como recuperá-la. Os dois se sustentam.

Assista ao treinamento técnico completo

Este artigo foi produzido a partir do treinamento técnico gratuito conduzido por Jennifer Dantas:

Leia mais

Perguntas frequentes

Qual é o tamanho mínimo de chave criptográfica aceito na ISO 27001?
O mínimo recomendado é 128 bits. Chaves de 56 bits são consideradas obsoletas e não sustentam mais o padrão de segurança. Combinações que preservam o nível reconhecido internacionalmente são aceitas, como o 3DES com chave de 168 bits, ainda comum em VPN e nuvem. Para criptografia simétrica, o AES é a referência.
Qual controle do Anexo A trata de criptografia?
Na ISO/IEC 27001:2022 é o controle A.8.24 (Uso de criptografia). Na versão 2013 ele correspondia ao A.10.1, referência que ainda aparece em materiais antigos. A ISO/IEC 27701 reforça o tema na seção 6.7, com controles específicos para controladores (Anexo A) e operadores (Anexo B) de dados pessoais.
A matriz com os algoritmos usados pode ser divulgada internamente?
Não deve. A matriz criptográfica é informação classificada e precisa de controle de acesso restrito, seguindo a lógica de classificação e rotulagem da informação. Se uma máquina for comprometida, quanto menos o atacante souber sobre a metodologia, ferramentas e algoritmos usados, mais difícil será o ataque. Quando a política precisa circular mais amplamente, mantenha a matriz em documento complementar restrito.
Como trocar a pre-shared key de uma VPN com segurança?
Por voz, em ligação telefônica com o setor especializado do cliente — nunca por escrito ou por canal digital inseguro. Além de evitar vazamento, a troca por voz ajuda a confirmar a identidade de quem solicita. A mesma prática se aplica a certificados digitais. Após o fechamento da VPN, crie regra no firewall limitando o acesso ao túnel a um grupo de hosts ou rede determinada.
Por que a criptografia vira não conformidade se o time de TI já sabe fazer?
Porque a não conformidade quase nunca é técnica — é de cobertura e de evidência. Os dois erros mais comuns são a implementação parcial (evidenciar cinco máquinas quando a política afirma que todo o parque é criptografado, sendo que o auditor escolhe uma máquina aleatória no inventário de TI) e a política que não registra onde, com quais ferramentas e em quais situações a criptografia é usada. Como o auditor entrevista quem executa, divergência entre a prática e o documento aparece.

Pronto para certificar sua empresa?

Fale com um especialista da Templum e receba um diagnóstico gratuito — com garantia de 200%.

Falar com um especialista