Comunicação de incidentes DORA e controlos ISO 27001 em 2026

São 08:17 de uma terça-feira de manhã em 2026. Sarah, CISO de uma fintech europeia, vê um painel de gestão a piscar a âmbar, não a vermelho. Uma plataforma crítica de liquidação de pagamentos está com degradação de desempenho. As transações não estão a falhar totalmente, mas demoram três vezes mais do que o permitido pelo acordo de nível de serviço. O SOC observa tentativas de autenticação invulgares contra uma conta de administrador. O prestador de infraestrutura em nuvem comunica degradação do serviço numa zona de disponibilidade. O apoio ao cliente começa a receber chamadas de clientes empresariais a perguntar por que motivo os ficheiros de pagamento estão atrasados.

Ainda ninguém sabe se se trata de um ciberataque, de uma falha de resiliência operacional, de uma indisponibilidade de fornecedor, de um incidente de privacidade ou de tudo isto ao mesmo tempo.

Sarah tem um problema DORA antes de os factos técnicos estarem completos. Trata-se de um incidente grave relacionado com as TIC? Afeta uma função crítica ou importante? Ultrapassou o limiar interno de severidade? Quem tem de ser notificado, quando e com que evidência? Se estiverem envolvidos dados pessoais, o prazo de notificação do GDPR também começou a contar? Se um prestador terceiro de serviços de TIC fizer parte da cadeia do incidente, quem é responsável pelos factos?

É aqui que as entidades financeiras descobrem a diferença entre ter um plano de resposta a incidentes e ter um modelo operacional auditável de comunicação de incidentes DORA.

A comunicação de incidentes DORA em 2026 exige mais do que escalonamento rápido. Exige uma cadeia defensável da deteção à classificação, da classificação à comunicação à autoridade de supervisão, da comunicação à remediação e da remediação às lições aprendidas. A ISO/IEC 27001:2022 fornece a estrutura do sistema de gestão. Os controlos do Anexo A da ISO/IEC 27002:2022 estabelecem as expectativas práticas de controlo. As políticas da Clarysec, o roteiro de 30 etapas e o guia de conformidade transversal transformam essas expectativas numa implementação preparada para evidência.

Porque falha a comunicação de incidentes DORA sob pressão

A maioria das falhas na comunicação de incidentes DORA não começa por negligência. Começa por ambiguidade.

Um analista de segurança vê um alerta, mas não sabe se este se qualifica como incidente relacionado com as TIC ao abrigo do DORA. O gestor de serviços de TI trata a degradação de desempenho como um problema técnico de serviço, enquanto a conformidade a trata como um evento regulamentar. O jurídico aguarda confirmação antes de escalar. O proprietário do processo de negócio ainda não consegue quantificar o impacto nos clientes. O CISO quer evidência, mas os logs relevantes estão dispersos por serviços em nuvem, endpoints, sistemas de identidade, SIEM e plataformas de fornecedores.

Quando a organização chega a acordo sobre a classificação, a janela de comunicação já está sob pressão.

Os artigos 17 a 21 do DORA criam uma expectativa estruturada para a gestão, classificação, comunicação, conteúdo da comunicação e tratamento pela supervisão de incidentes relacionados com as TIC. Para as entidades financeiras, o requisito prático é claro: monitorizar, gerir, registar eventos, classificar, comunicar, atualizar e aprender com incidentes relacionados com as TIC de forma que possa ser reconstruída posteriormente.

A Política de Resposta a Incidentes [IRP] da Clarysec incorpora o DORA diretamente no quadro de referência:

DORA da UE (2022/2554): artigo 17: requisitos de comunicação de incidentes de TIC por instituições financeiras às autoridades competentes.

A mesma política liga a gestão de incidentes aos controlos 5.25 a 5.27 da ISO/IEC 27002:2022, abrangendo responsabilidades de avaliação, resposta, comunicação e melhoria de incidentes.

Para empresas de tecnologia financeira de menor dimensão e entidades reguladas com estruturas mais enxutas, a Política de Resposta a Incidentes - PME [IRP-SME] da Clarysec torna a obrigação prática ao salientar que o DORA exige que as entidades financeiras classifiquem, comuniquem e acompanhem incidentes e perturbações relacionados com as TIC.

