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