Dados pessoais em logs de segurança: playbook para o RGPD, NIS2 e DORA

Um analista de segurança abre o SIEM às 02:17. O alerta parece rotineiro à primeira vista: várias autenticações falhadas, uma sessão bem-sucedida a partir de um endereço IP invulgar e, em seguida, um pico de chamadas de API contra um endpoint de exportação de clientes. Em poucos minutos, o canal de incidentes está cheio. O CISO quer saber se se trata de uma tomada de controlo de contas. A equipa jurídica pergunta se os logs contêm dados pessoais. O DPO pergunta se o ID de utilizador, o endereço IP, o identificador do dispositivo e os URLs dos pedidos no SIEM estão cobertos pelo aviso de privacidade e pelos registos de atividades de tratamento. O gestor de conformidade pergunta se os logs devem ser preservados para reporte regulamentar. A equipa de sucesso do cliente pergunta se um cliente pode pedir amanhã o apagamento dessas mesmas entradas de log.

É neste ponto que muitas organizações descobrem que o registo em logs de segurança e a governação da privacidade foram concebidos como mundos separados.

As equipas de segurança querem logs detalhados, retenção longa, armazenamento imutável e acesso rápido. As equipas de privacidade querem minimização, limitação das finalidades, acesso baseado em funções, disciplina de retenção e eliminação quando os dados deixam de ser necessários. As equipas de resposta a incidentes querem evidência preservada exatamente como estava. A responsabilização exigida pelo RGPD obriga a organização a explicar por que motivo os dados pessoais estão ali, quem lhes acedeu e durante quanto tempo são conservados. A NIS2 e a DORA aumentam a urgência, porque entidades essenciais, entidades importantes e organizações financeiras precisam de evidência suficiente para classificar incidentes, reportá-los dentro dos prazos e demonstrar uma gestão eficaz do risco das TIC.

A verdade incómoda é simples: os logs de segurança são frequentemente repositórios de dados pessoais. Os logs de autenticação podem conter nomes de utilizador, endereços de correio eletrónico, endereços IP, impressões digitais de dispositivos e geolocalização. Os logs aplicacionais podem expor URLs, parâmetros de pesquisa, fragmentos de payload, números de processo e conteúdo de mensagens. Os logs de EDR e de cloud podem incluir nomes de hosts associados a trabalhadores, caminhos de ficheiros com nomes, identificadores de sessão e ações de administradores. Os logs de IAM podem revelar alterações de privilégios, pertença a grupos e tentativas falhadas de acesso a sistemas sensíveis.

Se os logs contêm dados pessoais, deixam de ser apenas uma questão de registo em logs no âmbito da ISO 27001. Passam a ser uma questão de privacidade, retenção, evidência, notificação de incidentes e governação de fornecedores. A Clarysec trata a governação de dados pessoais em logs de segurança como um problema transversal de conformidade, não como um problema de configuração de ferramentas.

O verdadeiro dilema do CISO: evidência de deteção versus minimização da privacidade

No cenário das 02:17, o CISO enfrenta um conflito operacional real. Se os logs forem demasiado escassos, o SOC não consegue detetar comprometimento, reconstruir cronologias ou apoiar o reporte NIS2 e DORA. Se os logs forem demasiado ricos, a organização pode recolher mais dados pessoais do que o necessário, retê-los durante demasiado tempo, expô-los a demasiados administradores ou não conseguir suportar os direitos previstos no RGPD e as obrigações de transparência.

O RGPD define dados pessoais de forma ampla, como informação relativa a uma pessoa identificada ou identificável. O tratamento inclui recolha, armazenamento, utilização, divulgação, apagamento e destruição. Na prática, logs que contenham endereços IP, IDs de utilizador, identificadores de dispositivo ou registos de atividade podem constituir dados pessoais, dependendo do contexto. Os princípios do RGPD exigem tratamento lícito, leal e transparente, limitação das finalidades, minimização dos dados, limitação da conservação, integridade e confidencialidade, bem como responsabilização.

