Ir para o conteúdo
Legiscope
Menu
Proteção de dados

Direito de retificação: corrigir dados e avisar destinatários

Tratamento de pedido individual com verificação e propagação. Método de aplicação, exemplos preenchidos e critérios de verificação.

Também disponível em:Italiano·Svenska·Lietuvių·Dansk·Suomi·Norsk

Um pedido de retificação exige corrigir a informação relevante e impedir que o erro continue a produzir efeitos. Alterar a morada na ficha visível ao cliente pode deixar intacta a lista de entregas, uma exportação ou um perfil calculado a partir dos dados antigos. O procedimento deve localizar o erro, decidir a correção e acompanhar a comunicação aos destinatários pertinentes.

Este guia organiza a resposta ao artigo 16.º com uma ficha preenchida e verificações práticas. A revisão preventiva de qualidade dos dados continua a ser necessária; aqui o ponto de partida é uma pessoa que identifica informação inexata ou incompleta e pede que seja tratada.

Distinguir retificação, complemento e apagamento

O artigo 16.º do RGPD prevê a retificação sem demora injustificada de dados inexatos e o complemento de dados incompletos, considerando as finalidades, incluindo mediante declaração adicional. O artigo 19.º prevê comunicação da retificação aos destinatários, salvo impossibilidade ou esforço desproporcionado, e informação sobre esses destinatários ao titular quando este a pedir.

A CNPD apresenta o direito de retificação como uma forma de corrigir ou completar informação. O apagamento responde a condições diferentes. Uma pessoa pode pedir ambas as coisas, mas a equipa deve identificar que decisão corresponde a cada conjunto de dados.

Um registo histórico pode descrever corretamente um estado passado e ser inadequado como informação atual. A antiga morada numa entrega concluída não tem necessariamente o mesmo tratamento que a morada usada para a próxima encomenda. Explique a finalidade de cada registo antes de decidir substituir, completar, restringir ou conservar a referência histórica.

Receber o pedido e delimitar o erro

Reconheça mensagens em linguagem corrente: «a data está errada», «essa dívida não é minha» ou «mudámos de morada». Não exija um número de artigo. Registe entrada, contacto, informação contestada, alteração pretendida e sistemas inicialmente conhecidos.

A gestão de pedidos do artigo 12.º organiza identidade, prazo e comunicação. A verificação deve ser proporcional à dúvida e ao risco. Um pedido dentro de uma conta autenticada para corrigir um contacto pode exigir menos informação adicional do que uma alteração que muda o destinatário de pagamentos ou revela dados de outra pessoa.

Se faltar informação necessária, explique o ponto concreto. Pedir «documentação completa» sem indicar o que precisa de verificar aumenta a recolha e dificulta a resposta. Continue as tarefas que já pode realizar e acompanhe o prazo legal, sem tratar qualquer pergunta interna como motivo automático para suspender todo o processo.

Verificar exatidão no contexto da finalidade

Compare o dado contestado com a fonte, a data de atualização e a utilização atual. Uma divergência entre sistemas não revela, por si só, qual deles está correto. Identifique quem tem competência para validar a informação e que prova é adequada à natureza do dado.

Uma opinião ou avaliação não fica imune à retificação por ser subjetiva. Pode conter factos errados, estar atribuída à pessoa incorreta ou omitir contexto relevante. Ao mesmo tempo, o direito não garante que qualquer apreciação seja substituída pela opinião preferida do titular. A decisão deve distinguir a expressão da avaliação, os factos que a sustentam e a finalidade do registo.

Quando a exatidão é contestada, considere o direito à limitação nas condições do artigo 18.º, n.º 1, alínea a), durante a verificação. Uma marca interna que não altera o uso pode ser insuficiente se o sistema continua a tomar decisões com base no dado contestado. Defina que utilizações ficam impedidas e quem consegue levantar a restrição após a decisão.

Exemplo preenchido: morada e destinatários de uma entrega

