Preparação para o Regulamento Cibersolidariedade da UE com ISO 27001

O incidente das 03:17 que transforma a cooperação da UE num problema de auditoria

Às 03:17 de uma terça-feira de manhã, Maria, Diretora de Segurança da Informação da InnovateCloud, olha para um ecrã cheio de alertas. A sua empresa é um prestador europeu de SaaS de média dimensão que presta serviços a clientes de logística na Alemanha, em França e na Polónia. O primeiro alerta parece indicar acesso privilegiado suspeito num tenant de produção. Dez minutos depois, o prestador de serviços de segurança geridos reporta atividade semelhante que afeta outros dois clientes. Às 04:00, o SOC identifica chamadas de API a partir de infraestrutura anteriormente associada à preparação de campanhas de ransomware.

A InnovateCloud não era o alvo inicial. Um prestador de infraestrutura central parece estar dentro do raio de impacto. Ainda assim, o impacto passou a ser problema de Maria.

Um dos clientes afetados é um banco alemão que exige respostas ao abrigo da DORA. Outro é um fornecedor crítico do setor da energia já classificado ao abrigo das regras nacionais da NIS2. O ambiente pode conter dados pessoais, mas a exfiltração ainda não está confirmada. A equipa de segurança quer conter a ameaça de imediato. A área jurídica quer saber se o prazo de alerta precoce de 24 horas da NIS2 já começou. A responsável pela privacidade pergunta se poderá haver notificação de violação de dados ao abrigo do RGPD da UE. O conselho de administração quer saber se a indisponibilidade pode propagar-se por vários Estados-Membros.

Em 2026, isto já não é apenas uma crise interna.

O Regulamento Cibersolidariedade da UE altera a realidade operacional dos ciberincidentes de grande escala e transfronteiriços. Introduz mecanismos de deteção, preparação e resposta ao nível da UE, incluindo o Sistema Europeu de Alerta de Cibersegurança, o Mecanismo de Emergência de Cibersegurança e a Reserva de Cibersegurança da UE. Mesmo que uma organização nunca solicite diretamente apoio à reserva, a sua evidência, os contactos com autoridades, os contratos com fornecedores, as cronologias de incidentes e as comunicações com clientes podem passar a integrar uma cadeia de resposta europeia mais ampla.

A lacuna torna-se visível rapidamente. Muitas organizações têm ferramentas, tickets e políticas, mas não têm evidência que resista ao escrutínio regulatório. Conseguem dizer “contactámos o regulador”, mas não conseguem provar quem estava autorizado, que limiar desencadeou o contacto, o que foi comunicado, se os logs foram preservados, se um fornecedor estava contratualmente obrigado a prestar apoio ou se é possível reconstruir um relatório final a partir de decisões contemporâneas.

A resposta não é outro dossiê isolado do “Regulamento Cibersolidariedade”. A resposta é um Sistema de Gestão de Segurança da Informação ISO/IEC 27001:2022 que produz evidência uma vez e a reutiliza para responder às expectativas da NIS2, da DORA, do RGPD da UE, do NIST CSF 2.0 e do COBIT 2019.

Essa evidência começa antes do incidente.

Porque o Regulamento Cibersolidariedade da UE eleva o padrão de evidência

O Regulamento Cibersolidariedade foi concebido para deteção, preparação e resposta a crises cibernéticas ao nível da UE. O seu efeito prático para Diretores de Segurança da Informação, auditores e gestores de conformidade é claro: a coordenação de incidentes de grande escala exige evidência mais rápida, mais limpa, mais consistente e mais fácil de partilhar com partes interessadas de confiança.

Quando existe a possibilidade de impacto transfronteiriço, uma organização pode ter de coordenar com CSIRT nacionais, autoridades competentes, reguladores setoriais, autoridades de controlo de proteção de dados, supervisores financeiros, autoridades policiais, clientes, subcontratantes responsáveis pelo tratamento de dados, fornecedores e prestadores externos de resposta a incidentes. A Reserva de Cibersegurança da UE acrescenta outra dimensão, porque prestadores privados pré-validados podem apoiar a preparação, a resposta e a recuperação. Isto torna ainda mais importantes a governação de fornecedores, a autoridade legal, o tratamento de dados e a preservação de evidência.

