Prazo de conservação de dados pessoais no RGPD

Última atualização: 26 de agosto de 2026

O prazo de conservação de dados pessoais na União Europeia começa numa pergunta concreta: que registo é este e por que continua necessário? Não existe um número universal. Uma tabela útil combina finalidade, obrigação, gatilho e ação final, chegando às cópias reais sem apagar evidência sujeita a uma suspensão válida ¹.

Resposta rápida Defina o prazo de conservação de dados pessoais na União Europeia por categoria e finalidade, nunca por um número copiado. Confirme obrigações específicas, escolha um gatilho calculável, documente a justificação e execute eliminação ou anonimização em todos os sistemas. Use suspensões delimitadas para litígios, investigações ou pedidos, com proprietário e data de revisão.

Comece pelo registo, não por um número preferido

Uma política que diz «guardar durante o necessário» repete o princípio, mas não permite eliminar nada; uma que diz «guardar tudo durante seis anos» transforma uma condição específica num atalho. Comece com o objeto de informação, a finalidade atual e a pessoa responsável pela decisão ².

Separe finalidades que partilham um ficheiro. Uma fatura pode sustentar contabilidade, enquanto o endereço de e-mail copiado para marketing serve outro objetivo; a obrigação relativa ao documento financeiro não prolonga automaticamente o uso promocional. Sistemas devem conseguir restringir ou eliminar campos por ramo quando a finalidade termina.

Pergunte que decisão falharia sem o registo. Se ninguém consegue dar um exemplo atual, a conservação pode estar a proteger hábito, não necessidade. Quando existe uma razão real, registe a evidência e escolha um período que corresponda ao ciclo do processo, evitando uma duração redonda sem ligação ao risco ou à obrigação.

O proprietário do sistema não deve aprovar sozinho a própria conveniência. Privacidade, finanças, pessoas, segurança e jurídico contribuem conforme a categoria, mas uma pessoa nomeada decide e assume a revisão. Sem proprietário, exceções acumulam-se e a data final torna-se apenas decorativa.

O direito aplicável fornece períodos específicos

O RGPD estabelece o princípio comum, mas não substitui os prazos nacionais que sustentam finalidades concretas. Obrigações fiscais, societárias, laborais, de folha salarial e setoriais devem ser verificadas no direito do Estado-Membro relevante para a entidade, a pessoa e o registo. Não importe números de outro país nem transforme um período verdadeiro para um documento numa regra para todo o sistema ^1,2.

Guarde a fonte oficial, a versão, o artigo ou página, a data da consulta e a interpretação junto da regra. Um nome curto como «fiscal» não chega: entidades e categorias diferentes podem usar gatilhos diferentes. A tabela operacional deve obrigar quem seleciona o prazo a escolher o conjunto exato e a condição capaz de alterar o cálculo.

Quando uma obrigação muda, preserve o cálculo anterior, a nova regra e a razão da transição. Uma inspeção, litígio ou declaração corrigida não deve ficar numa nota que o motor de eliminação nunca lê; ligue o evento ao registo, limite a suspensão ao material relevante e documente quem a pode libertar.

A ausência de um prazo legal não autoriza conservação indefinida. Contratos, candidaturas, apoio, controlo de acessos e marketing precisam de uma decisão baseada em finalidade, necessidade, expectativas, risco e alternativas menos intrusivas. Onde a organização escolhe a duração, o registo deve explicar por que um período menor não permitiria concluir a finalidade.

A lógica de decisão da União Europeia e a do Reino Unido atual é materialmente equivalente: nenhuma oferece um prazo universal e ambas exigem finalidade, gatilho e ação final. O que muda é o direito doméstico que fornece períodos de apoio. Esta equivalência não autoriza transportar para a União Europeia números fiscais, laborais ou societários britânicos.

Construa a tabela como ferramenta de operação

Uma tabela de retenção deve ser suficientemente precisa para que engenharia configure uma regra e atendimento explique uma decisão. Categorias largas como «dados de cliente» ou «RH» misturam gatilhos, pessoas e ações incompatíveis, tornando impossível provar o que desapareceu.

Para cada registo, defina primeiro a categoria e a finalidade e verifique a fonte da necessidade ². Depois fixe um gatilho calculável, o período, as exceções controladas e a ação final. Execute essa ação em todas as cópias reais e verifique o resultado.

