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

Governação de acordos de partilha de dados no RGPD da UE e na ISO 27701

Igor Petreski

São 16h00 de uma terça-feira e Sarah, Diretora de Segurança da Informação (CISO) de uma fintech em rápido crescimento, está a analisar um acordo de partilha de dados apresentado por um parceiro estratégico de análise de dados com IA. A equipa comercial está entusiasmada. O parceiro promete melhor conhecimento sobre os clientes, maior personalização e uma previsão mais rápida do abandono de clientes. A equipa jurídica está cautelosa. O acordo está cheio de expressões vagas como “segurança comercialmente razoável” e quase nada diz sobre prazos de resposta a incidentes, tratamento dos direitos dos titulares dos dados, retenção, eliminação, direitos de auditoria ou planeamento de saída.

Sarah identifica o risco de imediato. O parceiro atua como subcontratante, responsável pelo tratamento independente ou responsável conjunto pelo tratamento? Quem valida o fundamento de licitude ao abrigo do RGPD da UE? Se um cliente apresentar um pedido de apagamento, que processo garante que os dados são eliminados do ambiente do parceiro, dos conjuntos de dados derivados e, quando aplicável, das cadeias de treino de IA? Se o parceiro sofrer uma violação de dados pessoais, quem informa quem, quando e com que evidência?

Isto não é apenas um contrato deficiente. É uma falha do modelo operacional.

As empresas modernas de SaaS, fintech, healthtech, serviços geridos e plataformas partilham dados continuamente através de API, integrações, parcerias de análise de dados, ferramentas de suporte, plataformas de nuvem, afiliadas, pedidos do setor público e serviços de IA. A linguagem comercial avança frequentemente mais depressa do que a governação. Um contrato é assinado, uma chave de API é emitida e os dados pessoais começam a circular antes de privacidade, segurança, compras, engenharia e o Encarregado da Proteção de Dados terem acordado os princípios básicos.

Ao abrigo do RGPD da UE, um acordo de partilha de dados não é apenas um artefacto jurídico. É evidência de licitude, lealdade, transparência, limitação das finalidades, minimização dos dados, limitação da conservação, integridade, confidencialidade e responsabilização. Ao abrigo da ISO/IEC 27701:2025, passa a integrar um Sistema de Gestão da Informação de Privacidade, ou PIMS, através do qual a organização consegue demonstrar que a informação pessoal é recolhida, utilizada, divulgada, partilhada, retida, protegida e eliminada por processos governados.

A Clarysec trata a governação da partilha de dados como um sistema de controlos interfuncional, não como um exercício de modelo contratual. Com o Zenith Blueprint, os Zenith Controls e o conjunto de políticas PIMS da Clarysec, as organizações podem passar de revisões ad hoc de acordos para um ciclo de vida pronto para auditoria que liga cláusulas jurídicas, registos, decisões de risco, controlos técnicos e evidência de conformidade.

Porque falham os acordos de partilha de dados em auditorias reais

A maioria das organizações não falha por nunca ter elaborado um contrato. Falha porque o contrato está desligado da realidade operacional.

Um revisor de privacidade solicita o registo de partilha de dados. A equipa jurídica envia o acordo assinado. O revisor pede então o fundamento de licitude, a finalidade da divulgação, a função do destinatário, as categorias de PII, a regra de retenção, o local de tratamento, o método de transferência, o encaminhamento dos pedidos de exercício de direitos dos titulares dos dados, as salvaguardas técnicas e a evidência de revisão. De repente, o acordo assinado é apenas uma peça do puzzle.

O Article 5 do RGPD da UE exige que o tratamento de dados pessoais observe a licitude, lealdade, transparência, limitação das finalidades, minimização dos dados, exatidão, limitação da conservação e integridade e confidencialidade. O Article 5(2) acrescenta a responsabilização, ou seja, o responsável pelo tratamento deve conseguir demonstrar o cumprimento. O Article 6 exige um fundamento de licitude válido. O Article 9 eleva o nível de exigência para categorias especiais de dados pessoais, incluindo dados de saúde, biométricos, genéticos, políticos, religiosos e outras categorias sensíveis.