As entidades privadas estão no centro desta realidade. Prestadores de serviços cloud, centros de dados, prestadores de serviços geridos, prestadores de serviços de segurança geridos, operadores de infraestrutura digital, fintechs e plataformas SaaS detêm frequentemente a telemetria, os logs, os dados de impacto em clientes e os factos técnicos de que as autoridades necessitam para compreender um incidente grave.

A NIS2 já aponta nesta direção. Aplica-se a muitas entidades médias e grandes nos setores dos Anexos I e II que prestam serviços ou exercem atividades na UE. Também abrange determinadas entidades independentemente da dimensão, incluindo prestadores de serviços de confiança, prestadores de serviços DNS, registos de domínios de topo e prestadores de serviços de registo de nomes de domínio. O Anexo I inclui infraestrutura digital, como serviços de computação em cloud, serviços de centros de dados, redes de distribuição de conteúdos, prestadores de DNS, prestadores de serviços de confiança e registos TLD. Inclui ainda a gestão de serviços TIC B2B, incluindo prestadores de serviços geridos e prestadores de serviços de segurança geridos. O Anexo II inclui prestadores digitais, como mercados em linha, motores de pesquisa em linha e plataformas de serviços de redes sociais.

A DORA acrescenta uma segunda camada para o setor financeiro. Desde 17 de janeiro de 2025, aplica-se a um amplo conjunto de entidades financeiras, incluindo instituições de crédito, instituições de pagamento, instituições de moeda eletrónica, empresas de investimento, prestadores de serviços de criptoativos, plataformas de negociação, empresas de seguros e resseguros, agências de notação de crédito, prestadores de serviços de financiamento colaborativo e outras entidades. Também cria expectativas significativas para prestadores terceiros de serviços TIC, porque as entidades financeiras continuam responsáveis pelos serviços TIC externalizados.

Um incidente numa fintech em 2026 pode, portanto, ser coordenado através dos canais de supervisão da DORA, enquanto o fornecedor SaaS ou MSSP que apoia essa fintech pode estar abrangido pela NIS2. O mesmo evento técnico pode criar diferentes deveres de reporte, expectativas de evidência e obrigações contratuais para diferentes intervenientes.

A ISO/IEC 27001:2022 dá às organizações o sistema operativo para gerir esta complexidade. As cláusulas 4.1 a 4.4 exigem que a organização enquadre o SGSI no seu contexto de negócio, identifique partes interessadas e os respetivos requisitos legais, regulamentares e contratuais, defina limites e dependências e estabeleça o sistema de gestão. As cláusulas 5.1 a 5.3 tornam a liderança responsável pela política, pelos recursos, pela integração e pela atribuição de funções. As cláusulas 6.1.1 a 6.1.3 exigem avaliação de riscos, tratamento de riscos e uma Declaração de Aplicabilidade repetíveis. A cláusula 8.1 exige controlo operacional, incluindo controlo sobre processos, produtos e serviços fornecidos externamente.

Este é o núcleo da preparação para o Regulamento Cibersolidariedade: demonstrar que a resposta à crise é gerida, testada e auditável, e não improvisada.

O modelo de evidência da Clarysec: um incidente, muitas obrigações

Um incidente transfronteiriço não espera que as equipas jurídicas o classifiquem. A evidência deve ser capturada desde o primeiro alerta e depois encaminhada para os percursos corretos de reporte e coordenação.

A abordagem da Clarysec liga três ativos:

1. Zenith Blueprint: Roteiro de 30 passos de um auditor Zenith Blueprint, que transforma a implementação da ISO/IEC 27001:2022 num percurso sequenciado e preparado para auditoria.
2. Zenith Controls: O guia de conformidade cruzada Zenith Controls, que mapeia os controlos ISO/IEC 27002:2022 para controlos relacionados, atributos, capacidades operacionais, domínios de segurança e expectativas de evidência entre referenciais.
3. Modelos de políticas Clarysec para resposta a incidentes, recolha de evidência, segurança de fornecedores, registo de logs, monitorização e continuidade de negócio, adaptados a ambientes empresariais e PME.

No Zenith Blueprint, na fase Controlos em Ação, o passo 22 aborda o controlo ISO/IEC 27002:2022 5.5, Contacto com autoridades. Indica:

O controlo 5.5 assegura que uma organização está preparada para interagir com autoridades externas quando necessário, não de forma reativa nem em pânico, mas através de canais predefinidos, estruturados e bem compreendidos.