Considere uma empresa fictícia que recebe um pedido para corrigir a morada atual de um cliente. O CRM contém a morada antiga, a encomenda ainda não foi expedida e os dados já foram enviados a um prestador logístico. A equipa identifica também uma fatura de uma compra anterior.

Elemento Decisão fictícia e verificação
Pedido Corrigir a morada atual para comunicações e entrega pendente
Identidade Pedido associado à conta, com validação adequada da alteração
CRM Atualizar o campo atual e conservar apenas o histórico necessário e restrito
Encomenda pendente Confirmar a atualização antes de preparar a expedição
Prestador logístico Comunicar a retificação e acompanhar a confirmação operacional
Documento histórico Avaliar a sua finalidade e regras próprias, sem apagar automaticamente a versão passada
Resposta Explicar os sistemas atualizados e a distinção relativa ao documento histórico
Controlo Novo pedido de teste utiliza a morada corrigida; importação antiga não a substitui

O exemplo não determina como alterar um documento fiscal concreto, que pode obedecer a regras próprias. Mostra por que motivo um botão «guardar» no CRM não fecha necessariamente o pedido. A equipa precisa de verificar o processo em curso e os destinatários que receberam a informação inexata.

Localizar sistemas a montante e a jusante

Use a cartografia dos sistemas e fluxos para seguir a informação. Identifique a fonte que alimenta atualizações automáticas, as aplicações que a utilizam e as exportações relevantes. Uma correção manual pode ser desfeita na noite seguinte se uma integração continuar a importar o valor antigo.

Quando o dado veio de um terceiro, o responsável que o utiliza deve analisar o pedido nos seus próprios tratamentos. Não remeta simplesmente a pessoa para o fornecedor e continue a usar a informação contestada. A correção da origem pode exigir cooperação própria para impedir recorrência, distinguindo-a da comunicação aos destinatários prevista no artigo 19.º.

O guia sobre dados obtidos de terceiros ajuda a identificar a origem e o contexto de aquisição. Registe conflitos entre fontes e a regra de precedência aprovada. «O ficheiro do parceiro diz isto» não é uma resposta suficiente a uma alegação fundada de inexatidão.

Comunicar aos destinatários pertinentes

Identifique a quem foram comunicados os dados e que retificação precisa de ser transmitida. A comunicação deve permitir ao destinatário localizar o registo e compreender a alteração, com o mínimo de informação adicional. Use um canal adequado ao conteúdo e evite distribuir documentos de identidade desnecessários para justificar uma alteração simples.

Se invocar impossibilidade ou esforço desproporcionado, documente as condições concretas e a avaliação. A exceção não deve resultar automaticamente de um número elevado de destinatários ou de uma falha de organização do inventário. Indique o que foi possível fazer e que risco permanece.

Quando o titular pedir informação sobre os destinatários, prepare uma resposta correspondente à obrigação aplicável. Não confunda esta comunicação com uma notificação geral à CNPD: o artigo 19.º dirige-se aos destinatários dos dados. Uma reclamação ou solicitação da autoridade pode criar um circuito próprio de resposta, que deve ser tratado no respetivo contexto.

Rever efeitos sobre perfis e decisões

Se o erro alimentou uma classificação, uma recomendação ou uma decisão, avalie os efeitos da correção. Atualizar o campo de origem pode não recalcular resultados já guardados nem retirar uma decisão em espera. A equipa deve identificar esses produtos derivados e decidir o tratamento pertinente.

No caso de uma avaliação de risco baseada numa data errada, verifique o cálculo depois da correção e as pessoas ou sistemas que receberam o resultado anterior. Quando estiverem em causa decisões abrangidas pelo artigo 22.º sobre decisões automatizadas, os direitos e salvaguardas próprios continuam relevantes. Não declare resolvida toda a contestação apenas porque um dado foi corrigido.

A revisão dos efeitos também pode revelar outras pessoas afetadas pelo mesmo erro de integração. O pedido individual desencadeia então uma melhoria preventiva. A gestão da exatidão dos dados permite tratar a causa comum sem confundir o fecho deste pedido com a correção global do sistema.

