DORA (Regulamento UE 2022/2554): guia de resiliência operacional digital para empresas brasileiras que operam ou atendem a UE

O que é o DORA e por que ele alcança empresas fora da UE

O Digital Operational Resilience Act é o Regulamento (UE) 2022/2554 do Parlamento Europeu e do Conselho, complementado pela Diretiva (UE) 2022/2556. Por ser um regulamento, e não uma diretiva, ele tem aplicabilidade direta em todos os Estados-Membros, sem depender de lei nacional de transposição. Foi publicado em dezembro de 2022, com data de aplicação fixada em 17 de janeiro de 2025. O objetivo declarado é consolidar e harmonizar, sob um único regime, as exigências de resiliência operacional digital que antes estavam dispersas em normas setoriais europeias.

A lógica do DORA parte de uma constatação simples: a estabilidade do sistema financeiro europeu depende cada vez mais da continuidade de sistemas de TIC, muitos deles operados por terceiros. Em vez de tratar segurança da informação como um anexo de governança, o regulamento eleva a resiliência operacional digital a requisito prudencial, com obrigações de board, métricas, testes e reporte. Resiliência, no vocabulário do DORA, é a capacidade de prevenir, resistir, conter e recuperar-se de incidentes relacionados a TIC, preservando a integridade e a continuidade das funções críticas.

O alcance extraterritorial não decorre de uma cláusula explícita como a do RGPD, mas da arquitetura de risco de terceiros. As entidades financeiras europeias passam a ser legalmente responsáveis por garantir que seus prestadores de serviços de TIC, onde quer que estejam, cumpram requisitos contratuais mínimos, permitam auditoria e acesso, e suportem testes. Para uma fintech, VASP ou SaaS brasileiro que vende para um banco, uma seguradora ou um CASP regulado na UE, isso significa que o DORA chega por via contratual, mesmo sem a empresa estar fisicamente ou juridicamente na União.

A quem o DORA se aplica: entidades financeiras e prestadores de TIC

O Artigo 2.º do regulamento lista o universo de destinatários. São cerca de vinte categorias de entidades financeiras, entre elas instituições de crédito, instituições de pagamento e de moeda eletrónica, empresas de investimento, seguradoras e resseguradoras, gestoras de fundos, agências de notação de crédito, infraestruturas de mercado e, por força do Regulamento MiCA (UE 2023/1114), os prestadores de serviços de criptoativos (CASP) e emitentes de tokens referenciados a ativos. Empresas brasileiras de cripto que pretendam atuar como CASP autorizado na UE entram diretamente nesse perímetro.

Ao lado das entidades financeiras, o DORA introduz uma categoria própria: os prestadores terceiros de serviços de TIC (ICT third-party service providers). A definição é ampla e cobre serviços digitais e de dados prestados de forma continuada, incluindo computação em nuvem, software, processamento de dados, data centers e serviços de segurança gerida. Esses prestadores não recebem obrigações diretas no caso geral, mas tornam-se objeto das exigências de gestão de risco de terceiros impostas às entidades financeiras, e devem aceitar cláusulas contratuais específicas.

Há, porém, um regime de supervisão direta para os prestadores classificados como críticos (Critical ICT Third-Party Providers, CTPPs). A designação é feita pelas Autoridades Europeias de Supervisão (ESAs: EBA, EIOPA e ESMA) com base em critérios como número de entidades financeiras servidas, substituibilidade e importância sistémica. Designado como crítico, o prestador passa a responder a um Lead Overseer, que pode conduzir investigações, inspeções no local e emitir recomendações, com possibilidade de aplicação de penalidades periódicas até a regularização.

Para a maioria das empresas brasileiras de TIC, o cenário realista não é a designação como CTPP, mas a obrigação indireta: o cliente europeu repassará, em contrato, os deveres de subcontratação, auditoria, localização de dados, planos de saída e cooperação em testes. Recusar essas cláusulas equivale, na prática, a ficar de fora do mercado financeiro europeu.

Os cinco pilares do DORA

O primeiro pilar é a gestão de risco de TIC (Capítulo II, Artigos 5.º a 16.º). Exige um framework documentado, sob responsabilidade última do órgão de administração, que cubra identificação de ativos e funções críticas, proteção e prevenção, deteção, resposta e recuperação, políticas de backup e restauração, e aprendizado pós-incidente. O board não pode delegar a responsabilidade: deve aprovar a estratégia, alocar orçamento e manter conhecimento atualizado sobre os riscos de TIC.

