DSAR, apagamento e evidência ISO 27001 em 2026

O email chegou à caixa de entrada de Sarah às 9:03.

Não era o primeiro pedido de acesso do titular dos dados que a sua empresa SaaS em rápido crescimento recebia. Era o primeiro que parecia uma auditoria pública.

O remetente era um antigo colaborador, agora defensor da privacidade. O pedido citava artigos do RGPD da UE por número e exigia todos os dados pessoais, a restrição imediata do tratamento, uma lista de todos os serviços de terceiros que detinham os seus dados e evidência verificável do apagamento nos sistemas de produção e de cópia de segurança. Um jornalista estava em cópia.

Em poucos minutos, as lacunas tornaram-se visíveis. A engenharia avisou que o “apagamento efetivo” numa base de dados multi-tenant podia afetar outros clientes. O marketing tentava separar dados de utilizadores distribuídos por várias plataformas de análise. O jurídico identificou um assunto laboral pendente. A segurança receava que os logs pudessem revelar lógica de deteção ou dados de outra pessoa. O suporte tinha registos sob dois endereços de email. A área financeira tinha faturas sob um terceiro.

O relógio já tinha começado a contar.

Este cenário já não é invulgar. Em 2026, os direitos dos titulares dos dados não são um problema de caixa de correio de privacidade. São um processo de negócio controlado, dependente de inventários de ativos, decisões sobre fundamento de licitude, verificação de identidade, controlo de acesso, regras de retenção, preservação legal, coordenação de fornecedores, divulgação segura, evidência de apagamento e registo preparado para auditoria.

O RGPD da UE indica às organizações quais são os direitos das pessoas. A ISO/IEC 27001:2022 dá às equipas de segurança e conformidade a disciplina de sistema de gestão necessária para demonstrar que esses direitos são tratados de forma consistente, segura e repetível.

Para CISOs, gestores de conformidade, responsáveis de privacidade e proprietários do negócio, o objetivo não é criar mais documentação. O objetivo é construir um único fluxo de trabalho fiável para DSAR, apagamento e restrição que produza a evidência exigida pelo RGPD da UE, por auditorias ISO/IEC 27001:2022 e por expectativas mais amplas de garantia no âmbito de NIS2, DORA, NIST CSF 2.0 e COBIT 2019.

Porque falha o tratamento ad hoc de DSAR sob pressão

A maioria das falhas em DSAR não resulta de más intenções. Resulta de fragmentação.

Uma organização pode ter um aviso de privacidade, uma caixa de correio do Encarregado da Proteção de Dados, uma cláusula do RGPD da UE nos contratos com fornecedores e, ainda assim, ter dificuldade em responder a perguntas operacionais básicas:

• Quem valida a identidade do requerente?
• Que entidade jurídica atua como responsável pelo tratamento ou subcontratante?
• Que sistemas devem ser pesquisados?
• Quem é o proprietário de cada sistema?
• Que dados estão dentro do âmbito?
• Que dados devem ser ocultados antes da divulgação?
• Que dados não podem ser apagados por motivos fiscais, de auditoria, litígio, prevenção de fraude ou obrigação legal?
• Como é aplicada tecnicamente a restrição do tratamento?
• Que fornecedores devem apoiar a pesquisa, exportação, apagamento ou restrição?
• Que evidência comprova que o pedido foi tratado dentro do prazo?
• O que acontece se o DSAR revelar uma violação de dados pessoais?

O artigo 5 do RGPD da UE exige que os dados pessoais sejam tratados de forma lícita, leal e transparente, recolhidos para finalidades determinadas, limitados ao necessário, mantidos exatos, conservados apenas pelo tempo necessário e protegidos por medidas técnicas e organizativas adequadas. O artigo 5(2) torna explícita a responsabilização: o responsável pelo tratamento deve ser capaz de demonstrar conformidade. O artigo 4 define o tratamento de forma ampla, incluindo recolha, armazenamento, utilização, divulgação, restrição, apagamento e destruição.

Isto significa que o próprio processo de DSAR é uma atividade de tratamento. Deve ser controlado.