Essa formulação é importante. A conformidade com o DORA não é apenas um modelo de comunicação. A organização deve classificar, comunicar e acompanhar. Isso implica evidência do evento inicial, critérios de decisão, nível de severidade, decisão de comunicação, comunicações, ações de recuperação, envolvimento de fornecedores e seguimento.

ISO/IEC 27001:2022 como centro de comando de incidentes DORA

Um Sistema de Gestão de Segurança da Informação ISO/IEC 27001:2022 maduro não deve tornar-se mais um silo de conformidade ao lado do DORA. Deve tornar-se o centro de comando da comunicação de incidentes DORA.

O SGSI já exige propriedade do risco, seleção de controlos, auditoria interna, revisão pela gestão, informação documentada, melhoria contínua e evidência da operação dos controlos. O DORA acrescenta pressão de comunicação específica do setor, mas a ISO/IEC 27001:2022 fornece a estrutura de governação para tornar o processo repetível.

O Zenith Blueprint: roteiro de 30 etapas para auditores [ZB] da Clarysec reforça esta integração na etapa 13, Planeamento do Tratamento de Riscos e Declaração de Aplicabilidade. O Blueprint recomenda mapear controlos para riscos e cláusulas para garantir rastreabilidade, incluindo a adição de uma referência de controlo do Anexo A aos riscos e a indicação de quando os controlos suportam GDPR, NIS2 ou DORA.

Para o incidente de liquidação de pagamentos de Sarah, a entrada no Registo de Riscos poderia ser:

“Interrupção ou comprometimento da plataforma de processamento de pagamentos.”

Os controlos mapeados do Anexo A da ISO/IEC 27001:2022 incluiriam 5.24, 5.25, 5.26, 5.27, 5.28, 6.8, 8.15 e 8.16, com uma nota DORA relativa à classificação e comunicação de incidentes graves relacionados com as TIC.

O Zenith Controls: guia de conformidade transversal [ZC] da Clarysec funciona então como a bússola de conformidade transversal. No Zenith Controls, a Clarysec mapeia os controlos ISO/IEC 27002:2022 para outros controlos ISO/IEC 27001:2022, normas relacionadas, expectativas de auditoria e regulamentos como DORA, GDPR e NIS2. Não cria “controlos Zenith” separados. Mostra como os controlos ISO existentes funcionam em conjunto e como são testados.

O fluxo de comunicação DORA pode ser visto como uma cadeia de controlos:

Não se pode comunicar o que não se detetou. Não se pode classificar o que não se avaliou. Não se pode justificar uma decisão de comunicação sem registos. Não se pode melhorar sem uma revisão pós-incidente.

Controlo 6.8: o relógio DORA começa nas pessoas

No cenário de Sarah, o primeiro sinal útil pode não vir do SOC. Pode vir de um gestor de relacionamento que ouve reclamações de clientes, de um utilizador da área financeira que observa lotes de liquidação falhados ou de um engenheiro que nota latência anómala.

É por isso que o controlo 6.8 do Anexo A da ISO/IEC 27001:2022, comunicação de eventos de segurança da informação, é essencial para o DORA. Torna a comunicação uma responsabilidade da força de trabalho, e não apenas uma função das operações de segurança.

No Zenith Blueprint, etapa 16, Controlos de Pessoas II, a Clarysec afirma:

Um sistema eficaz de resposta a incidentes não começa com ferramentas, mas com pessoas.

A etapa 16 recomenda canais de comunicação claros, formação de sensibilização, uma cultura sem culpabilização, triagem, confidencialidade e simulações periódicas. A mensagem prática mais útil é simples:

“Em caso de dúvida, comunique.”

Este é um princípio de controlo DORA. Se os trabalhadores esperarem até terem certeza, a organização perde tempo. Se comunicarem cedo, a organização pode avaliar, classificar e decidir.

No Zenith Controls, o 6.8 é mapeado como controlo de deteção que suporta a confidencialidade, a integridade e a disponibilidade. Liga-se ao 5.24 porque os canais de comunicação devem fazer parte do plano de incidentes. Alimenta o 5.25 porque os eventos só podem ser avaliados se forem comunicados. Aciona o 5.26 porque a resposta formal começa depois de as comunicações serem avaliadas.