O segundo pilar trata da gestão, classificação e reporte de incidentes (Capítulo III). As entidades devem ter um processo para detetar, registar e classificar incidentes relacionados com TIC segundo critérios harmonizados (impacto, duração, abrangência geográfica, perdas de dados, criticidade dos serviços). Incidentes graves devem ser comunicados à autoridade competente em janelas definidas pelos padrões técnicos, com notificação inicial, relatório intermédio e relatório final. Há ainda comunicação voluntária de ciberameaças significativas.

O terceiro pilar é o de testes de resiliência operacional digital (Capítulo IV). Todas as entidades devem manter um programa de testes proporcional ao risco, com avaliações de vulnerabilidade, análises de código, testes de penetração e exercícios de continuidade. As entidades significativas, identificadas pelas autoridades, devem realizar Threat-Led Penetration Testing (TLPT) ao menos a cada três anos, seguindo a metodologia europeia TIBER-EU, com testes baseados em inteligência de ameaças reais. O TLPT abrange também os prestadores de TIC que suportam funções críticas.

O quarto pilar cobre a gestão de risco de terceiros de TIC (Capítulo V), com o Artigo 28.º estabelecendo princípios gerais e o Artigo 30.º fixando o conteúdo contratual mínimo: descrição dos serviços, localização do processamento de dados, direitos de acesso e auditoria, requisitos de segurança, condições de subcontratação, estratégias de saída e cooperação com as autoridades. O quinto pilar, o mais leve, incentiva o compartilhamento voluntário de informação e inteligência sobre ciberameaças entre entidades financeiras, dentro de arranjos de confiança e em conformidade com a proteção de dados.

Prazos, padrões técnicos e cadeia normativa

A data de aplicação do DORA é 17 de janeiro de 2025, conforme o Artigo 64.º. A partir desse marco, as obrigações são exigíveis e as autoridades nacionais competentes passam a supervisionar o cumprimento. Não há período de adaptação adicional previsto no texto; entidades e prestadores deveriam ter os controlos implementados nessa data.

O regulamento é um texto de princípios, detalhado por padrões técnicos vinculativos elaborados pelas ESAs: normas técnicas de regulamentação (RTS) e normas técnicas de execução (ITS), adotadas pela Comissão Europeia como atos delegados e de execução. Esses padrões especificam, por exemplo, o conteúdo da política de gestão de risco de TIC, os critérios de classificação de incidentes, os modelos de reporte, o conteúdo do Register of Information e a metodologia de TLPT. Acompanhar essa camada é essencial, porque é nela que se encontram os requisitos concretos e auditáveis.

Um elemento operacional relevante é o Register of Information: cada entidade financeira deve manter e reportar às autoridades um registo estruturado de todos os acordos contratuais com prestadores de TIC, distinguindo os que suportam funções críticas ou importantes. Esse registo alimenta a designação de prestadores críticos e a supervisão sistémica. Na prática, um fornecedor brasileiro será inventariado nesse registo do cliente europeu, com nível de criticidade atribuído.

Como uma empresa brasileira se posiciona: regulado, prestador ou subcontratado

Antes de adequar-se, a empresa precisa entender qual papel ocupa. Se for uma fintech ou um VASP que busca autorização para operar como entidade financeira na UE, será destinatária direta do DORA e responderá pelos cinco pilares por inteiro. Se for um SaaS, provedor de nuvem, segurança gerida ou processamento que apenas vende para entidades financeiras europeias, será prestador terceiro de TIC, alcançada pelas obrigações contratuais e de auditoria que o cliente lhe repassa.

O ponto mais sensível é a função crítica ou importante. Se o seu serviço sustenta uma função que, em caso de falha, comprometeria a continuidade ou a conformidade da entidade financeira, o contrato terá o conjunto completo de exigências do Artigo 30.º, e há probabilidade de o cliente exigir participação em TLPT e em testes de continuidade. Serviços não críticos enfrentam um conjunto contratual reduzido, mas ainda assim formalizado. Identificar essa classificação cedo evita surpresas comerciais.

