DORA (UE) e o Impacto em Cadeias de Fornecedores Brasileiros

Contexto: o que é DORA e desde quando vigora

O Digital Operational Resilience Act — formalmente Regulamento (UE) 2022/2554 — é o instrumento europeu que harmoniza, em uma única peça normativa, as expectativas de resiliência operacional digital para o setor financeiro da União Europeia. Publicado em dezembro de 2022, passou a ser aplicável a partir de 17 de janeiro de 2025, após período de transição de 24 meses para que entidades e supervisores se adaptassem.

Antes do DORA, o tema estava fragmentado entre diretivas setoriais, guidelines da EBA sobre outsourcing e ICT risk management, recomendações da ESMA e da EIOPA para suas indústrias supervisionadas, e abordagens nacionais variadas. A consequência prática era um patchwork: um banco com filiais em três países da UE precisava sustentar interpretações distintas de essencialmente os mesmos controles. DORA encerra essa fragmentação ao instituir regras de aplicação direta — não dependem de transposição nacional — e ao concentrar a autoridade supervisora final, no caso de terceiros críticos, em uma das três ESAs.

Para um CISO de uma fintech ou de um SaaS brasileiro que atende clientes europeus, isso significa duas coisas. Primeiro, seus clientes na UE precisam — desde janeiro de 2025 — operar sob DORA, e isso recai em formato de exigência contratual e operacional sobre você. Segundo, a partir do momento em que os RTS e ITS (regulatory/implementing technical standards) detalhando o regulamento estão sendo progressivamente publicados pelas ESAs, há um aumento contínuo de granularidade das expectativas — e do nível de evidência que o cliente europeu cobra do fornecedor.

A quem se aplica — e por onde alcança o Brasil

DORA aplica-se a uma lista ampla de entidades financeiras estabelecidas na UE — não apenas bancos. Inclui:

• Instituições de crédito (bancos);
• Instituições de pagamento e de moeda eletrônica;
• Empresas de investimento, gestoras de fundos, depositários centrais;
• Seguradoras, resseguradoras e intermediários de seguros;
• Provedores de serviços de crypto-assets autorizados sob MiCA;
• Agências de rating, administradores de benchmark, plataformas de crowdfunding;
• Câmaras de compensação (CCPs), trade repositories, entre outros.

Ao lado dessas entidades, DORA disciplina os fornecedores de serviços ICT que as sustentam — categoria deliberadamente ampla, que cobre cloud computing, software, processamento de dados, serviços gerenciados de segurança, conectividade, consultoria técnica continuada. É por aqui que empresas brasileiras entram no mapa.

Há três caminhos principais pelos quais uma organização brasileira é alcançada por DORA:

1. Como ICT third-party de entidade financeira da UE — uma fintech brasileira de antifraude que serve um banco italiano, um SaaS de KYC vendendo para neobanks alemães, um processador de pagamento brasileiro com clientes na Espanha, uma consultoria especializada em red team operando para uma seguradora francesa. Não importa onde os servidores estão; o que importa é a quem o serviço é prestado.
2. Via subsidiária brasileira de grupo financeiro europeu — quando o banco mãe na Europa decide que seu programa global de DORA precisa abranger toda a infraestrutura crítica do grupo, controles, testes e reporting são empurrados para a subsidiária brasileira por razão de consolidação. Não há aplicação extraterritorial direta, mas há aplicação por governança corporativa.
3. Como sub-outsourcing — sua empresa brasileira é contratada por um provedor europeu, que por sua vez serve uma entidade financeira da UE. DORA exige que o cliente final tenha visibilidade e governança sobre toda a cadeia, incluindo subcontratados materiais. Você herda obrigações via cascata contratual.

Em todos os três cenários, o efeito prático é o mesmo: a empresa brasileira precisa se comportar como se DORA se aplicasse, mesmo sem ser destinatária direta do regulamento. Resistência ao tema, na prática, equivale a não vender ao mercado europeu — uma decisão estratégica que poucas empresas estão dispostas a tomar.

Os cinco pilares do DORA

A estrutura do regulamento organiza-se em cinco pilares, cada um com requisitos detalhados e nível crescente de RTS/ITS preenchendo os detalhes técnicos.

Pilar 1 — ICT Risk Management em detalhe