O artigo 3 do RGPD da UE também é relevante para empresas cloud, SaaS, fintech e digitais fora da UE. Se oferecer bens ou serviços a pessoas na União, monitorizar o seu comportamento ou tratar dados pessoais no contexto de um estabelecimento na UE, o RGPD da UE pode aplicar-se mesmo quando as operações são externalizadas ou a infraestrutura é global.

A ISO/IEC 27001:2022 traz estrutura a esta realidade. As cláusulas 4.1 a 4.4 exigem que a organização compreenda o seu contexto, partes interessadas, requisitos, âmbito do SGSI e processos em interação. Um titular dos dados é uma parte interessada. Os direitos do RGPD da UE são requisitos. Aplicações SaaS, fornecedores de identidade, plataformas de análise, ferramentas de suporte, data warehouses e cópias de segurança na nuvem são processos em interação. Um fluxo de trabalho de DSAR pertence ao SGSI; não deve existir à margem dele.

Os três direitos dos titulares dos dados que criam maior pressão

Acesso, apagamento e restrição expõem a maior diferença entre a promessa legal e a capacidade operacional.

O artigo 6 do RGPD da UE é central para esta lógica de decisão. Não é possível tratar, conservar, divulgar ou recusar o apagamento sem compreender o fundamento de licitude. O artigo 9 eleva o nível de exigência para categorias especiais de dados pessoais, como dados de saúde, dados biométricos utilizados para identificação única ou dados que revelem características sensíveis. Num ambiente SaaS em 2026, isto pode afetar a integração, a verificação de identidade, a monitorização de fraude, anexos de suporte ao cliente e registos de colaboradores.

A política empresarial da Clarysec Data Protection and Privacy Policy [P17] enquadra a obrigação de forma direta. Na cláusula 3.6 de Objetivos, exige que a organização:

Defenda os direitos dos titulares dos dados, incluindo acesso, retificação, apagamento, restrição, portabilidade, oposição e proteção contra decisões automatizadas.

Esse objetivo só se torna auditável quando está ligado a proprietários, registos, fluxos de trabalho, controlos e evidência.

Comece onde os auditores começam: âmbito, partes interessadas e propriedade

No Zenith Blueprint: An Auditor’s 30-Step Roadmap [ZB], a fase ISMS Foundation & Leadership, Step 2, centra-se nas necessidades das partes interessadas e no âmbito do SGSI. Para o RGPD da UE, o Blueprint identifica as expectativas dos reguladores como:

Reguladores da UE
(RGPD da UE)

Tratamento lícito de dados
pessoais, notificação de violações no prazo de 72 horas,
direitos dos titulares dos dados

Nomear Encarregado da Proteção de Dados, estabelecer
processo de resposta a violações, procedimentos para
tratamento de pedidos de dados.

Este é o ponto de partida correto. Antes de automatizar tickets ou configurar portais, defina o âmbito do tratamento de direitos dos titulares dos dados:

1. Que entidades jurídicas atuam como responsável pelo tratamento, responsáveis conjuntos ou subcontratantes?
2. Que produtos, serviços e territórios estão dentro do âmbito?
3. Que categorias de titulares dos dados existem, como clientes, colaboradores, utilizadores de avaliação, prospetos, fornecedores, visitantes do website ou utilizadores da aplicação?
4. Que sistemas, repositórios e fornecedores detêm dados pessoais?
5. Que funções aprovam divulgação, recusa, apagamento, restrição ou escalonamento?
6. Que métricas são reportadas à gestão?

As cláusulas 5.1 a 5.3 da ISO/IEC 27001:2022 exigem liderança, alinhamento de políticas, recursos e responsabilidades atribuídas. Isto alinha diretamente com a responsabilização prevista no RGPD da UE.

A Data Protection and Privacy Policy [P17], cláusula 6.4.1 de Requisitos de implementação da política, estabelece:

O Encarregado da Proteção de Dados (DPO) deve manter processos documentados para receção, validação, acompanhamento e resposta a pedidos dos titulares dos dados (DSR).

Para PME, a Data Protection and Privacy Policy - SME [P17S] da Clarysec utiliza uma propriedade ajustada à dimensão. A cláusula 5.2.1 de Requisitos de governação estabelece:

O Coordenador de Privacidade deve manter um registo de todas as atividades de tratamento de dados pessoais, incluindo categorias de dados, finalidade, fundamento de licitude e prazos de retenção.

