Pular para o conteúdo principal

SbD-ToE 4 DORA: Playbook de Implementação

Visão Geral​

Este playbook mapeia requisitos DORA (Regulamento UE 2022/2554) para ações SbD-ToE práticas.

Princípio: Implementar o SbD-ToE cobre grande parte da base AppSec e operacional exigida por DORA, mas a conformidade final depende também de formalização regulatória adicional, artefactos institucionais e parametrização de reporte que ficam fora do manual base.

Estrutura: Cada secção mostra:

  • DORA requisito ou bloco normativo
  • SbD-ToE capítulo/addon aplicável
  • O que fazer
  • Que parte fica dentro do manual e que parte continua em overlay/compliance

📚 Recursos de Suporte: Para templates práticos e exemplos de implementação, consultar Exemplo-Playbook com toolchains, KPIs, RACI e relatórios de incidentes reutilizáveis para DORA e outros frameworks.

Mapa Rápido: DORA Art. → SbD-ToE​

DORA ArtigoRequisitoCapítulo SbD-ToEAção Principal
5Governação e responsabilidade do órgão de gestãoCap. 01, Cap. 14Aprovar políticas, supervisionar risco, formalizar cadeia de autoridade
6Framework de gestão de risco TICCap. 01, Cap. 02, Cap. 14Inventariar, classificar, ligar risco a requisitos, evidência e revisão
8–15Proteção, prevenção, deteção, resposta, recuperação, aprendizagem e comunicaçãoCap. 02, Cap. 03, Cap. 05, Cap. 07, Cap. 08, Cap. 11, Cap. 12, Cap. 13Implementar controlos técnicos e operacionais com evidência, monitorização e melhoria
17–23Gestão, classificação e reporte de incidentes TICCap. 12, Cap. 14Deteção, triagem, escalonamento e parametrização de reporte regulatório
24–27Programa de testes de resiliência digital e TLPTCap. 10, Cap. 11Testes contínuos, validação pré-deploy e TLPT readiness bounded
28–30Gestão de risco de terceiros TICCap. 05, Cap. 14SBOM, due diligence, cláusulas contratuais, ciclo de vida e saída

Como Implementar (Ordem Lógica)​

Fase 1: Governação (M0–M2)​

DORA Art. 5 - Estabelecer supervisão do órgão de gestão

  1. Criar fórum formal de governação de segurança digital

    • Membros: board sponsor, CISO, CTO, GRC, legal/procurement
    • Frequência: regular e com registo formal
    • Evidência: atas, decisões, owners, follow-up

  2. Aprovar política e cadeia de autoridade

  3. Definir RACI e critérios de escalada

    • Quem aprova o quê
    • Quando escalar
    • Como preservar trilho documental
    • 📄 Template: RACI e Governance

Fase 2: Framework de risco TIC (M2–M4)​

DORA Art. 6 - Estruturar a gestão de risco TIC

  1. Inventariar aplicações e serviços

  2. Classificar por risco

  3. Definir requisitos mínimos por nível

  4. Formalizar evidência, revisão e owners

Fase 3: Proteção, prevenção, deteção e recuperação (M4–M12)​

DORA Art. 8–15 - Implementar controlos técnicos e operacionais

3.1 Threat modeling, requisitos e arquitetura​

3.2 Desenvolvimento, CI/CD, IaC e supply chain​

3.3 Monitorização, resposta, recuperação e aprendizagem​

Fase 4: Incidentes e reporte regulatório (M8–M12)​

DORA Art. 17–23 - Gerir, classificar e reportar incidentes TIC

4.1 Monitorização centralizada​

  • O que: logs centralizados de aplicações, infraestrutura e acessos
  • Retenção: conforme política interna e enquadramento regulatório aplicável
  • Proteção: imutabilidade, integridade e rastreabilidade
  • Referência: Cap. 12 - Monitorização e Operações

4.2 Deteção, triagem e resposta​

4.3 Parametrização de reporte externo​

Fase 5: Testes de resiliência (M12–M18)​

DORA Art. 24–27 - Validar postura defensiva e preparar TLPT

5.1 Testes contínuos​

  • SAST: análise estática integrada
  • DAST: análise dinâmica em staging
  • PenTesting: testes manuais guiados por threat model
  • Referência: Cap. 10 - Testes de Segurança

5.2 Validação pré-deploy​

  • O que: checklist de segurança antes de produção
  • Confirmação: requisitos e evidência coerentes com o nível de risco
  • Aprovação: formal quando aplicável
  • Referência: Cap. 11 - Deploy Seguro

5.3 TLPT readiness e boundary regulatório​

  • O que: preparar a base técnica para exercícios TLPT em entidades elegíveis
  • Base: cenários de threat model, escopo, remediação e evidência
  • Boundary: elegibilidade, qualificação formal de testers e attestation pertencem à camada regulatória/compliance
  • Referências: Cap. 10 - Testes de Segurança, Cap. 11 - Deploy Seguro

Fase 6: Terceiros TIC e fornecedores críticos (M12–M18)​

DORA Art. 28–30 - Gerir risco de terceiros TIC

6.1 Fornecedores de componentes e supply chain de software​

  • O que: SBOM + SCA
  • Como: gerar SBOM; scan contínuo; atualizar dependências
  • Trilho: inventário, findings, correções e exceções
  • Referência: Cap. 05 - Dependências & SBOM

6.2 Fornecedores contratuais​

  • O que: contractors, outsourcing e parceiros com acesso ou responsabilidade técnica
  • Ciclo de Vida:
    • Onboarding: validação, formação SbD, sandbox
    • Operação: acesso controlado, revisão periódica
    • Offboarding: revogação de acessos, auditoria de fecho
  • Referência: Cap. 14 - Governança e Contratação