Acrescente uma regra de conflito. Se duas finalidades exigem durações diferentes, não escolha automaticamente a maior para todos os campos; retenha apenas o subconjunto necessário para a finalidade remanescente, restrinja o uso anterior e execute a ação final quando o último ramo termina.

Defina estados compreensíveis: ativo, gatilho ocorrido, em período, suspenso, pronto para ação, concluído e falha. Um painel que mostra apenas data de criação não distingue cliente atual, conta encerrada e dossiê sujeito a retenção jurídica. A transição de estado precisa de evento, hora e proprietário.

Ligue a tabela a alterações de produto. Novo campo, exportação, fornecedor ou ambiente de teste deve indicar categoria e regra antes de receber dados. Se a equipa não encontra correspondência, abre uma decisão; não herda silenciosamente o prazo do sistema que ficou mais próximo.

Controle a granularidade com exemplos negativos. «Correspondência com clientes» não informa se inclui contrato, gravação, mensagens e resultado; «ficheiro de trabalhador» não distingue remuneração, desempenho, ausência e controlo de acesso. Divida até cada ramo possuir uma finalidade, um gatilho e uma ação final comuns, mas evite criar categorias por cada campo quando o tratamento é realmente igual.

Publique a tabela num formato que pessoas e sistemas consigam consumir. A versão legível explica escolhas e exceções, enquanto a configuração técnica traduz identificador de categoria, evento e ação sem copiar texto livre; ambas devem partilhar número de versão, aprovador e data de entrada em vigor, para que uma mudança editorial não fique desligada do motor.

Inclua dependências. Se um dossiê precisa da data de encerramento enviada pelo CRM, nomeie sistema de origem, validação e comportamento quando o evento falta; se uma suspensão chega de jurídico, indique canal autenticado e confirmação. Esta coluna torna visível onde uma regra correta falha por falta de dados.

Um calendário trabalhado separa um cliente em ramos

Considere um cliente que encerra a conta. O motor regista um único evento, mas abre ramos distintos: o perfil operacional deixa de suportar o serviço, a lista promocional deve refletir imediatamente o fim da permissão aplicável, os documentos contabilísticos recebem apenas a regra fiscal correspondente à entidade, e uma reclamação aberta suspende somente mensagens, decisões e transações capazes de provar o caso.

O sistema não deve copiar o dossiê inteiro para o ramo mais longo. Identifique campos e documentos necessários para cada finalidade, restrinja acesso e impeça reutilização. O endereço necessário numa fatura não autoriza manter a mesma morada numa lista de segmentação, e a prova de oposição não precisa de conservar todo o histórico comercial.

Registe o evento de fecho, a última transação pertinente, o conjunto fiscal aplicável, o identificador da reclamação e a ação final por sistema. Quando a reclamação termina, a suspensão liberta o material para a regra que já estava a correr, em vez de reiniciar o relógio; se o cliente regressar, uma nova relação operacional não deve reativar dados eliminados só porque existe um documento fiscal restrito.

Teste o exemplo com pessoas de suporte e finanças. Cada uma deve explicar o que continua acessível, para quem e porquê; se a resposta depende de conhecer pastas secretas ou exportações manuais, o calendário ainda não representa a realidade.

Faça depois o percurso inverso. Partindo de uma fatura restrita, verifique se alguém ainda consegue reconstruir preferências comerciais ou abrir o perfil completo por uma ligação antiga; partindo da reclamação, confirme que a suspensão não bloqueou relatórios agregados sem relação com o caso. O teste mostra se a separação existe nos acessos e não apenas na tabela.

Documente o resultado em linguagem que atendimento possa usar: que dados terminaram, que subconjunto permanece, qual finalidade o sustenta e que evento libertará uma exceção. Esta explicação reduz respostas contraditórias e permite corrigir uma categoria quando a realidade de um cliente difere do caso padrão.

A eliminação tem de chegar às cópias reais

O evento final não é uma linha numa folha de cálculo. Mapeie aplicação, base analítica, armazenamento de documentos, correio, dispositivos, exportações, fornecedores, testes e cópias de segurança. Para cada camada, defina o método, a latência operacional, a prova e o tratamento de falhas.

