FAQ - Frequently Asked Questions

Scope and Applicability​

Who is SbD-ToE for?​

Organisations that:

• Develop software (own products, internal tools, apps for clients).
• Contract out development (outsourcing, contractors, system integrators).
• Acquire critical SaaS/PaaS/IaaS and need to validate the supplier's security.
• Operate critical ICT infrastructure (on-prem, cloud, hybrid).
• Are subject to regulation (NIS2, DORA, CRA, GDPR) and need technical evidence of compliance.

SbD-ToE is not only for software companies. It is for any organisation with critical ICT systems.

My organisation does not develop software. Is SbD-ToE relevant?​

Yes, very probably.

Even without in-house development, most organisations:

• Acquire or contract software (ERP, CRM, core systems, SaaS).
• Operate infrastructure (servers, cloud, network).
• Manage sensitive data (customers, employees, financial).

SbD-ToE helps to:

• Classify applications by criticality (Ch. 01).
• Define security requirements for suppliers (Ch. 02, 14).
• Validate the security of acquired software (Ch. 10: pentests, audits).
• Manage suppliers in line with DORA/NIS2 (Ch. 05, 14: SBOM, contracts, SLAs).
• Operate with resilience (Ch. 12: logs, backups, incidents, monitoring).

Example: A bank that uses SAP/Oracle (and does not develop) still needs to:

• Classify the ERP as L3 (critical).
• Require an SBOM and patch SLAs from the supplier.
• Integrate logs into the corporate SIEM.
• Run annual pentests.
• Document everything for the DORA audit.

→ Applicable chapters: 01, 02, 05, 10, 12, 14.

What is the difference between SbD-ToE and ISO 27001?​

In practical terms:

• ISO 27001 says: "Technical vulnerabilities must be managed" (control A.8.8 in the 2022 edition).
• SbD-ToE says: "Ch. 05 - How to do SBOM, SCA, patching with SLAs, formal exceptions, CI/CD integration".

Can they coexist? Yes, and they should. SbD-ToE provides the "technical how" that can support ISO 27001 implementation and audit.

Compliance and Regulation​

Does SbD-ToE cover DORA/NIS2/CRA/GDPR?​

Yes, but in a different way:

Principle: SbD-ToE provides the reusable technical core. The legal-administrative parts (contracts, legal bases, formal declarations) are handled by Legal/GRC.

Can I use SbD-ToE as compliance evidence?​

As supporting evidence, yes. Each chapter produces reusable artefacts:

• L1–L3 classification matrix → supports DORA Art. 8, NIS2 Art. 21 and GDPR Arts. 25 and 32.
• SBOM per release → evidence for the CRA (Annex I, Part II, point 1; technical documentation in Annex VII); supports DORA Art. 28, without replacing the register of information.
• SAST/DAST/pentest reports → support DORA Arts. 24 and 25, NIS2 Art. 21 and CRA Annex VII, point 6.
• Incident runbook → supports DORA Arts. 17 to 19, NIS2 Art. 23 and GDPR Arts. 33 and 34 (deadlines in Policy 32 §6).
• Supplier contracts → support DORA Arts. 28 to 30, NIS2 Art. 21(2)(d) and GDPR Art. 28.

The same set of evidence can support several regimes and audits; compliance remains the organisation's judgement. What each regime requires, obligation by obligation, is in the normative cross-check.

What about certification? Is there an SbD-ToE certification?​

No. SbD-ToE is not a certification scheme. It is an internal operational framework.

But: SbD-ToE evidence can be reused to accelerate and simplify external certifications:

• ISO 27001 (ISMS) - Annex A technical controls (no control-by-control mapping)
• EUCC (adopted European scheme; EUCS and EU5G are not yet adopted) - product/service security evidence
• SOC 2 Type II (for cloud/SaaS) - demonstration of Trust Service Criteria

Important: Reusing evidence reduces the effort (80–90%), but does not replace the independent audit/assessment required for formal certification.

See: ENISA/CSA Certification

Implementation​

How long does it take to implement SbD-ToE?​

It depends on the initial maturity:

Note: Implementation is iterative (not "big bang"). It starts with critical apps (L3) and expands progressively.

Do I need to implement every chapter?​

Not necessarily. It depends on the context:

Mandatory for all:

• Ch. 01 (Classification)
• Ch. 02 (Minimum requirements)
• Ch. 12 (Monitoring and operations)
• Ch. 14 (Governance)