Esse registo de tratamento é o núcleo operacional da preparação para DSAR. Se estiver incompleto, a equipa de DSAR pesquisa com base em memória, mensagens no Slack e conhecimento informal. Se estiver correto, a equipa pesquisa por atividade de tratamento, categoria de dados, proprietário do sistema, fornecedor e regra de retenção.

O fluxo de trabalho de DSAR da Clarysec: da receção ao encerramento

Um fluxo de trabalho de DSAR preparado para auditoria deve ser suficientemente simples para funcionar sob pressão, mas suficientemente controlado para resistir a um regulador, a uma revisão de garantia solicitada por clientes ou a uma auditoria ISO/IEC 27001:2022.

1. Receção e confirmação

Os pedidos devem entrar por um canal controlado, como uma caixa de correio de privacidade, portal, formulário de suporte ou fila de receção jurídica. O pessoal deve reconhecer pedidos em linguagem comum. Uma pessoa não precisa de escrever “DSAR” para exercer um direito. “Que dados têm sobre mim?” ou “apaguem o meu perfil” pode ser suficiente para acionar o fluxo de trabalho.

A Data Protection and Privacy Policy - SME [P17S], cláusula 6.5.2 de Requisitos de implementação da política, define um nível de serviço claro:

O Coordenador de Privacidade deve acusar a receção dos pedidos no prazo de 3 dias úteis e responder no prazo de 30 dias.

A confirmação deve incluir a referência do pedido, a clarificação de âmbito quando necessária, as instruções de verificação de identidade e o prazo esperado de resposta.

2. Verificação de identidade e autoridade

Um DSAR pode transformar-se numa violação de dados pessoais se a informação for enviada à pessoa errada. A verificação deve ser proporcional e não deve recolher novos dados pessoais em excesso. Utilize portais autenticados sempre que possível. Para antigos utilizadores, valide contra dados de conta conhecidos. Para colaboradores, coordene com Recursos Humanos. Para representantes, exija prova de autoridade.

Retenha evidência do método de verificação, data de conclusão, aprovador, qualquer informação adicional solicitada e a decisão caso a verificação falhe.

3. Classificar o pedido

Uma única mensagem pode conter vários direitos. Classifique cada um separadamente, porque acesso, apagamento, restrição, oposição e portabilidade exigem lógica de decisão e evidência diferentes. Sinalize também potenciais reclamações, assuntos laborais, dados de crianças, dados de categoria especial e potenciais violações de dados pessoais.

4. Pesquisar o inventário, não apenas os sistemas óbvios

É aqui que a ISO/IEC 27001:2022 se torna prática. O Zenith Blueprint [ZB], fase Controls in Action, Step 22, alerta que o âmbito do inventário é mais amplo do que muitas organizações assumem:

O âmbito deste inventário é mais amplo do que muitos imaginam. Deve incluir:

✓ Ativos físicos: computadores portáteis, servidores, telefones, fitas de cópia de segurança, suportes removíveis,
registos impressos.
✓ Ativos digitais: documentos, conjuntos de dados, repositórios, emails, código-fonte, ficheiros
armazenados na nuvem.
✓ Ativos lógicos: contas de utilizador, credenciais, chaves, licenças de software, interfaces de programação de aplicações (API).
✓ Ativos relacionados com serviços: plataformas SaaS, serviços geridos de segurança, armazenamento
externalizado.
✓ Pessoas como ativos: não num sentido mercantilizado, mas em termos de responsabilidades atribuídas,
acesso e exposição à informação orientada pela função.

O Step 22 também explica a propriedade:

Cada ativo deve ter um proprietário definido, não a pessoa que o utiliza, mas quem é responsável
pela sua utilização, proteção e ciclo de vida. A propriedade é essencial para o alinhamento dos controlos: quem classifica
o ativo (5.10), quem decide o seu nível de acesso (8.3), quem trata do seu apagamento (8.10), quem garante
que é devolvido (5.9 sobrepõe-se subtilmente aos procedimentos de devolução de ativos).

No Zenith Controls: The Cross-Compliance Guide [ZC], o controlo 5.9 da ISO/IEC 27002:2022, Inventário de informações e outros ativos associados, é tratado como um controlo preventivo que suporta Confidencialidade, Integridade e Disponibilidade. O seu conceito de cibersegurança é Identify, a sua capacidade operacional é Gestão de ativos e os seus domínios de segurança incluem Governação, Ecossistema e Proteção.

