Monitorização contínua da conformidade para NIS2 e DORA

A pergunta de sexta-feira à tarde a que todos os CISO têm agora de responder

Às 16:40 de uma sexta-feira, o CISO de uma plataforma de pagamentos alojada na cloud recebe três mensagens em dez minutos.

A primeira é do CFO: “O nosso parceiro bancário quer evidência atualizada de que cumprimos as expectativas do DORA para o risco de terceiros de TIC e a comunicação de incidentes.”

A segunda é da Assessoria Jurídica: “O nosso serviço gerido de segurança pode colocar-nos no âmbito da transposição nacional da NIS2. Conseguimos demonstrar supervisão pela gestão e eficácia dos controlos?”

A terceira é do Responsável de Engenharia: “Aplicámos o patch para a vulnerabilidade crítica, mas o backlog mostra 38 constatações médias em atraso. Temos de escalar?”

Este é o momento em que a conformidade anual deixa de funcionar.

Um PDF de política, um Registo de Riscos atualizado pela última vez antes da auditoria anterior e uma pasta de capturas de ecrã não são suficientes para NIS2 e DORA. Estes regimes esperam governação viva, supervisão pela gestão, fluxos de trabalho de incidentes, visibilidade sobre fornecedores, testes de resiliência, ações corretivas e eficácia dos controlos demonstrável.

Para muitos CISO, a pressão não é teórica. A transposição da NIS2 nos Estados-Membros da UE transformou a cibersegurança de um programa técnico numa matéria de responsabilização da gestão. O DORA é aplicável desde 17 de janeiro de 2025 e fornece às entidades financeiras um conjunto setorial de regras de resiliência operacional para risco de TIC, comunicação de incidentes, testes e risco de terceiros. Prestadores de cloud, SaaS, serviços geridos, segurança gerida, centros de dados, distribuição de conteúdos, serviços de confiança e comunicações eletrónicas públicas também podem estar sujeitos a obrigações diretas ou indiretas, consoante o âmbito, a dimensão, o setor, a classificação nacional e os contratos com clientes.

A pergunta prática já não é: “Temos um controlo?”

É: “Quem é o responsável pelo controlo, que métrica prova que está a funcionar, com que frequência recolhemos evidência e o que acontece quando a métrica falha?”

Este é o núcleo da monitorização contínua da conformidade para NIS2 e DORA. Nas implementações Clarysec, usamos a ISO/IEC 27001:2022 como base do sistema de gestão, a ISO/IEC 27002:2022 como linguagem de controlos, Zenith Blueprint: o roteiro de 30 passos para auditores como sequência de implementação e Zenith Controls: o guia de conformidade cruzada como bússola de conformidade cruzada que liga a evidência da ISO/IEC 27001:2022 à NIS2, ao DORA, ao RGPD da UE, ao NIST CSF 2.0, ao COBIT 2019 e às expectativas de auditoria.

Porque NIS2 e DORA tornam insuficiente a conformidade periódica

NIS2 e DORA diferem na estrutura jurídica, no modelo de supervisão e no âmbito, mas criam a mesma pressão operacional. A cibersegurança e a resiliência das TIC devem ser governadas continuamente.

A NIS2 exige que as entidades essenciais e importantes apliquem medidas técnicas, operacionais e organizativas adequadas e proporcionais, usando uma abordagem baseada em todos os riscos. Essas medidas incluem análise de riscos, políticas de segurança dos sistemas de informação, tratamento de incidentes, continuidade de negócio, gestão de crises, segurança da cadeia de abastecimento, 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 acesso, gestão de ativos e autenticação multifator, quando apropriado. Os órgãos de gestão devem aprovar as medidas de gestão de riscos de cibersegurança, supervisionar a sua implementação e receber formação.

O DORA torna isto ainda mais explícito para as entidades financeiras. Exige mecanismos internos de governação e controlo do risco de TIC, um quadro de gestão do risco de TIC documentado, responsabilidade do órgão de gestão, gestão e comunicação de incidentes relacionados com TIC, testes de resiliência operacional digital, gestão do risco de terceiros de TIC, acompanhamento de auditorias, formação e mecanismos de comunicação. O DORA também deixa claro que as entidades financeiras continuam responsáveis pela conformidade quando recorrem a prestadores terceiros de serviços de TIC.