Responder e conservar uma prova proporcional

Informe o titular do resultado de forma clara: o que foi corrigido, completado ou mantido e por que motivo. Quando não der seguimento, aplique as exigências de fundamentação e indicação das vias de reclamação e recurso. Uma resposta que apenas diz «dados conformes» não explica uma decisão controvertida.

A retificação deve ocorrer sem demora injustificada e a resposta segue o regime do artigo 12.º. Não transforme o prazo geral de um mês numa espera deliberada quando a correção já está validada e pode ser executada. Também não invente um prazo técnico universal de alguns dias aplicável a todos os sistemas.

Conserve a decisão, os elementos necessários à verificação, as operações executadas e as comunicações pertinentes. Não mantenha cópias integrais de todos os documentos apresentados sem necessidade. O registo serve para demonstrar a correção e prevenir reincidência, com acesso e conservação adequados ao seu próprio conteúdo.

Antes de fechar, confirme que o valor correto chega ao percurso real, que as restrições temporárias foram tratadas e que a próxima sincronização não repõe o erro. O pedido só produz o resultado esperado quando os dados relevantes e as decisões que deles dependem passam a refletir a informação validada.

L
Escrito por
Legiscope
Legiscope

Passe esta orientação à prática

Veja como o Legiscope liga registos de privacidade, fontes e trabalho sujeito a revisão.

Marcar uma demonstração personalizada
Continuar a ler

Artigos relacionados

01Proteção de dados

Anonimização de dados: técnicas e teste de reidentificação

Anonimizar dados exige demonstrar que o resultado já não permite identificar pessoas pelos meios razoavelmente suscetíveis de serem utilizados. Apagar nomes e números de identificação é apenas uma…

8 de setembro de 2026
02Proteção de dados

Artigo 12.º: comunicar com clareza e gerir pedidos de direitos

Uma pessoa deve conseguir perceber o que a organização faz com os seus dados e exercer os seus direitos sem atravessar um circuito desnecessariamente difícil. O artigo 12.º liga a clareza da…

8 de setembro de 2026
03Proteção de dados

BCR, cláusulas-tipo e DPF: comparar o âmbito das garantias

A escolha entre regras vinculativas aplicáveis às empresas, cláusulas contratuais-tipo e Data Privacy Framework depende do destinatário e do fluxo de dados. Estes mecanismos não têm o mesmo âmbito…

8 de setembro de 2026
04Proteção de dados

Biometria para assiduidade e acessos: avaliação em Portugal

Um leitor biométrico não deve ser escolhido apenas porque evita cartões esquecidos. A organização precisa de demonstrar por que o tratamento é necessário, quais os dados realmente utilizados e como…

8 de setembro de 2026
05Proteção de dados

Cartografia dos sistemas de informação: mapa de dados e dependências

A cartografia dos sistemas de informação mostra como a atividade depende de aplicações, dados, pessoas, equipamentos e prestadores. Um inventário de software é um ponto de partida, mas não explica…

8 de setembro de 2026
06Proteção de dados

Certificação para EPD: comparar formação jurídica e operacional

Uma certificação de EPD pode ajudar a demonstrar conhecimentos, mas a escolha deve começar pelas funções que a pessoa vai desempenhar e pelas competências que lhe faltam. Comprar a formação com o…

8 de setembro de 2026
07Proteção de dados

Cifragem de dados pessoais: escolher medidas e gerir chaves

A cifragem protege a confidencialidade de dados quando o mecanismo e as chaves são adequados ao risco. Para escolher uma medida, é preciso identificar quem poderá aceder ao conteúdo, em que momento e…

8 de setembro de 2026
08Proteção de dados

Cláusulas contratuais-tipo: escolher módulos e preencher anexos

As cláusulas contratuais-tipo para transferências internacionais só são úteis quando o contrato identifica o fluxo real: quem disponibiliza os dados, quem os recebe, em que qualidade, para que…

8 de setembro de 2026