Governação de responsáveis conjuntos pelo tratamento: guia de auditoria ao Article 26 do GDPR

A chamada chegou numa terça-feira de manhã. Para o Diretor de Segurança da Informação da CareConnect, um fornecedor SaaS MedTech em rápido crescimento, foi o momento em que o terreno mudou.

Do outro lado estava a Responsável de Conformidade da MetroHealth, o seu principal parceiro hospitalar. Um paciente que utilizava a plataforma de monitorização remota gerida em conjunto tinha apresentado um pedido de acesso do titular dos dados um mês antes. Nenhuma das organizações tinha respondido integralmente. Cada uma acreditava que a outra era responsável.

Depois, o Jurídico encaminhou uma segunda mensagem. Um programador júnior da CareConnect tinha exposto acidentalmente um endpoint de API não crítico que incluía identificadores limitados de pacientes. O problema parecia passível de contenção, e a janela de 72 horas para notificação de violação de dados pessoais ao abrigo do GDPR ainda não tinha fechado. Mas a mesma pergunta bloqueou ambas as equipas.

Quem informa a autoridade de controlo? Quem comunica com os pacientes? Quem é responsável pelo aviso de privacidade? Quem valida o pedido do titular dos dados? Quem regista a decisão?

O acordo comercial era detalhado quanto a créditos de serviço, faturação, limites de responsabilidade e marcos do roadmap do produto. Era quase omisso quanto à realidade operacional da governação de responsáveis conjuntos pelo tratamento ao abrigo do Article 26 do GDPR.

É aqui que muitas parcerias falham. O problema não é que as equipas de privacidade, jurídico, segurança e compras nunca tenham ouvido a expressão “acordo entre responsáveis conjuntos pelo tratamento”. O problema é que ninguém consegue provar, antes do início do tratamento, quem é responsável por transparência, fundamento de licitude, direitos dos titulares dos dados, escalonamento de violações de dados pessoais, obrigações em cadeia de fornecedores, transferências, retenção, evidência e comunicação com reguladores.

O GDPR define a obrigação. A ISO/IEC 27701:2025 dá às equipas de privacidade uma estrutura de sistema de gestão. As políticas PIMS da Clarysec, o Zenith Blueprint: roteiro de auditor em 30 passos e o Zenith Controls: guia de conformidade transversal transformam o Article 26 em evidência operacional pronta para auditoria.

Porque falha a governação de responsáveis conjuntos pelo tratamento antes de alguém reparar

Existe uma relação de responsáveis conjuntos pelo tratamento quando duas ou mais partes determinam conjuntamente as finalidades e os meios do tratamento de dados pessoais. O fator determinante não é a redação do contrato. É o poder de decisão.

No exemplo da CareConnect e da MetroHealth, a CareConnect fornece a plataforma, a analítica, a arquitetura técnica, a interface de utilizador e os fluxos de dados. A MetroHealth fornece a relação com o paciente, o contexto clínico, o modelo de serviço e os dados dos pacientes. Ambas influenciam a razão pela qual os dados pessoais são tratados e a forma como o tratamento funciona. Isto é muito diferente de um fornecedor que se limita a alojar uma base de dados ou a enviar mensagens com base em instruções documentadas.

O mesmo padrão surge em campanhas de bem-estar financeiro, parcerias de seguros incorporados, marketplaces online, consórcios de deteção de fraude, plataformas de saúde conectada, programas de fidelização, ecossistemas de verificação de identidade e colaborações analíticas. Um banco, uma seguradora e uma plataforma SaaS podem decidir conjuntamente segmentos-alvo, regras de definição de perfis, métricas de conversão e canais de marketing. Um acordo de tratamento de dados com um subcontratante não resolve esse problema se, na realidade, as partes forem responsáveis conjuntos pelo tratamento.

As falhas práticas são previsíveis:

1. O aviso de privacidade diz pouco mais do que “podemos partilhar dados com parceiros”.
2. O inventário de tratamento identifica as partes, mas não a repartição de obrigações.
3. O fluxo de direitos dos titulares dos dados não tem uma via para encaminhar, validar ou responder a pedidos.
4. O plano de incidentes diz “notificar o Jurídico”, mas não indica qual dos responsáveis conjuntos pelo tratamento lidera a comunicação externa.
5. O contrato é tratado como documentação comercial, não como evidência de responsabilização.
6. As disposições de cessação não cobrem devolução de dados, apagamento, anonimização, remoção de acessos ou preservação de evidência.

O GDPR Article 5 torna estas falhas sensíveis em auditoria, porque os responsáveis pelo tratamento não devem apenas cumprir princípios como licitude, lealdade, transparência, limitação das finalidades, minimização, exatidão, limitação da conservação, integridade, confidencialidade e responsabilização. Devem conseguir demonstrar o cumprimento. O Article 6 acrescenta o requisito de fundamento de licitude. O Article 3 pode colocar fornecedores SaaS, fintech, health-tech e analíticos não pertencentes à UE dentro do âmbito quando ofereçam serviços a pessoas singulares na UE ou monitorizem o seu comportamento.

A lição para Diretores de Segurança da Informação e gestores de conformidade é direta: a governação de responsáveis conjuntos pelo tratamento não é “apenas Jurídico”. É um sistema de controlos interfuncional que envolve privacidade, segurança, compras, produto, engenharia, suporte, resposta a incidentes, marketing e supervisão executiva.

O princípio PIMS da ISO/IEC 27701:2025: decidir antes de iniciar o tratamento

Um Sistema de Gestão da Informação de Privacidade ISO/IEC 27701:2025 só funciona se os papéis de privacidade forem determinados antes do início do tratamento. Esta é a disciplina operacional que impede que o Article 26 se transforme num exercício de reconstrução pós-incidente.

A Política do Sistema de Gestão da Informação de Privacidade da Clarysec, cláusula 4.2.2, estabelece:

[Responsável conjunto pelo tratamento] O Responsável pelo fornecedor / pelas compras DEVE documentar a repartição de responsabilidades entre responsáveis conjuntos pelo tratamento no REG08 antes do início do tratamento conjunto.

A expressão “antes do início do tratamento conjunto” é o ponto de controlo. Significa antes de a integração da plataforma entrar em produção, antes de o painel partilhado ser ativado, antes de começar a sincronização com o CRM, antes de as audiências de campanha serem ativadas e antes de começarem a chegar pedidos dos titulares dos dados.

A obrigação de inventário de suporte consta da Política de Inventário de Tratamento de Dados Pessoais e Fundamento de Licitude, cláusula 4.3.5:

[Responsável conjunto pelo tratamento] O Responsável pelo fornecedor / pelas compras DEVE registar a finalidade do tratamento pelo responsável conjunto e a referência da repartição de responsabilidades no REG02 e no REG08 antes do início do tratamento por responsáveis conjuntos.

Em conjunto, estas cláusulas criam a cadeia de evidência que os auditores esperam:

• O REG02 regista a atividade de tratamento, finalidade, categorias de dados, fundamento de licitude, retenção, sistemas, destinatários, transferências e referência ao responsável conjunto pelo tratamento.
• O REG08 regista o acordo entre responsáveis conjuntos pelo tratamento e a repartição de responsabilidades.
• O REG07 regista o resumo de transparência destinado ao público.
• O REG06 pode registar a receção de pedidos de exercício de direitos, encaminhamento, validação, prazos e evidência de resposta.
• O REG10 regista decisões de avaliação de incidentes e violações de dados pessoais.

Essa cadeia transforma o Article 26 de uma declaração jurídica num processo de sistema de gestão.

Começar pelo âmbito, partes interessadas e uma matriz RACI

O Zenith Blueprint começa pelo âmbito e pelas partes interessadas porque a governação de responsáveis conjuntos pelo tratamento falha quando as partes interessadas e os requisitos são identificados demasiado tarde.