Para o DORA, isto suporta os artigos 17 e 18, nos quais as entidades financeiras devem gerir, classificar e comunicar incidentes graves relacionados com as TIC e ameaças cibernéticas significativas. Também suporta o artigo 33 e o considerando 85 do GDPR, porque a comunicação interna determina a rapidez com que uma violação de dados pessoais é identificada e escalada.

Uma implementação prática da Clarysec é uma folha de instruções de uma página intitulada “Como comunicar um incidente de TIC”. Deve incluir:

• O que comunicar, incluindo indisponibilidades, mensagens de correio eletrónico suspeitas, dispositivos perdidos, comportamento invulgar de sistemas, suspeita de comprometimento de fornecedor, acesso não autorizado, fuga de dados e degradação de serviço com impacto em clientes.
• Como comunicar, utilizando uma caixa de correio monitorizada, categoria de ticket, linha direta, canal de colaboração ou portal SOC.
• O que incluir, como hora, sistema, utilizador, processo de negócio, impacto observado, capturas de ecrã se for seguro, e se clientes ou dados pessoais podem estar afetados.
• O que não fazer, incluindo não apagar logs, não reiniciar sistemas críticos salvo instrução em contrário, não contactar clientes externamente sem aprovação e não investigar para além da respetiva função.
• O que acontece a seguir, incluindo triagem, classificação, escalonamento, resposta, preservação de evidência e possível avaliação regulamentar.

O objetivo não é transformar todos os trabalhadores em investigadores. É fazer de cada trabalhador uma fonte de sinal fiável.

Controlo 5.25: o ponto de decisão da classificação DORA

A comunicação de incidentes graves relacionados com as TIC ao abrigo do DORA assenta na classificação. É aqui que o controlo 5.25 do Anexo A da ISO/IEC 27001:2022, avaliação e decisão sobre eventos de segurança da informação, se torna central.

O Zenith Blueprint, etapa 23, explica o desafio prático:

Nem todas as anomalias são um desastre. Nem todos os alertas sinalizam comprometimento.

Depois descreve a finalidade do 5.25 como:

distinguir o inofensivo do nocivo e saber o que exige escalonamento.

Para o DORA, este é o momento em que um evento de segurança, degradação de serviço, indisponibilidade de fornecedor, exposição de dados ou perturbação operacional é avaliado face aos critérios de incidente grave. A organização deve considerar o impacto operacional, os serviços afetados, as funções críticas ou importantes, os clientes e transações afetados, a duração, a dispersão geográfica, o impacto nos dados, as implicações reputacionais e o impacto económico.

No Zenith Controls, o 5.25 é mapeado diretamente para o artigo 18 do DORA, Classificação de Incidentes Graves de TIC. É o processo estruturado de avaliação para determinar se um evento observado se qualifica como incidente de segurança. Também se liga ao 8.16, Atividades de monitorização, porque os alertas e os dados de logs devem ser triados, e ao 5.26, porque a classificação aciona a resposta.

É aqui que muitas organizações falham auditorias. Têm tickets, mas não registos de classificação. Têm etiquetas de severidade, mas não critérios. Têm comunicações regulamentares, mas não o rasto de decisão que demonstre por que motivo um incidente foi ou não considerado grave.

A Clarysec responde a isto incorporando a classificação DORA no modelo de severidade de incidentes. Na Política de Resposta a Incidentes empresarial, a cláusula 5.3.1 inclui um exemplo claro de Nível 1:

Nível 1: Crítico (por exemplo, violação de dados confirmada, surto de ransomware, comprometimento de sistema de produção)

Para organizações de menor dimensão, a Política de Resposta a Incidentes - PME acrescenta uma expectativa operacional rigorosa:

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

Este objetivo de classificação no prazo de uma hora é poderoso porque impõe disciplina de governação. Uma entidade regulada mais pequena pode não ter um SOC 24/7, mas ainda assim pode definir quem classifica, quem presta aconselhamento e com que rapidez a decisão deve ocorrer.

Um registo de triagem de incidentes DORA-ISO

