Regulamento da UE · Resiliência digital no setor financeiro
O Sightadel guia-o pelos requisitos do Regulamento DORA – da gestão do risco de TIC à notificação de incidentes graves e ao registo de informações. Com modelos setoriais baseados em muitos anos de prática de consultoria, uma IA que ajuda na redação e consultores reais para as partes difíceis.
Do que se trata
O Regulamento relativo à resiliência operacional digital do setor financeiro (Digital Operational Resilience Act, DORA) é um regulamento da UE e aplica-se diretamente desde 17 de janeiro de 2025, sem lei nacional de transposição. Exige que as entidades financeiras consigam resistir a perturbações graves de TIC, detetá-las, notificá-las e recuperar delas – e que o possam demonstrar a qualquer momento. Na Alemanha, a supervisão cabe à autoridade federal alemã de supervisão financeira (BaFin).
O regulamento assenta em cinco pilares: gestão do risco de TIC com responsabilidade clara do órgão de administração, gestão e notificação de incidentes relacionados com as TIC, testes de resiliência operacional digital, gestão do risco de terceiros no domínio das TIC, incluindo o registo de informações, e partilha voluntária de informações sobre ciberameaças. Normas técnicas das Autoridades Europeias de Supervisão concretizam muitos pormenores.
Para as entidades financeiras, o DORA é o regime especial face à NIS2. Os conteúdos sobrepõem-se fortemente a um SGSI segundo a ISO 27001. O que aí falta é sobretudo o registo de informações, a classificação própria de incidentes com os respetivos prazos de notificação e as regras para os contratos com prestadores de serviços de TIC.
Saiba mais sobre o software adequado: Software DORA, com funcionalidades, implementação e preços.
As bases estão criadas, mas o registo, a classificação de incidentes ou o programa de testes ainda são folhas de cálculo e intenções. A supervisão pede agora evidências, não planos.
O DORA aplica-se segundo o princípio da proporcionalidade. Para determinadas empresas de menor dimensão existe um quadro simplificado – mas continua a precisar das evidências.
Não está sujeito a supervisão, mas os seus clientes têm de o incluir no registo de informações, acordar cláusulas contratuais e avaliá-lo. Os requisitos chegam-lhe através do contrato.
Programa de testes segundo os art. 24.º–25.º
O DORA exige de todas as entidades financeiras um programa de testes baseado no risco, incluindo avaliações de vulnerabilidades, análises e testes de penetração. Em conjunto com a veyrisk, oferecemos os testes necessários. O planeamento, os resultados e o tratamento das constatações ficam registados no Sightadel. Os testes de penetração baseados em ameaças (TLPT) previstos no art. 26.º não estão abrangidos.
Entidades financeiras que estão a criar ou a completar o seu programa de testes segundo o DORA
O âmbito e a periodicidade dos testes dependem da sua avaliação de riscos. Recebe a proposta após uma breve conversa.
Pedir testesRequisitos
Resumido por palavras nossas. Prevalece sempre o texto original na versão em vigor.
O órgão de administração é responsável pelo risco de TIC, aprova o quadro, mantém os seus conhecimentos atualizados e disponibiliza recursos. O quadro está documentado e é revisto regularmente.
No SightadelPerguntas orientadoras sobre funções, estratégia e aprovação. O modelo fornece um rascunho do quadro; a apetência pelo risco e os responsáveis são definidos por si. As formações da administração são registadas com data de validade.
Conhecer as funções críticas, os ativos de TIC e as dependências, aplicar medidas de proteção como o controlo de acessos e a gestão de alterações e detetar anomalias atempadamente.
No SightadelPerguntas guiadas por requisito com opções de resposta, ligação a evidências e comentário. As evidências da ISO 27001 podem ser reutilizadas diretamente.
Planos de resposta e recuperação de TIC, políticas de cópias de segurança e recuperação testada.
No SightadelTestes de recuperação como ciclo recorrente com registo. Quando uma evidência de teste expira, aparece no painel antes de a auditoria interna a encontrar.
Registar os incidentes relacionados com as TIC, classificá-los segundo critérios uniformes e reconhecer como tal os incidentes graves.
No SightadelControlos sobre processo, funções, critérios de classificação e registo de incidentes. Os critérios ficam documentados de antemão, e não só quando o incidente acontece.
Notificação inicial à autoridade poucas horas depois da classificação como grave e, no máximo, 24 horas após o conhecimento do incidente; depois, relatório intercalar e relatório final.
No SightadelOs canais de notificação, os responsáveis e os substitutos ficam registados; as diferenças em relação à NIS2 quanto ao início da contagem dos prazos estão claramente separadas.
Um programa de testes baseado no risco para todos. As entidades designadas pela autoridade realizam adicionalmente, pelo menos de três em três anos, testes de penetração baseados em ameaças (TLPT).
No SightadelPrograma de testes como ciclo; as constatações tornam-se problemas com prazo e responsável. O TLPT propriamente dito é realizado por testadores especializados; o Sightadel regista o planeamento, o resultado e o tratamento.
Uma estratégia para o risco de terceiros, avaliação antes da celebração do contrato, estratégias de saída e um registo de informações completo de todos os contratos de TIC, a apresentar à autoridade.
No SightadelNo módulo Fornecedores regista os prestadores, as funções apoiadas, a criticidade e as evidências com data de validade. O registo cresce com a manutenção contínua, e não com uma recolha à pressa antes da data de referência.
Os contratos incluem conteúdos mínimos, como a descrição dos serviços, os locais de tratamento dos dados, direitos de auditoria e de acesso, direitos de rescisão e apoio em caso de incidentes.
No SightadelControlos por conteúdo contratual, ligados ao prestador. As cláusulas em falta tornam-se pontos de ação para a próxima ronda contratual.
As entidades financeiras podem partilhar informações sobre ameaças em comunidades de confiança e comunicam a sua participação à autoridade.
No SightadelA participação, as regras e a comunicação à autoridade ficam arquivadas como evidência.
Processo
Seis a doze meses para colmatar as lacunas existentes. Quem tem um SGSI em funcionamento avança mais depressa. O registo de informações e as alterações contratuais determinam normalmente o ritmo.
Esclarecer que obrigações se aplicam, se o quadro simplificado é uma opção e que funções são críticas ou importantes.
Percorrer os 50 requisitos de forma guiada e associar as evidências existentes do SGSI, da gestão da continuidade e das compras.
Registar prestadores, contratos, funções apoiadas e subcontratantes. Por experiência, é a parte mais trabalhosa, porque os dados não constam completos em nenhuma pasta de contratos.
Definir critérios de classificação, responsabilidades e canais de notificação e simular o processo uma vez.
Planos de ação com responsáveis e prazos. As alterações contratuais costumam ser o que demora mais, porque a outra parte tem de colaborar.
Executar o programa de testes, rever o quadro, manter o registo atualizado. Depois, estes passos repetem-se em ciclo.
Pronto para começar
Quem esclarece estas questões cedo poupa semanas mais tarde. No Sightadel estão configuradas como as primeiras tarefas.
Divisão de tarefas
Se um software preenchesse tudo, a norma não cumpriria o seu objetivo – e o auditor notaria. Por isso está claramente definido o que fica a seu cargo.
Da prática
Da longa experiência em consultoria e certificação: estes são os pontos que mais tempo consomem ou que levam a não conformidades na auditoria.
Quem só preenche o registo de informações antes da submissão anual volta a procurar os mesmos dados todos os anos. Mantenha prestadores e contratos de forma contínua, logo que são contratados ou alterados.
Se quase todas as funções forem críticas, a classificação perde valor. Se forem poucas demais, faltam contratos e testes. Derive a classificação de uma análise de impacto no negócio compreensível e submeta-a à aprovação da administração.
Sob pressão de tempo, um incidente é reconhecido tarde demais como grave e o prazo de notificação expira. Defina de antemão critérios, limiares, responsáveis e substitutos e simule o processo pelo menos uma vez por ano.
As cláusulas obrigatórias em falta são identificadas, mas não acompanhadas. Defina por prestador quando a lacuna será colmatada, por exemplo na próxima renovação, e registe-o como tarefa com prazo.
Uma circular à administração não substitui uma deliberação. Submeta o quadro, a apetência pelo risco e as políticas a aprovação formal e documente a formação dos membros da administração.
Uma estratégia de saída que ninguém verificou não ajuda quando é preciso. Verifique, para os prestadores de funções críticas, se as alternativas, a devolução de dados e os períodos de transição são realistas, e atualize a estratégia quando os contratos mudam.
Uma evidência, vários frameworks
Não indicamos propositadamente uma percentagem – depende do seu âmbito. Onde os requisitos coincidem, uma evidência fica associada a todos.
A gestão do risco de TIC, o controlo de acessos, as cópias de segurança e a gestão de incidentes assentam nas mesmas bases. O registo de informações não tem equivalente na ISO 27001.
NIS2Para as entidades financeiras, o DORA prevalece. Muitas medidas coincidem. Os prazos de notificação diferem no ponto de partida: o DORA conta a partir da classificação, a NIS2 a partir do conhecimento do incidente.
BSI C5Um relatório de atestação C5 de um fornecedor de cloud é uma evidência valiosa na avaliação desse prestador. Não substitui a avaliação de riscos própria.
RGPDAs medidas técnicas e organizativas e os acordos de subcontratação recorrem aos mesmos dados dos prestadores. Um incidente pode desencadear várias obrigações de notificação.
Auditoria e evidências
Na Alemanha, a supervisão cabe à BaFin; os prestadores terceiros críticos de serviços de TIC são, além disso, supervisionados diretamente pelas Autoridades Europeias de Supervisão. A isto juntam-se os revisores oficiais de contas, a auditoria interna e os clientes que o avaliam como prestador. O Sightadel não certifica nem substitui a consultoria em matéria de supervisão.
Quem audita recebe no Sightadel um acesso próprio, sem permissão para apagar. O registo de atividade mostra sem lacunas quem fez o quê e quando. Como prestador, mostra aos seus clientes certificados, documentos e subcontratantes no Trust Center, em vez de responder a cada questionário individualmente. A ISO 27001 é uma base comprovada e estruturada, mas não é obrigatória. Para auditorias externas, escolha um auditor da nossa rede de parceiros independentes ou um da sua confiança. Pelas auditorias não é paga qualquer comissão – nem a nós, nem aos parceiros.
Ver a rede de auditores independentesO regulamento em si estabelece os princípios. Os pormenores constam de 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 dizem respeito ao quadro de gestão do risco de TIC e à sua variante simplificada, à classificação de incidentes e ciberameaças, ao conteúdo, formato e prazos das notificações de incidentes, aos testes de penetração baseados em ameaças, aos modelos do registo de informações, à política relativa a serviços de TIC que apoiam funções críticas ou importantes e à subcontratação.
Na prática, isto significa: o regulamento diz que tem de classificar um incidente. Só a norma indica os critérios, como os clientes afetados, a duração, a dispersão geográfica, as perdas de dados e o impacto económico, e define a partir de quando um incidente é considerado grave. O mesmo acontece com o registo: os campos que tem e a forma como está estruturado resultam dos modelos da norma técnica de execução.
A isto somam-se as orientações e as perguntas e respostas das Autoridades Europeias de Supervisão, bem como publicações da BaFin, por exemplo sobre canais de notificação e janelas de submissão. Estes textos mudam com mais frequência do que o regulamento. No Sightadel, cada controlo está ligado ao artigo a que se refere. Quando uma norma define pormenores, o controlo indica a evidência esperada. Em caso de dúvida, confirme a versão aplicável junto da autoridade de supervisão.
O registo é a parte do DORA que a maioria das empresas subestimou. Não exige simplesmente uma lista de contratos, mas um inventário estruturado: que serviço de TIC a empresa obtém de quem, com base em que contrato, para que função, se essa função é crítica ou importante, onde são tratados os dados, quão fácil seria substituir o prestador e que subcontratantes estão por trás na cadeia. O registo é mantido ao nível da entidade individual e, no caso de grupos, de forma consolidada.
A BaFin solicita o registo uma vez por ano, com referência a uma data fixa. A submissão é feita através da sua plataforma de reporte e publicação, numa janela temporal definida. Para o reporte de 2026, essa janela foi em março. Um registo só é considerado submetido quando cumpre as regras de validação das Autoridades Europeias de Supervisão. Identificadores de prestadores em falta ou dados contraditórios sobre funções levam à rejeição. As Autoridades Europeias de Supervisão utilizam também os registos para designar os prestadores terceiros críticos de serviços de TIC sujeitos à supervisão direta da UE.
O verdadeiro trabalho não está no preenchimento, mas na recolha. Os dados estão dispersos por contratos, compras, informática e áreas de negócio. Quem só atualiza o registo para a data de referência recomeça a procura todos os anos. Por isso, o Sightadel parte do módulo Fornecedores: cada prestador é mantido com contrato, funções apoiadas, criticidade, localizações e evidências logo que é contratado. Novos contratos, rescisões e alterações de subcontratantes entram aí no dia a dia, e não na primavera.
O DORA custa sobretudo tempo de pessoas que já estão sobrecarregadas: segurança da informação, gestão da continuidade, compras, jurídico, auditoria interna e administração. 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 noutro lado e são faturados diretamente pelos respetivos fornecedores. Por 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 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 recolha de dados para o registo quando o acervo de contratos está incompleto.
Onde é possível poupar: quem opera um SGSI segundo a ISO 27001 não tem de reinventar a gestão do risco, o controlo de acessos, as cópias de segurança e a gestão de incidentes. No Sightadel, as evidências existentes ficam associadas a ambos os frameworks. Não indicamos deliberadamente um valor para a sobreposição, porque depende do âmbito. A consultoria para as partes difíceis, como a determinação das funções críticas ou importantes, pode ser contratada como pacote na aplicação, se necessário.
O DORA coloca expressamente a responsabilidade pelo risco de TIC nas mãos do órgão de administração. Este define e aprova o quadro, estabelece as funções, determina a apetência pelo risco de TIC, aprova as políticas de continuidade do negócio e de terceiros, disponibiliza o orçamento e forma-se regularmente. Pode delegar-se o trabalho, não a responsabilidade. Por isso, nas auditorias pergunta-se o que a administração decidiu, como é informada e que formações os seus membros comprovadamente concluíram.
Na Alemanha, as infrações são sancionadas pela BaFin ao abrigo do direito nacional de supervisão, adaptado para aplicar as regras sancionatórias do DORA. São possíveis determinações, coimas e, em caso de deficiências graves, outras medidas de supervisão. Os prestadores terceiros críticos de serviços de TIC estão sujeitos à supervisão direta de uma entidade principal de supervisão europeia, que emite recomendações e pode aplicar sanções pecuniárias compulsórias calculadas com base no volume de negócios diário a nível mundial.
Além da supervisão, conta o lado civil. Uma falha de um prestador sem plano, uma notificação tardia ou uma cópia de segurança não testada podem levantar questões de indemnização perante clientes e de responsabilidade da administração. A avaliação no caso concreto deve ser feita com o seu consultor jurídico. O Sightadel não presta aconselhamento jurídico, mas garante que deliberações, formações e decisões ficam documentadas com data e responsável.
O regulamento não define uma lista exaustiva, mas do regulamento e das normas resulta um núcleo claro. Inclui o quadro de gestão do risco de TIC documentado, com a estratégia de resiliência operacional digital, políticas de segurança da informação, de controlo de acessos, de gestão de alterações e de gestão de vulnerabilidades, uma política de continuidade do negócio no domínio das TIC com planos de resposta e recuperação, políticas de cópias de segurança com evidências de recuperação testada, um processo de gestão de incidentes com critérios de classificação e registo de incidentes, o programa de testes com resultados, a estratégia para o risco de terceiros no domínio das TIC, o registo de informações e estratégias de saída para prestadores que apoiam funções críticas ou importantes.
O quadro deve ser revisto pelo menos uma vez por ano e, além disso, após incidentes graves e após conclusõ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, comprovativos de formação, registos de testes de recuperação, constatações de testes e auditorias tratadas.
No Sightadel, cada um destes documentos está associado a um controlo, com versão, aprovação e data de validade. Quando uma evidência expira, como um teste anual de recuperação, aparece no painel como ponto em aberto. Assim, o estado não está completo apenas na data da auditoria.
Todas as entidades financeiras que não estão abrangidas pelo quadro simplificado precisam de um programa de testes de resiliência operacional digital baseado no risco. Consoante o contexto, inclui avaliações e análises 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 adequadamente pelo menos uma vez por ano. Os testadores têm de ser independentes, internos ou externos.
Os testes de penetração baseados em ameaças, abreviados TLPT, dizem respeito apenas às entidades designadas para tal pela autoridade de supervisão e realizam-se então, em regra, de três em três anos. Seguem uma norma técnica própria, inspirada no quadro europeu TIBER. Um TLPT decorre em sistemas de produção e inclui uma análise de ameaças, um ataque encoberto por uma red team e uma análise conjunta posterior. A autoridade acompanha o teste e confirma no final a sua realização.
Muitas vezes subestima-se o tempo após o teste. As constatações têm de ser avaliadas, priorizadas e tratadas com prazos, e a autoridade quer ver o progresso. No Sightadel, cada constatação torna-se um problema com responsável e prazo. O teste propriamente dito é realizado por testadores especializados; o Sightadel regista o planeamento, o resultado e o tratamento.
Para as entidades financeiras, o DORA é o regime especial face à NIS2. As obrigações de cibersegurança são cumpridas através do DORA, não em duplicado. Em grupos com sociedades fora do setor financeiro, os dois regimes podem aplicar-se lado a lado. Nesse caso, compensa manter medidas e evidências uma única vez e associá-las a ambos.
As anteriores circulares de TI da BaFin para bancos, seguradoras, sociedades 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 a forma como as regras existentes, por exemplo sobre a gestão da subcontratação fora das TIC, se relacionam com o DORA. Antes da análise de lacunas, deve estar claro que partes continuam a aplicar-se 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 suporta o DORA em grande parte. O que o DORA exige adicionalmente é sobretudo o registo, os prazos de notificação, o conteúdo dos contratos e o programa de testes. Relatórios de atestação como o BSI C5 ou o SOC 2 dos seus prestadores são evidências valiosas na avaliação destes, mas não substituem a sua própria avaliação de riscos.
Quanto custa
Paga apenas os frameworks de que realmente precisa. As edições diferem na capacidade e no tempo de resposta, não no âmbito técnico. Quem gere vários frameworks poupa de forma permanente. Todos os preços, descontos e uma calculadora estão na página de preços.
Os custos do organismo de certificação ou de auditoria são faturados diretamente por este à sua empresa. Se precisar, pode contratar consultoria como pacote na aplicação.
Material de trabalho
↓DORA – lista de verificação de implementação e evidênciasLista de verificação · XLSX, PDFMaterial de apoio, não constitui aconselhamento jurídico.
Termos
Perguntas e respostas
Mais nas nossas perguntas frequentes ou diretamente através do nosso formulário de contacto.
Sim, se for uma entidade financeira na aceção do regulamento – por exemplo, instituição de crédito, instituição de pagamento ou de moeda eletrónica, empresa de investimento, empresa de seguros, gestor de fundos ou prestador de serviços de criptoativos. Como prestador de serviços de TIC destas empresas, os requisitos chegam-lhe através do contrato, mesmo sem estar sujeito a supervisão.
As sanções regem-se pelo direito nacional de supervisão. Na Alemanha, a BaFin pode determinar medidas e aplicar coimas. Para os prestadores terceiros críticos de serviços de TIC, as Autoridades Europeias de Supervisão preveem sanções pecuniárias compulsórias próprias. A responsabilidade pelo risco de TIC cabe expressamente ao órgão de administração.
Não. O DORA é um regulamento com supervisão, não uma norma certificável. A implementação é demonstrada perante a autoridade de supervisão e os seus auditores. Certificados ISO 27001 ou relatórios de atestação C5 ajudam como evidências, mas não substituem essa demonstração.
Em caso de incidente grave relacionado com as TIC: notificação inicial, no máximo, quatro horas após a classificação e, em caso algum, mais de 24 horas após o conhecimento do incidente; relatório intercalar no prazo de 72 horas; relatório final no prazo de um mês. Os pontos de referência exatos são regulados pelas normas técnicas.
Um inventário completo de todos os contratos relativos a serviços de TIC, ao nível da entidade individual e do grupo, com as funções apoiadas e os subcontratantes. Tem de ser mantido atualizado e apresentado regularmente à autoridade de supervisão. Os dados exigidos têm normalmente de ser reunidos a partir dos contratos, das compras e da operação.
Só se a autoridade de supervisão o designar para tal. Nesse caso, pelo menos de três em três anos. Todos os outros precisam de um programa de testes baseado no risco, com avaliações de vulnerabilidades, testes de penetração e verificações semelhantes.
Para as entidades financeiras, o DORA prevalece como regime especial. As obrigações de cibersegurança são cumpridas aí. O Sightadel trata ambos com as mesmas evidências, caso partes do seu grupo estejam abrangidas pela NIS2.
Não, propositadamente. A IA fornece rascunhos a partir de modelos setoriais e ajuda na redação. As funções críticas, a apetência pelo risco e a classificação são decididas por si – e é precisamente isso que a autoridade de supervisão verifica.
Uma vez por ano, com referência a uma data fixa, numa janela temporal definida pela BaFin, através da sua plataforma de reporte e publicação. Para 2026, a janela foi em março. O registo tem de cumprir as regras de validação das Autoridades Europeias de Supervisão. As datas atuais são publicadas pela BaFin.
Para as entidades abrangidas pelo DORA, as anteriores circulares de TI da BaFin (como as BAIT para bancos e as VAIT para seguradoras) foram substituídas pelo regulamento. A BaFin publicou orientações sobre a forma como as regras existentes se relacionam com o DORA. Antes da análise de lacunas, esclareça que partes continuam a aplicar-se na sua organização.
14 dias, acesso completo, sem dados de pagamento. Tudo o que configurar mantém-se no plano pago.