Isto cria uma nova realidade de conformidade. Um CISO não pode esperar pelo mês da auditoria para descobrir que:

• as revisões de acessos privilegiados foram omitidas durante dois trimestres;
• os planos de saída de fornecedores foram documentados, mas nunca testados;
• os critérios de severidade de incidentes não estão mapeados para os limiares de reporte regulatório;
• as cópias de segurança estão configuradas, mas falta evidência de restauro;
• a gestão nunca reviu tratamentos de risco em atraso;
• os contratos cloud não incluem direitos de auditoria, visibilidade sobre subcontratantes ou cláusulas de notificação de incidentes.

O antigo modelo baseado em projetos cria ciclos de pânico. As equipas correm antes de uma auditoria, recolhem capturas de ecrã, atualizam datas de políticas e esperam que a evidência conte uma história coerente. NIS2 e DORA foram concebidos para fazer essa abordagem falhar. Centram-se em responsabilização, proporcionalidade, resiliência e evidência de operação.

A ISO/IEC 27001:2022 fornece o sistema operativo para este problema. As suas cláusulas exigem que as organizações compreendam o contexto, as partes interessadas, os requisitos legais e contratuais, o âmbito, a liderança, as funções, a avaliação de riscos, o tratamento de riscos, a Declaração de Aplicabilidade, o planeamento operacional, a avaliação de desempenho, a auditoria interna, a revisão pela gestão, o tratamento de não conformidades e a melhoria contínua. Esta estrutura é ideal para combinar NIS2, DORA, RGPD da UE, garantia para clientes e risco interno num único modelo de monitorização contínua.

Conformidade contínua não significa mais painéis de gestão. Significa uma cadência de evidência governada.

Construir o motor de conformidade sobre a ISO/IEC 27001:2022

Muitas organizações interpretam incorretamente a ISO/IEC 27001:2022 como apenas um referencial de certificação. Na prática, é um sistema de gestão de riscos que torna a governação da segurança repetível, mensurável e auditável.

Isto é importante porque NIS2 e DORA não são listas de verificação isoladas. Exigem um modelo operacional capaz de absorver requisitos legais, traduzi-los em controlos, atribuir responsabilidades, monitorizar desempenho e melhorar quando são identificadas lacunas.

As cláusulas fundamentais da ISO/IEC 27001:2022 fornecem esse modelo:

Para uma FinTech, um prestador SaaS, um prestador de serviços de segurança geridos ou um fornecedor de TIC a entidades financeiras, esta estrutura evita projetos de conformidade duplicados. Um único SGSI pode mapear obrigações para controlos uma vez e reutilizar depois a evidência em NIS2, DORA, RGPD da UE, NIST CSF 2.0, COBIT 2019, certificação ISO/IEC 27001:2022 e revisões de garantia para clientes.

Começar pela responsabilidade pelos controlos, não pelas ferramentas

O primeiro padrão de falha na conformidade contínua é a implementação orientada por ferramentas. Uma empresa compra uma plataforma GRC, importa centenas de requisitos, atribui tudo à “Segurança” e chama a isso monitorização contínua. Seis meses depois, o painel de gestão está a vermelho, a engenharia contesta a evidência de vulnerabilidades, o departamento jurídico diz que a documentação de fornecedores está incompleta e a gestão não consegue ver claramente o risco residual.

A ISO/IEC 27001:2022 evita isto ao exigir que responsabilidades e autoridades sejam atribuídas e comunicadas. NIS2 e DORA reforçam a mesma expectativa através da responsabilização da gestão, de funções definidas e da supervisão.

A Política de Funções e Responsabilidades de Governação - PME da Clarysec estabelece:

Cada função com responsabilidade de segurança deve ser registada num registo central e aceite por escrito.

Essa cláusula é mais importante do que a maioria dos painéis de gestão. Se os testes de cópia de segurança, a remediação de vulnerabilidades, a diligência prévia de fornecedores, a classificação de incidentes e a revisão de acessos privilegiados não tiverem responsáveis nomeados, não existe uma cadência de evidência fiável.

