Segurança de dados do cliente: 10 boas práticas

A segurança de dados do cliente (customer data security) é o conjunto de políticas, controles técnicos e processos que protege os dados pessoais de clientes contra acesso não autorizado, vazamento e uso fora da finalidade declarada, em todo o caminho que esses dados percorrem: coleta, armazenamento, tratamento, compartilhamento e eliminação.

No Brasil, essa proteção é obrigação legal, com autoridade fiscalizadora e valor de multa definidos em lei. A LGPD obriga controlador e operador a adotar medidas técnicas e administrativas de segurança (art. 46) e prevê multa de até 2% do faturamento da empresa no Brasil, limitada a R$ 50 milhões por infração, aplicada pela Autoridade Nacional de Proteção de Dados (ANPD). A sanção não é o único custo: o cliente que perde a confiança para de fornecer os dados primários (first-party data) que sustentam a personalização.

As dez práticas abaixo cobrem o que uma operação brasileira precisa ter implantado, da política de senha à comunicação de incidente à ANPD. A última seção trata do que muda quando os dados de cliente passam a viver em uma plataforma governada em vez de espalhados por dezenas de sistemas.

Por que os dados de cliente no Brasil exigem controles próprios

Três características da operação brasileira mudam o cálculo de risco: o CPF como chave de identidade, o WhatsApp como canal de relacionamento e a quantidade de fornecedores que recebem cópia dos dados pessoais.

O CPF não se troca. O CPF aparece no cadastro da loja on-line, na nota fiscal (o CPF na nota), no programa de fidelidade e no atendimento, e costuma ser a chave que a resolução de identidade (identity resolution) usa para unir esses registros. A mesma estabilidade que faz do CPF uma boa chave torna o vazamento de dados (data breach) irreversível para o cliente: senha se troca, cartão se cancela, CPF permanece a vida inteira. Um CPF exposto continua servindo para fraude de cadastro anos depois do incidente.

A conversa no WhatsApp guarda dados pessoais. O histórico de mensagens com o cliente guarda identificação, pedido, endereço e, muitas vezes, comprovante de pagamento. O provedor da API do WhatsApp Business trata esses dados em nome da empresa, na posição de operador prevista na LGPD, e por isso o contrato precisa fixar escopo de acesso, prazo de retenção e obrigação de avisar sobre incidente. O mesmo vale para a agência que recebe públicos exportados.

Cada fornecedor a jusante recebe uma cópia. Um stack montado com reverse ETL copia o perfil para cada ferramenta de destino a cada sincronização. Isso não significa que “os dados ficam no data warehouse”: a partir do primeiro envio existe uma cópia dos dados pessoais na plataforma de disparo de e-mail, outra na conta de mídia paga e outra no atendimento, cada uma com o próprio controle de acesso e o próprio histórico de falhas. Se os dados de fato não saíssem do data warehouse, não haveria nada para o destino ler.

As 10 boas práticas de segurança de dados do cliente

1. Senha forte e autenticação em dois fatores

A credencial é o primeiro controle e o mais fácil de contornar quando a política é frouxa. Uma política de senha aplicável em toda a empresa vale mais do que uma política severa que a equipe contorna com anotação em planilha.

Exija senha longa e única por sistema, com letras maiúsculas, números e símbolos.
Distribua um gerenciador de senhas à equipe, em vez de deixar cada pessoa resolver o problema sozinha.
Monitore os pedidos de redefinição de senha: um pico costuma ser o primeiro sinal de credencial vazada.
Revogue a credencial de quem sai da empresa no mesmo dia, e não no fechamento do mês.

O que a autenticação de dois fatores resolve

A autenticação de dois fatores (2FA) exige uma segunda prova além da senha: um código enviado ao celular, uma leitura biométrica ou um token físico. Com 2FA ativo, a senha descoberta em um golpe de phishing não basta para entrar na conta, porque falta o segundo fator. Nos sistemas que guardam dados de cliente, o segundo fator deve ser obrigatório, não uma opção que cada usuário ativa se quiser.

2. Rede e sistemas protegidos

A rede protegida é o que impede que um acesso indevido a um sistema periférico chegue à base de clientes.