Para DSARs, isto significa que o inventário não é uma folha de cálculo de TI. É o mapa que indica à privacidade, ao jurídico e à segurança onde podem existir dados pessoais.

5. Rever, ocultar e aprovar a divulgação

Uma resposta a DSAR não deve ser uma exportação em bruto. A revisão deve proteger dados pessoais de outras pessoas, informação de negócio confidencial, privilégio legal, dados sensíveis de segurança, sinais de fraude e dados fora do âmbito do pedido.

A aprovação deve ser baseada no risco. Respostas de acesso rotineiras podem ser aprovadas pelo Coordenador de Privacidade ou pelo DPO. Pedidos que envolvam colaboradores, litígio, dados de categoria especial, crianças, fraude, logs de segurança ou grandes exportações devem envolver o jurídico, Recursos Humanos ou liderança de segurança.

6. Entregar de forma segura

Não anexe ficheiros grandes não cifrados a emails. Utilize portais autenticados, ficheiros cifrados com entrega separada da palavra-passe ou ligações de transferência segura com expiração e registo de acessos. Registe o método de entrega, data, conta do destinatário, data de expiração e confirmação quando disponível.

7. Encerrar com evidência

A Data Protection and Privacy Policy [P17], cláusula 6.4.3, é explícita:

Todas as ações tomadas devem ser registadas para fins de auditoria, incluindo decisões de recusa de pedidos.

A Data Protection and Privacy Policy - SME [P17S], cláusula 6.5.4, estabelece:

Todas as respostas a pedidos de titulares dos dados devem ser registadas num registo seguro, com acesso restrito ao Coordenador de Privacidade e ao Diretor-Geral (GM).

Um DSAR não fica concluído quando o email é enviado. Fica concluído quando o registo demonstra o pedido, a verificação de identidade, as decisões, os sistemas pesquisados, a resposta, as exceções, as aprovações, a entrega e o encerramento.

O apagamento é destruição controlada, não um botão de eliminar

Os pedidos de apagamento revelam se a privacidade foi incorporada nos sistemas ou acrescentada após o lançamento.

A política empresarial da Clarysec Data Retention and Disposal Policy [P14], cláusula 4.3.3 de Papéis e responsabilidades, atribui responsabilidade à função que:

Responde a pedidos de apagamento e garante a eliminação atempada e verificável de dados pessoais quando exigido.

A expressão “quando exigido” é crítica. O apagamento ao abrigo do RGPD da UE não é absoluto. As organizações podem ter de conservar dados para cumprimento de obrigações legais, auditoria, obrigações fiscais, deveres regulamentares, prevenção de fraude, segurança, litígio ou declaração, exercício ou defesa de direitos legais. O fluxo de trabalho deve incluir uma decisão lícita sobre retenção e exceção.

O Zenith Blueprint [ZB], fase Controls in Action, Step 19, explica o controlo 8.10 da ISO/IEC 27002:2022, Apagamento de informação, em termos operacionais:

Este controlo garante que os dados não são mantidos por mais tempo do que o necessário e, quando deixam de ser
necessários, devem ser apagados de forma segura e fiável. Muitas organizações acumulam grandes
volumes de dados ao longo do tempo, mas sem um processo claro de apagamento esses dados podem ficar inativos e
desprotegidos, aumentando silenciosamente o risco de exposição, violação ou incumprimento regulamentar.

Também alerta:

Não se esqueça das cópias de segurança e dos sistemas arquivados; estes retêm frequentemente dados históricos muito para além do seu
valor operacional. As políticas de apagamento devem abranger:

✓ Definições de retenção de cópias de segurança,
✓ Ciclos de vida de snapshots,
✓ Repositórios de email ou documentos arquivados.

E conclui com a evidência:

O próprio processo de apagamento deve ser registado em logs e, no caso de dados de alto risco ou regulados,
revisto ou aprovado. Isto garante rastreabilidade e protege contra destruição acidental ou
não autorizada de registos valiosos.

