Classificação da gravidade de incidentes para DORA, NIS2 e RGPD da UE

A chamada de incidente das 02:17 que se transforma numa decisão regulamentar

Às 02:17 de uma quinta-feira de manhã, Sarah, Diretora de Segurança da Informação da FinScale, vê o primeiro alerta: tráfego anómalo de API, picos de falhas de autenticação e latência no painel de pagamentos acima de 3000 ms. Em poucos minutos, o apoio ao cliente reporta erros no estado dos pagamentos. O prestador de serviços de nuvem informa que não existe qualquer incidente generalizado na plataforma. O SOC observa tokens de acesso suspeitos provenientes de duas regiões geográficas. A equipa de produto confirma que o painel voltou a estar online após 19 minutos, mas doze clientes já abriram tickets.

Às 03:05, Sarah está na sala de crise com o gestor do incidente, a assessoria jurídica, o Coordenador de Privacidade, o responsável pelas operações de nuvem e o patrocinador executivo. A pergunta técnica é suficientemente clara: o que aconteceu ao gateway de API? As perguntas regulamentares são mais difíceis:

1. Isto é um incidente grave relacionado com TIC ao abrigo da DORA?
2. É um incidente significativo ao abrigo da NIS2?
3. Existe uma violação de dados pessoais ao abrigo do RGPD da UE que exija notificação?
4. A organização consegue demonstrar como chegou a essas respostas?

A resposta errada pode criar exposição regulamentar. A resposta lenta pode fazer perder uma janela de notificação. A resposta não documentada pode falhar numa auditoria ISO/IEC 27001:2022 meses mais tarde.

Este é o desafio da resposta a incidentes em 2026. Muitas organizações têm um Plano de Resposta a Incidentes, procedimentos forenses, playbooks de privacidade e modelos de comunicação de crise. Menos organizações têm um modelo defensável de classificação da gravidade de incidentes que converta um evento de segurança ruidoso numa decisão documentada perante a DORA, a NIS2, o RGPD da UE e as expectativas de evidência da ISO/IEC 27001:2022.

A solução não passa por três processos de triagem separados. Passa por um único modelo de gravidade governado, com camadas regulamentares separadas, limiares mensuráveis, regras de escalonamento, registos de decisão e requisitos de recolha de evidência. Em termos práticos, a gravidade de um incidente não deve ser uma etiqueta escolhida sob pressão. Deve ser uma decisão de negócio controlada, capaz de resistir ao escrutínio de reguladores, auditores, membros do conselho de administração, clientes e do EPD.

Porque a classificação da gravidade de incidentes é agora um controlo ao nível do conselho de administração

A classificação de incidentes era, em grande medida, técnica: gravidade de malware, hosts afetados, vulnerabilidades exploradas e se houve exfiltração de dados. Em 2026, é também jurídica, financeira, social e contratual.

A DORA transforma a resiliência operacional digital numa obrigação de governação para entidades financeiras. Espera-se que o órgão de gestão defina, aprove, supervisione e continue responsável pelo quadro de gestão do risco das TIC. Isto inclui continuidade de negócio das TIC, planos de resposta e recuperação, canais de notificação de incidentes graves, risco de terceiros de TIC e lições aprendidas.

A NIS2 aumenta a exigência de governação para entidades essenciais e importantes. Article 20 exige que os órgãos de gestão aprovem medidas de gestão de riscos de cibersegurança, supervisionem a sua implementação e frequentem formação. Também associa falhas na gestão de riscos e na notificação de incidentes a consequências de supervisão graves. Para entidades essenciais, os valores máximos de referência das coimas administrativas podem atingir pelo menos EUR 10,000,000 ou 2 por cento do volume de negócios anual mundial total, consoante o que for mais elevado. Para entidades importantes, o valor de referência é de pelo menos EUR 7,000,000 ou 1,4 por cento do volume de negócios, consoante o que for mais elevado.

O RGPD da UE acrescenta uma perspetiva diferente. Uma violação de dados pessoais não se limita a divulgação pública confirmada ou ficheiros roubados. Inclui destruição, perda, alteração, divulgação não autorizada ou acesso não autorizado a dados pessoais, de forma acidental ou ilícita. Os responsáveis pelo tratamento devem avaliar o risco para as pessoas singulares e demonstrar responsabilização pela decisão de notificar ou não notificar.