A mesma secção coloca a pergunta a que todos os Diretores de Segurança da Informação devem responder antes da crise:

se a sua organização fosse alvo de um ciberataque, estivesse envolvida numa violação de dados ou sob investigação, quem faria a chamada para as autoridades? Como saberiam o que dizer? Em que condições seria iniciado esse contacto?

Isto não é burocracia administrativa. Num ambiente do Regulamento Cibersolidariedade, é a diferença entre um alerta precoce sereno e mensagens contraditórias entre jurisdições.

O Zenith Controls trata o controlo ISO/IEC 27002:2022 5.5, Contacto com autoridades, como preventivo e corretivo, ligado à Confidencialidade, Integridade e Disponibilidade, e alinhado com os conceitos Identify, Protect, Respond e Recover. Liga o 5.5 ao planeamento e preparação da gestão de incidentes, ao reporte de eventos, às informações sobre ameaças, a grupos de interesse especial e à resposta a incidentes.

O mesmo guia trata o controlo ISO/IEC 27002:2022 5.24, Planeamento e preparação da gestão de incidentes de segurança da informação, como um controlo corretivo ligado a Respond e Recover. As suas ligações à avaliação de eventos, à resposta a incidentes, às lições aprendidas, ao registo de logs, à monitorização, à segurança durante perturbações e à continuidade mostram o que os auditores testam frequentemente: se o plano liga deteção, classificação, escalonamento, evidência, recuperação e aprendizagem.

Para o tratamento de evidência, o controlo ISO/IEC 27002:2022 5.28, Recolha de evidência, é especialmente importante. O Zenith Controls liga-o à resposta a incidentes, ao registo de logs, à monitorização e ao reporte de eventos. Num incidente transfronteiriço grave, é aqui que a investigação técnica se torna defensável.

Mapear a preparação para o Regulamento Cibersolidariedade para evidência ISO 27001

O Regulamento Cibersolidariedade da UE cria um ambiente de preparação e coordenação. A ISO/IEC 27001:2022 fornece o motor de evidência. A NIS2, a DORA e o RGPD da UE definem muitas expectativas específicas de reporte, governação e proteção.

Repare no que está ausente: um silo separado de conformidade. A mesma evidência que suporta a certificação ISO/IEC 27001:2022 pode suportar a responsabilização da gestão na NIS2, a gestão do risco de TIC na DORA, a responsabilização de segurança no RGPD da UE, os resultados de comunicação do NIST CSF e as expectativas de garantia do COBIT 2019.

NIS2: o relógio de reporte começa quando há tomada de conhecimento

A NIS2 é central para a preparação de 2026 porque define um fluxo faseado de reporte de incidentes.

O Article 23 exige que entidades essenciais e importantes notifiquem o seu CSIRT ou autoridade competente, sem demora injustificada, sobre incidentes significativos que afetem a prestação de serviços. O alerta precoce deve ser submetido sem demora injustificada e, no máximo, 24 horas após a tomada de conhecimento do incidente significativo. Deve indicar, quando aplicável, se há suspeita de atos maliciosos ou ilícitos e se é possível impacto transfronteiriço.

Segue-se uma notificação de incidente sem demora injustificada e, no máximo, 72 horas após a tomada de conhecimento, atualizando o alerta precoce e fornecendo uma avaliação inicial da gravidade, impacto e indicadores de compromisso disponíveis. O relatório final é devido no prazo de um mês após a notificação do incidente, com gravidade, impacto, tipo provável de ameaça ou causa raiz, medidas de mitigação e impacto transfronteiriço.

É por isto que a resposta a incidentes não pode começar com um documento em branco.

A Política de Resposta a Incidentes empresarial Política de Resposta a Incidentes declara:

NIS2 Article 23 (notificação no prazo de 24 horas após a tomada de conhecimento do incidente)

A Política de Resposta a Incidentes - PME Política de Resposta a Incidentes - PME traz a mesma lógica temporal para uma governação prática:

“Os prazos de resposta, incluindo recuperação de dados e obrigações de notificação, devem ser documentados e alinhados com os requisitos legais, como o requisito do RGPD da UE de notificação de violação de dados pessoais no prazo de 72 horas.”

Da Política de Resposta a Incidentes - PME, secção “Requisitos de governação”, cláusula 5.3.2.

Também obriga a integrar a avaliação multirregime no processo de incidente:

“Quando estiverem envolvidos dados de clientes, o Diretor-Geral deve avaliar as obrigações legais de notificação com base na aplicabilidade do RGPD da UE, da NIS2 ou da DORA.”

Da Política de Resposta a Incidentes - PME, secção “Tratamento do risco e exceções”, cláusula 7.4.1.

Num cenário do Regulamento Cibersolidariedade, “é possível impacto transfronteiriço” torna-se operacionalmente importante. O alerta precoce pode não conter todos os factos, mas a organização deve conseguir demonstrar por que suspeitou, ou não suspeitou, de impacto transfronteiriço com base na evidência disponível.

O registo de incidente deve capturar:

• Quando a organização tomou conhecimento.
• Quem declarou o evento como potencial incidente.
• Que serviços, países, clientes ou setores foram potencialmente afetados.
• Se havia suspeita de atividade maliciosa ou ilícita.
• Que indicadores de compromisso estavam disponíveis.
• Que via de contacto com autoridades foi usada.
• Se eram necessárias comunicações a clientes.
• Que evidência foi preservada antes da remediação de maior impacto.

O melhor momento para conceber estes campos é antes das 03:17.

DORA: quando o cliente é regulado, mas o fornecedor detém os logs

A DORA altera a conversa com fornecedores. As entidades financeiras devem gerir o risco de terceiros de TIC como parte do seu quadro de gestão do risco de TIC. A externalização de serviços TIC não transfere a responsabilidade regulatória para fora da entidade financeira.

A DORA exige estratégias de risco de terceiros de TIC, registos de contratos de serviços TIC, diligência prévia, planeamento de auditoria e inspeção, direitos de cessação e estratégias de saída testadas para serviços TIC críticos ou importantes. O Article 30 exige clareza contratual, incluindo descrições de serviços, localizações, tratamento de dados, Confidencialidade, Integridade, Disponibilidade, níveis de serviço, assistência durante incidentes TIC, cooperação com autoridades e direitos de cessação. Para funções críticas ou importantes, aplicam-se termos mais rigorosos.

Voltemos ao incidente de Maria. O banco alemão é regulado pela DORA. A InnovateCloud presta serviços SaaS. O MSSP deteta atividade suspeita. O prestador de infraestrutura cloud detém alguns dos principais logs de auditoria. Um subcontratante opera parte da cadeia de processamento de telemetria. O banco continua responsável, mas não consegue classificar e reportar corretamente sem evidência dos fornecedores.

A Clarysec aborda isto através da classificação de fornecedores e da evidência contratual. A Política de Segurança de Terceiros e Fornecedores empresarial Política de Segurança de Terceiros e Fornecedores exige:

Os contratos com fornecedores devem incluir:

A Política de Segurança de Terceiros e Fornecedores - PME Política de Segurança de Terceiros e Fornecedores - PME usa a mesma lógica de conformidade num modelo operacional mais leve:

Os contratos devem incluir cláusulas obrigatórias que cubram:

O valor está no calendário por trás destas palavras: deveres de notificação de incidentes, acesso a logs, direitos de auditoria, confidencialidade, localização de dados, controlos de subcontratantes, cooperação com autoridades, apoio à recuperação e obrigações de saída.

O Zenith Blueprint, na fase Controlos em Ação, passo 23, fornece a via de implementação:

Compile uma lista completa de fornecedores e prestadores de serviços atuais (5.19) e classifique-os com base no acesso a sistemas, dados ou controlo operacional. Para cada fornecedor classificado, verifique que as expectativas de segurança estão claramente integradas nos contratos (5.20), incluindo confidencialidade, acesso, reporte de incidentes e obrigações de conformidade.

Continua com o risco a jusante:

Para cada fornecedor crítico, identifique se utiliza subcontratantes (subcontratantes subsequentes) que possam aceder aos seus dados ou sistemas. Documente de que forma os seus requisitos de segurança da informação são transferidos para estas partes, seja através dos termos contratuais do seu fornecedor ou das suas próprias cláusulas diretas.

Isto também é preparação para a Reserva de Cibersegurança. Se um prestador externo de resposta entrar no seu ambiente durante uma emergência, tem de conhecer o fundamento legal, o âmbito de acesso, as regras de evidência, as obrigações de tratamento de dados, a via de coordenação com autoridades e as condições de saída. A DORA torna isto explícito para entidades financeiras. A NIS2 torna-o relevante para entidades essenciais e importantes. A ISO/IEC 27001:2022 torna-o auditável.