A Política de Segurança da Informação operacionaliza isto para ambientes empresariais:

Recolher e reter evidência de auditoria para auditorias e revisões de controlos.

Também exige que os responsáveis pelos controlos:

Reportem o desempenho dos controlos e quaisquer lacunas ou problemas ao Gestor do SGSI.

No Zenith Controls, este tema mapeia diretamente para o controlo ISO/IEC 27002:2022 5.2 Funções e responsabilidades de segurança da informação, 5.35 Revisão independente da segurança da informação e 5.36 Conformidade com políticas, regras e normas de segurança da informação.

O Zenith Blueprint fornece um ponto de partida prático na fase de Fundamentos e Liderança do SGSI, Passo 4: Funções e responsabilidades no SGSI. Recomenda nomeação formal, atualização de descrições de função, alinhamento de KPIs, comunicação a toda a organização e responsabilidade ao nível dos departamentos.

Um registo típico de nomeação pode indicar:

“Com efeitos imediatos, é nomeado Responsável de Segurança da Informação, com responsabilidade por supervisionar e coordenar o SGSI, incluindo gestão de riscos, implementação de controlos e monitorização da conformidade.”

Essa nomeação não é burocracia. É evidência de auditoria para liderança e atribuição de funções segundo a ISO/IEC 27001:2022. Também apoia a supervisão pela gestão no âmbito da NIS2 e a governação do DORA. Reguladores, auditores de certificação e clientes bancários querem ver que a responsabilidade não está implícita. Está atribuída, aceite, dotada de recursos e monitorizada.

Um registo prático de responsabilidade pelos controlos deve incluir estes campos:

Este registo torna-se a ponte entre política e evidência.

Definir KPIs e KRIs que comprovem a eficácia dos controlos

Depois de existirem responsáveis, estes precisam de saber como se define “bom”. A monitorização contínua da conformidade assenta em indicadores significativos, não em intenções genéricas.

“Melhorar a aplicação de patches” não é um KPI. “Rever fornecedores regularmente” não é evidência. “Manter resiliência” não é um controlo mensurável.

A Clarysec separa claramente os dois tipos de indicadores:

• KPI, indicador-chave de desempenho, mede se o processo está a funcionar como esperado.
• KRI, indicador-chave de risco, sinaliza aumento de risco ou violação de limiar que exige escalonamento.

A Política de Gestão de Riscos empresarial estabelece:

Os KRIs (Indicadores-Chave de Risco) e as métricas de segurança devem ser definidos para riscos críticos e monitorizados mensalmente.

Também exige lógica de escalonamento:

Os desencadeadores de escalonamento devem estar incorporados na lógica de monitorização (por exemplo, quando o risco residual aumenta mais de um nível ou quando os prazos de tratamento são falhados).

Para organizações mais pequenas, a Política de Gestão de Riscos - PME da Clarysec adota uma abordagem proporcional:

O progresso na mitigação de riscos deve ser revisto trimestralmente.

Também permite métricas simplificadas:

Podem ser acompanhadas métricas informais (por exemplo, número de riscos abertos, ações em atraso, novos incidentes).

Essa proporcionalidade importa. Um banco multinacional e um fornecedor FinTech com 60 pessoas não precisam da mesma telemetria, mas ambos precisam de responsabilidade atribuída, medição repetível, limiares de escalonamento e evidência de ações corretivas.

Um modelo prático de KPI e KRI para NIS2 e DORA é o seguinte:

Estas métricas apoiam mais do que a certificação ISO/IEC 27001:2022. Também apoiam as medidas de gestão de riscos de cibersegurança da NIS2, a preparação para reporte de incidentes NIS2, a gestão do risco de TIC no DORA, o risco de terceiros no DORA, a responsabilização no RGPD da UE, os resultados de governação do NIST CSF 2.0 e a gestão de desempenho ao estilo COBIT.

Estabelecer uma cadência de evidência antes de a auditoria a solicitar