A ISO/IEC 27001:2022 dá a estas obrigações uma espinha dorsal de evidência. As cláusulas 4.1 a 4.4 exigem que a organização compreenda o seu contexto, os requisitos das partes interessadas, o âmbito, as interfaces e as dependências. As cláusulas 5.1 a 5.3 exigem compromisso da liderança, política, papéis, responsabilidades e reporte. As cláusulas 6.1.1 a 6.1.3 exigem planeamento baseado no risco, avaliação de riscos, tratamento de riscos e uma Declaração de Aplicabilidade. As cláusulas 8.1 a 8.3 exigem controlo operacional, controlo de alterações, evidência retida e reavaliação quando as condições de risco mudam. ISO/IEC 27001:2022

Quando ocorre a chamada de incidente, a pergunta não deve ser: “Quem acha que isto é crítico?” Deve ser: “O que é que os nossos critérios aprovados, os acionadores legais, a evidência e as regras de escalonamento nos exigem fazer agora?”

Um evento, três sistemas de classificação regulamentar

A DORA, a NIS2 e o RGPD da UE não usam a mesma linguagem para incidentes. Essa é a principal razão pela qual as organizações têm dificuldades durante a primeira hora.

DORA Article 17 exige que as entidades financeiras estabeleçam um processo de gestão de incidentes relacionados com TIC que detete, gira e notifique incidentes de TIC, registe incidentes relacionados com TIC e ameaças cibernéticas significativas, trate as causas raiz, utilize indicadores de alerta precoce, categorize e classifique incidentes, atribua papéis, gira comunicações, escale incidentes graves à alta direção e restaure operações seguras.

DORA Article 18 exige classificação com base em critérios como clientes afetados, contrapartes afetadas, transações, duração, indisponibilidade, dispersão geográfica, perda de dados que afete disponibilidade, autenticidade, integridade ou confidencialidade, criticidade dos serviços afetados e impacto económico. DORA Article 19 exige a notificação de incidentes graves relacionados com TIC e comunicação aos clientes quando os seus interesses financeiros sejam afetados.

NIS2 Article 23 define um incidente significativo como aquele que causou ou é capaz de causar uma perturbação operacional grave ou perda financeira, ou que afetou ou é capaz de afetar terceiros, causando danos materiais ou imateriais consideráveis. Exige um alerta precoce no prazo de 24 horas após a tomada de conhecimento do incidente significativo, uma notificação de incidente no prazo de 72 horas, relatórios intercalares mediante pedido e um relatório final no prazo de um mês após a notificação do incidente. Quando aplicável, os destinatários dos serviços afetados também devem ser informados sobre medidas ou soluções que possam adotar.

O RGPD da UE coloca uma pergunta de risco de privacidade. Uma violação de segurança causou destruição, perda, alteração, divulgação não autorizada ou acesso não autorizado a dados pessoais? Se sim, o responsável pelo tratamento deve avaliar o risco para os direitos e liberdades das pessoas singulares. Se a violação for suscetível de resultar num risco, a autoridade de controlo deve, em regra, ser notificada no prazo de 72 horas a contar da tomada de conhecimento. Se for suscetível de resultar num risco elevado, pode ser necessário informar as pessoas afetadas sem demora injustificada.

Por isso, um único incidente exige classificação simultânea.

Para entidades financeiras, a DORA é o ato jurídico setorial da União para obrigações de gestão do risco das TIC e notificação de incidentes que se sobrepõem à NIS2. Isto não torna a NIS2 irrelevante. Pode continuar a ser relevante para cooperação, fluxos de informação, serviços fora do perímetro DORA, entidades de grupo não financeiras, serviços de nuvem, serviços geridos e obrigações contratuais com clientes. O modelo de gravidade deve registar não apenas o resultado, mas também a lógica de aplicabilidade.

O modelo da Clarysec: classificar o evento, não a emoção

A Clarysec começa pelo controlo 5.25 da ISO/IEC 27002:2022, avaliação e decisão sobre eventos de segurança da informação, como âncora de conformidade transversal. Em Zenith Controls: The Cross-Compliance Guide Zenith Controls, este tema é mapeado através da entrada “Avaliação e decisão sobre eventos de segurança da informação” para o controlo 5.25, suportada por “Planeamento e preparação da gestão de incidentes de segurança da informação” para o controlo 5.24 e “Recolha de evidência” para o controlo 5.28.