O pilar 1 é o "guarda-chuva" e dialoga diretamente com NIST CSF, ISO/IEC 27001 e práticas estabelecidas. A novidade é a responsabilização explícita do órgão de administração: o board aprova a estratégia ICT, conhece o apetite de risco, recebe reporting material e responde por adequação de recursos. Para subsidiárias brasileiras de grupos europeus, isso se traduz em board reporting harmonizado e métricas comparáveis entre jurisdições.

Pilar 2 — Incident Management & Reporting em detalhe

O reporte de major ICT-related incidents segue prazos prescritos. Há uma notificação inicial que deve ser submetida em janela curta após a classificação do incidente como major (a referência operacional comum mencionada em material de implementação é até quatro horas após a classificação, conforme o RTS aplicável e considerando a classificação dentro de 24 horas da detecção). Em seguida, uma notificação intermediária e um relatório final em prazos definidos. Significant cyber threats também podem ser reportados, em regime voluntário.

Para a empresa brasileira que serve a UE, a consequência direta é: seu cliente europeu precisa que você o avise rapidamente sobre incidentes que afetem o serviço prestado a ele — porque ele depende dessa informação para conseguir cumprir seu próprio prazo de reporte ao supervisor. Cláusulas contratuais típicas falam em "sem demora indevida" e adicionam prazos numéricos (geralmente 1 a 2 horas para a primeira sinalização ao cliente). Esse fluxo precisa estar documentado, ensaiado e testado — não improvisado.

Pilar 3 — Resilience Testing e TLPT

DORA institui um programa de testes de resiliência operacional digital com escala proporcional. No nível mais básico, todas as entidades financeiras devem testar regularmente a resiliência de seus sistemas ICT críticos — testes de vulnerabilidade, scenario testing, testes de continuidade, gap analyses, testes de compatibilidade. No topo da pirâmide, entidades significantes precisam realizar TLPT com periodicidade mínima de três anos.

TLPT — Threat-Led Penetration Testing — segue a metodologia TIBER-EU (Threat Intelligence-based Ethical Red Teaming framework), originalmente publicada pelo BCE. Diferentemente de pentests tradicionais, TLPT:

• É baseado em inteligência de ameaças específica para a entidade — TTPs de atores reais que têm motivo e capacidade de atacar aquele alvo;
• Exercita funções críticas e a infraestrutura que as sustenta — incluindo prestadores ICT relevantes;
• Roda em ambiente de produção, com salvaguardas, por equipes de red team externas certificadas;
• Tem governança formal — White Team interno, autoridade competente envolvida, regras de engajamento estritas;
• Termina com remediation plan rastreado, não relatório engavetado.

Pilar 4 — ICT Third-Party Risk Management

O pilar de terceiros ICT é onde a maior parte do impacto sobre empresas brasileiras se materializa. Os principais elementos:

• Estratégia formal de terceiros ICT aprovada pelo board, com critérios de criticidade e tolerância;
• Due diligence proporcional antes da contratação — incluindo avaliação de risco-país, perfil de segurança, capacidade financeira, sub-outsourcing;
• Cláusulas contratuais mínimas (referência ao Art. 30 do regulamento) cobrindo descrição do serviço, locais de execução e armazenamento, requisitos de segurança da informação, acesso/auditoria/inspeção, BCM, treinamento, sub-outsourcing, terminação, estratégia de saída, cooperação com autoridades;
• Register of Information — registro detalhado de todos os arranjos ICT da entidade, reportado às autoridades em formato padronizado (XBRL/CSV);
• Monitoração contínua do desempenho e do perfil de risco do prestador ao longo do contrato;
• Exit strategy — capacidade demonstrável de sair do prestador sem ruptura, incluindo migração de dados, conhecimento e operação para alternativa.

Pilar 5 — Information-Sharing Arrangements

O pilar 5 é o mais leve — habilita arranjos voluntários de compartilhamento de informações sobre ameaças cibernéticas entre entidades financeiras, dentro de comunidades confiáveis (FS-ISAC e equivalentes), preservando confidencialidade e respeitando GDPR. Não cria obrigação, mas sinaliza que o regulador valoriza essa colaboração — entidades que participam tendem a ter melhor postura percebida.

Como brasileiros são impactados via supply chain