Na prática, um processo de governação de acordos de partilha de dados deve responder a estas perguntas antes do início de uma partilha externa recorrente:

  • Quem é o destinatário e qual é a sua função em matéria de privacidade?
  • Que dados pessoais são partilhados e para que finalidade?
  • Que fundamento de licitude suporta a divulgação?
  • A nova finalidade é compatível com a finalidade original da recolha?
  • Os titulares dos dados foram informados através de um aviso de privacidade ou de outro mecanismo de transparência?
  • Que registos, aprovações e decisões de risco evidenciam a partilha?
  • Como são encaminhados os direitos dos titulares dos dados entre as partes?
  • Que obrigações de retenção, eliminação, devolução e cessação se aplicam?
  • Que salvaguardas protegem a transferência, o armazenamento, o acesso, o registo, a divulgação ulterior e a auditabilidade?
  • O que acontece se o parceiro alterar a finalidade, a localização, os subcontratantes ou as categorias de dados?

O Zenith Blueprint, fase Controls in Action, Step 23, resume claramente a realidade de auditoria:

A base deste controlo é a consciência dos dados. A organização deve saber que PII recolhe, onde reside, porque está a ser tratada e quem pode aceder-lhe. Sem esta linha de base, quaisquer promessas de privacidade são vazias. A classificação e a rotulagem (5.12–5.13) tornam-se essenciais neste ponto, porque a PII não pode ser protegida se não for identificada.

Se o acordo não estiver ligado ao inventário, à classificação, à retenção, aos controlos de segurança e ao processo de exercício de direitos, não há governação. Há apenas um documento num repositório.

A partilha de dados não é o mesmo que o tratamento por conta de um cliente

Um erro frequente é tratar todas as relações com terceiros que envolvem dados pessoais como cenários de subcontratação. O RGPD da UE exige análise das funções das partes. Um subcontratante atua por conta de um responsável pelo tratamento. Um responsável pelo tratamento determina as finalidades e os meios. Responsáveis conjuntos pelo tratamento determinam conjuntamente as finalidades e os meios. Alguns destinatários são responsáveis pelo tratamento independentes que recebem dados para as suas próprias finalidades.

Esta distinção altera o modelo de acordo.

Um acordo de subcontratação centra-se em instruções documentadas, confidencialidade, subcontratantes subsequentes, assistência, segurança, notificação de violação de dados pessoais, eliminação ou devolução e apoio à auditoria. Um acordo de partilha de dados entre responsáveis pelo tratamento centra-se mais intensamente no fundamento de licitude, finalidade, transparência, independência do destinatário, limites à divulgação ulterior, coordenação dos pedidos de exercício de direitos, retenção, salvaguardas de segurança e repartição de responsabilidades. Um acordo entre responsáveis conjuntos pelo tratamento exige repartição transparente das obrigações e clareza sobre a tomada de decisão partilhada.

As políticas PIMS da Clarysec tornam esta classificação um ponto de controlo obrigatório. A política Enterprise Processor, Subprocessor and Third-Party Privacy Management Policy estabelece:

[Ambos] O Responsável de Privacidade / Gestor do PIMS DEVE classificar cada relação de privacidade com terceiros como responsável pelo tratamento, responsável conjunto pelo tratamento, subcontratante, subcontratante subsequente ou outra relação com terceiros em REG08 antes da aprovação do contrato ou antes do início do tratamento de PII, consoante o que ocorrer primeiro.

Para PME, o mesmo princípio é expresso de forma mais simples. A Data Protection and Privacy Policy - SME, Governance Requirements 5.2.2, exige:

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.

A lição é prática: antes de redigir cláusulas, classifique a relação. A função determina o acordo, as aprovações, as salvaguardas, as responsabilidades e a evidência.

O ciclo de vida da governação da partilha de dados

Um fluxo de trabalho maduro para acordos de partilha de dados deve funcionar como um processo de negócio controlado, não como uma escalada jurídica de emergência. A Clarysec implementa-o normalmente através de sete pontos de controlo interligados.

