O DORA livrou vocês da NIS2. Não livrará do CRA.

TL;DR. Em 11 de setembro o CRA dispara um prazo de 24 horas. Ele recai sobre produtos, e a isenção do DORA frente à NIS2 nunca o alcança.

Principais conclusões

O que realmente começa em 11 de setembro. O CRA entrou em vigor em 10 de dezembro de 2024 com um cronograma escalonado de aplicação, e é justamente o escalonamento que se perde.
Por que a isenção do DORA não o alcança. Esta é a parte que merece precisão, porque o raciocínio que produz a resposta errada é um raciocínio genuinamente bom, levado um regulamento longe demais.
Vocês são fabricantes? Ninguém respondeu isso por vocês. Aqui a posição honesta é que a questão está aberta e não resolvida, e que um banco que espere pela resolução esperará além da data.
A colisão de relógios. Suponha por um instante que a análise conclua pela inclusão de ao menos um artefato.

Em trinta e nove dias o Regulamento de Ciber-resiliência dispara um prazo de notificação de vinte e quatro horas, e a isenção que todo banco invoca não o detém. Pergunte a uma instituição financeira se a NIS2 se aplica e a resposta vem sem hesitação: o DORA é lex specialis, o artigo 4.º da NIS2 recua quando um ato setorial cobre o mesmo terreno, e o banco notifica incidentes de TIC à sua autoridade competente em vez de a um CSIRT. Essa resposta está correta. E está prestes a ser dada, equivocadamente, a uma pergunta sobre outro regulamento. O CRA não regula entidades. Regula produtos, e impõe seus deveres a quem os fabrica. Não há no seu artigo de escopo qualquer exclusão para serviços financeiros, porque uma exclusão redigida para direito de entidades não tem a que se agarrar em direito de produtos. A partir de 11 de setembro de 2026, um banco que disponibilize software no mercado deve à ENISA um alerta antecipado em vinte e quatro horas — e o deve além do DORA, não em lugar dele.

Resumo executivo

Uma data viva, não um horizonte. O artigo 14.º aplica-se desde 11 de setembro de 2026. O restante do CRA espera 11 de dezembro de 2027, e o erro de planejamento mora na distância entre esses dois fatos.

O escopo é decidido pelo que você entrega, não pelo que você é. As exclusões do CRA são outros regimes de produto: dispositivos médicos, veículos, aviação, equipamentos marítimos. O setor bancário não consta, e nunca constaria.

O gatilho é a exploração, não a gravidade. Uma vulnerabilidade ativamente explorada inicia o relógio mesmo que nenhum cliente seja afetado e mesmo que nada configurasse incidente grave sob o DORA.

Hoje ninguém é dono disso. A notificação DORA vive na resiliência operacional. A notificação CRA vive em quem for considerado fabricante — um papel que a maioria dos bancos nunca atribuiu.

O que realmente começa em 11 de setembro

O CRA entrou em vigor em 10 de dezembro de 2024 com um cronograma escalonado de aplicação, e é justamente o escalonamento que se perde.

A aplicação plena — requisitos essenciais de cibersegurança do anexo I, avaliação da conformidade, marcação CE, documentação técnica — cai em 11 de dezembro de 2027. A notificação dos organismos de avaliação da conformidade abriu em 11 de junho de 2026. Entre as duas está a data que importa neste trimestre: 11 de setembro de 2026, quando começam as obrigações de notificação do artigo 14.º.

A estrutura de notificação tem três etapas e é mais apertada do que parece à primeira leitura.

Alerta antecipado em 24 horas desde que o fabricante toma conhecimento de uma vulnerabilidade ativamente explorada, ou de um incidente grave com impacto na segurança do produto.
Notificação completa em 72 horas, com o detalhe técnico e as medidas corretivas ou de mitigação adotadas.
Relatório final em 14 dias após uma medida corretiva ficar disponível para uma vulnerabilidade ativamente explorada, ou em um mês contado da notificação para um incidente grave.

