Tenho de apagar dados pessoais das cópias de segurança?

Nem é necessário destruir imediatamente todos os suportes de recuperação, nem as cópias de segurança estão fora do direito ao apagamento. Para decidir quando apagar dados das cópias de segurança, determine primeiro se o artigo 17.º exige o apagamento, classifique todas as cópias, atue sem demora injustificada quando for adequado e impeça que um restauro volte a introduzir dados apagados ^1,3.

Resposta rápida: Deve apagar dados das cópias de segurança quando o artigo 17.º o exigir, começando pelas cópias ativas e editáveis. Se a integridade impedir uma alteração segura, isole o conjunto, documente a expiração e bloqueie o uso normal. Em qualquer restauro, consulte o registo e reaplique o apagamento antes de libertar dados recuperados ^1,3.

Última atualização: 24 de setembro de 2026

O nome da cópia não decide o tratamento

Uma cópia de segurança não é automaticamente isenta nem necessariamente editável. A função real distingue uma réplica corrente, um instantâneo que pode ser alterado com segurança e um conjunto de recuperação protegido contra mudanças. Antes da mecânica, vem a pergunta jurídica: existe um fundamento de apagamento e alguma exceção aplicável ³?

Ligue o responsável pelos pedidos ao responsável pela recuperação. O primeiro conhece identidade, âmbito e resposta à pessoa; o segundo conhece snapshots, réplicas, calendários e dependências. Se trabalharem em listas separadas, um pedido pode parecer concluído no sistema ativo e reaparecer meses depois.

Classifique também cópias chamadas “arquivo”, “cache” ou “exportação”. Um nome técnico não demonstra isolamento. Se utilizadores ou processos as consultam para fins normais, continuam ativas para esta análise e precisam de uma ação verificável.

Faça a classificação com perguntas observáveis. Quem consegue montar ou pesquisar a cópia, com que frequência, para que finalidade e que dados podem sair dela? Um snapshot guardado num serviço de recuperação pode ser tecnicamente uma cópia de segurança, mas torna-se operacional quando uma equipa o monta para responder a consultas. Em sentido inverso, uma imagem imutável, sem acesso rotineiro e com expiração controlada, não deve ser tratada como uma base ativa apenas porque contém os mesmos bytes. Documente o estado atual e o acontecimento que o pode alterar, incluindo testes de recuperação, migrações e investigações internas.

Para backups editáveis, avalie se a alteração conserva a recuperabilidade do conjunto inteiro, não apenas se uma ferramenta oferece um comando de eliminação. Teste uma cópia controlada, verifique índices e manifestos, restaure dados não abrangidos e confirme que o processo não cria uma nova réplica esquecida. Se a reconstrução for a opção segura, registe a origem, os filtros, a validação e a eliminação do conjunto substituído. Essa prova permite distinguir uma decisão real de integridade de uma preferência por não tocar no sistema.

O fundamento vem antes do inventário técnico

O artigo 17.º não é acionado apenas porque alguém usa a palavra apagamento. Confirme identidade, pedido e âmbito; procure identificadores conhecidos e variantes razoáveis; depois registe qual fundamento se aplica ³:

• Os dados pessoais já não são necessários para as finalidades que justificaram a recolha ou tratamento.
• A pessoa retirou o consentimento e não existe outro fundamento jurídico para continuar o tratamento.
• A pessoa opôs-se e a oposição prevalece, ou opôs-se ao tratamento para comercialização direta.
• Os dados pessoais foram tratados ilicitamente e a continuação não pode ser justificada.
• O apagamento é necessário para cumprir uma obrigação do direito da União ou de um Estado-Membro aplicável ao responsável.
• Os dados foram recolhidos no contexto da oferta de serviços da sociedade da informação referida no artigo 8.º, n.º 1.

Cada fundamento pede prova própria. Para “já não necessário”, compare a finalidade aprovada com o uso atual; para retirada do consentimento, confirme se existe outro fundamento; para obrigação legal, identifique a regra concreta ³. A decisão deve separar o que a pessoa pediu daquilo que a pesquisa realmente encontrou. Um endereço eletrónico pode apontar para uma conta ativa, faturas conservadas por uma regra aplicável, registos de suporte já sem finalidade e várias imagens de recuperação. Cada resultado recebe a sua própria ação e justificação. Assim, o pedido não se transforma numa ordem cega para destruir tudo, mas também não é encerrado depois de apagar apenas a conta visível. Uma conclusão genérica não permite explicar por que um conjunto foi apagado, outro restringido e outro legitimamente conservado.