O momento de conformidade mais importante, muitas vezes, não é a contenção. É a bifurcação em que um evento de segurança passa a ser um incidente regulamentar, ou em que é registado de forma defensável como um evento de menor gravidade.

O Zenith Blueprint: An Auditor’s 30-Step Roadmap da Clarysec Zenith Blueprint descreve este momento na fase Controls in Action, passo 23:

“Nem toda a anomalia é um desastre. Nem todo o alerta sinaliza compromisso. No mundo real, as equipas de segurança e as unidades de negócio são inundadas por ruído: tentativas de autenticação, anomalias de logs, violações menores da política, atividade de Shadow IT. O verdadeiro desafio não está apenas na deteção, mas em distinguir o inofensivo do prejudicial e saber o que exige escalonamento.”

Essa frase capta o problema operacional. Um alerta SIEM não equivale automaticamente a um incidente grave DORA. Uma indisponibilidade temporária não equivale automaticamente a um incidente significativo NIS2. Uma consulta suspeita a uma base de dados não equivale automaticamente a uma notificação obrigatória ao abrigo do RGPD da UE. Qualquer um destes casos pode tornar-se notificável em função do impacto, âmbito, dados, partes afetadas e evidência.

O Zenith Blueprint, fase Risk Management, passo 10, também recomenda que as definições de impacto sejam adaptadas à escala do negócio e à exposição regulamentar:

“Ao definir impacto, é prudente relacionar os níveis com a escala específica do seu negócio. Por exemplo, ‘Impacto financeiro maior = perda > $100k’ (ajuste ao seu contexto). Considere também o impacto regulatório: por exemplo, uma violação de dados pessoais pode ser automaticamente ‘Maior’ ou ‘Severa’ devido a coimas e requisitos de notificação do RGPD da UE, mesmo que a perda financeira direta não seja clara.”

Este é o princípio de conceção para a classificação da gravidade de incidentes em 2026: gravidade é impacto no negócio mais impacto legal mais grau de confiança da evidência.

Uma taxonomia prática de gravidade de incidentes para DORA, NIS2 e RGPD da UE

Uma taxonomia defensável deve separar a gravidade interna da classificação regulamentar. A gravidade interna determina a urgência da resposta, a afetação de recursos e o escalonamento executivo. A classificação regulamentar determina a notificação, a revisão jurídica e a comunicação externa.

O nível de gravidade interna não é a resposta regulamentar final. É o modo operacional. Um evento SEV 3 pode tornar-se notificável ao abrigo do RGPD da UE após revisão de logs. Uma indisponibilidade SEV 2 pode não ser um incidente grave DORA se os limiares de impacto não forem atingidos. Um incidente de ransomware SEV 1 pode acionar DORA, NIS2, RGPD da UE, contratos com clientes e coordenação com autoridades policiais ao mesmo tempo.

Uma matriz de classificação mais detalhada ajuda a equipa a passar do alerta à ação.

O modelo deve estar incorporado na política, e não ficar dependente da voz mais forte na sala de crise. A Política de Resposta a Incidentes para PME Incident Response Policy-sme - SME, Requisitos de governação, cláusula 5.3.1, estabelece:

“O Diretor-Geral, com contributos do prestador de suporte de TI, deve classificar todos os incidentes por gravidade no prazo de uma hora após a notificação.”

A mesma política para PME, Tratamento do risco e exceções, cláusula 7.4.1, acrescenta:

“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.”

Para organizações de maior dimensão, a Política de Resposta a Incidentes Incident Response Policy, Requisitos de governação, cláusula 5.3, formaliza o mesmo conceito:

“A classificação de incidentes deve seguir um modelo por níveis:”

A linguagem da política é relevante porque reguladores e auditores irão perguntar se os critérios de classificação existiam antes do incidente. Uma matriz inventada depois do facto é evidência fraca. Uma matriz aprovada, objeto de formação, exercitada e usada de forma consistente é defensável.

O registo de decisão: o artefacto de evidência mais importante

Quando auditores, reguladores ou membros do conselho de administração analisam um incidente, raramente perguntam apenas: “O que aconteceu?” Perguntam: “Quando souberam, quem decidiu, com base em que evidência, e porque não notificaram mais cedo?”