A pergunta operacional do CISO brasileiro é: "em que ponto, exatamente, DORA toca a minha empresa?". Depende do tipo de operação. Quatro arquétipos comuns:

Em todos os casos, vale o TPRM reverso: sua empresa precisa ter um programa equivalente para seus próprios subcontratados materiais. DORA exige que o cliente final consiga rastrear a cadeia inteira — se você usa um sub-processador menor para parte do serviço, esse sub-processador precisa estar disclosed e governado.

Critical ICT Third-Party Providers e oversight das ESAs

Um dos elementos mais inovadores de DORA é o regime de Critical ICT Third-Party Providers (CTPP). A Comissão Europeia, com base em critérios objetivos definidos no regulamento e detalhados em ato delegado, designa determinados provedores como críticos para o sistema financeiro da UE. Critérios incluem:

• Impacto sistêmico sobre estabilidade, continuidade ou qualidade dos serviços financeiros caso o prestador falhe;
• Importância sistêmica das entidades financeiras servidas;
• Substitutibilidade (ou ausência dela) do provedor;
• Número total de entidades financeiras servidas e volume agregado dos serviços ICT prestados.

Uma vez designado CTPP, o provedor passa a estar sob oversight direto de uma das três ESAs — EBA, ESMA ou EIOPA — na função de Lead Overseer, conforme o perfil predominante do prestador. O Lead Overseer trabalha em colaboração com Joint Examination Teams compostos por especialistas das três ESAs e de autoridades nacionais.

Poderes do Lead Overseer incluem:

• Solicitar informações relevantes para a supervisão;
• Conduzir inspeções gerais e on-site;
• Emitir recomendações endereçando deficiências de risco ICT — recomendações que, embora dirigidas ao CTPP, têm efeito indireto vinculante: entidades financeiras supervisionadas pelas autoridades europeias devem considerá-las nas suas decisões de continuar (ou não) utilizando aquele provedor;
• Aplicar penalty payments (pagamentos periódicos coercitivos) em caso de não conformidade com pedidos de informação ou recomendações de remediação significativas.

Para uma empresa brasileira de escala global servindo muitas instituições europeias, há um cenário não trivial: ser designada CTPP. Quando isso acontece, o relacionamento com supervisores europeus deixa de ser indireto via cliente — passa a ser direto. É um nível de exposição regulatória que muda a operação. As empresas com perfil potencialmente CTPP devem mapear essa hipótese antecipadamente e dimensionar capacidade de jurídico, compliance e tecnologia para sustentá-la.

DORA vs. Resolução BCB nº 6 vs. NIS2

CISOs de instituições brasileiras com presença internacional convivem hoje com pelo menos três regimes paralelos. As diferenças, em rápida comparação:

Em prática operacional, há sobreposição grande. Quem já está em conformidade com a Resolução BCB nº 6 tem ~70% do esforço caminhado em direção ao DORA — o que falta tipicamente é a prescrição de TLPT, o detalhamento contratual no nível Art. 30, o registro de informações em formato padronizado e a capacidade de cooperação ativa com supervisores europeus. Reverter: organizações estritamente "DORA-ready" para clientes europeus precisam adicionar particularidades do BCB (proporcionalidade S1-S5, terminologia local, integração com o Cadoc 6000).

O que preparar agora

Para uma organização brasileira que serve o mercado financeiro europeu — ou tem essa ambição de curto prazo — vale um plano em quatro frentes paralelas. Não é necessário esgotar uma antes de começar a outra.

Frente 1 — Inventário de exposição

• Lista de clientes europeus ativos e prospects sérios, com indicação do setor (banco, fintech, seguradora, gestora);
• Mapa de quais serviços são prestados, com classificação preliminar de criticidade segundo a ótica do cliente;
• Lista de seus próprios subcontratados materiais — quem você usa para entregar o serviço, com classificação equivalente;
• Avaliação de exposição agregada — em quantos clientes europeus você é "concentration risk"? Há sinais de candidatura a CTPP no horizonte de 24-36 meses?

Frente 2 — Questionários e evidências

• Padronizar respostas aos cinco pilares com evidência objetiva — políticas datadas e aprovadas, relatórios de SOC e IR, métricas de SLA, registros de testes, certificações ISO 27001 / ISO 22301 / SOC 2 Tipo II;
• Manter trust portal ou repositório seguro com documentação atualizada, reduzindo retrabalho a cada novo cliente;
• Tabletop com cenários de questionário hostil — simular due diligence rigorosa antes de tê-la em mãos.