Depois da decisão jurídica, crie um inventário de cópias. Inclua produção, arquivos pesquisáveis, réplicas, caches, exportações, snapshots e conjuntos externos sob controlo do responsável. Para cada elemento, registe proprietário, capacidade de pesquisa, integridade, rotação, destino de restauro e destinatários dependentes.

As exceções exigem necessidade delimitada

Antes de apagar, teste as exceções do artigo 17.º. As cinco categorias são liberdade de expressão e informação; cumprimento de obrigação legal ou missão de interesse público ou autoridade pública; saúde pública; arquivo, investigação ou estatística nos termos do artigo 89.º quando o apagamento impossibilite ou prejudique gravemente os objetivos; e declaração, exercício ou defesa de direitos num processo ³.

Uma exceção não transforma uma base de dados inteira em “retenção legal”. Em especial, o artigo 17.º, n.º 3, alínea b), exige identificar a norma da União ou do Estado-Membro realmente aplicável, os dados cobertos e quem controla o prazo. Não invente um período europeu uniforme para backups.

Se apenas alguns campos forem necessários, separe-os ou restrinja-os quando tecnicamente possível. O registo deve mostrar por que os restantes foram apagados. Uma falha de separação não amplia automaticamente a exceção; exige uma decisão técnica e jurídica documentada.

Teste a necessidade no nível mais estreito possível. Uma obrigação de conservar uma fatura não significa conservar preferências de marketing, notas de suporte e cópias de identificação que estavam ligadas à mesma conta. Um litígio pode exigir mensagens específicas, não todo o histórico do cliente. Registe os campos, o intervalo temporal, os acessos permitidos e o acontecimento de libertação. Quando a mesma cópia contém dados abrangidos e não abrangidos, documente por que a separação imediata é ou não segura e que controlos impedem o uso dos dados conservados para outra finalidade.

Revise as exceções enquanto o conjunto permanece. Uma reclamação pode terminar, uma norma pode deixar de exigir certos documentos ou um projeto de investigação pode alcançar o seu objetivo. Associe cada decisão a uma data ou evento de revisão e a um proprietário. Sem esse mecanismo, uma exceção inicialmente correta converte-se silenciosamente em retenção indefinida. A revisão não precisa de desmontar o backup; precisa de atualizar o registo que governa expiração, acesso e reaplicação no restauro.

As cópias ativas precisam de um fecho verificável

Produção, arquivo pesquisável, réplica comum, cache e exportação de trabalho podem ser cópias ativas, qualquer que seja o rótulo; por isso, defina os campos e identificadores abrangidos, execute apagamento ou restrição, verifique a ausência e trate destinatários a quem os dados tenham sido comunicados.

“Sem demora injustificada” não corresponde a um prazo técnico universal inventado ³, pelo que a organização precisa de um processo que comece prontamente, explique dependências reais e mantenha a pessoa informada quando necessário; um calendário interno pode distribuir tarefas, mas não alterar o padrão jurídico.

O registo de conclusão deve conter chave do pedido, âmbito, sistemas consultados, método de pesquisa, ações, exceções, destinatários, responsável, data e verificação independente, enquanto resultados parciais ou pesquisas que falharam permanecem abertos. Marcar “concluído” porque uma tarefa foi enviada à equipa técnica não prova que os dados desapareceram; o responsável pelo pedido deve receber o resultado de cada sistema, distinguir ausência confirmada de erro de pesquisa e reabrir a ação sempre que a prova não reproduza o fecho declarado.

Verifique também efeitos laterais, pois um índice de pesquisa pode manter um valor depois da eliminação no sistema principal, uma exportação pode alimentar outro processo e um fornecedor pode possuir uma réplica; o fecho só é sólido quando essas rotas foram examinadas e o resultado ficou associado ao pedido.

Integridade técnica exige controlo no restauro

Alguns conjuntos de recuperação são deliberadamente imutáveis. Alterá-los pode destruir a prova de integridade ou tornar o restauro incerto. O relatório do EDPB reconhece a preocupação e aponta uma resposta prática: acompanhar os pedidos e reaplicá-los depois de restaurar ¹.