Para tornar a classificação defensável, crie um registo de triagem de incidentes DORA no seu sistema de tickets, GRC ou gestão de incidentes. O registo deve ser criado para cada evento de TIC potencialmente material, mesmo que seja posteriormente rebaixado.

Acrescente uma nota de decisão:

“Com base na perturbação do serviço de pagamentos que afeta um processo de negócio crítico, na causa raiz ainda não resolvida e no potencial impacto em clientes, o evento é escalado como potencial incidente grave relacionado com as TIC. A conformidade e o jurídico devem avaliar os requisitos de notificação regulamentar. Preservação de evidência iniciada.”

Este único registo suporta o acompanhamento do artigo 17 do DORA, a classificação do artigo 18, as decisões de comunicação do artigo 19, a avaliação do Anexo A 5.25 da ISO/IEC 27001:2022, a comunicação 6.8, a resposta 5.26 e o tratamento de evidência 5.28.

Controlos 5.24 e 5.26: planeamento, papéis e resposta

Quando ocorre um incidente DORA, o plano de resposta já deve responder a perguntas difíceis.

Quem tem autoridade para classificar? Quem contacta a autoridade competente? Quem aprova a notificação inicial? Quem comunica com os clientes? Quem contacta o prestador terceiro de serviços de TIC? Quem decide se o incidente também aciona uma notificação GDPR? Quem preserva a evidência? Quem é responsável pelo relatório final?

O controlo 5.24 do Anexo A da ISO/IEC 27001:2022, planeamento e preparação da gestão de incidentes de segurança da informação, responde a essas perguntas antes da crise. O controlo 5.26, resposta a incidentes de segurança da informação, assegura que o plano se transforma em ação controlada durante o incidente.

No Zenith Controls, o 5.24 está ligado aos artigos 17 a 21 do DORA porque operacionaliza uma resposta a incidentes documentada, testada e revista, incluindo escalonamento interno, notificação regulamentar externa, comunicação com partes interessadas e lições aprendidas.

A ISO/IEC 27035-1:2023 suporta isto ao alargar a gestão de incidentes para além dos procedimentos de resposta, abrangendo política, planeamento, capacidades, relações, mecanismos de suporte, sensibilização, formação e testes regulares. A ISO/IEC 27035-2:2023 detalha ainda o processo de gestão de incidentes desde a preparação até às lições aprendidas.

O Zenith Blueprint, etapa 23, fornece uma instrução direta de implementação:

Assegure que dispõe de um plano de resposta a incidentes atualizado (5.24), abrangendo preparação, escalonamento, resposta e comunicação.

Um plano de resposta a incidentes preparado para DORA deve definir:

• A equipa de resposta a incidentes de TIC e os substitutos.
• Autoridade para classificação de severidade e escalonamento da comunicação DORA.
• Responsabilidades do jurídico, conformidade, privacidade, comunicações, TI, segurança, fornecedor e proprietário do processo de negócio.
• Critérios para classificação de incidente grave relacionado com as TIC.
• Procedimentos para comunicação regulamentar inicial, intermédia e final.
• Avaliação de notificações GDPR, NIS2, contratuais, de seguro cibernético e ao conselho de administração.
• Etapas de contenção, erradicação, recuperação e validação.
• Requisitos de preservação de evidência.
• Procedimentos de escalonamento de fornecedores e de acesso a logs.
• Acompanhamento de lições aprendidas e ações corretivas.

A Política de Resposta a Incidentes - PME também liga os prazos de resposta aos requisitos legais:

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 GDPR de notificação de violação de dados pessoais no prazo de 72 horas.

Isto é vital porque um único incidente de TIC pode tornar-se um incidente grave DORA, uma violação de dados pessoais GDPR, um incidente significativo NIS2, um evento de notificação contratual a clientes e uma questão de gestão de fornecedores. O plano deve coordenar estas sobreposições em vez de as tratar como mundos separados.

Controlos 8.15 e 8.16: os logs tornam a comunicação defensável

A comunicação de incidentes DORA depende de factos. Os factos dependem de registo de eventos e monitorização.