Ponto de controlo de governaçãoDecisão a tomarEvidência a reter
1. ReceçãoQue atividade de partilha de dados é proposta, por quem e para que finalidade de negócio?Formulário de receção, proprietário de negócio, destinatário, conjunto de dados, data de início prevista
2. Classificação de funçõesO destinatário é responsável pelo tratamento, responsável conjunto pelo tratamento, subcontratante, subcontratante subsequente ou outro terceiro?Classificação e aprovação da relação em REG08
3. Fundamento de licitude e finalidadeQue fundamento de licitude do RGPD da UE suporta a divulgação e a finalidade é compatível?Registo de tratamento REG02, nota de fundamento de licitude, avaliação de compatibilidade se necessário
4. Dados e classificaçãoQue categorias e classificações de PII são partilhadas?Inventário de dados, etiqueta de classificação, revisão de minimização dos dados
5. Contrato e salvaguardasQue cláusulas contratuais, controlos de segurança, termos de transferência e limites à partilha ulterior se aplicam?DSA, DPA, termos entre responsáveis conjuntos pelo tratamento, anexo de segurança, controlos de transferência
6. Integração operacionalComo são tratados os pedidos de exercício de direitos, incidentes, retenção, eliminação, pedidos de auditoria e revisões?Fluxo de trabalho dos pedidos de exercício de direitos, interface de incidentes, calendário de retenção, calendário de revisão
7. Garantia contínuaA partilha continua a ser necessária, segura, lícita e alinhada com avisos e registos?Revisão periódica, evidência de auditoria, ações corretivas, evidência de cessação

A política Enterprise PII Collection, Use, Disclosure and Sharing Policy torna explícito o requisito do lado do responsável pelo tratamento:

[Responsável pelo tratamento] O Responsável por Fornecedores / Compras DEVE registar a identidade do destinatário, a função do destinatário, a finalidade da divulgação, as categorias de PII, a frequência da partilha, o local de tratamento e a fonte de autorização em REG08 antes do início de uma partilha externa recorrente.

REG08 é o registo de destinatários e de relações de privacidade com terceiros. Não deve existir separado do inventário de tratamento. A política Enterprise PII Processing Inventory and Lawful Basis Policy exige:

[Ambos] O Responsável por Fornecedores / Compras DEVE verificar que as entradas relativas a destinatários externos, subcontratantes, subcontratantes subsequentes e partilha de dados em REG02 estão alinhadas com REG08 antes da aprovação do acordo ou de uma alteração material da relação.

Isto fecha uma lacuna de auditoria comum. REG02 pode indicar “análise de dados de produto para melhoria interna”, enquanto REG08 indica “parceiro de análise de dados para benchmarking”. Se a finalidade, o destinatário, o fundamento de licitude, as categorias de dados ou as regras de retenção não estiverem alinhados, a organização tem uma deficiência de responsabilização.

O que deve conter cada acordo de partilha de dados

Um acordo de partilha de dados ao abrigo do RGPD da UE e da ISO 27701:2025 não deve depender de linguagem genérica de confidencialidade. Deve refletir o fluxo real de dados, a classificação das funções das partes, o perfil de risco e as interfaces operacionais.

Área da cláusulaPorque é importante
Partes e funçõesConfirma se cada parte é responsável pelo tratamento independente, responsável conjunto pelo tratamento, subcontratante ou outro destinatário
Finalidade e fundamento de licitudeLiga a divulgação a uma finalidade válida e a um fundamento de licitude ao abrigo do RGPD da UE
Categorias de dados e titulares dos dadosLimita o acordo a categorias de PII definidas e aos titulares dos dados afetados
Minimização dos dadosImpede a partilha de campos que não são necessários para a finalidade
Obrigações de transparênciaReparte responsabilidades relativas a avisos de privacidade e comunicações
Condições relativas a categorias especiaisAcrescenta salvaguardas explícitas e justificação quando estão envolvidos dados do Article 9
Método de transferênciaExige canais seguros, como API cifradas, SFTP, portais seguros ou controlos equivalentes
Controlo de acessoDefine quem pode aceder aos dados partilhados e como o acesso é aprovado, revisto e revogado
Retenção e eliminaçãoDefine limites de retenção, eventos de apagamento, obrigações de devolução e requisitos de evidência
Divulgação ulteriorRestringe a partilha com afiliadas, subcontratantes, organismos públicos ou parceiros comerciais sem condições
Cooperação em pedidos de exercício de direitosDefine encaminhamento, confirmação, validação de identidade, coordenação de resposta e evidência de encerramento
Notificação de incidentesDefine prazos de notificação, conteúdo, contactos de escalada e expectativas de cooperação
Auditoria e garantiaPermite a revisão de evidência, atestados de controlo, certificações ou apoio à auditoria
Controlo de alteraçõesExige reavaliação para novas finalidades, novas categorias de dados, novas localizações ou novos destinatários
CessaçãoAbrange devolução dos dados, destruição, revogação de acessos e certificação da eliminação