RGPD da UE: a pergunta sobre violação de dados dentro da crise cibernética

Nem todos os incidentes de cibersegurança são violações de dados pessoais, mas todos os incidentes graves devem ser avaliados quanto a essa possibilidade.

O RGPD da UE aplica-se ao tratamento no contexto de um estabelecimento na UE, bem como a responsáveis pelo tratamento ou subcontratantes fora da UE que ofereçam bens ou serviços a pessoas na UE ou monitorizem o seu comportamento na UE. Define dados pessoais, tratamento, responsável pelo tratamento, subcontratante e violação de dados pessoais. Os seus princípios incluem Integridade, Confidencialidade e responsabilização, o que significa que os responsáveis pelo tratamento devem conseguir demonstrar conformidade.

Durante o incidente das 03:17, a equipa de Maria deve perguntar:

• Foram dados pessoais acedidos, divulgados, alterados, perdidos ou destruídos?
• A InnovateCloud é responsável pelo tratamento, subcontratante ou ambos relativamente aos dados afetados?
• Estão envolvidas categorias especiais de dados pessoais?
• Que clientes ou indivíduos são afetados?
• Os logs são suficientes para avaliar o âmbito?
• As obrigações de notificação do RGPD da UE decorrem em paralelo com as obrigações da NIS2 ou da DORA?

É por isto que a coordenação de privacidade pertence ao escalonamento do incidente, e não a uma revisão jurídica tardia depois de os sistemas terem sido reconstruídos e os logs terem sido rodados.

A Política de Registo de Logs e Monitorização - PME Política de Registo de Logs e Monitorização - PME declara:

Alertas de alta prioridade devem ser escalados para o Diretor-Geral e para o Coordenador de Privacidade no prazo de 24 horas

Esta cláusula é simples, mas resolve um padrão real de falha. Os responsáveis pela privacidade precisam de evidência enquanto esta ainda está suficientemente atual para determinar se ocorreu uma violação de dados pessoais e se os indivíduos estão em risco.

Construir um pacote de evidência de 24 horas para incidentes transfronteiriços

Um exercício prático de preparação deve simular as primeiras 24 horas de um incidente transfronteiriço. O objetivo não é reportar em excesso. O objetivo é demonstrar que a organização consegue reunir factos, tomar decisões defensáveis e manter comunicações consistentes.

Cenário

O seu MSSP deteta acesso privilegiado suspeito a partir de uma região invulgar contra o seu tenant de produção. A mesma infraestrutura de origem surge em alertas que afetam dois clientes em dois Estados-Membros. Um cliente é uma entidade financeira. O ambiente afetado contém dados pessoais, mas a exfiltração não está confirmada.

Passo 1: Abrir o registo de incidente

Crie o ticket de incidente usando campos de classificação aprovados. Inclua hora de tomada de conhecimento, fonte de deteção, ativos impactados, serviços impactados, países potencialmente afetados, atividade maliciosa suspeita, gravidade inicial e comandante do incidente.

Associe isto aos controlos ISO/IEC 27002:2022 5.24, 5.25 e 5.26, e aos controlos do Anexo A da ISO/IEC 27001:2022 A.5.24, A.5.25 e A.5.26.

Passo 2: Acionar o fluxo de decisão sobre autoridades

Use a matriz de contactos com autoridades exigida pelo passo 22 do Zenith Blueprint. Identifique as autoridades potencialmente relevantes: CSIRT nacional, autoridade de controlo de proteção de dados, regulador financeiro, autoridades policiais e regulador setorial.

Registe a decisão e a fundamentação. Se não for emitido um alerta precoce NIS2, capture o motivo. Se for possível impacto transfronteiriço, registe a evidência que sustenta essa conclusão.

Passo 3: Preservar evidência antes de remediações de maior impacto

A Política de Recolha de Evidência e Análise Forense empresarial Política de Recolha de Evidência e Análise Forense declara:

Toda a evidência recolhida deve ser identificada de forma única, rotulada e armazenada num repositório seguro com:

A Política de Recolha de Evidência e Análise Forense - PME Política de Recolha de Evidência e Análise Forense - PME aplica a mesma disciplina de forma mais simples:

“Cada item de evidência digital deve ser registado com:”