Muitas organizações recolhem evidência de forma aleatória. Uma captura de ecrã aparece num canal Teams. Um ticket Jira é ligado num email. Um questionário de fornecedor é guardado pela área de Compras. Um teste de cópia de segurança é descrito verbalmente. Durante a semana de auditoria, o Gestor do SGSI transforma-se num investigador forense.

A conformidade contínua exige cadência planeada e higiene adequada da evidência.

A Política de Auditoria e Monitorização da Conformidade - PME da Clarysec estabelece:

Cada auditoria deve incluir um âmbito, objetivos, pessoal responsável e evidência necessária claramente definidos.

Também indica:

A evidência deve ser retida durante pelo menos dois anos, ou por período superior quando exigido por acordos de certificação ou de clientes.

Para organizações empresariais, a Política de Auditoria e Monitorização da Conformidade acrescenta expectativas de automatização:

Devem ser implementadas ferramentas automatizadas para monitorizar a conformidade da configuração, a gestão de vulnerabilidades, o estado dos patches e o acesso privilegiado.

A automatização deve ser direcionada. Controlos de alto risco e alta frequência não devem depender de capturas de ecrã manuais. O melhor modelo de evidência combina telemetria automatizada, atestados dos responsáveis, registos de exceções, registos de tickets, resultados de testes e atas de revisão pela gestão.

Uma convenção de nomenclatura também importa. A evidência deve ser fácil de recuperar sem esforço heroico. Por exemplo:

• relatório semanal de vulnerabilidades: YYYY-MM-DD_Vulnerability-SLA_ControlOwner
• revisão mensal de acessos privilegiados: YYYY-MM_IAM-Privileged-Review_Attestation
• revisão trimestral de fornecedores: YYYY-QX_Critical-Supplier-Review
• pacote de incidente: INC-YYYY-###_Timeline-Classification-RCA-CAPA

É aqui que a política se torna operacional. A retenção de evidência não é uma tarefa de arquivo. Faz parte do controlo.

Mapear um item de evidência para muitas obrigações

A conformidade contínua ganha força quando um item de evidência satisfaz vários referenciais. É por isso que o Zenith Controls é central na abordagem de conformidade cruzada da Clarysec.

Considere o tratamento de incidentes. No âmbito da NIS2, os incidentes significativos exigem reporte por fases, incluindo alerta precoce no prazo de 24 horas após a tomada de conhecimento, notificação no prazo de 72 horas e relatório final no prazo de um mês, sujeito à transposição nacional e aos factos do incidente. O DORA exige que as entidades financeiras façam a gestão, classificação, escalonamento e reporte de incidentes maiores relacionados com TIC usando processos e modelos obrigatórios. O RGPD da UE exige que os responsáveis pelo tratamento avaliem e gerem violações de dados pessoais quando a confidencialidade, integridade ou disponibilidade dos dados pessoais seja afetada.

Um único pacote de evidência de incidente pode apoiar os três se incluir:

• cronologia do incidente e momento de tomada de conhecimento;
• fundamentação da classificação;
• serviços e jurisdições afetados;
• impacto em clientes, transações ou utilizadores;
• avaliação de impacto sobre dados pessoais;
• análise de causa raiz;
• ações de mitigação e recuperação;
• comunicações e notificações;
• registo de escalonamento para a gestão;
• entrada de ação corretiva.

A mesma lógica de conformidade cruzada aplica-se ao risco de fornecedores. A NIS2 exige segurança da cadeia de abastecimento e atenção às relações com fornecedores diretos e prestadores de serviços. O DORA exige estratégia de risco de terceiros de TIC, registos, diligência prévia pré-contratual, cláusulas contratuais, direitos de auditoria, níveis de serviço, estratégias de saída e monitorização do risco de concentração. O NIST CSF 2.0 trata o risco da cadeia de abastecimento como uma disciplina de governação ao longo do ciclo de vida. A ISO/IEC 27001:2022 liga estes requisitos ao âmbito, aos requisitos das partes interessadas, ao tratamento de riscos e ao controlo operacional de processos fornecidos externamente.

Uma matriz prática de evidência ajuda os responsáveis pelos controlos a compreender por que razão a evidência importa:

Esta abordagem evita trabalho de conformidade duplicado. A organização recolhe um conjunto de evidência robusto e mapeia-o depois para várias obrigações.

O modelo de monitorização da Clarysec, da obrigação ao responsável e à evidência

Um modelo de monitorização robusto segue uma sequência simples.

Primeiro, definir a obrigação. Por exemplo, o DORA exige que o risco de terceiros de TIC seja gerido como parte da gestão do risco de TIC, com registos, diligência prévia, requisitos contratuais, direitos de auditoria e estratégias de saída para funções críticas ou importantes. A NIS2 exige segurança da cadeia de abastecimento e ações corretivas adequadas.

Segundo, traduzir a obrigação em requisitos do SGSI da ISO/IEC 27001:2022. Isto inclui requisitos das partes interessadas, âmbito, avaliação de riscos, tratamento de riscos, Declaração de Aplicabilidade, controlo operacional, monitorização, auditoria interna, revisão pela gestão e melhoria.

Terceiro, selecionar controlos operacionais. No Zenith Controls, os controlos centrais de governação para conformidade contínua incluem os controlos ISO/IEC 27002:2022 5.2, 5.35 e 5.36. Os controlos de suporte incluem frequentemente 5.19 Segurança da informação nas relações com fornecedores, 5.21 Gestão da segurança da informação na cadeia de abastecimento de TIC, 5.22 Monitorização, revisão e gestão de alterações de serviços de fornecedores, 5.23 Segurança da informação para a utilização de serviços cloud, 5.24 Planeamento e preparação da gestão de incidentes de segurança da informação, 5.26 Resposta a incidentes de segurança da informação, 5.30 Preparação das TIC para a continuidade de negócio, 5.31 Requisitos legais, estatutários, regulamentares e contratuais, 8.8 Gestão de vulnerabilidades técnicas, 8.13 Cópias de segurança da informação, 8.15 Registo de eventos, 8.16 Atividades de monitorização e 8.9 Gestão da configuração.

Quarto, atribuir o responsável e a cadência. O risco de fornecedores pode envolver Compras, Jurídico, Segurança e o Responsável pelo Serviço de Negócio, mas um responsável principal deve manter o registo e reportar exceções.

Quinto, definir KPIs, KRIs e evidência. Os KPIs de fornecedores podem incluir a percentagem de fornecedores críticos de TIC com diligência prévia concluída, a percentagem com cláusulas contratuais aprovadas, o número sem planos de saída testados e o número de revisões de fornecedores em atraso. Os KRIs podem incluir constatações de fornecedores de alto risco por resolver, risco de concentração acima da tolerância ou ausência de direitos de auditoria para um serviço que suporta uma função crítica ou importante.

Sexto, reportar e escalar. Os painéis mensais do SGSI não devem limitar-se a mostrar estado verde. Devem identificar evidência em atraso, movimento de risco, prazos de tratamento falhados e decisões de gestão necessárias.

Sétimo, auditar e melhorar. Lacunas de evidência tornam-se ações corretivas, não desculpas.

Isto está alinhado com a fase de Auditoria, Revisão e Melhoria do Zenith Blueprint. O Passo 25, Programa de Auditoria Interna, recomenda cobrir processos e controlos relevantes do SGSI ao longo do ciclo de auditoria, com uma auditoria anual de âmbito completo e verificações por amostragem trimestrais mais pequenas em áreas de alto risco, quando apropriado. O Passo 28, Revisão pela Gestão, exige entradas como alterações de requisitos, resultados de monitorização e medição, resultados de auditoria, incidentes, não conformidades, oportunidades de melhoria e necessidades de recursos. O Passo 29, Melhoria Contínua, usa o Registo de CAPA para capturar descrição do problema, causa raiz, ação corretiva, responsável, data-alvo e estado.

Isto é conformidade contínua na prática.

Um cenário prático: vulnerabilidade crítica numa API pública

Às 02:15, é gerado um alerta SIEM. Uma análise de vulnerabilidades identificou uma vulnerabilidade crítica de execução remota de código num gateway de API exposto ao público que suporta um serviço de pagamentos regulado.