O Zenith Blueprint, fase Controls in Action, Step 23, apresenta a perspetiva dos acordos com fornecedores:

As principais áreas normalmente tratadas em acordos com fornecedores incluem:

✓ Obrigações de confidencialidade, incluindo âmbito, duração e restrições de divulgação a terceiros; ✓ Responsabilidades de controlo de acesso, como quem pode aceder aos seus dados, como são geridas as credenciais e que monitorização está implementada; ✓ Medidas técnicas e organizativas para proteção de dados, cifragem, transmissão segura, cópia de segurança e compromissos de disponibilidade; ✓ Prazos e protocolos de comunicação de incidentes, frequentemente com prazos definidos (por exemplo, “notificar no prazo de 24 horas”); ✓ Direito de auditoria, incluindo frequência, âmbito e acesso a evidência relevante (por exemplo, relatórios de testes de intrusão, SoA, certificações); ✓ Controlos de subcontratantes, exigindo que o fornecedor transmita obrigações de segurança equivalentes aos seus parceiros a jusante; ✓ Disposições de fim de contrato, como devolução ou destruição de dados, recuperação de ativos e desativação de contas.

A governação jurídica empresarial reforça este ponto. A Legal and Regulatory Compliance Policy, Governance Requirements 5.3.1.2, identifica contratos que envolvem:

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

Isto coloca a governação da partilha de dados na interseção entre privacidade, jurídico, risco comercial, garantia de fornecedores e operações de segurança.

Classificação e transferência segura são a ponte em falta

Muitas falhas de partilha de dados começam com uma classificação deficiente. Se o proprietário de negócio não consegue indicar se o conjunto de dados é público, interno, confidencial, restrito ou contém PII regulada, o acordo será vago e os controlos técnicos serão inconsistentes.

A Data Classification and Labeling Policy - SME da Clarysec estabelece:

Os acordos de partilha de dados ou os Acordos de Confidencialidade (NDA) devem referenciar os requisitos de tratamento associados à classificação.

Para ambientes empresariais, a Data Classification and Labeling Policy exige que determinados dados:

Só possam ser partilhados externamente ao abrigo de um NDA ou de salvaguardas contratuais equivalentes.

A etiqueta de classificação deve constar do acordo ou do anexo de segurança. Se o histórico de pedidos de suporte estiver classificado como confidencial e contiver PII, o acordo deve definir destinatários permitidos, métodos de transferência aprovados, locais de armazenamento, controlos de acesso, monitorização, expectativas de eliminação e evidência de garantia.

O Zenith Blueprint, fase Controls in Action, Step 22, explica o lado operacional da transferência de informação:

No essencial, este controlo exige que a organização:

✓ Defina como a informação pode ser transferida, tanto interna como externamente; ✓ Determine que métodos são permitidos (por exemplo, correio eletrónico cifrado, portais seguros, SFTP, API, entrega física com cifragem); ✓ Alinhe os métodos de transferência com a classificação da informação (conforme definido em 5.12 e tornado visível através de 5.13); ✓ E assegure que todas as partes envolvidas na transferência compreendem as suas funções, responsabilidades e obrigações.

Para PME, a Third-Party and Supplier Security Policy - SME define a expectativa de forma direta:

Todos os dados partilhados com fornecedores devem ser protegidos por cifragem e transmitidos através de protocolos seguros (por exemplo, HTTPS, SFTP).

