Aplicabilidade dos controlos ISO 27701 de acordo com as funções do RGPD da UE
São 08:40 de uma terça-feira e Maria, CISO de uma empresa SaaS de tecnologia de saúde em rápido crescimento, está a olhar para quatro mensagens de correio eletrónico de clientes que parecem quase idênticas, mas que significam coisas muito diferentes.
Um cliente empresarial pede evidência de que a empresa pode atuar como subcontratante ao abrigo do Article 28 do RGPD da UE. Um segundo pergunta se a plataforma também atua como responsável pelo tratamento para telemetria e análise de produto. Um terceiro solicita a lista atual de subcontratantes subsequentes e prova de que as cláusulas do Acordo de Tratamento de Dados são repercutidas em cadeia. Um quarto, um cliente fintech a preparar revisões de fornecedores no âmbito do DORA, pergunta se os mesmos controlos de privacidade estão mapeados para resiliência operacional, notificação de incidentes e risco de terceiros TIC.
A empresa de Maria não é negligente. Tem um SGSI alinhado com a ISO/IEC 27001:2022, políticas de privacidade, um registo de atividades de tratamento, MFA, cifragem, revisão de acessos e formação em privacidade desde a conceção. Mas o pedido expõe a pergunta mais difícil que auditores e clientes realmente testam:
A empresa consegue demonstrar que os controlos corretos do PIMS ISO 27701 se aplicam à função correta no RGPD da UE, para a atividade de tratamento correta, com o proprietário, a evidência e a justificação corretos?
É aqui que muitos programas de privacidade falham. Tratam a ISO 27701 como uma lista de verificação, quando organismos de certificação, auditores de clientes e Encarregados da Proteção de Dados esperam uma decisão fundamentada sobre a aplicabilidade dos controlos. A resposta não é “temos controlos de privacidade”. A resposta é “para esta atividade de tratamento, somos responsáveis pelo tratamento, subcontratantes, responsáveis conjuntos pelo tratamento ou subcontratantes subsequentes, e é por isto que estes controlos se aplicam ou não se aplicam”.
Porque a aplicabilidade dos controlos ISO 27701 é a camada PIMS em falta
As funções do RGPD da UE baseiam-se na autoridade de decisão. Um responsável pelo tratamento determina as finalidades e os meios do tratamento. Um subcontratante atua em nome de um responsável pelo tratamento. Os responsáveis conjuntos pelo tratamento determinam conjuntamente as finalidades e os meios. Um subcontratante subsequente é contratado por um subcontratante para tratar dados pessoais a jusante.
Em ambientes SaaS reais, essas funções raramente são uniformes ao nível da empresa. A organização de Maria é subcontratante quando aloja dados de bem-estar de clientes, responsável pelo tratamento para processamento salarial de trabalhadores e contactos de marketing, possível responsável pelo tratamento para telemetria de produto dependendo da finalidade e dos termos contratuais, e responsável conjunto pelo tratamento numa campanha de marca partilhada. Se um prestador de serviços geridos de maior dimensão revender a sua plataforma, a empresa também pode tornar-se subcontratante subsequente nessa cadeia.
A aplicabilidade dos controlos ISO 27701 é a disciplina que impede que essas funções se degradem em declarações vagas. Pergunta:
- Que atividade de tratamento está abrangida pelo âmbito?
- Que função do RGPD da UE desempenha a organização nessa atividade?
- Que controlos PIMS se aplicam devido a essa função?
- Que controlos são excluídos e porquê?
- Que evidência comprova a implementação?
- Que requisito legal, contratual, de risco ou de âmbito determinou a decisão?
A Política do Sistema de Gestão de Informação de Privacidade da Clarysec define a classificação de funções como ponto de partida:
“[Ambos] O Proprietário do Processo / Responsável de Negócio DEVE classificar a função da organização no PIMS para cada atividade de tratamento de PII no REG02 antes do início da atividade de tratamento.”
Da secção “Determinação da função no PIMS”, cláusula 4.2.1 da política.
A mesma política liga essa decisão sobre a função à aplicabilidade dos controlos:
“[Ambos] O Responsável pela Privacidade / Gestor do PIMS DEVE manter o REG03 com controlos incluídos, controlos excluídos, estado de implementação e justificação, anualmente e no prazo de 30 dias após cada alteração ao tratamento de riscos de privacidade.”
Da secção “Política de privacidade, objetivos e aplicabilidade dos controlos”, cláusula 4.3.3 da política.
O REG02 responde que tratamento existe e que função se aplica. O REG03 responde que controlos se aplicam, o que está excluído, que evidência existe e porque é que a decisão é defensável.
Construir o PIMS sobre a lógica da Declaração de Aplicabilidade da ISO/IEC 27001:2022
Um PIMS baseado em funções funciona melhor quando é construído sobre um SGSI maduro. A ISO/IEC 27001:2022 já exige definição de âmbito, análise das partes interessadas, avaliação de riscos, tratamento de riscos, seleção de controlos e uma Declaração de Aplicabilidade. A ISO 27701 estende essa lógica de sistema de gestão à privacidade.
A Política de Segurança da Informação da Clarysec estabelece:
“O SGSI deve incluir limites de âmbito definidos, uma metodologia de avaliação de riscos, objetivos mensuráveis e controlos documentados justificados na Declaração de Aplicabilidade (SoA).”
Da secção “Requisitos de implementação da política”, cláusula 6.1.2 da política.
A Política de Gestão de Riscos reforça a mesma disciplina de evidência:
“A Declaração de Aplicabilidade (SoA) deve refletir todas as decisões de tratamento e deve ser atualizada sempre que a cobertura de controlos seja modificada.”
Da secção “Requisitos de governação”, cláusula 5.4 da política.
Para a privacidade, o REG03 torna-se o registo de aplicabilidade dos controlos PIMS que espelha a disciplina da Declaração de Aplicabilidade. Não substitui a SoA ISO/IEC 27001:2022. Enriquece-a ao acrescentar decisões de privacidade específicas por função do RGPD da UE para responsáveis pelo tratamento, subcontratantes, responsáveis conjuntos pelo tratamento e subcontratantes subsequentes.
A Política de Inventário de Tratamento de PII e Fundamento de Licitude torna essa ligação explícita:
“[Ambos] O Responsável pela Privacidade / Gestor do PIMS DEVE ligar as atividades de tratamento aplicáveis do REG02 aos registos de aplicabilidade dos controlos do REG03 antes da revisão de preparação para certificação.”
Da secção “Operação do inventário de tratamento”, cláusula 7.1.5 da política.
Um auditor deve conseguir selecionar uma atividade de tratamento no REG02, identificar a função no RGPD da UE, rastrear os controlos aplicáveis no REG03, rever os controlos ISO/IEC 27001:2022 relevantes na SoA e inspecionar evidência como um DPA, um registo de fundamento de licitude, uma revisão de acessos, uma aprovação de subcontratante subsequente, um procedimento de incidente ou um registo de apagamento.
O modelo de aplicabilidade dos controlos baseado em funções
A forma mais rápida de tornar a ISO 27701 utilizável é decidir a aplicabilidade ao nível da atividade de tratamento, não ao nível da empresa.
Um prestador SaaS deve evitar dizer “somos subcontratantes”. Deve dizer “para registos de utilizadores carregados por clientes na plataforma de produção, somos subcontratantes. Para processamento salarial, somos responsáveis pelo tratamento. Para análise de produto, a nossa função depende de as análises serem usadas apenas para prestar os serviços contratados ou para finalidades próprias. Para o fornecedor de tickets que suporta dados de clientes, o fornecedor é subcontratante subsequente.”
| Função no RGPD da UE/PIMS | Foco da aplicabilidade dos controlos | Evidência típica na implementação Clarysec |
|---|---|---|
| Responsável pelo tratamento | Fundamento de licitude, transparência, direitos dos titulares dos dados, retenção, AIPD, privacidade desde a conceção, seleção de subcontratantes e decisão sobre violações de dados pessoais | Atividade de tratamento no REG02, registo de fundamento de licitude, aviso de privacidade, regra de retenção, AIPD quando exigida, controlos aplicáveis no REG03, devida diligência de subcontratantes |
| Subcontratante | Instruções documentadas, medidas de segurança, confidencialidade, assistência ao responsável pelo tratamento, notificação de violação de dados pessoais ao responsável pelo tratamento, devolução ou apagamento, aprovação de subcontratante subsequente | DPA, registo de instruções de clientes, registos de acesso, procedimento de escalamento de incidentes, registo de subcontratantes subsequentes, certificado de apagamento, controlos de subcontratante no REG03 |
| Responsável conjunto pelo tratamento | Acordo conjunto, repartição de responsabilidades, transparência para os titulares dos dados, fluxo de trabalho partilhado para violações de dados pessoais e direitos dos titulares | Acordo entre responsáveis conjuntos pelo tratamento, matriz de responsabilidades, texto do aviso de privacidade, fluxo de escalamento, controlos de responsável conjunto no REG03 |
| Subcontratante subsequente | Obrigações em cadeia, tratamento ao abrigo dos termos do subcontratante ou do cliente, segurança e confidencialidade, apoio à auditoria, tratamento na cessação | Acordo com subcontratante subsequente, lista de verificação de cláusulas em cadeia, evidência de garantia de fornecedores, revisão de acessos, evidência de devolução ou destruição de dados |
Esta visão baseada em funções está alinhada com a responsabilização do RGPD da UE. Os responsáveis pelo tratamento devem demonstrar cumprimento de princípios como licitude, lealdade, transparência, limitação da finalidade, minimização, exatidão, limitação da conservação, integridade, confidencialidade e responsabilização. Os subcontratantes devem tratar dados apenas mediante instruções documentadas, implementar segurança adequada, assistir os responsáveis pelo tratamento, gerir subcontratantes subsequentes e apoiar a devolução ou o apagamento.
O atalho perigoso é presumir que todos os controlos de privacidade se aplicam em todo o lado. Um subcontratante normalmente não determina o fundamento de licitude para dados de utilizadores finais de clientes, mas deve demonstrar que trata os dados apenas de acordo com instruções do cliente. Um responsável pelo tratamento pode não precisar de aprovação de subcontratantes subsequentes pelo cliente para tratamento interno de recursos humanos, mas deve realizar devida diligência sobre o subcontratante que presta o serviço de processamento salarial.
Classificar antes da aprovação contratual ou do início do tratamento
A constatação de preparação PIMS mais comum é a classificação tardia da função. O contrato foi assinado, a plataforma está em produção, os fornecedores estão integrados e ninguém decidiu se a organização é responsável pelo tratamento, subcontratante, responsável conjunto pelo tratamento ou subcontratante subsequente para cada fluxo de dados.
Esse atraso cria problemas a jusante. É usado o DPA errado. Os subcontratantes subsequentes não são divulgados. As AIPD são omitidas. A retenção não é clara. O suporte ao cliente não sabe que prazo de notificação de violação de dados pessoais se aplica. A aquisição trata um fornecedor com impacto na privacidade como “apenas uma ferramenta”.
A Política de Gestão de Privacidade de Subcontratantes, Subcontratantes Subsequentes e Terceiros trata diretamente o momento:
“[Ambos] O Responsável pela 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 terceiro no REG08 antes da aprovação contratual ou antes do início do tratamento de PII, consoante o que ocorrer primeiro.”
Da secção “Identificação e classificação da relação”, cláusula 4.1.3 da política.
A classificação de fornecedores e relações com terceiros no REG08 alimenta o REG03. Se um fornecedor for subcontratante, os controlos aplicáveis incluem termos de DPA, confidencialidade, medidas de segurança, direitos de auditoria, assistência com pedidos de exercício de direitos, apoio em caso de violação de dados pessoais, devolução ou apagamento e controlos de subcontratantes subsequentes. Se um fornecedor for responsável independente pelo tratamento, o foco desloca-se para fundamento de licitude, governação da divulgação, transferências, transparência e responsabilização.
Para organizações de menor dimensão, a Política de Segurança de Terceiros e Fornecedores - PME exige que as equipas considerem:
“Exposição regulamentar (por exemplo, função de subcontratante no RGPD da UE, obrigações do setor financeiro ao abrigo do DORA)”
Da secção “Requisitos de governação”, cláusula 5.2.4 da política.
Também estabelece um requisito claro antes da partilha:
“As cláusulas do Acordo de Tratamento de Dados (DPA) ou termos contratuais equivalentes devem ser acordados antes da partilha de quaisquer dados pessoais ou sensíveis.”
Da secção “Requisitos de implementação da política”, cláusula 6.3.2 da política.
Esta é a diferença entre ter contratos de fornecedores e ter governação auditável das funções de privacidade.
Mapear controlos para função, risco, lei e contrato
O Zenith Blueprint, fase de Gestão de Riscos, Passo 13: Planeamento do tratamento de riscos e Declaração de Aplicabilidade, explica a lógica central de aplicabilidade. Os controlos são aplicáveis devido a decisões de tratamento de riscos, requisitos legais ou contratuais, relevância para o âmbito e contexto organizacional. As exclusões precisam de razões claras, e os controlos aplicáveis devem ser rastreáveis a um risco ou requisito.
No Passo 13, o Zenith Blueprint estabelece:
“Garanta o alinhamento com o seu Registo de Riscos: cada controlo de mitigação que registou no plano de tratamento de riscos deve corresponder a um controlo do Anexo A marcado como ‘Aplicável’. Inversamente, se um controlo estiver marcado como aplicável, deve existir um risco ou um requisito que o justifique.”
Para a ISO 27701, o mesmo método aplica-se aos controlos de privacidade. Um controlo pode ser aplicável porque:
- O RGPD da UE o exige para a função da organização.
- Um contrato de cliente, DPA ou acordo entre responsáveis conjuntos pelo tratamento o exige.
- Um tratamento de riscos de privacidade o exige.
- O tratamento envolve categorias especiais de dados, dados de crianças, monitorização em larga escala, definição de perfis sensível ou dados pessoais de elevado impacto.
- O risco de fornecedor, nuvem, subcontratante subsequente ou transferência transfronteiriça torna o controlo necessário.
- O controlo suporta o âmbito de certificação, a preparação para auditoria ou objetivos de privacidade aprovados.
A Política de Cumprimento Legal e Regulamentar reforça esta disciplina de mapeamento:
“Quando um regulamento se aplica a várias áreas (por exemplo, o RGPD da UE aplica-se à retenção, segurança e privacidade), tal deve ser claramente mapeado no Registo de Conformidade e nos materiais de formação.”
Da secção “Requisitos de governação”, cláusula 5.2.2 da política.
A mesma Política de Cumprimento Legal e Regulamentar é explícita quanto à integração no SGSI empresarial:
“Todas as obrigações legais e regulamentares devem ser mapeadas para políticas, controlos e proprietários específicos no Sistema de Gestão de Segurança da Informação (SGSI).”
Da secção “Requisitos de implementação da política”, cláusula 6.2.1 da política.
Por isso, o REG03 nunca deve ser uma folha de cálculo de privacidade isolada. Deve ligar atividades de tratamento, obrigações legais, tratamentos de riscos, contratos, controlos ISO/IEC 27001:2022 e proprietários da evidência.
Exemplo prático: um fluxo de trabalho de suporte SaaS
Considere um fluxo de trabalho de suporte na plataforma SaaS de Maria. Os clientes submetem tickets que podem conter nomes, endereços de correio eletrónico, IDs de conta, capturas de ecrã e, ocasionalmente, contexto empresarial sensível. Os agentes de suporte acedem a registos limitados. Um fornecedor de sistema de tickets em nuvem aloja os dados e utiliza os seus próprios subcontratantes subsequentes.
Passo 1: Registar a atividade no REG02
O Responsável pela Privacidade regista:
- Nome da atividade: tratamento de tickets de suporte ao cliente
- Categorias de PII: identificadores de utilizador, dados de contacto, capturas de ecrã, metadados de conta
- Titulares dos dados: administradores de clientes e utilizadores finais
- Finalidade: suporte e resolução de problemas do serviço
- Função: subcontratante para PII de utilizadores finais fornecida por clientes; responsável pelo tratamento para gestão de contactos comerciais diretos, se usados para comunicações de conta
- Retenção: período definido de retenção para suporte e auditoria
- Destinatários: pessoal interno de suporte, fornecedor do sistema de tickets, subcontratantes subsequentes aprovados
- Classificação de segurança: confidencial, PII
A Política de Proteção de Dados e Privacidade - PME suporta esta linha de base:
“O Coordenador de Privacidade deve manter um registo de todas as atividades de tratamento de dados pessoais, incluindo categorias de dados, finalidade, fundamento de licitude e prazos de retenção”
Da secção “Requisitos de governação”, cláusula 5.2.1 da política.
Passo 2: Classificar o fornecedor no REG08
Se a empresa de Maria for subcontratante para dados de clientes, o fornecedor do sistema de tickets é normalmente subcontratante subsequente para esses dados de clientes. O REG08 deve capturar o tipo de relação, estado contratual, categorias de dados, localizações dos dados, subcontratantes subsequentes a jusante e evidência de garantia.
Passo 3: Registar a aplicabilidade no REG03
| Tema de controlo | Aplicável? | Porquê | Evidência |
|---|---|---|---|
| Determinação da função no tratamento | Sim | Exigida antes do início do tratamento e necessária para distinguir obrigações de responsável pelo tratamento e de subcontratante | Campo de função no REG02, registo de relação no REG08 |
| Documentação do fundamento de licitude | Parcialmente | Aplica-se ao tratamento de contactos comerciais do lado do responsável pelo tratamento, não ao tratamento de utilizadores finais de clientes realizado mediante instruções | Registo de fundamento de licitude, aviso de privacidade |
| Tratamento mediante instruções documentadas | Sim | Aplica-se à atividade de subcontratante para dados de utilizadores finais de clientes | DPA, termos de suporte, fluxo de trabalho de instruções do cliente |
| Privacidade desde a conceção e por defeito | Sim | O fluxo de suporte pode expor capturas de ecrã, identificadores e informação confidencial de clientes | Minimização no formulário de receção, orientações de mascaramento, restrições de acesso |
| Gestão de subcontratantes subsequentes | Sim | A plataforma de tickets e prestadores a jusante acedem a PII | Lista de subcontratantes subsequentes, fluxo de aprovação, repercussão contratual de obrigações |
| Assistência em pedidos de titulares dos dados | Sim | O subcontratante deve apoiar o responsável pelo tratamento do cliente quando aplicável | Procedimento de assistência a pedidos de titulares dos dados, evidência de encaminhamento de tickets |
| Apoio à notificação de violação de dados pessoais | Sim | Uma violação de dados pessoais na ferramenta de suporte deve ser escalada | Procedimento de incidentes, termos de notificação no DPA |
| Devolução ou apagamento | Sim | Exigido no termo do contrato e no fim do prazo de retenção | Calendário de retenção, registos de apagamento, certificado de apagamento do fornecedor |
| AIPD | Condicional | Exigida se o processo de suporte se expandir para monitorização de alto risco ou dados sensíveis em escala | Registo de triagem para AIPD |
A Política de Proteção de Dados e Privacidade empresarial acrescenta um desencadeador de alto risco:
“A modelação de ameaças e as Avaliações de Impacto sobre a Proteção de Dados (AIPD) são obrigatórias para sistemas de tratamento de alto risco.”
Da secção “Requisitos de implementação da política”, cláusula 6.3.4 da política.
A Política de Proteção de Dados e Privacidade - PME incorpora a expectativa de conceção:
“A privacidade desde a conceção e por defeito deve ser aplicada em todos os novos sistemas e serviços”
Da secção “Requisitos de governação”, cláusula 5.3.1 da política.
Passo 4: Alinhar com os controlos ISO/IEC 27001:2022
Se a plataforma de suporte estiver no âmbito do SGSI, a SoA deve incluir controlos ISO/IEC 27002:2022 de suporte, como relações com fornecedores, acordos com fornecedores, gestão da cadeia de fornecimento TIC, controlo de acesso, gestão de identidades, transferência de informação, serviços em nuvem, gestão de incidentes, registo de eventos e monitorização, gestão de alterações, cumprimento legal e proteção da privacidade.
O Zenith Blueprint, fase de Gestão de Riscos, Passo 14: Políticas de tratamento de riscos e referências cruzadas regulamentares, recomenda referências cruzadas entre RGPD da UE, NIS2 e DORA e as políticas e controlos, especialmente para proteção de dados pessoais, resposta a incidentes, controlo de acesso, continuidade de negócio e risco de terceiros TIC.
O resultado é evidência reutilizável, não folhas de cálculo separadas para RGPD da UE, DORA, NIS2 e certificação.
O que o Zenith Controls acrescenta à aplicabilidade PIMS
Zenith Controls é o guia de conformidade cruzada da Clarysec para compreender relações entre controlos ISO/IEC 27001:2022 e ISO/IEC 27002:2022, métodos de auditoria e outros referenciais. Não é um conjunto separado de controlos. Para este tema, os controlos ISO/IEC 27002:2022 centrais são:
- 5.34 Privacidade e proteção de PII
- 5.19 Segurança da informação nas relações com fornecedores
- 5.20 Abordagem da segurança da informação nos acordos com fornecedores
- 5.21 Gestão da segurança da informação na cadeia de fornecimento TIC
- 5.22 Monitorização, revisão e gestão de alterações dos serviços de fornecedores
Para 5.34, o Zenith Controls classifica o controlo como preventivo, mapeado para confidencialidade, integridade e disponibilidade, alinhado com Identificar e Proteger, e associado a capacidades de proteção da informação, jurídico e conformidade.
O seu mapeamento para o RGPD da UE estabelece:
“A implementação de 5.34 é evidência direta da capacidade de uma organização cumprir os requisitos de responsabilização do RGPD da UE.”
De Zenith Controls, Privacidade e Proteção de PII, mapeamento cruzado com o RGPD da UE.
Essa frase é importante porque transforma o 5.34 de uma declaração genérica de privacidade em evidência de auditoria. Deve ser suportada por inventários de PII, classificação, controlo de acesso, mascaramento, transferência segura, governação de nuvem, AIPD, avisos de privacidade, fluxos de trabalho para pedidos de titulares dos dados e tratamento de violações de dados pessoais.
| Controlo ISO/IEC 27002:2022 de suporte | Porque é relevante para a aplicabilidade PIMS |
|---|---|
| 5.9 Inventário de informação e outros ativos associados | Os acervos de PII devem ser conhecidos antes de os controlos de privacidade poderem ser selecionados ou testados |
| 5.12 Classificação da informação | A PII deve ser classificada para que se apliquem regras de tratamento mais robustas |
| 5.14 Transferência de informação | As transferências de PII exigem canais seguros, partilha lícita e controlos contratuais |
| 5.15 Controlo de acesso | O acesso segundo o princípio da necessidade de conhecer apoia a confidencialidade e a prevenção de violações de dados pessoais |
| 5.16 Gestão de identidades | São necessárias identidades fiáveis antes de o acesso poder ser autorizado e revisto |
| 5.23 Segurança da informação para utilização de serviços em nuvem | A PII em nuvem exige devida diligência do prestador, conhecimento da localização dos dados e planeamento de saída |
| 5.8 Segurança da informação na gestão de projetos | Os requisitos de privacidade e segurança devem ser incorporados em novos sistemas e alterações materiais |
| 8.11 Mascaramento de dados | O mascaramento reduz a exposição de PII em fluxos de suporte, testes e análise |
| 8.32 Gestão de alterações | As alterações com impacto na privacidade devem ser revistas antes da entrada em produção |
O Zenith Controls também liga a privacidade e a proteção de PII a normas relacionadas, como a ISO/IEC 27018 para tratamento de PII em nuvem pública, a ISO/IEC 29100 para princípios de privacidade e a ISO/IEC 29151 para práticas de proteção de PII. A governação da privacidade de fornecedores é suportada pela família ISO/IEC 27036 para relações com fornecedores e segurança da cadeia de fornecimento TIC, e pela ISO/IEC 27017 para responsabilidades partilhadas de segurança em nuvem.
A evidência de fornecedores e subcontratantes subsequentes é onde as funções convergem
As obrigações de responsáveis pelo tratamento e subcontratantes encontram-se frequentemente na fronteira com os fornecedores.
Se a empresa de Maria for responsável pelo tratamento, o RGPD da UE espera que utilize subcontratantes que ofereçam garantias suficientes. Se for subcontratante, os clientes esperam que faça a gestão de subcontratantes subsequentes, repercuta obrigações em cadeia e forneça garantia. Se for subcontratante subsequente, herda obrigações através da cadeia.
Isto torna os controlos ISO/IEC 27002:2022 5.19 e 5.20 centrais para a aplicabilidade dos controlos ISO 27701.
Para 5.19, o Zenith Controls salienta a segurança das relações com fornecedores nos domínios de governação, ecossistema e proteção. Liga-se diretamente a 5.20 acordos com fornecedores, 5.21 segurança da cadeia de fornecimento TIC, 5.14 transferência de informação, 5.36 cumprimento de políticas, regras e normas de segurança da informação, e 5.10 utilização aceitável da informação e de outros ativos associados.
Para 5.20, o Zenith Controls salienta a formalização contratual. Os acordos com fornecedores devem definir confidencialidade, notificação de violação de dados pessoais, direitos de auditoria, aprovação de subcontratantes, transferência segura, devolução ou destruição de dados, obrigações de conformidade e monitorização.
O Zenith Blueprint, fase Controlos em Ação, Passo 23: Controlos organizacionais, dá uma instrução prática para subcontratantes subsequentes:
“Para cada fornecedor crítico, identifique se utiliza subcontratantes (subcontratantes subsequentes) que possam aceder aos seus dados ou sistemas. Documente como os seus requisitos de segurança da informação são repercutidos para essas partes, através dos termos contratuais do fornecedor ou das suas próprias cláusulas diretas.”
Os auditores não ficam por “tem um DPA?”. Perguntarão se os fornecedores são subcontratantes, subcontratantes subsequentes, responsáveis independentes pelo tratamento ou responsáveis conjuntos pelo tratamento; se as aprovações de subcontratantes subsequentes estão documentadas; se as obrigações são repercutidas em cadeia; se os prazos de violação de dados pessoais são claros; se ocorre monitorização; e se é possível obter evidência de apagamento ou devolução.
Conformidade cruzada sem sistemas de controlo duplicados
A aplicabilidade dos controlos ISO 27701 torna-se mais valiosa quando suporta conversas de garantia sobre RGPD da UE, NIS2, DORA, NIST CSF 2.0 e COBIT 2019 a partir da mesma base de evidência.
O RGPD da UE impulsiona obrigações de privacidade baseadas em funções: responsabilização do responsável pelo tratamento, deveres do subcontratante, fundamento de licitude, direitos dos titulares dos dados, segurança, governação de violações de dados pessoais e contratos.
A NIS2 acrescenta gestão de riscos de cibersegurança, tratamento de incidentes, continuidade de negócio, segurança da cadeia de fornecimento, desenvolvimento seguro, tratamento de vulnerabilidades, controlo de acesso, criptografia, MFA e formação para entidades essenciais e importantes.
O DORA aplica-se a partir de 17 de janeiro de 2025 às entidades financeiras abrangidas e exige gestão do risco das TIC, notificação de incidentes, testes de resiliência e gestão do risco de terceiros TIC. Prestadores SaaS e TIC que servem entidades financeiras são frequentemente chamados a fornecer evidência de privacidade, segurança, resiliência, direitos de auditoria e saída num único pacote de garantia.
O NIST CSF 2.0 fornece uma camada de governação através da função GOVERN, incluindo obrigações legais, regulamentares, contratuais e de privacidade, funções, apetite ao risco, supervisão de políticas e governação da cadeia de fornecimento.
O COBIT 2019 acrescenta práticas de governação e gestão. Para privacidade, o Zenith Controls mapeia 5.34 para COBIT DSS06.02, DSS06.08 e APO13.01. Para fornecedores, 5.19 e 5.20 suportam práticas de risco de fornecedor e acordos com fornecedores.
| Motor de requisitos | Impacto na aplicabilidade dos controlos | Evidência a reutilizar |
|---|---|---|
| Responsabilização do responsável pelo tratamento no RGPD da UE | Fundamento de licitude, transparência, retenção e supervisão de subcontratantes aplicam-se quando a empresa determina finalidades e meios | REG02, registo de fundamento de licitude, aviso de privacidade, calendário de retenção, DPA |
| Obrigações de subcontratante no RGPD da UE | Instruções documentadas, confidencialidade, segurança, assistência, apoio em caso de violação de dados pessoais e apagamento aplicam-se a dados de clientes | DPA, fluxo de instruções, escalamento de incidentes, registos de apagamento |
| Temas do NIS2 Article 21 | Gestão de riscos, tratamento de incidentes, segurança da cadeia de fornecimento, controlo de acesso, criptografia e continuidade reforçam a proteção de PII | SoA, Registo de Riscos, plano de incidentes, revisões de fornecedores, revisão de acessos |
| Risco de terceiros TIC no DORA | Clientes financeiros esperam cláusulas contratuais, direitos de auditoria, resiliência, saída e cooperação em incidentes | Registo de fornecedores TIC, lista de verificação de cláusulas contratuais, plano de saída, testes de resiliência |
| NIST CSF 2.0 GOVERN e GV.SC | Obrigações legais, funções, risco de fornecedor, contratos e monitorização tornam-se resultados do perfil | Perfil CSF, registo de riscos de fornecedores, POA&M |
| Governação de privacidade e fornecedores no COBIT 2019 | A supervisão pelo conselho de administração, a gestão do programa de privacidade e a monitorização de acordos com fornecedores são testadas | Atas de governação, avaliação de riscos de privacidade, evidência de monitorização contratual |
O ponto estratégico é simples. O REG03 deve ser mais do que um artefacto ISO 27701. Deve ser um mapa reutilizável de aplicabilidade dos controlos para auditorias de clientes, revisões regulatórias e garantia ao nível do conselho de administração.
Como os auditores testam a aplicabilidade dos controlos ISO 27701
Auditores diferentes começam por ângulos diferentes, mas normalmente convergem no mesmo trilho de evidência.
Um auditor de sistemas de gestão ISO começa pelo âmbito, partes interessadas, obrigações, avaliação de riscos, alinhamento com a SoA, auditoria interna, revisão pela gestão e melhoria contínua. Testará se o REG02, o REG03 e a SoA ISO/IEC 27001:2022 estão coerentes.
Um auditor focado no RGPD da UE ou um revisor de privacidade testa a lógica das funções. Fará amostragem de atividades, reverá fundamento de licitude, avisos de privacidade, DPA, subcontratantes subsequentes, AIPD, tratamento de pedidos de exercício de direitos dos titulares, retenção e decisão sobre violações de dados pessoais.
Um avaliador orientado para NIST procura resultados de governação, categorização de riscos, inventários de dados, controlos de acesso, proteção de dados em repouso e em trânsito, monitorização, resposta a incidentes, risco de fornecedor e planos de melhoria.
Um auditor COBIT 2019 ou ISACA analisa propriedade de governação, capacidade do processo, eficácia da conceção e eficácia operacional. Testará se os controlos de privacidade estão incorporados na aquisição, gestão de alterações, gestão de incidentes e monitorização de fornecedores.
| Área de foco da auditoria | O que o auditor pedirá | Caminho de evidência Clarysec |
|---|---|---|
| Classificação de funções PIMS | Mostre o inventário de tratamento e explique como foi determinada cada função de responsável pelo tratamento, subcontratante, responsável conjunto pelo tratamento ou subcontratante subsequente | REG02 ao abrigo da Política do Sistema de Gestão de Informação de Privacidade |
| Aplicabilidade dos controlos PIMS | Justifique controlos de privacidade incluídos e excluídos para as atividades amostradas | REG03 ligado ao REG02 e a decisões de tratamento de riscos ao abrigo do Zenith Blueprint |
| Obrigações de subcontratante | Mostre o DPA, as instruções dos clientes, os controlos de confidencialidade e a lista de subcontratantes subsequentes | DPA, fluxo de instruções, revisão de acessos, REG08, registo de fornecedores |
| Obrigações de responsável pelo tratamento | Mostre o fundamento de licitude, o aviso de privacidade, a retenção e o tratamento dos direitos dos titulares dos dados | REG02, registo de fundamento de licitude, aviso de privacidade, procedimento de pedidos de titulares dos dados, calendário de retenção |
| Validação de fornecedores | Mostre devida diligência, cláusulas contratuais, monitorização e evidência de saída para subcontratantes de alto risco | REG08, avaliação de risco de fornecedores, evidência de 5.19 e 5.20, certificado de apagamento |
Para 5.34, o Zenith Controls descreve auditores a rever políticas de privacidade, inventários de dados, AIPD, registos de formação, salvaguardas técnicas, amostras de pedidos de titulares dos dados, incidentes de PII e evidência de privacidade desde a conceção. Para 5.19 e 5.20, os auditores solicitam inventários de fornecedores, classificações de risco, registos de devida diligência, contratos, termos de violação de dados pessoais, direitos de auditoria, aprovação de subcontratantes, evidência de saída e prova de que os relatórios de fornecedores são revistos.
A distinção é crítica. Preparação para auditoria não é “temos uma cláusula”. Preparação para auditoria é “usámos a cláusula, monitorizámo-la, revimos evidência e atuámos quando o risco mudou”.
Erros comuns na aplicabilidade para responsáveis pelo tratamento e subcontratantes
A Clarysec observa repetidamente cinco falhas evitáveis.
Primeiro, as organizações classificam a empresa inteira com uma única função no RGPD da UE. Isso não funciona para SaaS, fintech, tecnologia de recursos humanos, tecnologia de saúde, serviços geridos ou prestadores em nuvem com fluxos de dados mistos.
Segundo, tratam os controlos ISO 27701 como universalmente aplicáveis sem justificação por função. Isto cria requisitos de evidência excessivos e exclusões fracas.
Terceiro, excluem controlos sem documentar o motivo. Na lógica da SoA ISO/IEC 27001:2022 e na lógica de aplicabilidade PIMS, as exclusões devem ser conscientes, fundamentadas e suportadas por análise de âmbito, função, risco ou enquadramento legal.
Quarto, esquecem-se dos subcontratantes subsequentes. A narrativa de garantia de um subcontratante é tão forte quanto a sua cadeia a jusante. Registos de subcontratantes subsequentes, mecanismos de aprovação, cláusulas de obrigações em cadeia e evidência de apagamento são essenciais.
Quinto, não ligam os controlos de privacidade às operações de segurança. Privacidade desde a conceção não é apenas um modelo de AIPD. Deve influenciar controlos de acesso, registo de eventos, desenvolvimento seguro, configuração de nuvem, devida diligência de fornecedores, automatização da retenção e resposta a incidentes.
Lista de verificação Clarysec para a aplicabilidade dos controlos no REG03
Use esta lista de verificação antes de revisões de preparação ISO 27701, garantia de clientes sobre o RGPD da UE ou avaliações de fornecedores motivadas pelo DORA:
- Criar ou atualizar o REG02 para cada atividade de tratamento que envolva PII.
- Classificar a função PIMS de cada atividade antes do início do tratamento.
- Classificar cada relação com terceiros no REG08 antes da aprovação contratual ou do tratamento de PII.
- Identificar obrigações com base na função: responsável pelo tratamento, subcontratante, responsável conjunto pelo tratamento ou subcontratante subsequente.
- Registar os controlos PIMS aplicáveis no REG03 com proprietário, estado de implementação e evidência.
- Registar os controlos excluídos com justificação clara.
- Ligar as decisões do REG03 a riscos, obrigações legais, contratos ou fundamentação de âmbito.
- Alinhar o REG03 com a SoA ISO/IEC 27001:2022 quando os controlos de segurança suportam a privacidade.
- Mapear controlos de privacidade para ISO/IEC 27002:2022 5.34 quando a proteção de PII é exigida.
- Mapear requisitos de fornecedores e subcontratantes subsequentes para 5.19, 5.20, 5.21 e 5.22.
- Acrescentar referências de conformidade cruzada para RGPD da UE, NIS2, DORA, NIST CSF 2.0 e COBIT 2019 quando relevante.
- Testar o trilho de evidência com uma amostra de auditoria interna antes da revisão de preparação para certificação.
- Obter aprovação da Gestão de Topo quando o âmbito do PIMS ou a aplicabilidade dos controlos mudar.
A Política do Sistema de Gestão de Informação de Privacidade fecha este ciclo de governação:
“[Ambos] A Gestão de Topo DEVE aprovar alterações ao âmbito do PIMS e à aplicabilidade dos controlos no REG01 e REG03 antes de serem submetidas alterações ao âmbito de certificação.”
Da secção “Governação PIMS”, cláusula 6.1.3 da política.
Este é o tipo de evidência de governação em que os auditores confiam.
Transformar decisões sobre funções do RGPD da UE em evidência defensável
A aplicabilidade dos controlos ISO 27701 é o ponto em que a teoria das funções do RGPD da UE se torna realidade operacional. Um responsável pelo tratamento precisa de evidência de fundamento de licitude, transparência, retenção, AIPD, tratamento de direitos e supervisão de subcontratantes. Um subcontratante precisa de evidência de instruções documentadas, confidencialidade, segurança, assistência, subcontratantes subsequentes, apoio em caso de violação de dados pessoais e apagamento. Um responsável conjunto pelo tratamento precisa de um acordo transparente de responsabilidades. Um subcontratante subsequente precisa de obrigações em cadeia e apoio à garantia.
A Clarysec ajuda as organizações a construir essa camada de evidência através de:
- Inventário de tratamento REG02 e estrutura de fundamentos de licitude.
- Registos REG03 de aplicabilidade dos controlos PIMS.
- Classificação REG08 de relações de privacidade com terceiros.
- Alinhamento com a SoA ISO/IEC 27001:2022.
- Cláusulas de políticas que atribuem proprietários, prazos e requisitos de aprovação.
- Mapeamento de conformidade cruzada através de Zenith Controls.
- Sequenciação da implementação através de Zenith Blueprint.
Se a sua organização está a preparar-se para prontidão PIMS ISO 27701, garantia de clientes sobre o RGPD da UE, revisões de fornecedores DORA ou governação da segurança alinhada com NIS2, comece por uma atividade de tratamento de alto risco. Classifique a função. Mapeie os controlos aplicáveis. Ligue a evidência. Depois repita até que o seu programa de privacidade não esteja apenas conforme no papel, mas seja explicável em auditoria.
Descarregue o conjunto de políticas PIMS da Clarysec, explore o Zenith Blueprint ou marque uma avaliação de prontidão Clarysec para transformar decisões de responsável pelo tratamento, subcontratante, responsável conjunto pelo tratamento e subcontratante subsequente num registo de evidência de privacidade pronto para certificação.
Frequently Asked Questions
About the Author
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council