Na fase de Fundamentos e Liderança do SGSI, passo 2, Necessidades das partes interessadas e âmbito do SGSI, o Zenith Blueprint recomenda uma análise de partes interessadas que capture requisitos explícitos e implícitos:

Como identificar necessidades e expectativas: Para cada grupo de partes interessadas identificado, liste o que exigem
em matéria de segurança da informação. Alguns requisitos são explícitos (leis, contratos,
SLA), enquanto outros são implícitos (expectativas ou boas práticas gerais). Ajuda:

✓ Rever os requisitos legais e regulamentares aplicáveis ao seu contexto (a partir da análise
de contexto do passo 1). Elaborar uma lista de cláusulas ou obrigações específicas relacionadas com
segurança da informação ou privacidade.
✓ Rever contratos e acordos: muitos contratos empresariais têm adendas de confidencialidade ou
segurança. Extraia esses requisitos.
✓ Realizar entrevistas ou workshops com partes interessadas: envolver representantes de
cada grupo (por exemplo, um gestor de RH para a perspetiva dos trabalhadores, um gestor comercial para as
expectativas dos clientes) para compreender as suas preocupações ou necessidades.
✓ Considerar normas setoriais ou códigos de prática que as partes interessadas esperam que a organização
siga.

Para um acordo auditável entre responsáveis conjuntos pelo tratamento ao abrigo do Article 26 do GDPR, a análise de partes interessadas deve incluir clientes, pacientes, utilizadores, autoridades de controlo, as outras partes responsáveis pelo tratamento, subcontratantes, subcontratantes subsequentes, seguradoras, prestadores de serviços cloud, departamentos internos, reguladores e órgãos de administração.

O passo 4, Papéis e responsabilidades no SGSI, transforma depois essa análise em titularidade. O Zenith Blueprint destaca o valor de um modelo RACI:

✓ Responsabilização vs. responsabilidade: uma ferramenta útil aqui é uma matriz RACI (Responsible,
Accountable, Consulted, Informed). Para cada processo ou controlo principal do SGSI, identifique
quem é Responsible (executa o trabalho), quem é Accountable (responde em última instância, muitas vezes um
gestor), quem é Consulted (fornece contributos) e quem é Informed.

Para responsáveis conjuntos pelo tratamento, a RACI não é opcional na prática. Sem ela, o Jurídico assume que a Privacidade está a responder ao pedido, a Privacidade assume que o Suporte tem a fila de receção, o Suporte assume que o parceiro responderá, e o prazo legal continua a correr.

O modelo de evidência da Clarysec para responsáveis conjuntos pelo tratamento

Um acordo maduro entre responsáveis conjuntos pelo tratamento deve ser compreensível numa página e demonstrável em dez minutos. O objetivo não é soterrar equipas em documentação jurídica. O objetivo é tornar responsabilidades visíveis, aceites e testáveis.

As políticas de privacidade da Clarysec reforçam cada camada.

A Política de Aviso de Privacidade e Transparência, cláusula 4.1.5, estabelece:

[Responsável conjunto pelo tratamento] O Responsável de Privacidade / Gestor do PIMS DEVE registar no REG07 o resumo público das responsabilidades entre responsáveis conjuntos pelo tratamento e o ponto de contacto antes de o tratamento por responsáveis conjuntos ser lançado ou materialmente alterado.

A Política de Gestão dos Direitos dos Titulares dos Dados, cláusula 6.1.5, estabelece:

[Responsável conjunto pelo tratamento] O Responsável de Privacidade / Gestor do PIMS DEVE documentar as responsabilidades de tratamento de direitos e as vias de contacto no REG02, REG06 ou REG08 antes do início do tratamento por responsáveis conjuntos.

A Política de Gestão de Incidentes e Violações de Dados Pessoais, cláusula 4.2.5, acrescenta:

[Responsável conjunto pelo tratamento] O Responsável de Privacidade / Gestor do PIMS DEVE verificar a responsabilidade acordada pela violação de dados pessoais, a responsabilidade principal pela comunicação e o acordo de coordenação antes de qualquer notificação ou comunicação externa por um responsável conjunto pelo tratamento, e DEVE registar a decisão no REG08 e no REG10.

É neste ponto que a ISO/IEC 27701:2025 e o GDPR se tornam operacionais. A organização não se limita a afirmar que as responsabilidades estão repartidas. Mostra onde estão registadas, quem as aprovou, quando foram testadas e como são utilizadas.

Exemplo prático: REG08 para uma plataforma de monitorização remota

Admita que a CareConnect e a MetroHealth operam conjuntamente uma plataforma de monitorização remota. Ambas decidem por que motivo os dados dos pacientes são tratados, que dados são recolhidos, como são configurados os alertas de monitorização, como a analítica é utilizada e como os pacientes interagem com o serviço.

Em primeiro lugar, o REG02 deve registar a atividade de tratamento:

• Nome do tratamento: serviço de monitorização remota de pacientes
• Papel do responsável pelo tratamento: responsável conjunto pelo tratamento
• Partes: CareConnect e MetroHealth
• Finalidade: monitorização de pacientes, coordenação de cuidados, melhoria do serviço, analítica da plataforma
• Categorias de dados pessoais: dados de contacto, identificadores de conta, observações clínicas, eventos de dispositivo, interações de suporte
• Verificação de categoria especial: são tratados dados de saúde e são exigidas salvaguardas reforçadas
• Fundamento de licitude: documentado por parte e por finalidade
• Retenção: definida por requisitos clínicos, de plataforma, legais e operacionais
• Sistemas: aplicação móvel, plataforma de monitorização, ferramenta de suporte, armazém analítico, fornecedor de identidade
• Destinatários: partes responsáveis conjuntas pelo tratamento, prestador de alojamento, fornecedores de suporte, prestadores de notificações
• Transferências: acesso remoto e tratamento fora do EEE avaliados
• Referência REG08: JC-2026-004

Em segundo lugar, o REG08 deve repartir responsabilidades de forma que os operadores consigam seguir.

Em terceiro lugar, o REG07 deve registar o resumo destinado ao público. O aviso deve explicar a essência do acordo conjunto em linguagem clara, identificar os responsáveis conjuntos pelo tratamento, descrever a responsabilidade de cada um e fornecer um ponto de contacto utilizável. Não deve obrigar pacientes ou utilizadores a decifrar a complexidade operacional interna.

Em quarto lugar, teste o fluxo antes do lançamento. Envie um pedido de acesso simulado para o ponto de contacto publicado. Confirme que o Suporte o identifica como pedido de exercício de direitos do titular dos dados, o encaminha para a Privacidade, consulta o REG08, solicita contributos do parceiro, regista ações no REG06 e produz um pacote de resposta. Em seguida, execute um exercício de tabletop de violação de dados pessoais com um cenário como “endpoint de API expõe identificadores de pacientes a utilizadores não autorizados” ou “utilizadores com supressão de apagamento são acidentalmente incluídos numa campanha de interação”.

Estes testes expõem as lacunas reais: caixas de correio sem responsável, SLA de parceiros pouco claros, texto de aviso não aprovado, registos incompletos de fundamento de licitude, verificações em falta de categorias especiais e playbooks de incidentes que não nomeiam o responsável principal pela comunicação externa.

Mapear o Article 26 para controlos ISO/IEC 27002:2022 através do Zenith Controls

Um acordo entre responsáveis conjuntos pelo tratamento não é apenas um artefacto jurídico. Deve ser suportado por controlos técnicos e organizacionais. O Zenith Controls ajuda as equipas a mapear expectativas de controlo da ISO/IEC 27001:2022 e da ISO/IEC 27002:2022 para evidência de privacidade, fornecedores, incidentes, cloud e governação.

