Skip to main content

SbD-ToE 4 DORA: Implementation Playbook

Overview​

This playbook maps DORA requirements (Regulation (EU) 2022/2554) to practical SbD-ToE actions.

Principle: Implementing SbD-ToE covers much of the AppSec and operational baseline required by DORA, but final compliance also depends on additional regulatory formalisation and on institutional artefacts that stay out of scope of the Manual.

What the Manual covers, the gaps it declares and what stays out of scope, obligation by obligation, are in Applicable requirements — What this Manual covers and what stays out.

Structure: Each section shows:

  • The DORA requirement or normative block
  • The applicable SbD-ToE chapter/addon
  • What to do
  • Which part falls within the Manual (including the floor entries and the requirements added by the DORA context, on the Applicable requirements page) and which part is out of scope

📚 Supporting Resources: For practical templates and implementation examples, see the Example Playbook, with reusable toolchains, KPIs, RACI and incident reports for DORA and other frameworks.

Quick Map: DORA Art. → SbD-ToE​

DORA ArticleRequirementSbD-ToE ChapterMain Action
5Governance and responsibility of the management bodyCh. 01, Ch. 14Approve policies, oversee risk, formalise the chain of authority
6ICT risk management frameworkCh. 01, Ch. 02, Ch. 14Inventory, classify, link risk to requirements, evidence and review
8–15Protection, prevention, detection, response, recovery, learning and communicationCh. 02, Ch. 03, Ch. 05, Ch. 07, Ch. 08, Ch. 11, Ch. 12, Ch. 13Implement technical and operational controls with evidence, monitoring and improvement
17–23Management, classification and reporting of ICT-related incidentsCh. 12, Ch. 14Detection, triage, escalation and parameterisation of regulatory reporting
24–27Digital resilience testing programme and TLPTCh. 10, Ch. 11Continuous testing, pre-deploy validation and bounded TLPT readiness
28–30ICT third-party risk managementCh. 05, Ch. 14SBOM, due diligence, contractual clauses, lifecycle and exit

How to Implement It (Logical Order)​

Phase 1: Governance (M0–M2)​

DORA Art. 5 - Establish oversight by the management body

  1. Create a formal digital security governance forum

    • Members: board sponsor, CISO, CTO, GRC, legal/procurement
    • Frequency: regular and with a formal record
    • Evidence: minutes, decisions, owners, follow-up

  2. Approve the policy and the chain of authority

    • Reference: Ch. 14 - Governance and Contracting
    • Approval: at the management level appropriate to the regulatory context
    • Content: responsibilities, escalation, exceptions, reporting

  3. Define RACI and escalation criteria

    • Who approves what
    • When to escalate
    • How to preserve the documentary trail
    • 📄 Template: RACI and Governance

Phase 2: ICT risk framework (M2–M4)​

