Mascaramento de dados na ISO 27001: o controle 8.11, a LGPD e o erro que gera não conformidade

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.

Quer isso avaliado na sua empresa?

Diagnóstico gratuito do seu SGSI: onde estão as lacunas de controle, antes de o auditor apontar.

Falar com a Olívia

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

• ISO 27001: o que é e como implementar a norma
• Controle criptográfico na ISO 27001: política, chaves e A.8.24
• Backup e cópia de segurança: o controle 8.13 na prática
• ISO 27701:2025: a norma de privacidade ficou independente
• Qual a relação da ISO 27001 com a ISO 27701?
• Tudo sobre a LGPD
• A LGPD e a segurança de dados