Regulamento e normas técnicas: o que está onde
O regulamento em si estabelece os princípios. Os detalhes estão em normas técnicas de regulamentação e de execução, elaboradas pelas Autoridades Europeias de Supervisão e adotadas pela Comissão Europeia. Quem implementa o DORA trabalha, por isso, sempre com vários textos em paralelo. Os mais importantes tratam da estrutura de gestão do risco de TIC e de sua variante simplificada, da classificação de incidentes e ameaças cibernéticas, do conteúdo, formato e prazos das notificações de incidentes, dos testes de penetração baseados em ameaças, dos modelos do registro de informações, da política para serviços de TIC que apoiam funções críticas ou importantes e da subcontratação.
Na prática, isso significa: o regulamento diz que você precisa classificar um incidente. Só a norma traz os critérios, como clientes afetados, duração, abrangência geográfica, perda de dados e impacto econômico, e define a partir de quando um incidente é considerado grave. O mesmo vale para o registro: os campos que ele tem e a forma como está estruturado resultam dos modelos da norma técnica de execução.
Somam-se a isso as orientações e as perguntas e respostas das Autoridades Europeias de Supervisão, além de publicações da BaFin, por exemplo sobre canais de notificação e janelas de envio. Esses textos mudam com mais frequência do que o regulamento. No Sightadel, cada controle está vinculado ao artigo a que se refere. Quando uma norma define detalhes, o controle indica a evidência esperada. Em caso de dúvida, confirme a versão aplicável com a autoridade de supervisão.
O registro de informações na prática
O registro é a parte do DORA que a maioria das empresas subestimou. Ele não exige simplesmente uma lista de contratos, mas um inventário estruturado: qual serviço de TIC a empresa contrata de quem, com base em qual contrato, para qual função, se essa função é crítica ou importante, onde os dados são tratados, quão fácil seria substituir o prestador e quais subcontratados estão por trás na cadeia. O registro é mantido no nível da entidade individual e, no caso de grupos, de forma consolidada.
A BaFin solicita o registro uma vez por ano, com referência a uma data fixa. O envio é feito pela plataforma de reporte e publicação da BaFin, dentro de uma janela de tempo definida. Para o reporte de 2026, essa janela foi em março. Um registro só é considerado enviado quando cumpre as regras de validação das Autoridades Europeias de Supervisão. Identificadores de prestadores faltantes ou dados contraditórios sobre funções levam à rejeição. As Autoridades Europeias de Supervisão também usam os registros para designar os prestadores terceirizados críticos de serviços de TIC sujeitos à supervisão direta da UE.
O verdadeiro trabalho não está no preenchimento, mas na coleta. Os dados estão espalhados por contratos, compras, TI e áreas de negócio. Quem só atualiza o registro para a data de referência recomeça a busca todo ano. Por isso, o Sightadel parte do módulo Fornecedores: cada prestador é mantido com contrato, funções apoiadas, criticidade, locais e evidências assim que é contratado. Novos contratos, rescisões e mudanças de subcontratados entram ali no dia a dia, e não só na primavera.
Custos e esforço interno
O DORA custa sobretudo tempo de pessoas que já estão sobrecarregadas: segurança da informação, gestão de continuidade, compras, jurídico, auditoria interna e diretoria. A licença do Sightadel para o DORA é cobrada mensalmente por edição, com descontos para vários frameworks e pagamento antecipado. Todos os preços e uma calculadora estão na nossa página de preços.
Os custos externos surgem em outro lugar e são cobrados diretamente pelos respectivos fornecedores. Pela experiência, os maiores fatores são três. Primeiro, as alterações contratuais com os prestadores, muitas vezes com acompanhamento jurídico. Segundo, o programa de testes, sobretudo se você for designado para TLPT: um teste baseado em ameaças, com análise de ameaças, red team e trabalho de encerramento, é um projeto de vários meses. Terceiro, a coleta de dados para o registro quando o acervo de contratos está incompleto.
Onde dá para economizar: quem opera um SGSI segundo a ISO 27001 não precisa reinventar a gestão de riscos, o controle de acesso, os backups e a gestão de incidentes. No Sightadel, as evidências existentes ficam vinculadas aos dois frameworks. Não indicamos de propósito um valor para a sobreposição, porque ele depende do escopo. A consultoria para as partes difíceis, como a definição das funções críticas ou importantes, pode ser contratada como pacote no aplicativo, se necessário.
Responsabilidade da diretoria, sanções e responsabilidade civil
O DORA coloca expressamente a responsabilidade pelo risco de TIC nas mãos do órgão de administração. Ele define e aprova a estrutura, estabelece as funções, determina o apetite a risco de TIC, aprova as políticas de continuidade de negócios e de terceiros, disponibiliza o orçamento e se capacita regularmente. É possível delegar o trabalho, não a responsabilidade. Por isso, nas auditorias se pergunta o que a diretoria decidiu, como ela é informada e quais treinamentos seus membros comprovadamente concluíram.
Na Alemanha, as infrações são punidas pela BaFin com base no direito nacional de supervisão, adaptado para aplicar as regras sancionatórias do DORA. São possíveis determinações, multas e, em caso de deficiências graves, outras medidas de supervisão. Os prestadores terceirizados críticos de serviços de TIC estão sujeitos à supervisão direta de uma autoridade supervisora principal europeia, que emite recomendações e pode aplicar multas coercitivas periódicas calculadas com base no faturamento diário mundial.
Além da supervisão, conta o lado civil. Uma falha de um prestador sem plano, uma notificação atrasada ou um backup não testado podem levantar questões de indenização perante clientes e de responsabilidade da diretoria. A avaliação de cada caso concreto deve ser feita com a sua assessoria jurídica. O Sightadel não presta assessoria jurídica, mas garante que deliberações, treinamentos e decisões fiquem documentados com data e responsável.
Qual documentação a autoridade de supervisão espera
O regulamento não define uma lista exaustiva, mas do regulamento e das normas resulta um núcleo claro. Ele inclui a estrutura de gestão do risco de TIC documentada, com a estratégia de resiliência operacional digital, políticas de segurança da informação, de controle de acesso, de gestão de mudanças e de gestão de vulnerabilidades, uma política de continuidade de negócios de TIC com planos de resposta e recuperação, políticas de backup com evidências de recuperação testada, um processo de gestão de incidentes com critérios de classificação e registro de incidentes, o programa de testes com resultados, a estratégia para o risco de terceiros de TIC, o registro de informações e estratégias de saída para prestadores que apoiam funções críticas ou importantes.
A estrutura deve ser revisada pelo menos uma vez por ano e, além disso, após incidentes graves e após constatações de testes ou auditorias. Sobre essa revisão é elaborado um relatório que a autoridade pode solicitar. Igualmente importantes são as evidências de que os documentos são aplicados: aprovações, comprovantes de treinamento, registros de testes de recuperação, constatações de testes e auditorias tratadas.
No Sightadel, cada um desses documentos está vinculado a um controle, com versão, aprovação e data de validade. Quando uma evidência vence, como um teste anual de recuperação, ela aparece no painel como ponto em aberto. Assim, o status não fica completo só na data da auditoria.
Planejar corretamente o programa de testes e o TLPT
Todas as entidades financeiras que não se enquadram na estrutura simplificada precisam de um programa de testes de resiliência operacional digital baseado em risco. Dependendo do contexto, ele inclui avaliações e varreduras de vulnerabilidades, revisões de código-fonte, testes baseados em cenários, testes de compatibilidade e de desempenho, testes de ponta a ponta e testes de penetração. Os sistemas que apoiam funções críticas ou importantes são testados de forma adequada pelo menos uma vez por ano. Os testadores precisam ser independentes, internos ou externos.
Os testes de penetração baseados em ameaças, abreviados como TLPT, se aplicam apenas às entidades designadas para isso pela autoridade de supervisão e, nesse caso, costumam ser realizados a cada três anos. Eles seguem uma norma técnica própria, inspirada na estrutura europeia TIBER. Um TLPT acontece em sistemas de produção e inclui uma análise de ameaças, um ataque encoberto por um red team e uma análise conjunta posterior. A autoridade acompanha o teste e, no final, confirma sua realização.
Muitas vezes se subestima o tempo depois do teste. As constatações precisam ser avaliadas, priorizadas e tratadas com prazos, e a autoridade quer ver o progresso. No Sightadel, cada constatação vira um problema com responsável e prazo. O teste em si é realizado por testadores especializados; o Sightadel registra o planejamento, o resultado e o tratamento.
Integração com a NIS2, a ISO 27001 e as antigas regras da BaFin
Para as entidades financeiras, o DORA é o regime especial em relação à NIS2. As obrigações de cibersegurança são cumpridas pelo DORA, não em duplicidade. Em grupos com empresas fora do setor financeiro, os dois regimes podem valer lado a lado. Nesse caso, vale a pena manter medidas e evidências uma única vez e vinculá-las aos dois.
As antigas circulares de TI da BaFin para bancos, seguradoras, gestoras de fundos e instituições de pagamento foram substituídas pelo regulamento para as entidades abrangidas pelo DORA. A BaFin publicou orientações sobre como as regras existentes, por exemplo sobre a gestão de terceirização fora da TI, se relacionam com o DORA. Antes da análise de lacunas, deve estar claro quais partes continuam valendo na sua organização.
A ISO 27001 não é obrigatória, mas é uma estrutura comprovada. Um certificado mostra que está em funcionamento um sistema de gestão que dá suporte ao DORA em grande parte. O que o DORA exige a mais é, sobretudo, o registro, os prazos de notificação, o conteúdo dos contratos e o programa de testes. Relatórios de asseguração como o BSI C5 ou o SOC 2 dos seus prestadores são evidências valiosas na avaliação deles, mas não substituem a sua própria avaliação de riscos.
