Proteção de informação pessoal identificável (PII) preparada para auditoria para RGPD, NIS2 e DORA
O alerta chegou à caixa de entrada da Sarah às 22h00 de uma terça-feira.
Enquanto CISO de uma fintech SaaS em crescimento, os alertas fora de horas não eram novidade. Este era diferente. Um programador júnior tinha exposto uma base de dados de pré-produção através de um endpoint público enquanto testava uma nova funcionalidade de análise. A base de dados deveria conter dados de teste, mas uma sincronização recente de produção para pré-produção tinha-a preenchido com PII real de clientes.
O incidente foi rapidamente contido. Depois surgiu a segunda descoberta. Uma folha de cálculo de migração chamada customer_users_final_v7.xlsx tinha sido copiada a partir do mesmo conjunto de dados. Continha nomes, emails, permissões de função, logs de utilização, campos de país, notas de suporte e comentários em texto livre que nunca deveriam ter entrado num fluxo de trabalho de teste. Tinha sido copiada para uma unidade partilhada, descarregada por um programador, anexada a um ticket e esquecida.
À meia-noite, Sarah já não estava a gerir uma configuração técnica incorreta. Estava a gerir um problema de auditoria.
A empresa já estava certificada pela ISO/IEC 27001:2022. O Conselho de Administração pedia garantia relativamente ao RGPD antes do lançamento no mercado europeu. Clientes de serviços financeiros enviavam questionários de diligência prévia DORA. Relações com serviços na nuvem e serviços geridos levantavam questões de cadeia de fornecimento no âmbito da NIS2. A área jurídica conseguia explicar as obrigações. A engenharia conseguia apontar para a cifragem. O produto tinha intenções de privacidade desde a conceção. A Declaração de Aplicabilidade mencionava privacidade e proteção de PII.
Mas ninguém conseguia demonstrar, numa cadeia única e rastreável, que PII existia, porque era tratada, quem lhe podia aceder, onde era mascarada, que fornecedores a tratavam, durante quanto tempo era retida e como um incidente seria classificado ao abrigo do RGPD, da NIS2 ou da DORA.
É precisamente essa lacuna que torna a ISO/IEC 27701:2025 e a ISO/IEC 29151:2022 relevantes. Não são apenas rótulos de privacidade. Ajudam as organizações a transformar compromissos de privacidade em controlos de proteção de PII preparados para auditoria. A ISO/IEC 27701:2025 alarga um Sistema de Gestão da Segurança da Informação (SGSI) ISO/IEC 27001:2022 à gestão da informação de privacidade. A ISO/IEC 29151:2022 acrescenta orientações práticas para proteger informação pessoal identificável ao longo do seu ciclo de vida.
A abordagem da Clarysec consiste em construir um único modelo operacional de privacidade e segurança orientado por evidência, e não silos de conformidade separados. Esse modelo combina Zenith Blueprint: roteiro de 30 passos para auditores Zenith Blueprint, Zenith Controls: guia de conformidade transversal Zenith Controls e políticas da Clarysec num sistema único e rastreável para RGPD, ISO/IEC 27001:2022, ISO/IEC 27701:2025, ISO/IEC 29151:2022, NIS2, DORA, garantia alinhada com NIST e expectativas de governação do COBIT 2019.
Porque a proteção de PII é agora uma questão de auditoria ao nível do Conselho de Administração
A proteção de PII costumava ser tratada como responsabilidade da equipa de privacidade. Hoje, é uma questão de confiança, resiliência e regulação ao nível do Conselho de Administração.
O RGPD continua a ser a referência de base para a proteção de dados pessoais na Europa e fora dela. Define dados pessoais, tratamento, responsável pelo tratamento, subcontratante, destinatário, terceiro, consentimento e violação de dados pessoais de formas que afetam contratos SaaS, operações de suporte, análise, telemetria de produto, gestão de fornecedores e resposta a incidentes. Os seus princípios exigem licitude, lealdade, transparência, limitação das finalidades, minimização dos dados, exatidão, limitação da conservação, integridade, confidencialidade e responsabilização. Em termos de auditoria, o RGPD não pergunta apenas se os dados estão cifrados. Pergunta se a organização consegue demonstrar por que razão os dados existem e como a conformidade é alcançada.
A NIS2 eleva a fasquia da governação de cibersegurança para entidades essenciais e importantes. Article 21 exige medidas de gestão de riscos de cibersegurança, incluindo análise de riscos, políticas de segurança dos sistemas de informação, tratamento de incidentes, continuidade de negócio, segurança da cadeia de fornecimento, desenvolvimento seguro, tratamento de vulnerabilidades, avaliação da eficácia dos controlos, higiene de cibersegurança, criptografia, segurança de recursos humanos, controlo de acesso, gestão de ativos, autenticação e comunicações seguras. Article 23 acrescenta comunicação faseada de incidentes, incluindo um alerta precoce no prazo de 24 horas, notificação no prazo de 72 horas e um relatório final no prazo de um mês após a notificação.
A DORA muda a conversa para entidades financeiras e respetivos prestadores de TIC. Aplica-se desde 17 de janeiro de 2025 e cria um regime harmonizado de resiliência operacional digital que abrange gestão do risco das TIC, reporte de incidentes graves relacionados com as TIC, testes de resiliência, risco de terceiros de TIC, requisitos contratuais e supervisão de prestadores críticos terceiros de serviços de TIC. Para muitas entidades financeiras, a DORA funciona como o ato jurídico setorial da União quando há sobreposição com obrigações equivalentes à NIS2. Para fornecedores SaaS e de TIC que prestam serviços a instituições financeiras, a pressão DORA chega frequentemente através de cláusulas contratuais, auditorias de clientes, requisitos de planeamento de saída, obrigações de apoio a incidentes e testes de resiliência.
A ISO/IEC 27001:2022 fornece a espinha dorsal do sistema de gestão. Exige contexto, partes interessadas, âmbito, responsabilização da liderança, políticas, funções, avaliação de riscos, tratamento de riscos, Declaração de Aplicabilidade, auditoria interna, revisão pela gestão e melhoria contínua. O Anexo A inclui controlos diretamente relevantes para a proteção de PII, incluindo 5.34 Privacidade e proteção de PII, 5.18 Direitos de acesso, 8.11 mascaramento de dados, 5.23 Segurança da informação na utilização de serviços na nuvem, 8.15 Registo, 8.33 Informação de teste, 8.24 Utilização de criptografia e 8.10 Eliminação de informação.
O desafio não é a inexistência de controlos nas organizações. É a fragmentação dos controlos. Os registos de privacidade ficam na área jurídica. As revisões de acessos ficam na TI. Os scripts de mascaramento ficam na engenharia. Os contratos com fornecedores ficam nas compras. A evidência fica em tickets, capturas de ecrã, folhas de cálculo e correio eletrónico.
A ISO/IEC 27701:2025 e a ISO/IEC 29151:2022 ajudam a unificar essa evidência em torno da gestão da informação de privacidade e das práticas de proteção de PII. A Clarysec transforma essa estrutura num modelo operacional.
Do SGSI ao PIMS: a cadeia integrada de controlos de privacidade
Um SGSI ISO/IEC 27001:2022 responde a uma pergunta central: a segurança da informação é governada, baseada no risco, implementada, monitorizada e melhorada?
Um Sistema de Gestão da Informação de Privacidade, ou PIMS, alarga essa pergunta aos dados pessoais: as responsabilidades de privacidade, as atividades de tratamento de PII, os riscos de privacidade, as obrigações de responsáveis pelo tratamento e subcontratantes, os direitos dos titulares dos dados e a evidência dos controlos de privacidade são geridos dentro do mesmo sistema?
A ISO/IEC 27701:2025 alarga o SGSI à governação da privacidade. A ISO/IEC 29151:2022 complementa-a com orientações práticas de proteção de PII, incluindo limitação da recolha, gestão da divulgação, aplicação de mascaramento ou pseudonimização, proteção de transferências, restrição de acesso e alinhamento dos controlos com o risco de privacidade.
| Camada | Pergunta principal | Evidência típica de auditoria |
|---|---|---|
| ISO/IEC 27001:2022 | Existe um SGSI governado e baseado no risco, com controlos selecionados e em operação? | Âmbito, partes interessadas, avaliação de riscos, plano de tratamento, SoA, políticas, auditoria interna, revisão pela gestão |
| ISO/IEC 27701:2025 | As responsabilidades de privacidade, os riscos de privacidade e as atividades de tratamento de PII são governados dentro do sistema de gestão? | Funções de privacidade, registo de tratamento, procedimentos para responsáveis pelo tratamento e subcontratantes, avaliações de risco de privacidade, AIPD, processo de pedidos dos titulares dos dados |
| ISO/IEC 29151:2022 | Estão implementadas medidas práticas de proteção de PII ao longo do ciclo de vida dos dados? | Classificação de PII, restrições de acesso, mascaramento, pseudonimização, controlos de retenção, salvaguardas de transferência, evidência de incidentes |
| RGPD | A organização consegue demonstrar tratamento lícito, leal, transparente, minimizado, seguro e responsável? | Registos de fundamento de licitude, avisos de privacidade, AIPD, processo de violação de dados, acordos com subcontratantes, tratamento de direitos |
| NIS2 e DORA | A organização consegue governar riscos de cibersegurança e resiliência, incluindo incidentes e fornecedores? | Supervisão pela gestão, quadro de risco das TIC, classificação de incidentes, playbooks de reporte, registos de fornecedores, direitos de auditoria, testes de continuidade |
Este modelo em camadas evita o erro mais comum na conformidade de privacidade: tratar a PII como apenas mais um tipo de dados sensíveis. A PII implica obrigações legais, éticas, operacionais, contratuais e reputacionais. Precisa de uma cadeia de controlo que comece na consciencialização e termine na evidência.
Comece pelo conhecimento dos dados, não por diagramas de cifragem
A falha de privacidade mais comum que a Clarysec observa é a falta de contexto. Uma empresa não consegue proteger PII se não souber que PII tem, onde reside, que finalidade serve, durante quanto tempo é conservada ou quem consegue aceder-lhe.
O Zenith Blueprint inicia este trabalho cedo na fase de gestão de riscos. No Step 9, Identifying Assets, Threats, and Vulnerabilities, instrui as organizações a inventariar ativos de informação e a sinalizar explicitamente dados pessoais:
“Para cada ativo, registe os principais detalhes: nome/descrição, proprietário, localização e classificação (sensibilidade). Por exemplo, um ativo poderia ser ‘Base de dados de clientes – propriedade do Departamento de TI – alojada na AWS – contém dados pessoais e financeiros (sensibilidade elevada).’”
Acrescenta ainda: “Assegure que os ativos de dados pessoais são sinalizados (pela sua relevância para o RGPD) e que os ativos de serviços críticos são assinalados (para potencial aplicabilidade da NIS2, se estiver num setor regulado).”
Esta é a base para a adoção da ISO/IEC 27701:2025 e da ISO/IEC 29151:2022. A sequência prática é simples:
- Identificar sistemas, conjuntos de dados, repositórios, logs, relatórios, cópias de segurança, ferramentas de suporte, ambientes de desenvolvimento e fornecedores que tratam PII.
- Atribuir um proprietário a cada ativo de PII.
- Classificar PII por sensibilidade, finalidade de negócio, fundamento de licitude, papel no tratamento e requisito de retenção.
- Ligar cada ativo de PII a ameaças, vulnerabilidades, cenários de risco e obrigações regulamentares.
- Selecionar controlos, atribuir evidência e monitorizar a operação ao longo do tempo.
As políticas da Clarysec tornam isto executável. A Política de proteção de dados e privacidade para PME Política de proteção de dados e privacidade - PME 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.”
Da secção “Requisitos de governação”, cláusula da política 5.2.1.
Para organizações empresariais, a Política de proteção de dados e privacidade Política de proteção de dados e privacidade estabelece uma regra estrita de minimização:
“Apenas os dados necessários para uma finalidade de negócio específica e legítima podem ser recolhidos e tratados.”
Da secção “Requisitos de implementação da política”, cláusula da política 6.2.1.
Estas cláusulas transformam a responsabilização do RGPD em operações diárias. Também suportam a gestão da informação de privacidade e a proteção de PII, porque obrigam a organização a definir que dados existem, por que razão existem e se são necessários.
Os três controlos que tornam a proteção de PII efetiva
Três controlos do Anexo A da ISO/IEC 27001:2022 determinam frequentemente se a proteção de PII é defensável em auditoria: 5.34 Privacidade e proteção de PII, 8.11 mascaramento de dados e 5.18 Direitos de acesso.
5.34 Privacidade e proteção de PII
O Controlo 5.34 é o eixo de governação. No Zenith Controls, o 5.34 é tratado como um controlo preventivo que suporta confidencialidade, integridade e disponibilidade, com conceitos de cibersegurança Identificar e Proteger e capacidades operacionais em proteção da informação e conformidade legal.
O Zenith Controls torna clara a dependência:
“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 recursos humanos). Isto sustenta o 5.34 ao assegurar que a organização sabe que PII tem e onde se encontra, o que constitui o primeiro passo para a proteger.”
O Controlo 5.34 depende do 5.9 Inventário de informação e outros ativos associados porque a PII não pode ser protegida se não puder ser encontrada. Também se liga ao 5.23 Segurança da informação na utilização de serviços na nuvem, porque a maior parte da PII vive atualmente em plataformas na nuvem, ferramentas SaaS, ambientes de análise e serviços geridos.
Para tratamento de alto risco, a Política de proteção de dados e privacidade empresarial exige:
“A modelação de ameaças e as Avaliações de Impacto sobre a Proteção de Dados (AIPD) são obrigatórias para sistemas de tratamento de alto risco.”
Da secção “Requisitos de implementação da política”, cláusula da política 6.3.4.
Esta cláusula é crítica. Transforma a privacidade numa atividade de conceção e gestão de riscos, e não numa revisão jurídica de última hora.
8.11 Mascaramento de dados
O Controlo 8.11 é a resposta direta à exposição da base de dados de pré-produção da Sarah. O Zenith Controls descreve o 8.11 como um controlo preventivo de confidencialidade no domínio da proteção da informação. Liga o 8.11 ao 5.12 Classificação da informação porque as decisões de mascaramento dependem da sensibilidade, ao 5.34 porque o mascaramento suporta a proteção da privacidade, e ao 8.33 Informação de teste porque os ambientes de teste não devem expor PII real.
A Política de Mascaramento de Dados e Pseudonimização Política de Mascaramento de Dados e Pseudonimização explicita a regra:
“Dados pessoais reais não devem ser utilizados em ambientes de desenvolvimento, teste ou pré-produção. Devem ser utilizados dados mascarados ou pseudonimizados, gerados a partir de modelos de transformação previamente aprovados.”
Da secção “Requisitos de implementação da política”, cláusula da política 6.3.
Para PME, a Política de Mascaramento de Dados e Pseudonimização para PME Política de Mascaramento de Dados e Pseudonimização - PME acrescenta um requisito essencial de segurança e evidência:
“O acesso às chaves deve ser cifrado, sujeito a controlo de acesso e registado.”
Da secção “Requisitos de implementação da política”, cláusula da política 6.2.1.3.
Isto é importante porque a pseudonimização só reduz o risco quando a lógica de transformação, as chaves e os caminhos de reidentificação são controlados.
5.18 Direitos de acesso
O Controlo 5.18 é o núcleo operacional do princípio do menor privilégio. O Zenith Controls trata-o como preventivo, ligado à confidencialidade, integridade e disponibilidade, e enquadrado na gestão de identidades e acessos. Relaciona o 5.18 com o 5.15 Controlo de acesso, 5.16 Gestão de identidades e 8.2 Direitos de acesso privilegiado.
A Política de Classificação e Rotulagem da Informação para PME Política de Classificação e Rotulagem da Informação - PME estabelece:
“O acesso deve ser limitado a utilizadores especificamente autorizados com necessidade de conhecer.”
Da secção “Requisitos de governação”, cláusula da política 5.2.1.
A Política de Classificação e Rotulagem da Informação empresarial Política de Classificação e Rotulagem da Informação acrescenta a linha de base de classificação:
“Todos os ativos de informação devem ter uma classificação claramente atribuída no momento da criação ou integração. Na ausência de classificação explícita, os ativos devem assumir por defeito a classificação ‘Confidencial’ até revisão formal.”
Da secção “Requisitos de governação”, cláusula da política 5.4.
Em conjunto, estes controlos formam a cadeia prática de proteção de PII: conhecer a PII, classificá-la, limitar o acesso, mascará-la quando a identidade completa não é necessária, proteger as chaves, registar o acesso e reter evidência.
Construir rastreabilidade através da Declaração de Aplicabilidade
Um sistema de gestão da privacidade fica preparado para auditoria quando consegue demonstrar rastreabilidade. O Zenith Blueprint, na fase de gestão de riscos, Step 13, Risk Treatment Planning and Statement of Applicability, descreve a Declaração de Aplicabilidade como um documento de ligação:
“A SoA é, na prática, um documento de ligação: liga a sua avaliação/tratamento de riscos aos controlos efetivos que possui. Ao completá-la, também verifica novamente se deixou algum controlo de fora.”
Este conceito é central para a preparação face à ISO/IEC 27701:2025, ISO/IEC 29151:2022, RGPD, NIS2 e DORA. Cada controlo de PII deve ser rastreável desde o requisito ao risco, do risco ao controlo, do controlo ao proprietário, do proprietário à evidência e da evidência à revisão.
| Item de rastreabilidade | Exemplo para PII de suporte ao cliente | Evidência esperada |
|---|---|---|
| Ativo de PII | Plataforma de tickets de suporte com nomes de clientes, emails, logs e anexos | Entrada no registo de ativos, proprietário, localização na nuvem, classificação |
| Finalidade do tratamento | Suporte ao cliente e diagnóstico do serviço | Registo de tratamento, fundamento de licitude, prazo de retenção |
| Cenário de risco | Agente de suporte ou programador acede a dados de cliente em excesso | Entrada no registo de riscos, probabilidade, impacto, proprietário |
| Seleção de controlos | 5.34 proteção de PII, 5.18 direitos de acesso, 8.11 mascaramento, 8.15 registo, 5.23 governação da nuvem | SoA, política de acesso, norma de mascaramento, configuração de registo |
| Evidência operacional | Acesso baseado em funções, exportações mascaradas, revisão trimestral de acessos, alertas sobre descarregamentos em massa | Registos de revisão de acessos, alertas DLP, logs, evidência em tickets |
| Mapeamento regulamentar | Responsabilização e segurança no RGPD, gestão de riscos NIS2, risco das TIC e requisitos de fornecedores DORA | Matriz de conformidade, playbook de incidentes, registo de contratos com fornecedores |
| Evidência de revisão | Constatação de auditoria interna encerrada, ação de revisão pela gestão aceite | Relatório de auditoria, ação corretiva, ata de revisão pela gestão |
A ISO/IEC 27005:2022 suporta esta abordagem baseada no risco ao enfatizar requisitos das partes interessadas, critérios de risco comuns, proprietários do risco responsabilizáveis, avaliação de riscos repetível, tratamento de riscos, seleção de controlos, alinhamento da Declaração de Aplicabilidade, aprovação do risco residual, monitorização e melhoria contínua. A proteção de PII deve ser um ciclo de risco vivo, e não um exercício documental pontual do RGPD.
Corrigir a folha de cálculo e a base de dados de pré-produção de risco
O incidente da Sarah pode ser transformado num pacote de controlos repetível se a remediação for tratada de forma sistemática.
| Passo | Ação | Resultado de evidência Clarysec |
|---|---|---|
| 1 | Registar a base de dados de pré-produção e a folha de cálculo como ativos de PII | Entradas no inventário de ativos com proprietário, localização, classificação, categorias de PII, finalidade e retenção |
| 2 | Atualizar a atividade de tratamento | Entrada no registo com categorias de dados, fundamento de licitude, finalidade e prazo de retenção |
| 3 | Classificar os ficheiros e conjuntos de dados | Classificação Confidencial ou superior aplicada por defeito até revisão formal |
| 4 | Remover PII real de ambientes que não sejam de produção | Conjunto de dados mascarado ou pseudonimizado gerado a partir de modelos de transformação aprovados |
| 5 | Restringir e rever o acesso | Permissões com base na necessidade de conhecer, revogação de acessos excessivos, registo de revisão de acessos |
| 6 | Proteger a lógica de transformação e as chaves | Acesso às chaves cifrado, sujeito a controlo de acesso e registado |
| 7 | Capturar evidência de forma centralizada | Registo de ativo, entrada de risco, revisão de acessos, evidência de eliminação, aprovação de mascaramento e encerramento de ticket |
| 8 | Atualizar a SoA e o plano de tratamento de riscos | Cenário de risco ligado a 5.34, 5.18, 8.11, 8.15, 8.10, 5.23 e controlos de fornecedores |
| 9 | Decidir se é necessária uma AIPD | AIPD ou justificação documentada para decisões de tratamento de alto risco |
| 10 | Registar lições aprendidas | Formação atualizada, regras de desenvolvimento seguro, controlos de exportação, monitorização DLP e orientações sobre dados de teste |
A Política de Auditoria e Monitorização da Conformidade para PME Política de Auditoria e Monitorização da Conformidade - PME estabelece:
“Toda a evidência deve ser armazenada numa pasta centralizada de auditoria.”
Da secção “Requisitos de implementação da política”, cláusula da política 6.2.1.
A Política de Segurança da Informação Política de Segurança da Informação torna explícita a expectativa mais ampla de auditoria:
“Todos os controlos implementados devem ser auditáveis, suportados por procedimentos documentados e por evidência retida da sua operação.”
Da secção “Requisitos de implementação da política”, cláusula da política 6.6.1.
Estas duas cláusulas são a diferença entre ter um controlo e conseguir demonstrá-lo.
Mapeamento de conformidade transversal para um único conjunto de controlos de PII
A proteção de PII torna-se mais fácil de defender quando é mapeada entre referenciais antes de o auditor perguntar.
| Tema de proteção de PII | Relevância para o RGPD | Relevância para ISO/IEC 27001:2022, ISO/IEC 27701:2025 e ISO/IEC 29151:2022 | Relevância para NIS2 | Relevância para DORA | Perspetiva de auditoria NIST e COBIT 2019 |
|---|---|---|---|---|---|
| Inventário de PII e registo de tratamento | Responsabilização, fundamento de licitude, limitação da finalidade, limitação da conservação | Contexto do SGSI, 5.9 inventário de ativos, gestão da informação de privacidade, proteção de PII | Gestão de ativos e análise de riscos | Conhecimento de ativos de TIC e dependências de serviços | Evidência da função Identificar e governação sobre ativos de informação |
| Direitos de acesso e princípio do menor privilégio | Integridade e confidencialidade, acesso limitado por função | 5.15 controlo de acesso, 5.16 gestão de identidades, 5.18 direitos de acesso, 8.2 direitos de acesso privilegiado | Controlo de acesso, segurança de recursos humanos, autenticação | Controlos de risco das TIC e supervisão de acessos privilegiados | Aplicação de acesso, propriedade, responsabilização e monitorização |
| Mascaramento e pseudonimização | Minimização de dados, proteção de dados desde a conceção, segurança do tratamento | 5.12 classificação, 5.34 proteção de PII, 8.11 mascaramento de dados, 8.33 informação de teste | Higiene de cibersegurança e desenvolvimento seguro | Testes seguros, redução de perda de dados, resiliência operacional | Testes de salvaguardas técnicas e operação fiável dos controlos |
| Classificação e reporte de incidentes | Avaliação e notificação de violação de dados pessoais | Planeamento de incidentes, avaliação de eventos, resposta, recolha de evidência | Alerta precoce de 24 horas, notificação de 72 horas, relatório final | Classificação e reporte de incidentes graves relacionados com as TIC | Critérios de escalonamento, logs de decisão, análise de causa raiz, remediação |
| Tratamento por fornecedores e na nuvem | Obrigações de subcontratantes, transferências, contratos | 5.21 cadeia de fornecimento de TIC, 5.23 serviços na nuvem, 5.31 requisitos legais e contratuais | Segurança da cadeia de fornecimento | Risco de terceiros de TIC, direitos de auditoria, saída e transição | Governação de terceiros, garantia e responsabilização da gestão |
É aqui que o Zenith Controls é especialmente útil. Para o 5.34, mapeia a proteção de PII para inventário de ativos, mascaramento de dados e governação da nuvem. Para o 8.11, mapeia o mascaramento para classificação, proteção da privacidade e informação de teste. Para o 5.18, mapeia direitos de acesso para controlo de acesso, gestão de identidades e acesso privilegiado. Estas relações permitem a uma equipa explicar não apenas que um controlo existe, mas por que razão existe e que controlos adjacentes devem operar com ele.
Como diferentes auditores testam o mesmo controlo de PII
Um único controlo, como o 8.11 mascaramento de dados, será examinado de forma diferente consoante a perspetiva de auditoria.
| Tipo de auditor | Foco principal | Evidência esperada |
|---|---|---|
| Auditor ISO/IEC 27001:2022 e ISO/IEC 27701:2025 | Integração SGSI e PIMS, tratamento de riscos, exatidão da SoA | Avaliação de riscos, entrada na SoA, política de mascaramento, registos de alterações, resultados de auditoria interna |
| Revisor do RGPD ou autoridade de proteção de dados | Proteção de dados desde a conceção, minimização, responsabilização | Registo de tratamento, fundamento de licitude, AIPD, evidência de pseudonimização, lógica de retenção |
| Avaliador NIS2 | Desenvolvimento seguro, prevenção de incidentes, governação | Procedimento de desenvolvimento seguro, formação de programadores, evidência de remediação de incidentes, revisão da eficácia dos controlos |
| Cliente ou auditor DORA | Resiliência operacional das TIC e risco de terceiros | Evidência de testes de aplicações críticas, cláusulas contratuais com fornecedores, obrigações de apoio a incidentes, planeamento de recuperação e saída |
| Revisor alinhado com NIST ou COBIT 2019 | Desenho, operação, propriedade e monitorização de controlos | Proprietário do controlo, métricas, repositório de evidência, reporte à gestão, ações corretivas |
Um auditor ISO/IEC 27001:2022 começa pela lógica do sistema de gestão. A PII está dentro do âmbito? Os requisitos das partes interessadas estão identificados? Os riscos de privacidade são avaliados com critérios definidos? Os controlos são selecionados através do tratamento de riscos? A SoA está correta? As auditorias internas e as revisões pela gestão abrangem controlos relacionados com PII?
Um revisor de privacidade começa pela responsabilização. Que dados pessoais são tratados? Qual é o fundamento de licitude? Os titulares dos dados são informados? O tratamento está limitado a uma finalidade específica? As atividades de alto risco são avaliadas? Os subcontratantes são governados?
Um avaliador focado na NIS2 começa pela governação e pela gestão de riscos de cibersegurança. A gestão aprova e supervisiona as medidas? O tratamento de incidentes, a continuidade, a segurança de fornecedores, o controlo de acesso, a gestão de ativos, o desenvolvimento seguro e a avaliação da eficácia dos controlos estão integrados?
Um cliente ou auditor DORA pergunta se a gestão do risco das TIC está documentada, governada pelo Conselho de Administração, é proporcional e suportada por contratos. Se a PII for tratada em serviços que suportam entidades financeiras, conte com perguntas sobre assistência em incidentes, localizações de tratamento de dados, recuperação, direitos de auditoria, níveis de serviço, cessação e saída.
Um revisor COBIT 2019 ou alinhado com ISACA testa o alinhamento de governação. Quem é o proprietário do risco de PII? Que órgão de governação recebe reporte? As responsabilidades estão atribuídas? Os fornecedores são monitorizados? Os desvios são acompanhados? As métricas são usadas na tomada de decisão? O risco residual é formalmente aceite?
Um único modelo de evidência pode satisfazer todas estas perspetivas, mas apenas se o sistema de controlos for concebido para rastreabilidade desde o início.
Constatações de auditoria comuns em programas de proteção de PII
As organizações que abordam a preparação para ISO/IEC 27701:2025 ou ISO/IEC 29151:2022 sem um conjunto integrado de ferramentas veem frequentemente as mesmas constatações.
| Constatação | Porque é importante | Remediação Clarysec |
|---|---|---|
| O inventário de PII exclui logs, cópias de segurança, exportações de análise ou anexos de suporte | A PII oculta não pode ser protegida nem eliminada de forma fiável | Expandir o inventário de ativos do Step 9 e o registo de tratamento para incluir todas as localizações de PII |
| Os ambientes de teste usam dados de produção | A PII real é exposta onde não é necessária | Aplicar a política de mascaramento e modelos de transformação aprovados |
| As revisões de acessos são genéricas e não se focam em repositórios de PII | O acesso excessivo permanece por detetar | Mapear 5.18 direitos de acesso para proprietários de ativos de PII e evidência de revisão periódica |
| O fundamento de licitude está documentado, mas não ligado a sistemas ou retenção | A responsabilização do RGPD não pode ser demonstrada | Acrescentar campos de fundamento de licitude e retenção ao registo de tratamento e ao inventário de ativos |
| Os contratos com fornecedores não incluem localização dos dados, assistência em incidentes, direitos de auditoria ou disposições de saída | Mantêm-se lacunas de garantia de fornecedores no âmbito da DORA, NIS2 e RGPD | Alinhar a devida diligência de fornecedores e contratos com a governação de terceiros de TIC e serviços na nuvem |
| Os playbooks de incidentes não distinguem incidentes de segurança de violações de dados pessoais | Os prazos de reporte podem ser falhados | Construir árvores de classificação para desencadeadores de reporte do RGPD, NIS2 e DORA |
| A evidência está dispersa por tickets, unidades, capturas de ecrã e correio eletrónico | A preparação para auditoria falha mesmo quando os controlos operam | Utilizar pastas centralizadas de auditoria e normas de nomenclatura de evidência |
Estas constatações não são problemas de documentação. São problemas de modelo operacional. A ISO/IEC 27701:2025 e a ISO/IEC 29151:2022 não os corrigirão se a governação da privacidade, os controlos de segurança e a gestão de evidência não forem incorporados nos fluxos de trabalho normais.
O que a gestão deve perguntar antes da próxima auditoria
Antes de procurar preparação para ISO/IEC 27701:2025, implementação da ISO/IEC 29151:2022 ou uma avaliação de cliente no âmbito do RGPD, NIS2 ou DORA, a gestão deve colocar dez perguntas diretas:
- Temos um registo completo das atividades de tratamento de PII, incluindo categorias de dados, finalidade, fundamento de licitude e retenção?
- Os ativos de PII estão sinalizados no inventário de ativos, incluindo logs, cópias de segurança, exportações, ferramentas de análise e anexos de suporte?
- As classificações de dados são atribuídas no momento da criação ou integração, com ativos não revistos a assumirem por defeito a classificação Confidencial?
- Conseguimos demonstrar que o acesso a PII está limitado a utilizadores autorizados com necessidade de conhecer?
- Os ambientes de desenvolvimento, teste e pré-produção utilizam dados mascarados ou pseudonimizados em vez de dados pessoais reais?
- Os modelos de mascaramento estão aprovados, e as chaves estão protegidas, sujeitas a controlo de acesso e registadas?
- A SoA liga os riscos de PII a controlos e obrigações regulamentares?
- Os contratos com fornecedores e serviços na nuvem são revistos quanto a localização dos dados, segurança, apoio a incidentes, direitos de auditoria, recuperação e saída?
- O nosso processo de incidentes consegue classificar violações de dados pessoais ao abrigo do RGPD, incidentes significativos NIS2 e incidentes graves relacionados com as TIC ao abrigo da DORA?
- A evidência é armazenada centralmente e retida de uma forma que um auditor consiga seguir?
Se a resposta a qualquer uma destas perguntas for pouco clara, a organização ainda não está preparada para auditoria.
Tornar a proteção de PII demonstrável
O incidente noturno da Sarah poderia ter-se transformado numa corrida fragmentada de conformidade. Em vez disso, pode tornar-se o ponto de partida para um modelo operacional mais forte: um SGSI ISO/IEC 27001:2022 alargado à privacidade através da ISO/IEC 27701:2025, reforçado por práticas da ISO/IEC 29151:2022 e mapeado para o RGPD, NIS2, DORA, garantia alinhada com NIST e expectativas de governação do COBIT 2019.
Esse é o verdadeiro valor da proteção de PII preparada para auditoria. Não depende de encontrar a folha de cálculo certa antes da chegada do auditor. Depende de um sistema que já sabe onde está a PII, porque existe, como é protegida, quem é responsabilizável, que fornecedores estão envolvidos e onde reside a evidência.
Comece com Zenith Blueprint: roteiro de 30 passos para auditores Zenith Blueprint para estruturar a sua implementação. Utilize Zenith Controls: guia de conformidade transversal Zenith Controls para mapear a proteção de PII entre ISO/IEC 27001:2022, RGPD, NIS2, DORA, garantia alinhada com NIST e expectativas de governação do COBIT 2019. Operacionalize o trabalho com políticas da Clarysec, incluindo a Política de proteção de dados e privacidade Política de proteção de dados e privacidade, a Política de Mascaramento de Dados e Pseudonimização Política de Mascaramento de Dados e Pseudonimização, a Política de Classificação e Rotulagem da Informação Política de Classificação e Rotulagem da Informação, a Política de Auditoria e Monitorização da Conformidade para PME Política de Auditoria e Monitorização da Conformidade - PME e a Política de Segurança da Informação Política de Segurança da Informação.
Se a sua próxima auditoria de cliente, revisão do RGPD, projeto de preparação NIS2 ou avaliação de fornecedor DORA se aproxima, não espere por uma violação para revelar as lacunas. Descarregue os kits de ferramentas da Clarysec, solicite uma demonstração ou agende uma avaliação de proteção de PII e construa um programa de privacidade que não seja apenas conforme, mas defensável.
Frequently Asked Questions
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