Três controlos ISO/IEC 27002:2022 são especialmente relevantes.

Control 5.2, Papéis e responsabilidades de segurança da informação, suporta o modelo operacional. Liga-se à ISO/IEC 27001:2022 Clause 5.3, papéis, responsabilidades e autoridades organizacionais. Também suporta a preparação para incidentes, porque papéis pouco claros fragilizam o ISO/IEC 27002:2022 Control 5.24, planeamento e preparação da gestão de incidentes de segurança da informação. Na governação de responsáveis conjuntos pelo tratamento, o Control 5.2 é onde a RACI, os responsáveis pelo REG08, os intervenientes nos pedidos de exercício de direitos, os responsáveis por violações de dados pessoais e os contactos de escalonamento se tornam evidência de auditoria.

Control 5.31, Requisitos legais, estatutários, regulamentares e contratuais, é onde o GDPR Article 26 passa a fazer parte do SGSI, em vez de ser um tema apenas do Jurídico. Suporta a identificação e gestão da responsabilização do GDPR Article 5, do fundamento de licitude do Article 6, da repartição de responsabilidades do Article 26, da segurança do Article 32, da notificação à autoridade de controlo do Article 33 e da comunicação às pessoas singulares afetadas do Article 34. Também se liga à ISO/IEC 27001:2022 Clause 4.2, compreensão das necessidades e expectativas das partes interessadas, e à Clause 6.1.3, tratamento de riscos de segurança da informação.

Control 5.34, Privacidade e proteção de dados pessoais, integra a proteção de dados pessoais no modelo operacional de segurança. É especialmente importante quando o acordo utiliza analítica cloud, painéis partilhados, data clean rooms, plataformas de monitorização, automatização de marketing ou ferramentas de suporte. As salvaguardas relacionadas podem incluir o ISO/IEC 27002:2022 Control 5.23, segurança da informação para utilização de serviços na nuvem, e o Control 8.11, mascaramento de dados.

O ecossistema ISO de suporte também é relevante. A ISO/IEC 27018 ajuda quando serviços de cloud pública tratam dados pessoais. A ISO/IEC 29100 fornece princípios de privacidade como transparência, consentimento, finalidade legítima, limitação da recolha, minimização de dados, limitação da utilização, exatidão, salvaguardas de segurança e responsabilização. A ISO/IEC 27001:2022 fornece a espinha dorsal do sistema de gestão através de contexto, partes interessadas, âmbito, liderança, avaliação de riscos, tratamento de riscos, Declaração de Aplicabilidade, auditoria interna, revisão pela gestão e melhoria contínua.

Os contratos devem refletir o modelo operacional

Um acordo entre responsáveis conjuntos pelo tratamento não pode existir apenas num aviso de privacidade. Deve refletir-se em contratos, anexos, procedimentos operacionais, playbooks de incidentes, vias de escalonamento e disposições de cessação.

A Política de Cumprimento Legal e Regulamentar da Clarysec, cláusula 5.3.1.2, integra explicitamente tipos de contratos na governação, incluindo:

Contratos que envolvam partilha de dados, direitos de propriedade intelectual, limitações de responsabilidade ou cláusulas de auditoria

A Política de Proteção de Dados e Privacidade, cláusula 5.1, estabelece a base empresarial:

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.

Para PME, o mesmo princípio é dimensionado à realidade operacional. A Política de Proteção de Dados e Privacidade para PME, cláusula 5.2.1, estabelece:

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

A cláusula 5.2.2 acrescenta:

Os contratos com terceiros que tratem dados pessoais devem incluir cláusulas de proteção de dados e devem ser revistos pelo Diretor-Geral ou por assessor jurídico

Isto é governação proporcional. Uma multinacional pode ter equipas separadas de jurídico, privacidade, compras, segurança, risco e conformidade. Uma PME pode depender de um Coordenador de Privacidade, Diretor-Geral e assessor jurídico externo. A expectativa de evidência mantém-se: atividades de tratamento, responsabilidades, fundamento de licitude, avisos, tratamento de direitos, escalonamento de incidentes e obrigações de cessação devem estar documentados e ser passíveis de revisão.