Da Política de Recolha de Evidência e Análise Forense - PME, secção “Requisitos de governação”, cláusula 5.2.1.

Para o exercício de mesa, recolha entradas de evidência exemplificativas: exportação de alerta SIEM, logs do fornecedor de identidade, registos de sessões privilegiadas, snapshot de endpoint, logs de firewall, logs de auditoria cloud, notas de impacto em clientes e aprovações de comunicação.

Passo 4: Ativar assistência de fornecedores

Verifique o Registo de Fornecedores. Identifique o MSSP, o prestador de serviços cloud e subcontratantes críticos. Confirme cláusulas de apoio a incidentes, contactos de escalonamento, períodos de retenção de logs, formato de evidência e obrigações de cooperação com autoridades.

Isto suporta diretamente os requisitos da DORA relativos a risco de terceiros de TIC e as expectativas da NIS2 sobre segurança da cadeia de fornecimento.

Passo 5: Redigir três comunicações

Redija três comunicações a partir da mesma base factual:

Passo 6: Encerrar com lições aprendidas

Atualize o Registo de Riscos, a Declaração de Aplicabilidade, o Registo de Fornecedores e o Plano de Resposta a Incidentes. Se o exercício revelar logs em falta, contactos com autoridades pouco claros ou cláusulas fracas com fornecedores, levante ações corretivas.

O Zenith Blueprint, na fase Controlos em Ação, passo 23, instrui as organizações a validar capacidades de incidente desta forma:

Selecione um evento recente ou conduza um exercício de mesa para validar o seu plano. Capture e registe em logs todas as decisões, papéis e comunicações (5.26), e atualize o plano com lições aprendidas (5.27). Confirme que existem procedimentos para preservar evidência forense (5.28), incluindo snapshots de logs, cópias de segurança e isolamento seguro dos sistemas impactados.

Esse parágrafo é uma agenda de exercício preparada para auditoria.

Registo de logs: a diferença entre coordenação e especulação

A coordenação de incidentes transfronteiriços falha quando todos têm opiniões e ninguém tem carimbos temporais.

O Zenith Blueprint, na fase Controlos em Ação, passo 19, apresenta-o claramente:

O registo de logs é o sangue vital de qualquer ambiente de TI seguro. Sem ele, os incidentes permanecem invisíveis, a responsabilização desvanece e as relações de causa e efeito desaparecem no vazio.

E continua:

No essencial, o registo de logs é sobre rastreabilidade. Quando algo corre mal, seja uma tentativa falhada de autenticação, a eliminação de ficheiros críticos ou um script não autorizado em execução num servidor, os logs fornecem o fio forense que ajuda a compreender o que realmente aconteceu.

Para a NIS2, os logs suportam a notificação de incidente em 72 horas com gravidade inicial, impacto e indicadores de compromisso. Para a DORA, os logs suportam a classificação de incidentes graves relacionados com TIC, a análise de causa raiz, o impacto operacional e a responsabilização de terceiros. Para o RGPD da UE, os logs suportam a avaliação sobre se dados pessoais foram acedidos ou divulgados. No contexto do Regulamento Cibersolidariedade, os logs suportam consciência situacional partilhada sem obrigar os intervenientes de resposta a depender de especulação.

Se a resposta a qualquer pergunta for “não temos a certeza”, o tema pertence ao plano de tratamento de riscos.

Continuidade de negócio e operações de crise seguras

A conversa sobre o Regulamento Cibersolidariedade centra-se naturalmente na resposta a incidentes, mas resiliência também significa manter serviços críticos seguros durante perturbações.

O Article 21 da NIS2 exige uma abordagem multirriscos que cubra tratamento de incidentes, continuidade de negócio, gestão de cópias de segurança, recuperação de desastre, gestão de crises, segurança da cadeia de fornecimento, tratamento de vulnerabilidades, avaliação de eficácia, higiene de cibersegurança, criptografia, segurança de recursos humanos, controlo de acesso, gestão de ativos, autenticação multifator, comunicações seguras e comunicações de emergência seguras quando adequado.

A DORA exige igualmente governação, gestão do risco de TIC, gestão de incidentes, testes de resiliência, gestão de risco de terceiros, continuidade e recuperação. Entidades mais pequenas podem ter requisitos simplificados, mas continuam a precisar de gestão do risco de TIC documentada, monitorização, sistemas resilientes, tratamento de incidentes, identificação de dependências de terceiros, cópias de segurança, restauro, testes, aprendizagem pós-incidente e formação.