A pergunta de governação não é: “Podemos alguma vez registar dados pessoais?” A pergunta correta é: “Que dados pessoais precisamos de registar para segurança, resposta a incidentes e conformidade, que fundamento de licitude o suporta, que salvaguardas se aplicam e quando devem ser apagados, anonimizados ou colocados sob preservação aprovada?”

A biblioteca de políticas empresariais de privacidade da Clarysec aborda diretamente esta tensão. A Política de Proteção de Dados e Privacidade, Requisitos de implementação da política, cláusula 6.2.1, estabelece:

Apenas podem ser recolhidos e tratados os dados necessários para uma finalidade empresarial específica e legítima.

Para PME, o mesmo princípio é indicado na Política de Proteção de Dados e Privacidade para PME, Requisitos de implementação da política, cláusula 6.2.1:

Apenas os dados pessoais mínimos necessários devem ser recolhidos e retidos.

Esta frase deve orientar todas as decisões de conceção de logs. Cada campo em cada fonte de logs é necessário para uma finalidade de segurança, operacional, legal ou contratual definida?

Porque é que a ISO 27701 altera a conversa sobre logs

A ISO/IEC 27001:2022 fornece o sistema de gestão: âmbito, partes interessadas, avaliação de riscos, tratamento de riscos, controlo operacional, monitorização, auditoria interna e melhoria contínua. A ISO/IEC 27002:2022 fornece orientação prática de controlos para registo em logs, monitorização, proteção da privacidade de PII, recolha de evidência, proteção de registos, eliminação, controlo de acesso e gestão de fornecedores. A ISO/IEC 27701 alarga o modelo de governação à gestão da informação de privacidade, centrando-se em responsáveis pelo tratamento e subcontratantes de PII, papéis de privacidade, registos de tratamento de PII, privacidade desde a conceção, tratamento de direitos e obrigações dos subcontratantes.

Para logs de segurança, a ISO 27701 é relevante porque impõe perguntas específicas de privacidade que as equipas de segurança por vezes ignoram:

• A fonte de logs trata PII enquanto responsável pelo tratamento, subcontratante, responsável conjunto pelo tratamento ou subcontratante subsequente?
• Os dados de log estão incluídos no inventário de atividades de tratamento?
• A organização sabe que campos de log contêm PII?
• A PII nos logs está associada a regras de retenção e eliminação?
• Os clientes de subcontratantes são informados sobre o registo de acessos a PII quando tal é exigido contratualmente?
• Os logs são considerados na resposta a pedidos de acesso, apagamento ou limitação?
• Os incidentes que envolvem PII são avaliados em função de critérios de reporte de privacidade, cibersegurança e setor financeiro?

A Política de Segurança e Controlo de Acesso a PII da Clarysec traduz isto em requisitos operacionais. Em Registo em logs e monitorização, cláusula 4.6.1:

[Ambos] O Proprietário do sistema / Proprietário da aplicação DEVE definir o âmbito de registo em logs relativo a PII para eventos de autenticação, eventos de acesso, ações privilegiadas, atividade de exportação de PII e alterações materiais de configuração no REG12 antes da utilização em produção ou de uma alteração material.

A cláusula 4.6.2 fecha depois o ciclo entre registo em logs, controlo de acesso e retenção:

[Ambos] O Responsável de Segurança da Informação DEVE assegurar que os logs que contêm PII têm acesso restrito e estão associados a uma regra aprovada de retenção ou eliminação no REG02 ou REG12 antes do início da monitorização de logs.

Isto torna a governação do PIMS prática. O REG12 define que registo em logs de PII é permitido e exigido. O REG02 identifica onde existe PII, incluindo logs. As regras de retenção e eliminação não são documentação acrescentada posteriormente. Tornam-se pré-condições para o registo em logs em produção.

Os logs de segurança são registos, evidência e atividade de tratamento de PII