Os relatórios transitam pela plataforma única de notificação do CRA operada pela ENISA. O fabricante protocola uma única vez, junto ao CSIRT designado coordenador no Estado-Membro do seu estabelecimento principal; a plataforma disponibiliza a notificação à ENISA simultaneamente, e o CSIRT receptor a propaga aos demais CSIRT nos territórios onde o produto é distribuído. Esse desenho de envio único elimina uma desculpa administrativa, mas não abranda o relógio.

Repare no gatilho. Nem gravidade, nem impacto ao cliente — exploração. Uma vulnerabilidade ativamente explorada abre uma obrigação de 24 horas, tenha havido ou não vítima, e independentemente de os mesmos fatos se classificarem como incidente grave em qualquer outro lugar.

Por que a isenção do DORA não o alcança

Esta é a parte que merece precisão, porque o raciocínio que produz a resposta errada é um raciocínio genuinamente bom, levado um regulamento longe demais.

O artigo 4.º da NIS2 contém um mecanismo de remissão: quando um ato setorial da União exige que entidades adotem medidas de gestão de riscos de cibersegurança ou notifiquem incidentes significativos, e esses requisitos são pelo menos equivalentes em efeito, as disposições correspondentes da NIS2 não se aplicam. O DORA é exatamente um desses atos. Assim, uma instituição de crédito gere risco de TIC e notifica incidentes graves sob o DORA, e os deveres paralelos da NIS2 recuam. Qualquer função de assuntos regulatórios sabe recitar isso.

Três coisas quebram a analogia ao transpô-la para o CRA.

O mecanismo vive dentro da NIS2. O artigo 4.º é uma disposição da Diretiva (UE) 2022/2555 que afasta disposições da Diretiva (UE) 2022/2555. Não é um princípio geral segundo o qual o regime setorial de uma entidade financeira desloca todo o resto. Não pode entrar no Regulamento (UE) 2024/2847 e desligar coisa alguma ali, porque nada no CRA lhe está sujeito.

O CRA regula produtos, não entidades. DORA e NIS2 perguntam ambos que tipo de organização você é. O CRA pergunta o que você colocou no mercado. São perguntas diferentes, e argumentos de equivalência entre elas não funcionam: em nenhum sentido o regime de notificação do DORA é «equivalente em efeito» ao dever de um fabricante avisar um CSIRT de que um artefato entregue está sendo explorado, porque protegem populações distintas. O DORA protege o sistema financeiro por meio do supervisor. O artigo 14.º protege todos os que executam o produto, por meio da rede de CSIRT.

As exclusões têm o formato errado. O artigo de escopo do CRA afasta produtos cobertos por outra legislação setorial de produtos — dispositivos médicos sob os Regulamentos (UE) 2017/745 e 2017/746, veículos sob o Regulamento (UE) 2019/2144, aviação civil sob o Regulamento (UE) 2018/1139, equipamentos marítimos sob a Diretiva 2014/90/UE — além de peças de reposição fabricadas conforme especificações idênticas e produtos desenvolvidos exclusivamente para segurança nacional ou defesa. Não há exclusão para serviços financeiros, nem para produtos fabricados por entidades reguladas pelo DORA. Isso não é um lapso que orientações virão corrigir. É o que acontece quando um legislador escreve direito de produtos: ele não exclui setores, exclui outros regimes de produto.

Tabela 1: três regimes, e qual recua

	DORA	NIS2	CRA
Regula	Entidades financeiras	Entidades essenciais e importantes	Produtos com elementos digitais
O dever recai sobre	A instituição	A instituição	O fabricante
Gatilho de notificação	Incidente classificado como grave	Incidente significativo	Vulnerabilidade ativamente explorada ou incidente grave
Destinatário	Autoridade competente	CSIRT ou autoridade competente	CSIRT do estabelecimento principal, e ENISA
Afastado para bancos?	Não — é a lex specialis	Sim, via artigo 4.º da NIS2	Não — nada o afasta

Vocês são fabricantes? Ninguém respondeu isso por vocês

Aqui a posição honesta é que a questão está aberta e não resolvida, e que um banco que espere pela resolução esperará além da data.

