Implementação DORA
A transformação digital no setor financeiro trouxe velocidade, eficiência e novos modelos de negócio — mas também uma dependência estrutural de tecnologia, cloud, software de terceiros, integrações e cadeias de fornecimento digitais. O DORA (Digital Operational Resilience Act) foi criado precisamente para responder a esse risco sistémico: garantir que entidades financeiras conseguem resistir, responder e recuperar de incidentes TIC/ciber (e também de falhas operacionais) sem comprometer a continuidade dos serviços críticos.
O DORA é um regulamento europeu (ou seja, diretamente aplicável), com requisitos harmonizados para o setor financeiro na União Europeia. Entrou em aplicação a 17 de janeiro de 2025.
Em Portugal, a Lei n.º 73/2025, de 23 de dezembro, veio assegurar o enquadramento nacional de execução, supervisão e regime sancionatório associado à resiliência operacional digital no setor financeiro.
Este artigo é um guia de implementação: sem jargão desnecessário, mas com passos, prioridades e entregáveis claros.
O que o DORA exige, em termos simples
O DORA organiza as obrigações em cinco grandes blocos (pilares) que se reforçam mutuamente:
-
Governação e gestão de risco TIC (framework, políticas, controlos, funções e responsabilidades)
-
Gestão e reporte de incidentes TIC (classificação, notificações, comunicação)
-
Testes de resiliência operacional digital (de testes básicos a exercícios avançados)
-
Gestão de risco de terceiros TIC (contratos, registo de fornecedores, planos de saída)
-
Partilha de informação sobre ameaças (mecanismos e boas práticas, quando aplicável)
As autoridades europeias e nacionais têm vindo a sintetizar esta lógica de “resiliência operacional digital” como uma capacidade contínua (não um projeto pontual).
Quem é abrangido (e por que isso interessa ao teu “perímetro”)
O DORA aplica-se a um vasto conjunto de entidades financeiras (ex.: banca, seguros, investimento e outros participantes regulados), e também introduz um quadro europeu de superintendência para prestadores críticos de serviços TIC que suportam o setor financeiro.
Na prática, a primeira tarefa de implementação não é “escrever políticas” — é definir o perímetro:
-
Que entidades do grupo estão sob supervisão financeira?
-
Quais os serviços/produtos e funções críticas ou importantes (CIFs) suportadas por TIC?
-
Quais as dependências (aplicações, infraestruturas, fornecedores, dados, integrações)?
-
Quem “possui” cada risco e cada controlo (propriedade operacional real)?
Se falhares aqui, tudo o resto (incidentes, testes, contratos, evidência) fica inconsistente.
O que muda especificamente em Portugal
Com a Lei n.º 73/2025, o quadro nacional fica alinhado com o regime europeu e reforça a execução/supervisão. A lei designa como autoridades competentes o Banco de Portugal, a CMVM e a ASF, e prevê cooperação institucional no âmbito do sistema de supervisão financeira.
Um ponto prático muito relevante para operações e compliance: o enquadramento nacional centraliza o reporte de incidentes graves de TIC no Banco de Portugal (com coordenação entre supervisores).
Além disso, Portugal reforçou comunicação institucional sobre DORA, incluindo o papel do Conselho Nacional de Supervisores Financeiros na articulação do pacote de resiliência.
Incidentes TIC: do “tratamos internamente” para um processo cronometrado
Uma das áreas com maior choque operacional é o reporte de incidentes. O DORA exige capacidade de:
-
detetar e classificar rapidamente incidentes TIC;
-
decidir se são “major ICT-related incidents” (conforme critérios/limiares aplicáveis);
-
reportar com conteúdo normalizado e timings exigentes, via templates e processos definidos.
Os prazos são particularmente apertados: há normas técnicas que apontam para notificação inicial em 4 horas após classificação (e até 24h após deteção/conhecimento, conforme enquadramento), depois reporte intermédio e final.
Em termos operacionais, isto obriga a duas mudanças:
-
Engenharia do processo (workflow) — quem deteta, quem classifica, quem aprova, quem submete, em que canal, com que evidência.
-
Capacidade de decisão 24/7 — não pode depender de “a equipa volta amanhã”.
👉 Dica de implementação: constrói um playbook de incidentes DORA com:
-
critérios de classificação e escalonamento;
-
RACI (responsáveis/decisores);
-
templates de reporte já pré-preenchidos (o que for possível);
-
exercícios de simulação para provar tempo de resposta.
Como implementar DORA: roadmap em 10 passos (realista)
1) Fazer um “DORA Scope Map” (2–3 semanas)
-
inventário de serviços e funções críticas/ importantes;
-
mapa de ativos TIC (aplicações, infra, dados, integrações);
-
lista de fornecedores TIC e dependências.
Entregável: mapa de perímetro + lista de CIFs + inventário inicial.
2) Gap assessment (DORA vs realidade)
Avaliar o “as-is” contra os 5 pilares: o que existe, o que falta, o que é só informal.
Entregável: matriz de gaps priorizada por risco e esforço.
3) Governação e accountability (o “tone from the top” com evidência)
O DORA exige envolvimento do órgão de gestão: decisões, aprovações, monitorização e responsabilidade.
Sem isto, as políticas parecem bonitas — mas não resistem a supervisão.
Entregável: modelo de governação (comités, reporting, KRIs/KPIs).
4) Framework de risco TIC (políticas + controlos + evidência)
Aqui entram políticas e procedimentos como:
-
gestão de vulnerabilidades e patching,
-
gestão de acessos,
-
logging e monitorização,
-
gestão de alterações,
-
backup/restore e continuidade,
-
gestão de configurações,
-
secure SDLC (se houver desenvolvimento),
-
gestão de dados (alinhado com RGPD quando aplicável).
Entregável: conjunto de políticas/procedimentos + evidência (registos, relatórios, tickets).
5) Incidentes e reporte (processo + treino)
Desenhar o fluxo e treinar: detetar → classificar → reportar → comunicar → fechar com RCA (root cause analysis).
Entregável: incident playbook + exercícios (tabletop) + lições aprendidas.
6) Testes de resiliência (do básico ao avançado)
Não é só pentest anual. Inclui:
-
testes de backup/restore,
-
testes de continuidade,
-
simulações de incidentes,
-
testes a processos de escalonamento,
-
e, para entidades relevantes, exercícios mais exigentes (ex.: abordagens tipo TLPT).
Entregável: plano anual de testes + evidência de execução e remediação.
7) Gestão de risco de terceiros TIC (contratos, registo, exit)
Este é o “calcanhar de Aquiles” típico: cloud, SaaS, MSSP, integradores, pagamentos, KYC, etc.
O DORA traz obrigações contratuais e de controlo, e cria supervisão europeia sobre terceiros críticos.
Entregáveis:
-
registo de contratos e serviços,
-
avaliação de risco por fornecedor,
-
cláusulas contratuais DORA (direitos de auditoria, SLAs, subcontratação, localização, incidentes, exit),
-
plano de saída (exit strategy) para serviços críticos.
8) Métricas e reporting contínuo (não “projeto que acaba”)
Criar um dashboard de resiliência:
-
incidentes e tempos de resposta,
-
disponibilidade de serviços críticos,
-
resultados de testes,
-
risco de fornecedores,
-
backlog de remediações.
9) Preparação para supervisão
A supervisão vai pedir evidência: não basta “temos política”.
Organiza o repositório de evidências por pilar.
10) Formação e cultura operacional
Sem treino, o reporte rápido falha.
Treina: IT, operações, risco, compliance, gestão, e fornecedores críticos.
DORA e NIS2: sobreposição, mas não substituição
Se a tua organização (ou parte dela) também cair em NIS2, há áreas comuns (incidentes, gestão de risco, cadeia de fornecimento). Mas atenção: no setor financeiro, o DORA funciona como regime especializado para resiliência digital — e as obrigações específicas continuam a ter de ser cumpridas conforme o enquadramento aplicável.
A abordagem prática é construir um sistema integrado, com:
-
taxonomia única de incidentes,
-
controlos base alinhados com standards (ex.: ISO 27001/22301),
-
mas workflows e reporting adaptados a cada obrigação (DORA vs NIS2 vs RGPD).
Erros comuns que geram não conformidade (e dores de cabeça)
-
Perímetro mal definido (CIFs vagas, fornecedores críticos “esquecidos”)
-
Contratos cloud/SaaS sem cláusulas DORA e sem exit strategy real
-
Incidentes sem classificação rápida e sem autoridade 24/7 para reportar
-
Testes que não fecham remediações (testa-se, encontra-se, mas não se corrige)
-
Evidência dispersa (ninguém consegue provar, em 2 dias, que controla o risco)
Checklist final: “DORA em 30 dias” (o mínimo que deves ter)
-
Scope map (CIFs + ativos + integrações)
-
Inventário de fornecedores TIC + criticidade
-
Gap assessment + roadmap aprovado
-
Governação formal (comités, reporting, responsáveis)
-
Processo de incidentes com classificação e escalonamento
-
Templates de reporte e testes de tempo de resposta
-
Plano de testes de resiliência + calendário
-
Registo de contratos + plano de remediação contratual
-
Exit strategy para serviços críticos
-
Repositório de evidência preparado para supervisão
Como a iCompliance.eu pode ajudar
Na iCompliance.eu, normalmente implementamos DORA como um programa de resiliência operacional (não como “documentação para inglês ver”), com foco em evidência e capacidade real de resposta:
-
DORA Readiness & Gap Assessment (perímetro, CIFs, riscos, maturidade)
-
Roadmap 90/180 dias com quick wins e prioridades por risco
-
Pacote de governação, políticas e procedimentos (alinhado com auditoria/supervisão)
-
Incident reporting pack (workflow, RACI, templates, exercícios)
-
Third-party ICT pack (registo, due diligence, cláusulas contratuais, exit plans)
-
Plano de testes e apoio em exercícios e preparação para inspeções
Passos seguintes:
- Diagnóstico DORA: Se quer saber, de forma objetiva, o que a sua organização tem de fazer para cumprir, a iCompliance.eu pode realizar uma avaliação rápida de enquadramento DORA e entregar um roadmap de conformidade com evidências prontas para supervisão e auditoria.
- Para ajudar o arranque faça download de uma checklist DORA Portugal em formato PDF, para tal solicite abaixo, nos comentários deste artigo.
- Contacte-nos: Contactos | iCompliance