O Zenith Blueprint, passo 23, Controlos organizacionais, suporta a disciplina de acordos com fornecedores através de confidencialidade, responsabilidades de controlo de acesso, medidas técnicas e organizativas, prazos de notificação de incidentes, direitos de auditoria, controlos sobre subcontratantes e disposições de fim de contrato. Nas relações entre responsáveis conjuntos pelo tratamento, essas cláusulas devem ser adaptadas à partilha de dados e à repartição de responsabilidades, em vez de copiadas de um modelo de subcontratante.

Governação de incidentes e violações de dados pessoais: decidir o responsável antes da violação

As violações de dados pessoais em contextos de responsáveis conjuntos pelo tratamento tornam-se caóticas quando as equipas esperam pelo incidente para decidir quem comunica externamente.

O GDPR 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 a dados pessoais. Quando exigida, a notificação à autoridade de controlo deve ocorrer sem demora injustificada e, sempre que viável, no prazo de 72 horas após a tomada de conhecimento da violação. A NIS2 e o DORA podem acrescentar expectativas adicionais de reporte de ciberincidentes e comunicação a clientes.

A Política de Resposta a Incidentes para PME da Clarysec, cláusula 5.3.2, capta a disciplina temporal:

Os prazos de resposta, incluindo recuperação de dados e obrigações de notificação, devem ser documentados e alinhados com requisitos legais, como o requisito de notificação de violação de dados pessoais no prazo de 72 horas previsto no GDPR.

O Zenith Blueprint, passo 5, Comunicação, sensibilização e competência, enfatiza o planeamento de comunicação externa, incluindo clientes, reguladores, parceiros e o público. Para responsáveis conjuntos pelo tratamento, a matriz de incidentes deve identificar quem realiza a classificação inicial da violação de dados pessoais, quem contacta o outro responsável pelo tratamento, quem determina se dados pessoais são afetados, quem avalia limiares de notificação, quem redige notificações às autoridades, quem comunica com as pessoas singulares, quem coordena o reporte NIS2 ou DORA, quem aprova declarações públicas e quem regista evidência no REG10.

Se o acordo envolver uma entidade financeira abrangida pelo DORA, o processo de incidentes também deve suportar classificação de incidentes graves relacionados com TIC, escalonamento para a direção de topo, atualizações intermédias, reporte final e comunicação a clientes quando interesses financeiros sejam afetados. Se a organização estiver no âmbito da NIS2, o reporte de incidentes significativos pode exigir notificação por fases e comunicação aos destinatários do serviço.

A prática mais segura é um exercício de tabletop conjunto antes do lançamento. Um bom cenário obriga as equipas a utilizar o REG08, o REG10, o playbook de incidentes, contactos do parceiro, modelos de notificação, árvores de escalonamento e logs de evidência sob pressão temporal.

Conformidade transversal: o Article 26 raramente existe isoladamente

Os acordos entre responsáveis conjuntos pelo tratamento inserem-se frequentemente em ecossistemas regulamentados mais amplos. Uma campanha fintech, uma plataforma de saúde conectada, uma relação de serviço gerido, uma integração em marketplace cloud ou uma parceria de infraestrutura digital pode desencadear obrigações para além do GDPR.

A NIS2 pode aplicar-se a entidades essenciais ou importantes de média e grande dimensão em setores como infraestrutura digital, computação em cloud, centros de dados, prestadores de serviços geridos, prestadores de serviços geridos de segurança, marketplaces online, motores de pesquisa e plataformas de redes sociais. O NIS2 Article 20 coloca a supervisão da gestão de riscos de cibersegurança nos órgãos de administração. O Article 21 exige medidas técnicas, operacionais e organizacionais, incluindo análise de riscos, tratamento de incidentes, continuidade de negócio, segurança da cadeia de fornecimento, desenvolvimento seguro, tratamento de vulnerabilidades, formação, cifragem, segurança de recursos humanos, controlo de acesso, gestão de ativos e autenticação. O Article 23 introduz reporte por fases para incidentes significativos.