Para a maioria dos prestadores brasileiros, a estratégia eficaz é antecipar-se: estruturar a postura de segurança e a documentação de forma que as cláusulas DORA já tenham respaldo operacional. Isso transforma a conformidade de obstáculo comercial em diferencial competitivo, encurtando o ciclo de due diligence e onboarding com clientes europeus. É exatamente nesse ponto que a abordagem de Segurança Normativa da Decripte se aplica: traduzir requisitos regulatórios em controlos verificáveis e evidências auditáveis.

Onde a Decripte atua na adequação ao DORA

A Decripte apoia empresas brasileiras nos quatro pilares mais demandantes do DORA com serviços técnicos diretos. Na gestão de risco de TIC, conduzimos identificação de ativos e funções críticas, avaliação de riscos e desenho de controlos alinhados ao Capítulo II e às RTS aplicáveis, com a documentação que o board precisa para assumir a responsabilidade prevista no regulamento.

Em testes de resiliência, executamos avaliações de vulnerabilidade e pentest convencional e, para os casos sujeitos a Threat-Led Penetration Testing, conduzimos exercícios baseados em inteligência de ameaças alinhados à lógica do TIBER-EU, na posição de prestador de testes que a entidade financeira europeia pode contratar. Em resposta a incidentes, ajudamos a montar o processo de deteção, classificação e reporte exigido pelo Capítulo III, com playbooks compatíveis com as janelas de notificação e com os modelos de relatório das ESAs.

Na gestão de risco de terceiros, atuamos do lado do prestador brasileiro: revisamos a aderência da postura de segurança às cláusulas do Artigo 30.º, preparamos a empresa para auditorias e direitos de acesso do cliente, e organizamos a documentação que alimenta o Register of Information do contratante europeu. O objetivo é que a sua empresa chegue à mesa de negociação com a conformidade pronta, em vez de reativa.

Como se adequar

1. 1

   Determine seu papel e escopo

   Defina se a empresa é entidade financeira sujeita ao DORA, prestador terceiro de TIC ou subcontratado de um prestador. Mapeie quais clientes europeus são entidades financeiras e quais dos seus serviços sustentam funções críticas ou importantes para eles. Esse enquadramento determina a profundidade de toda a adequação.

2. 2

   Mapeie ativos, funções críticas e dependências

   Construa um inventário de ativos de TIC, fluxos de dados, subcontratados e dependências que suportam os serviços vendidos a clientes europeus. Identifique pontos únicos de falha e a localização do processamento e armazenamento de dados, informação que o cliente precisará para o Register of Information dele.

3. 3

   Estruture o framework de gestão de risco de TIC

   Implemente políticas e controlos cobrindo identificação, proteção, deteção, resposta, recuperação e backup, com aprovação e supervisão do órgão de administração. Alinhe ao Capítulo II do DORA e às RTS, e produza evidências auditáveis: políticas versionadas, registos de risco e métricas.

4. 4

   Monte o processo de gestão e reporte de incidentes

   Defina deteção, registo e classificação de incidentes segundo os critérios harmonizados (impacto, duração, abrangência, perda de dados). Crie playbooks que permitam apoiar o cliente europeu nas notificações inicial, intermédia e final, dentro das janelas dos padrões técnicos, e estabeleça canais de comunicação contratualmente acordados.

5. 5

   Prepare-se para testes e TLPT

   Estabeleça um programa contínuo de avaliação de vulnerabilidades e pentest. Para serviços que sustentam funções críticas, prepare a empresa para participar de Threat-Led Penetration Testing conduzido sob a metodologia TIBER-EU, garantindo ambientes, escopo e cláusulas que autorizem o teste sem violar outros compromissos.

6. 6

   Ajuste contratos ao Artigo 30.º

   Reveja os contratos com clientes financeiros europeus para acomodar direitos de acesso e auditoria, requisitos de segurança, regras de subcontratação, localização de dados, estratégias de saída e cooperação com autoridades. Negocie condições viáveis antes que o cliente imponha um modelo unilateral.

7. 7

   Consolide governança e evidências contínuas

   Centralize a documentação de conformidade, mantenha o registo de subcontratados atualizado e estabeleça revisões periódicas e pós-incidente. Trate a conformidade como diferencial comercial: um pacote de evidências pronto encurta a due diligence do cliente europeu e sustenta renovações.

Perguntas frequentes