Avaliação de riscos de privacidade para ISO 27701 e RGPD da UE

A reunião de segunda-feira de manhã era familiar para Maria, a Diretora de Segurança da Informação (CISO) de uma empresa de tecnologia de saúde em forte crescimento.

O CEO queria um painel de gestão simples que mostrasse a exposição ao risco no âmbito do RGPD da UE antes de a empresa lançar a sua plataforma de análise de pacientes baseada em IA. O novo responsável pela privacidade, David, tinha um Registo de Atividades de Tratamento (RoPA) com 50 separadores. A engenharia tinha protegido o ambiente de nuvem. O produto estava pronto para lançamento. O fornecedor descrevia o seu conjunto de subcontratantes subsequentes como de “nível empresarial”.

Mas uma pergunta bloqueou a sala.

“Qual é o nosso risco real e conseguimos demonstrar aos clientes empresariais que o temos sob controlo?”

O RoPA mostrava o que a empresa tratava. O Registo de Riscos de segurança mostrava riscos de infraestrutura. Algumas AIPD existiam em documentos separados. As revisões de fornecedores estavam em pastas de compras. Ninguém conseguia mostrar uma cadeia de decisão rastreável desde a atividade de tratamento até ao risco de privacidade, à decisão sobre AIPD, ao plano de tratamento, ao mapeamento de controlos, à aprovação do risco residual e à data de revisão.

Esta é a lacuna que muitas organizações enfrentam quando avançam para a ISO/IEC 27701:2025 e para a responsabilização ao abrigo do RGPD da UE. Têm avisos de privacidade, questionários de fornecedores, entradas no RoPA, mapas de dados, modelos de AIPD e controlos da ISO/IEC 27001:2022. O que frequentemente lhes falta é a camada operacional que liga todos estes elementos.

Um Sistema de Gestão de Informação de Privacidade maduro, ou PIMS, não trata a avaliação de riscos de privacidade como um documento jurídico paralelo. Trata-a como um fluxo de decisão repetível: identificar o tratamento, fazer a triagem do risco, decidir se é necessária uma AIPD, selecionar controlos, atribuir responsáveis, aprovar o risco residual, monitorizar desencadeadores e reter evidência.

É aqui que os pacotes de políticas da Clarysec, o Zenith Blueprint e o Zenith Controls ajudam as equipas a passar de folhas de cálculo desconexas para um motor defensável de gestão de riscos de privacidade.

A avaliação de riscos de privacidade é a camada operacional em falta

A responsabilização ao abrigo do RGPD da UE é muitas vezes reduzida a “ter documentação”. A documentação é importante, mas o Article 5(2) vai mais longe. O responsável pelo tratamento é responsável pelo cumprimento dos princípios do Article 5(1), incluindo licitude, lealdade, transparência, limitação da finalidade, minimização dos dados, exatidão, limitação da conservação, integridade e confidencialidade, e deve conseguir demonstrá-lo.

Isto exige mais do que um RoPA. A organização deve conseguir explicar por que razão uma atividade de tratamento é aceitável, que riscos cria para os titulares dos dados, que controlos reduzem esses riscos, quem é responsável pela decisão e quando esta deve ser revista.

A ISO/IEC 27701:2025 reforça esta expectativa ao incorporar a governação da privacidade num PIMS gerido. Na prática, a avaliação de riscos de privacidade deve ligar seis objetos operacionais:

1. O inventário do tratamento de informação pessoal identificável (PII) ou RoPA.
2. A documentação do fundamento de licitude e da finalidade.
3. A triagem de riscos de privacidade e a decisão sobre AIPD.
4. O tratamento de riscos e a seleção de controlos.
5. A governação de fornecedores, subcontratantes e subcontratantes subsequentes.
6. A evidência retida no SGSI e no PIMS.

A Clarysec torna essa ligação explícita. Na política Enterprise Privacy Risk Assessment and DPIA Policy, o desencadeador ocorre antes do início do tratamento:

[Ambos] O responsável pelo processo / responsável pelo negócio DEVE iniciar a triagem de riscos de privacidade em REG04 antes de se iniciar qualquer tratamento de informação pessoal identificável (PII) novo ou materialmente alterado registado em REG02.

A mesma disciplina a montante surge na política Enterprise PII Processing Inventory and Lawful Basis Policy:

[Ambos] O responsável pelo processo / responsável pelo negócio DEVE iniciar a triagem de riscos de privacidade e AIPD em REG04 antes de avançar com qualquer tratamento de informação pessoal identificável (PII) novo ou materialmente alterado.

Isto evita o padrão de falha comum: o produto é lançado, o RoPA é atualizado mais tarde, a questão da AIPD chega demasiado tarde e o Registo de Riscos nunca recebe o cenário de privacidade.

Para responsáveis pelo tratamento, isto suporta a disciplina do fundamento de licitude do GDPR Article 6, a proteção de dados desde a conceção e por defeito do Article 25, a segurança do tratamento do Article 32 e a responsabilização do Article 5. Para subcontratantes, suporta instruções documentadas, garantia para clientes, limites contratuais e transparência sobre subcontratantes subsequentes.

Comece pela realidade do tratamento, não por um modelo em branco

Uma avaliação de riscos de privacidade falha quando começa com um formulário vazio e sem contexto operacional. A primeira pergunta não deve ser “Precisamos de uma AIPD?”. Deve ser “Que tratamento está efetivamente a mudar?”.

Para uma organização SaaS, fintech ou de tecnologia de saúde, a alteração pode envolver:

• Uma nova categoria de dados, como dados comportamentais de utilização, dados de saúde, sinais biométricos ou metadados de pagamento.
• Uma nova finalidade, como pontuação de fraude, análise de pacientes, suporte assistido por IA, previsão de churn ou personalização.
• Um novo destinatário, subcontratante ou subcontratante subsequente.
• Um novo fluxo de trabalho de suporte ou uma nova via de acesso transfronteiriça.
• Um novo prazo de retenção.
• Um novo modelo, algoritmo ou recomendação automatizada.
• Um novo grupo de titulares dos dados, como menores, trabalhadores, pacientes ou pessoas financeiramente vulneráveis.

As definições do RGPD da UE são amplas. Os dados pessoais incluem identificadores, identificadores em linha, dados de localização e fatores ligados à identidade. O tratamento inclui recolha, armazenamento, consulta, utilização, divulgação, limitação, apagamento e destruição. Uma violação de dados pessoais inclui destruição, perda, alteração, divulgação não autorizada ou acesso, de forma acidental ou ilícita.

Isto significa que um fluxo de trabalho de riscos de privacidade deve captar mais do que saber se a base de dados está cifrada. Deve captar por que existe o tratamento, se a finalidade é compatível, se o fundamento de licitude é válido, se estão envolvidos dados de categorias especiais, se os titulares dos dados conseguem compreender o tratamento e se as salvaguardas são proporcionais.

Para equipas mais pequenas, a política PME Política de proteção de dados e privacidade fornece o ponto de partida na cláusula 5.2.1:

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

Esse registo não é burocracia. É o modelo de entrada para a avaliação de riscos de privacidade. Sem categorias de dados, finalidade, fundamento de licitude e prazos de retenção, a avaliação não consegue avaliar de forma fiável a limitação da finalidade, a minimização dos dados, a limitação da conservação, a transparência ou a lealdade.

A mesma política PME também torna a revisão de risco uma obrigação recorrente na cláusula 7.1.1:

O Coordenador de Privacidade deve avaliar os riscos de privacidade anualmente e durante alterações significativas aos sistemas

Para empresas, a periodicidade de governação é mais exigente. A política Enterprise Política de proteção de dados e privacidade estabelece:

Os registos de riscos de privacidade devem ser mantidos no âmbito do SGSI e revistos pelo Encarregado da Proteção de Dados (EPD) e pelo CISO, pelo menos trimestralmente.

É aqui que a integração entre ISO/IEC 27701:2025 e ISO/IEC 27001:2022 se torna prática. Os riscos de privacidade não ficam enterrados em pastas jurídicas. São revistos juntamente com riscos de segurança, riscos de fornecedores, incidentes, constatações de auditoria, planos de tratamento e reporte à gestão.

O fluxo de trabalho REG02 a REG04 da Clarysec

O processo mais eficaz de avaliação de riscos de privacidade é suficientemente simples para responsáveis de negócio e suficientemente rigoroso para auditores. O modelo da Clarysec utiliza REG02 como inventário do tratamento de informação pessoal identificável (PII) e REG04 como registo de avaliação de riscos de privacidade e AIPD.