Anonimização só encerra a retenção de dados pessoais quando o resultado não permite reidentificação razoável. Remover nome enquanto conserva identificador estável, localização rara e tabela de correspondência separada pode deixar a pessoa identificável. Documente técnica, atacantes razoáveis, acesso a dados auxiliares e teste de reversibilidade.

As cópias de segurança exigem desenho próprio. Quando eliminação imediata de cada cópia não é operacional, impeça uso corrente, limite acesso, deixe a cópia expirar segundo o ciclo aprovado e garanta que uma restauração reaplica as eliminações entretanto vencidas. Restaurar uma base antiga não deve ressuscitar contas encerradas.

Exija evidência do fornecedor. «Apagado» pode significar oculto ao utilizador, marcado para fila, removido do serviço ativo ou destruído em todas as réplicas; o contrato e o teste devem esclarecer o estado, os subcontratantes e como uma falha é comunicada.

Trate ficheiros derivados como dados, não como resíduos técnicos. Relatórios descarregados, anexos enviados para aprovação, índices de pesquisa e tabelas de aprendizagem podem conservar o conteúdo depois de a linha principal desaparecer; atribua-lhes a categoria de origem, reduza a criação desnecessária e faça a ação final propagar-se pelo identificador apropriado.

Desenhe uma fila de falhas que não perca o contexto. Cada erro deve guardar registo afetado, regra, sistema, tentativa, causa e proprietário, com alerta capaz de distinguir indisponibilidade temporária de uma incompatibilidade permanente. Repetir silenciosamente não resolve um fornecedor que deixou de reconhecer o identificador, enquanto marcar sucesso ocultaria dados ainda presentes.

Faça uma verificação humana por amostra. Abra o perfil como utilizador autorizado, procure pelo identificador em exportações e peça ao fornecedor a prova definida; esta combinação deteta interfaces que escondem dados sem os remover e logs que confirmam apenas que um comando foi enviado, não que a ação terminou.

As suspensões são exceções com prazo de revisão

Uma suspensão impede temporariamente a ação normal para preservar informação relevante a litígio, investigação, reclamação ou outro processo concreto. Não cria uma nova finalidade ampla nem autoriza copiar todo o sistema. Delimite pessoas, categorias, assunto e custodiantes, e restrinja o uso ao motivo registado.

Cada suspensão precisa de proprietário, data de início, âmbito, razão, aprovador e evento de libertação. Reveja enquanto permanece ativa e, quando termina, retome a regra original a partir do ponto correto; não atribua um novo período completo só porque os dados estiveram suspensos.

Avise quem executa eliminações sem divulgar mais do que o necessário. Se a suspensão depende de uma pessoa lembrar uma pasta meses depois, falhará; se bloqueia a base inteira sem necessidade, conserva dados excessivos. O controlo deve ser granular, testável e visível no estado do registo.

Teste conflitos entre duas suspensões e o calendário normal. O sistema precisa de mostrar qual matéria protege cada subconjunto, libertar uma sem apagar o que a outra ainda cobre e executar a regra vencida logo que desaparece a última razão. Uma única caixa «hold» não consegue representar esta sobreposição nem explicar o acesso autorizado.

Revogue acessos concedidos para a exceção quando ela termina. A conservação limitada não justifica que toda a equipa continue a pesquisar o material, e a libertação deve gerar uma revisão de permissões, cópias de trabalho e exportações produzidas durante o caso, antes de retomar a ação final.

Torne o gatilho calculável

«Após o fim da relação» parece claro até existir conta inativa, contrato renovável, dívida pendente e último contacto em datas diferentes. Defina o evento que o sistema consegue observar, a fonte autorizada e a regra para correções retroativas. Um gatilho sem dado confiável é apenas uma intenção editorial.

Prefira eventos de negócio: encerramento confirmado, fim do exercício financeiro pertinente, entrega de declaração, fim do ano fiscal ou conclusão documentada de um caso. Data de criação pode ser inadequada quando o registo continua ativo, enquanto «último uso» pode prolongar-se por tarefas automáticas que nada dizem sobre necessidade humana.