O CRA alcança produtos com elementos digitais disponibilizados no mercado — fornecidos para distribuição ou uso no âmbito de uma atividade comercial. Dessa formulação decorrem imediatamente duas consequências.

O preço não é o critério. Software fornecido gratuitamente entra no escopo se for fornecido no âmbito de uma atividade comercial. A leitura da Comissão sobre código aberto gira em torno da atividade comercial e não do pagamento, e um banco que distribui um aplicativo para captar e atender clientes pagantes não age fora do âmbito de uma atividade comercial. O instinto de que «damos o aplicativo de graça, logo não vendemos um produto» é a razão mais comum para este dossiê não ter sido aberto, e é o mais fraco dos argumentos disponíveis.

Software estritamente interno fica de fato de fora. Produtos não disponibilizados no mercado — a plataforma de core banking, o ferramental interno, tudo o que nunca é fornecido além da instituição — não são alcançados. É uma exclusão real e substancial, e por isso a exposição é mais estreita do que sugere a versão alarmista desta análise.

A pergunta, portanto, não é se um banco entra no escopo como entidade. É quais artefatos específicos ele fornece. Quatro categorias merecem inventário antes de qualquer conclusão:

O aplicativo de banco móvel, distribuído ao público geral pelas lojas de aplicativos. Se um aplicativo voltado ao cliente é um produto fornecido para uso, ou apenas a interface de um serviço prestado pelo banco, é a questão genuinamente controversa — e ela é controversa, não resolvida a favor do banco.
Artefatos voltados a desenvolvedores: SDKs, bibliotecas cliente, ferramental de API e implementações de referência publicadas para clientes corporativos ou parceiros. Esses se parecem muito mais com produtos fornecidos e muito menos com uma interface de serviço.
Projetos de código aberto que a instituição publica e mantém como parte de sua atividade comercial, onde as disposições sobre o curador também podem incidir.
Software white label ou embarcado que o banco repassa a parceiros sob o próprio nome, a rota mais rápida de implantador a fabricante em qualquer regime de produto da UE.

A postura honesta de planejamento não é afirmar uma conclusão. É inventariar os artefatos, registrar por escrito uma posição fundamentada sobre cada um e ser capaz de mostrar o raciocínio se um CSIRT perguntar por que nenhuma notificação chegou.

A colisão de relógios

Suponha por um instante que a análise conclua pela inclusão de ao menos um artefato. O que muda operacionalmente não é a existência de um processo de incidentes — os bancos têm — mas o fato de que agora dois processos rodam sobre o mesmo evento com parâmetros diferentes.

Uma vulnerabilidade em um SDK publicado por um banco passa a ser ativamente explorada. O DORA pergunta se se trata de um incidente grave relacionado às TIC que afeta a instituição e, em caso afirmativo, a notificação inicial vai à autoridade competente em quatro horas dessa classificação e, em todo caso, em 24 horas do conhecimento, com um relatório intermediário e um final atrás. O artigo 14.º faz uma pergunta inteiramente diferente — está sendo explorado um produto que esta instituição fabricou — e dispara seu próprio alerta antecipado de 24 horas a um CSIRT e à ENISA.

Os dois podem divergir nas duas direções, e é isso que torna inseguro qualquer processo fundido.

Uma vulnerabilidade explorada em um SDK entregue que não cause interrupção alguma aos serviços do próprio banco pode não ser incidente grave algum sob o DORA e ainda assim cair inteiramente no artigo 14.º. E uma falha severa de uma plataforma construída internamente é uma notificação DORA sem dimensão CRA nenhuma, porque nada foi colocado no mercado. Construir um fluxo único que presuma que os dois sempre disparam juntos produz ao mesmo tempo falsos negativos e ruído regulatório desnecessário.

Tabela 2: o que estabelecer antes de 11 de setembro