A Privacy Risk Assessment and DPIA Policy define a evidência mínima necessária antes de REG04 poder ser encerrado:

[Ambos] O Responsável pela Privacidade / Gestor do PIMS DEVE assegurar que cada avaliação REG04 regista a classificação de risco, a decisão de tratamento, o proprietário, a data-limite, o risco residual, o estado de aprovação e a data de revisão antes do encerramento.

Esta frase é a espinha dorsal operacional. Uma avaliação de riscos de privacidade não está encerrada porque alguém escreveu “baixo risco” numa caixa de comentários. Está encerrada quando o registo inclui a classificação, a decisão de tratamento, o proprietário, a data-limite, o risco residual, o estado de aprovação e a data de revisão.

Para PME, a mesma disciplina é ajustada à escala. A política PME Política de Gestão de Riscos estabelece:

Cada entrada de risco deve incluir: descrição, probabilidade, impacto, pontuação, proprietário e plano de tratamento.

O princípio é proporcionalidade, não informalidade. Organizações mais pequenas podem usar um registo mais simples, mas cada risco continua a precisar de descrição, pontuação, proprietário e plano de tratamento.

Use o motor de risco da ISO/IEC 27001:2022 para a privacidade

O risco de privacidade não deve existir fora do método de gestão de riscos da organização. A ISO/IEC 27001:2022 já fornece o motor do sistema de gestão: contexto, partes interessadas, âmbito, liderança, avaliação de riscos, tratamento, controlo operacional, informação documentada, avaliação de desempenho e melhoria contínua.

As cláusulas 4.1 a 4.4 exigem que a organização compreenda questões internas e externas, requisitos das partes interessadas, âmbito do SGSI e processos do SGSI. Para a privacidade, as partes interessadas incluem clientes, titulares dos dados, trabalhadores, reguladores, subcontratantes, subcontratantes subsequentes, autoridades de controlo, supervisores do setor financeiro quando aplicável e clientes contratuais.

A cláusula 6.1.2 exige um processo de avaliação de riscos de segurança da informação. A cláusula 6.1.3 exige tratamento de riscos de segurança da informação, incluindo selecionar controlos, produzir uma Declaração de Aplicabilidade, formular um plano de tratamento de riscos e obter a aprovação do proprietário do risco para o plano e os riscos residuais. As cláusulas 8.2 e 8.3 exigem a realização de avaliações e tratamentos de riscos de segurança da informação em intervalos planeados ou quando ocorram alterações significativas, mantendo os resultados documentados.

A política Enterprise Política de Gestão de Riscos da Clarysec está alinhada com essa estrutura na cláusula 5.1:

Deve ser mantido um processo formal de gestão de riscos em conformidade com a ISO/IEC 27005 e a ISO 31000, abrangendo identificação, análise, avaliação, tratamento, monitorização e comunicação de riscos.

Para a privacidade, os critérios de risco devem incluir o impacto sobre os titulares dos dados, e não apenas o impacto no negócio. Uma perda financeira reduzida pode ainda assim representar um impacto de privacidade elevado se o tratamento envolver dados de categorias especiais, pessoas vulneráveis, definição de perfis, opacidade, retenção ilícita, impossibilidade de exercer direitos ou danos não materiais.

O Zenith Blueprint: roteiro de 30 passos para auditores da Clarysec explica isto na fase de Gestão de Riscos, passo 10:

Ao definir o impacto, é recomendável relacionar os níveis com a escala específica do seu negócio. Por exemplo, “Impacto financeiro maior = perda > $100k” (ajuste ao seu contexto). Considere também o impacto regulamentar: por exemplo, uma violação de dados pessoais pode ser automaticamente “Maior” ou “Severa” devido a coimas do RGPD da UE e requisitos de notificação, mesmo que a perda financeira direta não seja clara.

Esta orientação é especialmente importante para análise baseada em IA, dados de saúde, definição de perfis financeiros, monitorização de trabalhadores e pontuação de clientes. O dano pode ser jurídico, reputacional, discriminatório, operacional, contratual ou pessoal.

Um exemplo prático: análise de pacientes com IA

Voltemos a Maria e David. A sua plataforma de tecnologia de saúde irá tratar dados de saúde de categorias especiais ao abrigo do GDPR Article 9. Usará histórico de pacientes, dados de marcações, notas clínicas e resultados do modelo para gerar informações de risco.

