⚡ LIMITED TIME Get our FREE €500+ Compliance Starter Kit
Get It Now →

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

Igor Petreski

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:

  1. Qual é o âmbito PIMS, incluindo os papéis de responsável pelo tratamento, subcontratante, corresponsável pelo tratamento e subcontratante ulterior?
  2. Que atividades de tratamento, categorias de dados, finalidades, fundamentos de licitude, destinatários, transferências e regras de retenção estão no âmbito?
  3. Que riscos de privacidade exigem AIPD, tratamento, aprovação e aceitação do risco residual?
  4. Que políticas, controlos, contratos, salvaguardas técnicas e registos demonstram a responsabilização exigida pelo RGPD da UE?
  5. 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çãoEvidência a recolherArtefacto Clarysec
Âmbito PIMSUnidades de negócio, sistemas, regiões, papéis de tratamento, exclusões, dependênciasREG01 Âmbito PIMS
Atividades de tratamentoFinalidade, fundamento de licitude, categorias de dados, titulares dos dados, retenção, destinatários, transferênciasREG02 Registo das Atividades de Tratamento
Aplicabilidade de controlosControlos incluídos, controlos excluídos, estado de implementação, justificaçãoREG03 Aplicabilidade de Controlos PIMS
Desencadeadores de AIPDTratamento de alto risco, novas finalidades, categorias especiais de dados, monitorização, decisões automatizadasREG04 Triagem de Riscos de Privacidade e AIPD
Plano de transiçãoResponsáveis, marcos, calendário de auditoria, entradas para revisão pela gestão, ações de remediaçãoREG12 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 UEEvidência de transição PIMSResponsável operacional
Fundamento de licitude e limitação da finalidadeRegisto das atividades de tratamento REG02 com finalidade, fundamento de licitude, papel e data de revisãoResponsável pela Privacidade e proprietário do processo
Privacidade desde a conceção e por defeitoLista de verificação de entrada de alterações, triagem de AIPD, revisão da arquitetura de segurança, registo de aprovaçãoProprietário do produto e arquiteto de segurança
Governação de subcontratantesAcordo 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çãoCompras e Jurídico
Direitos dos titulares dos dadosRegisto de pedidos, registo de verificação de identidade, evidência de cumprimento, decisões de exceçãoOperações de Privacidade
Gestão de violações de dados pessoaisRegisto de incidente, avaliação de severidade, decisão de notificação, lições aprendidasGestor de Incidentes e EPD
Retenção e eliminaçãoCalendário de retenção, evidência de eliminação, aprovação de exceçãoProprietá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:2022Relevância da transição para PIMS do RGPD da UE
5.9 Inventário de informação e outros ativos associadosIdentifica repositórios de PII, sistemas, responsáveis e fluxos de dados
5.12 Classificação da informaçãoClassifica PII e categorias especiais de dados para aplicar controlos mais robustos
5.14 Transferência de informaçãoControla a transferência interna e externa de dados pessoais
5.15 Controlo de acessoAplica o princípio da necessidade de conhecer no acesso a PII
5.16 Gestão de identidadesAssegura que as identidades com acesso a PII são governadas e rastreáveis
5.19 Segurança da informação nas relações com fornecedoresSuporta privacidade de fornecedores, garantia de subcontratantes e monitorização de terceiros
5.20 Tratamento da segurança da informação nos acordos com fornecedoresIncorpora requisitos de segurança e privacidade nos contratos
5.21 Gestão da segurança da informação na cadeia de fornecimento das TICSuporta 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 nuvemAssegura 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 contratuaisMapeia obrigações do RGPD da UE, DORA, NIS2, clientes e contratos
5.33 Proteção de registosSuporta retenção, integridade e proteção dos registos de evidência
5.34 Privacidade e proteção de PIIAncora controlos de privacidade em todo o ciclo de vida das PII
5.35 Revisão independente da segurança da informaçãoSuporta auditoria interna e garantia externa
5.36 Cumprimento de políticas, regras e normas de segurança da informaçãoTesta se os controlos de privacidade são seguidos
5.8 Segurança da informação na gestão de projetosIncorpora privacidade e segurança na governação de projetos
8.10 Eliminação de informaçãoSuporta a limitação da conservação e os compromissos de eliminação
8.11 Mascaramento de dadosProtege PII em casos de utilização de ambientes não produtivos e análise
8.15 Registo de eventosFornece evidência de acesso e atividade envolvendo PII
8.16 Atividades de monitorizaçãoDeteta atividade suspeita e suporta a investigação de incidentes
8.32 Gestão de alteraçõesAssegura 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 fornecedorEvidência de privacidade necessária
Subcontratante que trata PII de clientesAcordo 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 SaaSObrigações em cadeia, localização, mecanismo de transferência, compromisso de eliminação, notificação de alterações
Prestador de alojamento na nuvemSeleção de região, cifragem, controlos de acesso, assistência em incidentes, termos de eliminação e devolução
Prestador de ferramenta de suporteRestrição de acesso, redação de pedidos de suporte, retenção, registo de eventos, confidencialidade do pessoal de suporte
Prestador de análise ou IALimitaçã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 incidenteFinalidade no RGPD da UEFinalidade na NIS2 ou DORA
Registo de classificação do incidenteDetermina se ocorreu uma violação de dados pessoaisDetermina a classificação como incidente significativo ou incidente grave de TIC
Avaliação de impacto nos dadosIdentifica titulares dos dados afetados e risco para direitos e liberdadesSuporta o reporte de severidade e impacto
Registo cronológicoDemonstra hora de conhecimento, escalonamento, decisões e momento da notificaçãoSuporta reporte faseado e comunicação com reguladores
Análise de causa raizSuporta remediação e responsabilizaçãoSuporta o reporte final e a melhoria da resiliência
Lições aprendidasAtualiza AIPD, controlos, formação e supervisão de fornecedoresAlimenta 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.

