Bancos, seguradoras, gestores de ativos e prestadores de serviços de criptoativos que operam na União Europeia ganharam um mapa inédito de onde o relato regulatório de incidentes de tecnologia costuma falhar. Em 16 de setembro de 2026, as três Autoridades Europeias de Supervisão — EBA, EIOPA e ESMA — publicaram instruções operacionais para padronizar o relato de incidentes graves de TI exigido pelo DORA, o regulamento europeu de resiliência operacional digital do setor financeiro. O documento não cria obrigações novas, mas expõe os erros que as autoridades competentes já identificaram desde o início da vigência do regime e que passam a ser cobrados com mais consistência. A prioridade para equipes de segurança e compliance é revisar o processo interno de classificação, versionamento e envio antes do próximo incidente relevante.
O que as novas instruções mudam
O DORA, Regulamento (UE) 2022/2554, transformou o relato de incidentes graves de TIC em um ciclo contínuo, composto por notificação inicial, relatórios intermédios e relatório final, com prazos e modelos padronizados definidos em normas técnicas delegadas. O que faltava era orientação prática sobre como preencher esses modelos sem gerar retrabalho. As instruções operacionais foram acordadas com as autoridades competentes nacionais, serão atualizadas conforme a experiência de supervisão acumula e funcionam em regime de melhor esforço, sem valor de interpretação jurídica formal. Para o time defensivo, o sinal é direto: o foco do supervisor deixou de ser apenas o cumprimento de prazo e passou a incluir a consistência e a qualidade dos dados enviados.
Um dos pontos mais práticos do documento trata de correções. Quando um relatório já enviado contém erro, a orientação não é corrigir apenas o campo isolado: a entidade deve enviar uma nova versão do relatório mais recente, contendo a correção e todas as demais informações vigentes sobre o incidente. Sem esse versionamento, os sistemas das autoridades podem registrar entradas desconectadas e perder o rastro do caso. O mesmo raciocínio vale para a relação com provedores terceirizados de TIC, cujos dados de identificação — como código LEI ou EUID — precisam estar disponíveis desde a primeira notificação, e não descobertos no meio da crise.
Prazos que definem o relato
Os prazos do relato de incidentes DORA permanecem os mesmos das normas técnicas, mas as instruções mostram onde as entidades se atrapalham ao aplicá-los. A notificação inicial precisa chegar à autoridade competente no máximo 24 horas após a entidade tomar conhecimento do incidente, e dentro de 4 horas da classificação como incidente grave. O primeiro relatório intermédio segue em até 72 horas da notificação inicial, mesmo que nada tenha mudado, e o relatório final deve ser entregue em até um mês após o último intermédio. Fins de semana e feriados aliviam o prazo para entidades menores, mas bancos, contrapartes centrais, operadores de mercados e entidades consideradas essenciais ou importantes sob a NIS2 não têm essa flexibilidade.
| Etapa | Prazo | Ponto de atenção |
|---|---|---|
| Notificação inicial | 4 horas da classificação; 24 horas da detecção | Campos de identificação definidos aqui valem até o final |
| Relatório intermédio | 72 horas da notificação inicial | Obrigatório mesmo sem mudança de status |
| Intermédios seguintes | Pelo menos um por mês | Mantém o ciclo vivo durante forense e apuração de perdas |
| Relatório final | Um mês após o último intermédio | Causa raiz, custos diretos e indiretos e recuperações |
Quem já estruturou um plano de resposta a incidentes alinhado a NIST e ANPD encontra aqui um teste útil: o plano precisa produzir, em plena crise, os campos exigidos pelos modelos do DORA, incluindo duração, indisponibilidade de serviço e indicadores de comprometimento. Se o runbook não gera esses dados, o relato vira reconstrução artesanal sob pressão de relógio.
Erros que criam incidentes duplicados
O erro mais comum detectado pelos supervisores envolve identificação. Os campos 1.3a, 1.3b e 2.1 do formulário, usados para identificar de forma única o incidente e a entidade notificante, não podem mudar entre notificação inicial e relatório final. Alterar qualquer um deles no meio do ciclo pode fazer o mesmo incidente ser contado duas vezes nas estatísticas de supervisão — um problema silencioso, que não gera multa imediata, mas corrói a confiança nos dados e atrai perguntas em fiscalizações posteriores. A regra prática é congelar a identificação na primeira submissão e tratá-la como chave imutável do caso.
Outra armadilha é a estimativa de duração. O relatório deve indicar se os valores de duração e de indisponibilidade são valores reais ou estimativas, e essa distinção precisa acompanhar o incidente nos relatórios intermédios e no final. Durante a resposta, números provisórios são normais; o que estraga o relato é apresentar estimativa como se fosse medição final. Equipes de SOC e de operações devem registrar carimbos temporais confiáveis desde a detecção, com fontes de tempo sincronizadas, porque reconstruir a linha do tempo depois custa caro e enfraquece cada campo seguinte do formulário.
Ciclo mensal até o relatório final
As instruções explicitam uma expectativa que muitas entidades não haviam interiorizado: depois da notificação inicial e do primeiro relatório intermédio, é esperado pelo menos um intermédio por mês até a entrega do relatório final. Em incidentes complexos, a recuperação técnica termina muito antes da apuração de causa raiz, da quantificação de perdas e da conclusão da perícia — e o ciclo de relato continua rodando durante toda essa fase. O processo interno precisa suportar esse calendário estendido sem depender da mesma equipe que está apagando o incêndio.
O relatório final cobre conteúdo que exige colaboração entre áreas: causa raiz, datas e horários de resolução, custos diretos e indiretos, recuperações financeiras e ocorrências recorrentes. O detalhamento econômico é obrigatório quando o impacto econômico foi critério de classificação do incidente, mas pode e deve ser informado sempre que a informação existir. Preparar antecipadamente o fluxo entre segurança, jurídico, financeiro e operações encurta o caminho até uma entrega limpa.
Ações priorizadas para o time
- P1 — Identidade do incidente: mapear quem define e congela os campos de identificação do relato, garantindo que não mudem ao longo do ciclo.
- P1 — Versionamento: implementar envio de nova versão completa do relatório mais recente a cada correção, nunca patches isolados.
- P1 — Carimbos temporais: garantir detecção, classificação e resolução registradas com hora confiável e sincronização de tempo ativa.
- P2 — Ciclo mensal: criar rotina de revisão mensal de incidentes abertos enquanto o relatório final não for viável.
- P2 — Dados de terceiros: manter cadastro de provedores de TIC com códigos LEI e EUID prontos para a primeira notificação.
- P2 — Estimativas rotuladas: separar medição e estimativa em todos os campos de duração e indisponibilidade.
Para entidades que também caem no escopo da NIS2, vale lembrar que o DORA funciona como legislação setorial específica e prevalece, mas os requisitos foram considerados equivalentes em efeito — uma razão a mais para unificar processos em vez de manter trilhas duplicadas, como discutido no guia NIS2 na prática: do risco à continuidade. Supervisão de qualidade de dados premia quem trata o relato como produto de engenharia, com dono, teste e versão.