Uma organização madura não deve tratar os logs como resíduo técnico descartável. Os logs são registos. Durante um incidente, podem tornar-se evidência legal. Quando contêm PII, são também dados de tratamento sujeitos a governação de privacidade.

A Política de Registo em Logs e Monitorização da Clarysec define expectativas de normalização de logs. Em Requisitos de governação, cláusula 5.1.4:

Requisitos de formato e normalização de logs (por exemplo, carimbo temporal, ID de utilizador, tipo de evento, IP de origem)

São exatamente esses os campos que tornam os logs úteis para a resposta a incidentes. São também os campos que frequentemente transformam os logs em dados pessoais. A mesma política empresarial assinala o que nunca deve acontecer, em Requisitos de governação, cláusula 5.3.3:

Armazenamento de dados sensíveis em texto simples (por exemplo, palavras-passe, segredos criptográficos)

O ponto não é que os logs devam evitar todos os identificadores. O ponto é que os identificadores devem ser intencionais, protegidos e justificados. Palavras-passe, segredos, tokens completos e payloads desnecessários não devem ser registados. IDs de utilizador, endereços IP e metadados de eventos podem ser necessários, mas exigem controlos.

Para PME, a Política de Registo em Logs e Monitorização para PME da Clarysec integra a revisão de privacidade na estrutura de papéis. Em Papéis e responsabilidades, cláusula 4.3.1, exige que a organização:

Verifique que os dados de logs relativos a informação pessoal ou sensível são tratados de acordo com o RGPD e demais legislação de proteção de dados.

A versão para PME também estabelece um requisito claro de retenção de referência. Em Requisitos de governação, cláusula 5.2.1:

Os logs devem ser retidos durante pelo menos 12 meses, salvo se um período de retenção mais longo for exigido por lei ou contrato, ou justificado no âmbito de um incidente ativo ou litígio.

E define a expectativa de proteção, em Requisitos de governação, cláusula 5.3.1:

Os logs devem ser armazenados em locais protegidos contra escrita, e o acesso deve ser restrito apenas a pessoal autorizado.

Para resposta a incidentes empresarial, a Política de Recolha de Evidência e Análise Forense, Requisitos de implementação da política, cláusula 6.3.1, exige:

Os logs de firewalls, SIEM, agentes de endpoint, plataformas de gestão de identidades e acessos (IAM) e plataformas cloud devem ser exportados e armazenados em formatos imutáveis.

A versão para PME acrescenta uma salvaguarda de proporcionalidade. A Política de Recolha de Evidência e Análise Forense para PME, Tratamento do risco e exceções, cláusula 7.2.1, estabelece:

Minimizar o âmbito da recolha; recolher apenas o que é necessário.

Este é o núcleo do registo em logs atento à privacidade: preservar o que é necessário, demonstrar por que motivo é necessário, restringir quem o pode ver e eliminá-lo quando a finalidade aprovada expira.

O modelo de controlos da Clarysec para evidência segura em termos de privacidade

No Zenith Blueprint: roteiro de 30 passos para auditores, a Clarysec coloca o registo em logs na fase Controlos em ação, Passo 19: Controlos tecnológicos I. O guia explica a expectativa de controlo da ISO/IEC 27002:2022:

A.8.15 – Registo em logs: “Devem ser produzidos, armazenados, protegidos e analisados logs que registem atividades, exceções, falhas e outros eventos relevantes.”

O mesmo passo instrui as organizações a gerar logs para eventos-chave, armazená-los de forma segura para que não possam ser alterados, retê-los por um período definido e analisá-los através de um SIEM ou de um processo de revisão. Também liga o registo em logs à notificação de violações de dados pessoais no âmbito do RGPD, aos registos de incidentes DORA, à gestão de riscos NIS2 e à análise de logs de segurança COBIT.

Mas o registo em logs, por si só, não basta. Na mesma fase Controlos em ação, Passo 19, o Zenith Blueprint aborda a eliminação. O guia alerta que dados retidos para além do seu valor operacional aumentam a exposição e o risco regulatório, e menciona expressamente cópias de segurança, snapshots e arquivos. Isto é relevante porque uma regra de retenção do SIEM não tem significado se arquivos replicados de logs ou buckets de armazenamento de objetos na cloud conservarem a mesma PII indefinidamente.