ReferencialO que auditores ou avaliadores esperamResposta de transição PIMS
RGPD da UEResponsabilização, fundamento de licitude, AIPD, governação de subcontratantes, gestão de violações, apoio a direitosREG02, REG04, registos de AIPD, registo de acordos de tratamento de dados, registos de decisões sobre violações, evidência de DSR
NIS2Análise de riscos, gestão de incidentes, continuidade de negócio, segurança da cadeia de fornecimento, controlo de acesso, gestão de ativosRegisto de Riscos do SGSI, níveis de fornecedores, fluxo de trabalho de incidentes, revisão de acessos, inventário de ativos
DORAQuadro de risco de TIC, reporte de incidentes, testes de resiliência, risco de terceiros de TIC, cláusulas contratuaisRegisto 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.0Governação, obrigações legais e de privacidade, perfis de risco, risco de fornecedores, resultados de resposta e recuperaçãoPerfis Atual e Alvo, mapeamento de conformidade, monitorização de fornecedores, evidência de resposta e recuperação
COBIT 2019Governação do programa de privacidade, monitorização da conformidade, acordos com fornecedores, controlos operacionais de privacidadeReporte 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.

CronogramaObjetivo da transiçãoPrincipais resultados
Dias 1 a 15Estabelecer âmbito e governaçãoAprovação REG01, patrocinador, mapa de papéis, atualização do Registo de Conformidade, plano de transição REG12
Dias 16 a 35Construir a linha de base de evidência de privacidadeLimpeza REG02, categorias de dados, finalidades, fundamentos de licitude, retenção, sistemas, fornecedores, transferências
Dias 36 a 55Executar triagem de riscos de privacidade e AIPDTriagem REG04, desencadeadores de AIPD, decisões de tratamento de riscos, aprovações de risco residual
Dias 56 a 70Atualizar controlos, contratos e salvaguardasAtualizaçã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 85Testar evidência através de auditoria internaAuditoria 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 90Realizar revisão pela gestão e decidir a preparaçãoAçõ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

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

Share this article