Resposta rápida

O controle A.8.11 da ISO 27001:2022 exige técnicas para ocultar dados pessoais sem impedir o funcionamento dos sistemas. Mascaramento é reversível por quem tem autorização; anonimização é irreversível e retira o dado do escopo da LGPD; pseudonimização troca identificadores por códigos com chave de mapeamento. Use mascaramento estático para enviar bases a terceiros e dinâmico quando o nível de acesso define o que cada usuário vê — sempre com criptografia por trás. Dado real em ambiente de teste ou desenvolvimento gera não conformidade em auditoria; a exceção exige risco registrado, aval da alta direção e controles compensatórios. E atenção à integridade referencial: mascarar o CPF em uma tabela e deixá-lo íntegro em outra quebra o sistema e mantém o risco.

Existe um erro em segurança da informação que garante não conformidade em auditoria, quase sem exceção: usar dados reais em ambiente de teste ou desenvolvimento. O auditor pede para abrir a base, olha, e a NC sai. E o controle que evita isso é o mesmo que protege relatórios de RH, telas de atendimento e integrações com terceiros — o A.8.11 da ISO/IEC 27001:2022, mascaramento de dados.

Neste artigo, a consultora Jennifer Dantas, especialista em ISO 27001 e ISO 27701 na Templum, explica as técnicas de mascaramento, a diferença entre mascarar, anonimizar e pseudonimizar, e como decidir qual usar.

O que o controle 8.11 exige

O controle estabelece o uso de técnicas para ocultar dados pessoais, permitindo que sistemas e aplicações continuem funcionando sem expor a informação real a quem não precisa dela na forma completa. É fundamental para os dados sensíveis que aparecem no inventário: laudos, informação de PCD, CPF de menores, dados de saúde.

Três objetivos sustentam o controle:

  • Limitar exposição — o princípio do menor privilégio aplicado ao dado, não só ao sistema.
  • Confidencialidade — proteger a informação no armazenamento, no processamento e na visualização.
  • Conformidade com a LGPD — atender às exigências legais de proteção de dados pessoais e sensíveis.

Mascaramento, anonimização e pseudonimização não são sinônimos

A confusão entre os três é a origem de decisões erradas de arquitetura. A diferença está na reversibilidade:

  • Mascaramento — oculta parte do dado mantendo sua estrutura. O dado original permanece intacto no banco e pode ser recuperado por usuário autorizado. É reversível, sob controle.
  • Anonimização — processo irreversível. O dado perde permanentemente o vínculo com o titular e, pela LGPD, deixa de ser considerado dado pessoal. Não há chave, não há volta.
  • Pseudonimização — substitui identificadores diretos por códigos ou pseudônimos. Só quem tem a chave de mapeamento reconecta o pseudônimo à pessoa real. É a técnica menos usada das três, mas continua disponível.

Estático ou dinâmico?

O mascaramento estático cria uma cópia do banco já mascarada — ideal para enviar a terceiros ou a desenvolvedores externos. O dado mascarado permanece na cópia, e a complexidade técnica é menor. Quem invadir essa cópia não chega ao titular.

O mascaramento dinâmico mantém o dado real no banco e aplica a máscara apenas na visualização, conforme o nível de acesso do usuário. Dá muito mais flexibilidade e controle, mas quem tem acesso pode reverter — por isso ele precisa vir acompanhado de criptografia e de controle de acesso rigoroso.

Técnicas e casos de uso que aparecem no dia a dia

As duas técnicas mais comuns são a substituição (o valor real vira um fictício ou genérico — "João" passa a "usuário 1") e o mascaramento nulo (o campo é substituído por vazio, ou preserva apenas tamanho e tipo originais).

Onde isso se aplica na prática:

  • Testes e desenvolvimento — nunca usar dado real de cliente ou funcionário. Dado mascarado elimina o vazamento acidental durante o desenvolvimento.
  • Suporte e atendimento — o atendente vê apenas os últimos dígitos do CPF ou do cartão, o suficiente para confirmar identidade sem acessar o dado completo.
  • Relatórios e pesquisas — estatísticas de PCD, dependentes, pesquisa de clima ou de diversidade. Quem trabalha o dado precisa do número agregado, não do nome nem da condição de saúde de cada pessoa.

A pergunta que orienta a decisão é simples: aquela atividade precisa do dado, ou precisa do dado naquela forma? Se puder mascarar, mascare.

Duas regras de ouro na implementação

1. Menor privilégio, avaliado atividade por atividade

O RH precisa do CPF completo para a folha de pagamento; o TI, não. Ao fazer o mapeamento de dados, avalie cada atividade que toca dado pessoal e pergunte se ela exige a forma original. Essa análise é o que permite reduzir a superfície de exposição sem quebrar a operação.

2. Integridade referencial — onde os projetos quebram

Se você mascara o CPF do dependente em uma tabela, ele precisa continuar ligado ao CPF do titular em outra, ou o sistema quebra. E há um risco espelhado: se o mesmo dado vive em vários lugares e você mascarou só um, quem acessar os outros reconstrói a identidade do titular. Mapeie onde o dado está antes de mascarar.