No Zenith Controls [ZC], o controlo 8.10 da ISO/IEC 27002:2022, Apagamento de informação, é mapeado como um controlo preventivo focado na Confidencialidade, alinhado com o conceito de cibersegurança Protect e ligado às capacidades operacionais de Proteção da informação e Jurídico e Conformidade.

Para arquiteturas cloud complexas, o apagamento criptográfico pode ser adequado quando concebido corretamente. Se os dados pessoais estiverem cifrados com uma chave específica do titular ou do tenant, a destruição da chave pode tornar os dados permanentemente inacessíveis, incluindo quando remanescentes cifrados permanecem em cópias de segurança até à rotação programada. Isto deve ser cuidadosamente concebido, documentado, testado e aprovado. Não é uma forma de contornar uma arquitetura de apagamento deficiente.

A preparação das aplicações é, portanto, essencial. A Application Security Requirements Policy - SME [P09S] da Clarysec, cláusula 6.5.1.3, exige que as aplicações:

permitam a exportação e eliminação segura de dados pessoais quando legalmente exigido (por exemplo, artigo 17 do GDPR – direito ao apagamento).

Se as equipas de produto não criarem capacidade de exportação e apagamento, as equipas de privacidade ficam dependentes de scripts de base de dados, tickets de fornecedores e trabalho manual inconsistente.

Preservação legal e suspensão do apagamento

Um fluxo de trabalho maduro de apagamento deve incluir uma via de “não apagar”. Isto não é uma desculpa para ignorar o apagamento. É uma exceção controlada.

A política para PME da Clarysec Data Retention Policy and Secure Disposal Policy - SME [P14S], cláusula 5.4 de Requisitos de governação, estabelece:

Os dados sujeitos a preservação legal e suspensão do apagamento (por exemplo, em caso de litígio, auditoria ou investigação) devem ser claramente identificados no sistema e protegidos contra apagamento, mesmo que o prazo de retenção programado tenha expirado.

A Data Retention and Disposal Policy [P14], cláusula 6.4.1, reflete o mesmo princípio:

Se for emitida uma preservação legal e suspensão do apagamento (por exemplo, litígio, investigação ou auditoria pendentes), os dados que de outro modo estariam sujeitos a destruição devem ser preservados para além do seu prazo normal de retenção.

Os auditores querem ver ambos os lados da história: evidência de eliminação atempada e evidência de retenção justificada.

Restrição do tratamento: o direito subestimado

Os pedidos de restrição nem sempre exigem apagamento. Exigem que a organização limite o tratamento ativo, mantendo os dados em condições controladas.

Exemplos comuns incluem:

• Um cliente contesta a exatidão e pede que os dados deixem de ser utilizados enquanto são verificados.
• Um antigo colaborador opõe-se ao tratamento, mas o registo é necessário para direitos legais.
• Um utilizador pede o apagamento, mas devem ser conservados dados mínimos para manter uma lista de supressão.
• Uma investigação de fraude exige retenção, mas não utilização operacional normal.

Um fluxo de trabalho prático de restrição deve incluir uma decisão jurídica, sinalizador no sistema, ajuste de controlo de acesso, supressão de marketing, exclusão de analytics, instrução ao fornecedor, revisão periódica e evidência da exceção.

No Zenith Controls [ZC], o controlo 5.34 da ISO/IEC 27002:2022, Privacidade e proteção de informações pessoais identificáveis (PII), é tratado como um controlo preventivo que suporta Confidencialidade, Integridade e Disponibilidade. Mapeia para Identify e Protect, com capacidades operacionais de Proteção da Informação e Jurídico e Conformidade.

O Zenith Blueprint [ZB], fase Controls in Action, Step 23, resume o teste de auditoria:

Confirme que a sua organização implementou medidas de privacidade (5.34) alinhadas com
os requisitos legais aplicáveis. Verifique a classificação de informações pessoais identificáveis (PII), controlos de acesso adequados, práticas de
tratamento seguro e formação de sensibilização. Valide se os pedidos de acesso dos titulares,
o apagamento de dados ou os logs de tratamento são suportados operacionalmente, e não apenas por política.

A expressão-chave é “suportados operacionalmente, e não apenas por política”.

Mapear fluxos de trabalho de DSAR para evidência ISO/IEC 27001:2022

