DORA não é apenas um registro mantido pela área de riscos. Para engenharia backend, resiliência aparece em fronteiras de serviço, dependências visíveis, cronômetros de incidentes, recuperação testada e evidências de que o sistema se comportou como esperado.
O Digital Operational Resilience Act (DORA, Regulamento UE 2022/2554) é aplicável desde 17 de janeiro de 2025 às entidades financeiras dentro do escopo. Ele estabelece requisitos para gestão de risco ICT, tratamento e notificação de incidentes, testes de resiliência e risco de terceiros ICT. As obrigações exatas variam conforme entidade, proporcionalidade e normas técnicas aplicáveis. Este artigo traduz o framework em padrões de engenharia; não é aconselhamento jurídico nem substitui a avaliação de controles da entidade regulada.
Uma transferência, operação ou serviço de sinistros depende de mais que pods da aplicação. Mapeie identidade, segredos, DNS, APIs financeiras, filas, bancos de dados, observabilidade, plano de controle de deploy, regiões cloud, suporte e subcontratados. Ligue cada dependência à função de negócio e à função crítica ou importante que sustenta. Só o nome do fornecedor não basta: registre serviço, localização, dados, substituibilidade, premissas de recuperação e responsável contratual.
O Artigo 28 do DORA exige que entidades abrangidas mantenham um registro de informações sobre acordos contratuais para serviços ICT, incluindo visões por entidade e consolidadas conforme aplicável. O registro apoia monitoramento e supervisão; não deve ser uma planilha que envelhece entre revisões anuais de compras. Modele relações canônicas entre fornecedor, serviço, contrato e subcontratação e gere os templates regulatórios a partir de dados governados.
Ofereça aos responsáveis por serviço um fluxo para confirmar mudanças em fornecedor, escopo, local de processamento, cadeia de subcontratação, criticidade e plano de saída. Reconcilie compras com inventário cloud, catálogo de arquitetura, faturas, endpoints e dependências de incidentes. Valide identificadores e campos antes de gerar entregas conforme as instruções ITS vigentes.
Engenharia deve detectar e preservar evidências cedo; as funções responsáveis da entidade regulada decidem classificação e notificação. Não codifique decisão jurídica de severidade em um único alerta de taxa de erro. O DORA exige classificação por critérios de impacto e notificação dos incidentes ICT graves conforme o framework aplicável. Use templates e prazos atuais da autoridade competente e das normas técnicas; o fluxo precisa permitir avaliação por etapas e atualizações.
| Etapa | Ação do sistema | Evidência a preservar |
|---|---|---|
| Detectar | Correlacionar alertas de aplicação, segurança, infraestrutura e fornecedor. | Primeiro horário conhecido, IDs de eventos e serviços afetados. |
| Delimitar | Resolver o grafo serviço-dependência e segmentos afetados. | Transações, regiões, classes de dados, duração e impacto downstream. |
| Classificar | Apresentar fatos conforme critérios governados para revisão responsável. | Entradas, justificativa, revisor e horários das decisões. |
| Notificar / atualizar | Preparar comunicações a regulador e clientes pelos canais aprovados. | Versões enviadas, confirmações, atualizações e responsáveis. |
| Recuperar / encerrar | Restaurar serviço, conciliar dados e verificar correções. | Linha do tempo, impacto, causa e evidência corretiva. |
Mantenha os relógios distintos: detecção técnica, ciência organizacional, classificação, aprovação e envio formal são horários relacionados, mas diferentes. Use registro durável com histórico append-only, relógios sincronizados e controle de acesso. Redija dados pessoais e de pagamento dos traces comuns, preservando evidência necessária à análise forense.
O DORA exige um programa de testes de resiliência digital; a combinação de testes deve ser proporcional à entidade e ao risco. O regulamento inclui avaliações de vulnerabilidade, cenários, testes end-to-end, desempenho e penetração entre métodos possíveis. Também exige testes apropriados pelo menos anualmente nos sistemas ICT que sustentam funções críticas ou importantes (Artigo 24). TLPT baseado em ameaças aplica-se às entidades identificadas conforme o regulamento, não é uma obrigação anual universal para todas as empresas.
Exercícios backend devem incluir perda de dependência, falha regional, comprometimento de credenciais, backlog de fila, corrupção de dados, rollback, recuperação de ransomware e indisponibilidade de fornecedor. Teste não só “o failover funciona?”, mas também saldos consistentes, eventos sem duplicidade, permissões corretas, comunicação ao cliente e estado auditável dos controles.
Criaria um plano de controle de resiliência apoiado por catálogo de serviços e grafo de dependências. Cada função crítica apontaria para APIs, dados, recursos cloud, fornecedores, objetivos de recuperação, testes e playbooks. Eventos de telemetria carregariam IDs de serviço/dependência para gerar rapidamente o mapa de impacto. Um exportador de registros validaria dados canônicos de fornecedores conforme o schema regulatório vigente, evitando cópias manuais.
Em CI/CD, mudanças em dependências críticas acionariam revisão do responsável e testes de resiliência direcionados. O sistema de incidentes iniciaria automaticamente uma cronologia durável, planilha estruturada de impacto e rascunho de notificação para aprovação humana responsável. O painel mostraria lacunas de controle, correções vencidas, cobertura de recuperação testada e concentração de terceiros, não um selo simplista “em conformidade com DORA”.
| Falha | Sinal | Controle técnico |
|---|---|---|
| Registro diverge da produção | API, conta cloud ou subcontratado não catalogado aparece no incidente. | Reconcilie contratos com inventário runtime e exija ateste do responsável. |
| Failover restaura computação, não estado de negócio | Transações duplicadas, ausentes ou fora de ordem após recuperação. | Teste replay, idempotência, conciliação de ledger e consistência ao cliente. |
| Notificação começa sem fatos completos | Escopo e horários são reconstruídos depois em chats. | Automatize coleta de evidências e mantenha cronologia revisável. |
| Achados de teste não fecham | Problemas recorrentes sem responsáveis ou reteste. | Atribua prazo, escalonamento e critério verificável de encerramento. |
| Plano de saída só existe no contrato | Exportação não restaura ou não há capacidade alternativa. | Faça exercício técnico de saída e quantifique dependências de transição. |
DORA transforma resiliência em disciplina de ciclo de vida: conhecer serviços e fornecedores que sustentam funções importantes, detectar e classificar incidentes com evidências, testar recuperação sob falhas realistas e vincular correções a responsáveis. Engenharia backend fornece mapas, telemetria, automação e testes repetíveis; governança e jurídico determinam interpretação e notificações específicas da entidade.
Nota editorial: DORA e normas técnicas relacionadas podem receber complementos e esclarecimentos. Este panorama de engenharia foi revisto em 28 de setembro de 2026 e não é aconselhamento jurídico. Confirme requisitos atuais com a autoridade competente e assessoria qualificada.