É por isso que a Clarysec recomenda um registo da decisão de gravidade para todos os eventos SEV 3 e superiores, e para qualquer evento que envolva dados pessoais, serviços críticos, clientes financeiros, serviços geridos, infraestrutura de nuvem ou impacto transfronteiriço.

Isto mapeia diretamente para a ISO/IEC 27001:2022. A cláusula 8.1 exige que os processos sejam planeados, implementados e controlados, com informação documentada suficiente retida para demonstrar que operaram conforme planeado. As cláusulas 8.2 e 8.3 exigem reavaliação quando ocorrem alterações significativas e retenção de evidência de tratamento de riscos. Os controlos do Anexo A A.5.24 a A.5.28 fornecem a estrutura central da gestão de incidentes: planeamento e preparação, avaliação e decisão sobre eventos, resposta, aprendizagem com incidentes e recolha de evidência.

A Política de Proteção de Dados e Privacidade para PME Data Protection and Privacy Policy-sme - SME, Aplicação e cumprimento, cláusula 8.3.2, suporta o lado RGPD da UE do modelo:

“O Coordenador de Privacidade determinará a gravidade, iniciará ações de contenção e documentará o caso”

A avaliação de privacidade não deve começar quando o relógio regulamentar já se tornou desconfortável. Deve estar integrada no fluxo de triagem.

Exemplo prático: classificar o incidente de API da Sarah

Voltemos à FinScale. É uma plataforma fintech B2B que utiliza infraestrutura de nuvem, um prestador externo de análise de fraude e um prestador de serviços de segurança geridos. É uma entidade financeira abrangida pela DORA para algumas atividades. É também um prestador de serviços digitais com operações relevantes para a NIS2 num Estado-Membro. Trata dados pessoais de clientes como responsável pelo tratamento para serviços de conta e como subcontratante para alguns clientes empresariais.

Às 02:17, é detetado tráfego anómalo de API. Às 02:35, o ticket de incidente é aberto. Às 03:00, Sarah conclui a triagem inicial com o gestor do incidente.

Primeiro, é definido o nível de gravidade interna. O incidente afetou a disponibilidade do painel de clientes durante 19 minutos, envolveu tokens de acesso suspeitos e tocou numa função crítica orientada para o cliente. É classificado como SEV 3 Moderado, pendente de confirmação, com escalonamento para o gestor do incidente, o Coordenador de Privacidade, a assessoria jurídica e o proprietário do serviço.

Segundo, é concluída a análise DORA. A equipa verifica clientes afetados, contrapartes, transações, duração, indisponibilidade, dispersão geográfica, perda de dados, criticidade e impacto económico. Não são confirmadas transações falhadas ou alteradas. A indisponibilidade é limitada. Não há perda de dados comprovada. Contudo, como um componente crítico de serviço financeiro e os interesses financeiros dos clientes podem ser afetados, o incidente permanece sob monitorização DORA e pode ser reclassificado.

Terceiro, é registada a análise NIS2. A equipa assinala que a DORA é o regime setorial primário de notificação para as obrigações da entidade financeira abrangida. Também verifica se o incidente afeta serviços ou clientes fora do perímetro DORA. Nesta fase, não é confirmada perturbação operacional grave nem dano considerável.

Quarto, é iniciada a análise RGPD da UE. Os tokens suspeitos podem ter permitido acesso a dados do painel de clientes. O Coordenador de Privacidade documenta categorias de dados, utilizadores afetados, âmbito dos tokens, logs revistos, se os dados foram visualizados ou exportados, e salvaguardas como expiração de tokens e controlos de acesso.

Às 04:20, a análise de logs mostra que dois tokens foram usados para aceder a metadados do painel de 41 clientes, incluindo nomes, IDs de conta e estado de transações, mas sem credenciais de pagamento nem documentos de identificação. A equipa atualiza o incidente para SEV 2 Maior, porque a confidencialidade de dados pessoais foi afetada e a comunicação a clientes pode ser necessária. O EPD avalia o risco RGPD da UE para as pessoas singulares. A decisão DORA é revista com base no impacto nos clientes, no impacto nas transações e no impacto económico.

Este é o valor prático do modelo. A classificação inicial não é uma conclusão jurídica final. É uma decisão baseada em evidência que pode ser atualizada à medida que os factos evoluem.