Conditional:

• Developing software? → Ch. 06–07 (SDLC/CI-CD), Ch. 10 (testing).
• Using containers? → Ch. 09.
• Using IaC? → Ch. 08.
• L3 (critical) apps? → Ch. 03 (Threat Modelling), Ch. 04 (Architecture).
• DORA/CRA? → Ch. 05 (SBOM mandatory).

Principle: Implement what is relevant and proportional to the risk.

How much does it cost to implement SbD-ToE?​

There is no licence cost (it is an open framework). The costs are internal (team time) and tools:

ROI: Fewer incidents, faster compliance, reuse of evidence, lower audit costs.

Exceptions and Deviations​

What are "exceptions" in SbD-ToE?​

Exception = a formal deviation from a security requirement, with:

• Technical or business justification.
• Approval by a designated authority (AppSec/CISO/Board, depending on criticality).
• Validity period (TTL).
• Remediation or compensation plan.
• Audited trail.

Example: "Deploy of an L3 app with a known High CVE, but with a compensating WAF, approved by the CISO, TTL 30 days, patch scheduled."

See: Ch. 02 addon 08, Ch. 05 addon 09, Ch. 14.

Are all exceptions allowed?​

No. There are categories of unacceptable exceptions:

• Critical RCE vulnerabilities without compensation.
• Absence of MFA in L3 apps.
• Unencrypted sensitive data.
• Regulatory compliance violations (e.g. DORA/NIS2/GDPR).

Rule: If the regulator or the criticality does not allow it, it is not an exception - it is non-compliance.

See: DORA cross-check - Exceptions

Relationship with Other Frameworks​

SbD-ToE vs. OWASP SAMM/BSIMM/SSDF?​

Convergence: They all speak of threat modelling, SAST/DAST, SBOM, testing. SbD-ToE operationalises it with addons, templates, checklists.

Can I use SbD-ToE with DevSecOps?​

Yes, it is the core of SbD-ToE.

• Ch. 06–07: Integration of security into pipelines (shift-left).
• Ch. 10: Continuous testing (SAST/DAST/fuzzing).
• Ch. 08–09: IaC and containers (secure infrastructure-as-code).
• Ch. 12: Observability and rapid response.

Principle: Automated security, not manual.

Multi-Jurisdictional Regulation​

I am subject to DORA + NIS2 + GDPR. Is there duplication?​

Very little. Most technical controls converge:

• Vulnerability management → DORA Art. 5, NIS2 Art. 21, CRA (SBOM/patching).
• Incidents → DORA Art. 18 (24h), NIS2 Art. 23 (24h/72h/1M), GDPR Art. 33 (72h).
• Suppliers → DORA Art. 26–28, NIS2 Art. 21, GDPR Art. 28.
• Testing → DORA Art. 19–20, NIS2 Art. 21.

Strategy:

1. Implement SbD-ToE Ch. 01–14 (common technical core).
2. Use specific playbooks for adjustments (reporting fields, templates).
3. A single incident runbook with channel branching (DORA → EBA, NIS2 → CSIRT, GDPR → DPO).

See: DORA & NIS2 Convergence

Metrics and Continuous Improvement​

How can I measure whether I am "SbD-ToE compliant"?​

Key metrics by chapter:

Single dashboard with aggregated KPIs: "SbD-ToE Compliance Score".

Is SbD-ToE "one-time" or continuous?​

Continuous.

• New apps → classify (Ch. 01).
• New CVEs → patch/exception (Ch. 05).
• Architectural changes → re-TM (Ch. 03).
• New suppliers → onboarding (Ch. 14).
• Quarterly exercises → incidents/DR (Ch. 12).

Formal review: Annual (policies, exceptions, gaps).

Next Steps​

Where do I start?​

1. Read: How to use this manual
2. Inventory: Ch. 01 - List and classify critical apps.
3. Gap analysis: Compare the current state vs. the Ch. 02 requirements.
4. Quick wins: Ch. 05 (SBOM), Ch. 12 (centralised logs), Ch. 14 (RACI).
5. Roadmap: Choose the relevant playbook (DORA, NIS2, CRA, GDPR).

Where can I get support?​

• Complete documentation: SbD-ToE Chapters 01–14
• Normative cross-checks: Section 002
• Practical playbooks: See each regulation
• Community: (to be defined - forum, GitHub Discussions, etc.)

Version: 1.0
Date: November 2025
Next review: May 2026