Vale conferir as funções nativas do próprio banco — SQL Server e Oracle já oferecem recursos de mascaramento que muitas equipes não sabem que têm.

Como o auditor verifica — e onde a NC é praticamente certa

Se a organização desenvolve software, o auditor vai verificar se há dado real em ambiente de teste ou de desenvolvimento. Ele pede para abrir e olha a base. Encontrando dado real sem que a empresa tenha tratado isso como risco, a não conformidade é aplicada — a orientação normativa é clara.

Existe caminho para a exceção, mas ele é trabalhoso e precisa estar documentado. Quando um cliente específico exige base real por um motivo concreto, o tratamento correto é:

  • Registrar formalmente o risco
  • Levar à alta direção e documentar a avaliação
  • Tentar a negociação com o cliente, explicando o prejuízo potencial
  • Aplicar controles compensatórios e mantê-los evidenciados

Em muitos casos, quando o contrato foi assinado sem que ninguém tivesse olhado por esse ângulo, a conversa com o cliente reverte a exigência e o ambiente passa a usar dados mascarados.

Depois de implementar, teste por perfil: entre no ERP com um usuário que não deveria ver o dado íntegro e confirme que ele vê a máscara — e faça o inverso com quem precisa do dado completo. É essa verificação que transforma configuração em evidência.

Mascarar ou anonimizar? O caso de RH e saúde

Essa dúvida apareceu no treinamento, trazida por uma empresa de digitalização de documentos que atende saúde e RH: o cliente às vezes precisa recuperar o dado, o que a anonimização definitiva impede — mas o mascaramento reversível abre a porta para quem invadir o sistema.

A recomendação é mascaramento reversível combinado com criptografia. O dado mascarado também fica criptografado, e apenas quem detém a chave — uma pessoa determinada, pelo princípio do menor privilégio — consegue recuperá-lo. Assim, a recuperação legítima continua possível e o atacante encontra duas barreiras em vez de uma.

É o mesmo raciocínio de gestão de chaves criptográficas: mascaramento sozinho é meia solução.

O que se ganha

  • Dano mínimo em incidente — se o atacante chega apenas a dado mascarado, a informação não serve para fraude nem para vazamento útil.
  • Proteção contra erro humano — usuário sem privilégio adequado nunca vê o dado sensível, mesmo quando alguém errar na configuração de uma tela.
  • Redução de exposição a multa — as sanções da LGPD por vazamento são altas o bastante para inviabilizar empresas, e já inviabilizaram.

Por onde começar na sua empresa

  1. Revisar sistemas e identificar campos críticos em ERP e RH que hoje exibem dado sensível integralmente
  2. Cruzar com o mapeamento de dados: quais atividades realmente exigem a forma original
  3. Aplicar mascaramento no maior número possível de casos
  4. Testar por perfil de acesso e registrar a evidência
  5. Verificar integridade referencial e funcionalidade dos sistemas após a implementação

Assista ao treinamento técnico completo

Este artigo foi produzido a partir do treinamento técnico gratuito conduzido por Jennifer Dantas, com as dúvidas dos participantes respondidas ao vivo:

Leia mais

Perguntas frequentes

Qual a diferença entre mascaramento, anonimização e pseudonimização?
O mascaramento oculta parte do dado mantendo sua estrutura: o original permanece no banco e pode ser recuperado por usuário autorizado. A anonimização é irreversível — o dado perde o vínculo com o titular e, pela LGPD, deixa de ser dado pessoal. A pseudonimização substitui identificadores diretos por códigos, e apenas quem tem a chave de mapeamento reconecta o pseudônimo à pessoa real.
Posso usar dados reais em ambiente de teste ou desenvolvimento?
Não. A orientação normativa é clara e, quando o auditor encontra dado real em teste ou desenvolvimento sem tratamento de risco, aplica não conformidade. Se um cliente específico exigir base real, trate como exceção formal: registre o risco, leve à alta direção, tente negociar com o cliente e aplique controles compensatórios documentados.
Qual escolher: mascaramento estático ou dinâmico?
O estático cria uma cópia do banco já mascarada e é ideal para enviar a terceiros ou desenvolvedores externos, com menor complexidade técnica e sem possibilidade de reversão. O dinâmico mantém o dado real no banco e aplica a máscara na visualização conforme o nível de acesso, oferecendo mais flexibilidade — mas exige criptografia e controle de acesso rigoroso, porque quem tem permissão consegue reverter.
Para RH e saúde, é melhor anonimizar definitivamente?
Normalmente não, porque a anonimização impede a recuperação legítima que essas áreas costumam precisar. A recomendação é mascaramento reversível combinado com criptografia: o dado mascarado também fica criptografado e só quem detém a chave, uma pessoa determinada pelo princípio do menor privilégio, consegue recuperá-lo. O atacante passa a enfrentar duas barreiras.
O que é integridade referencial no mascaramento de dados?
É a garantia de que as relações entre tabelas continuem válidas depois de mascarar. Se você mascara o CPF do dependente em uma tabela, ele precisa seguir vinculado ao CPF do titular em outra, ou o sistema quebra. Há também o risco inverso: se o mesmo dado existe em vários lugares e apenas um foi mascarado, quem acessar os demais reconstrói a identidade do titular.

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