Mantenha firewall entre a rede interna e a internet, com regra explícita para cada serviço exposto.
Atualize software e sistema operacional em cadência definida, porque a correção publicada pelo fabricante também informa ao atacante onde estava a falha.
Transmita dados de cadastro e de pagamento sempre sob TLS, inclusive entre sistemas internos.
Mantenha antivírus e monitoramento de endpoint atualizados nas máquinas que acessam o CRM e a plataforma de dados.

3. Criptografia dos dados sensíveis

A criptografia (encryption) transforma os dados em um texto que só a chave correta reverte, o que reduz o valor do que o atacante consegue levar. A LGPD não impõe uma técnica específica, então a escolha precisa estar documentada e ser revista com o tempo.

Use algoritmos consagrados, como o AES (Advanced Encryption Standard) para dados em repouso e o RSA ou curvas elípticas para troca de chaves.
Trate a gestão de chaves como controle separado: chave guardada no mesmo servidor dos dados criptografados não protege nada.
Criptografe em repouso e em trânsito, o que inclui banco de dados, backup, dispositivo portátil e integração entre sistemas.
Revise a configuração periodicamente; um algoritmo aceitável há cinco anos pode estar depreciado hoje.

4. Acesso restrito ao que cada função exige

O controle de acesso por papel (RBAC, role-based access control) limita cada pessoa ao conjunto de dados que o trabalho dela exige. É também o controle que transforma um incidente de credencial em um problema pequeno: quem entra com a conta de um analista de campanha não alcança a base inteira.

Defina papéis, não exceções. Exceção individual não sobrevive à rotatividade da equipe.
Monitore quem acessa o quê. A trilha de auditoria responde quem leu qual registro e quando, e é ela que delimita o alcance de um incidente.
Revise os acessos periodicamente. Promoção e mudança de área acumulam permissões que ninguém retira.
Exija autenticação multifator (MFA) no acesso administrativo às bases que guardam dados pessoais.
Mascare o que a função não precisa ver. O atendimento costuma resolver o chamado com os quatro últimos dígitos do CPF, sem ver o número inteiro.

A governança de dados (data governance) é o que mantém essas regras escritas, revisadas e aplicadas do mesmo jeito em todos os sistemas.

5. Backup regular e teste de restauração

O backup responde pela disponibilidade e pela integridade dos dados de cliente quando um incidente, uma falha de hardware ou um erro de operação apaga o que estava em produção.

Defina a frequência pelo volume e pela criticidade de cada base, não por um padrão único.
Mantenha uma cópia fora do ambiente principal, para que o mesmo incidente não alcance original e backup.
Teste a restauração com calendário fixo: backup nunca restaurado é hipótese, não plano.
Criptografe as cópias e controle quem pode lê-las.
Monitore as rotinas e trate falha de backup como incidente, não como aviso de rotina.

O backup também cria uma obrigação. O pedido de eliminação dos dados previsto no art. 18 da LGPD precisa alcançar as cópias, ou ao menos ter prazo documentado para que a retenção expire e o registro desapareça sozinho.

6. Treinamento da equipe e orientação ao cliente

Os controles acima dependem, no fim, de uma decisão que alguém toma em segundos diante de uma mensagem que parece legítima.

Mantenha um programa de treinamento sobre phishing, engenharia social e higiene de credencial, com atualização periódica.
Abra um canal simples para relatar suspeita, sem punição para quem relata o próprio erro. Quanto mais tarde o incidente aparece, maior o número de titulares atingidos e menor o tempo que resta para comunicar à ANPD.
Diga ao cliente quais dados a empresa nunca pede por WhatsApp, SMS ou telefone. O golpe que se passa pelo atendimento da marca depende de o cliente não saber onde está a fronteira.
Comunique mudanças de política em linguagem direta, e não em aviso jurídico de dez parágrafos.

7. Coleta mínima e prazo de retenção definido

Os dados que a empresa não coleta não vazam, e a LGPD já pede essa disciplina: o art. 6º, III limita o tratamento ao mínimo necessário para a finalidade declarada. O art. 16 exige a eliminação dos dados quando o tratamento termina, salvo as hipóteses de guarda previstas na lei.