DORA Art. 6 - Structure ICT risk management

  1. Inventory applications and services

  2. Classify by risk

    • Level L1–L3 per application, according to the axes of exposure, data sensitivity and impact (CLA-001)
    • Mark, per application, whether it supports a critical or important function (FCI grade of the DORA context, with a reference to the entity's inventory of functions): it is an axis separate from the level and adds its own floor requirements; L3 is not equivalent to a critical or important function
    • Reference: Ch. 01 - Application Classification

  3. Define minimum requirements per level

  4. Formalise evidence, review and owners

Phase 3: Protection, prevention, detection and recovery (M4–M12)​

DORA Art. 8–15 - Implement technical and operational controls

3.1 Threat modelling, requirements and architecture​

3.2 Development, CI/CD, IaC and supply chain​

3.3 Monitoring, response, recovery and learning​

  • What: monitor, react, contain, recover and learn from events and deviations
  • How: structured logging; alerts with SLAs; rollback; runbooks; metrics; continuous training
  • Trail: operational evidence, post-incident reviews, KPIs and reporting
  • Recovery: backups with tested restoration (OPS-016) and recovery objectives and procedure for the application (OPS-017); redundant capacities and switchover testing are a requirement added by the DORA context (CTX-DORA-R01). The entity's continuity plans (Article 11) stay outside the Manual.
  • DORA context floor: IRP at any level (Policy 32 §2; CTX-DORA-P01); dynamic testing (TST-005; P03); annual access review, and half-yearly for critical or important functions (ACC-010; P05, P06); strong authentication (AUT-001; P07); weekly vulnerability scanning of the assets supporting critical or important functions (Policy 10 §9; P08); responsible disclosure (GOV-015; P10); privileged accounts and identity lifecycle (GOV-016, GOV-017; P13, P14); key lifecycle and certificate register (ENC-007; P15, P16); cryptographic agility (ENC-003; P17); half-yearly review of network filtering rules (ARC-006; P18). See Applicable requirements.
  • References: Ch. 11 - Secure Deployment, Ch. 12 - Monitoring and Operations, Ch. 13 - Training and Onboarding

Phase 4: Incidents and regulatory reporting (M8–M12)​

DORA Art. 17–23 - Manage, classify and report ICT-related incidents

4.1 Centralised monitoring​

  • What: centralised logs of applications, infrastructure and access
  • Retention: in line with internal policy and the applicable regulatory framework
  • Protection: immutability, integrity and traceability
  • Reference: Ch. 12 - Monitoring and Operations

4.2 Detection, triage and response​

4.3 Parameterisation of external reporting​

  • What: translate the internal process into initial, intermediate and final report, within the time limits set by the RTS (Delegated Regulation (EU) 2025/301, Art. 5: initial notification ≤ 4 h after classification as major and ≤ 24 h after becoming aware; intermediate report ≤ 72 h after the initial notification; final report ≤ 1 month after the latest intermediate report) and inform the affected clients without undue delay (Article 19(3))
  • How: start from the impact data (Policy 32 §4.3), classify using the criteria of Article 18 and the thresholds of Delegated Regulation (EU) 2024/1772, with a monthly assessment of recurring incidents (CTX-DORA-R02), and use the content of Policy 32 §6.1 (templates of Implementing Regulation (EU) 2025/302)
  • Boundary: submission, channels and the relationship with the competent authority stay out of scope of the Manual
  • References: Ch. 12 - Monitoring and Operations, Ch. 14 - Governance and Contracting

Phase 5: Resilience testing (M12–M18)​

DORA Art. 24–27 - Validate the defensive posture and prepare for TLPT

5.1 Continuous testing​

  • SAST: integrated static analysis
  • DAST: dynamic analysis in staging, mandatory at any level in the DORA context, with testing of Internet-facing systems and applications (TST-005; CTX-DORA-P03)
  • PenTesting: manual testing guided by the threat model
  • Reference: Ch. 10 - Security Testing

5.2 Pre-deploy validation​

  • What: security checklist before production
  • Confirmation: requirements and evidence consistent with the risk level
  • Approval: formal where applicable
  • Reference: Ch. 11 - Secure Deployment

5.3 TLPT readiness and regulatory boundary​

  • What: prepare the technical foundation for TLPT exercises in eligible entities
  • Basis: threat model scenarios, scope, remediation and evidence
  • Boundary: eligibility, formal qualification of testers and attestation belong to the regulatory/compliance layer
  • References: Ch. 10 - Security Testing, Ch. 11 - Secure Deployment

Phase 6: ICT third parties and critical suppliers (M12–M18)​

DORA Art. 28–30 - Manage ICT third-party risk

6.1 Component suppliers and software supply chain​

  • What: SBOM + SCA
  • How: generate the SBOM; continuous scanning; update dependencies
  • Trail: inventory, findings, fixes and exceptions
  • Reference: Ch. 05 - Dependencies & SBOM

6.2 Contractual suppliers​

  • What: contractors, outsourcing and partners with access or technical responsibility
  • Lifecycle:
    • Onboarding: validation, SbD training, sandbox
    • Operation: controlled access, periodic review
    • Offboarding: access revocation, closure audit
  • Reference: Ch. 14 - Governance and Contracting

6.3 Concentration and exit​

  • What: assess concentration, critical dependencies and exit strategy
  • How: inventory, periodic revalidation, contractual clauses and transition plans
  • Boundary: the register of information (Implementing Regulation (EU) 2024/2956), concentration analysis and the entity's exit strategies stay out of scope of the Manual (relationship with the supervisor and business continuity); the transition and full data migration plans are a declared gap.
  • References: Ch. 05 - Dependencies & SBOM, Ch. 14 - Governance and Contracting

DORA Reading Checklist​

The list below makes it possible to validate the maturity of the AppSec and operational foundation for a defensible DORA reading. Final compliance still depends on regulatory parameterisation and additional institutional evidence:

  • Governance: Policy approved; clear chain of authority; periodic reporting
  • Risk framework: All apps classified and linked to requirements by level
  • Requirements: Versioned and traceable catalogue
  • Technical supply chain: SBOM generated and continuous SCA
  • Pipeline: Operational security gates
  • Monitoring: Centralised logs, adequate protection and retention
  • Incidents: IRP at any level (CTX-DORA-P01); DORA classification (CTX-DORA-R02) and the content of Policy 32 §6.1
  • Suppliers: Inventory, due diligence and operational lifecycle
  • Testing: SAST/DAST integrated; readiness for TLPT where applicable
  • Evidence: Data room with policies, tests, logs, contracts and reporting

What Each SbD-ToE Chapter Covers (Quick Reference)​

ChapterDORA ArticlesWhat It Does
Ch. 01Art. 5, 6Classification of apps by risk and proportionality
Ch. 02Art. 6, 8–15Minimum requirements, traceability and validation
Ch. 03Art. 8–15, 24–27Threat modelling for realistic scenarios
Ch. 05Art. 8–15, 28–30SBOM, SCA, software supply chain
Ch. 07Art. 8–15Secure CI/CD, gates, audited trail
Ch. 10Art. 24–27Continuous testing, readiness and evidence
Ch. 11Art. 8–15, 24–27Pre-deploy validation, rollback and containment
Ch. 12Art. 8–15, 17–23Monitoring, incidents, response and internal reporting
Ch. 13Art. 8–15Continuous training and upskilling
Ch. 14Art. 5, 6, 17–23, 28–30Governance, RACI, reporting and supplier lifecycle

The column shows where each chapter contributes, not that the article is covered. In Articles 28–30, the Manual covers parts of due diligence and of the clauses and supports evidence; the register of information and concentration analysis stay out of scope. In Article 19, Policy 32 §6 supports evidence, and the relationship with the authority stays out of scope. The detail is in Applicable requirements.

Simple Metric: Am I Well Prepared?​

Each affirmative answer scores one point and indicates the maturity of the AppSec baseline for a defensible DORA implementation:

  1. Governance: Do I have an approved policy and a clear chain of authority?
  2. Risk Management: Are all apps classified and linked to requirements?
  3. Security by Design: Are my requirements and controls traceable?
  4. Software Supply: Do I have SBOM and SCA in place?
  5. Operations: Do I have centralised monitoring with adequate retention and protection?
  6. Incident Response: Can I detect and classify incidents and configure their reporting?
  7. Vendor Management: Do I have a formal lifecycle for contractors and critical third parties?
  8. Testing: Do I run SAST/DAST and am I ready for TLPT where applicable?
  9. Evidence: Can I demonstrate all of this in an audit and in regulatory reporting?

Practical reading: the more positive answers, the more mature the AppSec baseline. Moving to full DORA compliance still requires what the Manual leaves out of scope, with the reason (business continuity and crisis management, physical and workstation security, register of information, regulated TLPT, reporting channels), formalisation by the management body and the closing of the gaps declared in Applicable requirements.

Critical Note: Exception Management under DORA​

The DORA framework requires exceptions to the implementation of the ICT security policies to be recorded and resilience to be ensured in those cases (Delegated Regulation (EU) 2024/1774, Article 2(2), point (c)); the acceptance of residual risks above the tolerance requires assigned roles, a justified inventory and annual review (Article 3, point (d)). The concrete approval level is defined by the entity.

What characterises an exception in SbD-ToE/DORA:

  • a formal deviation from a requirement;
  • technical and business justification;
  • a validity period (TTL);
  • a remediation plan and an owner;
  • an auditable documentary trail.

Who approves depends on criticality, the governance model and the applicable regulatory framework. In the Manual, the approval authority for exceptions goes no higher than the CISO (Policy 05 §6), and Critical is not acceptable as an exception at L3. In critical contexts, a DORA reading tends to require escalating the decision to the management body: that is the entity's decision, out of scope of the Manual.

Practical reading:

  • exceptions without formal approval undermine oversight;
  • some exceptions may be unacceptable in a defensible regulatory reading;
  • the Manual covers the process well, but final admissibility still depends on the regulatory context.

References: Ch. 02 - Security Requirements and Ch. 14 - Governance

Practical Implementation Resources​

For concrete support in implementing this playbook, see the following reusable examples:

These resources are reusable across multiple frameworks and show how to operationalise, outside the base Manual, the details that depend on the regulatory context, the supervisor and tooling.

Next Steps​

  1. Carry out an audit of current compliance against the matrix above
  2. Sequence the roadmap by criticality, gap and dependency
  3. Implement in phases, with versioned evidence
  4. Link the content of Policy 32 §6.1 to the authority's channels and take care of what stays out of scope (register of information, concentration, continuity)
  5. Periodically validate documentary and operational readiness

Full documentation: see SbD-ToE chapters 01–14 for technical and operational detail.

References​

  • SbD-ToE Manual: Chapters 01–14
  • DORA Cross-Check: Full normative analysis
  • DORA Regulation: Regulation (EU) 2022/2554

Version: 1.3 (aligned with the coverage matrix and the DORA context)
Date: September 2026
Note: This playbook complements the DORA normative analysis with bounded, evidence-oriented practical implementation.