Usando o Zenith Blueprint, começam pelo passo 9, identificando ativos, ameaças e vulnerabilidades:

Para cada ativo, registe detalhes-chave: 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)”.

O mesmo passo acrescenta a perspetiva de privacidade:

Assegure que os ativos de dados pessoais são assinalados (para relevância face ao RGPD da UE) e que os ativos de serviços críticos são identificados (para potencial aplicabilidade da NIS2, se estiver num setor regulado).

A equipa de Maria identifica a Plataforma de Análise de Pacientes com IA, a base de dados de pacientes, o armazém de dados, o pipeline de treino do modelo, o painel clínico, o armazenamento em nuvem, o fornecedor de identidade, os logs de auditoria, a plataforma de tickets de suporte e a ferramenta de análise de terceiros. Cada ativo recebe um proprietário, localização, classificação e relação com informação pessoal identificável (PII).

Depois definem cenários de risco. Um é o acesso não autorizado a registos de saúde. Outro é a divulgação acidental através de exportações analíticas. Um terceiro é o enviesamento do modelo de IA causado por dados de treino enviesados, resultando em pontuações de risco de pacientes injustas ou discriminatórias.

O passo 11 do Zenith Blueprint explica a função do Registo de Riscos:

O Registo de Riscos é normalmente uma folha de cálculo (o nosso modelo “Risk Register and SoA Builder.xlsx” tem uma folha dedicada para este fim). Serve como registo mestre dos riscos.

Uma entrada de risco de privacidade para o cenário de enviesamento do modelo de IA pode ter este aspeto:

Esta entrada faz o que a antiga folha de cálculo não conseguia. Liga uma atividade de tratamento a um ativo, ameaça, vulnerabilidade, risco para os titulares dos dados, proprietário, pontuação, plano de tratamento e trilho de evidência.

Como o tratamento é de alto risco e envolve dados de categorias especiais, a AIPD não é uma reflexão posterior separada. Torna-se a fase de avaliação mais aprofundada para um risco já registado no sistema. A política Enterprise Política de proteção de dados e privacidade estabelece:

Todas as alterações significativas a sistemas ou processos que envolvam informação pessoal identificável (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).

Para risco residual elevado do responsável pelo tratamento, a Privacy Risk Assessment and DPIA Policy acrescenta:

[Responsável pelo tratamento] A gestão de topo DEVE aprovar a aceitação de risco residual de privacidade elevado em REG04 antes de o tratamento de alto risco pelo responsável pelo tratamento começar ou continuar.

A decisão de lançamento passa agora a ter rastreabilidade: o que mudou, o que foi avaliado, que riscos foram identificados, que controlos foram selecionados, quem é responsável pelo tratamento, quem aprovou o risco residual e quando a decisão será revista.

Dos riscos aos controlos com Zenith Controls

A avaliação de riscos de privacidade só importa se conduzir a decisões de controlo. O Zenith Controls: guia de conformidade transversal da Clarysec é o guia de conformidade transversal que mapeia controlos da ISO/IEC 27001:2022 e ISO/IEC 27002:2022 para requisitos relacionados em vários referenciais. Não é um conjunto separado de controlos. Ajuda as equipas a compreender como a evidência de controlos suporta múltiplas obrigações.

Para avaliação de riscos de privacidade, o Zenith Controls destaca três controlos centrais da ISO/IEC 27002:2022:

O controlo 5.34 também suporta o GDPR Article 25 e o Article 32, as medidas de gestão de riscos de cibersegurança do NIS2 Article 21, as expectativas de gestão do risco das TIC do DORA e os resultados do NIST CSF 2.0, como GV.OC-03 para obrigações legais, regulamentares, contratuais, de privacidade e de liberdades civis, bem como PR.DS-01 para proteção de dados em repouso.

O passo 13 do Zenith Blueprint liga estas decisões à Declaração de Aplicabilidade:

Faça referências cruzadas a regulamentos: se determinados controlos forem implementados especificamente para cumprir o RGPD da UE, a NIS2 ou o DORA, pode assinalá-lo no Registo de Riscos (como parte da justificação do impacto do risco) ou nas notas da SoA.

É assim que uma constatação de privacidade se torna uma decisão de controlo do SGSI e do PIMS, e não apenas um comentário jurídico.

O risco de fornecedores e subcontratantes deve ser avaliado antes da aprovação