No cenário de liquidação de pagamentos, Sarah precisa de saber quando começou a degradação, que sistemas foram afetados, se foram utilizadas contas privilegiadas, se os dados saíram do ambiente, se a indisponibilidade do prestador de serviços em nuvem coincide com a telemetria interna e quando a recuperação ficou concluída.

O controlo 8.15 do Anexo A da ISO/IEC 27001:2022, Registo de eventos, e o 8.16, Atividades de monitorização, suportam esta base de evidência. No Zenith Controls, ambos se ligam ao 5.24 porque o planeamento da resposta a incidentes deve incluir dados de logs utilizáveis e capacidade de monitorização. O controlo 8.16 também se liga ao 5.25 porque os alertas devem ser triados e convertidos em decisões.

A Política de Registo de Eventos e Monitorização - PME [LMP-SME] da Clarysec inclui um requisito prático de escalonamento:

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

Para entidades reguladas pelo DORA, incidentes de TIC potencialmente graves exigem normalmente um modelo de escalonamento operacional mais rápido, especialmente quando funções críticas ou importantes são afetadas. Ainda assim, o padrão de governação está correto: alertas de alta prioridade não podem permanecer dentro da TI. Devem chegar aos papéis de negócio, privacidade e gestão.

Um modelo de registo de eventos preparado para DORA deve incluir:

• Registo centralizado para sistemas críticos, plataformas de identidade, endpoints, serviços em nuvem, ferramentas de segurança de rede e aplicações empresariais.
• Sincronização temporal entre sistemas para que as cronologias de incidentes sejam fiáveis.
• Categorização de alertas alinhada com a severidade de incidentes e a classificação DORA.
• Retenção de logs alinhada com necessidades regulamentares, contratuais e forenses.
• Controlos de acesso que protejam a integridade dos logs.
• Procedimentos para capturar snapshots de logs durante incidentes graves.
• Requisitos de acesso a logs de fornecedores para serviços críticos de TIC.

Os auditores não aceitarão “está no SIEM” como evidência suficiente. Perguntarão se existiam os logs corretos, se os alertas foram revistos, se o escalonamento ocorreu dentro do prazo e se os logs foram preservados quando o incidente se tornou potencialmente comunicável.

Controlo 5.28: recolha de evidência e cadeia de custódia

Num incidente grave relacionado com as TIC, a evidência serve três finalidades: investigação técnica, responsabilização regulamentar e defensabilidade jurídica.

Se a evidência estiver incompleta, sobrescrita, alterada ou não documentada, a organização pode ter dificuldade em provar o que aconteceu. Pode também ter dificuldade em justificar a sua decisão de classificação.

A Política de Recolha de Evidência e Análise Forense [ECF] da Clarysec estabelece:

Um registo de cadeia de custódia deve acompanhar toda a evidência física ou digital desde o momento da aquisição até ao arquivo ou transferência e deve documentar:

A versão PME, Política de Recolha de Evidência e Análise Forense - PME [ECF-SME], mantém o requisito simples:

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

A lição operacional é direta. O tratamento de evidência não pode começar apenas quando o jurídico a solicita. Deve estar incorporado na resposta a incidentes.

A ISO/IEC 27006-1:2024 reforça esta expectativa de auditoria ao salientar procedimentos para identificar, recolher e preservar evidência de incidentes de segurança da informação. Para o DORA, o mesmo conjunto de evidências pode suportar a notificação inicial, atualizações intermédias, relatório final, revisão pós-incidente e perguntas da supervisão.

Uma lista de verificação prática de evidência para incidentes relacionados com o DORA deve incluir:

• Ticket de incidente e notas de triagem.
• Cronologia da deteção, escalonamento, classificação, comunicação, contenção, recuperação e encerramento.
• Alertas SIEM e logs correlacionados.
• Artefactos de endpoints e servidores.
• Logs de identidade e de acessos privilegiados.
• Resumos de tráfego de rede.
• Estado do prestador de serviços em nuvem e logs de auditoria.
• Comunicações de fornecedores e declarações sobre incidentes.
• Registos de impacto no negócio, incluindo clientes, serviços, transações e indisponibilidade.
• Rascunhos e submissões de notificações regulamentares.
• Decisões e aprovações da gestão.
• Análise de causa raiz.
• Lições aprendidas e ações corretivas.