A governação empresarial de fornecedores acrescenta mais detalhe. A Third party and supplier security policy exige requisitos de tratamento de dados, incluindo:

Requisitos de tratamento de dados, incluindo local de armazenamento, controlos de acesso e cláusulas de devolução ou destruição.

Estes requisitos não devem ficar enterrados num questionário. Devem ser termos contratuais exigíveis e rastreáveis até REG08, à configuração técnica e à evidência de auditoria.

Exemplo: aprovação do parceiro de análise de dados com IA de Sarah

A fintech de Sarah pretende partilhar IDs pseudonimizados de clientes, padrões de transações, métricas de utilização e informação sobre o nível de suporte com um parceiro de análise de dados com IA para personalização e previsão de abandono de clientes. O parceiro pode combinar os dados com os seus modelos analíticos e devolver informação acionável à fintech.

Um fluxo de trabalho governado seria assim.

Primeiro, o Responsável por Fornecedores ou Compras cria a entrada REG08. O Responsável de Privacidade ou Gestor do PIMS classifica a relação. Se o parceiro determinar finalidades de análise de dados e a conceção do modelo para além das instruções de Sarah, a função pode ser responsável pelo tratamento independente ou responsável conjunto pelo tratamento, em vez de subcontratante.

CampoValor de exemplo
DestinatárioAI Analytics Inc.
Função do destinatárioResponsável pelo tratamento independente, pendente de validação jurídica final
Fundamento de licitudeInteresses legítimos, avaliação de interesses legítimos (LIA) arquivada
Categorias de PIIID de cliente, histórico de transações, métricas de utilização, nível de suporte
SalvaguardasPseudonimização, minimização ao nível do campo, API cifrada, registo de acessos
FinalidadePersonalização do produto e previsão de abandono de clientes
Frequência de partilhaDiária via API
Local de tratamentoUE, Irlanda
Acordo aplicávelDSA-2026-042
Data de revisão2027-04-01

Segundo, REG02 é reconciliado. Se o inventário de tratamento apenas descrever “análise de dados de produto interna”, deve ser atualizado antes do início da partilha externa. O fundamento de licitude deve ser documentado e, se a finalidade tiver sido alterada, pode ser necessária uma avaliação de compatibilidade ou uma avaliação de interesses legítimos.

Terceiro, o proprietário dos dados aplica classificação e minimização dos dados. Domínios de correio eletrónico de administradores podem não ser necessários. IDs de conta podem ser substituídos por IDs pseudónimos específicos do parceiro. O nível de suporte só deve ser retido se for necessário para a finalidade aprovada.

Quarto, jurídico, privacidade e segurança negoceiam o acordo de partilha de dados e o anexo de segurança. O acordo proíbe a reidentificação, restringe a divulgação ulterior, define a retenção, exige evidência de eliminação, especifica prazos de notificação de incidentes, inclui direitos de auditoria ou garantia e define os passos de saída.

Quinto, o aviso de privacidade e o fluxo de trabalho dos pedidos de exercício de direitos são atualizados. A política Enterprise PII Principal Rights Management Policy exige:

[Ambos] O Responsável por Fornecedores / Compras DEVE acompanhar a confirmação de terceiros relativamente a notificações relacionadas com direitos em REG08 antes de encerrar o pedido REG06 relacionado.

Para PME, a Data Protection and Privacy Policy - SME define uma expectativa prática de nível de serviço:

O Coordenador de Privacidade deve acusar a receção dos pedidos no prazo de 3 dias úteis e responder no prazo de 30 dias.

Por fim, a engenharia aplica o acordo. As credenciais de API são delimitadas. As transferências utilizam HTTPS. Os logs capturam extrações de dados. Os alertas detetam atividade invulgar. O acesso é revisto. A retenção é automatizada sempre que possível. O acordo torna-se um sistema de controlos vivo, não um PDF.

Mapeamento entre referenciais para RGPD da UE, ISO 27701, DORA, NIS2, NIST e COBIT 19