O modelo de monitorização contínua deve responder sem esperar por uma reunião.

Primeiro, o inventário de ativos classifica o gateway como crítico. O relógio do KPI de gestão de vulnerabilidades começa. O KRI relativo a vulnerabilidades críticas não corrigidas aumenta. Se o ativo estiver exposto à Internet e a exploração estiver ativa, o limiar de escalonamento é acionado imediatamente.

Segundo, o ticket é encaminhado para a equipa DevOps de prevenção. O Responsável de DevOps, como responsável pelo controlo de gestão de vulnerabilidades, recebe uma notificação automatizada. O Gestor do Centro de Operações de Segurança (SOC) acompanha se existem indicadores de exploração. O Gestor do SGSI monitoriza se os critérios de incidente são cumpridos.

Terceiro, a evidência é recolhida como subproduto do fluxo de trabalho. O alerta SIEM, a análise de vulnerabilidades, a classificação do ativo, os carimbos temporais do ticket, o chat de resposta, o registo de patch, a análise de validação e a aprovação de encerramento são anexados ao pacote de evidência.

Quarto, a equipa avalia se o evento é apenas uma vulnerabilidade, um evento de segurança ou um incidente. Se existirem impacto no serviço, indicadores de compromisso, impacto no cliente ou exposição de dados pessoais, o fluxo de trabalho de incidentes desencadeia as avaliações de reporte NIS2, DORA, RGPD da UE e contratuais.

Quinto, a gestão recebe um relatório conciso. Se a vulnerabilidade tiver sido remediada em quatro horas, a evidência apoia a eficácia do controlo. Se o SLA tiver sido falhado, o registo de CAPA regista a causa raiz, a ação corretiva, o responsável, a data-alvo e o estado.

Este evento único gera evidência útil para gestão de vulnerabilidades, preparação para incidentes, monitorização, acesso a ativos críticos, revisão pela gestão e melhoria contínua.

Como auditores e reguladores testarão o mesmo modelo de monitorização

Um programa maduro de conformidade contínua deve resistir a diferentes perspetivas de auditoria. A evidência não muda, mas as perguntas sim.

Para o controlo ISO/IEC 27002:2022 5.35 Revisão independente da segurança da informação, um auditor ISO/IEC 27001:2022 focar-se-á no plano de auditoria interna, âmbito, competência, constatações e ações corretivas. Um regulador NIS2 ou DORA focar-se-á em saber se a gestão compreendeu as constatações, financiou a remediação e reduziu o risco sistémico. Um avaliador NIST CSF 2.0 pode mapear a revisão para a função GOVERN, incluindo supervisão e ajuste de desempenho.

O mesmo conjunto de evidência serve todos eles se for completo, atual e ligado à responsabilidade atribuída.

Armadilhas comuns que enfraquecem a conformidade contínua

A primeira armadilha é tratar NIS2 e DORA como projetos separados. Isso cria registos duplicados, métricas conflituantes e responsáveis pelos controlos exaustos. Use a ISO/IEC 27001:2022 como base do SGSI e mapeie as obrigações através de uma única biblioteca de controlos.

A segunda armadilha é atribuir controlos a equipas em vez de pessoas. “TI é responsável pelas cópias de segurança” não basta. Um responsável nomeado deve atestar, reportar exceções e escalar o risco.

A terceira armadilha é recolher evidência sem avaliar a eficácia. Uma captura de ecrã de sucesso de cópia de segurança não prova recuperabilidade. Um teste de restauro prova. Um questionário de fornecedor não prova resiliência de terceiros. Cláusulas contratuais, direitos de auditoria, termos de notificação de incidentes, relatórios de desempenho e planeamento de saída criam evidência mais forte.

A quarta armadilha é medir atividade em vez de risco. Contar vulnerabilidades é útil. Acompanhar vulnerabilidades críticas em atraso em sistemas expostos à Internet é melhor. Contar fornecedores é útil. Acompanhar fornecedores críticos sem planos de saída é melhor.