6.3 Concentração e saída​

  • O que: avaliar concentração, dependências críticas e estratégia de saída
  • Como: inventário, revalidação periódica, cláusulas contratuais e planos de transição
  • Boundary: parte desta leitura é regulatória e portfolio-wide, não apenas AppSec
  • Referências: Cap. 05 - Dependências & SBOM, Cap. 14 - Governança e Contratação

Checklist de Leitura DORA​

A lista abaixo permite validar a maturidade da base AppSec e operacional para uma leitura DORA defensável. A conformidade final continua a depender de parametrização regulatória e evidência institucional adicional:

  • Governação: Política aprovada; cadeia de autoridade clara; reporting periódico
  • Framework de risco: Todas as apps classificadas e ligadas a requisitos por nível
  • Requisitos: Catálogo versionado e rastreável
  • Supply chain técnica: SBOM gerado e SCA contínuo
  • Pipeline: Gates de segurança operacionais
  • Monitorização: Logs centralizados, proteção e retenção adequadas
  • Incidentes: Processo de deteção, classificação e reporte parametrizável
  • Fornecedores: Inventário, due diligence e ciclo de vida operacional
  • Testes: SAST/DAST integrados; readiness para TLPT onde aplicável
  • Evidência: Data room com políticas, testes, logs, contratos e reporting

O Que Cada Capítulo SbD-ToE Cobre (Referência Rápida)​

CapítuloDORA ArtigosO Que Faz
Cap. 01Art. 5, 6Classificação de apps por risco e proporcionalidade
Cap. 02Art. 6, 8–15Requisitos mínimos, rastreabilidade e validação
Cap. 03Art. 8–15, 24–27Threat modeling para cenários realistas
Cap. 05Art. 8–15, 28–30SBOM, SCA, supply chain de software
Cap. 07Art. 8–15CI/CD seguro, gates, trilho auditado
Cap. 10Art. 24–27Testes contínuos, readiness e evidência
Cap. 11Art. 8–15, 24–27Validação pré-deploy, rollback e contenção
Cap. 12Art. 8–15, 17–23Monitorização, incidentes, resposta e reporting interno
Cap. 13Art. 8–15Formação e capacitação contínua
Cap. 14Art. 5, 6, 17–23, 28–30Governança, RACI, reporte e ciclo de vida fornecedores

Métrica Simples: Estou Bem Preparado?​

Se consegues responder SIM a isto, tens uma base AppSec forte para uma implementação DORA defensável:

  1. Governance: Tenho política aprovada e cadeia de autoridade clara? ✓
  2. Risk Management: Todas as apps estão classificadas e ligadas a requisitos? ✓
  3. Security by Design: Meus requisitos e controlos são rastreáveis? ✓
  4. Software Supply: Tenho SBOM e SCA ativos? ✓
  5. Operations: Tenho monitorização centralizada com retenção e proteção adequadas? ✓
  6. Incident Response: Consigo detetar, classificar e parametrizar reporte de incidentes? ✓
  7. Vendor Management: Tenho ciclo de vida formal de contractors e terceiros críticos? ✓
  8. Testing: Faço SAST/DAST e tenho readiness para TLPT quando aplicável? ✓
  9. Evidence: Consigo demonstrar tudo isto em auditoria e reporte regulatório? ✓

Leitura prática: quanto mais respostas positivas, mais madura está a tua base AppSec. A passagem para conformidade DORA plena continua a exigir artefactos regulatórios, templates de reporte e formalização institucional que não vivem apenas neste manual.

Nota Crítica: Gestão de Exceções em DORA​

DORA exige que desvios e exceções sejam formais, auditáveis e aprovados ao nível adequado.

O que caracteriza uma exceção em SbD-ToE/DORA:

  • desvio formal de um requisito;
  • justificação técnica e de negócio;
  • prazo de validade (TTL);
  • plano de remediação e owner;
  • trilho documental passível de auditoria.

Quem aprova depende da criticidade, do modelo de governação e do enquadramento regulatório aplicável. Em contextos críticos, a leitura DORA tende a exigir elevação clara da decisão ao nível de gestão apropriado.

Leitura prática:

  • exceções sem aprovação formal comprometem a supervisão;
  • algumas exceções podem ser inaceitáveis em leitura regulatória defensável;
  • o manual cobre bem o processo, mas a admissibilidade final continua a depender do contexto regulatório.

Referências: Cap. 02 - Requisitos de Segurança e Cap. 14 - Governança

Recursos Práticos de Implementação​

Para suporte concreto na implementação deste playbook, consultar os seguintes exemplos reutilizáveis:

Estes recursos são reutilizáveis para múltiplos frameworks e mostram como operacionalizar, fora do manual base, os detalhes que dependem de contexto regulatório, supervisor e tooling.

Próximos Passos​

  1. Fazer um audit de conformidade atual contra a matriz acima
  2. Sequenciar o roadmap por criticidade, gap e dependência
  3. Implementar por fases, com evidência versionada
  4. Parametrizar a camada regulatória de reporte e terceiros
  5. Validar periodicamente a prontidão documental e operacional

Documentação completa: ver capítulos SbD-ToE 01–14 para detalhe técnico e operacional.

Referências​

Versão: 1.2 (recalibrado após validação regulatória)
Data: Abril 2026
Nota: Este playbook complementa a análise normativa DORA com implementação prática bounded e orientada a evidência.