Testes de controlos de privacidade da ISO 27701 para o RGPD da UE
A auditoria de privacidade de sexta-feira que expôs o verdadeiro problema
São 15:40 de uma sexta-feira quando Maria, a CISO de uma empresa SaaS em rápido crescimento, entra numa videochamada com o responsável principal de compras de um potencial cliente empresarial de grande dimensão.
A sua equipa trabalhou durante meses no sistema de gestão da informação de privacidade. As políticas estão aprovadas. O registo de atividades de tratamento existe. A empresa tem um plano de preparação para a ISO 27701. O EPD dispõe de fluxos de trabalho para pedidos de exercício de direitos dos titulares dos dados. A equipa jurídica atualizou os acordos de tratamento de dados. A engenharia afirma que o acesso ao ambiente de produção está restrito.
O responsável de compras começa de forma educada, mas direta.
“Obrigado pela documentação, Maria. O certificado e o pacote de políticas são um bom ponto de partida. A nossa equipa de diligência prévia estará no local no próximo mês. Vai querer ver o vosso processo de pedidos de exercício de direitos em funcionamento, verificar controlos de minimização dos dados nas nossas contas de teste, rever logs de acesso à produção e inspecionar evidência de que os controlos de privacidade são testados, e não apenas documentados.”
Em poucos minutos, Maria recebe mais duas mensagens.
O EPD pergunta se a nova funcionalidade analítica está coberta pelo registo de atividades de tratamento, pela avaliação do fundamento de licitude, pelo calendário de retenção e pelas obrigações em cadeia aplicáveis ao subcontratante.
O gestor de conformidade pergunta se a revisão de preparação para a ISO 27701:2025 consegue demonstrar que os controlos PIMS estão a operar eficazmente.
É neste momento que muitos programas de privacidade vacilam. A organização tem documentos de privacidade, mas não prova operacional de privacidade. Tem fluxos de trabalho, mas não evidência baseada em amostragem. Tem contratos, mas registos de monitorização fracos. Tem confiança interna, mas não dispõe de um trilho de auditoria defensável.
Essa lacuna é a diferença entre conformidade documental e responsabilização demonstrável.
O RGPD da UE torna o problema explícito. O responsável pelo tratamento é responsável pelo cumprimento dos princípios de proteção de dados e deve conseguir demonstrá-lo. Os dados pessoais devem ser tratados de forma lícita, leal e transparente, para finalidades determinadas, limitados ao necessário, exatos, conservados apenas durante o tempo necessário e protegidos por medidas técnicas e organizativas adequadas.
A ISO 27701:2025 fornece às organizações a estrutura de gestão da privacidade. A ISO/IEC 27001:2022 fornece a espinha dorsal do SGSI para âmbito, tratamento de riscos, controlo operacional, auditoria interna, revisão pela gestão e melhoria contínua. O RGPD da UE estabelece o ónus jurídico da responsabilização. NIS2, DORA, NIST CSF 2.0, modelos de garantia ao estilo COBIT 2019 e revisões de segurança solicitadas por clientes aumentam a pressão para demonstrar que os controlos funcionam.
A visão da Clarysec é simples: os testes de controlos de privacidade não devem ser uma corrida anual à recolha de capturas de ecrã. Devem constituir um sistema de evidência PIMS que liga atividades de tratamento, controlos aplicáveis, riscos, amostras, verificações técnicas, constatações, CAPA e revisão pela gestão num modelo rastreável.
É aqui que o conjunto de políticas PIMS da Clarysec, o Zenith Blueprint: roteiro de 30 passos para auditores e o Zenith Controls: guia de conformidade cruzada se tornam ferramentas operacionais, e não material de prateleira.
Os testes de controlos de privacidade são a ponte entre política e responsabilização
Um teste de controlo de privacidade responde a três perguntas práticas:
- O controlo está concebido para cumprir a obrigação de privacidade ou reduzir o risco de privacidade?
- O controlo está implementado no processo, sistema, equipa, fornecedor ou fluxo de trabalho de produto relevante?
- O controlo opera eficazmente ao longo do tempo, com evidência que satisfaça um auditor, cliente, regulador ou comité de risco do conselho de administração?
Uma empresa SaaS pode afirmar que suporta pedidos de apagamento. Um teste de conceção verifica se estão definidos a política de apagamento, o processo de verificação de identidade, o modelo de responsabilidade, a coordenação com subcontratantes, as exceções de retenção e o tratamento de cópias de segurança. Um teste de eficácia operacional utiliza amostras de pedidos de apagamento concluídos, compara carimbos temporais, verifica aprovações, revê logs de sistema, confirma notificações a subcontratantes a jusante e valida a evidência de encerramento.
A Política de Monitorização, Auditoria e Melhoria do PIMS transforma isto num requisito auditável:
[Ambos] O Revisor de Auditoria Interna / Conformidade DEVE testar o estado de implementação dos controlos PIMS aplicáveis contra o REG03 durante cada auditoria PIMS.
Da secção ‘Programa de auditoria interna do PIMS’, cláusula 4.2.5 da política.
A expressão “contra o REG03” é central. O teste não é uma entrevista aberta. O REG03 funciona como referência de aplicabilidade e implementação dos controlos PIMS. Mostra o que se aplica, por que razão se aplica e que evidência deve existir.
A mesma política acrescenta:
[Ambos] O Revisor de Auditoria Interna / Conformidade DEVE registar no REG12 a amostra selecionada de evidência de tratamento de PII durante cada auditoria PIMS.
Da secção ‘Programa de auditoria interna do PIMS’, cláusula 4.2.6 da política.
Este é o núcleo dos testes de controlos de privacidade da ISO 27701:2025. Uma auditoria PIMS sem amostra é uma conversa. Uma auditoria PIMS com evidência selecionada, mapeamento de controlos, exceções, ação corretiva e rastreabilidade para a revisão pela gestão é responsabilização.
Começar pelo âmbito, pelo papel e pela realidade do tratamento
A maioria das auditorias de privacidade fracas falha antes de os testes começarem. Selecionam controlos genéricos sem confirmar que dados pessoais são tratados, onde residem, que sistemas e fornecedores lhes acedem e se a organização atua como responsável pelo tratamento, subcontratante, responsável conjunto pelo tratamento ou subcontratante subsequente.
As obrigações do RGPD da UE dependem muito do papel desempenhado. Um responsável pelo tratamento que decide por que razão e de que forma os dados pessoais são tratados tem obrigações diferentes das de um subcontratante que atua segundo instruções documentadas do cliente. A sensibilidade dos dados também é relevante. Dados dos trabalhadores, dados de contas de clientes, telemetria, dados financeiros, verificação biométrica, dados relacionados com saúde, triagem de sanções e dados relativos a infrações penais não apresentam o mesmo risco.
Um programa robusto de testes da ISO 27701:2025 começa com disciplina de delimitação do âmbito.
| Pergunta de âmbito | Evidência a inspecionar | Por que é relevante |
|---|---|---|
| Que atividades de tratamento de PII estão no âmbito? | Registo de atividades de tratamento, mapa de fluxos de dados, inventário de sistemas, registo centralizado de fornecedores | Os testes devem amostrar tratamento real, não declarações abstratas de política |
| Que papel PIMS se aplica? | Mapeamento de responsável pelo tratamento, subcontratante, responsável conjunto pelo tratamento e subcontratante subsequente | As obrigações do RGPD da UE e os controlos PIMS diferem consoante o papel |
| Que obrigações legais, contratuais e regulamentares se aplicam? | Avaliação do RGPD da UE, acordos de tratamento de dados de clientes, regras setoriais, avaliações de transferência | A conceção dos controlos deve refletir as obrigações reais |
| Que sistemas e fornecedores tratam PII? | Inventário de ativos, inventário de serviços na nuvem, lista de subcontratantes, matriz de acessos | Os testes operacionais exigem evidência técnica e de terceiros |
| Que alterações afetam o tratamento de PII? | Registos de alterações de produto, desencadeadores de AIPD, notas de versão, revisões de arquitetura | A privacidade desde a conceção deve ser testada antes do lançamento, não depois de reclamações |
A ISO/IEC 27001:2022 suporta esta abordagem integrada através dos seus requisitos relativos ao contexto da organização, requisitos das partes interessadas, obrigações legais e contratuais, âmbito do sistema de gestão, planeamento operacional e tratamento de riscos. Para a privacidade, isto significa que o tratamento de PII não pode permanecer numa folha de cálculo desligada. Deve integrar o modelo operacional do SGSI e do PIMS.
A Política do Sistema de Gestão da Informação de Privacidade liga diretamente os testes de privacidade à governação:
[Todos] A Alta Direção DEVE rever anualmente no REG12 o desempenho do PIMS, os objetivos de privacidade, os riscos em aberto, as não conformidades, as ações corretivas e as decisões de melhoria.
Da secção ‘Governação do PIMS’, cláusula 6.1.1 da política.
Se os testes identificarem uma lacuna de privacidade, isso não é apenas uma nota de auditoria. É uma entrada do sistema de gestão que deve influenciar o tratamento de riscos, prioridades, recursos e decisões da liderança.
Eficácia da conceção versus eficácia operacional
Quando um cliente pergunta se os controlos de privacidade são testados, normalmente refere-se à eficácia operacional. Contudo, os auditores também analisam a eficácia da conceção.
Um controlo eficaz na conceção é capaz de cumprir o requisito se for executado conforme previsto. Um controlo eficaz operacionalmente é executado de forma consistente e suportado por evidência.
| Área de controlo | Teste de eficácia da conceção | Teste de eficácia operacional |
|---|---|---|
| Recolha de consentimento | Verificar a política, o texto do consentimento, as regras de fundamento de licitude, os requisitos de interface de utilizador e o fluxo de trabalho de retirada do consentimento | Amostrar registos de consentimento e retiradas do consentimento, comparar carimbos temporais e verificar a supressão após retirada do consentimento |
| Limitação das finalidades | Rever o registo de atividades de tratamento, o aviso de privacidade, os requisitos do produto, a separação do consentimento e as regras de utilização dos dados | Amostrar registos de utilizadores, logs, exportações e fluxos analíticos para confirmar que a PII não é reutilizada para finalidades não autorizadas |
| Acesso a PII | Rever a política de acesso, o modelo de funções, o procedimento de admissões, movimentações e desligamentos e o fluxo de trabalho de aprovação | Amostrar utilizadores com acesso a PII e verificar aprovação, necessidade de negócio, MFA e revisão de acessos recente |
| Integração de subcontratantes | Rever critérios de diligência prévia, cláusulas do acordo de tratamento de dados, regras de subcontratantes subsequentes e salvaguardas de transferência | Amostrar um subcontratante e inspecionar avaliação, contrato, revisão de segurança e evidência de monitorização de subcontratantes subsequentes |
| Retenção e apagamento | Rever o calendário de retenção, as regras de exceção, o procedimento de apagamento e a capacidade do sistema | Amostrar registos apagados ou pedidos de apagamento e inspecionar logs, tickets e confirmações de subcontratantes |
| Tratamento de violações de dados pessoais | Rever a classificação de incidentes, o escalonamento de privacidade e os critérios de notificação à autoridade | Amostrar registos de incidentes e verificar triagem, fundamentação da decisão, notificações e lições aprendidas |
A Política de Auditoria e Monitorização da Conformidade enuncia diretamente a finalidade:
Validar a eficácia dos controlos de segurança e privacidade
Da secção ‘Finalidade’, cláusula 1.1.1 da política.
A versão PME mantém o mesmo princípio de garantia em linguagem operacional. A Política de Auditoria e Monitorização da Conformidade - PME estabelece:
Esta política define a abordagem da organização à realização de auditorias internas, revisões de controlos de segurança e monitorização da conformidade. Garante que todos os controlos, políticas, sistemas e prestadores de serviços são sujeitos a revisão regular e estruturada.
Da secção ‘Finalidade’, cláusula 1.1 da política.
A preparação para a ISO 27701 não depende da dimensão da empresa. Um subcontratante SaaS com 30 pessoas pode não precisar das mesmas ferramentas de auditoria de um banco global, mas continua a ter de demonstrar que acesso, apagamento, escalonamento de incidentes, governação de subcontratantes subsequentes e retenção de evidência estão controlados.
A cadeia de evidência da Clarysec: REG03, REG12, CAPA e revisão
A Clarysec estrutura os testes de controlos de privacidade em torno de uma cadeia de evidência simples.
O REG03 define os controlos PIMS aplicáveis e o estado de implementação. O REG12 regista amostras, evidência, constatações, lacunas de rastreabilidade, verificação de ações corretivas e entradas para revisão pela gestão. Os registos CAPA convertem constatações em melhorias baseadas em análise de causa raiz. A Alta Direção revê o desempenho do PIMS, riscos, não conformidades, ações corretivas e decisões de melhoria.
A Política de Informação Documentada e Gestão de Evidência do PIMS exige que sejam registados problemas de qualidade da evidência:
[Todos] O Revisor de Auditoria Interna / Conformidade DEVE registar no REG12 lacunas de completude, exatidão ou rastreabilidade da evidência durante cada auditoria ou revisão de conformidade programada.
Da secção ‘Criação, nomenclatura e qualidade da evidência’, cláusula 4.3.4 da política.
Isto é importante porque nem todas as constatações correspondem a uma falha total de controlo. Por vezes, o controlo funcionou, mas a evidência está incompleta. Por vezes, um ticket de apagamento está fechado, mas não existe log de sistema que comprove o apagamento. Por vezes, o registo de atividades de tratamento identifica o CRM, mas omite a exportação para o armazém de dados. Por vezes, existe um contrato com o fornecedor, mas não há monitorização contínua.
A Política de Auditoria e Monitorização da Conformidade também exige auditorias internas estruturadas:
As auditorias internas devem seguir um procedimento documentado que inclua:
Da secção ‘Requisitos de implementação da política’, cláusula 6.1.1 da política.
E, quando ocorrem constatações:
Todas as constatações devem resultar numa CAPA documentada que inclua:
Da secção ‘Requisitos de implementação da política’, cláusula 6.2.1 da política.
A Política de Gestão de Riscos - PME reforça a disciplina de encerramento:
A conclusão e a eficácia das ações de tratamento devem ser verificadas.
Da secção ‘Requisitos de implementação da política’, cláusula 6.3.2 da política.
A Política de Monitorização, Auditoria e Melhoria do PIMS fecha o ciclo:
[Todos] O Revisor de Auditoria Interna / Conformidade DEVE verificar a eficácia da ação corretiva no REG12 no prazo de 30 dias após o encerramento comunicado da ação corretiva.
Da secção ‘Não conformidade e ação corretiva’, cláusula 4.4.7 da política.
Esta é a diferença entre fechar um ticket e melhorar um sistema de gestão.
Teste prático 1: pedidos de apagamento e responsabilização no RGPD da UE
Os pedidos de apagamento são uma das formas mais claras de testar se a responsabilização em matéria de privacidade funciona na prática.
Assuma que uma empresa SaaS de mercado intermédio atua simultaneamente como responsável pelo tratamento e subcontratante. Controla dados dos trabalhadores, de marketing e de faturação. Trata dados de utilizadores finais de clientes por conta de clientes empresariais. A organização pretende testar se os controlos de apagamento estão preparados para uma auditoria ISO 27701:2025 e para garantia de privacidade solicitada por clientes no âmbito do RGPD da UE.
Passo 1: selecionar a atividade de tratamento no REG03
Escolha uma atividade de tratamento com risco real de privacidade, como “dados de perfil de utilizadores finais de clientes tratados na plataforma SaaS”. Confirme se a organização atua como responsável pelo tratamento, subcontratante ou ambos. Identifique os controlos associados para tratamento de pedidos de exercício de direitos, validação de instruções do subcontratante, retenção, apagamento, controlo de acesso, registo, tratamento de cópias de segurança e coordenação com fornecedores.
Passo 2: definir um objetivo de teste preciso
Um objetivo de teste útil é específico e orientado por evidência:
“Verificar que os pedidos de apagamento de dados de perfil de utilizadores finais de clientes são recebidos, autenticados ou validados contra instruções, executados no fluxo de trabalho definido, registados, tecnicamente concluídos nos sistemas de produção, propagados aos subcontratantes subsequentes relevantes quando aplicável e encerrados com evidência.”
Passo 3: recolher uma amostra representativa
Selecione cinco pedidos de apagamento do último trimestre. Inclua um pedido de rotina, um pedido que envolva um administrador do cliente, um pedido por instrução do subcontratante, um pedido com exceção de retenção e um pedido que envolva tratamento de cópias de segurança.
O Zenith Blueprint, na fase Auditoria, Revisão e Melhoria, Passo 26: Execução da auditoria, enfatiza a amostragem e a recolha de evidência:
✓ Entrevistar pessoal relevante: peça às pessoas responsáveis pelos processos que expliquem como cumprem os requisitos. Por exemplo, pergunte ao proprietário do risco sobre a última avaliação de riscos, ou pergunte aos Recursos Humanos como as novas admissões recebem formação em segurança (para cobrir o controlo 6.3 sobre sensibilização).
✓ Rever documentação: verifique se os documentos e registos existem e estão atualizados.
✓ Observar práticas: se possível, faça observação direta.
✓ Amostrar e efetuar verificações por amostragem: não é possível verificar tudo, por isso utilize amostragem.
Da fase Auditoria, Revisão e Melhoria, Passo 26: Execução da auditoria (realização de uma auditoria interna).
Passo 4: inspecionar a evidência de cada amostra
Para cada pedido amostrado, recolha o ticket de receção, a classificação de papéis, a verificação de identidade ou autorização do cliente, o log de apagamento do sistema, a decisão de exceção de retenção, a explicação do tratamento de cópias de segurança, a notificação ao subcontratante subsequente, a comunicação de encerramento, os carimbos temporais e a aprovação formal do revisor.
Passo 5: registar os resultados no REG12
Registe no REG12 a amostra, a fonte de evidência, o resultado do controlo, a exceção e a lacuna de rastreabilidade. Se o apagamento ocorreu mas não existe log de produção, o controlo pode ter operado, mas a evidência é fraca. Se o pedido se atrasou porque a responsabilidade do fornecedor não estava clara, a constatação pode envolver governação de terceiros e obrigações contratuais em cadeia.
Passo 6: criar CAPA e verificar a eficácia
Se a causa raiz for falta de clareza sobre a responsabilidade entre suporte, jurídico e engenharia, a CAPA pode incluir um fluxo de trabalho revisto, RACI atualizado, campos obrigatórios de evidência e verificações mensais de amostras de apagamento.
O Zenith Blueprint, na fase Auditoria, Revisão e Melhoria, Passo 29, explica a expectativa de encerramento:
Planeie como vai verificar a eficácia de cada ação corretiva. Isto pode implicar agendar uma auditoria ou verificação de seguimento. Por exemplo, se a sua ação corretiva consistiu em formar a equipa de TI sobre controlo de acesso, pode planear rever novas contas no prazo de um mês para verificar se todas têm aprovações adequadas (verificação).
Da fase Auditoria, Revisão e Melhoria, Passo 29: Melhoria contínua (ações corretivas e lições aprendidas).
Para apagamento, a verificação pode significar amostrar os cinco pedidos de apagamento seguintes após a entrada em produção do fluxo de trabalho revisto. Só depois a CAPA deve ser encerrada.
Teste prático 2: limitação das finalidades e minimização dos dados
Um segundo teste de elevado valor é a limitação das finalidades. É especialmente útil antes de diligência prévia de clientes, lançamentos de funcionalidades analíticas, enriquecimento por IA, expansão do armazém de dados ou alterações de automatização de marketing.
A plataforma SaaS de Maria recolhe dados de utilizadores de clientes para prestação do serviço. O objetivo de controlo é assegurar que a PII é utilizada apenas para finalidades determinadas e legítimas, e não reutilizada para análise de marketing salvo se o utilizador tiver dado consentimento explícito e separado quando exigido.
| Tipo de evidência | Artefactos específicos |
|---|---|
| Documentação | Política de proteção de dados e privacidade, registo de atividades de tratamento, acordo de tratamento de dados do cliente, avisos de privacidade, registos de gestão de consentimento |
| Configuração técnica | Regras de tratamento de dados da aplicação, esquemas de bases de dados, configurações de interfaces de programação de aplicações, definições de tarefas ETL |
| Logs e registos | Logs de acesso da aplicação, logs de consultas à base de dados, histórico de alterações de consentimento, registos de exportação de campanhas |
| Evidência de pessoal | Entrevistas com o proprietário do produto, programador principal, administrador de base de dados e responsável de privacidade |
Um teste operacional robusto não se fica pela política. Amostra utilizadores que aceitaram marketing e utilizadores que não aceitaram. Rastreia se o estado do consentimento está corretamente refletido nas bases de dados principais da aplicação, tabelas do armazém de dados, ferramentas de campanha, painéis de gestão e exportações. Se utilizadores sem consentimento surgirem num público de marketing, a organização tem uma não conformidade concreta.
A Política de Auditoria e Monitorização da Conformidade para PME dá a mentalidade correta através de um exemplo de teste técnico:
Verificação de controlos técnicos (por exemplo, estado de cópia de segurança, configuração de controlo de acesso, registos de patches)
Da secção ‘Requisitos de implementação da política’, cláusula 6.1.1.2 da política.
Para privacidade, a verificação de controlos técnicos inclui verificações de sincronização de consentimento, exportações de controlo de acesso, logs de apagamento, definições de cifragem, testes de mascaramento de dados, alertas DLP, restrições de cópias de segurança, eventos de monitorização e evidência de fornecedores.
Mapeamento dos testes de privacidade para a ISO/IEC 27001:2022 e a conformidade cruzada da Clarysec
Os controlos de privacidade não operam isoladamente. A proteção de PII depende de inventário de ativos, classificação, controlo de acesso, governação de serviços na nuvem, mascaramento de dados, transferência de informação, registo, monitorização, apagamento, proteção de registos, supervisão de fornecedores e revisão independente.
No Zenith Controls: guia de conformidade cruzada, o controlo 5.34 do Anexo A da ISO/IEC 27001:2022, Privacidade e proteção de PII, é mapeado como controlo preventivo alinhado com confidencialidade, integridade e disponibilidade, com os conceitos de cibersegurança Identificar e Proteger, e com capacidades operacionais em Proteção da Informação, mais Jurídico e Conformidade.
A sua relação com o inventário é direta:
Um inventário de ativos de informação (5.9) deve incluir repositórios de dados de PII (bases de dados de clientes, ficheiros de RH). Isto sustenta o 5.34 ao garantir que a organização sabe que PII possui e onde se encontra, o que é o primeiro passo para a proteger.
De Zenith Controls, Privacidade e Proteção de PII, controlo 5.34.
Para testes de auditoria, isto significa que o auditor de privacidade não deve começar apenas pelo aviso de privacidade. Deve começar pelo inventário de PII, registo de atividades de tratamento, fluxos de dados, inventário de ativos e inventário de fornecedores. Se o inventário estiver incompleto, os controlos de privacidade a jusante não podem ser plenamente fiáveis.
O guia também mapeia o controlo 5.34 do Anexo A da ISO/IEC 27001:2022 para controlos relacionados, como 5.9 Inventário de informações e outros ativos associados, 5.12 Classificação da informação, 5.14 Transferência de informação, 5.15 Controlo de acesso, 5.16 Gestão de identidades, 5.23 Segurança da informação para utilização de serviços na nuvem, 5.33 Proteção de registos, 8.11 Mascaramento de dados, 8.12 Prevenção de fuga de dados e 8.10 Eliminação de informação.
Dois controlos adicionais do Anexo A da ISO/IEC 27001:2022 são especialmente relevantes:
| Controlo ISO/IEC 27001:2022 | Relevância para os testes de privacidade | Exemplo de evidência |
|---|---|---|
| 5.34 Privacidade e proteção de PII | Confirma que os requisitos de privacidade e proteção de PII estão implementados com base em leis, regulamentos e contratos | Registo de atividades de tratamento, AIPD, registos de fundamento de licitude, evidência de pedidos de exercício de direitos, logs de retenção |
| 5.35 Revisão independente da segurança da informação | Proporciona validação objetiva de que os mecanismos de segurança, incluindo controlos relevantes para a privacidade, são revistos de forma independente | Relatórios de auditoria interna, resultados de revisão externa, amostras REG12, registos CAPA |
| 5.36 Cumprimento de políticas, regras e normas de segurança da informação | Confirma o cumprimento contínuo de regras e normas internas | Revisões de cumprimento da política, verificações de acesso, resultados de monitorização, registos de exceções |
A Política de proteção de dados e privacidade exige:
Deve ser realizada anualmente, ou perante alterações organizacionais ou regulamentares relevantes, uma auditoria interna de conformidade de privacidade. O âmbito da auditoria deve incluir:
Da secção ‘Requisitos de governação’, cláusula 5.4 da política.
Inclui ainda:
Eficácia das medidas técnicas e organizativas
Da secção ‘Requisitos de governação’, cláusula 5.4.1 da política.
A Política de proteção de dados e privacidade - PME mantém a mesma expectativa de forma prática:
Devem ser realizadas e registadas auditorias de privacidade ou verificações de controlo regulares
Da secção ‘Requisitos de governação’, cláusula 5.3.3 da política.
Por que a responsabilização no RGPD da UE é agora uma questão de governação de cibersegurança
A evidência de privacidade já não é solicitada apenas por auditores de privacidade. A mesma prova pode ser pedida por um auditor ISO 27701:2025, um auditor ISO/IEC 27001:2022, um revisor do RGPD da UE, uma autoridade competente NIS2, um cliente regulado por DORA, um avaliador NIST CSF ou um comité de risco do conselho de administração.
O Article 21 da NIS2 exige que entidades essenciais e importantes implementem medidas técnicas, operacionais e organizacionais adequadas e proporcionais para a gestão de riscos de cibersegurança. O Article 21(2)(f) inclui explicitamente políticas e procedimentos para avaliar a eficácia das medidas de gestão de riscos de cibersegurança. A NIS2 também responsabiliza os órgãos de administração pela aprovação e supervisão das medidas de gestão de riscos de cibersegurança.
O DORA aplica-se a partir de 17 de janeiro de 2025 às entidades financeiras e estabelece um quadro detalhado de resiliência operacional digital. Exige gestão do risco das TIC, supervisão pelo órgão de administração, auditoria interna, remediação de constatações críticas, classificação e reporte de incidentes, testes de resiliência, gestão de risco de terceiros de TIC, controlos contratuais, registos de acordos de serviços de TIC e estratégias de saída. Os prestadores de TIC que servem entidades financeiras devem esperar pedidos de evidência orientados pelo DORA através de garantia para clientes.
O NIST CSF 2.0 fornece uma camada útil de tradução. A sua função GOVERN espera que as organizações compreendam as expectativas das partes interessadas, dependências e obrigações legais, regulamentares, contratuais, de privacidade e de liberdades civis. A sua abordagem de Perfis ajuda a comparar resultados atuais com resultados-alvo, identificar lacunas e priorizar planos de ação.
| Pressão de requisitos | O que os testes de controlos de privacidade devem produzir | Âncora Clarysec |
|---|---|---|
| Responsabilização no RGPD da UE | Evidência de que princípios, fundamento de licitude, direitos, segurança, retenção e obrigações de subcontratantes são demonstravelmente cumpridos | Políticas PIMS, REG03, REG12, CAPA |
| Preparação para a ISO 27701:2025 | Controlos PIMS testados, aplicabilidade baseada em papéis, qualidade da evidência, auditoria interna, revisão pela gestão | Política de Monitorização, Auditoria e Melhoria do PIMS |
| Garantia ISO/IEC 27001:2022 | Rastreabilidade do tratamento de riscos, fundamentação da SoA, controlo operacional, auditoria, revisão, melhoria | Zenith Blueprint, guia de conformidade cruzada Zenith Controls |
| Governação NIS2 | Avaliação da eficácia, preparação para incidentes, controlos de fornecedores, supervisão pela gestão | Mapeamento dos controlos 5.35 e 5.36 do Anexo A da ISO/IEC 27001:2022 |
| Garantia DORA | Testes de controlos de TIC, testes de resiliência, evidência de terceiros, registos do ciclo de vida dos incidentes | Modelo de evidência de auditoria com mapeamento cruzado |
| NIST CSF 2.0 | Perfil atual, perfil-alvo, análise de lacunas, melhoria priorizada | Zenith Blueprint Passos 24, 26, 29 |
O Zenith Blueprint reforça a rastreabilidade no Passo 24:
A sua SoA deve ser consistente com o seu Registo de Riscos e Plano de Tratamento de Riscos. Confirme que cada controlo escolhido como tratamento de riscos está marcado como “Aplicável” na SoA. Inversamente, se um controlo estiver marcado como “Aplicável” na SoA, deve existir uma fundamentação para tal — normalmente um risco mapeado, um requisito legal/regulamentar ou uma necessidade de negócio.
Da fase Auditoria, Revisão e Melhoria, Passo 24: Auditoria, Revisão e Melhoria.
Para testes de controlos de privacidade, o mesmo princípio aplica-se à aplicabilidade PIMS. Cada controlo de privacidade aplicável deve ser rastreável a um risco de tratamento, obrigação legal, requisito de cliente ou necessidade de negócio. Cada teste deve ser rastreável a esse controlo.
Como diferentes auditores avaliam o mesmo controlo
Um programa robusto de testes de privacidade antecipa a perspetiva do auditor. O mesmo controlo de apagamento, controlo de acesso ou controlo de integração de subcontratantes será interpretado de forma diferente consoante o contexto da revisão.
| Perspetiva do auditor | Pergunta provável de auditoria | Evidência esperada |
|---|---|---|
| Auditor ISO 27701:2025 | Os controlos PIMS baseados em papéis estão implementados, avaliados e melhorados? | Aplicabilidade REG03, amostras REG12, registo de atividades de tratamento, mapeamento de políticas, resultados de auditoria |
| Auditor ISO/IEC 27001:2022 | O controlo relacionado com privacidade está integrado no tratamento de riscos, SoA, controlo operacional, auditoria interna e revisão pela gestão? | Registo de Riscos, fundamentação da SoA, plano de tratamento, evidência de controlo, atas de revisão pela gestão |
| Revisor do RGPD da UE | O responsável pelo tratamento consegue demonstrar cumprimento dos princípios e obrigações do RGPD da UE? | Fundamento de licitude, avisos, logs de pedidos de exercício de direitos, AIPD, contratos, registos de violações de dados pessoais, evidência de retenção |
| Avaliador NIST CSF | A organização conhece as obrigações, define resultados-alvo, mede lacunas e melhora? | Perfil atual e perfil-alvo, plano de lacunas, priorização de riscos, registos de governação |
| Cliente ou regulador orientado por DORA | Os controlos de TIC são testados, os incidentes são classificados, os fornecedores são monitorizados e os serviços críticos são resilientes? | Programa de testes, registos de incidentes, registo centralizado de fornecedores, contratos, planos de saída |
| Auditor ISACA ou ao estilo COBIT 2019 | Objetivos, responsabilidade, métricas, encerramento de questões e supervisão de governação são eficazes? | RACI, KPIs, registos de questões, verificação CAPA, reporte à gestão |
É por isso que o REG12 é tão valioso. Converte a conformidade de privacidade em evidência de governação auditável.
Constatações comuns nos testes de controlos PIMS
A Clarysec observa repetidamente as mesmas constatações de auditoria de privacidade em organizações que se preparam para certificação ISO 27701:2025, garantia de clientes no âmbito do RGPD da UE ou diligência prévia empresarial.
O registo de atividades de tratamento não corresponde à realidade dos sistemas
O registo de atividades de tratamento lista CRM e plataformas de suporte, mas os engenheiros adicionaram exportações analíticas, logs de observabilidade, ferramentas de IA e tabelas de armazém de dados.
Resposta ao teste: amostrar sistemas do inventário de ativos e do inventário de serviços na nuvem e depois reconciliá-los com o registo de atividades de tratamento. Utilize a relação entre os controlos 5.9 e 5.34 do Anexo A da ISO/IEC 27001:2022 como fundamentação de auditoria.
O acesso a PII está aprovado, mas não é revisto periodicamente
Existem aprovações iniciais, mas as revisões de acessos privilegiados não incluem ferramentas de personificação indevida de suporte, bases de dados de produção, painéis de BI ou contas de emergência.
Resposta ao teste: amostrar utilizadores ativos com acesso a PII e comparar função, necessidade de negócio, aprovação, estado de MFA, último login e evidência de revisão.
Existem contratos com subcontratantes, mas a monitorização é fraca
O acordo de tratamento de dados está assinado, mas o questionário do fornecedor está desatualizado. Ninguém reviu alterações de subcontratantes subsequentes, localizações dos dados, postura de segurança ou obrigações de notificação de incidentes.
Resposta ao teste: amostrar subcontratantes críticos e inspecionar diligência prévia, cláusulas contratuais, alterações de subcontratantes subsequentes, salvaguardas de transferência e registos de monitorização. Isto suporta o RGPD da UE, as expectativas NIS2 para a cadeia de fornecimento e as expectativas DORA relativas a risco de terceiros.
Existe resposta a incidentes, mas a classificação de privacidade é inconsistente
Os incidentes de segurança são registados, mas o impacto na privacidade nem sempre é avaliado. Os critérios de violação de dados pessoais do RGPD da UE não são documentados de forma consistente. As obrigações de notificação de clientes são tratadas informalmente.
Resposta ao teste: amostrar incidentes que envolvam exposição de dados e inspecionar classificação, escalonamento de privacidade, revisão jurídica, decisões de notificação, preservação de evidência, causa raiz e lições aprendidas.
A CAPA é encerrada sem verificação de eficácia
Um procedimento é atualizado e a constatação é encerrada. Ninguém testa se a amostra seguinte melhorou.
Resposta ao teste: verificar a eficácia da ação corretiva no REG12 no prazo de 30 dias após o encerramento comunicado, conforme exigido pela Política de Monitorização, Auditoria e Melhoria do PIMS.
Um sprint de 90 dias para testes de controlos de privacidade
Para organizações que avançam para preparação para a ISO 27701:2025, diligência prévia de clientes ou revisão de responsabilização no RGPD da UE, a Clarysec recomenda um sprint focado de 90 dias.
| Prazo | Foco | Saídas |
|---|---|---|
| Dias 1 a 15 | Âmbito e modelo de evidência | Papéis PIMS, registo de atividades de tratamento, aplicabilidade REG03, riscos prioritários, obrigações legais, dependências de fornecedores, regras de nomenclatura de evidência |
| Dias 16 a 35 | Testes de conceção | Revisão de políticas, RACI, avisos de privacidade, fundamento de licitude, desencadeadores de AIPD, fluxos de trabalho de pedidos de exercício de direitos, classificação de incidentes, calendários de retenção, controlos de fornecedores |
| Dias 36 a 65 | Testes operacionais | Amostras de acesso, apagamento, incidentes, subcontratantes, transferências, retenção, formação, monitorização técnica, evidência REG12 |
| Dias 66 a 80 | CAPA e tratamento de riscos | Causa raiz, ação corretiva, proprietário, data limite, risco residual, método de verificação |
| Dias 81 a 90 | Preparação para revisão pela gestão | Pacote de desempenho do PIMS, objetivos, riscos em aberto, não conformidades, ações corretivas, questões de fornecedores, decisões de melhoria |
No final do sprint, a organização deve conseguir responder às perguntas que os auditores realmente fazem:
- Que PII tratam?
- Em que papel?
- Que controlos se aplicam?
- Por que razão são aplicáveis?
- Que evidência demonstra que estão implementados?
- Que amostra demonstra que operam?
- Que lacunas foram encontradas?
- Que ações corretivas foram tomadas?
- Quem verificou a eficácia?
- O que reviu e decidiu a Alta Direção?
Da privacidade em papel à responsabilização demonstrável
Um certificado ISO 27701 é valioso, mas não é o destino final. Clientes, reguladores, conselhos de administração e auditores esperam cada vez mais prova de que os controlos de privacidade estão concebidos, implementados, monitorizados, corrigidos e governados.
A conformidade de privacidade falha quando é tratada como um projeto documental. Resiste ao escrutínio quando se torna um sistema de evidência testado.
A Clarysec ajuda as organizações a passar de conformidade declarada para responsabilização demonstrável, ligando políticas PIMS, aplicabilidade REG03, amostras de evidência REG12, verificação CAPA, revisão pela gestão e mapeamento entre referenciais através do Zenith Blueprint: roteiro de 30 passos para auditores e do Zenith Controls: guia de conformidade cruzada.
Se a sua organização está a preparar-se para certificação ISO 27701:2025, revisão de responsabilização no RGPD da UE, garantia de privacidade para clientes, evidência de governação NIS2 ou diligência prévia de fornecedores impulsionada pelo DORA, comece com um workshop focado de testes de controlos de privacidade.
A Clarysec pode ajudar a mapear a aplicabilidade REG03, criar amostras de auditoria REG12, testar controlos PIMS prioritários, alinhar constatações com CAPA e preparar saídas da revisão pela gestão que resistam ao escrutínio.
A sua próxima auditoria de privacidade não deve ser uma corrida à recolha de capturas de ecrã. Deve ser uma demonstração confiante de que a privacidade está operacional, evidenciada, revista e continuamente melhorada.
About the Author
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council