Pergunta	O que determina na sua exposição
Que artefatos fornecemos para fora da instituição?	O escopo é por produto; não há resposta no nível da entidade
Para cada um, há posição documentada sobre o status de fabricante?	Uma suposição não documentada não é defesa
Onde fica nosso estabelecimento principal para fins de CSIRT?	Determina qual CSIRT nacional recebe o protocolo
Estamos registrados na plataforma única de notificação da ENISA?	24 horas não bastam para descobrir uma etapa de credenciamento
«Ativamente explorada» tem dono na triagem?	O gatilho difere de toda escala de gravidade já em uso
Quem protocola às 3h de um domingo?	Ambos os relógios correm em tempo real, não em horário comercial

O número que define a prioridade

O descumprimento dos requisitos essenciais do anexo I e das obrigações dos artigos 13.º e 14.º sujeita a coimas administrativas de até 15 milhões de euros ou 2,5 % do faturamento anual mundial total, o que for maior. As demais obrigações de fabricantes, importadores e distribuidores ficam um degrau abaixo, em 10 milhões ou 2 %, e prestar informação incorreta ou enganosa às autoridades, em 5 milhões ou 1 %.

Leia o degrau superior contra o trabalho a que ele se prende. Determinar se quatro categorias de artefatos estão no escopo, registrar-se numa plataforma de notificação e acrescentar um ramo a um manual de triagem existente é um esforço modesto, com dono designado e cinco semanas pela frente. Não é comparável ao programa de avaliação da conformidade e documentação técnica que aguarda em dezembro de 2027. A assimetria entre a exposição e o custo de remediação é o argumento inteiro, e é o raro argumento de conformidade que sobrevive ao contato com uma reunião de priorização.

O manual operacional

Cinco movimentos, e o primeiro não é um parecer jurídico.

Inventarie o que sai do prédio. Não sistemas — artefatos. Tudo o que a instituição fornece a alguém de fora, incluindo aplicativos gratuitos, bibliotecas publicadas e repositórios de código aberto. A maioria dos bancos não tem essa lista, porque nenhuma norma anterior a pediu.
Fixe uma posição por artefato, por escrito. Fabricante, ou não, e por quê. O valor não está em acertar cada linha; está em ter um raciocínio anterior ao incidente em vez de construído depois.
Credencie-se já na plataforma única de notificação. Registro, credenciais e um protocolador designado são exatamente o tipo de pré-requisito invisível até que um relógio de 24 horas já esteja correndo.
Desdobre o gatilho na triagem. Acrescente uma pergunta explícita — um produto que fabricamos está sendo ativamente explorado — avaliada de forma independente da classificação de incidente grave do DORA. A independência é o ponto: um controle aninhado herda o limiar errado.
Comece o trabalho de SBOM contra a data de dezembro de 2027. O anexo I exige uma lista de materiais de software em formato comum legível por máquina, cobrindo ao menos as dependências de primeiro nível. Esse dever está a dezesseis meses, e é o mesmo problema de enumeração em que as instituições já falham do lado criptográfico.

O padrão não é novo. Um regime é redigido pensando num setor específico, as instituições financeiras leem o nome do setor e concluem que o dossiê é de outra pessoa. O CRA foi escrito para fabricantes de dispositivos e fornecedores de software. Alcança o banco mesmo assim, no espaço estreito em que o banco acaba sendo um deles — e a isenção a que todos recorrerão primeiro foi escrita em outra lei, para outra finalidade, e não se aplica.

Perguntas frequentes

Notificamos sob o DORA. Isso não cobre?
Não. O DORA afasta as obrigações paralelas da NIS2 pelo mecanismo de remissão do próprio artigo 4.º da NIS2. Esse mecanismo é interno à NIS2 e não produz efeito sobre o Regulamento (UE) 2024/2847. O CRA impõe deveres a fabricantes de produtos, não a entidades financeiras, de modo que não há nada que um argumento de lex specialis possa afastar.

Nosso aplicativo de banco móvel está no escopo?
Essa é a questão genuinamente aberta, e deve ser respondida deliberadamente e não presumida. O aplicativo é software com conexão de dados, fornecido ao público no âmbito de uma atividade comercial, que é a formulação legal. O argumento contrário é que ele constitui a interface de um serviço regulado e não um produto fornecido para uso. Documente uma posição; não se apoie no fato de ser gratuito, porque o preço não é o critério.

