Diagrama de mapeamento de dados GDPR: como mapear os fluxos de dados pessoais entre seus sistemas

Pergunte a uma equipe de privacidade onde ficam os dados pessoais e você vai receber uma planilha. Pergunte à engenharia e vai receber um diagrama de arquitetura que nunca menciona dados pessoais. Os dois estão incompletos: a planilha não mostra como os dados se movem, e o diagrama de arquitetura não diz o que se move nem por quê.

Um diagrama de mapeamento de dados GDPR é onde os dois se encontram. Este guia cobre o que um mapa de dados precisa registrar, um método para construí-lo e um mapa completo para um produto SaaS típico. Não é aconselhamento jurídico; quem decide bases legais, mecanismos de transferência e prazos de retenção é o responsável por privacidade ou o jurídico da sua empresa.

Mapa de dados e registro das atividades de tratamento

O artigo 30 do GDPR exige que cada controlador mantenha um registro das atividades de tratamento contendo:

• o nome e os contatos do controlador e, quando aplicável, do seu representante e do encarregado de proteção de dados;
• as finalidades do tratamento;
• as categorias de titulares e de dados pessoais;
• as categorias de destinatários, incluindo destinatários em países terceiros;
• as transferências para países terceiros e, em alguns casos, a documentação das salvaguardas;
• quando possível, os prazos para a eliminação;
• quando possível, uma descrição geral das medidas de segurança.

Os operadores mantêm um registro semelhante do tratamento que fazem para cada controlador. O artigo 30(5) isenta organizações com menos de 250 funcionários, mas só se o tratamento não for suscetível de gerar risco para os direitos das pessoas, for ocasional e não incluir categorias especiais de dados nem dados relativos a condenações penais. Uma empresa SaaS que trata dados de clientes todos os dias raramente se enquadra. Os legisladores da UE debateram elevar esse limite, então confira o texto em vigor antes de contar com ele.

O registro é uma tabela. O mapa de dados é a forma de descobrir o que entra nessa tabela e de conferir depois se continua verdadeiro.

O que registrar para cada fluxo

Um método que funciona

1. Faça o inventário dos sistemas. Comece pelo que você consegue listar: contas de nuvem, bancos de dados, ferramentas SaaS que aparecem no login único (SSO) e nos pagamentos a fornecedores feitos pelo financeiro. É ali que as ferramentas paralelas aparecem.
2. Siga uma jornada de usuário por vez. Cadastro, cobrança, uso diário do produto, um ticket de suporte, um e-mail de marketing. Desenhe onde os dados entram, onde são armazenados e para onde vão em seguida.
3. Pergunte aos responsáveis. Para cada sistema: quais campos, para quê, quem os recebe e por quanto tempo ficam.
4. Marque operadores e transferências. Anote onde cada fornecedor trata os dados, se há um contrato de tratamento de dados (DPA) assinado e qual salvaguarda cobre cada transferência para fora do EEE.
5. Adicione retenção e exclusão. Um armazenamento sem prazo de retenção já é um achado.
6. Revise com a equipe de privacidade e derive do mapa o registro do artigo 30.

Transferências para fora do EEE

O Capítulo V do GDPR, artigos 44 a 49, só permite transferências para países terceiros com base em certos fundamentos. Os mais comuns para uma empresa SaaS:

• Decisão de adequação. A Comissão Europeia lista os países cuja proteção considera adequada. Para os Estados Unidos, a decisão de julho de 2023 cobre as empresas que participam do Data Privacy Framework UE-EUA (DPF). O Tribunal Geral da UE a confirmou em setembro de 2025, e um recurso foi interposto no Tribunal de Justiça em outubro de 2025; por isso, verifique a situação dela antes de contar com ela.
• Cláusulas contratuais-padrão. As cláusulas contratuais-padrão (SCC) de 2021 da Comissão são a salvaguarda contratual usual quando não há decisão de adequação aplicável.
• Outras salvaguardas e derrogações, como regras corporativas vinculantes ou consentimento explícito, para casos mais restritos.

No mapa, uma transferência é uma aresta que sai da sua região, rotulada com o destino e a salvaguarda.

O exemplo completo: um produto SaaS B2B

O produto roda em uma região de nuvem na UE: um aplicativo web, um banco de dados PostgreSQL e um data warehouse de analytics. Cinco fornecedores recebem dados pessoais: envio de e-mail e pagamentos no EEE, e analytics de produto, uma central de suporte e um CRM nos Estados Unidos.

Como ler:

• Entrada. Os usuários dos clientes criam contas, pagam, usam o produto e escrevem para o suporte. Cada fluxo que sai do aplicativo web é rotulado com as categorias de dados que transporta.
• Seus sistemas, região da UE. O banco de dados do aplicativo guarda dados de conta e de workspace. O data warehouse recebe eventos de uso com IDs pseudonimizados, não nomes.
• Operadores no EEE. O envio de e-mail recebe nomes, endereços de e-mail e o conteúdo das mensagens; os pagamentos recebem contatos de cobrança e faturas. Não há transferência envolvida.
• Operadores nos EUA. Cada aresta que entra nesta moldura é uma transferência e traz sua salvaguarda: DPF para os fornecedores certificados no framework, SCC para o que não é.
• A legenda explica os rótulos e lista exemplos de prazos de retenção por armazenamento.

Convenções de desenho que ajudam

• Rotule as arestas com categorias de dados, não com tecnologias. “Nome, e-mail, conteúdo do ticket” ajuda quem revisa; “REST API” não.
• Desenhe uma fronteira em volta dos seus próprios sistemas e coloque os operadores do lado de fora, agrupados por região.
• Marque cada transferência com o destino e a salvaguarda.
• Destaque os dados de categorias especiais com uma única cor, sempre a mesma, e diga na legenda o que ela significa.
• Escreva a retenção em cada armazenamento. É o item que mais falta nos registros de tratamento.
• Mantenha finalidades e bases legais no registro, ao lado do diagrama. O diagrama mostra onde; o registro diz por quê.

Mantenha atualizado

Um mapa de dados fica desatualizado no dia em que alguém adiciona um fornecedor. Vincule as atualizações aos eventos que o alteram: entrada de novos fornecedores, novas funcionalidades que coletam dados novos e avaliações de impacto sobre a proteção de dados. Pelo artigo 35, o controlador precisa avaliar, antes de começar, o tratamento que possa resultar em alto risco, e o mapa é o ponto de partida natural dessa avaliação. Revise o mapa inteiro uma vez por ano e guarde a versão anterior. Diagramas de arquitetura que não envelhecem descreve um fluxo de trabalho exatamente para isso, e incorporar o diagrama ao vivo na wiki de privacidade mantém todo mundo na mesma versão.

Como o mapa ajuda com as solicitações dos titulares

Uma solicitação de acesso ou de eliminação precisa cobrir todos os lugares onde estão os dados de uma pessoa: o banco de dados do aplicativo, o data warehouse, os backups e cada operador. Com um mapa atualizado, responder vira um checklist em vez de uma busca. Os operadores são obrigados por contrato a ajudar com essas solicitações, e o mapa diz a quais deles perguntar.

Para uma visão de segurança dos mesmos fluxos, veja diagramas de fluxo de dados para modelagem de ameaças.

Monte no Archboard

1. Entre com Google ou GitHub e crie um diagrama.
2. Adicione uma Pessoa do pack Modelo C4 para o usuário do cliente.
3. Adicione uma Moldura do pack Básico para os seus sistemas na região da UE, com um Contêiner do pack Modelo C4 para o aplicativo web, um Postgres do pack Dados para o banco de dados do aplicativo e um Armazém de dados do pack Dados para analytics.
4. Adicione mais dois nós Moldura do pack Básico para os operadores, um para o EEE e outro para os EUA, com um nó Sistema externo do pack Modelo C4 para cada papel de fornecedor.
5. Rotule cada aresta com as categorias de dados que ela transporta e adicione a salvaguarda em cada aresta que entra na moldura dos EUA.
6. Adicione um bloco Markdown do pack Básico com a legenda e os prazos de retenção.

O exemplo usa 13 nós de diagrama e fica dentro do plano Free. O caso de uso de mapeamento de dados GDPR mostra outras formas de organizar um mapa.

Perguntas frequentes

O GDPR exige um mapa de dados? O GDPR exige o registro das atividades de tratamento do artigo 30, não um diagrama. A maioria das equipes percebe que não consegue montar nem manter um registro preciso sem antes mapear os fluxos.

Quem deve ser o dono do mapa de dados? Privacidade é dona do registro e das decisões nele; a engenharia é dona dos sistemas. Dê ao diagrama um dono de cada lado e revisem juntos.

O mapa deve mostrar cada tabela do banco de dados? Não. Mostre os armazenamentos e as categorias de dados que eles contêm. O detalhe de cada tabela pertence a um catálogo de dados.

Como mostro um fornecedor que é ao mesmo tempo operador e controlador? Desenhe-o uma vez e rotule o papel dele em cada fluxo. Alguns fornecedores, como os de pagamento, atuam como controladores em parte do tratamento que fazem; os contratos dizem em qual.

O diagrama pode substituir o registro do artigo 30? Não. O registro precisa conter informações específicas por escrito, incluindo finalidades e medidas de segurança. Use o diagrama para montar e conferir o registro.

Comece grátis — um assento, sem cartão de crédito.