A quinta armadilha é uma disciplina fraca de ações corretivas. O Passo 29 do Zenith Blueprint é claro: as constatações precisam de descrição do problema, causa raiz, ação corretiva, responsável, data-alvo e estado. Se o registo de CAPA não for revisto, a conformidade contínua torna-se acumulação contínua de fragilidades conhecidas.

O que a gestão deve ver todos os meses

Os órgãos de gestão no âmbito da NIS2 e do DORA não precisam de exportações brutas de scanners. Precisam de uma visão de risco cibernético e de TIC com qualidade para decisão.

Um painel mensal para o conselho de administração ou para a gestão deve incluir:

• principais riscos cibernéticos e de TIC com movimento do risco residual;
• tratamentos de risco em atraso e prazos falhados;
• incidentes significativos, candidatos a incidentes maiores relacionados com TIC e lições aprendidas;
• exceções de risco de fornecedores críticos;
• desempenho de SLA de vulnerabilidades para ativos críticos;
• estado dos testes de cópia de segurança e recuperação;
• exceções de revisão de acessos privilegiados;
• taxa de conclusão da evidência de conformidade;
• constatações de auditoria e estado de CAPA;
• decisões de recursos necessárias.

Isto apoia diretamente a revisão pela gestão da ISO/IEC 27001:2022 e as expectativas de governação da NIS2 e do DORA. Também se alinha com o NIST CSF 2.0, no qual os executivos definem prioridades, responsabilização, recursos e apetite ao risco, enquanto os gestores traduzem essas prioridades em perfis alvo e planos de ação.

Construir esta semana o seu ritmo de evidência para NIS2 e DORA

Não precisa de resolver tudo de uma vez para começar. Uma primeira semana útil pode ser simples.

Dia 1, crie um registo de responsáveis pelos controlos para cinco domínios: governação e gestão de riscos, gestão e reporte de incidentes, gestão de vulnerabilidades e patches, risco de fornecedores e cloud, e continuidade de negócio e recuperação.

Dia 2, defina um KPI e um KRI para cada domínio. Mantenha-os específicos, mensuráveis e ligados ao apetite ao risco.

Dia 3, mapeie cada item de evidência para o valor que entrega à NIS2, ao DORA, à ISO/IEC 27001:2022, ao RGPD da UE e à garantia para clientes.

Dia 4, defina cadência de evidência, localização de armazenamento, convenção de nomenclatura, regra de retenção e revisor.

Dia 5, execute um escalonamento em exercício de tabletop. Use um cenário de indisponibilidade cloud ou de vulnerabilidade crítica. Confirme classificação, avaliação de reporte regulatório, comunicação ao cliente, armazenamento de evidência e criação de CAPA.

Se a sua organização ainda gere NIS2 e DORA através de folhas de cálculo, workshops anuais e pastas de evidência dispersas, está na altura de mudar para uma cadência operacional monitorizada.

Comece com três ações:

1. Construa um registo de responsáveis pelos controlos para os seus domínios de maior risco.
2. Defina um KPI, um KRI, um item de evidência e uma cadência por controlo.
3. Realize uma revisão de evidência de 30 minutos e abra itens de CAPA para tudo o que estiver em falta.

A Clarysec pode ajudar a acelerar esta transição com o Zenith Blueprint para sequenciação da implementação, o Zenith Controls para mapeamento de conformidade cruzada e a biblioteca de políticas da Clarysec, incluindo a Política de Segurança da Informação, a Política de Gestão de Riscos, a Política de Auditoria e Monitorização da Conformidade, a Política de Funções e Responsabilidades de Governação - PME, a Política de Gestão de Riscos - PME e a Política de Auditoria e Monitorização da Conformidade - PME.

O objetivo não é produzir mais documentação de conformidade. O objetivo é responder à pergunta de sexta-feira à tarde com confiança:

“Sim, sabemos quem é o responsável pelo controlo, conhecemos o KPI, temos a evidência, conhecemos as exceções e a gestão reviu o risco.”

Contacte a Clarysec para construir um modelo de monitorização contínua da conformidade preparado para auditoria, adequado ao conselho de administração e suficientemente resiliente para NIS2, DORA e o próximo regulamento que vier a seguir.