Registo, monitorização e evidência forense: a camada de prova

Um modelo de gravidade sem evidência é uma opinião de reunião. A expectativa em 2026 é que a classificação seja suportada por logs, monitorização, artefactos preservados e cadeia de custódia.

A Política de Registo e Monitorização para PME Logging and Monitoring Policy-sme - SME, Aplicação e cumprimento, cláusula 8.3.4, estabelece:

“As investigações de violações devem ser suportadas por logs adequados para cumprir o princípio da responsabilização ao abrigo do RGPD da UE e da DORA”

O tratamento forense é igualmente importante. A Política de Recolha de Evidência e Análise Forense para PME Evidence Collection and Forensics Policy-sme - SME, Requisitos de governação, cláusula 5.3.1, exige:

“Deve ser mantido um registo simples da cadeia de custódia (por exemplo, ficheiro Excel ou documento-modelo) para cada incidente.”

Para ambientes empresariais, a Política de Recolha de Evidência e Análise Forense Evidence Collection and Forensics Policy, Requisitos de governação, cláusula 5.5, exige:

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

O Zenith Blueprint, fase Controls in Action, passo 23, explica porque isto é importante para o controlo 5.28 da ISO/IEC 27002:2022:

“Quando ocorre um incidente de segurança da informação, um dos elementos mais críticos da resposta, embora frequentemente negligenciado, é a evidência. Não logs, não capturas de ecrã, não narrativas soltas, mas evidência devidamente preservada, respeitando a cadeia de custódia e resistente à adulteração.”

Um pacote prático de evidência para um incidente grave ou potencialmente notificável deve incluir:

• Ticket de incidente e cronologia
• Registo da decisão de gravidade e histórico de reclassificação
• Alertas SIEM, alertas EDR, logs de nuvem e logs de identidade
• Logs de acesso a dados e logs de exportação
• Entradas do inventário de ativos e serviços afetados
• Avaliação de impacto por cliente, transação e geografia
• Ficha de análise DORA, NIS2 e RGPD da UE
• Avaliação pelo EPD ou jurídica
• Aprovações de comunicação e mensagens enviadas
• Registo de cadeia de custódia
• Análise de causa raiz
• Ações corretivas e lições aprendidas

Este pacote de evidência também suporta os controlos do Anexo A da ISO/IEC 27001:2022 A.8.15 registo, A.8.16 atividades de monitorização, A.5.28 recolha de evidência, A.5.27 aprendizagem com incidentes de segurança da informação, A.5.31 requisitos legais, estatutários, regulamentares e contratuais, e A.5.34 privacidade e proteção de informações pessoais identificáveis.

Mapeamento de conformidade transversal: construir uma vez, responder a muitos auditores

Os modelos mais robustos de gravidade de incidentes são construídos uma vez e mapeados muitas vezes. Zenith Controls foi concebido como uma bússola de conformidade transversal para este trabalho. Para este tema, as entradas centrais da ISO/IEC 27002:2022 são 5.24 planeamento e preparação da gestão de incidentes de segurança da informação, 5.25 avaliação e decisão sobre eventos de segurança da informação, 5.26 resposta a incidentes de segurança da informação, 5.27 aprendizagem com incidentes de segurança da informação e 5.28 recolha de evidência.

Estes controlos ligam-se naturalmente ao sistema de gestão da ISO/IEC 27001:2022. As cláusulas 4, 5, 6 e 8 definem âmbito, liderança, critérios de risco, tratamento e evidência operacional. A ISO/IEC 27002:2022 fornece a linguagem de implementação de controlos. O raciocínio de continuidade de negócio ao estilo ISO 22301 suporta limiares de perturbação, prioridades de recuperação e gestão de crise. As práticas de gestão de incidentes ao estilo ISO/IEC 27035 suportam deteção, comunicação, avaliação, resposta e aprendizagem estruturadas. A governação de privacidade ao estilo ISO/IEC 27701 suporta papéis em violações de dados pessoais, considerações de responsável pelo tratamento e subcontratante, evidência de privacidade e responsabilização.

O mesmo modelo mapeia para o NIST Cybersecurity Framework 2.0. A função GOVERN exige que obrigações legais, regulamentares, contratuais, de privacidade e de liberdades civis sejam compreendidas e geridas. Também espera que apetite ao risco, papéis, autoridades, políticas e supervisão estejam definidos. As funções DETECT, RESPOND e RECOVER suportam triagem, análise, escalonamento, contenção, restauro, comunicações e melhoria.