A ISO/IEC 27001:2022 não substitui o RGPD da UE. Organiza a evidência.

As cláusulas 6.1.1 a 6.1.3 exigem avaliação de riscos, tratamento de riscos, critérios de aceitação do risco, proprietários dos riscos, seleção de controlos, Declaração de Aplicabilidade e plano de tratamento de riscos. Os riscos de DSAR incluem divulgação não autorizada, incumprimento de prazos, apagamento incompleto, retenção ilícita, verificação de identidade excessiva, não cooperação de fornecedores e incapacidade de restringir o tratamento.

A cláusula 8.1 exige que as organizações planeiem, implementem e controlem processos do SGSI, retenham evidência documentada, controlem alterações e garantam que processos, produtos e serviços fornecidos externamente e relevantes para o SGSI são controlados. Isto adequa-se às operações de DSAR porque os pedidos atravessam funções internas e subcontratantes externos.

Um pacote de evidência robusto inclui o procedimento DSR, registo DSR, registo de atividades de tratamento, inventário de ativos, calendário de retenção de dados, registo de preservação legal, procedimento de verificação de identidade, orientações de ocultação, método de divulgação segura, procedimento de apagamento, procedimento de restrição, guião operacional de fornecedores, Registo de Exceções, registos de formação, resultados de auditoria interna e reporte de revisão pela gestão.

Um fluxo de trabalho prático para acesso, apagamento e restrição

Este fluxo de trabalho transforma a crise de Sarah num processo auditável. Cada etapa tem um proprietário, uma base de controlo e evidência.

Valor de conformidade cruzada para além do RGPD da UE

Um fluxo de trabalho de DSAR tem origem no RGPD da UE, mas os mesmos controlos suportam referenciais mais amplos.

O artigo 20 da NIS2 torna a cibersegurança uma responsabilidade de gestão para entidades essenciais e importantes. O artigo 21 exige medidas técnicas, operacionais e organizacionais adequadas e proporcionais, incluindo análise de riscos, tratamento de incidentes, continuidade de negócio, segurança da cadeia de fornecimento, avaliação da eficácia, higiene de cibersegurança, formação, controlo de acesso, gestão de ativos, autenticação e comunicações seguras. Os DSARs dependem de muitas dessas mesmas capacidades.

O DORA aplica-se desde 17 de janeiro de 2025 a muitas entidades financeiras e estabelece requisitos uniformes de gestão do risco das TIC, notificação de incidentes, testes de resiliência e risco de terceiros de TIC. Os artigos 5 e 6 exigem governação e gestão do risco das TIC documentada. Os artigos 17 a 20 tratam de deteção, classificação, escalonamento, comunicação e encerramento de incidentes. Os artigos 24 a 30 tratam de testes de resiliência, risco de terceiros de TIC, registos de serviços, direitos de auditoria, localização de dados, assistência a incidentes e estratégias de saída. Uma fintech que trata DSARs através de plataformas cloud deve alinhar o tratamento de pedidos de privacidade com o seu registo de serviços de TIC.

O NIST CSF 2.0 ajuda a traduzir o mesmo trabalho em resultados de cibersegurança. GOVERN trata requisitos legais, regulamentares e contratuais, estratégia de risco, papéis, política e supervisão. IDENTIFY e PROTECT alinham-se fortemente com visibilidade de ativos, classificação de dados, controlo de acesso, apagamento, governação de fornecedores e proteção da privacidade.

O COBIT 2019 coloca questões de governação. Quem é proprietário do processo? Que objetivos estão definidos? Como é medido o desempenho? Como são aprovadas as exceções? Como é obtida a garantia? A evidência de DSAR pode suportar objetivos como APO13 Segurança Gerida, APO14 Dados Geridos e DSS06 Controlos Geridos dos Processos de Negócio.

A perspetiva do auditor

Não crie evidência separada para cada referencial. Crie um fluxo de trabalho de DSAR fiável e mapeie-o bem.

Métricas de DSAR que a gestão deve ver

A gestão não consegue supervisionar o que não vê. Métricas úteis incluem volume de pedidos por tipo de direito, tempo médio de confirmação, tempo médio de encerramento, cumprimento de prazos, taxas de clarificação de identidade, exceções de apagamento, casos de preservação legal, tempos de resposta de fornecedores, recusas parciais, incidentes identificados durante o tratamento e ações de remediação em aberto.