No Passo 23: Controlos organizacionais, o Zenith Blueprint aborda a recolha de evidência. Afirma que a evidência de incidentes deve ser identificada, recolhida e preservada de forma legalmente admissível, fiável e alinhada com as necessidades de investigação. Também salienta uma realidade operacional: a evidência é frequentemente perdida nos primeiros minutos da resposta, quando os logs fazem rotação, os sistemas são reiniciados ou os administradores alteram contas comprometidas antes de serem capturados snapshots.

O Passo 23 também aborda a privacidade e a proteção da PII. O guia enquadra a PII como uma questão de ciclo de vida que exige conhecimento dos dados, classificação, controlo de acesso, mascaramento, eliminação, cifragem e obrigações de fornecedores. Para logs, isso significa que o SIEM, o EDR, a plataforma de registo em logs cloud e o sistema de tickets devem fazer parte do inventário de PII.

Mapeamento transversal de conformidade para PII em logs

O Zenith Controls: guia transversal de conformidade mapeia o controlo 8.15 da ISO/IEC 27002:2022, Registo em logs, para controlos relacionados essenciais à governação de PII. Estas relações mostram por que razão o registo em logs não é apenas uma preocupação do SOC.

O Zenith Controls também mapeia Registo em logs para a cláusula 8.15 da ISO/IEC 27002:2022, ISO/IEC 27035-1 e ISO/IEC 27035-2 para gestão de incidentes, ISO/IEC 27701 para registo em logs de atividades de tratamento de PII, ISO/IEC 27017 para logs de auditoria cloud, ISO/IEC 27018 para registo de acessos a PII na cloud, ISO/IEC 27005 para riscos decorrentes de registo em logs insuficiente, ISO/IEC 27033 para registo de atividade de rede e ISO/IEC 15408-2 para funcionalidade de auditoria em produtos avaliados.

Especificamente para privacidade, o Zenith Controls mapeia o controlo 5.34 da ISO/IEC 27002:2022, Privacidade e proteção da PII, para inventário de ativos, mascaramento de dados, serviços na cloud, classificação, transferência de informação, controlo de acesso, gestão de identidades e revisão de segurança de projetos e alterações. Para um programa de governação de logs, essas ligações tornam-se requisitos práticos de conceção:

• Inventariar repositórios de logs como localizações de PII.
• Mascarar ou tokenizar PII quando os identificadores completos não forem necessários.
• Rever serviços de registo em logs cloud e fornecedores de SIEM ao abrigo dos controlos de cloud e fornecedores.
• Classificar logs que contenham PII como registos sensíveis.
• Governar exportações e transferências de logs como transferências de PII.
• Restringir o acesso aos logs através de controlos de identidade e de acessos privilegiados.
• Rever alterações ao registo em logs aplicacional antes da entrada em produção.

RGPD, NIS2 e DORA: um log, três perspetivas regulamentares

A mesma entrada de log pode ser analisada de forma diferente ao abrigo do RGPD, da NIS2 e da DORA.

Ao abrigo do RGPD, a organização pergunta se a entrada de log contém dados pessoais, que fundamento de licitude suporta o tratamento, se os dados são necessários, durante quanto tempo são retidos, quem lhes pode aceder, se são divulgados a subcontratantes ou clientes e se devem ser considerados num pedido de exercício de direitos ou numa avaliação de violação de dados pessoais.

