Pedidos de divulgação de dados pessoais ao abrigo do RGPD da UE e da ISO 27701
O pedido chega às 16:47 de uma sexta-feira
Um gestor de sucesso do cliente reencaminha uma mensagem de correio eletrónico para o Departamento Jurídico com o assunto: “PEDIDO POLICIAL URGENTE.” Em anexo segue uma carta digitalizada que solicita dados da conta, histórico de autenticações, endereços IP, registos de pagamento e “qualquer outra informação relevante” sobre uma pessoa identificada. O remetente afirma pertencer a uma unidade de cibercrime. A mensagem pede a divulgação no prazo de 24 horas e solicita que a organização “não notifique o titular dos dados”.
Ao mesmo tempo, a equipa de operações de segurança está a investigar atividade invulgar na mesma conta de cliente. O EPD encontra-se noutro fuso horário. O CISO pergunta se isto é um incidente, um pedido jurídico, uma divulgação ao abrigo do RGPD da UE ou os três. A equipa comercial quer “cooperar plenamente”. O suporte quer saber se pode exportar o perfil do cliente. Alguém sugere enviar o registo completo do CRM porque “as autoridades pediram tudo”.
Esta é a lacuna de governação.
A maioria das organizações tem uma política de privacidade, um Plano de Resposta a Incidentes (IRP) e um processo para pedidos de acesso dos titulares dos dados. Muitas conseguem gerir a diligência prévia de fornecedores, a correspondência regulatória e a notificação de violações de dados pessoais. Muito menos organizações têm um fluxo de trabalho repetível para pedidos oficiais ou legalmente impostos de divulgação de dados pessoais provenientes de autoridades policiais, reguladores, tribunais, autoridades fiscais, supervisores financeiros, reguladores de telecomunicações, unidades de cibercrime ou autoridades públicas estrangeiras.
Essa lacuna é perigosa. Cumprir um pedido fraudulento pode transformar-se numa violação de dados pessoais. Recusar um pedido legítimo pode criar exposição legal. Responder sem um processo controlado pode levar a divulgação excessiva, quebra da cadeia de custódia, incumprimento de prazos, transferências internacionais ilícitas e falha em auditoria.
Ao abrigo do RGPD da UE, da ISO 27701:2025 e da ISO/IEC 27001:2022, um pedido oficial de divulgação de dados pessoais não é apenas um assunto da caixa de correio do Departamento Jurídico. Envolve fundamento de licitude, registos de responsabilização, limitação das finalidades, minimização dos dados, confidencialidade, aprovação baseada em funções, governação de transferências internacionais, instruções ao subcontratante, preservação de evidência, transferência segura e trilhos de auditoria.
O teste prático é simples: quando o pedido chega, a sua organização consegue provar que validou o requerente, avaliou a autoridade legal, minimizou a divulgação, obteve as aprovações corretas, protegeu a evidência, registou a decisão e manteve um trilho pronto para auditoria?
A posição da Clarysec é clara. Trate os pedidos de divulgação de dados pessoais por autoridades policiais e reguladores como um fluxo de trabalho controlado de privacidade e segurança da informação, e não como uma resposta improvisada por correio eletrónico.
Porque os pedidos oficiais de divulgação de dados pessoais são diferentes
Um acordo normal de partilha externa de dados começa, normalmente, com uma finalidade de negócio. Um fornecedor precisa de dados dos trabalhadores para processamento salarial. Um prestador SaaS trata identificadores de clientes. Um parceiro recebe dados transacionais ao abrigo de contrato. O padrão de governação é familiar: diligência prévia, Acordo de Tratamento de Dados, requisitos de segurança, avaliação da transferência, termos de retenção e monitorização contínua.
Os pedidos de divulgação de dados pessoais por autoridades policiais e reguladores são diferentes. São acionados por eventos, são sensíveis ao tempo, frequentemente confidenciais e, por vezes, juridicamente vinculativos. Podem chegar fora dos canais de contratação. Podem solicitar categorias amplas de dados pessoais. Podem proibir a notificação. Podem envolver autoridades estrangeiras. Podem surgir durante um incidente, uma investigação de fraude, uma preservação legal, uma inspeção regulatória ou uma investigação de cibercrime.
Isto cria três requisitos imediatos de governação.
Primeiro, a organização deve saber quem pode responder. Um trabalhador da linha da frente não deve decidir se um pedido policial é válido, se a redação de um regulador é vinculativa ou se a notificação ao cliente é proibida.
Segundo, a cooperação deve ser separada da divulgação excessiva. O RGPD da UE não impede a cooperação lícita com autoridades, mas continua a exigir um fundamento de licitude válido, lealdade, transparência quando aplicável, limitação das finalidades, minimização dos dados, integridade, confidencialidade e responsabilização.
Terceiro, a evidência deve ser preservada. Se o pedido estiver relacionado com um incidente, um evento de fraude, um litígio ou um pedido de esclarecimento de uma autoridade de controlo, apagar logs, modificar registos ou exportar dados sem rastreabilidade pode prejudicar tanto a conformidade como a defensabilidade jurídica.
O modelo operacional mais robusto liga governação da privacidade, aprovação jurídica, tratamento de evidência, resposta a incidentes, transmissão segura e contacto com autoridades num único fluxo de trabalho.
O cluster de controlos da Clarysec: autoridades, privacidade e evidência
Em Zenith Controls: o guia de conformidade transversal, a Clarysec trata a governação da divulgação a autoridades policiais e reguladores como um cluster de controlos interligados, e não como uma tarefa isolada de privacidade. Os controlos centrais da ISO/IEC 27002:2022 são 5.5 Contacto com autoridades, 5.28 Recolha de evidência e 5.34 Privacidade e proteção de dados pessoais. As relações de controlo de suporte incluem classificação e rotulagem, controlo de acesso, relações com fornecedores, gestão de incidentes, registo, sincronização horária, criptografia, mascaramento, eliminação e transferência de informação.
Isto é relevante porque os pedidos oficiais de divulgação podem falhar em vários pontos. Uma equipa de privacidade pode validar o fundamento de licitude, mas falhar na preservação de evidência. Um SOC pode preservar logs, mas divulgar demasiados dados pessoais. O Departamento Jurídico pode aprovar uma resposta, mas esquecer-se de atualizar o registo de divulgação. Um subcontratante pode responder diretamente a uma autoridade quando deveria ter encaminhado o pedido para o responsável pelo tratamento.
O Zenith Blueprint: roteiro de 30 passos para auditores reforça esta ligação operacional na fase Controlos em Ação, passo 22, em Contacto com autoridades:
O Controlo 5.5 assegura que uma organização está preparada para interagir com autoridades externas quando necessário, não de forma reativa ou em pânico, mas através de canais predefinidos, estruturados e bem compreendidos.
A mesma secção enquadra as perguntas que devem ser respondidas antes da chegada de um pedido real:
O princípio é simples: se a sua organização fosse alvo de um ciberataque, estivesse envolvida numa violação de dados ou fosse objeto de investigação, quem faria a comunicação às autoridades? Como saberia o que dizer? Em que condições esse contacto seria iniciado? Estas perguntas devem ser respondidas antecipadamente, e não após o facto.
Para a proteção de dados pessoais, o Zenith Blueprint, na fase Controlos em Ação, passo 23, enquadra a privacidade como uma obrigação de ciclo de vida:
O Controlo 5.34 exige que as organizações protejam a privacidade das pessoas através da implementação de medidas adequadas para o tratamento de dados pessoais ao longo de todo o seu ciclo de vida.
Para a evidência, a mesma fase e o mesmo passo explicam por que motivo o tratamento informal é arriscado:
O Controlo 5.28 reconhece que, após um incidente, aquilo que se consegue provar é tão importante como aquilo que efetivamente aconteceu.
Em conjunto, estes três princípios definem o modelo de governação: saber quem fala com as autoridades, proteger os dados pessoais ao longo de todo o ciclo de vida da divulgação e preservar a evidência de forma defensável.
A perspetiva do RGPD da UE e da ISO 27701:2025 sobre divulgações obrigatórias
A ISO 27701:2025 reforça a necessidade de disciplina no Sistema de Gestão da Informação de Privacidade (PIMS). Um PIMS deve definir como os responsáveis pelo tratamento de dados pessoais e os subcontratantes de dados pessoais tratam pedidos oficiais de divulgação, incluindo receção, validação, revisão jurídica, autorização, registo, minimização, transmissão segura, retenção e revisão pós-resposta.
Para um responsável pelo tratamento, a questão central é saber se a organização determina as finalidades e os meios do tratamento e, por isso, deve decidir se e como a divulgação é lícita. Para um subcontratante, a questão é saber se pode divulgar dados sem instruções do responsável pelo tratamento, salvo quando legalmente obrigado. Para um subcontratante subsequente, o encaminhamento e as obrigações em cadeia tornam-se ainda mais sensíveis.
O RGPD da UE reforça os mesmos requisitos operacionais. Uma divulgação a uma autoridade pública continua a ser tratamento. A organização precisa de um fundamento de licitude ao abrigo do Article 6, de uma finalidade documentada, de segurança adequada, de minimização dos dados ao abrigo do Article 5(1)(c) e de evidência de responsabilização ao abrigo do Article 5(2). Em muitos casos, o fundamento de licitude será o Article 6(1)(c), tratamento necessário para o cumprimento de uma obrigação legal, mas apenas depois de o Departamento Jurídico validar o pedido e a jurisdição.
Quando o pedido vem de uma autoridade pública estrangeira, a governação da transferência e a revisão pelo EPD tornam-se essenciais. Quando o pedido envolve um subcontratante, devem ser verificadas as regras contratuais de notificação e instrução. Quando o pedido se relaciona com um incidente de cibersegurança, a resposta deve alinhar-se com os requisitos de tratamento de incidentes e recolha de evidência.
O conjunto de políticas da Clarysec transforma estes requisitos em regras operacionais.
A política empresarial P17 Política de Proteção de Dados e Privacidade, cláusula 6.1.1, estabelece:
Todo o tratamento deve basear-se num fundamento jurídico válido (por exemplo, consentimento, contrato, obrigação legal).
A mesma política, cláusula 6.2.1, acrescenta o princípio de minimização:
Apenas podem ser recolhidos e tratados os dados necessários para uma finalidade de negócio específica e legítima.
Para PME, a P17S Política de Proteção de Dados e Privacidade - PME, cláusula 6.2.1, estabelece:
Apenas os dados pessoais mínimos necessários devem ser recolhidos e retidos.
Estas cláusulas são relevantes quando o pedido solicita “todas as informações”, “histórico completo” ou “quaisquer registos relacionados”. A resposta correta não é exportar todos os campos. A resposta correta é validar o pedido, identificar o âmbito legalmente exigido, divulgar apenas os dados pessoais necessários, documentar a decisão e reter a evidência.
Do pânico por correio eletrónico à divulgação controlada
Um fluxo de trabalho maduro deve ser suficientemente simples para ser seguido por trabalhadores da linha da frente e suficientemente rigoroso para auditores, reguladores e tribunais. A Clarysec recomenda um modelo em sete fases.
| Fase | Objetivo de controlo | Responsável principal | Evidência criada |
|---|---|---|---|
| 1. Receção e quarentena | Prevenir resposta informal ou divulgação acidental | Central de serviços, ponto de receção do Departamento Jurídico, Responsável de Privacidade | Ticket do pedido, mensagem original, anexos, carimbo temporal |
| 2. Validação da autenticidade | Confirmar a identidade do requerente, autoridade, jurisdição e instrumento jurídico | Departamento Jurídico, EPD, Conformidade | Notas de validação, verificação de contacto da autoridade, avaliação do fundamento jurídico |
| 3. Determinação de papéis | Decidir se a organização atua como responsável pelo tratamento, subcontratante, responsável conjunto pelo tratamento ou subcontratante subsequente | Responsável de Privacidade, Proprietário do contrato | Avaliação do papel no PIMS, registo de instrução do cliente se atuar como subcontratante |
| 4. Minimização do âmbito | Traduzir o pedido em categorias específicas de dados pessoais e intervalos de datas | Proprietário do processo, Segurança, Departamento Jurídico | Extrato de mapeamento de dados, decisão de minimização, notas de expurgo |
| 5. Aprovação | Assegurar uma decisão autorizada antes da divulgação | EPD, Departamento Jurídico, CISO, proprietário do negócio | Registo de aprovação, registo de exceção se urgente |
| 6. Divulgação segura | Transmitir apenas dados aprovados através de canais controlados | Segurança, Operações Jurídicas | Log de transferência, evidência de cifragem, confirmação do destinatário |
| 7. Registo e revisão | Reter evidência de responsabilização e lições aprendidas | Gestor do PIMS, Conformidade | Entrada em REG08, REG09 ou REG12, trilho de auditoria, revisão de encerramento |
A primeira regra é o encaminhamento. Todos os trabalhadores devem saber que os pedidos oficiais de dados pessoais seguem uma via de receção definida. Ninguém deve responder a partir de uma caixa de correio pessoal. Ninguém deve telefonar ao requerente usando um número impresso numa carta não verificada. Ninguém deve exportar dados de clientes antes de o Departamento Jurídico e a Privacidade terem revisto o pedido.
A política empresarial P30 Política de Resposta a Incidentes, cláusula 6.5.5, apoia esta disciplina de encaminhamento:
Qualquer interação com autoridades policiais ou prestadores de serviços forenses deve ser coordenada através da Equipa Jurídica e do CISO.
Essa cláusula é especialmente importante quando o pedido de divulgação está ligado a fraude, cibercrime, comprometimento de conta, ransomware, ameaça interna ou investigação de violação de dados pessoais. O Departamento Jurídico e a segurança devem coordenar-se, e não operar em paralelo.
A política empresarial P37 Política de Cumprimento Legal e Regulamentar, cláusula 7.3.1.2, controla declarações externas:
Quaisquer declarações verbais ou escritas a reguladores devem ser previamente aprovadas.
A cláusula 7.3.1.3 acrescenta disciplina sobre prazos e evidência:
Os prazos de resposta devem ser acompanhados e os logs de evidência devem ser mantidos.
Estas regras não são fricção burocrática. Previnem admissões acidentais, divulgação não controlada, incumprimento de prazos e evidência fraca.
Disciplina de aprovação e registo: a evidência de auditoria que a maioria das equipas falha
Muitas organizações conseguem apresentar a mensagem original do pedido. Menos conseguem demonstrar quem aprovou a divulgação, que fundamento jurídico foi usado, por que razão determinados campos foram incluídos ou excluídos, como o requerente foi validado, se o titular dos dados foi notificado ou legitimamente não notificado, e onde a resposta foi registada.
É aqui que os registos do PIMS da Clarysec se tornam centrais.
Para responsáveis pelo tratamento, a política empresarial PII09 Política de Recolha, Utilização, Divulgação e Partilha de Dados Pessoais, cláusula 4.4.1, exige:
[Responsável pelo tratamento] O Proprietário do Processo / Proprietário do Negócio DEVE registar o resultado da revisão do Responsável de Privacidade / Gestor do PIMS no REG08 antes do início de qualquer nova divulgação externa ou acordo de partilha de dados.
A cláusula 4.4.2 especifica o que deve ser capturado para partilhas recorrentes:
[Responsável pelo tratamento] O Proprietário de Fornecedores / Aquisição DEVE registar a identidade do destinatário, o papel do destinatário, a finalidade da divulgação, as categorias de dados pessoais, a frequência da partilha, o local do tratamento e a fonte de autorização no REG08 antes do início da partilha externa recorrente.
Para subcontratantes, a política empresarial PII12 Política de Gestão de Privacidade de Subcontratantes, Subcontratantes Subsequentes e Terceiros, cláusula 4.5.3, fornece uma regra específica para pedidos juridicamente vinculativos e autorizados pelo cliente:
[Subcontratante] O Proprietário de Fornecedores / Aquisição DEVE registar pedidos de divulgação por terceiros, pedidos de divulgação juridicamente vinculativos ou pedidos de divulgação autorizados pelo cliente no REG08 antes da divulgação ou no prazo de dois dias úteis quando o registo prévio não for permitido ou operacionalmente possível.
Para pedidos de autoridades públicas estrangeiras, a política empresarial PII13 Política de Transferência Internacional de Dados Pessoais, cláusula 4.4.3, é mais específica:
[Ambos] O Responsável de Privacidade / Gestor do PIMS DEVE registar pedidos de divulgação de dados por autoridade pública estrangeira no REG09 ou REG12 antes da divulgação, quando praticável, ou no prazo de um dia útil quando o registo prévio não for praticável.
A cláusula 4.4.4 acrescenta disciplina de revisão:
[Ambos] O Encarregado da Proteção de Dados / Assessor de Privacidade DEVE rever pedidos de divulgação de dados por autoridade pública estrangeira com impacto relevante na privacidade no REG09 ou REG12 antes da resposta, quando praticável.
Um registo de divulgação é a fonte única de verdade da organização. Não deve ser substituído por mensagens de correio eletrónico dispersas, conversas privadas em chat ou folhas de cálculo ad hoc.
| Campo do registo | O que demonstra |
|---|---|
| ID do pedido | O pedido foi acompanhado de forma única |
| Origem do pedido | A autoridade ou o requerente foi identificado |
| Fonte da autoridade legal | O instrumento jurídico ou a autoridade foi avaliado |
| Papel no PIMS | Foram consideradas as obrigações de responsável pelo tratamento, subcontratante, responsável conjunto pelo tratamento ou subcontratante subsequente |
| Categorias de dados pessoais solicitadas | O âmbito original do pedido foi capturado |
| Categorias de dados pessoais aprovadas | A divulgação final foi controlada |
| Dados pessoais excluídos | A minimização dos dados foi aplicada ativamente |
| Cadeia de aprovação | Foram registadas as aprovações do Departamento Jurídico, EPD, CISO e negócio |
| Método de transmissão | Foram usados controlos de transferência segura |
| Decisão de notificação | Foram consideradas restrições ou diferimentos de transparência |
| Retenção e encerramento | A evidência foi retida e o assunto foi encerrado |
Exemplo prático: um pedido de regulador no REG08
Imagine que uma fintech regulada recebe um pedido escrito de um regulador financeiro nacional solicitando dados pessoais relacionados com transações suspeitas de um cliente durante um período de 90 dias. O pedido solicita registos de verificação de identidade, logs de transações, identificadores de dispositivos, tickets de suporte e notas internas de risco.
Usando o kit da Clarysec, o Responsável de Privacidade abre um registo de divulgação REG08.
| Campo REG08 | Exemplo de entrada |
|---|---|
| ID do pedido | REG08-2026-041 |
| Origem do pedido | Regulador financeiro nacional, verificado através do diretório oficial de contactos de supervisão |
| Tipo de pedido | Pedido de divulgação de dados pessoais por regulador |
| Papel no PIMS | Responsável pelo tratamento |
| Fonte da autoridade legal | Pedido legal de informação para fins de supervisão, referência FIN-REQ-7781 |
| Finalidade | Investigação de transações suspeitas relativas a cliente identificado |
| Categorias de dados pessoais solicitadas | Dados de verificação de identidade, logs de transações, identificadores de dispositivos, comunicações de suporte, notas de risco |
| Categorias de dados pessoais aprovadas | Logs de transações, identificadores de dispositivos, campos relevantes de verificação de identidade, dois tickets de suporte dentro do intervalo de datas |
| Dados pessoais excluídos | Histórico de suporte não relacionado, opiniões internas de analistas fora do intervalo de datas, referências a clientes terceiros |
| Justificação de minimização | Âmbito limitado ao cliente identificado, período de 90 dias, registos relevantes para as transações identificadas no pedido |
| Revisão pelo EPD | Aprovado com instruções de expurgo |
| Aprovação jurídica | Aprovado, redação da resposta revista |
| Revisão pelo CISO | Aprovado método de exportação e transferência segura |
| Método de transmissão | Arquivo cifrado através do portal seguro do regulador |
| Notificação do titular dos dados | Diferida devido a restrição legal no pedido, data de revisão definida |
| Retenção | Registo do pedido e pacote de divulgação retidos ao abrigo do calendário de preservação legal |
| Evidência de encerramento | Recibo de submissão no portal, hash do pacote de divulgação, cadeia de aprovação |
Esta é a diferença entre “cumprimos” e “conseguimos provar que cumprimos de forma lícita e proporcional”. Se o cliente reclamar mais tarde, se a autoridade fizer perguntas de seguimento ou se um auditor amostrar a divulgação, o registo demonstra a lógica de governação.
Preservação de evidência: não danificar os factos ao tentar ajudar
Quando um pedido de uma autoridade policial ou de um regulador está ligado a uma investigação, a governação da privacidade cruza-se com a análise forense e a preservação legal. Os dados divulgados são frequentemente evidência, e o ato de os recolher deve preservar a integridade.
A Política de Cumprimento Legal e Regulamentar - PME, cláusula 6.4.1, define o contexto:
Em caso de litígio, investigação ou pedido jurídico:
A cláusula 6.4.1.2 dá uma instrução clara:
Os trabalhadores não devem apagar nem alterar materiais que possam fazer parte de uma investigação.
A P31S Política de Recolha de Evidência e Análise Forense - PME, cláusula 2.2.5, inclui explicitamente:
Pedidos de esclarecimento regulamentares ou de autoridades policiais
A cláusula 5.2.1 estabelece disciplina de registo:
Cada item de evidência digital deve ser registado com:
Em termos operacionais, o log de evidência deve capturar um identificador único, data e hora da recolha, nome do responsável pela recolha, localização de origem e hash criptográfico quando adequado. O objetivo é a rastreabilidade. Se os logs forem exportados manualmente, os nomes dos ficheiros forem alterados, os carimbos temporais forem pouco claros ou não for retido qualquer hash, a organização poderá ter dificuldade em provar a integridade posteriormente.
Um fluxo de trabalho robusto de evidência também limita o acesso. Os pacotes de divulgação devem ser armazenados em localizações restritas, cifrados em trânsito, acompanhados através de logs de transferência e retidos de acordo com requisitos de preservação legal e retenção. Se um pedido de divulgação se sobrepuser a uma resposta a incidentes, a equipa deve saber quando mudar do modo de remediação para uma postura de investigação.
Mapeamento de conformidade transversal: um fluxo de trabalho, muitas obrigações
Um fluxo de trabalho bem concebido para pedidos de divulgação de dados pessoais pode satisfazer vários referenciais sem duplicar trabalho. O Zenith Controls ajuda as organizações a mapear a mesma evidência operacional entre expectativas de privacidade, cibersegurança, resiliência operacional e governação.
| Referencial | O que o auditor ou regulador espera | Como o fluxo de trabalho da Clarysec apoia |
|---|---|---|
| ISO 27701:2025 | Papéis no PIMS, governação da divulgação lícita, instruções ao subcontratante, registos de divulgação de dados pessoais, tratamento de riscos de privacidade | Determinação de papéis, REG08, REG09, REG12, revisão pelo EPD, justificação de minimização |
| RGPD da UE | Fundamento de licitude, responsabilização, minimização dos dados, segurança, decisões de transparência, governação de subcontratantes e transferências | Avaliação da autoridade legal, cadeia de aprovação, pacote de divulgação limitado, evidência de transferência segura |
| ISO/IEC 27001:2022 e ISO/IEC 27002:2022 | Contacto com autoridades, recolha de evidência, proteção de dados pessoais, controlo de acesso, registo, criptografia, eliminação | Matriz de contactos com autoridades, log de evidência, exportação segura, registo de hash, decisão de retenção |
| NIS2 | Disciplina de notificação de incidentes, cooperação com autoridades competentes, responsabilização da governação, sensibilização da cadeia de fornecimento | Coordenação jurídica e do CISO, prazos de resposta, registo de contactos com autoridades, ligação ao incidente |
| DORA | Governação de incidentes de TIC em entidades financeiras, interação com reguladores, preparação da evidência, risco de prestadores terceiros de serviços de TIC | Encaminhamento de pedidos de reguladores, registos de divulgação segura, preservação de evidência de incidente, interface com fornecedores |
| NIST Cybersecurity Framework | Resultados de governar, identificar, proteger, detetar, responder e recuperar para eventos de cibersegurança | Titularidade da política, inventário de dados, controlos de acesso, registo, fluxo de resposta, revisão pós-resposta |
| COBIT 2019 | Objetivos de governação para conformidade, risco, segurança, gestão da informação e garantia | Direitos de decisão, titularidade do processo, registos de auditoria, supervisão pela gestão, melhoria contínua |
As normas ISO de suporte também são relevantes. A ISO/IEC 27035 ajuda a estruturar a gestão de incidentes quando o pedido está relacionado com um incidente. A ISO/IEC 27037 apoia a identificação, recolha, aquisição e preservação de evidência digital. A ISO/IEC 27018 é útil quando subcontratantes de cloud pública tratam dados pessoais. A ISO/IEC 27017 apoia responsabilidades de segurança cloud. A ISO 22301 torna-se relevante se as obrigações de contacto com autoridades e divulgação tiverem de continuar em condições de crise. A ISO/IEC 27006-1:2024 é indiretamente relevante porque os auditores de certificação esperam uma implementação consistente e auditável dos controlos do sistema de gestão dentro do âmbito.
O objetivo não é construir um processo de conformidade separado para cada referencial. O objetivo é desenhar um fluxo de trabalho defensável que produza evidência reutilizável.
Como diferentes auditores irão testar o fluxo de trabalho
Um auditor ISO/IEC 27001:2022 começará normalmente pela integração com o sistema de gestão. Perguntará se a organização determinou partes interessadas, requisitos legais e regulamentares, riscos, objetivos de controlo, procedimentos documentados, responsabilidades atribuídas e evidência retida. Para pedidos de divulgação, poderá amostrar incidentes, correspondência com reguladores, listas de contactos de autoridades, logs de evidência e registos de privacidade. Provavelmente testará os controlos do Anexo A A.5.5 Contacto com autoridades, A.5.28 Recolha de evidência e A.5.34 Privacidade e proteção de dados pessoais.
Um avaliador ISO 27701:2025 focar-se-á na clareza dos papéis no PIMS. A organização atuava como responsável pelo tratamento, subcontratante, responsável conjunto pelo tratamento ou subcontratante subsequente? Se era responsável pelo tratamento, onde está o fundamento de licitude e o registo de divulgação? Se era subcontratante, atuou segundo as instruções do responsável pelo tratamento, salvo se legalmente obrigada em contrário? O cliente foi notificado quando exigido ou quando contratualmente esperado? Os pedidos de autoridades públicas estrangeiras foram registados e revistos?
Um regulador do RGPD da UE focar-se-á na responsabilização. A pergunta não será apenas “existia uma obrigação legal?”. Será “por que razão esta quantidade de dados foi divulgada, quem aprovou, como foi validado o requerente, que segurança protegeu a transferência, como foi avaliada a transparência e onde está o registo?”.
Um avaliador orientado para NIST examinará resultados de governação e resposta. Perguntará se os papéis foram definidos, se os logs foram preservados, se o acesso aos pacotes de divulgação foi restringido, se as atividades de resposta foram documentadas e se as lições aprendidas melhoraram o programa.
Um auditor COBIT 2019 ou ISACA testará a governação dos direitos de decisão. Poderá perguntar se a gestão definiu o proprietário do processo, se as responsabilidades Jurídicas, de Privacidade, Segurança e Negócio estão segregadas, se as exceções são aprovadas, se as métricas são reportadas e se a garantia pode apoiar-se na evidência.
Um regulador, auditor, CISO e EPD podem ver o mesmo registo de forma diferente. Um profissional de privacidade vê um registo de divulgação lícita. Um auditor de segurança vê preservação de evidência e transferência segura. Um auditor de governação vê responsabilização e direitos de decisão. A organização deve conseguir responder a todos a partir da mesma evidência de controlo.
Padrões comuns de falha
A Clarysec observa repetidamente as mesmas falhas evitáveis.
A primeira é o contacto informal com autoridades. Um agente policial telefona para o suporte, o suporte quer ajudar, e o trabalhador confirma verbalmente dados da conta. Sem validação, sem aprovação, sem registo.
A segunda é a divulgação excessiva. A organização envia um ficheiro completo do cliente em vez dos registos específicos e do intervalo de datas exigidos. Isto cria risco evitável no âmbito do RGPD da UE e enfraquece a confiança.
A terceira é a atuação indevida do subcontratante. Um prestador SaaS recebe um pedido de autoridade policial relativo a dados pessoais controlados pelo cliente e responde sem notificar nem envolver o cliente, apesar de o contrato e o papel no PIMS exigirem encaminhamento salvo proibição legal.
A quarta é a ausência de revisão de autoridade estrangeira. Um pedido de uma autoridade pública não nacional é tratado como uma divulgação ordinária, sem avaliação da transferência, revisão pelo EPD ou entrada em REG09 ou REG12.
A quinta é o tratamento fraco da evidência. Os logs são exportados manualmente, os carimbos temporais são pouco claros, os nomes dos ficheiros são alterados e não existe registo de hash nem de cadeia de custódia.
A sexta é a confidencialidade não gerida. Demasiados trabalhadores são copiados no pedido, incluindo pessoas sem necessidade de conhecer. Detalhes sensíveis da investigação espalham-se por canais de chat.
A sétima é a confusão de prazos. A organização perde uma data de resposta juridicamente relevante porque o pedido fica numa caixa de correio em vez de estar num fluxo de trabalho acompanhado.
Cada falha é evitável com canais predefinidos, registos, aprovações e normas de evidência.
Papéis e direitos de decisão
Um modelo prático de governação define os direitos de decisão antes da chegada do primeiro pedido.
| Papel | Responsabilidade no fluxo de trabalho de divulgação |
|---|---|
| Trabalhador da linha da frente | Reencaminhar o pedido para o canal de receção aprovado, não responder substantivamente, não divulgar dados pessoais |
| Equipa Jurídica | Validar o instrumento jurídico, jurisdição, autoridade, restrição de confidencialidade e redação da resposta |
| EPD ou Assessor de Privacidade | Avaliar implicações do RGPD da UE e da ISO 27701:2025, minimização, transparência, papel no PIMS e questões de transferência |
| CISO | Aprovar a recolha segura de evidência, exportação segura, método de transferência e ligação a incidentes |
| Proprietário do processo | Identificar sistemas e categorias de dados relevantes, confirmar o contexto de negócio |
| Gestor do PIMS | Manter REG08, REG09 ou REG12, acompanhar o resultado da revisão, reter evidência de auditoria |
| Aprovador executivo | Aprovar divulgações de alto risco, estrangeiras, estratégicas ou sensíveis em termos reputacionais |
| Proprietário de Fornecedores ou Aquisição | Coordenar registos de pedidos relacionados com terceiros ou subcontratantes e obrigações contratuais |
Este modelo deve ser incorporado na formação de sensibilização. Os trabalhadores não precisam de conhecer todas as nuances jurídicas, mas devem conhecer a regra: pedidos oficiais seguem para o canal definido, e dados pessoais não são divulgados sem autorização.
Lista de verificação de preparação para o próximo exercício de simulação
Use esta lista de verificação num workshop de governação da privacidade, numa auditoria interna ou num exercício de simulação.
- Temos um único canal de receção para pedidos de divulgação de dados pessoais por autoridades policiais e reguladores?
- Os trabalhadores sabem que não devem responder informalmente?
- Validamos a identidade do requerente usando fontes de contacto independentes?
- Distinguimos pedidos de reguladores, decisões judiciais, pedidos de autoridades policiais, pedidos autorizados pelo cliente e pedidos de autoridades públicas estrangeiras?
- Determinamos se somos responsável pelo tratamento, subcontratante, responsável conjunto pelo tratamento ou subcontratante subsequente antes de responder?
- Documentamos o fundamento de licitude, a autoridade legal, a jurisdição e as restrições de confidencialidade?
- Aplicamos minimização dos dados e expurgamos dados pessoais não relacionados?
- Exigimos revisão pelo EPD ou Assessor de Privacidade para pedidos com impacto relevante na privacidade?
- Exigimos coordenação entre o Departamento Jurídico e o CISO quando estão envolvidas autoridades policiais ou questões forenses?
- Registamos divulgações efetuadas enquanto responsável pelo tratamento no REG08?
- Registamos pedidos de autoridades públicas estrangeiras no REG09 ou REG12?
- Acompanhamos prazos de resposta e mantemos logs de evidência?
- Preservamos materiais potencialmente relevantes e prevenimos a sua eliminação ou alteração?
- Protegemos os pacotes de divulgação com cifragem, controlo de acesso e registo da transferência?
- Realizamos revisão pós-resposta para pedidos de alto risco?
- Reportamos métricas e lições aprendidas à gestão?
Se a resposta a qualquer uma destas perguntas for “normalmente tratamos isso por correio eletrónico”, o processo ainda não está pronto para auditoria.
Integrar o fluxo de trabalho no SGSI e no PIMS
O melhor modelo de governação não vive apenas no Departamento Jurídico. Faz parte do SGSI e do PIMS.
No Zenith Blueprint, a fase Fundação e Liderança do SGSI, passo 5, recomenda planear a comunicação externa e identificar quem comunica com reguladores, clientes, parceiros e o público. Observa que a assessoria jurídica pode participar na redação das comunicações a reguladores. Esse princípio aplica-se diretamente aos pedidos oficiais de divulgação de dados pessoais.
A fase Controlos em Ação operacionaliza depois o fluxo de trabalho através de contacto com autoridades, proteção de dados pessoais e recolha de evidência. É por isso que o guia de 30 passos da Clarysec não trata privacidade, segurança e conformidade como fluxos de trabalho desconectados. Um pedido real atravessa os três.
Para os proprietários do negócio, o benefício é a redução do caos. Para os CISO, clarifica quando a evidência de segurança pode ser recolhida, divulgada ou preservada. Para os EPD, cria responsabilização demonstrável ao abrigo do RGPD da UE e da ISO 27701:2025. Para os gestores de conformidade, produz registos e trilhos de auditoria. Para os auditores, cria um caminho claro desde o requisito da política até à evidência operacional.
Próximos passos com a Clarysec
Um pedido de regulador ou de autoridade policial não é o momento para inventar o seu processo de governação da privacidade. É o momento em que o seu processo é testado.
Comece com um exercício de simulação. Use um pedido realista de cibercrime, regulador ou autoridade pública estrangeira. Peça ao Departamento Jurídico, ao EPD, ao CISO, ao suporte e ao proprietário do processo relevante que percorram receção, validação, determinação de papéis, minimização, aprovação, transferência segura, registo, preservação de evidência e revisão de encerramento.
Depois, compare as suas respostas com o modelo operacional da Clarysec:
- Use o Zenith Blueprint: roteiro de 30 passos para auditores para integrar contacto com autoridades, comunicação externa, proteção de dados pessoais e recolha de evidência no seu plano de implementação do SGSI e do PIMS.
- Use o Zenith Controls: o guia de conformidade transversal para mapear expectativas da ISO 27701:2025, RGPD da UE, ISO/IEC 27001:2022, ISO/IEC 27002:2022, NIS2, DORA, NIST e COBIT 2019 numa narrativa de controlos pronta para auditoria.
- Use as políticas da Clarysec de Proteção de Dados e Privacidade, Resposta a Incidentes, Cumprimento Legal e Regulamentar, Recolha de Evidência e Análise Forense, Divulgação de Dados Pessoais, Gestão de Subcontratantes e Transferência Internacional para definir regras de fluxo de trabalho, registos, aprovações e requisitos de evidência.
A Clarysec ajuda as equipas a passar do pânico reativo para a execução controlada. Transfira os kits relevantes da Clarysec, execute o exercício de simulação e marque uma avaliação de governação da divulgação para garantir que a sua próxima resposta é lícita, mínima, aprovada, registada, segura e auditável.
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