Revise cada formulário de cadastro e remova o campo que ninguém usa.
Defina prazo de retenção por categoria de dados e registre a justificativa de cada prazo.
Elimine ou anonimize ao fim do prazo, com rotina automática em vez de pedido manual.
Verifique se a eliminação alcança os sistemas a jusante que receberam cópia do perfil.

8. Mascaramento e pseudonimização fora da produção

O mascaramento de dados (data masking) substitui o valor real por um valor fictício que preserva o formato, e é o que permite testar, treinar e analisar sem expor a base real. Um ambiente de homologação com cópia da produção guarda os mesmos dados pessoais do sistema principal, e costuma ter controle de acesso mais frouxo que ele.

A pseudonimização separa o identificador direto do resto do registro e guarda a chave de reversão à parte, sob controle próprio. A anonimização vai além: quando a reversão deixa de ser possível por meios razoáveis, os dados anonimizados saem do alcance da LGPD (art. 12). A diferença importa na prática, porque um conjunto “anonimizado” que volta a identificar o cliente ao ser cruzado com outra base continua sendo dados pessoais.

9. Plano de resposta a incidente com comunicação à ANPD

O art. 48 da LGPD obriga o controlador a comunicar à ANPD e ao titular o incidente de segurança que possa acarretar risco ou dano relevante. O prazo e o conteúdo dessa comunicação seguem a regulamentação editada pela ANPD, e quem decide sobre a relevância é a empresa que coletou os dados, não o fornecedor onde o incidente aconteceu.

Defina antes quem lidera a resposta, quem fala com a ANPD e quem fala com o cliente.
Registre a linha do tempo: o que foi acessado, quando, por quem e quais titulares foram atingidos.
Faça uma simulação por ano, com o time de dados, o jurídico e a comunicação na mesma sala.
Publique o contato do encarregado de dados (DPO), como exige o art. 41 da LGPD, e mantenha esse canal atendido.

10. Governança dos fornecedores que tratam dados em seu nome

Todo fornecedor que recebe dados de cliente estende a superfície de exposição da empresa, e a LGPD trata essa relação explicitamente. O operador atua conforme as instruções do controlador (art. 39) e responde quando descumpre a lei ou foge dessas instruções (art. 42), mas quem coletou os dados continua respondendo perante o cliente.

Peça a lista de subprocessadores e o compromisso de avisar antes de mudá-la.
Verifique o mecanismo de transferência internacional quando os dados saem do Brasil (art. 33).
Trate certificações como SOC 2 Tipo II e ISO/IEC 27001 como evidência de processo, não como substituto da sua própria avaliação.
Exija prazo contratual de aviso de incidente compatível com o prazo que a sua empresa tem perante a ANPD.

Erros comuns na segurança de dados do cliente

A maior parte dos incidentes com dados de cliente não vem de ataque inédito: vem de controle que existe no papel e falha em um ponto específico. Uma cópia da base de produção parada em um ambiente de teste, um token de integração que ninguém trocou, uma revogação de consentimento que nunca chegou à plataforma de disparo de e-mail. A IBM e o Ponemon Institute calculam o custo médio global de um vazamento de dados em US$ 4,99 milhões e a média dos Estados Unidos em US$ 11,5 milhões (Cost of a Data Breach Report 2026). Os cinco erros abaixo são os pontos em que a política escrita e a prática diária se separam.