A Política de Continuidade de Negócio e Recuperação de Desastre empresarial Política de Continuidade de Negócio e Recuperação de Desastre parte de um requisito simples:

Os planos devem cobrir:

Por trás dessa frase está a evidência de continuidade que os auditores esperam: prioridades de recuperação, objetivos de tempo de recuperação, objetivos de ponto de recuperação, calendários de cópias de segurança, testes de restauro, papéis de crise, comunicações alternativas, dependências de fornecedores e ações de melhoria pós-exercício.

Os controlos ISO/IEC 27002:2022 5.29 e 5.30 são centrais aqui. O controlo 5.29 aborda a segurança da informação durante perturbações. O controlo 5.30 aborda a preparação das TIC para a continuidade de negócio. No Zenith Controls, o planeamento de incidentes no 5.24 está ligado à segurança durante perturbações e ao planeamento mais amplo da continuidade. Isto é especialmente relevante quando os canais normais estão indisponíveis, os sistemas de identidade estão degradados ou as equipas de crise têm de coordenar com autoridades através de comunicações de emergência seguras.

Mapa de conformidade cruzada: NIS2, DORA, RGPD da UE, NIST CSF 2.0 e COBIT 2019

Um Diretor de Segurança da Informação não precisa de cinco programas de incidentes separados. Precisa de um modelo de evidência que possa ser visto através de cinco lentes.

O método de perfis atuais e alvo do NIST CSF 2.0 é especialmente útil para organizações que ainda não têm maturidade suficiente para uma plataforma GRC totalmente integrada. Incentiva as organizações a definir o âmbito de um perfil, recolher entradas como políticas, prioridades de risco empresarial, análises de impacto no negócio, requisitos, normas, procedimentos, salvaguardas e papéis, depois analisar lacunas e criar um plano de ação priorizado. Isto aproxima-se de um ciclo prático de preparação para o Regulamento Cibersolidariedade: evidência atual, obrigações alvo, plano de lacunas, proprietários, datas e trilho de auditoria.

Auditores no estilo COBIT 2019 e ISACA tendem a perguntar se os objetivos de governação têm proprietários, são medidos e são monitorizados. Não ficarão satisfeitos com “o SOC trata disso”. Perguntarão como os órgãos de gestão aprovam medidas de risco, como o desempenho é reportado, como é governado o risco de terceiros, como são aceites exceções e como são acompanhadas as ações corretivas.

Como os auditores testarão o mesmo incidente

O mesmo incidente das 03:17 produz perguntas de auditoria diferentes consoante o mandato do avaliador.

Um auditor ISO/IEC 27001:2022 começará pelo SGSI. Perguntará se o processo de incidentes está no âmbito, se os requisitos das partes interessadas incluem NIS2, DORA, RGPD da UE e contratos, se a avaliação de riscos considerou cenários transfronteiriços e de fornecedores, se os controlos do Anexo A foram selecionados na Declaração de Aplicabilidade e se os registos operacionais comprovam que o processo foi seguido.

Uma autoridade ou avaliador focado na NIS2 concentrar-se-á na responsabilização da gestão, nas medidas de gestão de riscos do Article 21 e no reporte do Article 23. Poderá perguntar quando a organização tomou conhecimento, por que razão o incidente foi ou não significativo, como foi avaliado o impacto transfronteiriço, se os clientes foram informados e se foram tomadas medidas corretivas sem demora injustificada.

Um supervisor DORA ou uma equipa de auditoria interna perguntará se o incidente afetou funções críticas ou importantes, se os prestadores terceiros de TIC apoiaram a resposta, se a entidade financeira manteve a responsabilidade, se o registo de informação estava correto, se o incidente foi classificado corretamente e se as lições aprendidas foram reintegradas nos testes de resiliência e na supervisão de fornecedores.

Um auditor do RGPD da UE ou uma autoridade de controlo de proteção de dados perguntará se a organização tinha evidência suficiente para determinar se houve violação de dados pessoais, se os papéis de responsável pelo tratamento e subcontratante eram claros, se os titulares dos dados estavam em risco, se os controlos de Confidencialidade e Integridade eram adequados e se os registos de responsabilização foram mantidos.