A governação da partilha de dados raramente pertence a um único referencial. Toca a responsabilização no RGPD da UE, as operações de privacidade da ISO/IEC 27701:2025, os requisitos de sistema de gestão da ISO/IEC 27001:2022, os controlos de segurança da ISO/IEC 27002:2022, o risco de terceiros de DORA, a segurança da cadeia de fornecimento da NIS2, os resultados do NIST CSF 2.0 e as expectativas de governação do COBIT 19.

A cláusula 4.2 da ISO/IEC 27001:2022 exige que as organizações compreendam as partes interessadas e os seus requisitos relevantes. A cláusula 5.1 exige que a liderança integre os requisitos de segurança da informação nos processos de negócio. Para a partilha de dados, isto significa que dependências de parceiros, requisitos contratuais, obrigações regulamentares e decisões de risco devem estar dentro do SGSI e do PIMS, não fora deles.

Os controlos mais relevantes da ISO/IEC 27002:2022 são:

  • 5.14 Transferência de informação
  • 5.20 Tratamento da segurança da informação em acordos com fornecedores
  • 5.34 Privacidade e proteção de PII

Os Zenith Controls ajudam as organizações a utilizar estes controlos como âncoras de mapeamento. Ligam o controlo 5.14 da ISO/IEC 27002:2022 à proteção dos dados em trânsito e aos requisitos contratuais, incluindo NIST CSF 2.0 PR.DS-02 e GV.SC-05, DORA Article 30(2)(d) e GDPR Article 46 quando sejam relevantes salvaguardas de transferência internacional. Ligam o controlo 5.20 à governação de acordos com fornecedores, incluindo NIS2 Article 21(2)(d) sobre segurança da cadeia de fornecimento e DORA Chapter V sobre risco de terceiros de TIC. Ligam o controlo 5.34 à privacidade e proteção de PII, incluindo GDPR Article 5(2) sobre responsabilização e controlos de suporte como cifragem, eliminação, gestão de fornecedores e limitação das finalidades.

Perspetiva do referencialO que a governação da partilha de dados deve demonstrar
RGPD da UEFundamento de licitude, transparência, limitação das finalidades, minimização dos dados, retenção, segurança, responsabilização, cooperação no exercício de direitos
ISO/IEC 27701:2025Clareza de funções no PIMS, controlos de privacidade, tratamento documentado, governação da divulgação, evidência das operações de privacidade
ISO/IEC 27001:2022Âmbito do SGSI, avaliação de riscos, tratamento, controlos de fornecedores, controlos de transferência, monitorização, auditoria, revisão pela gestão
ISO/IEC 27002:2022Transferência de informação, segurança de acordos com fornecedores, privacidade e proteção de PII
NIS2Supervisão pela gestão, segurança da cadeia de fornecimento, gestão de riscos numa abordagem a todos os perigos, tratamento de incidentes, formação, controlo de acesso
DORACiclo de vida de terceiros de TIC, registos contratuais, apoio a incidentes, direitos de auditoria, localização dos dados, saída e resiliência
NIST CSF 2.0Resultados GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND, RECOVER para risco de terceiros e risco de dados
COBIT 19Objetivos de governação, responsabilização, propriedade do risco, desempenho dos controlos, garantia e melhoria

O objetivo não é criar sete programas de conformidade. O objetivo é um ciclo de vida único e governado de partilha de dados que produza evidência reutilizável.

Como os auditores irão testar os seus acordos de partilha de dados

Um processo de governação robusto deve resistir à amostragem. Os auditores não se limitarão ao acordo assinado. Testarão o ciclo de vida.

Um auditor de ISO/IEC 27001:2022 e ISO/IEC 27701:2025 perguntará se o âmbito do SGSI e do PIMS inclui a partilha externa, se a avaliação de riscos cobre a relação, se os controlos foram selecionados e operados e se a gestão revê o risco de privacidade e segurança de terceiros.

Um revisor do RGPD da UE ou uma autoridade de controlo focar-se-á na responsabilização. Perguntará que dados pessoais foram partilhados, porquê, com que fundamento de licitude, se os titulares dos dados foram informados, durante quanto tempo os dados foram retidos, se estiveram envolvidas categorias especiais de dados, se as transferências internacionais foram avaliadas e se os pedidos de exercício de direitos foram encaminhados e evidenciados.