Dados de produção em ambiente de teste, de análise e de demonstração. As equipes de engenharia e de análise copiam a base real de clientes porque montar massa de teste realista leva mais tempo. Essas cópias raramente herdam o controle de acesso, o registro em log e a regra de retenção do sistema de origem. O que fazer: aplicar mascaramento de dados (em inglês) ou tokenização no momento da exportação, para que nenhum ambiente fora de produção guarde dados pessoais reais.
Coletar e guardar mais do que a empresa consegue defender. Cada atributo armazenado é um atributo para proteger, auditar e eliminar quando o titular pedir. A base cresce em silêncio: campo de formulário que nenhuma área usa, log de evento sem prazo de expurgo, exportação avulsa esquecida em pasta compartilhada. O que fazer: fixar prazo de retenção por tipo de dados, eliminar por rotina automática em vez de lembrete e parar de coletar campo que ninguém sabe justificar.
Tratar o consentimento como configuração de marketing, e não como controle de acesso. A revogação registrada em um sistema não vale nada quando a ferramenta a jusante que guarda o mesmo perfil nunca é avisada. É assim que uma empresa dispara e-mail para quem revogou a permissão meses antes, o que é falha de segurança além de falha de conformidade. O que fazer: aplicar a gestão de consentimento no momento da ativação, e não apenas no momento da coleta.
Revisar o acesso das pessoas e ignorar o acesso das máquinas. A revisão periódica de acessos cobre usuários nomeados. As contas de serviço, as chaves de API e os tokens OAuth que conectam o data warehouse, a CDP, a plataforma de disparo de e-mail e as contas de mídia costumam sobreviver aos projetos que os criaram, com permissão mais ampla do que alguém concederia a uma pessoa. O que fazer: inventariar cada credencial de integração, limitar cada uma ao mínimo de dados de que ela precisa e trocá-la em calendário fixo.
Um plano de resposta a incidente que ninguém ensaiou. O art. 33 do GDPR dá 72 horas para notificar a autoridade supervisora depois que a empresa toma conhecimento do vazamento de dados pessoais, e a empresa brasileira que trata dados de clientes na Europa fica sujeita a esse prazo além do que a ANPD exige. Boa parte dessas 72 horas se perde enquanto as equipes descobrem quais sistemas guardavam os registros atingidos e quem está autorizado a falar. O que fazer: uma simulação por ano, com base em um mapa atualizado de onde os dados de cliente vivem e com responsáveis nomeados para falar com o regulador, com o cliente e com a direção.

Como uma CDP muda a superfície de exposição

Uma plataforma de dados do cliente (customer data platform) concentra os dados de cliente em um sistema governado, o que reduz o número de cópias espalhadas e, ao mesmo tempo, aumenta o que está em jogo nesse sistema. As duas metades dessa frase valem juntas. Quem lê só a primeira trata a CDP como redução de risco e ignora que a base unificada passa a concentrar o que antes estava disperso.

O que melhora com a consolidação é mensurável em número de lugares a proteger. Em vez de dezenas de bases isoladas, cada uma com o próprio controle de acesso, a empresa aplica uma política só: criptografia em repouso e em trânsito, controle de acesso por campo, trilha de auditoria de quem leu qual perfil e um caminho único de eliminação que propaga o pedido do titular aos destinos. A gestão de consentimento entra no mesmo ponto: quando a decisão do cliente vive no perfil, ela vale para todas as ativações, e não apenas para o canal onde foi registrada.

A redução de cópias, porém, depende de os sistemas de origem entregarem as suas. Quando a CDP entra e a base de marketing, a extração para análise e as planilhas de cada área continuam no lugar, a plataforma passa a ser mais uma cópia ao lado delas, e não a substituta de nenhuma. Desativar os sistemas que a CDP consolida faz parte do ganho de segurança, não é uma limpeza para agendar depois.

A segunda variável é a ativação, e ela empurra na direção contrária. Cada sincronização de perfis para uma plataforma de disparo de e-mail, uma conta de mídia paga ou uma ferramenta de atendimento cria mais um contrato de operador, mais um escopo de auditoria e mais um caminho de comunicação de incidente. A sincronização nativa e o reverse ETL produzem essas cópias por arquitetura, e é por isso que a contagem de cópias entra na avaliação ao lado das certificações do fornecedor: a certificação diz como cada cópia é protegida, não quantas cópias existem. O guia de arquitetura de CDP para CISOs (em inglês) detalha como avaliar esse trade-off.

O que exige atenção é a concentração em si. Uma base unificada é um alvo de valor maior, então o acesso administrativo a ela pede MFA, segregação de ambientes e revisão de permissões em cadência mais curta que a do resto do stack. Na avaliação de fornecedores, o Adobe Real-Time CDP e o Salesforce Data Cloud embutem controle de acesso por campo e gestão de consentimento nas suas suítes; a Treasure AI (antiga Treasure Data) coloca essas políticas na própria camada de dados e mantém a certificação SOC 2 Tipo II. Em qualquer um dos casos, peça a demonstração do fluxo de eliminação ponta a ponta antes de assinar, e não depois de migrar a base.

Avaliar uma plataforma pela segurança, e não pela lista de funcionalidades, se resume aos controles administrativos que ela entrega:

Granularidade do acesso. A permissão precisa ser definível por atributo e por público, para que a equipe de campanha trabalhe com identificador mascarado ou com hash em vez dos dados de contato brutos.
Trilha de auditoria exportável. Quem consultou qual perfil, por quanto tempo esse histórico fica guardado e se ele pode ser enviado ao sistema de monitoramento de segurança (SIEM) da própria empresa, em vez de viver apenas no console do fornecedor.
Custódia das chaves. Criptografia em repouso e em trânsito é requisito básico; a pergunta é quem guarda as chaves e se a plataforma aceita chave gerenciada pelo cliente.
Eliminação que propaga. O pedido de eliminação atendido dentro da CDP e não nos destinos que ela alimenta não foi atendido.
Residência e compartilhamento da infraestrutura. Em quais regiões os dados podem ser fixados, e se armazenamento e processamento ficam compartilhados com outros clientes na arquitetura multi-inquilino (multi-tenant).
Integração com a identidade corporativa. Autenticação única (SSO) e desprovisionamento automático (SCIM), para que revogar uma conta retire o acesso em todos os sistemas: é o que torna aplicável a revogação no mesmo dia da primeira prática.

O que uma CDP não resolve é a camada humana e o dispositivo de quem trabalha com os dados. Phishing, senha reaproveitada, notebook comprometido e analista que exporta um segmento para uma planilha continuam exatamente tão arriscados quanto o treinamento e o controle de endpoint da empresa permitirem. A plataforma serve como sistema de registro que delimita onde os dados de cliente podem viver; as dez práticas acima continuam valendo para tudo que está fora dela.

Para levar essas perguntas a todos os fornecedores nos mesmos termos, a Treasure Data publica um modelo de RFP para CDP (em inglês) com as capacidades a considerar e as perguntas a fazer a cada fornecedor.

FAQ

O que é segurança de dados do cliente?

A segurança de dados do cliente é o conjunto de políticas, controles técnicos e processos que protege as informações de clientes contra acesso não autorizado, vazamento e uso indevido. A segurança de dados do cliente abrange criptografia, controle de acesso por papel, mascaramento de dados, backup, treinamento da equipe e conformidade com leis como a LGPD, o GDPR e a CCPA. No Brasil, quem fiscaliza essas obrigações é a ANPD.

Quais são as causas mais comuns de vazamento de dados de cliente?

As causas mais frequentes são o phishing que captura a credencial de um funcionário, a senha fraca ou reaproveitada, o armazenamento em nuvem mal configurado, o software sem atualização e o uso indevido por quem tem acesso legítimo. Boa parte dos casos combina erro humano com controle insuficiente, e não invasão sofisticada, o que explica por que treinamento e revisão de permissões rendem tanto quanto ferramenta nova.

Como uma CDP ajuda a proteger os dados do cliente?

A CDP centraliza os dados de cliente em uma plataforma governada, com criptografia em repouso e em trânsito, controle de acesso por papel, mascaramento e trilha de auditoria. Ao reunir em um sistema o que antes vivia em dezenas de bases isoladas, a CDP reduz o número de cópias dos dados pessoais e aplica a mesma política de segurança e de consentimento em todas as ativações. Em troca, a base unificada exige controle administrativo mais rígido.

O que a LGPD exige em segurança da informação?

O art. 46 da LGPD obriga controlador e operador a adotar medidas de segurança, técnicas e administrativas, aptas a proteger os dados pessoais de acesso não autorizado e de perda, alteração ou difusão acidental ou ilícita. A LGPD não impõe uma tecnologia específica, então cabe à empresa documentar as medidas escolhidas, revisá-las e demonstrá-las quando a ANPD pedir.

Quem deve comunicar um vazamento de dados à ANPD?

O controlador comunica o incidente de segurança à ANPD e ao titular quando o incidente puder acarretar risco ou dano relevante, conforme o art. 48 da LGPD. O operador que detecta o problema comunica ao controlador, que decide sobre a comunicação externa e responde por ela. O prazo e o conteúdo dessa comunicação seguem a regulamentação editada pela ANPD.

Este artigo também está disponível em: Customer Data Security: 6 Best Practices for 2026