O que exatamente dispara o prazo de 24 horas?
Tomar conhecimento de uma vulnerabilidade do seu produto que esteja sendo ativamente explorada, ou de um incidente grave com impacto na segurança do produto. O gatilho é a exploração, não a gravidade nem o impacto ao cliente — razão pela qual não se sobrepõe à classificação de incidente grave do DORA.

Para quem protocolamos na prática?
Pela plataforma única de notificação do CRA da ENISA, endereçada ao CSIRT designado coordenador no Estado-Membro do seu estabelecimento principal. A ENISA a recebe simultaneamente, e o CSIRT receptor a compartilha com os CSIRT de outros territórios onde o produto é distribuído. Um protocolo, não vários.

Começa mais alguma coisa em setembro?
Não. Apenas as obrigações de notificação do artigo 14.º. Os requisitos essenciais de cibersegurança, o dever de SBOM, a avaliação da conformidade, a documentação técnica e a marcação CE aplicam-se todos a partir de 11 de dezembro de 2027. Tratar setembro como o dossiê inteiro é a imagem invertida de ignorá-lo.

Qual o custo se errarmos o escopo?
As violações dos artigos 13.º e 14.º e dos requisitos essenciais do anexo I sujeitam a coimas de até 15 milhões de euros ou 2,5 % do faturamento anual mundial total, o que for maior. O custo mais imediato é procedimental: um alerta antecipado perdido não se sana retroativamente, e o momento em que uma instituição descobre que era fabricante não deveria ser aquele em que um CSIRT pergunta por que nenhuma notificação chegou.

Referências

Parlamento Europeu e Conselho da União Europeia, 2024. Regulamento (UE) 2024/2847 relativo a requisitos horizontais de cibersegurança para produtos com elementos digitais (Regulamento Ciber-resiliência). Bruxelas: Jornal Oficial da União Europeia. Disponível em: Parlamento Europeu e Conselho da União Europeia, 2024..
Comissão Europeia, 2026. Regulamento Ciber-resiliência — Obrigações de notificação. Bruxelas: Direção-Geral das Redes de Comunicação, Conteúdos e Tecnologias. Disponível em: Comissão Europeia, 2026..
Comissão Europeia, 2026. O Regulamento Ciber-resiliência — Resumo do texto legislativo. Bruxelas: Direção-Geral das Redes de Comunicação, Conteúdos e Tecnologias. Disponível em: Comissão Europeia, 2026..
Parlamento Europeu e Conselho da União Europeia, 2022. Diretiva (UE) 2022/2555 relativa a medidas destinadas a garantir um elevado nível comum de cibersegurança na União (Diretiva NIS 2). Bruxelas: Jornal Oficial da União Europeia. Disponível em: Parlamento Europeu e Conselho da União Europeia, 2022..
Parlamento Europeu e Conselho da União Europeia, 2022. Regulamento (UE) 2022/2554 relativo à resiliência operacional digital do setor financeiro (DORA). Bruxelas: Jornal Oficial da União Europeia. Disponível em: Parlamento Europeu e Conselho da União Europeia, 2022..

Última revisão 2026-08-16.

Republicar este artigo

O DORA livrou vocês da NIS2. Não livrará do CRA. — Sebastien Rousseau

Em 11 de setembro o CRA dispara um prazo de 24 horas. Ele recai sobre produtos, e a isenção do DORA frente à NIS2 nunca o alcança.

Este artigo está licenciado sob Creative Commons Attribution 4.0 International. A republicação exige atribuição à URL canônica.

O DORA livrou vocês da NIS2. Não livrará do CRA. — Sebastien Rousseau

Em 11 de setembro o CRA dispara um prazo de 24 horas. Ele recai sobre produtos, e a isenção do DORA frente à NIS2 nunca o alcança.

Originally published at https://sebastienrousseau.com/pt-br/2026-08-03-cyber-resilience-act-article-14-reporting-banks-2026/ by Sebastien Rousseau.
Licensed under CC-BY-4.0.

SEBASTIEN ROUSSEAU FOUNDER · ENGINEER