Teste extremos. Que acontece se o cliente nunca conclui o registo, se reabre a conta, se uma obrigação nacional muda, se começa uma inspeção ou se o fornecedor não envia o evento? Para cada ramo, defina estado, responsável e fila de exceção; não transforme erro de integração em conservação infinita.

Mantenha o relógio legível. O registo deve mostrar evento, data, regra aplicada, data prevista, suspensão e ação final. Se duas equipas calculam datas diferentes a partir da mesma informação, a descrição do gatilho ainda contém uma ambiguidade.

Valide a implementação com uma amostra conhecida. Crie registos de teste em estados diferentes, execute a regra e compare campos, derivados, logs e mensagens. O resultado precisa de provar tanto a ação correta como a preservação do subconjunto que ainda possui justificação.

Quando o período é decidido pela empresa, registe o raciocínio: ciclo de serviço, frequência de reclamações, necessidade de suporte, expectativas da pessoa, risco e alternativas menos intrusivas. A decisão não fica legal só porque a ferramenta exige um número; deve explicar por que um intervalo menor não permitiria cumprir a finalidade.

Defina um dicionário de eventos partilhado. «Encerrado» pode significar pedido do cliente, fim de faturação, revogação técnica ou conclusão do último serviço; escolha o evento que corresponde à finalidade e impeça equipas de reutilizarem o mesmo nome para estados diferentes. A documentação deve incluir exemplo positivo, contraexemplo e campo de origem.

Considere eventos que chegam fora de ordem. Uma correção contabilística pode alterar o exercício pertinente, uma sincronização atrasada pode informar encerramento depois de o período já ter começado e um caso pode reabrir legitimamente; o motor conserva a cronologia, recalcula com regra versionada e encaminha mudanças que apagariam dados antes de uma revisão humana necessária.

Meça cobertura, não apenas execução. Compare todas as categorias do inventário com as regras publicadas, depois todos os registos com um gatilho válido; uma taxa elevada de eliminações pode coexistir com uma população antiga que nunca recebeu categoria. A fila «sem regra» deve ter proprietário e decisão, não um valor padrão indefinido.

Evite que atividade automática adie o fim. Uma rotina de segurança, sincronização ou mensagem do sistema pode atualizar «último acesso» sem demonstrar que a finalidade continua; se esse campo controla o prazo, separe ação humana significativa de eventos técnicos, preserve ambos nos logs e baseie o gatilho na definição aprovada.

Para mudanças de regra, decida o tratamento do stock. Aplicar apenas a novos registos deixa o histórico sob uma política abandonada, enquanto recalcular tudo sem teste pode antecipar ações inesperadas; execute uma simulação, conte efeitos por categoria e exceção, aprove o plano e conserve o relatório antes de ativar a versão.

Os pedidos de direitos não apagam o calendário

Um pedido de apagamento abre uma decisão por dados e finalidade. Localize as categorias, confirme identidade de forma proporcionada, aplique as condições do direito e explique o resultado. Onde existe razão válida para conservar, restrinja utilizações incompatíveis e mantenha apenas o necessário; onde não existe, execute a eliminação sem esperar pelo calendário normal ¹.

Pedidos de acesso também interagem com retenção. Não elimine deliberadamente informação que integra um pedido aberto só porque o prazo automático vence, mas não suspenda todos os dados da pessoa sem delimitação. Preserve o conjunto relevante, registe a suspensão e liberte-o quando a resposta e qualquer questão associada terminarem.

Retificação deve chegar a cópias ativas e destinatários aplicáveis. Uma versão incorreta conservada por obrigação não precisa de continuar a orientar decisões; marque o estado, restrinja o uso e mantenha a correção associada para que o registo histórico não seja apresentado como verdade atual.

Conserve prova mínima de certas preferências ou ações quando necessária para respeitar a pessoa, sem transformar essa prova num perfil. Por exemplo, impedir novo contacto pode exigir um identificador limitado, mas não o histórico completo que originou a oposição. Documente finalidade, acesso e prazo da própria prova.

O atendimento precisa de ver o calendário em linguagem comum. Uma resposta que diz apenas «a política permite» não identifica categoria, gatilho, obrigação ou ação; forneça a razão concreta e uma via de revisão quando os factos da pessoa não correspondem ao registo.

