DORA: Cross-Check Normativo
Para implementação prática, consulte o Playbook SbD-ToE 4 DORA.
Para exemplos práticos internos, ver pasta
exemplo-playbook/.
Enquadramento Geral
O Digital Operational Resilience Act (DORA) - Regulamento (UE) 2022/2554 (CELEX: 32022R2554) - representa uma viragem histórica na forma como a União Europeia encara a resiliência digital no setor financeiro.
A partir de janeiro de 2025, não basta às entidades financeiras protegerem dados ou cumprirem boas práticas gerais: exige-se que demonstrem, com evidências e mecanismos consistentes, que sabem identificar, prevenir, detetar, responder e aprender com riscos tecnológicos.
O SbD-ToE foi concebido como modelo universal de segurança aplicacional e cobre naturalmente os pilares técnicos da DORA. Este documento consolida:
- Cross-check normativo: Como o SbD-ToE mapeia para DORA
- Playbook prático: Roadmap de 12–18 meses para implementação
PARTE I: ANÁLISE NORMATIVA
🔍 O que DORA exige, em termos operacionais
⚖️ Nota editorial.
Esta secção é uma síntese operacional dos artigos relevantes do DORA, não uma citação literal do regulamento.
Baseia-se, em particular, nos Artigos 4.º–7.º (governação e gestão de risco TIC), 11.º–12.º (classificação de incidentes), 15.º, 18.º–20.º (incidentes e testes), 26.º–28.º (fornecedores TIC).
De forma prática, o DORA traduz-se em obrigações que impactam diretamente as práticas do SbD-ToE:
-
Órgão de gestão com responsabilidade explícita (Art. 5.º).
- O órgão de gestão aprova a estratégia de gestão de risco TIC, acompanha a sua execução e é responsável por garantir que existem políticas, procedimentos, documentação e evidência.
- No SbD-ToE isto liga-se à governação global, políticas e à exigência de accountability sobre decisões de risco.
-
Gestão de risco TIC estruturada e documentada (Art. 6.º–7.º).
- O regulamento exige identificação de ativos críticos, avaliação de impacto, definição de controlos e monitorização contínua.
- O SbD-ToE fornece os blocos técnicos (capítulos 01–14) que podem ser usados como catálogo de controlos para cumprir esta obrigação.
-
Gestão de incidentes e reporte estruturado (Art. 18.º–20.º).
- DORA define requisitos mínimos para classificação, registo, escalonamento e reporte de incidentes de TIC a autoridades competentes, em prazos definidos.
- O manual fornece práticas para deteção, logging, evidência técnica e runbooks que suportam estes fluxos.
-
Testes de resiliência operacional digital (Art. 19.º–20.º).
- Exige um programa de testes regulares, proporcional ao risco (incluindo threat-led penetration testing para entidades mais críticas).
- No SbD-ToE isto cruza diretamente com capítulos de testes de segurança, red teaming, chaos engineering e validação contínua de pipelines.
-
Gestão de risco de terceiros TIC (Art. 26.º–28.º).
- Impõe inventário de fornecedores TIC críticos, avaliação de risco, cláusulas contratuais específicas e supervisão contínua.
- O manual cobre estes aspetos nos capítulos de dependências, SBOM/SCA, supply chain, outsourcing e governação/contratação.
-
Decisões de exceção e vulnerabilidades não remediadas.
- Embora o regulamento não use exatamente esta formulação, a combinação de exigências sobre gestão de risco, testes, incidentes e terceiros implica que:
- exceções a testes de resiliência,
- aceitação de vulnerabilidades não remediadas, e
- desvios às políticas de segurança aprovadas
devem ser formalmente analisados, contextualizados, aprovados ao nível adequado e documentados (incluindo justificação, prazo, owner e medidas compensatórias).
- O SbD-ToE materializa isto em playbooks de Risk Acceptance, fluxos de aprovação, registos estruturados e KPIs.
- Embora o regulamento não use exatamente esta formulação, a combinação de exigências sobre gestão de risco, testes, incidentes e terceiros implica que:
Na prática, o DORA fornece o "chapéu regulatório" e os critérios de responsabilização; o SbD-ToE funciona como o manual técnico que torna essas obrigações executáveis no ciclo de vida de desenvolvimento e operação.
Gestão de Risco TIC (Artigo 5 DORA)
Cobertura SbD-ToE:
- Cap. 01: Classificação de criticidade aplicacional (L1–L3)
- Cap. 02: Catálogo de requisitos de segurança por nível
- Cap. 03: Threat Modeling para identificação de riscos
- Cap. 12: Deteção, resposta e melhoria contínua
- Cap. 14: Governação e aprovação de políticas
Lacuna intencional: O SbD-ToE não fixa o nível hierárquico de aprovação (mantém flexibilidade organizacional). A conformidade com DORA requer mapeamento das políticas SbD-ToE para aprovação formal em órgão de gestão, com registo documental da decisão.
Incidentes e Reporte (Artigo 18 DORA)
Exige processo ponta-a-ponta: deteção, registo, classificação, reporte formal com templates normalizados.
Cobertura SbD-ToE:
- Cap. 12: Processos de deteção e resposta de incidentes
- Cap. 14: Responsabilidades de reporte e escalonamento
Lacuna intencional: O SbD-ToE não define taxonomia de prioridades (P0–P3) nem templates específicos DORA, preservando universalidade. A conformidade requer configuração de campos de incidentes segundo RTS/ITS da DORA e integração com sistemas de reporte automático (ex: SIEM).
Testes de Resiliência (Artigos 19–20 DORA)
Exige programa contínuo de testes, culminando em Threat-Led Penetration Testing (TLPT) para entidades elegíveis.
Cobertura SbD-ToE:
- Cap. 03: Threat Modeling (cenários de ataque realistas)
- Cap. 10: Catálogo de testes (SAST, DAST, fuzzing, etc.)
- Cap. 11: Validação de segurança pré-produção
Cobertura parcial - ver Cap. 10 → addon 14: TLPT Readiness: O SbD-ToE enquadra o que é o TLPT, o que o distingue do PenTest convencional e como a maturidade do programa de testes se relaciona com o exercício. O que permanece fora do âmbito do manual são os critérios de elegibilidade (identificação pela autoridade competente), a qualificação formal de testers e providers segundo o Reg. Delegado (UE) 2025/1190, e o processo de attestation pela autoridade TLPT designada - estes aspectos são da competência das equipas de compliance e da relação com o supervisor.
Gestão de Fornecedores Críticos (Artigos 26–28 DORA)
Os Artigos 26–28 estabelecem requisitos para inventário formal, avaliação de risco, cláusulas contratuais obrigatórias, supervisão contínua e planos de saída testados.
Cobertura SbD-ToE (Duas categorias de fornecedores, uma estratégia):
Categoria 1: Fornecedores de Componentes de Software (Cap. 05 - SBOM)
- Contexto DORA: Componentes de software (bibliotecas, frameworks) de terceiros constituem fornecedores implícitos de tecnologia
- Solução técnica: SBOM (Software Bill of Materials) identifica dependências e respetivos fornecedores
- Característica: Fornecedores implícitos - os autores de componentes frequentemente desconhecem que integram a cadeia de fornecimento
- Gestão operacional: SCA contínuo (análise de vulnerabilidades), gestão de atualizações de segurança, rastreamento de licenças
- Pré-requisito DORA: Sem SBOM, a organização não consegue identificar fornecedores de software
Categoria 2: Fornecedores Contratuais (Cap. 14 - Governance)
- Entidades contratadas formalmente: contractors, outsourcing, prestadores de serviços
- Característica: Fornecedores explícitos com contratos e responsabilidades formalmente documentadas
- Ciclo de vida estruturado: preparação → onboarding → monitorização → offboarding
- User Stories US-15 a US-20: Processos de gestão de contractors/fornecedores
Artefactos de suporte (Cap. 14):
- Template de validação pré-acesso de contractors
- Guia de preparação técnica de sandbox
- Checklist de offboarding seguro
Conformidade DORA (Art. 26–28):
- Ambas as categorias exigem inventário e supervisão - não existe opcionalidade
- SBOM alimenta o inventário de risco técnico de componentes
- Fornecedores contratuais alimentam o inventário de risco organizacional
- Lacuna intencional: O SbD-ToE não inclui templates ITS nem fórmulas de análise de concentração DORA. A conformidade requer: manutenção de SBOM atualizado (Cap. 05), inventário formal de contractors (Cap. 14) e templates contratuais com cláusulas de segurança alinhadas com DORA.
Partilha de Informação sobre Ameaças (Artigo 16 DORA)
O Artigo 16 DORA exige mecanismos de recolha e disseminação de informação sobre incidentes e ameaças TIC, promovendo a cooperação entre entidades financeiras e autoridades.
Cobertura SbD-ToE:
- Cap. 12: Integração de indicadores de threat intelligence em processos de monitorização
- Cap. 14: Estruturas de governança e responsabilidades de reporte
Lacuna intencional: O SbD-ToE não prescreve acordos institucionais específicos nem processos de notificação ao supervisor. A integração de feeds de threat intelligence (ex: STIX/TAXII, MISP) e a formalização de canais de partilha com autoridades competentes devem ser estabelecidos em conformidade com orientações setoriais e requisitos regulatórios DORA.
Gestão de Exceções e Desvios (Artigos 5, 18, 19–20, 26–28 DORA)
DORA não menciona explicitamente "exceções", porém em conformidade regulatória, exceções constituem desvios formais de requisitos que exigem:
- Aprovação documentada com autoridade formal designada
- Justificação técnica e de negócio
- Período de validade definido
- Plano de remediação estruturado
Cobertura SbD-ToE (Parcial):
- Cap. 10: Gestão de exceções em testes de segurança com aprovação formal (ex: vulnerabilidades conhecidas com justificação)
- Cap. 08: Rastreamento de exceções de configuração em IaC
- Cap. 14: Estrutura RACI para aprovações (implicitamente define autoridade para exceções)
Lacuna intencional: O SbD-ToE não define:
- Níveis de autoridade para aprovação de exceções em contexto DORA (board, CISO, compliance officer)
- Categorias de exceções admissíveis segundo DORA (algumas podem ser inadmissíveis)
- Templates de reporte de exceções ao regulador
- SLA de remediação por tipo de exceção
Conformidade DORA:
- Estabelecer política formal de exceções com estrutura de governança e rastreabilidade
- Documentar cada exceção: justificação, aprovador, data de expiração, plano de correção
- Manter trilho auditado de exceções (passível de inspeção regulatória)
- Validar admissibilidade com supervisor (algumas exceções podem violar Art. 5)
Exceções Formais e Desvios de Conformidade (Artigos 5, 18, 19–20, 26–28 DORA)
O Problema: Exceções Informais = Incoerência com DORA
DORA Art. 5 estabelece que a resiliência digital é responsabilidade última do órgão de gestão (board), e supervisão de execução significa:
- Conhecer todos os desvios de políticas de segurança
- Aprovar formalmente exceções a controlos
- Documentar razões, período de validade e plano de remediação
- Manter trilho auditado para demonstrar ao regulador
Cenário crítico (incoerência com DORA):
| Situação | Risco | Impacto | Posição DORA |
|---|---|---|---|
| SQLi em produção (L3) sem exceção documentada | Exploração, violação de dados, incident notificável | Responsabilidade não-atribuída, trilho perdido | ❌ GRAVE - Violação Art. 5 (sem supervisão) + Art. 18 (sem rastreamento) |
| CVE crítico ignorado sem justificação | Exposição contínua, compliance gap | Falha de gestão de risco TIC | ❌ GRAVE - Violação Art. 19–20 (teste de resiliência inadequado) |
| Exceção aprovada verbalmente (no Teams/email informal) | Perda de trilho, falta de autoridade formal, re-negociação ad-hoc | Impossível auditar decisões | ❌ CRÍTICO - Sem evidência de governance; regulador questiona: "quem aprovou?" |
| Exceção expirada sem reavaliação | Risco aceito torna-se risco não-aceito (drift), violação técnica silenciosa | Aplicação continua com risco acima de limite | ❌ CRÍTICO - Violação Art. 5 (falta de supervisão contínua) |
O que DORA Exige Explicitamente
Art. 5 (Gestão de Risco TIC):
"Membros do órgão de gestão aprovam a estratégia e supervisionam a execução de políticas, incluindo respostas a riscos emergentes."
Tradução operacional:
- Decisões de aceitação de risco (exceções) exigem aprovação documentada de autoridade formal
- O regulador interpreta conhecimento prévio de vulnerabilidade explorada sem aprovação documentada como negligência de supervisão
- Exceções requerem reavaliação periódica - a ausência de reavaliação constitui aprovação tácita indefinida, configurando falha de supervisão
Art. 18 (Incidentes):
"Exceções a testes de resiliência ou vulnerabilidades não-remediadas devem ser reportadas com contexto."
Art. 19–20 (Testes):
"Programa contínuo de testes deve cobrir cenários realistas. Exceções (ex: componente legado não-testável) requerem compensação documentada."
Art. 26–28 (Fornecedores):
"Exceções a SLAs de fornecedores ou CVEs não-mitigados devem ser escalados conforme plano de risco."
Cobertura SbD-ToE (Forte, mas com Gaps Explícitos)
O que SbD-ToE JÁ PRESCREVE (excelente):
| Capítulo | O que prescreve | Nível de detalhe |
|---|---|---|
| Cap. 01 | Classificação L1–L3 (base para criticidade de exceções) | ✅ Modelo E+D+I claro; criterios de L1/L2/L3 definidos |
| Cap. 01, addon 03 | Critérios de aceitação de risco (limiares por nível) | ✅ L1≤9, L2≤6, L3≤4; requer validação por 2+ perfis em L2/L3 |
| Cap. 02, addon 08 | Gestão de exceções a requisitos (processo formal) | ✅ Identificação, justificação, avaliação, compensação, revisão periódica |
| Cap. 04, addon 03 | Exceções a requisitos arquiteturais | ✅ Modelo de registo com horizonte temporal; responsáveis designados |
| Cap. 05, addon 09 | Exceções a CVEs (formalização, owner, TTL, impacto) | ✅ Processo completo: identificação → justificação → aceitação → TTL → revalidação |
| Cap. 10 | Exceções a testes de segurança (com aprovação formal) | ✅ Menção explícita: "exceções formais aprovadas" |
| Cap. 14 | Governança de exceções (RACI, approval flow, auditoria) | ⚠️ PARCIAL - User Stories definem roles, mas não explicam implicações DORA |
| Cap. 13 | Waivers e exceções temporárias (durante formação) | ✅ "Justificação formal documentada, aprovada por AppSec/GRC/gestão" |
Gaps Identificados (Incoerências com DORA)
Gap 1: Falta de Mapeamento Explícito de Autoridade DORA-compatível
| Nível | SbD-ToE Prescreve | DORA Exige | Gap |
|---|---|---|---|
| L1 | Validação por AppSec Engineer (informal) | Aprovação por autoridade formal designada | ⚠️ Developer-friendly, mas falta escalada clara |
| L2 | Validação formal por AppSec + GRC | Aprovação por CISO ou equivalente formal | ✅ Adequado, mas manual não o diz explicitamente |
| L3 | Aprovação de Gestão Executiva/CISO | Aprovação de board ou CRO (exigência DORA) | ❌ GAP CRÍTICO - Manual não especifica "board-level approval" |
Como manifesta: Organização aceita exceção L3 com aprovação de CISO; regulador questiona: "foi aprovada em board?" → sem ata = falha de governance.
Gap 2: Falta de Descrição de Inaceitabilidade em DORA
| Exceção | SbD-ToE | DORA |
|---|---|---|
| "Não implementar MFA porque é complexo" | Tecnicamente aceitável com TTL em L1 | ❌ Pode violar DORA (MFA é obrigatório em Art. 19) |
| "SQLi em endpoint legado, mantém-se" | Aceitável com compensação (ex: WAF) em L1/L2 | ❌ Pode violar DORA (SQLi é nunca aceitável em qualquer L) |
| "CVE P0 em runtime, sem plano de fix" | Aceitável se compensado em L1 | ❌ Violação DORA (Art. 19 requer plano de remediação) |
Como manifesta: Organização registra exceção no SbD-ToE formalmente; regulador rejeita: "esta exceção não é admissível em DORA" → perda de tempo, revisão forçada.
Gap 3: Falta de Rastreamento de TTL vs. Supervisão Contínua
| Processo | SbD-ToE | DORA Exigência | Gap |
|---|---|---|---|
| Criação de exceção | Documenta com owner, TTL, critérios | ✅ Bom | ✅ Alinhado |
| Reavaliação periódica | Revisão 30 dias antes expiração; re-aprovação obrigatória | ✅ Bom | ✅ Alinhado |
| Rastreamento centralizado | Ferramenta GRC; audit trail por aplicação | ✅ Bom | ⚠️ Manual não descreve formato de reporte a DORA |
| Escalada ao regulador | Não mencionado no manual | ❌ DORA exige reportar exceções em contexto de incidentes | ❌ GAP - Sem guia de quando escalar ao regulador |
Como manifesta: Incidente de segurança; regulador pede: "mostre-me exceções relevantes" → organização não tem visão consolidada ou não sabe se deve reportar.
Gap 4: Sem Política Organizacional Formal sobre Inaceitabilidade
O SbD-ToE descreve como gerir exceções, mas não estabelece quais categorias são inaceitáveis em DORA:
-
Nunca aceitável (violação Art. 5):
- Exceções sem aprovação documentada
- Exceções expiradas sem reavaliação
- Violações de conformidade regulatória (ex: SQLi, injeção de comando)
-
Aceitável com restrições (compatível com DORA):
- Exceções com TTL, plano de fix e compensação
- Exceções aprovadas por board/CRO
- Exceções com trilho auditado
Como manifesta: Organização sem política formal aceita exceção inadmissível; auditoria regulatória identifica achado crítico.
Como Resolver a Incoerência
1. Estabelecer Política Formal de Exceções Compatível com DORA
POLÍTICA: Gestão de Exceções e Desvios de Conformidade
Objetivo: Garantir que todas as exceções a requisitos de segurança são aprovadas por autoridade formal, documentadas com trilho auditado, e compatíveis com exigências regulatórias (DORA).
Categorias de exceção:
A. Exceções INACEITÁVEIS (violação de DORA Art. 5/19):
- Exceções sem aprovação documentada
- Exceções expiradas sem reavaliação
- Vulnerabilidades exploráveis sem compensação (ex: SQLi, injeção)
- Violações de requisitos obrigatórios de conformidade
➜ Ação: REJEITAR; forçar mitigação
B. Exceções ACEITÁVEIS com aprovação board-level (L3 DORA):
- Componentes legados sem patch aplicável
- CVEs com "no fix available" + compensação (ex: isolamento de rede)
- Arquitetura herdada em transição
➜ Ação: APROVAR se board/CRO assina; TTL ≤ 90 dias; reavaliação obrigatória
C. Exceções ACEITÁVEIS com aprovação CISO-level (L2 DORA):
- Requisitos técnicos com compensação equivalente
- Testes legítimos de resiliência suspensos (ex: TLPT adiado)
➜ Ação: APROVAR se CISO/AppSec assina; TTL ≤ 180 dias; reavaliação obrigatória
D. Exceções ACEITÁVEIS com aprovação AppSec-level (L1):
- MVP com funcionalidade reduzida de segurança
- Prototipagem com dados não-sensíveis
➜ Ação: APROVAR se AppSec assina; TTL ≤ 365 dias; reavaliação obrigatória
Rastreamento:
- Ferramenta GRC centralizada (SAP GRC, AuditBoard, ou custom)
- Campos: ID | Aplicação | Nível | Exceção | Justificação | Aprovador | Data | TTL | Status | Observações regulatórias
- Reporte trimestral a CISO/board
- Reporte ad-hoc a regulador se incidente relacionado
2. Esclarecer no Manual SbD-ToE
Adicionar ao Cap. 14 (Governança) uma secção dedicada:
## Compatibilidade DORA: Exceções Inaceitáveis vs. Aceitáveis
[Tabela acima com categorias A–D]
### Implicações Regulatórias
Se um incidente ocorre e há exceção relacionada:
- **Com aprovação documentada** → Demostra supervisão; mitigação regulatória
- **Sem aprovação documentada** → Evidência de negligência; penalidade potencial
### Processo de Escalada ao Regulador
[Template de como reportar exceção ao supervisor em contexto de incidente]
3. Integrar em User Stories do Cap. 14
Expandir US-15 (Processo formal de exceções) com:
- Approval Matrix DORA-compatível
- Categorias de inaceitabilidade
- Template de reporte ao regulador
Resumo: Por que Ausência de Gestão Formal = Incoerência DORA
| Aspecto | Sem Gestão Formal | Com Gestão SbD-ToE + DORA Mapping |
|---|---|---|
| Descoberta regulatória | Ausência de documentação de exceções ou localização desconhecida ❌ | Processo formal em sistema GRC com aprovação board-level ✅ |
| Trilho auditado | Exceções em canais informais (Slack/Teams/email) ❌ | Exceções em ferramenta GRC com audit trail completo ✅ |
| Supervisão do board | Board desconhece exceções críticas ❌ | Board recebe reporte trimestral de exceções L3 ✅ |
| Resposta a incidentes | Desconhecimento de vulnerabilidade explorada ❌ | Vulnerabilidade registada em exceção aprovada com plano de correção; escalada segundo protocolo ✅ |
| Achados auditoria | Achado crítico: falha de governance ❌ | Achado menor: oportunidades de melhoria operacional ✅ |
Conformidade Prática
Alinhamento SbD-ToE com DORA:
- ✅ Aplicar processo formal de exceções do SbD-ToE (Cap. 14, Cap. 02 addon 08, Cap. 05 addon 09)
- ✅ Mapear níveis de criticidade a aprovadores DORA-compatíveis (L1→AppSec, L2→CISO, L3→Board/CRO)
- ✅ Definir categorias de inaceitabilidade (política organizacional)
- ✅ Implementar rastreamento centralizado com audit trail (ferramenta GRC)
- ✅ Estabelecer reporte trimestral a estruturas de governance (exigência DORA Art. 5)
- ✅ Definir protocolo de escalada ao regulador em contexto de incidente (Art. 18)
CONCLUSÃO DO CROSS-CHECK
O SbD-ToE cobre o núcleo técnico da DORA. As lacunas observadas não constituem falhas do modelo, mas abstenções deliberadas para preservar universalidade e aplicabilidade em contextos organizacionais diversos.
Requisitos para conformidade plena:
- Mapeamento de políticas SbD-ToE a aprovações formais de órgão de gestão
- Configuração de campos de incidentes segundo RTS/ITS DORA
- Extensão de inventários com dados regulatórios específicos
- Cálculo de métricas DORA de concentração de fornecedores
- Formalização de acordos de partilha de informação sobre ameaças
Referências
- SbD-ToE Manual (Capítulos 01–14)
- Regulamento DORA (UE 2022/2554)
- NIST SP 800-53, OWASP SAMM, BSIMM, SSDF
- Cap. 14 SbD-ToE: User Stories US-15 a US-20 (fornecedores/contractors)
Versão: 1.0
Data: Novembro 2025
Próxima revisão: Junho 2026