A evidência deve demonstrar tanto os factos técnicos como as decisões de governação. A comunicação DORA não se limita ao que aconteceu aos sistemas. Diz também respeito à forma como a gestão reconheceu, avaliou, escalou, controlou e melhorou a partir do incidente.

Controlo 5.27: lições aprendidas e melhoria contínua

Um incidente DORA não fica encerrado quando o relatório final é submetido. Fica encerrado quando a organização aprendeu com ele, atribuiu ações corretivas, atualizou controlos e verificou a melhoria.

O controlo 5.27 do Anexo A da ISO/IEC 27001:2022, aprendizagem com incidentes de segurança da informação, liga a comunicação DORA ao ciclo de melhoria contínua da ISO/IEC 27001:2022. No Zenith Controls, o 5.24 está ligado ao 5.27 porque a gestão de incidentes fica incompleta sem análise de causa raiz, lições aprendidas e melhoria dos controlos.

O Zenith Blueprint, etapa 23, instrui as organizações a atualizar o plano com lições aprendidas e a disponibilizar formação direcionada sobre resposta a incidentes e tratamento de evidência. Isto é especialmente importante para o DORA, porque atrasos recorrentes na classificação, evidência de fornecedores em falta, logs insuficientes ou comunicações pouco claras podem tornar-se preocupações de supervisão.

Um modelo de lições aprendidas deve captar:

• O que aconteceu e quando.
• Que funções críticas ou importantes foram afetadas.
• Se a classificação foi tempestiva e precisa.
• Se as decisões de comunicação DORA foram tomadas com evidência suficiente.
• Se foram avaliados acionadores de notificação GDPR, NIS2, contratuais ou a clientes.
• Se os fornecedores responderam dentro dos prazos acordados.
• Se os logs e a evidência forense foram preservados.
• Que controlos falharam ou estavam em falta.
• Que políticas, playbooks, formação ou controlos técnicos devem ser melhorados.
• Quem é responsável por cada ação corretiva e até quando.

Isto também alimenta a revisão pela gestão da ISO/IEC 27001:2022. As tendências de incidentes devem ser revistas pela liderança, e não ficar enterradas em análises pós-incidente técnicas.

Conformidade transversal: DORA, GDPR, NIS2, NIST e COBIT 2019

O DORA é o tema central para as entidades financeiras, mas a comunicação de incidentes raramente pertence a um único referencial.

Um único incidente de TIC pode envolver comunicação de incidente grave relacionado com as TIC ao abrigo do DORA, notificação de violação de dados pessoais GDPR, comunicação de incidente significativo NIS2, obrigações contratuais com clientes, notificação de seguro cibernético e comunicação ao conselho de administração.

O Zenith Controls ajuda a reduzir esta complexidade ao mapear controlos ISO/IEC 27002:2022 entre referenciais. Por exemplo:

Da perspetiva do NIST, o mesmo modelo suporta resultados de Detect, Respond e Recover. Da perspetiva de auditoria COBIT 2019 e ISACA, a preocupação é a governação: se a gestão de incidentes, continuidade, risco, conformidade, responsabilidades de fornecedores e monitorização de desempenho estão controladas.

As organizações mais maduras não criam fluxos de trabalho separados para cada referencial. Criam um único processo de gestão de incidentes com camadas regulamentares. O ticket capta uma única vez os mesmos factos essenciais e depois ramifica para comunicação DORA, GDPR, NIS2, contratual, de seguro ou específica do setor quando necessário.

Como os auditores irão testar o seu processo de incidentes DORA

Um processo de comunicação de incidentes preparado para DORA deve resistir a diferentes perspetivas de auditoria.

Um auditor ISO/IEC 27001:2022 examinará se o SGSI selecionou e implementou os controlos relevantes do Anexo A, se a Declaração de Aplicabilidade suporta esses controlos, se existem registos de incidentes e se a auditoria interna e a revisão pela gestão incluem o desempenho de incidentes.