Crie um mapa entre direitos e estados. Um registo ativo, vencido, suspenso ou já anonimizado exige passos diferentes, e o gestor do pedido deve conseguir ver a ação programada sem alterar manualmente a data. Se a resposta depende de um fornecedor, registe envio, confirmação, exceção apresentada e resultado por categoria.

Não use a existência de um pedido para renovar necessidade. O facto de a pessoa perguntar sobre um dado não cria, por si, uma nova finalidade de conservar todo o conteúdo; preserve apenas o material necessário para tratar e demonstrar a resposta, mantenha a regra restante e elimine cópias de trabalho quando o processo termina.

Quando a resposta é parcial, explique a fronteira. Um documento pode ser conservado sob obrigação verificada enquanto campos promocionais são apagados e um histórico de segurança é restringido; comunicar estes ramos mostra que a organização avaliou finalidades, em vez de aceitar ou recusar o pedido como bloco indivisível.

Teste o circuito com um pedido simulado que chega por suporte, não por formulário especializado. A equipa deve reconhecer o pedido, impedir uma eliminação conflitante apenas no âmbito necessário, localizar cópias, obter decisões e atualizar o calendário; depois, a revisão confirma que as suspensões foram libertadas e os ficheiros temporários desapareceram.

Reveja a tabela testando sistemas

A revisão anual não deve começar numa sala de reuniões, mas numa amostra de registos vencidos, ativos, suspensos e eliminados. Siga cada um do evento ao resultado, compare a tabela com o sistema e descubra onde exportações, fornecedores ou erros de fila escapam à ação.

Reconcilie contagens antes e depois. Uma queda total pode parecer sucesso enquanto categorias críticas ficaram intocadas; estratifique por sistema, regra, idade, estado e causa de falha. Investigue filas acumuladas e registos sem gatilho, porque estes nunca chegam ao painel de vencidos.

Entreviste equipas sobre desvios reais. Finanças pode guardar exportações locais, suporte pode copiar anexos para tickets e engenharia pode replicar produção em testes; atualize o mapa e elimine a prática ou aplique a regra. A política deve seguir dados reais, não apenas arquitetura aprovada.

Revise as fontes nacionais e as condições de cada período aplicado, sem supor que uma página antiga continua igual. Registe data da consulta e responsável pela alteração; se a autoridade muda, avalie registos existentes, configuração futura e informação às pessoas antes de atualizar o motor.

Feche achados com proprietário, prazo e prova de eficácia. Corrigir uma consulta não demonstra que a próxima execução funcionará; repita a amostra, teste uma restauração e confirme o fornecedor. O calendário está vivo quando produz eliminações explicáveis e exceções limitadas, não quando possui uma versão recente no cabeçalho.

Inclua registos que deveriam permanecer. Um teste composto apenas por itens vencidos pode premiar um processo que apaga demasiado; selecione categorias ativas, obrigações condicionadas e suspensões válidas, e confirme que o motor preserva exatamente o subconjunto necessário sem permitir uso alheio à finalidade.

Compare a interface com a base. Se atendimento vê «eliminado», descubra que estado técnico produz o rótulo, quando réplicas e índices acompanham a mudança e como uma restauração o respeita. A discrepância deve gerar incidente operacional e correção, não uma explicação permanente de que a palavra no ecrã significa outra coisa.

Peça ao proprietário que reproduza uma data sem consultar quem criou a regra. Ele deve encontrar categoria, evento, condição, versão e suspensão e chegar ao mesmo resultado; se precisa de interpretação oral, a lógica não está suficientemente definida para automação nem para explicar a uma pessoa.

Em Portugal, a Comissão Nacional de Proteção de Dados (CNPD) é o contacto nacional para questões de proteção de dados. A ligação serve como contacto do leitor; os prazos substantivos continuam a depender da fonte oficial adequada ao registo e ao setor, não desta página partilhada.

Use os achados para reduzir dados na origem. Categorias difíceis de eliminar costumam revelar exportações excessivas, integrações sem identificador ou finalidades misturadas; corrigir recolha, arquitetura e acessos evita que a próxima revisão encontre a mesma falha em volume maior. O melhor calendário não administra apenas o passado, mas muda a forma como novos dados entram.