Um avaliador NIST CSF 2.0 traduzirá o evento em resultados Govern, Identify, Protect, Detect, Respond e Recover. Procurará expectativas das partes interessadas, obrigações legais, apetite ao risco, governação de fornecedores, registo de logs, monitorização, execução da resposta, comunicações e validação da recuperação.

Um auditor COBIT 2019 ou ISACA focar-se-á na eficácia da governação e do sistema de gestão: propriedade, direitos de decisão, métricas, aceitação do risco, desempenho dos processos, garantia e melhoria contínua.

É aqui que o Zenith Controls é útil como bússola de conformidade cruzada. Não renomeia controlos oficiais nem cria um quadro de controlos paralelo. Mostra como controlos ISO/IEC 27002:2022, como 5.5, 5.24 e 5.28, se ligam a capacidades operacionais, controlos relacionados e evidência relevante para auditoria.

O que os Diretores de Segurança da Informação devem fazer agora para a preparação de 2026

Se está a preparar-se para a realidade operacional do Regulamento Cibersolidariedade da UE, comece pela evidência, não por slogans.

Primeiro, atualize o contexto do seu SGSI e a análise de partes interessadas. Identifique se a sua organização, clientes ou fornecedores estão abrangidos pela NIS2, DORA ou RGPD da UE. Inclua presença em Estados-Membros, classificação setorial, clientes críticos, dependências de serviços TIC e contactos com autoridades.

Segundo, realize um exercício de mesa de incidente transfronteiriço. Use um cenário que inclua um fornecedor, mais do que um Estado-Membro, possível exposição de dados pessoais e um cliente financeiro regulado. Limite temporalmente as primeiras 24 horas.

Terceiro, reveja contratos com fornecedores. Confirme deveres de notificação, acesso a logs, apoio forense, cooperação com autoridades, obrigações em cadeia para subcontratantes, localização de dados, direitos de auditoria, apoio à continuidade e direitos de cessação.

Quarto, teste a recolha de evidência. Exporte logs, preserve snapshots, rotule evidência, registe a cadeia de custódia e valide o acesso ao repositório. Se a sua política afirma que a evidência é identificada de forma única e armazenada em segurança, prove-o.

Quinto, alinhe comunicações de incidente. O seu alerta precoce NIS2, o escalonamento DORA, a avaliação de violação de dados do RGPD da UE e a comunicação ao cliente não devem contradizer-se. Podem ter finalidades legais diferentes, mas devem partir da mesma base factual.

Sexto, integre o conselho de administração no exercício. A NIS2 e a DORA elevam ambas a responsabilização da gestão. As cláusulas de liderança da ISO/IEC 27001:2022 tornam isto auditável. Um conselho de administração que nunca viu um prazo de notificação cibernética de 24 horas não está preparado para uma crise transfronteiriça.

Próximos passos com a Clarysec

O futuro da cibersegurança da UE assenta na colaboração e na confiança comprovada. Organizações que tratam a NIS2 e a DORA como listas de verificação isoladas terão dificuldades durante incidentes transfronteiriços. Organizações que constroem sistemas operacionais ISO/IEC 27001:2022 apoiados por evidência conseguirão responder a reguladores, clientes, auditores e intervenientes de crise com confiança.

A Clarysec ajuda Diretores de Segurança da Informação, gestores de conformidade, auditores e responsáveis de negócio a transformar a regulamentação cibernética da UE em evidência operacional preparada para auditoria através de:

• Zenith Blueprint: Roteiro de 30 passos de um auditor para implementação estruturada da ISO/IEC 27001:2022 e sequenciação de auditoria.
• Zenith Controls: O guia de conformidade cruzada para mapear controlos de incidentes, autoridades, fornecedores, evidência, registo de logs e continuidade entre referenciais.
• Modelos de políticas Clarysec, incluindo Política de Resposta a Incidentes, Política de Recolha de Evidência e Análise Forense, Política de Segurança de Terceiros e Fornecedores, Política de Continuidade de Negócio e Recuperação de Desastre, além de versões PME quando a proporcionalidade é relevante.

O melhor momento para preparar a coordenação de incidentes transfronteiriços é antes do alerta das 03:17. O segundo melhor momento é hoje.

Comece com uma revisão de preparação da Clarysec, descarregue o kit de políticas relevante ou solicite uma demonstração orientada sobre como o Zenith Blueprint e o Zenith Controls podem ajudar o seu SGSI a produzir a evidência que a ciber-resiliência de 2026 exigirá.