Estas métricas mostram se os direitos dos titulares dos dados estão operacionalmente saudáveis ou dependem de heroísmo.

Lacunas comuns na preparação para DSAR

A Clarysec observa frequentemente as mesmas fragilidades em SaaS, fintech, serviços profissionais e PME orientadas prioritariamente para a nuvem:

• Ausência de proprietário para cada sistema que contém dados pessoais
• Registo de tratamento não alinhado com a utilização real de SaaS
• Plataformas de marketing, analytics e data warehouses excluídas das pesquisas
• Ausência de norma documentada de verificação de identidade
• Ausência de revisão de ocultação antes da divulgação
• Apagamento em produção realizado sem tratamento das cópias de segurança
• Ausência de verificação de preservação legal antes do apagamento
• Restrição tratada manualmente sem sinalizador no sistema
• Contratos com fornecedores sem termos de assistência DSAR
• Recusas e recusas parciais não documentadas
• Ausência de amostragem por auditoria interna de DSARs concluídos
• Pessoal da linha da frente sem formação para reconhecer pedidos

A sua lista de verificação de preparação para DSAR em 2026

Utilize-a como teste de maturidade:

• Temos um processo documentado de receção, validação, acompanhamento e resposta a DSR?
• Confirmamos a receção dos pedidos dentro de um SLA interno definido?
• Mantemos um registo DSR seguro com acesso restrito?
• Temos um registo atual de atividades de tratamento com categorias, finalidades, fundamentos de licitude e prazos de retenção?
• Conhecemos todos os sistemas, plataformas SaaS, repositórios e fornecedores que podem deter dados pessoais?
• Cada ativo relevante tem um proprietário responsável?
• Conseguimos exportar dados pessoais de forma segura?
• Conseguimos apagar dados pessoais de forma segura quando legalmente exigido?
• Conseguimos restringir o tratamento técnica ou procedimentalmente?
• Verificamos a preservação legal antes da eliminação?
• Documentamos decisões de recusa, recusa parcial e exceção?
• Os contratos com fornecedores suportam assistência DSAR?
• Testamos o fluxo de trabalho através de auditoria interna ou exercícios de simulação?
• Reportamos o desempenho de DSAR à gestão?
• Mapeamos os controlos de DSAR para o tratamento de riscos ISO/IEC 27001:2022 e para a Declaração de Aplicabilidade?

Se várias respostas forem “não de forma consistente”, o próximo pedido pode expor a lacuna.

Transformar direitos dos titulares dos dados em evidência preparada para auditoria

Em 2026, os direitos dos titulares dos dados exigem mais do que boas intenções e uma caixa de correio de privacidade. Exigem um fluxo de trabalho capaz de encontrar dados, validar identidade, tomar decisões lícitas, coordenar fornecedores, proteger a divulgação, executar o apagamento, aplicar a restrição e preservar evidência.

A Clarysec ajuda as organizações a construir esse fluxo de trabalho sem criar uma burocracia paralela de conformidade. Comece com o Zenith Blueprint para posicionar os direitos dos titulares dos dados na fase e nos passos corretos do SGSI. Utilize a Data Protection and Privacy Policy, a Data Protection and Privacy Policy - SME, a Data Retention and Disposal Policy, a Data Retention Policy and Secure Disposal Policy - SME e a Application Security Requirements Policy - SME da Clarysec para definir propriedade e regras operacionais.

Depois utilize o Zenith Controls para mapear os controlos 5.9, 5.34 e 8.10 da ISO/IEC 27002:2022 para evidência de conformidade cruzada para garantia em RGPD da UE, ISO/IEC 27001:2022, NIS2, DORA, NIST CSF 2.0 e COBIT 2019.

Se quiser saber se os seus fluxos de trabalho de DSAR, apagamento e restrição sobreviveriam amanhã a uma auditoria, a Clarysec pode ajudar a testar o processo, fechar lacunas e construir o pacote de evidência antes da chegada do próximo pedido. Descarregue os modelos de políticas Clarysec relevantes ou agende uma avaliação de preparação para DSAR para evoluir de resposta reativa para operações de privacidade controladas e preparadas para auditoria.