O isolamento tem de ser real: sem montagens rotineiras, análises, exportações ou recuperação de registos para uma finalidade normal. Controle acessos e minimize os identificadores no registo. Uma lista de pedidos demasiado rica cria um novo conjunto de risco e pode sobreviver mais tempo do que precisa.

Expiração planeada não é expiração comprovada. Guarde evidência de que o conjunto saiu da rotação e de que réplicas dependentes também desapareceram. Quando novos conjuntos substituem antigos, confirme que os dados já apagados não entraram novamente durante a transição.

O registo de restauro deve estar disponível no momento em que o ambiente principal pode não estar. Guarde-o num local resiliente, com controlo de acesso, versão e procedimento de emergência, sem o incorporar apenas no conjunto que será restaurado. Defina quem autoriza a consulta e como os identificadores são protegidos durante o incidente. Se a equipa de recuperação trabalha sob pressão, uma instrução longa e implícita será ignorada; transforme-a em pontos de decisão claros, mas mantenha a fundamentação completa ligada à chave do pedido.

Teste também a passagem entre equipas e fornecedores. Um prestador pode restaurar a infraestrutura antes de a equipa do pedido saber que o evento ocorreu, ou pode entregar uma imagem a outro prestador que cria réplicas. O contrato e o guião devem exigir notificação, isolamento e confirmação antes da libertação. Registe quem controla cada etapa, que evidência devolve e o que acontece quando a verificação não pode ser concluída dentro da janela técnica. A resposta correta é manter o ambiente controlado, não presumir que o apagamento anterior sobreviveu.

A rotação automática não fecha um pedido

A ação coordenada registou preocupações entre metade das autoridades respondentes e identificou fragilidades de execução; esses dados descrevem respostas das autoridades no exercício, não a prevalência entre todas as organizações ^1,2, pelo que não devem sustentar a inferência de que uma prática é comum ou aceitável.

Um procedimento individual liga fundamento, exceções, ações em cópias ativas, conjuntos de backup nomeados, decisão de integridade, expiração e instrução de restauro; a rotação automática pode ser um componente, mas não responde sozinha a nenhuma destas perguntas nem mostra que a pessoa certa foi abrangida.

Intervalos longos exigem avaliação baseada em risco, finalidade de recuperação, isolamento e capacidade de reaplicação, porque o relatório não estabelece um máximo universal e a organização deve justificar o seu desenho sem apresentar uma preferência técnica como prazo legal. Essa avaliação liga cada conjunto ao pedido, confronta a duração prevista com o uso possível e identifica o controlo que mantém os dados indisponíveis até à expiração. Se o isolamento falhar, o conjunto muda de classificação; sem reaplicação demonstrada, o restauro não é um risco controlado.

Distinga sempre “programado para expirar” de “expiração verificada”: o primeiro é um plano e o segundo é evidência; se um suporte falhar ao sair de rotação ou uma réplica permanecer, o pedido continua aberto e precisa de responsável e nova data. A verificação nomeia conjunto, evento e dependências eliminadas, para que outro responsável confirme que nenhuma cópia sucessora herdou os dados; um resultado incompleto reabre a tarefa sem apagar ações já comprovadas.

Os números do exercício são contexto, não prevalência

A ação envolveu 32 autoridades de controlo: 9 abriram investigações formais e 23 realizaram recolha de factos. Foram contactados 7 943 responsáveis pelo tratamento e recebidas 764 respostas ¹. Estes números descrevem o desenho e a participação no exercício, não uma amostra universal de desempenho.

As conclusões destacaram falhas recorrentes em procedimentos, calendários e exclusões injustificadas ^1,2. Uma exclusão automática de backups pode esconder uma cópia ativa; um calendário sem pesquisa pode não encontrar a pessoa; um procedimento sem restauro pode reverter uma eliminação correta.

Uma pequena organização não precisa de duplicar a escala do exercício. Um registo de pedido, um inventário de cópias e um guião de restauro podem bastar, desde que identifiquem responsáveis, decisões e prova. A simplicidade é uma vantagem quando torna o percurso repetível, mas não quando elimina perguntas necessárias.

Revise o processo com um caso positivo e um caso sem correspondência. O primeiro demonstra que os controlos encontram e tratam dados; o segundo demonstra que um “não encontrado” foi realmente pesquisado. Ambos precisam de registos compreensíveis por outra pessoa.