Muitas falhas de privacidade começam na governação de fornecedores. Um subcontratante acrescenta um novo subcontratante subsequente. Um fornecedor de suporte obtém acesso à produção. Uma plataforma de análise armazena dados de eventos numa nova região. A equipa de compras assina o contrato antes de a privacidade analisar o risco.

A política Enterprise Processor, Subprocessor and Third-Party Privacy Management Policy da Clarysec evita isto ao ligar a revisão de fornecedores, REG04 e o registo de terceiros:

[Ambos] O Responsável pela Privacidade / Gestor do PIMS DEVE acionar a triagem de riscos de privacidade e AIPD em REG04 para relações de alto risco com subcontratantes e alterações materiais de privacidade relativas a terceiros antes da aprovação, registando a referência REG04 em REG08.

Para PME, a Política de segurança de terceiros e fornecedores estabelece o requisito de revisão prévia à contratação:

Antes da contratação, cada fornecedor deve ser revisto quanto a riscos potenciais. Esta revisão deve incluir:

A mensagem operacional é clara. O risco de fornecedor é avaliado antes da aprovação, não depois da assinatura.

Isto também suporta a NIS2 e o DORA. O NIS2 Article 21 exige segurança da cadeia de fornecimento como parte das medidas de gestão de riscos de cibersegurança. Os DORA Articles 28 a 30 exigem que as entidades financeiras façam a gestão do risco das TIC de terceiros, realizem avaliações pré-contratuais, mantenham salvaguardas contratuais, compreendam o risco de subcontratação, monitorizem dependências e planeiem saídas para funções críticas ou importantes.

Se um fornecedor tocar em informação pessoal identificável (PII) ou suportar tratamento crítico para a privacidade, o registo de riscos de privacidade deve mostrar o fornecedor, a função no tratamento, a localização dos dados, a dependência de subcontratantes subsequentes, as salvaguardas contratuais, os compromissos de incidentes, as regras de retenção, a abordagem de monitorização e o plano de saída.

Um fluxo de trabalho, muitos resultados de conformidade

A vantagem de um fluxo de trabalho PIMS integrado é que a mesma evidência suporta vários referenciais sem duplicar trabalho.

O NIST CSF 2.0 é especialmente útil para comunicação executiva. A sua função GOVERN abrange contexto organizacional, estratégia de gestão de riscos, política, funções, supervisão e risco da cadeia de fornecimento. Os seus Perfis Organizacionais ajudam a traduzir resultados atuais e alvo num plano de ação priorizado, como um Registo de Riscos ou um plano de ação e marcos.

Para organizações sujeitas à NIS2, ao DORA ou a regras setoriais específicas, a evidência de riscos de privacidade também suporta governação de cibersegurança, supervisão de fornecedores, preparação para incidentes e reporte de resiliência.

O tratamento de riscos de privacidade é mais amplo do que cifragem

A cifragem é importante, mas não corrige um fundamento de licitude inválido, recolha excessiva, definição de perfis não divulgada, tratamento desleal, retenção ilícita ou um subcontratante que atua fora das instruções.

A política PME Política de proteção de dados e privacidade estabelece:

Devem ser implementados controlos para reduzir os riscos identificados, incluindo cifragem, anonimização, eliminação segura e restrições de acesso

Estes são exemplos sólidos, mas o tratamento deve ajustar-se ao cenário. Um plano de tratamento de riscos de privacidade pode incluir restringir a finalidade do tratamento, remover categorias de dados desnecessárias, agregar ou pseudonimizar dados, atualizar avisos, alterar o fundamento de licitude quando apropriado, limitar a retenção, restringir acessos, acrescentar registo, atualizar contratos, concluir uma AIPD, adiar o lançamento ou rejeitar tratamento que continue inaceitável.

A política Enterprise Política de Gestão de Riscos reforça o planeamento do tratamento para riscos acima da tolerância:

Todos os riscos classificados acima do nível de tolerância devem ter um Plano de tratamento de riscos associado que especifique:

Na prática, isto significa que um risco de privacidade elevado não pode ser aceite por silêncio. Deve ser tratado, transferido quando apropriado, evitado ou formalmente aceite pelo responsável adequado.

Os desencadeadores de revisão mantêm a avaliação viva

