Plano de transição para ISO/IEC 27701:2025 no âmbito PIMS alinhado com o RGPD da UE

A pergunta do conselho de administração que expõe uma lacuna de evidência de privacidade
Anya, Diretora de Segurança da Informação de uma FinTech em rápida expansão, olhava para a agenda da reunião do conselho de administração. Entre projeções de receita e expansão de mercado estava o ponto que consumira a sua semana: conformidade com o RGPD da UE e preparação para a ISO/IEC 27701:2025.
A empresa tinha um programa de conformidade com o RGPD da UE. Havia um EPD, avisos de privacidade, acordos de tratamento de dados, um modelo de AIPD e um processo para pedidos dos titulares dos dados (DSR). A área comercial já tinha informado clientes empresariais de que a empresa estava a avançar para um Sistema de Gestão da Informação de Privacidade ISO/IEC 27701:2025, ou PIMS. A equipa de produto preparava uma funcionalidade de análise assistida por IA que trataria o comportamento de utilizadores de clientes, pedidos de suporte, metadados de faturação e atividade de conta. Um cliente importante da UE tinha solicitado evidência de que as obrigações de responsável pelo tratamento e de subcontratante eram geridas separadamente.
A verdade desconfortável não era a falta de documentação de privacidade. O problema era a evidência.
O registo das atividades de tratamento não demonstrava de forma consistente o fundamento de licitude, a retenção, as dependências de subcontratantes ulteriores, as transferências internacionais ou se a empresa atuava como responsável pelo tratamento ou subcontratante para cada finalidade de tratamento. As revisões de fornecedores focavam-se na segurança, mas não suficientemente nas instruções de privacidade, na eliminação, no apoio em caso de violação de dados pessoais, nos direitos de auditoria e nas obrigações em cadeia relativas a subcontratantes ulteriores. A engenharia tinha revisões de segurança, mas a proteção de dados desde a conceção nem sempre era acionada quando uma funcionalidade alterava a finalidade do tratamento. A auditoria interna testava o RGPD da UE a alto nível, mas nem sempre conseguia rastrear uma obrigação até um responsável, controlo, registo, teste e decisão de revisão pela gestão.
Este é o verdadeiro desafio da transição para ISO/IEC 27701:2025. Não é apenas um projeto de certificação. É um teste de maturidade: a sua organização consegue operar a privacidade como um sistema gerido, e não como uma pasta de documentos jurídicos?
Para organizações orientadas pelo RGPD da UE, a resposta é estender o Sistema de Gestão de Segurança da Informação ISO/IEC 27001:2022 a um sistema de gestão da privacidade que integre o âmbito PIMS, os registos das atividades de tratamento, a avaliação de riscos de privacidade, as AIPD, a governação de fornecedores, a gestão de violações de dados pessoais, o mapeamento de controlos, a auditoria interna e a melhoria contínua.
Porque é que a conformidade fragmentada com o RGPD da UE falha sob pressão de auditoria
Muitas organizações tratam a conformidade em matéria de privacidade como uma frente de trabalho separada da segurança da informação. O departamento jurídico gere contratos. A TI gere a cifragem. A área de compras gere fornecedores. O EPD responde a pedidos de acesso dos titulares dos dados. As equipas de produto lançam funcionalidades. A segurança gere incidentes. Cada função pode estar a realizar trabalho útil, mas, sem um modelo operacional único, a evidência de privacidade torna-se fragmentada.
Isto cria quatro problemas recorrentes.
Primeiro, as equipas duplicam esforços. As avaliações de riscos de segurança e de privacidade podem usar métodos diferentes, pontuações diferentes e responsáveis diferentes.
Segundo, surgem lacunas em serviços de terceiros, configurações de nuvem, cadeias de processamento analítico, ferramentas de suporte e novos projetos de desenvolvimento porque ninguém tem uma visão completa dos fluxos de informação pessoal identificável (PII).
Terceiro, torna-se difícil prestar garantia ao conselho de administração e aos clientes. Um conjunto de políticas desconexas não demonstra que as obrigações de privacidade estão implementadas, monitorizadas e melhoradas.
Quarto, as expectativas regulamentares modernas estão a convergir. O RGPD da UE exige responsabilização e evidência. A NIS2 exige governação, gestão de riscos, gestão de incidentes, controlo de acesso, gestão de ativos e segurança da cadeia de fornecimento. A DORA exige que as entidades financeiras façam a gestão do risco das TIC, de incidentes, de testes de resiliência, de contratos com terceiros e de estratégias de saída. Um programa de privacidade em silo não consegue suportar tudo isto de forma eficiente.
A abordagem mais robusta consiste em construir a transição para ISO/IEC 27701:2025 sobre o SGSI ISO/IEC 27001:2022. A ISO/IEC 27001:2022 fornece a estrutura de sistema de gestão para contexto, partes interessadas, âmbito, avaliação de riscos, tratamento de riscos, objetivos, planeamento e controlo operacional, auditoria interna, revisão pela gestão, ação corretiva e melhoria contínua. A ISO/IEC 27002:2022 fornece a base de controlos para obrigações legais, inventário de ativos, relações com fornecedores, serviços na nuvem, controlo de acesso, registo de eventos, monitorização, eliminação, mascaramento e privacidade e proteção de informação pessoal identificável (PII).
A transição deve responder a cinco perguntas:
- Qual é o âmbito PIMS, incluindo os papéis de responsável pelo tratamento, subcontratante, corresponsável pelo tratamento e subcontratante ulterior?
- Que atividades de tratamento, categorias de dados, finalidades, fundamentos de licitude, destinatários, transferências e regras de retenção estão no âmbito?
- Que riscos de privacidade exigem AIPD, tratamento, aprovação e aceitação do risco residual?
- Que políticas, controlos, contratos, salvaguardas técnicas e registos demonstram a responsabilização exigida pelo RGPD da UE?
- Como confirmarão a auditoria interna e a revisão pela gestão que o PIMS está a operar e a melhorar?
Fase 1: aprovar o âmbito PIMS antes de reescrever políticas
Um plano de transição para ISO/IEC 27701:2025 robusto não começa pela reescrita de todas as políticas de privacidade. Começa pela governação e pelo âmbito.
O âmbito do SGSI existente é o ponto de partida, mas o âmbito PIMS deve identificar explicitamente o tratamento de informação pessoal identificável (PII), unidades de negócio, serviços, sistemas, regiões, ambientes de nuvem, fornecedores e papéis de privacidade. O conselho de administração ou a alta direção deve compreender a importância da transição, especialmente quando clientes, reguladores ou obrigações setoriais como a DORA dependem de evidência demonstrável de privacidade e resiliência.
A Política do Sistema de Gestão da Informação de Privacidade da Clarysec [Política PIMS] torna obrigatória a aprovação do âmbito:
[Ambos] A alta direção DEVE aprovar o âmbito PIMS em REG01 antes da implementação inicial do PIMS e no prazo de 30 dias após qualquer alteração material.
Para programas de transição que utilizam a numeração de cláusulas da biblioteca de políticas da Clarysec, esta é a expectativa central da Cláusula 4.1.1. É relevante porque o âmbito de privacidade implícito é uma das fragilidades de auditoria mais comuns. Se uma linha de produto, jurisdição, papel de tratamento, fornecedor, região de nuvem ou processo de negócio se alterar materialmente, o âmbito PIMS não pode ficar sujeito a interpretação.
A mesma política também transforma a transição num programa gerido:
[Ambos] O Responsável pela Privacidade / Gestor do PIMS DEVE registar o plano de implementação do PIMS em REG12 antes da implementação do PIMS ou de uma alteração PIMS significativa.
REG12 não é sobrecarga administrativa. É o painel de controlo da transição. Deve demonstrar o que está a mudar, porque é relevante, quem é responsável, que evidência é necessária, que riscos permanecem em aberto e quando a preparação será testada.
Fase 2: construir um inventário de transição orientado por registos
Para sistemas de gestão da privacidade baseados no RGPD da UE, o primeiro entregável prático deve ser um inventário de evidência, não a reescrita de políticas. A Clarysec utiliza uma abordagem orientada por registos porque os registos convertem a intenção de privacidade em evidência auditável.
O âmbito PIMS em REG01 liga-se às atividades de tratamento em REG02, à aplicabilidade de controlos em REG03, à triagem de riscos de privacidade e AIPD em REG04 e ao planeamento de implementação em REG12.
A Política de proteção de dados e privacidade - PME da Clarysec [Política de Privacidade para PME] define a linha de base:
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.
Para ambientes de maior dimensão, a Política de proteção de dados e privacidade [P17 Política de proteção de dados e privacidade] eleva a expectativa de governação:
A organização deve manter um quadro formal de governação da privacidade integrado no Sistema de Gestão de Segurança da Informação (SGSI) para aplicar esta política.
Essa integração é o princípio da transição. Um registo de tratamento sem tratamento de riscos é uma folha de cálculo. Uma AIPD sem responsabilidade atribuída pelos controlos é um parecer jurídico. Um acordo de tratamento de dados com fornecedor sem monitorização é uma pasta contratual. O trabalho de transição para ISO/IEC 27701:2025 deve integrar estes artefactos num PIMS governado.
| Item de transição | Evidência a recolher | Artefacto Clarysec |
|---|---|---|
| Âmbito PIMS | Unidades de negócio, sistemas, regiões, papéis de tratamento, exclusões, dependências | REG01 Âmbito PIMS |
| Atividades de tratamento | Finalidade, fundamento de licitude, categorias de dados, titulares dos dados, retenção, destinatários, transferências | REG02 Registo das Atividades de Tratamento |
| Aplicabilidade de controlos | Controlos incluídos, controlos excluídos, estado de implementação, justificação | REG03 Aplicabilidade de Controlos PIMS |
| Desencadeadores de AIPD | Tratamento de alto risco, novas finalidades, categorias especiais de dados, monitorização, decisões automatizadas | REG04 Triagem de Riscos de Privacidade e AIPD |
| Plano de transição | Responsáveis, marcos, calendário de auditoria, entradas para revisão pela gestão, ações de remediação | REG12 Plano de Implementação do PIMS |
Este inventário também suporta um Perfil Atual e um Perfil-Alvo ao estilo do NIST Cybersecurity Framework 2.0. O Perfil Atual documenta processos, controlos e evidência de privacidade existentes. O Perfil-Alvo define o PIMS pretendido, alinhado com a ISO/IEC 27701:2025. A lacuna entre ambos torna-se a carteira de ações de transição.
Fase 3: mapear a responsabilização do RGPD da UE para o PIMS
A responsabilização do RGPD da UE é a espinha dorsal da evidência de privacidade. O RGPD da UE aplica-se ao tratamento no contexto de um estabelecimento na UE e também pode aplicar-se a responsáveis pelo tratamento ou subcontratantes fora da UE que ofereçam bens ou serviços a pessoas na UE ou monitorizem o seu comportamento. Define dados pessoais de forma ampla, incluindo identificadores diretos e indiretos. Distingue responsáveis pelo tratamento de subcontratantes e define uma violação de dados pessoais como uma violação da segurança que provoque, de modo acidental ou ilícito, a destruição, perda, alteração, divulgação não autorizada de dados pessoais ou o acesso não autorizado aos mesmos.
Para o planeamento da transição, o ponto essencial é que o RGPD da UE não fica satisfeito com a afirmação “temos controlos de segurança”. O Article 5 exige tratamento lícito, leal e transparente, limitação das finalidades, minimização dos dados, exatidão, limitação da conservação, integridade e confidencialidade, e responsabilização demonstrável. O Article 6 exige um fundamento de licitude. O Article 9 acrescenta condições mais rigorosas para categorias especiais de dados pessoais. O Article 25 exige proteção de dados desde a conceção e por defeito. O Article 28 exige governação de subcontratantes. O Article 32 exige segurança do tratamento.
A Política de Cumprimento Legal e Regulamentar - PME da Clarysec [Política de Conformidade Legal e Regulamentar para PME] oferece às organizações mais pequenas um ponto de partida simples:
O Diretor-Geral deve manter um Registo de Conformidade simples e estruturado que liste:
A Política de Cumprimento Legal e Regulamentar empresarial [P37 Política de Conformidade Legal e Regulamentar] é mais explícita:
Todas as obrigações legais e regulamentares devem ser mapeadas para políticas, controlos e responsáveis específicos no Sistema de Gestão de Segurança da Informação (SGSI).
Essa frase é a diferença entre conformidade informal com o RGPD da UE e gestão da privacidade pronta para auditoria. Cada obrigação material do RGPD da UE deve mapear para uma política, controlo, responsável, campo de registo e fonte de evidência.
| Área de obrigação do RGPD da UE | Evidência de transição PIMS | Responsável operacional |
|---|---|---|
| Fundamento de licitude e limitação da finalidade | Registo das atividades de tratamento REG02 com finalidade, fundamento de licitude, papel e data de revisão | Responsável pela Privacidade e proprietário do processo |
| Privacidade desde a conceção e por defeito | Lista de verificação de entrada de alterações, triagem de AIPD, revisão da arquitetura de segurança, registo de aprovação | Proprietário do produto e arquiteto de segurança |
| Governação de subcontratantes | Acordo de tratamento de dados, avaliação de riscos de fornecedor, lista de subcontratantes ulteriores, direitos de auditoria, cláusula de apoio em caso de violação | Compras e Jurídico |
| Direitos dos titulares dos dados | Registo de pedidos, registo de verificação de identidade, evidência de cumprimento, decisões de exceção | Operações de Privacidade |
| Gestão de violações de dados pessoais | Registo de incidente, avaliação de severidade, decisão de notificação, lições aprendidas | Gestor de Incidentes e EPD |
| Retenção e eliminação | Calendário de retenção, evidência de eliminação, aprovação de exceção | Proprietário dos dados e Operações de TI |
A evidência de responsável pelo tratamento e de subcontratante deve ser separada. Um responsável pelo tratamento deve demonstrar fundamento de licitude, transparência, gestão de direitos, decisões sobre finalidades e retenção. Um subcontratante deve demonstrar tratamento com base em instruções documentadas, governação de subcontratantes ulteriores, assistência ao responsável pelo tratamento, medidas de segurança, apoio à notificação de violações e devolução ou eliminação no fim do serviço. Se a organização atuar em ambos os papéis, um modelo genérico de evidência não é suficiente.
Fase 4: utilizar a SoA como ponte de controlos de privacidade
Um erro comum na transição é criar uma folha de cálculo autónoma de controlos PIMS, deixando intocada a Declaração de Aplicabilidade do SGSI. Isso cria dois universos de controlo concorrentes.
A ISO/IEC 27001:2022 exige que as decisões de tratamento de riscos sejam refletidas na Declaração de Aplicabilidade. A Política de Gestão de Riscos da Clarysec [Política de Gestão de Riscos] estabelece:
Uma Declaração de Aplicabilidade (SoA) deve refletir todas as decisões de tratamento e deve ser atualizada sempre que a cobertura de controlos for modificada.
Para a transição para ISO/IEC 27701:2025, a SoA torna-se a ponte entre o SGSI e o PIMS. Se uma AIPD ou o tratamento de riscos de privacidade acrescentar cifragem, mascaramento de dados, controlos de eliminação, mecanismos de consentimento, diligência prévia de subcontratantes, restrições de acesso ou monitorização do fluxo de trabalho de DSR, a SoA e REG03 devem refletir a decisão.
O Zenith Blueprint: roteiro de 30 passos para auditores [Zenith Blueprint] reforça isto no Passo 6:
✓ Controlos adicionais: Existem controlos fora do Anexo A que poderia incluir? A ISO 27001
permite acrescentar outros controlos na SoA. Por exemplo, poderá querer incluir
conformidade com o NIST CSF ou controlos específicos de privacidade da ISO 27701.
Não force obrigações de privacidade em controlos que não se ajustam. Acrescente controlos específicos de privacidade quando necessário, mas governe-os através do mesmo modelo de tratamento de riscos, responsabilidade, estado de implementação, evidência e auditoria.
Os controlos ISO/IEC 27002:2022 que ancoram a transição
No Zenith Controls: guia de conformidade transversal [Zenith Controls], dois controlos ISO/IEC 27002:2022 são centrais para a transição para ISO/IEC 27701:2025: 5.31 Requisitos legais, estatutários, regulamentares e contratuais, e 5.34 Privacidade e proteção de informação pessoal identificável (PII).
O controlo 5.31 é o centro de conformidade. Suporta a identificação, documentação, responsabilidade atribuída e revisão de requisitos legais, regulamentares, estatutários e contratuais. Liga-se naturalmente à responsabilização do RGPD da UE, à governação da NIS2, às obrigações de gestão do risco das TIC da DORA, às cláusulas de privacidade de clientes e aos compromissos de tratamento na nuvem.
O controlo 5.34 é a âncora operacional da privacidade. Zenith Controls explica claramente a dependência:
Um inventário de ativos de informação (5.9) deve incluir conjuntos de informação pessoal identificável (PII) (bases de dados de clientes, ficheiros de RH). Isto sustenta o 5.34 ao assegurar que a organização sabe que PII tem e onde estão, o que constitui o primeiro passo para as proteger.
A matriz de correspondência de controlos deve ser utilizada como lista de verificação prática de conceção.
| Controlo ISO/IEC 27002:2022 | Relevância da transição para PIMS do RGPD da UE |
|---|---|
| 5.9 Inventário de informação e outros ativos associados | Identifica repositórios de PII, sistemas, responsáveis e fluxos de dados |
| 5.12 Classificação da informação | Classifica PII e categorias especiais de dados para aplicar controlos mais robustos |
| 5.14 Transferência de informação | Controla a transferência interna e externa de dados pessoais |
| 5.15 Controlo de acesso | Aplica o princípio da necessidade de conhecer no acesso a PII |
| 5.16 Gestão de identidades | Assegura que as identidades com acesso a PII são governadas e rastreáveis |
| 5.19 Segurança da informação nas relações com fornecedores | Suporta privacidade de fornecedores, garantia de subcontratantes e monitorização de terceiros |
| 5.20 Tratamento da segurança da informação nos acordos com fornecedores | Incorpora requisitos de segurança e privacidade nos contratos |
| 5.21 Gestão da segurança da informação na cadeia de fornecimento das TIC | Suporta a governação de subcontratantes ulteriores e dependências de TIC |
| 5.23 Segurança da informação na utilização de serviços na nuvem | Assegura que os prestadores de serviços na nuvem cumprem expectativas de privacidade, localização, eliminação e contrato |
| 5.31 Requisitos legais, estatutários, regulamentares e contratuais | Mapeia obrigações do RGPD da UE, DORA, NIS2, clientes e contratos |
| 5.33 Proteção de registos | Suporta retenção, integridade e proteção dos registos de evidência |
| 5.34 Privacidade e proteção de PII | Ancora controlos de privacidade em todo o ciclo de vida das PII |
| 5.35 Revisão independente da segurança da informação | Suporta auditoria interna e garantia externa |
| 5.36 Cumprimento de políticas, regras e normas de segurança da informação | Testa se os controlos de privacidade são seguidos |
| 5.8 Segurança da informação na gestão de projetos | Incorpora privacidade e segurança na governação de projetos |
| 8.10 Eliminação de informação | Suporta a limitação da conservação e os compromissos de eliminação |
| 8.11 Mascaramento de dados | Protege PII em casos de utilização de ambientes não produtivos e análise |
| 8.15 Registo de eventos | Fornece evidência de acesso e atividade envolvendo PII |
| 8.16 Atividades de monitorização | Deteta atividade suspeita e suporta a investigação de incidentes |
| 8.32 Gestão de alterações | Assegura que o impacto na privacidade é revisto antes de alterações em produção |
É aqui que a privacidade se torna operacional. Para cada atividade de tratamento de alto risco, pergunte: que ativos contêm as PII, como estão classificados, quem lhes pode aceder, para onde são transferidos, que serviços na nuvem os tratam, que regra de retenção se aplica, que monitorização deteta utilização indevida e que evidência demonstra que esses controlos operam?
Exemplo de fluxo de trabalho: integração de uma funcionalidade de análise assistida por IA
Regressemos à FinTech de Anya. A equipa de produto pretende lançar uma funcionalidade de análise assistida por IA que trata identificadores de utilizadores, atividade de conta, metadados de suporte, metadados de faturação e sinais comportamentais. Alguns clientes empresariais poderão utilizar os resultados para monitorização de trabalhadores, o que aumenta o risco de privacidade.
Um fluxo de trabalho de transição PIMS deve tratar o lançamento como um evento de privacidade controlado.
Passo 1: atualizar REG02 para papéis e finalidades do tratamento
O proprietário do processo cria ou atualiza o registo das atividades de tratamento. Os campos obrigatórios incluem finalidade, categorias de dados, categorias de titulares dos dados, fundamento de licitude ou instrução do subcontratante, prazo de retenção, sistemas, fornecedores, destinatários, transferências e contexto do papel.
Se a empresa for subcontratante para análises de clientes, REG02 deve demonstrar tratamento com base nas instruções do cliente. Se também utilizar dados agregados para melhorar o seu próprio produto, essa finalidade separada pode torná-la responsável pelo tratamento secundário. O registo não deve confundir os papéis.
Passo 2: concluir a triagem REG04
A Política de Avaliação de Riscos de Privacidade e AIPD da Clarysec [Política de Avaliação de Riscos de Privacidade e AIPD] exige:
[Ambos] O proprietário do processo / proprietário do negócio DEVE concluir a triagem REG04 de referência para todas as atividades de tratamento REG02 ativas dentro do âmbito no prazo de 30 dias úteis após a aprovação ou expansão do âmbito PIMS.
A triagem deve identificar monitorização, definição de perfis, categorias especiais de dados, pessoas vulneráveis, nova tecnologia, tratamento em larga escala, transferências transfronteiriças ou alteração da finalidade. Se os limiares forem atingidos, é desencadeada uma AIPD.
Passo 3: realizar a AIPD e definir o tratamento
A P17 Política de proteção de dados e privacidade exige:
Todas as alterações significativas a sistemas ou processos que envolvam informações pessoais (PII) devem exigir uma Avaliação de Impacto sobre a Proteção de Dados (AIPD) documentada, revista pelo Encarregado da Proteção de Dados (EPD).
Na biblioteca Clarysec, isto está ligado à Cláusula 5.6. A AIPD deve avaliar riscos como recolha excessiva, finalidade pouco clara, reidentificação, acesso não autorizado por administradores de clientes, retenção pouco clara e exposição a subcontratantes ulteriores. Os tratamentos podem incluir minimização ao nível dos campos, pseudonimização, controlos de configuração pelo cliente, definições de retenção por defeito, registo de auditoria mais robusto, atualizações do acordo de tratamento de dados, avisos do produto e restrições ao treino de modelos.
Passo 4: atualizar REG03 e a SoA
A Política PIMS exige:
[Ambos] O Responsável pela Privacidade / Gestor do PIMS DEVE manter REG03 com controlos incluídos, controlos excluídos, estado de implementação e justificação anualmente e no prazo de 30 dias após cada alteração de tratamento de riscos de privacidade.
Se a AIPD acrescentar mascaramento para análises em ambientes não produtivos, registo de eventos para acesso de administradores, controlos de eliminação, cláusulas de fornecedores ou salvaguardas de configuração pelo cliente, REG03 e a SoA devem ser atualizados.
Passo 5: demonstrar privacidade desde a conceção
A Política de Privacidade para PME enuncia o princípio de forma clara:
A privacidade desde a conceção e por defeito deve ser aplicada em todos os novos sistemas e serviços.
A evidência deve incluir a AIPD, a revisão da arquitetura de segurança, a decisão de minimização de dados, o modelo de acesso, a configuração de registo de eventos, a definição de retenção, os resultados dos testes, a aprovação de lançamento e a revisão pós-lançamento. Isto transforma o lançamento da funcionalidade em evidência PIMS reutilizável.
Governação da privacidade de fornecedores num mundo DORA e NIS2
A governação da privacidade de fornecedores é onde muitas transições falham. O Article 28 do RGPD da UE exige que os responsáveis pelo tratamento utilizem subcontratantes que apresentem garantias suficientes e que formalizem obrigações de subcontratante em contratos escritos. Os Articles 28 a 30 da DORA exigem que as entidades financeiras façam a gestão do risco de terceiros de TIC, mantenham registos de acordos contratuais, realizem diligência prévia, incluam direitos de auditoria e cláusulas de saída, giram a subcontratação e tratem funções críticas ou importantes. O Article 21 da NIS2 exige medidas de segurança da cadeia de fornecimento, incluindo a consideração de vulnerabilidades dos fornecedores, práticas de cibersegurança e procedimentos de desenvolvimento seguro.
O controlo 5.19 da ISO/IEC 27002:2022, Segurança da informação nas relações com fornecedores, é a âncora operacional. Zenith Controls mapeia esta área para acordos com fornecedores, segurança da cadeia de fornecimento das TIC, transferência de informação, monitorização contínua da conformidade, utilização aceitável, obrigações de subcontratantes ao abrigo do RGPD da UE, cibersegurança da cadeia de fornecimento NIS2, risco de terceiros de TIC DORA, governação de fornecedores NIST e gestão de fornecedores COBIT.
| Categoria de fornecedor | Evidência de privacidade necessária |
|---|---|
| Subcontratante que trata PII de clientes | Acordo de tratamento de dados, instruções, medidas técnicas e organizativas, lista de subcontratantes ulteriores, apoio à notificação de violação, direitos de auditoria |
| Subcontratante ulterior na cadeia de prestação SaaS | Obrigações em cadeia, localização, mecanismo de transferência, compromisso de eliminação, notificação de alterações |
| Prestador de alojamento na nuvem | Seleção de região, cifragem, controlos de acesso, assistência em incidentes, termos de eliminação e devolução |
| Prestador de ferramenta de suporte | Restrição de acesso, redação de pedidos de suporte, retenção, registo de eventos, confidencialidade do pessoal de suporte |
| Prestador de análise ou IA | Limitação da finalidade, restrição de treino de modelos, pseudonimização, mecanismos de oposição ou controlos de configuração |
Para entidades financeiras reguladas pela DORA, esta evidência deve ligar-se aos registos de terceiros de TIC e às avaliações de funções críticas ou importantes. Para entidades NIS2, os mesmos registos de fornecedores suportam a gestão de riscos da cadeia de fornecimento. Para o NIST CSF 2.0, a governação de fornecedores alinha com a função GOVERN, especialmente os resultados de gestão de riscos da cadeia de fornecimento. Para COBIT 2019, a governação de fornecedores alinha com objetivos como APO10 Managed Vendors e controlos operacionais DSS relacionados com fornecedores.
A preparação para incidentes e violações deve estar integrada
Os planos de transição de privacidade tendem a focar-se demasiado na documentação e insuficientemente na gestão de violações de dados pessoais. Isto é perigoso porque o RGPD da UE, a NIS2 e a DORA exigem processos de incidente disciplinados, ainda que os limiares e os prazos de reporte sejam diferentes.
O RGPD da UE exige a avaliação de se um evento de segurança causou uma violação de dados pessoais e se é necessária notificação à autoridade de controlo ou às pessoas afetadas. A NIS2 estabelece reporte faseado para incidentes significativos, incluindo alerta precoce no prazo de 24 horas, notificação no prazo de 72 horas e relatório final no prazo de um mês. A DORA exige que as entidades financeiras detetem, giram, classifiquem, registem, notifiquem, respondam e aprendam com incidentes relacionados com TIC, com reporte faseado para incidentes graves.
| Evidência de incidente | Finalidade no RGPD da UE | Finalidade na NIS2 ou DORA |
|---|---|---|
| Registo de classificação do incidente | Determina se ocorreu uma violação de dados pessoais | Determina a classificação como incidente significativo ou incidente grave de TIC |
| Avaliação de impacto nos dados | Identifica titulares dos dados afetados e risco para direitos e liberdades | Suporta o reporte de severidade e impacto |
| Registo cronológico | Demonstra hora de conhecimento, escalonamento, decisões e momento da notificação | Suporta reporte faseado e comunicação com reguladores |
| Análise de causa raiz | Suporta remediação e responsabilização | Suporta o reporte final e a melhoria da resiliência |
| Lições aprendidas | Atualiza AIPD, controlos, formação e supervisão de fornecedores | Alimenta testes, auditoria e revisão pela gestão |
O NIST CSF 2.0 suporta este ciclo através dos resultados Detect, Respond, Recover e Govern. A equipa de transição deve assegurar que as decisões sobre violações de privacidade estão incorporadas no fluxo de trabalho de incidentes de segurança, e não tratadas como uma reflexão jurídica posterior e desconectada.
Um roteiro, muitos resultados de conformidade
A transição para ISO/IEC 27701:2025 torna-se mais valiosa quando reduz trabalho de conformidade duplicado. O Zenith Blueprint, Passo 14, recomenda referências cruzadas entre RGPD da UE, NIS2 e DORA para que as organizações possam demonstrar que o tratamento de riscos e os controlos satisfazem múltiplas obrigações:
Para cada regulamento, se aplicável, pode criar uma tabela simples de mapeamento (que pode ser um
anexo num relatório) que liste os principais requisitos de segurança do regulamento e os
controlos/políticas correspondentes no seu SGSI.
Para o planeamento da transição de privacidade, o mapeamento deve ser prático e orientado por evidência.
| Referencial | O que auditores ou avaliadores esperam | Resposta de transição PIMS |
|---|---|---|
| RGPD da UE | Responsabilização, fundamento de licitude, AIPD, governação de subcontratantes, gestão de violações, apoio a direitos | REG02, REG04, registos de AIPD, registo de acordos de tratamento de dados, registos de decisões sobre violações, evidência de DSR |
| NIS2 | Análise de riscos, gestão de incidentes, continuidade de negócio, segurança da cadeia de fornecimento, controlo de acesso, gestão de ativos | Registo de Riscos do SGSI, níveis de fornecedores, fluxo de trabalho de incidentes, revisão de acessos, inventário de ativos |
| DORA | Quadro de risco de TIC, reporte de incidentes, testes de resiliência, risco de terceiros de TIC, cláusulas contratuais | Registo de dependências de TIC, mapeamento de fornecedores críticos, relatórios de incidente, evidência de testes, planos de saída |
| NIST CSF 2.0 | Governação, obrigações legais e de privacidade, perfis de risco, risco de fornecedores, resultados de resposta e recuperação | Perfis Atual e Alvo, mapeamento de conformidade, monitorização de fornecedores, evidência de resposta e recuperação |
| COBIT 2019 | Governação do programa de privacidade, monitorização da conformidade, acordos com fornecedores, controlos operacionais de privacidade | Reporte ao conselho de administração, Registo de Conformidade, evidência alinhada com APO e DSS, constatações de auditoria interna |
Em Zenith Controls, o controlo 5.31 da ISO/IEC 27002:2022 suporta a rastreabilidade legal e regulamentar entre responsabilização do RGPD da UE, obrigações de conformidade DORA, expectativas de governação NIS2, NIST CSF 2.0 GV.OC-03 e monitorização de conformidade externa COBIT. O controlo 5.34 suporta os Articles 25 e 32 do RGPD da UE, a proteção do ciclo de vida das PII, as expectativas de tratamento de PII na nuvem e os controlos de segurança sensíveis à privacidade.
O resultado não é um modelo simplista de “um controlo equivale a uma lei”. É um modelo de evidência defensável, no qual um conjunto de controlos bem concebido suporta múltiplas necessidades de garantia.
Como os auditores testarão a transição
Um plano de transição robusto antecipa técnicas de auditoria.
Um auditor de sistemas de gestão ISO começará pelo âmbito, partes interessadas, requisitos legais, riscos, objetivos, controlos operacionais, auditorias internas, revisões pela gestão, não conformidades e melhoria. Verificará se o âmbito PIMS está aprovado, se as obrigações de privacidade estão incluídas no Registo de Conformidade, se os controlos estão justificados na SoA e se a evidência de implementação corresponde ao âmbito declarado.
Um auditor de privacidade fará amostragens de registos das atividades de tratamento, AIPD, DSR, decisões sobre violações, contratos de subcontratantes, controlos de retenção e integração de projetos. Não aceitará intenção de política quando faltar evidência operacional.
Um avaliador alinhado com o NIST procurará governação, obrigações legais e contratuais, perfis-alvo, risco de fornecedores, monitorização, resposta e evidência de recuperação.
Um auditor COBIT 2019 focar-se-á na supervisão pelo conselho de administração, no reporte de conformidade, na governação de fornecedores, em papéis e responsabilidades e em saber se o risco de privacidade é gerido em todo o ciclo de vida da informação.
A Política de Monitorização, Auditoria e Melhoria do PIMS da Clarysec [Política de Monitorização, Auditoria e Melhoria do PIMS] torna obrigatório o programa de auditoria:
[Todos] O Revisor de Auditoria Interna / Conformidade DEVE preparar um programa de auditoria interna PIMS baseado no risco em REG12 anualmente antes do primeiro ciclo planeado de auditoria PIMS.
A Política de Auditoria e Monitorização da Conformidade [Política de Auditoria e Monitorização da Conformidade] aplica a mesma disciplina ao nível do SGSI:
Deve ser desenvolvido e aprovado anualmente um Plano de Auditoria baseado no risco, tendo em conta:
Para organizações mais pequenas, a Política de Auditoria e Monitorização da Conformidade - PME [Política de Auditoria e Monitorização da Conformidade para PME] mantém o planeamento da auditoria focado:
O plano deve identificar os principais sistemas e políticas a rever, com foco em:
Durante a transição, a primeira auditoria interna não deve testar tudo. Deve testar os riscos de transição mais elevados: registos das atividades de tratamento incompletos, desencadeadores de AIPD em falta, cláusulas de privacidade de fornecedores fracas, decisões sobre violações não testadas, papéis pouco claros de responsável pelo tratamento e subcontratante, e desalinhamento com a SoA.
Um roteiro prático de 90 dias para a transição ISO/IEC 27701:2025
Um roteiro realista deve ser suficientemente curto para executar e suficientemente estruturado para criar evidência.
| Cronograma | Objetivo da transição | Principais resultados |
|---|---|---|
| Dias 1 a 15 | Estabelecer âmbito e governação | Aprovação REG01, patrocinador, mapa de papéis, atualização do Registo de Conformidade, plano de transição REG12 |
| Dias 16 a 35 | Construir a linha de base de evidência de privacidade | Limpeza REG02, categorias de dados, finalidades, fundamentos de licitude, retenção, sistemas, fornecedores, transferências |
| Dias 36 a 55 | Executar triagem de riscos de privacidade e AIPD | Triagem REG04, desencadeadores de AIPD, decisões de tratamento de riscos, aprovações de risco residual |
| Dias 56 a 70 | Atualizar controlos, contratos e salvaguardas | Atualização REG03, atualização SoA, remediação de acordos de tratamento de dados, acesso, eliminação, mascaramento, registo de eventos, controlos de nuvem |
| Dias 71 a 85 | Testar evidência através de auditoria interna | Auditoria por amostragem de um processo de responsável pelo tratamento, um serviço de subcontratante, um fornecedor, uma AIPD, um DSR, um cenário de violação |
| Dias 86 a 90 | Realizar revisão pela gestão e decidir a preparação | Ações de revisão, questões de fornecedores, incidentes, constatações de auditoria, objetivos de privacidade, decisão de avaliação externa |
A meta de 90 dias não significa que todos os itens de remediação fiquem encerrados. Significa que a liderança deve dispor de um âmbito aprovado, uma linha de base de evidência credível, tratamento de riscos priorizado, resultados de auditoria focados e uma decisão de gestão sobre a preparação.
Tornar a transição orientada por evidência
As organizações que têm sucesso na transição para ISO/IEC 27701:2025 não são as que têm a política de privacidade mais longa. São as que conseguem demonstrar como as obrigações de privacidade passam da lei para o âmbito, do âmbito para os registos das atividades de tratamento, dos registos das atividades de tratamento para a avaliação de riscos, da avaliação de riscos para os controlos, dos controlos para a evidência e da evidência para a melhoria.
A Clarysec ajuda as equipas a tornar essa transição prática. O nosso conjunto de políticas PIMS, mapeamentos do RGPD da UE, registos de evidência de responsável pelo tratamento e subcontratante, fluxos de trabalho de AIPD, modelos de governação da privacidade de fornecedores, materiais de gestão de violações, agendas de revisão pela gestão, Zenith Blueprint e Zenith Controls oferecem a Diretores de Segurança da Informação, EPD, gestores de conformidade, auditores e proprietários do negócio um percurso estruturado desde a intenção de privacidade até à operação pronta para auditoria.
Se a sua organização se está a preparar para a ISO/IEC 27701:2025, comece esta semana com três ações: aprove o âmbito de transição PIMS em REG01, preencha REG02 para o serviço de maior risco e execute a primeira triagem REG04. Em seguida, utilize a Clarysec para transformar esse conjunto de evidências num roteiro completo de transição PIMS alinhado com o RGPD da UE, pronto para clientes, auditores, reguladores e o conselho de administração.
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