Ao abrigo da NIS2, a organização pergunta se os logs suportam a gestão de riscos de cibersegurança, o tratamento de incidentes, a continuidade de negócio, o controlo de acesso, a segurança da cadeia de abastecimento e a avaliação da eficácia dos controlos. O Article 20 da NIS2 responsabiliza os órgãos de administração pela aprovação e supervisão das medidas de gestão de riscos de cibersegurança. O Article 21 exige medidas técnicas, operacionais e organizacionais adequadas e proporcionadas, incluindo tratamento de incidentes, continuidade de negócio, segurança da cadeia de abastecimento, desenvolvimento seguro, tratamento de vulnerabilidades, avaliação da eficácia, higiene de cibersegurança, controlo de acesso e gestão de ativos. O Article 23 cria um reporte faseado para incidentes significativos, incluindo alerta precoce no prazo de 24 horas, notificação no prazo de 72 horas e relatório final no prazo de um mês.

Ao abrigo da DORA, as entidades financeiras devem operar um quadro documentado de gestão do risco das TIC. O Article 5 da DORA atribui responsabilidade ao órgão de administração. O Article 10 aborda a deteção. O Article 17 exige um processo de gestão de incidentes relacionados com as TIC. O Article 18 cobre a classificação de incidentes relacionados com as TIC e de ciberameaças. O Article 19 aborda o reporte de incidentes graves relacionados com as TIC. Os logs suportam deteção, classificação, análise de causa raiz, avaliação de impacto, resposta, recuperação e evidência de remediação.

Um mapeamento de controlos mais detalhado ajuda o CISO a justificar o registo em logs sem recorrer a afirmações vagas como “precisamos disto para segurança”.

Criar um âmbito de registo em logs relativo a PII no REG12

Um cliente da Clarysec trataria o incidente SIEM das 02:17 antes de ele alguma vez ocorrer. A organização começa por uma aplicação orientada para o cliente que trata dados de conta. Antes da produção, o proprietário da aplicação utiliza o REG12 para definir o âmbito de registo em logs relativo a PII. O objetivo é capturar eventos suficientes para evidência de segurança e regulatória sem registar dados pessoais desnecessários ou conteúdo de payload.

Em seguida, o responsável de privacidade confirma se a organização atua como responsável pelo tratamento, subcontratante ou ambos para cada fonte de logs. Se a organização for subcontratante, as instruções contratuais dos clientes e as divulgações de subcontratantes subsequentes podem limitar o acesso aos logs e a sua partilha. Se for responsável pelo tratamento, devem ser considerados os avisos de privacidade, o fundamento de licitude e o tratamento de direitos.

O proprietário dos dados atualiza então o REG02 para incluir repositórios ativos de logs, índices SIEM, arquivos, cópias de segurança e exportações forenses temporárias. Isto alinha-se com a Política de Retenção, Eliminação e Descarte de PII, Cópias de segurança, arquivos, réplicas, logs e ficheiros temporários, cláusula 4.4.1:

[Ambos] O Proprietário do sistema / Proprietário da aplicação DEVE identificar repositórios ativos, arquivos, cópias de segurança, réplicas, logs, áreas de staging e ficheiros temporários que contenham PII no REG02 antes da entrada em produção e durante cada revisão anual de retenção.

A Política de Retenção e Eliminação de Dados deve então alinhar as regras de retenção do negócio com requisitos legais, contratuais e de preservação de evidência.

Por fim, a equipa de segurança configura o SIEM para que palavras-passe, segredos e corpos de payload sejam descartados ou redigidos antes da ingestão. Os logs que contêm PII são atribuídos a índices restritos. A retenção é aplicada automaticamente, salvo se for aprovado um incidente ou uma preservação legal. As ações de eliminação são registadas. As exportações forenses exigem aprovação e acompanhamento da cadeia de custódia. Os painéis de gestão mostram identificadores pseudonimizados quando a identidade completa não é necessária. A recuperação histórica de logs é testada durante auditorias internas.

Esta é a diferença entre dizer “registamos logs por motivos de segurança” e demonstrar “registamos apenas o que é necessário, protegemo-lo, retemo-lo ao abrigo de regras aprovadas e conseguimos usá-lo como evidência sem violar obrigações de privacidade”.

DSAR, apagamento e logs: decidir antes de o pedido chegar