Uma avaliação de riscos de privacidade que nunca é revista torna-se evidência desatualizada. As cláusulas 8.2 e 8.3 da ISO/IEC 27001:2022 exigem avaliação e tratamento de riscos em intervalos planeados ou quando ocorrem alterações significativas. A responsabilização ao abrigo do RGPD da UE exige decisões atuais. A ISO/IEC 27701:2025 depende de monitorização e melhoria contínua.

Uma avaliação REG04 deve ser reaberta quando a finalidade muda, são acrescentadas novas categorias de dados, passam a estar envolvidos dados de categorias especiais, o fundamento de licitude muda, muda um subcontratante ou subcontratante subsequente, o armazenamento passa para uma nova região, os prazos de retenção mudam, a lógica de definição de perfis muda, ocorre uma violação ou quase-incidente, os contratos com clientes mudam ou passa a aplicar-se uma nova obrigação NIS2, DORA ou setorial específica.

Os processos de incidentes devem retroalimentar o fluxo de trabalho de riscos de privacidade. O NIS2 Article 23 estabelece reporte faseado de incidentes significativos. Os DORA Articles 17 a 20 exigem registo, classificação, escalonamento, comunicação, análise de causa raiz e melhoria de incidentes relacionados com TIC. Também podem ser acionadas obrigações de violação de dados pessoais ao abrigo do RGPD da UE. Se um incidente revelar controlos de acesso fracos, retenção excessiva, notificação de fornecedores pouco clara ou instruções de cliente deficientes, REG04 deve ser atualizado.

O que os auditores esperam ver

Um fluxo de trabalho robusto de riscos de privacidade deve resistir a várias perspetivas de garantia.

A política Enterprise Política de proteção de dados e privacidade também exige atividade de auditoria interna:

Deve ser realizada anualmente uma auditoria interna de conformidade de privacidade ou aquando de alterações organizacionais ou regulamentares relevantes. O âmbito da auditoria deve incluir:

Isto cria um ciclo de feedback para a gestão. Os registos REG02 estão completos? As triagens REG04 são atempadas? As AIPD são realizadas quando exigido? Os riscos residuais elevados são aprovados? As alterações de fornecedores são captadas? Os planos de tratamento são encerrados? Os avisos estão alinhados com o tratamento real?

Lista de verificação para a sua próxima reunião sobre alterações de privacidade

Use esta lista de verificação antes de uma nova atividade de tratamento, funcionalidade de produto, fornecedor, modelo ou fluxo de trabalho de suporte entrar em produção.

Esta lista de verificação não substitui a política. É uma forma prática de operacionalizar a política em reuniões de produto, compras, engenharia, conformidade, jurídico e liderança.

Transforme a responsabilização em privacidade num sistema funcional

A ISO/IEC 27701:2025 e a responsabilização ao abrigo do RGPD da UE exigem mais do que documentos. Exigem um sistema funcional que ligue registos de tratamento, fundamento de licitude, risco de privacidade, decisões de AIPD, fornecedores, controlos, proprietários, aprovações e evidência.

Comece pela fase de Gestão de Riscos do Zenith Blueprint, especialmente os passos 9 a 13. Use o Risk Register and SoA Builder para ligar ativos, ameaças, vulnerabilidades, riscos de privacidade, decisões de tratamento e referências de controlos. Em seguida, use o Zenith Controls para mapear a proteção de PII, o inventário de ativos e a segurança de fornecedores para expectativas de garantia do RGPD da UE, ISO/IEC 27001:2022, NIS2, DORA, NIST CSF 2.0 e COBIT 19.

Alinhe as políticas operacionais que tornam o fluxo de trabalho aplicável: Privacy Risk Assessment and DPIA Policy, PII Processing Inventory and Lawful Basis Policy, Processor, Subprocessor and Third-Party Privacy Management Policy, Política de Gestão de Riscos e Política de proteção de dados e privacidade. Equipas mais pequenas também podem usar as políticas PME da Clarysec, enquanto organizações maiores podem estruturar a governação através das políticas Enterprise.

Se a sua equipa está a lançar novo tratamento, a alterar fornecedores, a preparar-se para a ISO/IEC 27701:2025 ou a tentar tornar repetível a evidência de responsabilização ao abrigo do RGPD da UE, comece por uma atividade de tratamento em produção. Abra REG02, execute a triagem REG04, mapeie os riscos para controlos, atribua proprietários de tratamento e reveja o risco residual com o decisor adequado.

Esse fluxo de trabalho único é onde a governação da privacidade se torna operacional.