O Zenith Controls cita a metodologia de auditoria ISO/IEC 19011:2018 para 5.24, 5.25 e 6.8. Para o 5.24, os auditores examinam o plano de resposta a incidentes quanto a tipos de incidentes, classificações de severidade, papéis atribuídos, listas de contactos, vias de escalonamento, instruções de comunicação regulamentar e responsabilidades de comunicação. Para o 5.25, examinam se existem critérios de classificação documentados, como matrizes de severidade ou árvores de decisão baseadas no impacto nos sistemas, sensibilidade dos dados e duração. Para o 6.8, avaliam mecanismos de comunicação, métricas de tempo até à comunicação e evidência de que os eventos comunicados são registados em logs, triados e resolvidos.

Uma revisão de supervisão DORA focar-se-á em saber se os incidentes graves relacionados com as TIC são detetados, classificados, comunicados, atualizados e encerrados de acordo com as expectativas regulamentares. O revisor pode solicitar um incidente de amostra e rastreá-lo desde o primeiro alerta até ao relatório final.

Um auditor de privacidade focar-se-á em saber se o risco de violação de dados pessoais foi avaliado e se foram acionadas as obrigações dos artigos 33 e 34 do GDPR. A BS EN 17926:2023 é relevante neste ponto porque acrescenta responsabilidades de incidentes de privacidade, critérios de notificação, prazos e alinhamento com expectativas de divulgação à supervisão.

A mesma evidência pode satisfazer várias perguntas de auditoria se estiver estruturada corretamente desde o início.

Lista de verificação de preparação para comunicação de incidentes DORA em 2026

Antes do próximo exercício de mesa, auditoria interna ou revisão de supervisão, teste a sua organização face a esta lista de verificação:

• Os trabalhadores sabem como comunicar incidentes de TIC suspeitos?
• Existe um canal dedicado de comunicação de incidentes?
• Os eventos de segurança são registados em logs e triados de forma consistente?
• Existe uma matriz documentada de severidade e classificação de incidente grave DORA?
• A classificação é exigida dentro de um prazo definido após a notificação?
• As funções críticas ou importantes estão mapeadas para sistemas e fornecedores?
• Os acionadores de notificação DORA, GDPR, NIS2, contratuais, de seguro e a clientes são avaliados num único fluxo de trabalho?
• Os papéis de incidentes estão definidos entre TI, segurança, jurídico, conformidade, privacidade, comunicações e proprietários do negócio?
• Os logs são suficientes para reconstruir cronologias de incidentes?
• A evidência é preservada com cadeia de custódia?
• As obrigações de incidentes dos fornecedores e os direitos de acesso a logs são testados?
• São realizados exercícios de mesa com cenários DORA realistas?
• As lições aprendidas são acompanhadas até às ações corretivas?
• As métricas de incidentes são revistas na revisão pela gestão?
• A Declaração de Aplicabilidade está mapeada para controlos ISO/IEC 27001:2022 relevantes para o DORA?

Se a resposta a qualquer destes pontos for “parcialmente”, a questão não é apenas conformidade. É resiliência operacional.

Construa um modelo de comunicação de incidentes DORA preparado para evidência

A comunicação de incidentes DORA em 2026 é um teste à governação sob pressão. As organizações com melhor desempenho não serão as que têm os documentos de resposta a incidentes mais extensos. Serão as que têm canais de comunicação claros, classificação rápida, logs fiáveis, evidência preservada, pessoas formadas, escalonamento de fornecedores testado e rastreabilidade entre referenciais.

A Clarysec pode ajudá-lo a construir esse modelo operacional.

Comece por mapear os seus riscos de incidentes e a Declaração de Aplicabilidade com o Zenith Blueprint: roteiro de 30 etapas para auditores. Depois alinhe os seus controlos de incidentes com o Zenith Controls: guia de conformidade transversal. Operacionalize o processo com a Política de Resposta a Incidentes, a Política de Resposta a Incidentes - PME, a Política de Registo de Eventos e Monitorização - PME, a Política de Recolha de Evidência e Análise Forense e a Política de Recolha de Evidência e Análise Forense - PME da Clarysec.

Se a sua equipa de liderança quiser ganhar confiança antes do próximo incidente real, realize um exercício de mesa de incidente grave relacionado com as TIC ao abrigo do DORA com o kit de ferramentas da Clarysec e produza o pacote de evidência que um auditor ou supervisor esperaria ver.