Uma das questões mais difíceis é saber se os logs devem ser pesquisados, divulgados ou apagados em resposta a pedidos de acesso do titular dos dados ou de apagamento. A resposta depende do papel, finalidade, fundamento de licitude, viabilidade, exceções e obrigações de retenção. Mas o processo de governação não pode ser inventado pedido a pedido.

A Política de Gestão dos Direitos dos Titulares de PII, Verificação de identidade, âmbito e avaliação, cláusula 4.2.3, estabelece:

[Responsável pelo tratamento] O Proprietário do processo / proprietário do negócio DEVE identificar sistemas, registos, finalidades, categorias de PII, destinatários e restrições de retenção relevantes a partir do REG02 antes de avaliar o cumprimento.

Isto significa que os logs devem estar no REG02 com metadados claros: que categorias de PII contêm, que finalidade servem, que restrição de retenção se aplica e se um pedido pode ser cumprido por divulgação direta, acesso resumido, limitação, apagamento no termo do prazo ou recusa com base num fundamento legal documentado.

A Clarysec recomenda uma abordagem em três níveis:

1. Logs operacionais com baixo impacto na privacidade, como logs de eventos de sistema que utilizem IDs de utilizador pseudónimos, podem ser pesquisáveis e divulgáveis quando adequado.
2. Logs de segurança com elevada sensibilidade de segurança, como dados de correlação SIEM ou contexto de informações sobre ameaças, podem exigir filtragem, divulgação resumida ou limitação para evitar expor lógica de deteção ou dados de terceiros.
3. Evidência forense sob incidente ativo ou preservação legal não deve ser alterada de forma casual. O apagamento pode ser diferido ou limitado quando legalmente justificado, com a decisão documentada pelas partes interessadas de privacidade e jurídico.

Se o DPO e o SOC discutirem cada DSAR do zero, a organização será inconsistente e lenta. Se o REG02 e o REG12 forem mantidos, o tratamento de direitos torna-se baseado em evidência.

Notificação de violações e incidentes: um evento, vários prazos

O alerta das 02:17 pode acionar vários prazos. A avaliação de violação de dados pessoais ao abrigo do RGPD pode exigir notificação a uma autoridade de controlo quando os limiares de risco forem atingidos. O reporte de incidente significativo ao abrigo da NIS2 pode exigir alerta precoce em 24 horas, notificação em 72 horas e relatório final. A DORA pode exigir o reporte de incidente grave relacionado com as TIC em fases inicial, intermédia e final. Os contratos com clientes podem prever janelas de notificação ainda mais curtas.

A Política de Gestão de Incidentes e Violações de PII da Clarysec aborda diretamente este problema de critérios cruzados de reporte. Em Classificação e avaliação da violação de dados pessoais, cláusula 4.2.6:

[Condicional] O Responsável de Privacidade / Gestor do PIMS DEVE avaliar os gatilhos de reporte legais, setoriais, do setor financeiro, de cibersegurança, contratuais, de cliente e de destinatários dos serviços aplicáveis a cada incidente de alto impacto relativo a PII e registar o resultado de aplicabilidade no REG01, REG08 e REG10.

Durante a triagem, a organização deve perguntar:

• O atacante acedeu a dados pessoais ou apenas a metadados?
• Os logs expuseram PII adicional a utilizadores não autorizados?
• Os logs são necessários para determinar pessoas afetadas, sistemas e período temporal?
• Os logs estão armazenados de forma imutável e com acesso restrito?
• Foi aplicada uma preservação por incidente que pausou a eliminação dos logs relevantes?
• São afetados clientes de subcontratantes, clientes do setor financeiro ou destinatários dos serviços?
• Que prazos de reporte se aplicam e quem é responsável por cada notificação?

Logs bem governados aceleram o reporte porque fornecem factos fiáveis aos decisores. Um registo em logs deficiente causa atrasos. O registo excessivo cria risco de privacidade. A resposta correta é um registo em logs direcionado, protegido e mapeado.

Fornecedores e registo em logs cloud: o problema do subcontratante escondido no seu SIEM