O benefício é prático. Quando um supervisor DORA pede a fundamentação de um incidente grave relacionado com TIC, uma autoridade NIS2 pergunta sobre a decisão de alerta precoce em 24 horas, uma autoridade de controlo pergunta por que foi ou não efetuada uma notificação ao abrigo do RGPD da UE, e um auditor ISO pergunta se o SGSI funcionou conforme planeado, a organização consegue responder a partir do mesmo conjunto de evidência.

Como auditores e reguladores irão testar o seu modelo

Um auditor ISO/IEC 27001:2022 começará normalmente pelo âmbito e pelos requisitos legais. Perguntará se DORA, NIS2, RGPD da UE, contratos com clientes e obrigações de terceiros de TIC foram identificados como requisitos das partes interessadas. Depois seguirá o rasto até aos critérios de risco, à Declaração de Aplicabilidade, aos procedimentos de gestão de incidentes, aos registos operacionais e à retenção de evidência. Quer evidência de que o processo de classificação não foi inventado durante o incidente.

Um supervisor DORA ou uma equipa de auditoria interna procurará um ciclo de vida completo: processo de gestão de incidentes, indicadores de alerta precoce, critérios de classificação, escalonamento de incidentes graves, comunicação a clientes, causa raiz, valores finais de impacto, testes de resiliência e supervisão pelo órgão de gestão. Também perguntará se foram consideradas dependências de terceiros de TIC, especialmente quando estiverem envolvidos prestadores de nuvem, SaaS, serviços de segurança geridos ou fornecedores de outsourcing.

Um auditor ou autoridade focada na NIS2 testará se a entidade consegue identificar incidentes significativos, cumprir prazos faseados, comunicar com destinatários dos serviços afetados e fornecer evidência da avaliação de impacto transfronteiriço. Ligará o tratamento de incidentes às medidas de gestão de riscos do Article 21, incluindo continuidade de negócio, gestão de crise, segurança da cadeia de fornecimento, controlo de acesso, gestão de ativos e formação.

Um EPD ou autoridade de controlo do RGPD da UE analisará se a organização identificou dados pessoais, papéis, titulares dos dados, categorias, sistemas afetados, tipo de violação e risco para as pessoas singulares. Testará se o responsável pelo tratamento consegue demonstrar responsabilização e se as notificações de subcontratantes aos responsáveis pelo tratamento foram atempadas e completas.

Um auditor com perspetiva ISACA ou COBIT 2019 focar-se-á na evidência de governação. Quem aprovou a taxonomia de gravidade? Quem é o proprietário do risco? Que métricas são reportadas à gestão? Como são tratadas as exceções? Como são convertidas as lições aprendidas em melhorias de controlo?

Padrões comuns de falha na classificação de incidentes

A primeira falha é o pensamento de etiqueta única. As equipas classificam um evento como alto, médio ou baixo, mas nunca avaliam separadamente os acionadores DORA, NIS2 e RGPD da UE. O resultado é uma etiqueta de gravidade que não consegue explicar uma decisão de notificação.

A segunda falha é o enviesamento para a violação confirmada. As equipas esperam por prova absoluta de exfiltração antes de envolver privacidade ou jurídico. A avaliação de violação ao abrigo do RGPD da UE começa frequentemente com possível acesso não autorizado, perda, alteração ou divulgação, e não apenas com publicação confirmada de dados.

A terceira falha é a confusão do relógio. Os prazos NIS2 e RGPD da UE dependem da tomada de conhecimento e da avaliação. Se o ticket de incidente não captar a hora de tomada de conhecimento, a hora de classificação e a hora de escalonamento, a organização pode ter dificuldade em demonstrar tempestividade.

A quarta falha é a análise forense depois da limpeza. Engenheiros rodam chaves, reconstroem hosts e eliminam evidência temporária antes de ser acionada uma postura de investigação. Isto pode destruir a prova necessária para revisão regulamentar, contratual ou jurídica.

