- DORA se aplica a 20 categorias de entidades financeiras e está em vigor desde 17 de janeiro de 2025. Não há período de carência.
- Uma análise de lacunas deve cobrir todos os cinco pilares: gestão de riscos ICT, notificação de incidentes, testes de resiliência, risco de terceiros e compartilhamento de informações
- Incidentes ICT graves devem ser notificados em 4 horas após a classificação, com relatório final em até um mês
- O Registro de Informações (ROI) para contratos ICT com terceiros é um dos requisitos operacionais mais exigentes. Reserve tempo no seu plano.
- TLPT (testes de penetração baseados em ameaças) se aplica apenas a entidades identificadas como significativas pela autoridade competente, mas testes básicos se aplicam a todos
Comece com uma análise de lacunas, não com um programa
Seu instinto pode ser iniciar a conformidade com a DORA redigindo políticas. Essa abordagem coloca as saídas antes das entradas. A análise de lacunas vem primeiro: ela identifica onde você está exposto, o que suas políticas não conseguem revelar.
Os cinco pilares da DORA criam requisitos em gestão de riscos ICT, notificação de incidentes, testes operacionais, risco de terceiros e compartilhamento de informações. A maioria das FinTechs tem controles parciais em algumas dessas áreas e nada em outras. A análise de lacunas mapeia o que existe, pontua isso em relação aos requisitos da DORA e produz uma lista priorizada de ações. Sem ela, você constrói programas baseados em suposições e descobre as lacunas quando um regulador perguntar.
Antes da análise: confirme seu escopo
DORA (Regulamento UE 2022/2554) se aplica a entidades financeiras que operam na UE em 20 categorias definidas. Essas incluem instituições de crédito, instituições de pagamento, empresas de investimento, seguradoras e resseguradoras, provedores de criptoativos, provedores de serviços de financiamento coletivo e provedores críticos de serviços ICT de terceiros, entre outros.
O escopo nem sempre é óbvio para FinTechs. Uma empresa que presta serviço de iniciação de pagamento é uma instituição de pagamento. Uma empresa que incorpora produtos de seguro em uma plataforma pode ser uma entidade distribuidora de seguros. Um provedor de carteira de criptoativos é um prestador de serviços de criptoativos sob a MiCA, o que o traz para o escopo da DORA. Confirme sua classificação com seu consultor jurídico antes de conduzir uma análise de lacunas. A classificação determina quais obrigações se aplicam e em qual nível de detalhe.
A DORA aplica um princípio de proporcionalidade. Microempresas (menos de 10 funcionários, faturamento anual abaixo de €2 milhões) se qualificam para um regime simplificado em vários pilares. Se sua organização está próxima desse limite, confirme se o regime simplificado ou o regime completo se aplica a você.
Se você fornece serviços ICT a entidades financeiras e as Autoridades Supervisoras Europeias (ESAs) o designarem como crítico, você fica sujeito diretamente ao framework de supervisão da DORA. As ESAs publicaram a primeira lista de provedores críticos de serviços ICT de terceiros designados em 2025. Provedores de nuvem, plataformas de análise de dados e provedores de infraestrutura bancária principal são as categorias com maior probabilidade de inclusão.
A DORA exige que toda entidade financeira em escopo mantenha um framework documentado de gestão de riscos ICT cobrindo o ciclo de vida completo do risco: identificação, proteção, detecção, resposta e recuperação. O framework deve ser aprovado pelo órgão de gestão e revisado pelo menos anualmente.
Ao avaliar sua lacuna neste pilar, percorra as seguintes perguntas:
- Existe um framework documentado de gestão de riscos ICT, ou seus controles são informais? A DORA exige que o framework seja escrito, aprovado pelo conselho e versionado.
- Ele cobre as cinco funções? Identificação (inventário de ativos, mapeamento de funções críticas), proteção (controles de acesso, gestão de patches), detecção (registro de logs, monitoramento), resposta (procedimentos de tratamento de incidentes) e recuperação (procedimentos de backup e restauração, metas de RTO/RPO).
- Seu conselho o aprovou? O Artigo 5 da DORA coloca o framework de gestão de riscos ICT diretamente na agenda do órgão de gestão. Se seu conselho não aprovou explicitamente o framework, isso é uma lacuna independentemente de quão bem escrito o documento esteja.
- Seu inventário de ativos está completo? Você não pode proteger o que não catalogou. Mapeie todos os ativos ICT que suportam funções críticas ou importantes, incluindo os hospedados por terceiros.
- Seus planos de continuidade de negócios e recuperação refletem a infraestrutura atual? Planos que referenciam sistemas obsoletos ou procedimentos de restauração não testados não satisfarão uma auditoria.
A lacuna mais comum neste pilar não é a ausência de controles, mas a ausência de documentação. A maioria das FinTechs tem engenheiros que sabem como os sistemas funcionam; poucas têm frameworks escritos que um regulador possa ler e avaliar.
A DORA estabelece prazos obrigatórios de notificação para incidentes ICT graves. Um incidente se qualifica como grave quando atende a um ou mais limites de materialidade:
Uma vez que um incidente é classificado como grave, três prazos de notificação correm a partir dessa classificação:
- 4 horas: notificação inicial à autoridade competente, cobrindo a natureza do incidente, seu impacto e as medidas de contenção tomadas.
- 72 horas: relatório intermediário com avaliação mais completa de causa, abrangência do impacto e status de remediação.
- 1 mês: relatório final com análise de causa raiz, ações corretivas e quaisquer efeitos transfronteiriços.
Ao auditar sua lacuna aqui, verifique se seus runbooks de resposta a incidentes incluem uma etapa de classificação em relação aos limites de materialidade da DORA e um responsável nomeado pela notificação regulatória. A maioria dos processos de resposta a incidentes de FinTechs para na contenção. A obrigação de notificação começa na classificação, não na resolução.
O prazo de 4 horas começa quando você classifica um incidente como grave, não quando o incidente começou. Se seu processo de classificação leva 6 horas, você já está fora do prazo. Incorpore a decisão de classificação na primeira hora da sua resposta a incidentes.
A DORA exige que todas as entidades em escopo executem um programa de testes de resiliência operacional. Os requisitos se dividem por tamanho e significância da entidade.
Todas as entidades em escopo devem conduzir avaliações de vulnerabilidade, testes baseados em cenários e avaliações de segurança de rede pelo menos anualmente. Esses cobrem ferramentas e sistemas ICT que suportam funções críticas ou importantes, não todo o patrimônio tecnológico.
Entidades significativas (aquelas identificadas pelas autoridades competentes com base nos critérios estabelecidos nas Normas Técnicas Regulatórias de TLPT, Regulamento Delegado da Comissão UE 2025/1190, aplicável a partir de julho de 2025) devem adicionalmente conduzir Testes de Penetração Baseados em Ameaças (TLPT) pelo menos a cada três anos. O TLPT segue o framework TIBER-EU e exige um provedor independente de inteligência de ameaças e um provedor separado de red team. Os resultados são reportados à autoridade competente com um certificado de conclusão.
Para sua avaliação de lacunas neste pilar:
- Liste quais testes sua organização conduziu nos últimos 12 meses e contra quais sistemas.
- Verifique se o escopo cobriu especificamente os serviços ICT que suportam funções críticas ou importantes, não apenas ativos de perímetro.
- Se sua autoridade competente informou que você se qualifica para TLPT, confirme a data do seu último teste e quando cai o próximo ciclo de três anos.
- Revise se os resultados dos testes estão documentados, se as ações de remediação são rastreadas e se os resultados são reportados ao órgão de gestão.
A maioria das FinTechs tem sua maior lacuna DORA no risco de terceiros. Os requisitos da DORA vão muito além de um questionário de fornecedores.
O elemento central é o Registro de Informações (ROI), exigido pelo Artigo 28(3). O ROI é um inventário estruturado de todo acordo contratual que sua organização tem com prestadores de serviços ICT de terceiros. Deve distinguir entre acordos que suportam funções críticas ou importantes e aqueles que suportam funções não críticas, e deve ser mantido nos níveis de entidade, subconsolidado e consolidado. O ROI é enviado às autoridades competentes anualmente, com o ciclo de 2026 cobrindo uma data de referência de 31 de dezembro de 2025.
No exercício de simulação da ESA em 2024, apenas 6,5% de quase 1.000 empresas participantes passaram em todas as 116 verificações de qualidade de dados. As falhas mais comuns foram dados contratuais incompletos, informações de subcontratados ausentes e classificações incorretas no Framework de Informações Comuns (CIF). Se você ainda não começou a construir seu ROI, comece agora.
Além do ROI, sua avaliação de lacunas neste pilar deve cobrir:
- Diligência prévia. Você conduz avaliações de risco documentadas antes de contratar prestadores de serviços ICT que suportam funções críticas? A DORA exige diligência prévia pré-contratual, não apenas revisões anuais.
- Termos contratuais. Seus contratos ICT com provedores de funções críticas ou importantes incluem as disposições obrigatórias do Artigo 30 da DORA? Essas incluem: descrições claras de serviços e SLAs, requisitos de segurança, direitos de auditoria, obrigações de notificação de incidentes e disposições de saída.
- Subcontratados. Você sabe a quem seus provedores críticos subcontratam? A DORA exige que você rastreie cadeias de subcontratação material, não apenas relacionamentos diretos com fornecedores.
- Risco de concentração. Você tem múltiplas funções críticas dependentes de um único provedor? A DORA espera que as entidades identifiquem e gerenciem o risco de concentração ICT tanto no nível da empresa quanto do setor.
O quinto pilar da DORA permite que entidades financeiras participem de acordos de compartilhamento de informações sobre ciberameaças, inteligência de ameaças e indicadores de ataque. A participação é voluntária e exige que os acordos de compartilhamento cumpram obrigações de proteção de dados e não violem legislação de concorrência.
Para a maioria das FinTechs na fase de análise de lacunas, este pilar tem menor prioridade do que os quatro primeiros. A lacuna a avaliar aqui é simplesmente se sua organização tem uma posição sobre compartilhamento de informações, conhece os fóruns existentes no seu setor e considerou os parâmetros de confidencialidade e legais da participação.
Construindo o roteiro de remediação
Uma análise de lacunas produz uma lista de achados em cinco pilares. Transformar essa lista em um roteiro exige três coisas: uma classificação de gravidade para cada lacuna, uma estimativa realista de esforço e uma lógica de sequenciamento.
Use esta abordagem de sequenciamento:
- Corrija primeiro a exposição regulatória. Lacunas nos procedimentos de notificação de incidentes e no ROI carregam o maior risco imediato de aplicação. Leve-os a um estado defensável antes de refinar seu framework de gestão de riscos ICT.
- Documente o que já funciona. A maioria das FinTechs tem controles que existem mas não estão escritos. Converter prática informal em política documentada é mais rápido do que construir novos controles e reduz a contagem de lacunas.
- Inicie o trabalho de terceiros cedo. Renegociar contratos de fornecedores e construir seu ROI exigem tempo de antecedência que você não controla. Inicie essas frentes de trabalho em paralelo com seu trabalho interno de políticas, não depois dele.
- Alinhe os testes ao seu próximo ciclo. Se seu teste de penetração anual está previsto para daqui a três meses, planeje a remediação das lacunas de testes para alimentar esse ciclo em vez de agendar uma avaliação separada.
O roteiro deve nomear responsáveis para cada ação, ter uma data de conclusão e ser revisado pelo órgão de gestão. As obrigações do órgão de gestão da DORA significam que seu conselho precisa ver este documento e aprovar formalmente o plano de remediação, não apenas receber um resumo.
Os reguladores trataram 2025 como um ano de transição, revisando frameworks e definindo expectativas em vez de buscar sanções imediatas. Esse período está se encerrando. Organizações que chegam a uma revisão regulatória com uma análise de lacunas concluída e um roteiro aprovado pelo conselho estão em posição materialmente melhor do que aquelas que apresentam trabalho em andamento.