O DORA aplica-se desde 17 de janeiro de 2025 a muitas entidades financeiras. Abrange gestão do risco das TIC, reporte de incidentes graves relacionados com TIC, testes de resiliência operacional digital, risco de terceiros de TIC, acordos contratuais com prestadores de TIC e supervisão de prestadores terceiros críticos de serviços de TIC. O DORA Article 5 coloca a governação do risco das TIC ao nível do órgão de administração. Os Articles 8 a 14 abrangem identificação de ativos, proteção, deteção, continuidade, cópia de segurança, recuperação, lições aprendidas, formação e comunicações de crise. Os Articles 17 a 20 definem o ciclo de vida e reporte de incidentes. Os Articles 28 a 30 tornam o risco de terceiros de TIC, cláusulas contratuais, registos, risco de concentração, direitos de auditoria e planeamento de saída obrigações centrais.

O NIST CSF 2.0 fornece uma camada prática de integração. A sua função GOVERN inclui obrigações legais, regulamentares, contratuais, de privacidade e de liberdades civis, responsabilização da liderança, apetite ao risco, política, supervisão e risco de fornecedores. Resultados como GV.OC-03 e GV.SC-02 alinham-se naturalmente com a evidência do Article 26, porque exigem que as obrigações legais e os papéis dos parceiros sejam compreendidos, geridos, comunicados e coordenados.

A vantagem do modelo da Clarysec é a reutilização de evidência. O REG08 não é apenas um registo do GDPR. Suporta responsabilização ISO/IEC 27701:2025, governação ISO/IEC 27001:2022, clareza dos papéis de fornecedores no NIST CSF 2.0, governação de terceiros DORA quando serviços financeiros estão envolvidos e supervisão pela gestão NIS2 quando a entidade está abrangida.

O que auditores e reguladores irão testar

Diferentes revisores abordarão a governação de responsáveis conjuntos pelo tratamento por perspetivas distintas, mas convergirão na mesma pergunta central: a organização consegue provar que a responsabilização funciona?

A postura de auditoria mais forte é a rastreabilidade. Comece pelo requisito legal, ligue-o à política PIMS, aponte para a entrada no registo, mostre o fluxo e depois apresente evidência de teste ou um registo de caso real.

Por exemplo, o GDPR Article 26 exige a repartição de responsabilidades entre responsáveis conjuntos pelo tratamento. A Política do Sistema de Gestão da Informação de Privacidade exige o REG08 antes do início do tratamento. O REG08 mostra a repartição de responsabilidades por avisos, direitos, violação de dados pessoais, retenção, gestão de fornecedores e contactos. O REG07 mostra o resumo destinado ao público. Uma simulação de pedido de exercício de direitos comprova que o fluxo funciona. As atas de revisão pela gestão mostram exceções, decisões e melhorias.

Isto é governação auditável.

A revisão pela gestão transforma o risco de privacidade em responsabilização executiva

A governação de responsáveis conjuntos pelo tratamento não deve ficar escondida numa pasta de privacidade. Pertence à revisão pela gestão porque afeta exposição regulamentar, confiança dos clientes, confiança dos pacientes, preparação para incidentes, risco de fornecedores, responsabilidade contratual e resiliência operacional.

A ISO/IEC 27001:2022 exige compromisso da liderança, papéis, recursos, alinhamento de políticas, planeamento baseado no risco, avaliação de desempenho e melhoria contínua. A NIS2 coloca obrigações de supervisão de cibersegurança nos órgãos de administração. O DORA coloca a responsabilidade última pelo risco das TIC no órgão de administração das entidades financeiras.

