---
title: "Reporte de incidentes do DORA e da NIS2: receba uma chamada antes que o prazo acabe"
description: "O DORA dá 4 horas a partir da classificação. A NIS2 dá 24 horas a partir do conhecimento. Nenhum desses relógios pausa à noite. Veja como transformar um alerta de detecção em uma chamada telefônica de verdade com o Echobell."
date: 2026-07-31
author: Nooc
authorAvatarLink: /images/avatars/nooc.webp
authorLink: https://nooc.me
tags:
  - reporte de incidentes DORA
  - reporte de incidentes NIS2
  - prazos regulatórios
  - alertas por chamada
  - alertas de plantão
---

# Reporte de incidentes do DORA e da NIS2: receba uma chamada antes que o prazo acabe

Todo prazo de reporte de incidentes da UE começa a correr a partir de algo que uma máquina percebe, e continua correndo enquanto o seu time dorme. Se o alerta que dispara o relógio chega como uma notificação push silenciosa às 2h40 de um domingo, você já queimou um quarto da sua janela de reporte do DORA antes que um único ser humano o tenha lido. Este guia mostra como colocar uma chamada telefônica de verdade na frente do seu processo de reporte usando o [Echobell](https://apps.apple.com/app/apple-store/id6743597198?pt=128151925&ct=blog-dora-nis2-incident-reporting-alerts-pt&mt=8) — para que o relógio e a sua resposta comecem mais ou menos ao mesmo tempo.

A escala disso agora é medida, não estimada. Em 3 de junho de 2026, as três Autoridades Europeias de Supervisão publicaram o primeiro panorama de toda a UE sobre incidentes graves relacionados a TIC reportados sob o DORA: **3.383 incidentes graves** em 2025, uma média de **0,18 por entidade financeira** no escopo, sendo que **cerca de um terço** teve impacto transfronteiriço ([EBA](https://www.eba.europa.eu/publications-and-media/press-releases/esas-publish-first-report-dora-major-ict-related-incidents), [ESMA](https://www.esma.europa.eu/press-news/esma-news/esas-publish-first-report-dora-major-ict-related-incidents)). O detalhe que deveria moldar os seus alertas: apenas **10%** tinham relação com cibersegurança. Falhas de sistema e eventos externos foram os principais causadores.

Em outras palavras, os eventos que disparam um relógio regulatório são, em esmagadora maioria, os chatos: um deploy que falhou, uma dependência morta, a queda de um provedor. As mesmas coisas que o seu monitoramento já detecta às 3 da manhã e entrega a um celular no modo Não perturbe.

## O que os prazos de reporte realmente exigem

**Três regimes, três tiros de largada diferentes — e todos correm em tempo real.** É isto que os textos atuais dizem.

| Regime | Primeiro prazo | Depois | Por fim |
| --- | --- | --- | --- |
| **DORA** (entidades financeiras da UE) | Notificação inicial em até **4 horas** depois de classificar o incidente como grave, e no máximo **24 horas** depois de tomar conhecimento dele | Relatório intermediário no máximo **72 horas** depois da notificação inicial | Relatório final no máximo **um mês** depois do (último) relatório intermediário |
| **NIS2** (entidades essenciais e importantes da UE) | Alerta antecipado sem demora injustificada e, em todo caso, em até **24 horas** depois de tomar conhecimento do incidente significativo | Notificação do incidente em até **72 horas** depois de tomar conhecimento | Relatório final no máximo **um mês** depois da notificação do incidente |
| **SEC Item 1.05** (empresas listadas nos EUA) | Formulário 8-K em geral devido **quatro dias úteis** depois de determinar que um incidente é relevante | — | — |

Os prazos do DORA vêm do Regulamento Delegado (UE) 2025/301 da Comissão, a norma técnica regulatória sobre o conteúdo e os prazos do reporte de incidentes, publicada em 20 de fevereiro de 2025 e complementando o [Regulamento (UE) 2022/2554](https://eur-lex.europa.eu/eli/reg/2022/2554/oj) ([Comissão Europeia](https://finance.ec.europa.eu/regulation-and-supervision/financial-services-legislation/implementing-and-delegated-acts/digital-operational-resilience-regulation_en), [texto do Artigo 5](https://www.springlex.eu/en/packages/dora/rts-ir-regulation/article-5/)). O próprio DORA se aplica desde 17 de janeiro de 2025 ([ESMA](https://www.esma.europa.eu/esmas-activities/digital-finance-and-innovation/digital-operational-resilience-act-dora)).

Os prazos da NIS2 estão no Artigo 23(4) da [Diretiva (UE) 2022/2555](https://eur-lex.europa.eu/eli/dir/2022/2555/oj); os Estados-membros tinham de transpô-la até 17 de outubro de 2024 ([Comissão Europeia](https://digital-strategy.ec.europa.eu/en/policies/nis2-directive)). O prazo da SEC vem das regras de divulgação de cibersegurança adotadas em 26 de julho de 2023 ([SEC](https://www.sec.gov/newsroom/press-releases/2023-139)).

## Por que um prazo de reporte é, na verdade, um problema de acordar alguém

**Porque nenhum desses relógios está atrelado ao seu horário de trabalho.** O DORA conta a partir da classificação e a partir do momento em que a entidade toma conhecimento. A NIS2 conta a partir do momento em que a entidade toma conhecimento. A SEC conta a partir da determinação de relevância. Se um determinado momento conta como "conhecimento" ou não é um julgamento jurídico que a sua área de conformidade faz — mas nada em nenhum desses textos reinicia a contagem porque a primeira pessoa a ver o alerta por acaso estava dormindo.

Faça a conta de trás para frente no caminho mais apertado do DORA. Você tem 4 horas a partir do momento em que um incidente é classificado como grave, e a classificação não acontece antes de um ser humano olhar para ele. Se a detecção é às 2h40, ninguém confirma antes das 8h e a classificação leva mais 90 minutos de investigação, você envia a notificação inicial por volta das 11h — dentro do limite externo de 24 horas, mas com mais de oito horas de um teto de 24 horas gastas em nada além de sono. Encurte o intervalo até a confirmação e todo passo seguinte ganha espaço para respirar.

Isso não é um argumento para alertar sobre mais coisas. É um argumento para que uma classe estreita e específica de alertas — aqueles que plausivelmente podem se tornar reportáveis — seja fisicamente impossível de perder no meio do sono. Todo o resto deve continuar em silêncio. (Se o seu time já está se afogando, comece [resolvendo a fadiga de alertas](/blog/fix-alert-fatigue-developer-guide) antes de acrescentar um canal mais barulhento.)

## O fim de semana te dá tempo extra?

**Um pouco, sob o DORA — e muito provavelmente não para você.** O Regulamento Delegado (UE) 2025/301 permite que uma entidade financeira cujo prazo caia em um dia de fim de semana ou em um feriado bancário no seu Estado-membro envie até o meio-dia do próximo dia útil. Mas o mesmo artigo nega essa extensão a instituições de crédito, contrapartes centrais e operadores de plataformas de negociação, além de entidades essenciais ou importantes no sentido da NIS2. As autoridades competentes também podem retirá-la de outras entidades sistemicamente relevantes ([Artigo 5](https://www.springlex.eu/en/packages/dora/rts-ir-regulation/article-5/), [resumo da Advisera](https://advisera.com/cdr-2025-301/time-limits-for-the-initial-notification-and-for-the-intermediate-and-final-reports/)).

Ou seja, as organizações com maior probabilidade de ter um incidente em uma noite de domingo são exatamente as que não têm alívio nenhum no fim de semana. O Artigo 23 da NIS2 não contém extensão alguma para fins de semana. Planeje-se para o relógio correr no sábado exatamente como corre na terça e trate qualquer extensão a que você tenha direito como bônus, não como folga.

## Como colocar um telefone tocando na frente do seu processo de reporte

O Echobell faz uma coisa só: transforma um webhook ou um e-mail em uma chamada telefônica — uma ligação de verdade, que toca e vibra, e que atravessa o modo Foco e o Não perturbe do iOS, como faria a ligação de um familiar (veja [como driblar o modo Foco do iOS para alertas críticos](/blog/how-to-bypass-ios-focus-mode-for-critical-alerts)). Ele fica entre o sistema que detecta o incidente e a pessoa que precisa iniciar o relógio.

### Passo 1 — Crie um canal em Chamada reservado a incidentes reportáveis

Crie um canal no Echobell e defina o tipo de notificação como **Chamada**. É isso que faz o telefone tocar em vez de entregar um push silencioso ([tipos de notificação](/docs/notification)). Dê a ele um nome que não deixe dúvida — "Incidente reportável — acorde" — e não o use para mais nada. Copie a URL do webhook nos detalhes do canal; ela se parece com `https://hook.echobell.one/t/<channel-token>`. Trate-a como um segredo.

### Passo 2 — Aponte a sua stack de detecção para esse webhook

O que quer que perceba o incidente envia uma requisição HTTP para a URL do canal. O Echobell tem guias diretos para [Grafana](/docs/developer/grafana), [Prometheus Alertmanager](/docs/developer/prometheus), [Uptime Kuma](/docs/developer/uptime-kuma) e [UptimeRobot](/docs/developer/uptimerobot); qualquer outra coisa capaz de fazer POST de JSON funciona pelo [guia de webhooks](/docs/webhook). Um payload útil carrega o suficiente para uma primeira decisão de classificação sem abrir o notebook:

```json
{
  "title": "Candidato a reportável: {{service}}",
  "message": "{{service}} fora do ar desde {{started_at}} — impacto em clientes: {{client_impact}}",
  "externalLink": "https://status.internal.example/incident/{{id}}"
}
```

A variável `externalLink` vira um link clicável no registro da notificação, então quem atende a chamada cai direto no incidente.

### Passo 3 — Use condições para que só candidatos plausíveis toquem

**Uma chamada que dispara a cada aviso deixa de ser uma chamada e vira ruído de fundo.** As [condições](/docs/conditions) do Echobell filtram por valores de variáveis com lógica E/OU, então você pode exigir, por exemplo, `severity == "critical"` **e** `client_impact == true` antes que o canal ligue para alguém. Mande tudo o que ficar abaixo dessa régua para um canal Urgente ou Normal separado. O seu canal de incidentes reportáveis deveria tocar um punhado de vezes por ano, não toda semana.

### Passo 4 — Capture os sistemas que só mandam e-mail

Muitos feeds de status de fornecedores, ferramentas de monitoramento de fraude e provedores terceiros notificam por e-mail e por mais nada — o que importa sob o DORA, onde falhas do lado do provedor estão claramente no escopo. Todo canal do Echobell pode ter o próprio endereço, então uma regra de encaminhamento transforma essas mensagens em chamadas ([gatilhos por e-mail](/docs/email-trigger), [configuração de e-mail para chamada](/docs/email-to-call)).

### Passo 5 — Coloque no mesmo canal quem responde pelo prazo

A engenharia encontra o incidente; a conformidade, o responsável de plantão ou o DPO respondem pelo prazo. Compartilhe o canal e cada inscrito escolhe a própria urgência, de modo que a pessoa de plantão na engenharia recebe uma chamada enquanto um segundo respondente recebe um alerta urgente. Ative **Repetir chamada perdida** para que uma chamada bloqueada pelo modo Foco seja tentada de novo.

### Passo 6 — Teste com o Não perturbe ligado

Envie um webhook de teste com o Não perturbe ativado em todo celular que importa, pelo menos uma vez por trimestre. Um caminho de escalonamento não testado é uma suposição — e é de suposições que as revisões pós-incidente são feitas.

## O que o Echobell não faz

Ser preciso aqui importa mais em um processo regulado do que em qualquer outro lugar.

**O Echobell faz:** transformar um webhook ou um e-mail em uma chamada que toca, em um alerta urgente ou em um push normal; atravessar o modo Foco e o Não perturbe do iOS nos alertas em Chamada; filtrar com condições e modelos; entregar o mesmo alerta a um canal de time compartilhado.

**O Echobell não:**

- **Classifica incidentes.** Ele não tem opinião sobre se algo é "grave" no sentido do DORA, "significativo" no sentido da NIS2 ou "relevante" no sentido das regras da SEC. Esses são julgamentos que as suas pessoas fazem com base nos critérios dos textos aplicáveis.
- **Protocola nada com ninguém.** Ele não envia nada a uma autoridade competente, a um CSIRT ou à SEC. Ele leva um ser humano até o ponto em que essa pessoa pode fazer isso.
- **Serve como o seu sistema de registros ou de GRC.** Esses regimes exigem documentação, registros e evidências que um app de alertas não produz. O Echobell guarda deliberadamente o conteúdo e o histórico das notificações apenas no seu dispositivo, deixando no servidor só contas, canais e inscrições ([modelo de privacidade](/docs/features)) — ótimo para minimização de dados, inútil como trilha de auditoria.
- **Vem com um atestado de conformidade.** Não há certificação, relatório de auditoria nem SLA contratual associado a ele. Se você o introduzir em um processo regulado, passe-o pelo seu próprio processo de risco de terceiros em TIC como faria com qualquer outra ferramenta, e mantenha um canal que não dependa dele.
- **Garante a entrega.** Uma chamada depende da infraestrutura de push, da rede e de um celular carregado. Trate-a como a camada que encurta drasticamente o tempo até a confirmação, não como um controle que você aponta em uma auditoria.

O enquadramento honesto: a sua obrigação regulatória não muda por causa de qual app faz o seu telefone tocar. O que uma chamada muda é o número de horas entre uma máquina perceber e uma pessoa decidir — e, sob um relógio de 4 horas, essas horas são a maior parte do orçamento.

## FAQ

### Usar o Echobell nos deixa em conformidade com o DORA ou a NIS2?

Não. A conformidade depende da sua governança, do seu processo de classificação, da documentação e dos envios efetivos à sua autoridade competente ou ao CSIRT. O Echobell só encurta o intervalo entre a detecção e a confirmação humana. Ele é uma entrada do processo, não o processo.

### Quando exatamente começa o relógio de 4 horas do DORA?

Na classificação. Sob o Regulamento Delegado (UE) 2025/301, a notificação inicial é devida em até quatro horas depois de classificar um incidente como grave e, em todo caso, no máximo 24 horas a partir do momento em que a entidade tomou conhecimento dele. São duas restrições separadas e você precisa satisfazer as duas — por isso uma decisão de classificação rápida importa tanto quanto um alerta rápido.

### O alerta antecipado da NIS2 precisa dos detalhes completos do incidente?

Não. O Artigo 23(4) da Diretiva (UE) 2022/2555 mantém o alerta antecipado de 24 horas deliberadamente provisório: se há suspeita de que o incidente foi causado por atos ilícitos ou maliciosos e se ele pode ter impacto transfronteiriço. O quadro mais completo é devido na notificação de 72 horas, e a análise de causa raiz no relatório final, um mês depois.

### Nosso monitoramento já manda e-mail para quem está de plantão. Isso não basta?

Basta quando alguém está acordado e olhando. E-mails e notificações push comuns são silenciados pelos modos Foco, pelo Não perturbe e pelas agendas de sono — exatamente as condições das noites e dos fins de semana em que o relógio é menos indulgente. A lacuna não está na detecção, está na confirmação.

### A conformidade e a engenharia podem receber o mesmo alerta?

Podem. Compartilhe o canal e todo mundo inscrito recebe o gatilho, cada um escolhendo o próprio tipo de notificação. Uma configuração comum: a pessoa de plantão na engenharia se inscreve como Chamada; a pessoa de conformidade de plantão, como Chamada no canal de incidentes reportáveis e Urgente em todo o resto.

### A chamada realmente atravessa o Não perturbe?

O tipo de notificação Chamada do Echobell foi feito para tocar através do modo Foco e do Não perturbe do iOS, e a opção Repetir chamada perdida tenta de novo as chamadas bloqueadas pelo modo Foco. Verifique isso no aparelho real de cada pessoa que responde antes de contar com ele — as configurações e as versões do sistema variam.

### Isso é só para iOS?

Não. O Echobell está disponível no iOS e no Android via Google Play (veja [o anúncio de lançamento do Android](/blog/echobell-android-release)). O comportamento dos alertas em formato de ligação difere entre as plataformas, então teste nos aparelhos que as suas pessoas de plantão realmente carregam.

### Quais dados devemos colocar no payload do webhook?

O mínimo possível. Envie um identificador e um link, em vez de dados de clientes ou detalhes do incidente — use a variável `externalLink` para apontar para o seu registro de incidente, que fica em um sistema construído para guardá-lo. O trabalho do alerta é acordar alguém, não fazer o briefing dessa pessoa.

---

## Relacionados

- [Quedas na nuvem são o novo normal: como continuar recebendo alertas](/blog/cloud-outage-alerts)
- [Alertas por chamada quando a sua API cai](/blog/phone-call-alerts-api-downtime)
- [Alternativas ao fim de vida do Opsgenie: desligamento em 2027](/blog/opsgenie-end-of-life-alternatives)
- [Como driblar o modo Foco do iOS para alertas críticos](/blog/how-to-bypass-ios-focus-mode-for-critical-alerts)
- [Guia de integração de webhooks](/docs/webhook)
- [Guia de condições](/docs/conditions)