A quinta falha é a cegueira em relação a fornecedores. DORA, NIS2 e NIST CSF 2.0 enfatizam todos o risco de terceiros e da cadeia de fornecimento. Se um prestador de nuvem, prestador de serviços geridos, processador de pagamentos, fornecedor de identidade ou fornecedor SaaS fizer parte da cadeia do incidente, o modelo de classificação deve incluir impacto no fornecedor e obrigações contratuais de notificação.

Uma lista de verificação de implementação da Clarysec para 2026

Para operacionalizar um modelo defensável de classificação da gravidade de incidentes, a Clarysec recomenda a seguinte sequência:

1. Confirmar a aplicabilidade regulamentar em DORA, NIS2, RGPD da UE, contratos com clientes e regras setoriais.
2. Atualizar o âmbito do SGSI e os requisitos das partes interessadas ao abrigo da ISO/IEC 27001:2022.
3. Definir níveis internos de gravidade com limiares mensuráveis para indisponibilidade, dados, clientes, geografia, perda financeira e criticidade.
4. Adicionar perguntas separadas de análise DORA, NIS2 e RGPD da UE ao fluxo de trabalho do ticket de incidente.
5. Definir acionadores de escalonamento para o gestor do incidente, EPD, jurídico, alta direção e conselho de administração.
6. Criar um modelo de registo da decisão de gravidade.
7. Ligar a classificação à recolha de evidência e aos procedimentos de cadeia de custódia.
8. Validar a cobertura de logs para eventos de identidade, nuvem, aplicação, base de dados, rede e fornecedores.
9. Executar exercícios de simulação de mesa para cenários de incidente grave DORA, incidente significativo NIS2 e violação de dados RGPD da UE.
10. Incorporar as lições aprendidas no tratamento de riscos, na Declaração de Aplicabilidade, na formação e nos testes de resiliência.

O Zenith Blueprint, fase Controls in Action, passo 16, reforça o lado humano deste modelo: as comunicações devem ser registadas, triadas, escaladas através do Plano de Resposta a Incidentes, e mesmo eventos menores devem ser acompanhados porque as tendências revelam fraquezas de controlo. Promove uma mentalidade de comunicação com baixo limiar: “Em caso de dúvida, comunique.”

Este ponto cultural é crítico. Um modelo de gravidade falha se os colaboradores atrasarem a comunicação por receio de reação excessiva. O objetivo é comunicação rápida, triagem disciplinada e classificação defensável.

Transformar incerteza de incidentes em evidência pronta para auditoria

Em 2026, a classificação da gravidade de incidentes já não é uma decisão exclusiva do SOC. É um processo regulado de governação que deve ligar critérios de incidentes graves relacionados com TIC da DORA, limiares de incidentes significativos da NIS2, risco de violação de dados do RGPD da UE e evidência ISO/IEC 27001:2022.

As organizações que têm melhor desempenho durante incidentes não serão as que têm o dossier de resposta mais volumoso. Serão as que conseguem responder rapidamente a quatro perguntas e demonstrar cada resposta mais tarde:

• O que aconteceu?
• Qual é a gravidade?
• Que obrigações regulamentares podem aplicar-se?
• Que evidência suporta a decisão?

A Clarysec ajuda as organizações a construir essa ponte através de modelos de políticas, taxonomias de gravidade, registos de decisão, cenários de simulação de mesa e mapeamentos de conformidade transversal. Comece pelas políticas de incidentes, valide os seus critérios de risco no Zenith Blueprint Zenith Blueprint e utilize Zenith Controls Zenith Controls para mapear os controlos ISO/IEC 27002:2022 5.24, 5.25, 5.26, 5.27 e 5.28 perante DORA, NIS2, RGPD da UE, NIST CSF e expectativas de auditoria.

Se a sua equipa não consegue responder “Isto é DORA grave, NIS2 significativo ou notificável ao abrigo do RGPD da UE?” na primeira hora, o próximo passo não é outro Plano de Resposta a Incidentes genérico. O próximo passo é um modelo operacional defensável de classificação da gravidade de incidentes, testado antes de chegar a próxima chamada das 02:17.

Pronto para substituir pânico por processo? Descarregue os modelos de políticas de resposta a incidentes e recolha de evidência da Clarysec, reveja a sua taxonomia atual de gravidade face ao Zenith Blueprint ou solicite uma avaliação de preparação da Clarysec para construir um modelo de classificação de incidentes DORA, NIS2, RGPD da UE e ISO/IEC 27001 pronto para auditoria.