A maioria das organizações não armazena todos os logs em infraestrutura que controla integralmente. Os logs fluem para plataformas SIEM, portais EDR, serviços nativos de registo em logs cloud, ferramentas de observabilidade, sistemas de tickets e prestadores de deteção e resposta geridas (Managed Detection and Response, MDR). Ao abrigo do RGPD, estes prestadores podem ser subcontratantes ou subcontratantes subsequentes. Ao abrigo da NIS2 e da DORA, podem também ser fornecedores diretos, prestadores terceiros de serviços de TIC, prestadores de serviços geridos ou prestadores de serviços de segurança geridos.

O Article 21 da NIS2 inclui explicitamente segurança da cadeia de abastecimento, vulnerabilidades dos fornecedores e práticas gerais de cibersegurança dos fornecedores. A DORA acrescenta requisitos detalhados de risco de terceiros de TIC para entidades financeiras, incluindo diligência pré-contratual, registos de informações, direitos de auditoria e acesso, assistência em incidentes, localização dos dados, cláusulas de proteção de dados, estratégias de saída e disposições contratuais para funções críticas ou importantes.

Para PII em logs de segurança, as revisões de fornecedores devem incluir estas perguntas:

Um contrato SIEM não é apenas uma subscrição de software. É uma dependência de tratamento de PII e de evidência de incidentes.

Perspetiva de auditoria: como os avaliadores testam PII em logs de segurança

Um bom auditor não aceitará uma afirmação de que “os logs estão protegidos”. Irá testar a cadeia desde a política até à configuração, evidência e revisão.

Um teste prático de auditoria é simples, mas revelador: pedir ao SOC que recupere uma entrada de log de há dez meses que mostre uma alteração de acesso privilegiado numa plataforma cloud, prove quem acedeu a esse log, prove que não foi alterado, mostre a regra de retenção que permitiu a sua existência, mostre os campos de PII que contém e mostre como seria tratado num DSAR ou num relatório de incidente. Se a equipa não conseguir responder de forma transversal a segurança, privacidade e conformidade, a governação está incompleta.

Constatações comuns em auditorias de logs com PII

A Clarysec observa frequentemente os mesmos padrões:

• Equipas aplicacionais registam payloads completos de pedidos para depuração, incluindo nomes, emails, números de conta ou conteúdo de mensagens.
• Índices SIEM estão abertos a grupos amplos de administradores de TI em vez de funções SOC restritas.
• A retenção de logs é definida globalmente sem considerar a sensibilidade da PII, contratos com clientes ou regras de preservação por incidente.
• Logs de prestadores cloud estão ativados, mas o acesso de administradores do fornecedor aos dados de logs de clientes não é revisto.
• Procedimentos DSAR não mencionam logs, casos SIEM ou exportações forenses.
• Playbooks de resposta a incidentes preservam evidência, mas as equipas de privacidade não participam na classificação.
• Cópias de segurança e arquivos retêm PII de logs durante mais tempo do que o SIEM.
• Programadores conseguem alterar níveis de registo em logs em produção sem revisão de privacidade ou segurança.
• Ambientes de teste recebem logs de produção com dados pessoais.
• A organização tem obrigações de reporte NIS2 ou DORA, mas não consegue recuperar rapidamente evidência fiável.

Estas constatações raramente resultam de má intenção. Resultam de propriedade em silos. Os logs de segurança situam-se entre SOC, engenharia de plataformas, privacidade, jurídico, conformidade, auditoria e fornecedores. Se ninguém for responsável por todo o ciclo de vida, surgem lacunas.

Lista de verificação Clarysec para governação de logs pronta para auditoria

Utilize esta lista de verificação como ponto de partida operacional para a próxima revisão de governação:

1. Definir que fontes de logs podem conter PII: IAM, aplicação, gateway de API, SIEM, EDR, cloud, base de dados, rede, acesso físico e sistema de tickets.
2. Registar cada repositório de logs no REG02, incluindo repositórios ativos, arquivos, cópias de segurança, réplicas e exportações forenses temporárias.
3. Definir o âmbito de registo em logs relativo a PII no REG12 antes da utilização em produção ou de alterações materiais.
4. Identificar a finalidade e o fundamento de licitude para o tratamento de logs de segurança.
5. Proibir palavras-passe, segredos, tokens completos e payloads desnecessários nos logs.
6. Utilizar mascaramento, hashing ou pseudonimização quando não forem necessários identificadores completos.
7. Restringir o acesso a logs que contenham PII por função, com revisão de acessos privilegiados.
8. Armazenar logs de elevado valor em formatos imutáveis ou protegidos contra escrita.
9. Definir a retenção por tipo de log, obrigação legal, contrato, necessidade de incidente e risco de privacidade.
10. Implementar preservações por incidente com aprovação, âmbito e data de expiração.
11. Incluir logs na lógica de avaliação de DSAR e apagamento.
12. Rever fornecedores de SIEM, EDR, cloud e MDR como subcontratantes ou terceiros de TIC.
13. Testar a recuperação histórica e a integridade da evidência.
14. Mapear o registo em logs para as necessidades de reporte do RGPD, ISO 27701, NIS2, DORA, NIST CSF e COBIT.
15. Formar equipas SOC, de privacidade e aplicacionais sobre o que pode e não pode ser registado em logs.

Esta lista de verificação transforma o registo em logs atento à privacidade num processo de controlo repetível.

Do dilema à confiança ao nível do conselho de administração

A NIS2 torna a cibersegurança uma responsabilidade da gestão. A DORA torna o órgão de administração responsável pela gestão do risco das TIC, pela estratégia de resiliência operacional digital, pela confidencialidade dos dados, pela comunicação de incidentes e pelas políticas relativas a prestadores terceiros de serviços de TIC. A ISO/IEC 27001:2022 exige que a alta direção alinhe o SGSI com os objetivos do negócio, atribua responsabilidades, forneça recursos e promova a melhoria contínua.

A PII em logs de segurança não é, portanto, um detalhe técnico restrito. É uma questão de confiança ao nível do conselho de administração. A capacidade da organização para detetar incidentes, proteger dados pessoais, preservar evidência, responder a clientes, satisfazer reguladores e recuperar operações depende de decisões de registo em logs tomadas muito antes do incidente.

Os melhores programas de governação não escolhem entre privacidade e segurança. Definem o registo em logs mínimo necessário para uma segurança robusta, protegem esse registo como PII sensível quando necessário e ligam-no à retenção, evidência, tratamento de direitos e obrigações de fornecedores.

Próximos passos com a Clarysec

Se os seus logs SIEM, IAM, EDR ou cloud contêm dados pessoais, este é o momento de os governar deliberadamente.

A Clarysec pode ajudar a:

• Criar um âmbito de registo em logs relativo a PII utilizando o REG12 e alinhá-lo com a Política de Segurança e Controlo de Acesso a PII.
• Inventariar repositórios de logs, arquivos, cópias de segurança e exportações forenses utilizando o REG02 e a Política de Retenção, Eliminação e Descarte de PII.
• Alinhar registo em logs, monitorização, evidência e controlos de privacidade com o Zenith Blueprint.
• Mapear os seus controlos no RGPD, ISO 27701, NIS2, DORA, NIST CSF e COBIT utilizando o Zenith Controls.
• Preparar evidência pronta para auditoria para revisões de garantia ISO, privacidade, NIST, COBIT, NIS2 e DORA.

Comece por um sistema de alto risco: a sua plataforma IAM, o SIEM ou uma aplicação orientada para o cliente. Identifique que PII entra nos logs, por que motivo é necessária, quem lhe pode aceder, durante quanto tempo é retida e como seria utilizada durante um incidente ou pedido de exercício de direitos. Esse exercício único revelará se o seu programa atual de registo em logs é meramente operacional ou verdadeiramente pronto para auditoria.