Frente 3 — Contratos alinhados ao Art. 30

• Modelo de contrato master atualizado, com clausulado refletindo elementos do Art. 30 — descrição precisa do serviço, locais de processamento, requisitos de segurança, audit rights, cooperação com supervisores, sub-outsourcing controlado, exit strategy detalhada;
• Anexo técnico de segurança (SLA, métricas, controles obrigatórios, comunicação de incidentes em janelas curtas);
• Política de sub-outsourcing material — quem precisa ser disclosed, quando, com que veto do cliente;
• Playbook de negociação — quais cláusulas são deal-breakers, quais admitem variação, quais exigem alçada do board.

Frente 4 — IR comunicação e cooperação em testes

• Processo formal de comunicação rápida a clientes europeus em caso de incidente — canais primários e secundários, modelo de mensagem, autorização de envio, idiomas, fuso;
• Capacidade de cooperar com TLPT — White Team próprio, jurídico alinhado, autorização do board para inclusão em escopo;
• Programa de testes próprio incluindo cenários de ransomware, ataque de cadeia de fornecedores e comprometimento de credencial privilegiada — exatamente as ameaças que clientes europeus avaliam.

Insumos úteis em outros artigos: o guia de TPRM cobre o ângulo do programa de terceiros aplicado a serviços críticos; o artigo de board reporting traz as métricas que conversam tanto com BCB quanto com supervisores europeus; e o comparador SOC vs. MDR vs. MSSP ajuda a calibrar o nível de serviço gerenciado que sua operação precisa para sustentar SLAs DORA.

Perguntas frequentes

Conclusão

DORA não é, para a empresa brasileira média, um regulamento "que se aplica a você". É um regulamento que seus clientes europeus precisam cumprir, e que por isso recai sobre você na forma de cláusulas, questionários, prazos de notificação, evidências contínuas, cooperação em testes e — quando há escala — oversight direto. Para fintechs, processadores, SaaS de serviços financeiros, MSSPs e consultorias com ambição europeia, tratar DORA como conformidade reativa é receita para perder contratos. Tratá-lo como diferencial proativo é receita para ganhá-los.

O CISO ou líder de GRC brasileiro com olho na UE em 2026 tem três tarefas convergentes: (1) harmonizar o programa interno em volta de NIST CSF + ISO 27001 + Res. BCB nº 6 + DORA, eliminando duplicidade documental; (2) profissionalizar a função comercial-técnica de responder due diligence, com trust portal e evidências de qualidade; (3) instituir cooperação ativa com clientes europeus em incidentes e em testes, demonstrando maturidade operacional. As demais peças — detecção, resposta, criptografia, hardening, gestão de identidades — já deveriam estar no programa.

A boa notícia: investido o esforço, a empresa que se ergue a esse patamar passa a estar em posição confortável para qualquer regulação cibernética setorial que vier — UE, Reino Unido, EUA, Singapura. DORA é, no fim, uma das peças mais bem desenhadas do panorama global e tende a ser referência para iniciativas equivalentes ao longo da década.

Referências

• União Europeia. Regulation (EU) 2022/2554 — Digital Operational Resilience Act (DORA). EUR-Lex. Disponível em: eur-lex.europa.eu/eli/reg/2022/2554/oj.
• European Banking Authority (EBA), ESMA e EIOPA. Joint Committee — DORA Regulatory Technical Standards (RTS) e ITS. Disponível em: eba.europa.eu/regulation-and-policy/operational-resilience.
• European Central Bank. TIBER-EU Framework — How to implement the European framework for Threat Intelligence-based Ethical Red Teaming. Disponível em: ecb.europa.eu/paym/cyber-resilience/tiber-eu.
• European Commission. Digital finance package — Digital Operational Resilience for the financial sector. Disponível em: finance.ec.europa.eu/.../digital-operational-resilience-act.
• Banco Central do Brasil. Resolução BCB nº 6 e regulação correlata de resiliência operacional cibernética. Disponível em: bcb.gov.br.
• European Union Agency for Cybersecurity (ENISA). Publications and Threat Landscape Reports. Disponível em: enisa.europa.eu/publications.