Um revisor de DORA, especialmente nos serviços financeiros, perguntará se o acordo suporta uma função crítica ou importante, se consta do registo contratual de TIC, se o contrato inclui assistência em incidentes, direitos de auditoria, localização dos dados, condições de subcontratação, direitos de cessação e planeamento de saída testado.

Um avaliador de NIST CSF 2.0 procurará resultados GOVERN na gestão de risco de fornecedores, resultados PROTECT em controlos de dados em trânsito, resultados RESPOND em interfaces de incidentes e resultados RECOVER no planeamento de saída e continuidade.

Um auditor COBIT 19 ou de estilo ISACA focar-se-á em direitos de decisão, apetite ao risco, realização de benefícios, otimização de recursos, obrigações de conformidade, métricas, exceções e melhoria contínua.

Teste de auditoriaEvidência esperada
Selecionar um parceiro ativo de partilha de dadosDSA assinado ou equivalente, entrada REG08, classificação de funções
Rastrear até ao inventário de tratamentoEntrada REG02 com finalidade, fundamento de licitude, categorias de PII, retenção, destinatários
Verificar a classificaçãoRegisto de classificação de dados e requisitos de tratamento referenciados no acordo
Verificar os controlos de segurançaCifragem, protocolo seguro, controlo de acesso, logs, local de armazenamento, evidência de monitorização
Verificar o processo de exercício de direitosEvidência do pedido REG06, notificação ao destinatário, confirmação acompanhada em REG08
Verificar retenção e cessaçãoRegra de retenção, procedimento de eliminação, cláusula de devolução ou destruição, certificado de eliminação se terminado
Verificar a revisãoRegisto de revisão periódica, alterações avaliadas, exceções e ações corretivas acompanhadas

Se a sua equipa não conseguir reunir esta evidência rapidamente, o processo depende demasiado da memória.

Armadilhas comuns na governação da partilha de dados

A Clarysec observa repetidamente cinco padrões de falha.

O primeiro é confundir um DPA com um acordo de partilha de dados. Cláusulas de subcontratação não resolvem a responsabilização entre responsáveis pelo tratamento ou entre responsáveis conjuntos pelo tratamento.

O segundo é uma higiene deficiente dos registos. REG02 e REG08 não coincidem. O aviso de privacidade refere genericamente “parceiros comerciais”, mas o inventário de tratamento não contém uma finalidade de divulgação correspondente.

O terceiro é o mau encaminhamento dos pedidos de exercício de direitos. Um titular dos dados solicita o apagamento, mas ninguém sabe que destinatários devem ser notificados nem como a confirmação é acompanhada.

O quarto é linguagem genérica de segurança. “Segurança adequada” não basta. O acordo deve especificar métodos de transferência, cifragem, controlos de acesso, logs, local de armazenamento, prazos de incidentes, eliminação e garantia.

O quinto é ignorar a divulgação ulterior. Os ecossistemas SaaS modernos incluem plataformas de nuvem, serviços de IA, fornecedores de análise de dados, ferramentas de suporte, prestadores geridos, afiliadas e organismos públicos. A governação da partilha de dados deve controlar a divulgação a jusante quando esta afeta a responsabilização.

A Processor, Subprocessor and Third-Party Privacy Management Policy capta a ligação operacional para relações com subcontratantes e subcontratantes subsequentes:

[Ambos] O Responsável por Fornecedores / Compras DEVE assegurar que os contratos com subcontratantes e subcontratantes subsequentes incluem assistência em matéria de privacidade, garantia de segurança, interface de incidentes através de PII15, devolução ou eliminação através de PII10, ligação de transferência através de PII13 e cooperação em auditoria ou garantia antes da aprovação.

Mesmo quando a relação é entre responsáveis pelo tratamento, a lógica de governação continua a ser valiosa: assistência em matéria de privacidade, garantia de segurança, interface de incidentes, ligação de transferência, devolução ou eliminação e cooperação em auditoria devem ser concebidas deliberadamente.

Lista de verificação prática para o seu próximo acordo de partilha de dados

