Evidência das TOMs do Article 32 do RGPD da UE com ISO, NIS2 e DORA
O e-mail chega à caixa de entrada do CISO com o peso familiar de uma oportunidade comercial capaz de mudar o trimestre da empresa.
Um potencial cliente empresarial de grande dimensão quer evidência das “medidas técnicas e organizativas do Article 32 do RGPD da UE, mapeadas para ISO 27001:2022, NIS2 e DORA quando aplicável”. Ao mesmo tempo, a área jurídica informou o Conselho de Administração sobre a responsabilidade dos órgãos de gestão ao abrigo da NIS2 e sobre as expectativas de resiliência operacional da DORA. A instrução do Conselho de Administração parece simples: demonstrar conformidade, evitar trabalho duplicado e não transformar isto em três projetos separados.
A empresa tem controlos. A MFA está ativada. As cópias de segurança são executadas. Os programadores fazem revisão de código. A equipa de privacidade mantém registos das atividades de tratamento. A equipa de infraestrutura realiza análises de vulnerabilidades. Os fornecedores são revistos durante o processo de aquisição. Mas, quando o potencial cliente pede evidência, a resposta fragmenta-se.
O relatório do fornecedor de identidade está num local. Os logs das cópias de segurança estão noutro. O Registo de Riscos não é atualizado desde o último lançamento do produto. A evidência de segurança de fornecedores está em e-mails de aquisição. Existem notas de exercícios de simulação de mesa de resposta a incidentes, mas ninguém consegue demonstrar que as lições aprendidas foram reintegradas no tratamento de riscos. O Conselho de Administração aprovou investimento em segurança, mas a aprovação não está associada a um risco de TIC nem a uma decisão de controlo documentada.
Esse é o verdadeiro problema das medidas técnicas e organizativas do Article 32 do RGPD da UE, normalmente designadas por TOMs. A maioria das organizações não falha por não ter controlos. Falha porque não consegue demonstrar que os controlos são baseados no risco, aprovados, implementados, monitorizados e melhorados.
A responsabilização prevista no RGPD da UE torna essa expectativa explícita. O Article 5 do RGPD da UE exige que os dados pessoais sejam protegidos com segurança adequada contra tratamento não autorizado ou ilícito e contra perda, destruição ou dano acidental. O Article 5(2) torna o responsável pelo tratamento responsável por demonstrar a conformidade. As definições do RGPD da UE também importam. Dados pessoais é um conceito amplo, tratamento abrange praticamente qualquer operação sobre dados, a pseudonimização é uma salvaguarda reconhecida e uma violação de dados pessoais inclui destruição, perda, alteração, divulgação não autorizada ou acesso, de forma acidental ou ilícita.
Por isso, um dossiê de evidência do Article 32 não pode ser uma pasta de capturas de ecrã aleatórias. Tem de ser um sistema de controlo vivo.
A abordagem da Clarysec consiste em transformar as TOMs do Article 32 do RGPD da UE num mecanismo de evidência rastreável, construído sobre a ISO/IEC 27001:2022 ISO/IEC 27001:2022, reforçado pela gestão de riscos da ISO/IEC 27005:2022 e referenciado de forma cruzada com obrigações da NIS2 e da DORA quando aplicáveis. O objetivo não é produzir documentação por si só. O objetivo é preparar a organização para auditoria antes de um cliente, auditor, regulador ou membro do Conselho de Administração fazer a pergunta difícil.
Porque falham na prática as TOMs do Article 32 do RGPD da UE
O Article 32 é frequentemente interpretado de forma incorreta como uma lista de ferramentas de segurança: cifragem, cópias de segurança, registo, controlo de acessos e resposta a incidentes. Essas medidas são importantes, mas só são defensáveis quando são adequadas ao risco e estão ligadas ao ciclo de vida dos dados pessoais.
Para uma empresa SaaS que trata dados de colaboradores de clientes, “usamos cifragem” não é suficiente. Um auditor pode perguntar que dados a cifragem protege, onde é obrigatória, como são geridas as chaves, se as cópias de segurança são cifradas, se os dados de produção são mascarados em testes, quem pode contornar controlos e como são aprovadas as exceções.
A Política de Proteção de Dados e Privacidade empresarial da Clarysec capta o princípio operacional:
“Implementar medidas técnicas e organizativas (TOMs) que protejam a confidencialidade, integridade e disponibilidade das informações pessoais identificáveis (PII) ao longo de todo o seu ciclo de vida.”
Fonte: Política de Proteção de Dados e Privacidade, Objetivos, cláusula da política 3.3. Política de Proteção de Dados e Privacidade
A expressão “ao longo de todo o seu ciclo de vida” é onde muitos programas de TOMs se tornam frágeis. Os dados pessoais podem estar protegidos em produção, mas ser copiados para sistemas de análise de dados, logs, exportações de suporte, ambientes de teste, cópias de segurança, plataformas de fornecedores e dispositivos de colaboradores. Cada localização cria riscos de segurança e privacidade.
O Article 6 do RGPD da UE exige um fundamento de licitude para o tratamento, incluindo consentimento, contrato, obrigação legal, interesses vitais, missão de interesse público ou interesses legítimos. Quando os dados são reutilizados para uma finalidade ulterior, devem ser consideradas a compatibilidade e salvaguardas como a cifragem ou a pseudonimização. Para dados de maior risco, o ónus da evidência aumenta. O Article 9 do RGPD da UE impõe limites rigorosos a categorias especiais de dados pessoais, como dados de saúde, dados biométricos usados para identificação e outras informações sensíveis. O Article 10 restringe o tratamento de dados relativos a condenações penais e infrações.
Para PME, a Clarysec expressa o tratamento de riscos em linguagem prática:
“Os controlos devem ser implementados para reduzir riscos identificados, incluindo cifragem, anonimização, eliminação segura e restrições de acesso.”
Fonte: Política de Proteção de Dados e Privacidade - PME, Tratamento do risco e exceções, cláusula da política 7.2.1. Política de Proteção de Dados e Privacidade - PME
Esta é uma linha de base sólida para TOMs. Para estar preparada para auditoria, cada controlo também deve estar ligado a um risco, proprietário, requisito de política, item de evidência e cadência de revisão.
A ISO 27001:2022 é a espinha dorsal da evidência do Article 32
A ISO 27001:2022 funciona bem para o Article 32 do RGPD da UE porque trata a segurança como um sistema de gestão, não como uma lista desconexa de controlos. Exige um Sistema de Gestão de Segurança da Informação, ou SGSI, concebido para preservar a confidencialidade, integridade e disponibilidade através da gestão de riscos.
O primeiro passo crítico é o âmbito. As cláusulas 4.1 a 4.4 da ISO 27001:2022 exigem que a organização compreenda questões internas e externas, identifique partes interessadas e requisitos, determine quais os requisitos que serão tratados pelo SGSI e defina o âmbito do SGSI, incluindo interfaces e dependências com organizações externas. Para as TOMs do Article 32, o âmbito do SGSI deve refletir o tratamento de dados pessoais, obrigações perante clientes, subcontratantes, subcontratantes subsequentes, plataformas de computação em nuvem, trabalho remoto, funções de suporte e ambientes de produto.
O segundo passo é a liderança. As cláusulas 5.1 a 5.3 exigem compromisso da gestão de topo, uma Política de Segurança da Informação, recursos, funções e responsabilidades e reporte de desempenho. Isto é importante porque o Article 32 do RGPD da UE, a NIS2 e a DORA dependem todos de governação. Um controlo sem proprietário, financiamento ou revisão é evidência fraca.
A Política de Segurança da Informação empresarial da Clarysec torna isto explícito:
“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).”
Fonte: Política de Segurança da Informação, Requisitos de implementação da política, cláusula da política 6.1.2. Política de Segurança da Informação
A mesma política define a expectativa de evidência:
“Todos os controlos implementados devem ser verificáveis em auditoria, suportados por procedimentos documentados e por evidência retida da sua operação.”
Fonte: Política de Segurança da Informação, Requisitos de implementação da política, cláusula da política 6.6.1.
As cláusulas 6.1.1 a 6.1.3 da ISO 27001:2022 exigem avaliação de riscos, tratamento de riscos, uma Declaração de Aplicabilidade, aprovação do risco residual e responsabilização do proprietário do risco. A cláusula 6.2 exige objetivos mensuráveis. As cláusulas 7.5, 9.1, 9.2, 9.3 e 10.2 exigem informação documentada, monitorização, auditoria interna, revisão pela gestão e ações corretivas.
Para o Article 32 do RGPD da UE, isto cria uma estrutura defensável.
| Pergunta de evidência do Article 32 do RGPD da UE | Resposta de evidência ISO 27001:2022 |
|---|---|
| Como decidiram que TOMs são adequadas? | Critérios de avaliação de riscos, Registo de Riscos, pontuação de probabilidade e impacto, plano de tratamento de riscos |
| Que controlos se aplicam e porquê? | Declaração de Aplicabilidade com justificações de inclusão e exclusão |
| Quem aprovou o risco residual? | Aprovação do proprietário do risco e aprovação formal da gestão |
| Os controlos estão a operar? | Logs, tickets, registos de revisão, resultados dos testes, relatórios de monitorização |
| Os controlos são revistos? | Relatórios de auditoria interna, atas de revisão pela gestão, registo de ações corretivas |
| Os riscos sobre dados pessoais são considerados? | Entradas de risco de proteção de dados, requisitos de privacidade no âmbito, AIPD ou avaliação equivalente quando aplicável |
A ISO/IEC 27005:2022 reforça esta estrutura. Recomenda que as organizações identifiquem requisitos do Anexo A da ISO 27001:2022, regulamentos, contratos, normas setoriais, regras internas e controlos existentes, e que os integrem na avaliação de riscos e no tratamento. Também exige critérios de risco e critérios de aceitação que considerem fatores legais, regulamentares, operacionais, de fornecedores, tecnológicos e humanos, incluindo privacidade.
A Política de Gestão de Riscos da Clarysec está diretamente alinhada:
“Deve ser mantido um processo formal de gestão de riscos em conformidade com a ISO/IEC 27005 e a ISO 31000, abrangendo identificação de riscos, análise, avaliação do risco, tratamento de riscos, monitorização e comunicação do risco.”
Fonte: Política de Gestão de Riscos, Requisitos de governação, cláusula da política 5.1. Política de Gestão de Riscos
Para PME, o mesmo requisito torna-se simples e acionável:
“Cada entrada de risco deve incluir: descrição, probabilidade, impacto, pontuação, proprietário e plano de tratamento.”
Fonte: Política de Gestão de Riscos - PME, Requisitos de governação, cláusula da política 5.1.2. Política de Gestão de Riscos - PME
Esta frase é um teste rápido de preparação para auditoria. Se um risco não tiver proprietário ou plano de tratamento, ainda não é um risco pronto para evidência.
A ponte da Clarysec: risco, SoA, controlos e regulamentos
O Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint da Clarysec trata a conformidade como trabalho de rastreabilidade. Na fase de gestão de riscos, o Step 13 centra-se no planeamento do tratamento de riscos e na Declaração de Aplicabilidade. Explica que as organizações devem mapear controlos para riscos, adicionar referências de controlos do Anexo A às entradas de tratamento de riscos, fazer referência cruzada a regulamentos externos e obter aprovação da gestão.
O Zenith Blueprint é direto quanto ao papel da SoA:
“A SoA é, na prática, um documento de ligação: liga a sua avaliação/tratamento de riscos aos controlos reais que possui. Ao completá-la, também verifica se deixou algum controlo por considerar.”
Fonte: Zenith Blueprint: An Auditor’s 30-Step Roadmap, fase de gestão de riscos, Step 13: Planeamento do tratamento de riscos e Declaração de Aplicabilidade (SoA). Zenith Blueprint
O Step 14 do Zenith Blueprint acrescenta a camada de referência cruzada regulamentar. Recomenda que as organizações documentem como os requisitos do RGPD da UE, NIS2 e DORA são cobertos por políticas e controlos. Para o RGPD da UE, enfatiza a proteção de dados pessoais nas avaliações e tratamentos de risco, incluindo cifragem como medida técnica e resposta a violações como parte do ambiente de controlo. Para a NIS2, destaca avaliação de riscos, segurança de redes, controlo de acessos, tratamento de incidentes e continuidade de negócio. Para a DORA, aponta para gestão do risco das TIC, resposta a incidentes, reporte e supervisão de terceiros de TIC.
Este é o núcleo do método da Clarysec: um SGSI, um Registo de Riscos, uma SoA, uma biblioteca de evidência, múltiplos resultados de conformidade.
Zenith Controls: The Cross-Compliance Guide Zenith Controls apoia este método ao ajudar as organizações a usar tópicos de controlo da ISO/IEC 27002:2022 ISO/IEC 27002:2022 como âncoras de conformidade cruzada. Para o Article 32 do RGPD da UE, as âncoras mais importantes incluem frequentemente Privacy and Protection of PII, controlo 5.34; Independent Review of Information Security, controlo 5.35; e Use of Cryptography, controlo 8.24.
| Âncora de controlo ISO/IEC 27002:2022 no Zenith Controls | Porque é relevante para as TOMs do Article 32 | Exemplos de evidência |
|---|---|---|
| 5.34 Privacidade e proteção de PII | Liga controlos de segurança da informação ao tratamento de dados pessoais e às obrigações de privacidade | Inventário de dados, avaliação de risco de privacidade, calendário de retenção, registos de DPA, revisão de acessos |
| 5.35 Revisão independente da segurança da informação | Demonstra garantia objetiva, auditabilidade e melhoria | Relatório de auditoria interna, avaliação externa, registo de ações corretivas, revisão pela gestão |
| 8.24 Utilização de criptografia | Protege a confidencialidade e a integridade de dados em trânsito, em repouso e em cópias de segurança | Norma de cifragem, registos de gestão de chaves, evidência de cifragem de disco, configuração TLS, cifragem de cópias de segurança |
A NIS2 transforma as TOMs numa questão de cibersegurança ao nível do Conselho de Administração
Muitas organizações tratam as TOMs do RGPD da UE como responsabilidade da equipa de privacidade. A NIS2 muda a conversa.
A NIS2 aplica-se a muitas entidades médias e grandes em setores listados e, em alguns casos, independentemente da dimensão. Os setores digitais e tecnológicos abrangidos incluem prestadores de serviços de computação em nuvem, prestadores de centros de dados, redes de distribuição de conteúdos, prestadores de serviços DNS, registos TLD, prestadores de serviços de confiança, prestadores de comunicações eletrónicas públicas, prestadores de serviços geridos, prestadores de serviços de segurança geridos, marketplaces online, motores de pesquisa e plataformas de redes sociais. A aplicabilidade a SaaS e PME tecnológicas depende do setor, dimensão, designação pelo Estado-Membro e impacto sistémico ou transfronteiriço.
O NIS2 Article 20 coloca a responsabilidade pela cibersegurança nos órgãos de gestão. Estes devem aprovar medidas de gestão de riscos de cibersegurança, supervisionar a implementação e realizar formação. As entidades essenciais podem enfrentar coimas administrativas de pelo menos 10 milhões de euros ou pelo menos 2 por cento do volume de negócios anual mundial. As entidades importantes podem enfrentar coimas de pelo menos 7 milhões de euros ou pelo menos 1,4 por cento.
O NIS2 Article 21 é diretamente relevante para as TOMs do Article 32 porque exige medidas técnicas, operacionais e organizativas adequadas e proporcionadas. Estas medidas devem considerar o estado da técnica, normas europeias e internacionais, custo, exposição, dimensão, probabilidade, severidade e impacto social ou económico. As áreas exigidas incluem análise de riscos, políticas de segurança, tratamento de incidentes, continuidade de negócio, segurança da cadeia de fornecimento, aquisição e desenvolvimento seguros, tratamento de vulnerabilidades, avaliação da eficácia, higiene de cibersegurança, formação, criptografia, segurança de recursos humanos, controlo de acessos, gestão de ativos, MFA ou autenticação contínua e comunicações seguras quando adequado.
O NIS2 Article 23 acrescenta notificação de incidentes por fases: alerta precoce no prazo de 24 horas, notificação de incidente no prazo de 72 horas, atualizações intermédias quando solicitadas e relatório final no máximo um mês após a notificação de 72 horas. Se uma violação de dados pessoais também se qualificar como incidente significativo NIS2, o dossiê de evidência deve suportar decisões de reporte tanto de privacidade como de cibersegurança.
A DORA eleva a fasquia para a resiliência financeira e os prestadores de serviços de TIC
A DORA aplica-se a partir de 17 de janeiro de 2025 e cria um quadro normativo setorial financeiro para a resiliência operacional digital. Abrange gestão do risco das TIC, reporte de incidentes graves relacionados com TIC, testes de resiliência operacional, partilha de informações sobre ameaças e vulnerabilidades cibernéticas, risco de terceiros de TIC, requisitos contratuais para prestadores de serviços de TIC, supervisão de prestadores terceiros críticos de serviços de TIC e supervisão.
Para entidades financeiras também identificadas ao abrigo das regras nacionais da NIS2, a DORA funciona como o ato jurídico da União específico do setor para deveres sobrepostos de gestão de riscos de cibersegurança e reporte de incidentes. Na prática, as entidades financeiras abrangidas devem priorizar a DORA nessas áreas sobrepostas, mantendo coordenação com autoridades competentes NIS2 e CSIRTs quando relevante.
Para a evidência do Article 32 do RGPD da UE, a DORA é relevante de duas formas. Primeiro, empresas fintech podem estar diretamente abrangidas como entidades financeiras, incluindo instituições de crédito, instituições de pagamento, prestadores de serviços de informação sobre contas, instituições de moeda eletrónica, empresas de investimento, prestadores de serviços de criptoativos, plataformas de negociação e prestadores de serviços de financiamento colaborativo. Segundo, prestadores SaaS, de computação em nuvem, dados, software e serviços geridos podem ser tratados por clientes financeiros como prestadores terceiros de serviços de TIC, porque a DORA define serviços de TIC de forma ampla.
O DORA Article 5 exige governação e controlos internos para a gestão do risco das TIC, com o órgão de gestão a definir, aprovar, supervisionar e permanecer responsável pelos mecanismos de risco de TIC. O Article 6 exige um quadro documentado de gestão do risco das TIC, incluindo estratégias, políticas, procedimentos, protocolos de TIC e ferramentas para proteger informação e ativos de TIC. O Article 17 exige um processo de gestão de incidentes relacionados com TIC que cubra deteção, gestão, notificação, registo, causa raiz, indicadores de alerta precoce, classificação, funções, comunicações, escalonamento e resposta. O Article 19 exige que incidentes graves relacionados com TIC sejam reportados às autoridades competentes.
Os DORA Articles 28 e 30 tornam o risco de terceiros de TIC um domínio de controlo regulado. As entidades financeiras permanecem responsáveis pela conformidade quando utilizam serviços de TIC. Precisam de uma estratégia de risco de terceiros, registos contratuais, avaliações de criticidade, diligência prévia, revisão do risco de concentração, direitos de auditoria e inspeção, gatilhos de cessação, estratégias de saída e disposições contratuais que cubram localizações de dados, disponibilidade, autenticidade, integridade, confidencialidade, assistência a incidentes, recuperação, níveis de serviço e cooperação com autoridades.
Para o Article 32, isto significa que os fornecedores fazem parte do dossiê de TOMs. Não é possível demonstrar segurança do tratamento se subcontratantes críticos, plataformas de computação em nuvem, prestadores de análise de dados, ferramentas de suporte e prestadores de serviços de TIC não forem controlados.
Uma construção prática de evidência do Article 32 em uma semana
Um dossiê de evidência robusto começa com um cenário de risco claro.
Use este exemplo: “Acesso não autorizado a dados pessoais de clientes na aplicação de produção.”
Crie ou atualize a entrada de risco. Inclua descrição, probabilidade, impacto, pontuação, proprietário e plano de tratamento. Atribua a propriedade ao responsável de engenharia, gestor de segurança ou função responsável equivalente. Classifique a probabilidade com base no modelo de acesso, superfície de ataque exposta, vulnerabilidades conhecidas e incidentes anteriores. Classifique o impacto com base no volume de dados pessoais, sensibilidade, contratos de clientes, consequências do RGPD da UE e possível impacto de serviço NIS2 ou DORA.
Selecione tratamentos como MFA para acesso privilegiado, controlo de acessos baseado em funções, revisão trimestral de acessos, cifragem em repouso, TLS, análise de vulnerabilidades, registo, alertas, cópia de segurança segura, procedimentos de resposta a incidentes e mascaramento de dados em ambientes de não produção.
Depois mapeie o risco para a SoA. Adicione referências ISO/IEC 27002:2022 como 5.34 Privacidade e proteção de PII, 8.24 Utilização de criptografia, 5.15 Controlo de acesso, 5.18 Direitos de acesso, 8.13 Cópia de segurança da informação, 8.15 Registo, 8.16 Atividades de monitorização, 8.8 Gestão de vulnerabilidades técnicas, 8.25 Ciclo de vida de desenvolvimento seguro e 8.10 Eliminação da informação quando aplicável. Adicione notas que mostrem como estes controlos suportam o Article 32 do RGPD da UE, NIS2 Article 21 e gestão do risco das TIC da DORA quando relevante.
Para o mapeamento regulamentar, mantenha os nomes dos controlos corretos e evite forçar equivalências falsas.
| Controlo ISO/IEC 27002:2022 | Nome do controlo | Porque foi incluído | Mapeamento regulamentar |
|---|---|---|---|
| 8.24 | Utilização de criptografia | Protege a confidencialidade e a integridade de dados pessoais em trânsito, em repouso e em cópias de segurança | RGPD da UE Art. 32; NIS2 Art. 21(2)(h) |
| 5.20 | Tratamento da segurança da informação em acordos com fornecedores | Garante que as obrigações de segurança dos fornecedores são definidas contratualmente e aplicáveis | Controlos de subcontratantes do RGPD da UE; NIS2 Art. 21(2)(d); DORA Art. 28 e Art. 30 |
| 5.24 | Planeamento e preparação da gestão de incidentes de segurança da informação | Estabelece preparação para deteção, escalonamento, avaliação e reporte | Responsabilização por violações no RGPD da UE; NIS2 Art. 23; DORA Art. 17 e Art. 19 |
| 8.13 | Cópia de segurança da informação | Suporta disponibilidade, restauro e resiliência após interrupção ou perda de dados | RGPD da UE Art. 32; NIS2 Art. 21(2)(c); expectativas de continuidade de TIC da DORA |
| 8.10 | Eliminação da informação | Suporta eliminação segura, aplicação da retenção e minimização de dados | Limitação da conservação do RGPD da UE e Art. 32; requisitos contratuais de clientes |
Agora construa a pasta de evidência. A Política de Auditoria e Monitorização da Conformidade para PME da Clarysec fornece uma regra simples:
“Toda a evidência deve ser armazenada numa pasta centralizada de auditoria.”
Fonte: Política de Auditoria e Monitorização da Conformidade - PME, Requisitos de implementação da política, cláusula da política 6.2.1. Política de Auditoria e Monitorização da Conformidade - PME
Para este cenário de risco, a pasta deve conter:
| Item de evidência | O que armazenar | Porque é importante |
|---|---|---|
| Entrada de risco | Descrição do risco, proprietário, pontuação, plano de tratamento e decisão de risco residual | Demonstra a seleção de TOMs baseada no risco |
| Extrato da SoA | Controlos aplicáveis e notas sobre RGPD da UE, NIS2 e DORA | Mostra rastreabilidade do risco ao controlo |
| Revisão de acessos | Utilizadores revistos, decisões, remoções e exceções | Demonstra a operação do controlo de acessos |
| Relatório de MFA | Exportação que demonstra a aplicação de MFA privilegiada | Suporta evidência de autenticação |
| Evidência de cifragem | Registo de configuração, nota de arquitetura ou registo de gestão de chaves | Suporta confidencialidade e integridade |
| Registo de vulnerabilidades | Análise mais recente, tickets de remediação e exceções aceites | Suporta a redução de risco técnico |
| Evidência de registo | Amostra de evento SIEM, regra de alerta e definição de retenção | Suporta deteção e investigação |
| Teste de cópia de segurança | Resultado do teste de restauro e registo de cobertura de cópias de segurança | Suporta disponibilidade e resiliência |
| Exercício de incidente | Notas de simulação de mesa, registo de incidente de teste ou registo de lições aprendidas | Suporta preparação de resposta |
| Aprovação da gestão | Atas de reunião, aprovação formal ou registo de aceitação do risco | Suporta responsabilização e proporcionalidade |
A evidência de acesso não deve ficar por capturas de ecrã. A Política de Controlo de Acessos - PME acrescenta um requisito operacional útil:
“O responsável de TI deve documentar os resultados da revisão e as ações corretivas.”
Fonte: Política de Controlo de Acessos - PME, Requisitos de governação, cláusula da política 5.5.3. Política de Controlo de Acessos - PME
A evidência de cópias de segurança deve demonstrar recuperabilidade, não apenas tarefas bem-sucedidas. A Política de Cópias de Segurança e Restauro - PME declara:
“Os testes de restauro são realizados pelo menos trimestralmente, e os resultados são documentados para verificar a recuperabilidade.”
Fonte: Política de Cópias de Segurança e Restauro - PME, Requisitos de governação, cláusula da política 5.3.3. Política de Cópias de Segurança e Restauro - PME
Isto dá-lhe um ciclo de evidência completo: o regulamento cria o requisito, o risco explica porque importa, a SoA seleciona o controlo, a política define a operação e a evidência retida demonstra que o controlo funciona.
Controlos em ação: transformar a política em evidência operacional
A fase Controls in Action do Zenith Blueprint, Step 19, centra-se na verificação técnica. Recomenda rever a conformidade de segurança de endpoints, gestão de identidades e acessos, configurações de autenticação, segurança do controlo de código-fonte, capacidade e disponibilidade, gestão de vulnerabilidades e patches, referenciais seguros, proteção contra malware, eliminação e minimização de dados, mascaramento e dados de teste, DLP, cópias de segurança e restauro, redundância, registo em logs e monitorização, e sincronização horária.
Para as TOMs do Article 32 do RGPD da UE, o Step 19 é onde a linguagem abstrata de controlo se transforma em evidência. Um dossiê de evidência robusto deve mostrar que:
- A cifragem de endpoints está ativada e monitorizada.
- Os utilizadores privilegiados têm MFA.
- Os processos de admissão, mobilidade interna e cessação são reconciliados com registos de recursos humanos.
- As contas de serviço estão documentadas e restritas.
- Os repositórios de código têm controlo de acessos e é efetuada análise de segredos.
- As análises de vulnerabilidades são realizadas e acompanhadas até à remediação.
- Os dados de produção não são copiados informalmente para ambientes de teste.
- As políticas de eliminação segura e retenção são aplicadas.
- Os alertas DLP são revistos.
- Os testes de restauro de cópias de segurança demonstram recuperabilidade.
- Os logs são centralizados, retidos e passíveis de revisão.
- A sincronização horária suporta uma investigação de incidentes fiável.
A chave é a ligação. Um relatório de patches sem referência a risco, política e SoA é um artefacto de TI. Um relatório de patches ligado ao Article 32 do RGPD da UE, ao NIS2 Article 21, à gestão do risco das TIC da DORA e a um plano de tratamento de riscos ISO 27001:2022 é evidência preparada para auditoria.
Um dossiê de evidência, múltiplas lentes de auditoria
A mesma evidência de TOMs será lida de forma diferente por diferentes partes interessadas. Um revisor de privacidade pode focar-se em dados pessoais, necessidade, proporcionalidade e responsabilização. Um auditor ISO 27001 pode focar-se em âmbito, tratamento de riscos, SoA e evidência de operação. Uma autoridade NIS2 pode focar-se na supervisão pela gestão, nas medidas do Article 21 e na preparação para reporte do Article 23. Um supervisor DORA ou cliente financeiro pode focar-se na governação do risco das TIC, testes de resiliência e dependências de terceiros.
A Clarysec usa Zenith Controls como guia de conformidade cruzada para esta tradução.
| Público | O que irá perguntar | Como a evidência deve responder |
|---|---|---|
| Revisor de privacidade do RGPD da UE | As TOMs são adequadas ao risco dos dados pessoais e é possível demonstrar responsabilização? | Registo de Riscos, inventário de dados, controlos de privacidade, registos de retenção, restrições de acesso, evidência de cifragem e registos de avaliação de violações |
| Auditor ISO 27001:2022 | O SGSI está delimitado, baseado no risco, implementado, monitorizado e melhorado? | Âmbito, metodologia de risco, SoA, auditoria interna, revisão pela gestão e ações corretivas |
| Revisor NIS2 | As medidas de cibersegurança estão aprovadas, são proporcionadas e cobrem as áreas do Article 21? | Aprovação do Conselho de Administração, políticas de segurança, tratamento de incidentes, continuidade, risco de fornecedores, formação, MFA e gestão de vulnerabilidades |
| Supervisor DORA ou cliente financeiro | O risco de TIC é governado, testado e resiliente, incluindo risco de terceiros de TIC? | Quadro de risco de TIC, estratégia de resiliência, processo de incidentes, evidência de testes, registo de fornecedores e planos de saída |
| Avaliador orientado por NIST | A organização consegue identificar, proteger, detetar, responder e recuperar usando evidência repetível? | Inventário de ativos e dados, controlos de proteção, registos de monitorização, logs de resposta e testes de recuperação |
| Auditor COBIT 2019 ou ISACA | A governação é responsável, medida e alinhada com objetivos empresariais? | Funções, reporte de gestão, apetite ao risco, métricas de desempenho, resultados de garantia e ações de melhoria |
Isto evita trabalho de conformidade duplicado. Em vez de criar pacotes de evidência separados para RGPD da UE, NIS2 e DORA, crie um dossiê de evidência de controlos e etiquete cada item pelas obrigações que suporta.
Lacunas comuns em programas de TOMs do Article 32
A lacuna mais comum é a orfandade de controlos. Uma empresa tem um controlo, como cifragem, mas não consegue explicar que risco trata, que política o exige, quem é o proprietário ou como é revisto.
A segunda lacuna é a evidência fraca de fornecedores. Ao abrigo do RGPD da UE, subcontratantes e subcontratantes subsequentes importam. Ao abrigo da NIS2, a segurança da cadeia de fornecimento faz parte da gestão de riscos de cibersegurança. Ao abrigo da DORA, o risco de terceiros de TIC é um domínio regulado com registos, diligência prévia, salvaguardas contratuais, direitos de auditoria e planeamento de saída. Uma folha de cálculo de fornecedores não é suficiente se as dependências críticas não forem avaliadas quanto ao risco e controladas.
A terceira lacuna é a evidência de incidentes. As organizações têm frequentemente um Plano de Resposta a Incidentes, mas não têm evidência de que classificação, escalonamento, reporte a autoridades e comunicação com clientes tenham sido testados. A NIS2 e a DORA elevam as expectativas nesta área, e a avaliação de violação de dados pessoais do RGPD da UE deve ser integrada no mesmo fluxo de trabalho.
A quarta lacuna é a evidência de cópias de segurança. Uma tarefa de cópia de segurança bem-sucedida não demonstra recuperabilidade. Um teste de restauro documentado demonstra.
A quinta lacuna é a revisão pela gestão. As TOMs do Article 32 devem ser proporcionadas ao risco. Se a gestão nunca revê riscos, incidentes, questões de fornecedores, orçamento, constatações de auditoria e risco residual, a proporcionalidade torna-se difícil de demonstrar.
O conjunto final preparado para auditoria
A fase Audit, Review and Improvement do Zenith Blueprint, Step 30, fornece a lista final de preparação. Inclui o âmbito e contexto do SGSI, a Política de Segurança da Informação assinada, documentos de avaliação de riscos e tratamento, SoA, políticas e procedimentos do Anexo A, registos de formação, registos operacionais, relatório de auditoria interna, registo de ações corretivas, atas de revisão pela gestão, evidência de melhoria contínua e registos de obrigações de conformidade.
A Política de Auditoria e Monitorização da Conformidade empresarial da Clarysec estabelece a finalidade desta disciplina:
“Gerar evidência defensável e uma pista de auditoria em suporte de pedidos de esclarecimento regulamentares, processos judiciais ou pedidos de garantia por parte de clientes.”
Fonte: Política de Auditoria e Monitorização da Conformidade, Objetivos, cláusula da política 3.4. Política de Auditoria e Monitorização da Conformidade
Um dossiê maduro de evidência de TOMs do Article 32 deve incluir:
| Categoria de evidência | Conteúdo mínimo preparado para auditoria |
|---|---|
| Governação | Âmbito do SGSI, aprovação de políticas, funções, objetivos, atas de revisão pela gestão |
| Risco | Metodologia de risco, Registo de Riscos, plano de tratamento, aprovações de risco residual |
| SoA | Controlos aplicáveis, exclusões, justificações e mapeamento regulamentar |
| Privacidade | Inventário de dados, controlos de PII, evidência de retenção, AIPD ou avaliação de risco de privacidade quando aplicável |
| Controlos técnicos | MFA, revisão de acessos, cifragem, gestão de vulnerabilidades, registo, monitorização e evidência de desenvolvimento seguro |
| Resiliência | Cobertura de cópias de segurança, testes de restauro, planos de continuidade, exercícios de incidentes e métricas de recuperação |
| Garantia de fornecedores | Registo de fornecedores, diligência prévia, cláusulas contratuais, monitorização, direitos de auditoria e planeamento de saída |
| Melhoria | Auditorias internas, ações corretivas, lições aprendidas e revisões do desempenho dos controlos |
Próximos passos: crie evidência de TOMs do Article 32 com a Clarysec
Se precisa de demonstrar as medidas técnicas e organizativas do Article 32 do RGPD da UE, não comece por recolher capturas de ecrã aleatórias. Comece pela rastreabilidade.
- Defina o âmbito do SGSI e os limites do tratamento de dados pessoais.
- Identifique requisitos do RGPD da UE, NIS2, DORA, contratuais e de clientes.
- Construa critérios de risco usando ISO/IEC 27005:2022 e apetite ao risco aprovado pela gestão.
- Crie ou atualize o Registo de Riscos.
- Mapeie cada tratamento para controlos ISO 27001:2022 e para a SoA.
- Use Zenith Controls para fazer referência cruzada a controlos de privacidade, criptografia, fornecedores, incidentes e revisão independente em diferentes expectativas de conformidade.
- Siga o Zenith Blueprint Step 13 e Step 14 para ligar riscos, controlos e obrigações regulamentares.
- Use o Zenith Blueprint Step 19 para verificar controlos técnicos em operação.
- Use o Zenith Blueprint Step 30 para montar o dossiê final de evidência preparado para auditoria.
- Armazene toda a evidência de forma centralizada, rotule-a por risco e tema de controlo, e mantenha as ações corretivas visíveis.
A Clarysec pode ajudar a converter o Article 32 do RGPD da UE de uma obrigação de conformidade vaga num sistema de evidência defensável e baseado no risco, alinhado com ISO 27001:2022, NIS2 e DORA.
Comece com o Zenith Blueprint, reforce-o com políticas Clarysec e use Zenith Controls para tornar cada TOM rastreável, testável e preparada para auditoria.
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
