O que é a DORA e quando se aplica a empresas brasileiras?
O Regulamento (UE) 2022/2554 sobre resiliência operacional digital do setor financeiro (DORA) está em aplicação desde 17 de janeiro de 2025. Aplica diretamente a entidades financeiras supervisionadas na UE — bancos, seguradoras, gestoras de ativos, ESI, IIC, fundos de pensão, ECC, DCV, instituições de pagamento, dinheiro eletrônico, plataformas de crowdfunding regulado e outros 21 tipos enumerados no artigo 2. Para empresas brasileiras, DORA pode aplicar nestes cenários: (1) você tem subsidiária financeira europeia regulada; (2) você é fornecedor TIC para uma entidade financeira europeia, situação em que será exigido contrato compatível com o artigo 30; (3) você participa em consórcios de pagamento ou clearing UE-Brasil onde o artigo 30 é referência contratual. Adicionalmente, a Resolução CMN 4.893/2021 e a Circular Bacen 3.909/2018 brasileiras compartilham princípios funcionais com DORA, e demonstrar conformidade DORA simplifica due diligence com clientes europeus.
Como o plano Enterprise cobre o artigo 30 ponto a ponto?
O plano Enterprise inclui automaticamente as cláusulas contratuais do artigo 30 DORA: 30(2)(a) descrição precisa do serviço (anexo técnico), 30(2)(b) localizações de tratamento (lista de PoPs UE com localização exata), 30(2)(c) disposições sobre disponibilidade (SLA 99,99% com créditos), 30(2)(d) acessibilidade e recuperação de dados no término do contrato (90 dias de retenção mais export estruturado), 30(2)(e) níveis de serviço e desempenho (métricas mensuráveis), 30(2)(f) assistência diante de incidentes, 30(2)(g) cooperação com autoridades competentes, 30(2)(h) direitos de rescisão e prazos mínimos de aviso (90 dias por causa, 180 por conveniência), 30(2)(i) participação em programas de treinamento. O acordo é assinado em formato bilíngue português/inglês com cláusula de prevalência configurável para clientes regulados pelo Bacen.
Notificação de incidentes maiores TIC nos prazos DORA.
O artigo 19 obriga as entidades financeiras a notificar à autoridade competente os incidentes maiores TIC em três fases: notificação inicial em até 4 horas úteis desde a classificação (não desde a detecção), notificação intermediária em 72 horas com análise preliminar de causas e impacto, relatório final em 1 mês com causa-raiz, impacto consolidado e plano de ação. Para que sua equipe possa cumprir estes prazos quando o incidente envolve nossa infraestrutura, nos comprometemos contratualmente a notificar você em 2 horas desde a detecção (ou seja, 2 horas de margem para sua própria classificação e notificação inicial). Os relatórios técnicos posteriores que precise incluir na notificação intermediária e final entregamos em menos de 48 horas após pedido.
Equivalência com a regulação Bacen para empresas brasileiras.
A Resolução CMN 4.893/2021 e a Circular Bacen 3.909/2018 estabelecem requisitos de cibersegurança para instituições financeiras brasileiras com proximidade funcional significativa a DORA. Pontos comuns: cláusulas contratuais com prestadores de serviço TIC, plano de continuidade documentado, gestão de incidentes com classificação, supervisão da cadeia de fornecedores. Diferenças: o regime Bacen exige DRP (Diretor Responsável pela Segurança da Informação) nomeado formalmente; DORA tem registro de informação no formato ITS publicado pela EBA; os prazos de notificação são mais flexíveis no Bacen (prazo razoável definido caso a caso) e estritamente armonizados em DORA. Empresas brasileiras com atividade na UE podem implementar dual-compliance com nosso plano Enterprise, com documentação separada para cada regime mas a mesma infraestrutura técnica.
Onde está a aplicação da DORA em 2026?
A DORA é aplicável desde 17 de janeiro de 2025, então a meados de 2026 já não é uma data futura mas um regime sob supervisão ativa, e as autoridades europeias passaram de orientação a exigência. Ao longo de 2025 as Autoridades Europeias de Supervisão e os supervisores nacionais começaram a recolher os Registros de Informação das entidades financeiras, com o primeiro envio relevante concentrado em torno de abril de 2025 e o ciclo anual fixado em 30 de abril, e o exercício revelou lacunas de dados que muitas entidades subestimaram. A designação dos primeiros Provedores TIC Críticos pelas AES é o passo seguinte do calendário, com o trabalho de classificação em curso ao longo de 2025 e 2026 sobre os provedores de maior importância sistêmica. Para um remetente que presta serviço a uma entidade financeira, a consequência prática é que a sua contraparte já está obrigada e já está sendo perguntada pelo seu supervisor, então o pedido de cláusulas do artigo 30, de entradas do registro e de termos de saída deixou de ser hipotético. Operamos contra o texto da DORA e os seus RTS de desenvolvimento desde antes da data de aplicação, de modo que a documentação que um cliente financeiro precisa não se monta às pressas quando o supervisor pergunta.
O que é o Registro de Informação e como os seus dados são cruzados?
O artigo 28 da DORA exige que cada entidade financeira mantenha um Registro de Informação dos seus acordos TIC com terceiros e o apresente anualmente à sua autoridade competente, com o prazo fixado em 30 de abril. O registro segue um template estruturado que as Autoridades Europeias de Supervisão publicaram, com campos definidos: o identificador legal do provedor incluindo o LEI, a função suportada e se é crítica ou importante, as localizações de dados e de processamento, as datas de início e fim, a cadeia de subcontratação e uma avaliação de substituibilidade. A parte que surpreende muitas entidades é que os reguladores cruzam os registros entre entidades: se vinte bancos nomeiam o mesmo provedor, os supervisores comparam como cada um o descreve, e as discrepâncias —uma função classificada como importante por um e como não crítica por outro, ou localizações de dados que não batem— levantam perguntas. Por isso entregamos aos clientes do setor financeiro um export pré-mapeado aos campos do registro com a nossa entidade legal e o nosso LEI, as localizações precisas dos datacenters UE em uso, a lista de suboperadores e a data contratual, de modo que a linha do e-mail seja consistente entre todos os clientes que nos nomeiam. Um registro coerente entre entidades é o que evita que a sua linha de provedor de e-mail vire o detalhe que dispara uma pergunta do supervisor.
Designação de Provedor TIC Crítico: o que significa não sermos um.
A DORA cria uma categoria de Provedor TIC Crítico, designado diretamente pelas Autoridades Europeias de Supervisão quando um provedor atinge importância sistêmica para o setor financeiro da União, e um provedor assim designado fica sob supervisão direta das AES com poderes de inspeção e de recomendação. Não somos um Provedor TIC Crítico, e isso é uma afirmação que vale a pena fazer com clareza em vez de deixar ambígua. A designação se baseia em métricas de escala e de substituibilidade —o número de entidades financeiras que dependem do provedor, a sua interconexão, a dificuldade de migrar— e a nossa base está bem abaixo desse limiar. O que isso significa para você é duplo. Por um lado, não herda a supervisão direta das AES sobre nós, o que simplifica a sua própria relação. Por outro, e mais importante, as suas obrigações do artigo 30 aplicam exatamente igual independentemente do nosso status, porque essas obrigações recaem sobre você como entidade financeira e não sobre o provedor. Dito de outro modo, o rótulo de Provedor TIC Crítico não muda os termos que você precisa no contrato, então o que importa na avaliação são as cláusulas e a evidência, e não a etiqueta. Um provedor que insinua um status de criticidade que não tem está vendendo fumaça, e um avaliador experiente o nota.
Quais cláusulas do artigo 30 os clientes de fato negociam?
O artigo 30(2) e (3) da DORA lista o conteúdo contratual mínimo para um acordo TIC que suporta uma função importante, e na prática há um subconjunto dessas cláusulas que as equipes jurídicas das entidades financeiras de fato negociam linha a linha. Os direitos de auditoria são o primeiro: a entidade precisa do direito de auditar o provedor, por si mesma ou por um terceiro, e os provedores costumam querer limitar a frequência e o alcance, então o ponto de equilíbrio é um direito de auditoria real com um aviso razoável. Os termos de subcontratação são o segundo: o direito a ser notificado das mudanças materiais na cadeia antes de surtirem efeito e a opor-se a elas. Os prazos de notificação de incidentes são o terceiro, porque têm que encaixar na cascata de reporte da entidade. Os termos de saída e portabilidade são o quarto. As localizações de dados e de processamento são o quinto, sobretudo quando uma regra de soberania nacional estreita as opções. O nosso addendum DPA Enterprise traz cada uma dessas cláusulas já redigida na forma que costuma sobreviver à revisão, o que mantém a negociação em uma ou duas rodadas em vez de um trimestre, e onde um cliente precisa de uma variação específica a tratamos como uma emenda pontual em vez de reabrir o contrato inteiro.
Estratégia de saída e o plano de transição testado que a DORA agora espera.
O artigo 28(8) da DORA exige que os acordos para funções críticas ou importantes incluam estratégias de saída documentadas, e o que mudou frente ao regime anterior é que o supervisor agora espera um plano de transição que tenha sido testado e não meramente redigido. Para um serviço de e-mail, uma estratégia de saída crível tem três partes concretas. Primeiro, os ativos que continuam sendo seus e se movem com você: os domínios de envio, os seletores DKIM, as listas de supressão, os templates e os dados históricos de eventos, exportáveis em formatos abertos. Segundo, a reputação construída sobre IPs dedicadas, que não evapora se a transição se faz com um período de execução em paralelo no qual o provedor entrante aquece as suas próprias IPs enquanto nós seguimos entregando. Terceiro, uma janela definida —no nosso contrato padrão do setor financeiro, de 90 a 180 dias— com passos de transferência ordenados e um cutover documentado. A parte que a DORA acrescenta é a evidência de teste: documentamos um exercício de transição de modo que você possa mostrar ao supervisor que o plano funciona, em vez de ser um mero parágrafo. Uma cláusula de saída que ninguém ensaiou é uma hipótese, e a hipótese é exatamente o que a DORA deixou de aceitar.
Testes de penetração guiados por ameaças contra infraestrutura compartilhada?
O artigo 26 da DORA exige que as entidades financeiras mais significativas realizem testes de penetração guiados por ameaças, conhecidos como TLPT e alinhados ao marco TIBER-EU, sobre os sistemas que suportam as suas funções críticas, e esses testes alcançam os provedores TIC que fazem parte dessas funções. Para um provedor de e-mail compartilhado isso cria uma tensão real: um teste de intrusão autêntico contra a nossa infraestrutura tocaria sistemas que servem muitos clientes ao mesmo tempo, então não podemos abrir a produção compartilhada a um red team de um único cliente sem pôr em risco os demais. A forma como isso se resolve na prática é por etapas. Para o escopo que toca o ambiente dedicado do cliente —as suas IPs, os seus domínios, a sua configuração— participamos do exercício do cliente de forma coordenada. Para a infraestrutura compartilhada de base, fornecemos os resultados dos nossos próprios testes de penetração independentes e a evidência do programa de gestão de vulnerabilidades em vez de expor a plataforma comum, que é a abordagem que os marcos de TLPT contemplam para serviços partilhados. O ponto é nomear essa distinção com antecedência no contrato, porque uma entidade que assume que pode lançar um red team irrestrito contra um provedor compartilhado descobre tarde demais que o escopo precisava de uma estrutura, e o cronograma do seu próprio teste regulatório fica comprometido.