Utilize esta lista de verificação antes de aprovar a partilha externa recorrente de dados pessoais.

  • Confirme a função de privacidade do destinatário em REG08.
  • Confirme que REG02 e REG08 estão alinhados antes da aprovação.
  • Documente a finalidade da divulgação e o fundamento de licitude.
  • Verifique se uma nova finalidade exige avaliação de compatibilidade.
  • Identifique categorias de PII, categorias de titulares dos dados e categorias especiais de dados.
  • Aplique minimização dos dados e remova campos desnecessários.
  • Referencie no acordo os requisitos de tratamento associados à classificação.
  • Defina métodos de transferência aprovados e requisitos de cifragem.
  • Especifique expectativas relativas a controlo de acesso, logs, monitorização e local de armazenamento.
  • Reparta responsabilidades de transparência e atualizações do aviso de privacidade.
  • Defina encaminhamento, confirmação, acompanhamento e evidência de encerramento dos pedidos de exercício de direitos.
  • Defina evidência de retenção, eliminação, devolução e cessação.
  • Restrinja a divulgação ulterior e exija notificação de alterações.
  • Inclua prazos de notificação de incidentes e requisitos de cooperação.
  • Inclua direitos de auditoria, garantia ou revisão de evidência.
  • Agende revisões periódicas e eventos de reavaliação.

Onde entra a Clarysec

O valor da Clarysec não está apenas nos modelos. Está na ligação entre políticas, registos, evidência, lógica de auditoria e mapeamento entre referenciais.

O Zenith Blueprint fornece às equipas de implementação um roteiro de 30 passos para transformar requisitos de controlo em práticas operacionais. Para a partilha de dados, o Step 22 ajuda as equipas a desenhar regras de transferência de informação, enquanto o Step 23 liga privacidade, acordos com fornecedores, requisitos legais, proteção de PII e obrigações contratuais.

Os Zenith Controls fornecem a bússola de mapeamento entre referenciais. Neste tema, ligam os controlos 5.34, 5.14 e 5.20 da ISO/IEC 27002:2022 à narrativa de auditoria mais ampla: proteção da privacidade, transferência de informação e governação de acordos com fornecedores. Ajudam CISO, Encarregados da Proteção de Dados, gestores de conformidade, equipas de compras e auditores a falar a mesma linguagem ao mapear expectativas do RGPD da UE, ISO/IEC 27701:2025, ISO/IEC 27001:2022, NIS2, DORA, NIST CSF 2.0 e COBIT 19.

O conjunto de políticas PIMS da Clarysec fornece então às organizações as regras operacionais: classificar relações de privacidade, manter registos de tratamento e de destinatários, verificar o alinhamento entre registos, definir fundamento de licitude, gerir os direitos dos titulares dos dados, controlar cláusulas de fornecedores e terceiros, aplicar requisitos de tratamento por classificação e preservar evidência.

Se a sua organização partilha dados pessoais com parceiros, plataformas, afiliadas, organismos públicos, prestadores de análise de dados, serviços de IA ou participantes do ecossistema SaaS, não comece pelo contrato. Comece pela governação.

Utilize o Zenith Blueprint: An Auditor’s 30-Step Roadmap para enquadrar a partilha de dados no seu plano de implementação do SGSI e do PIMS. Utilize os Zenith Controls: The Cross-Compliance Guide para mapear os controlos 5.34, 5.14 e 5.20 da ISO/IEC 27002:2022 face às expectativas de garantia do RGPD da UE, NIS2, DORA, NIST e COBIT. Em seguida, implemente as políticas PIMS da Clarysec, incluindo a PII Collection, Use, Disclosure and Sharing Policy, a PII Processing Inventory and Lawful Basis Policy e a Processor, Subprocessor and Third-Party Privacy Management Policy, para que cada acordo seja suportado por registos, fluxos de trabalho, salvaguardas e evidência.

A próxima ação prática é simples: selecione as três relações externas de partilha de dados com maior risco e teste-as contra REG02, REG08, fundamento de licitude, encaminhamento dos pedidos de exercício de direitos, controlos de transferência, retenção e evidência de auditoria. Se a cadeia de evidência falhar, a Clarysec pode ajudar a reconstruí-la num modelo de governação de partilha de dados pronto para auditoria.

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