A Política de Papéis e Responsabilidades de Governação para PME da Clarysec, cláusula 5.5, estabelece:

Todas as decisões de segurança significativas, exceções e escalonamentos devem ser registados e rastreáveis.

Para organizações empresariais, a Política de Papéis e Responsabilidades de Governação, cláusula 5.2, exige:

Deve ser mantido um Registo de Funções e Responsabilidades, que deve incluir:

Esse registo deve incluir papéis de governação da privacidade quando afetem segurança, resposta a incidentes, garantia de fornecedores, resiliência operacional e reporte executivo. Exceções relativas a responsáveis conjuntos pelo tratamento devem ser escaladas antes do lançamento, não descobertas após uma reclamação.

Um pacote prático de revisão pela gestão deve incluir:

• Acordos novos e alterados entre responsáveis conjuntos pelo tratamento
• Estado de conclusão do REG08
• Atividades de tratamento de alto risco e estado da AIPD, quando aplicável
• Questões em aberto de fundamento de licitude ou transparência
• Desempenho de pedidos de exercício de direitos e ações de parceiros em atraso
• Resultados de exercícios de tabletop de violação de dados pessoais e lacunas não resolvidas
• Dependências de fornecedores, subcontratantes subsequentes, cloud e transferências
• Exceções de retenção e cessação
• Constatações de auditoria e estado de remediação
• Impacto de reporte no GDPR, NIS2, DORA, NIST CSF 2.0 e COBIT 2019

Uma abordagem Clarysec em cinco passos para tornar o Article 26 auditável

Se a sua organização partilha poder de decisão sobre o tratamento de dados pessoais com outra parte, não espere por uma reclamação, auditoria, violação de dados pessoais ou disputa com um parceiro para clarificar responsabilidades.

Use esta abordagem em cinco passos:

1. Use o passo 2 do Zenith Blueprint para identificar partes interessadas, requisitos legais, expectativas de parceiros, obrigações de privacidade e âmbito regulamentar.
2. Use o passo 4 do Zenith Blueprint para construir uma RACI para avisos, fundamento de licitude, direitos, comunicação de violações de dados pessoais, retenção, transferências, fornecedores, evidência de auditoria e cessação.
3. Registe a atividade de tratamento no REG02 e a repartição de responsabilidades entre responsáveis conjuntos pelo tratamento no REG08, usando o conjunto de políticas PIMS da Clarysec.
4. Mapeie o acordo através do Zenith Controls, especialmente o ISO/IEC 27002:2022 Control 5.2, Control 5.31 e Control 5.34.
5. Teste o acordo com uma simulação de pedido de exercício de direitos e um exercício de tabletop de violação de dados pessoais antes do início do tratamento.

A CareConnect e a MetroHealth não precisavam de mais alinhamento informal. Precisavam de uma repartição de responsabilidades documentada, um resumo destinado ao público, um fluxo de direitos, um registo de coordenação de violação de dados pessoais, cláusulas contratuais e evidência de revisão pela gestão.

Essa é a diferença entre “pensámos que o parceiro tratava disso” e “aqui está o acordo aprovado, o aviso, o fluxo, a evidência de teste e o registo de decisão sobre a violação de dados pessoais”.

A Clarysec pode ajudar a implementar a governação PIMS ISO/IEC 27701:2025, alinhá-la com o GDPR Article 26, integrá-la no seu SGSI ISO/IEC 27001:2022 e produzir evidência pronta para auditoria face às expectativas do GDPR, NIS2, DORA, NIST CSF 2.0 e COBIT 2019.

Pronto para substituir a ambiguidade entre responsáveis conjuntos pelo tratamento por evidência pronta para auditoria? Explore o Zenith Blueprint: roteiro de auditor em 30 passos, use o Zenith Controls: guia de conformidade transversal ou contacte a Clarysec para uma avaliação PIMS e SGSI que transforme o Article 26 num sistema de controlos operacionais antes de a sua próxima parceria entrar em produção.