Um ensaio de restauro impede a reversão silenciosa

Mantenha o ambiente restaurado isolado até a verificação do apagamento estar completa. O ensaio deve seguir oito passos, pela mesma ordem:

1. Identificar o snapshot, os sistemas abrangidos e a hora exata do ponto restaurado.
2. Restringir acessos e impedir que o ambiente envie dados ou alimente serviços de produção.
3. Consultar o registo de pedidos usando apenas identificadores autorizados para correspondência.
4. Reaplicar cada correspondência positiva antes de qualquer utilização normal do ambiente.
5. Separar os dados conservados por exceção e manter a finalidade e os acessos delimitados.
6. Verificar réplicas a jusante, caches, índices e exportações criados durante ou após o restauro.
7. Registar correspondências, ausências confirmadas, ações, erros e verificações realizadas.
8. Libertar o ambiente apenas depois da assinatura dos responsáveis pelo pedido e pela recuperação.

Use dados de teste controlados para provar o mecanismo, mas inclua também o caminho genuíno de “sem correspondência”. Se uma etapa falhar, não contorne a verificação para cumprir a janela de recuperação. Mantenha o isolamento, atribua um responsável e repita a etapa.

O ensaio deve refletir mudanças recentes em identificadores, formatos e destinos. Uma instrução antiga que procura apenas email pode perder um identificador de cliente ou um endereço alterado. Atualize o registo e o guião quando o sistema ou a estratégia de backup mudar.

Inclua no ensaio uma mudança deliberada de identificador. Crie um registo de teste cujo endereço tenha sido substituído, mas cuja chave interna permaneça, e confirme que a pesquisa encontra ambas as relações autorizadas. Em seguida, teste um homónimo ou valor semelhante para demonstrar que o processo não apaga dados de outra pessoa. A correspondência deve equilibrar cobertura e precisão, com regras documentadas e revisão humana quando o resultado é ambíguo. Uma pesquisa excessivamente estreita deixa dados para trás; uma pesquisa indiscriminada cria um novo incidente.

Meça o tempo de cada etapa sem o transformar num prazo jurídico. A medição revela se a janela de recuperação permite consultar o registo, reaplicar ações e verificar réplicas antes de libertar o serviço. Se não permitir, altere a arquitetura, a sequência ou a janela planeada. Registe as dependências que atrasaram o exercício e atribua melhorias. Um ensaio que termina apenas porque o relógio acabou prova a fragilidade do processo, não a sua conclusão.

Depois do exercício, compare os dados restaurados com o inventário anterior e confirme que nenhuma exportação temporária ficou fora do ambiente isolado. Elimine os dados de teste de acordo com a finalidade definida e guarde apenas a evidência necessária do ensaio. O relatório final distingue correspondências positivas, ausências genuínas, exceções mantidas e falhas; assim, a próxima equipa pode repetir o procedimento sem depender da memória de quem participou.

O fecho reúne direito, cópias e recuperação

O dossiê de fecho reúne fundamento, exceções, ações ativas, conjuntos de backup, decisões de integridade, expiração e controlos de restauro; trabalho sem prova ou testes falhados não desaparecem por causa de uma data administrativa ³. Antes de escolher um estado, o responsável percorre a cadeia, confirma cada evidência e compara o âmbito pesquisado com o pedido; uma ligação em falta mantém a parte afetada aberta e impede um fecho total.

A prova operacional liga o resultado datado da pesquisa, a expiração verificada do conjunto e a assinatura dos responsáveis pelo pedido e pela recuperação.

Use três estados finais:

• Fechar: todas as ações e verificações aplicáveis têm prova e a resposta pode ser sustentada.
• Suspender: existe uma exceção, dependência ou decisão legítima ainda em análise, com âmbito controlado.
• Reabrir: surgiu uma cópia, falhou uma verificação ou um restauro exige nova execução do pedido.

A decisão completa tem três partes: o artigo 17.º define o âmbito jurídico, a função e a integridade de cada cópia definem a execução, e o registo e o guião de restauro impedem que uma recuperação reverta silenciosamente o resultado ³. Para fechar, associe cada parte ao proprietário e à última verificação positiva. Se surgir novo conjunto, expirar uma exceção ou falhar um ensaio, reabra o ponto pela mesma chave, preserve a prova anterior e repita as verificações dependentes; o fecho continua assim reproduzível.