Practical Cases of Risk Classification
The following examples illustrate different legitimate ways of classifying applications in SbD-ToE, demonstrating:
- direct application of the E/D/I model;
- impact of data and regulatory context;
- use of conservative classification by operational criticality;
- influence of advanced automation (incl. AI) where relevant.
The objective is not to find the “perfect classification”,
but to ensure the appropriate level of care and control.
📝 Case 1 - Public E-commerce Platform
Context
Online sales platform, with direct payments and integration with third parties.
- Exposure (E): Public (web + mobile app) → 3
- Data Type (D): Personal data + payment data → 3
- Impact (I): Financial, reputational and legal → 3
Classification:
E + D + I = 9 → L3 (High Risk)
Rationale
Even without considering past incidents, the combination of public exposure, sensitive data and direct business impact justifies maximum rigour.
Practical implications:
- Complete and traceable security requirements
- Formal threat modelling
- Continuous SBOM and SCA
- Continuous DAST, fuzzing and regression validation
📝 Case 2 - Internal Hospital HR Portal
Context
Internal application, accessible only on the hospital network, used for HR management.
- Exposure (E): Internal → 1
- Data Type (D): Clinical and financial data of staff → 3
- Impact (I): Legal (GDPR), sensitive confidentiality → 3
Classification:
E + D + I = 7 → L3 (High Risk)
Rationale
Low exposure does not offset the nature of the data or the legal impact.
This is a classic example of a common error avoided by the SbD-ToE model.
Important note
This case demonstrates that:
“internal” does not mean “low risk”.
📝 Case 3 - B2B Invoicing System
Context
System used by authenticated business customers, with ERP integration.
- Exposure (E): Authenticated external access → 2
- Data Type (D): Financial and customer data → 2
- Impact (I): Operational and financial → 2
Classification:
E + D + I = 6 → L2 (Medium Risk)
Rationale
Relevant system, but with manageable impact and no critical regulated data.
Practical implications:
- Formal but proportional security requirements
- Simplified threat modelling
- SCA with a severity policy
- Regular, not continuous, security testing
📝 Case 4 - Internal Task Management Tool
Context
Simple application, used internally for task management.
- Exposure (E): Internal → 1
- Data Type (D): Non-sensitive → 1
- Impact (I): Low → 1
Classification:
E + D + I = 3 → L1 (Low Risk)
Rationale
Low exposure, low impact and the absence of sensitive data justify minimal controls.
Practical implications:
- Linters and basic code review
- General security good practices
- No requirement for advanced testing
📝 Case 5 - Core Service with Critical DRP (Conservative Classification)
Context
Central business service, classified as Critical in the DRP:
- RTO < 1h
- RPO ≈ 0
- An outage halts the organisation's operations
Strict technical analysis:
- Controlled exposure
- Moderately sensitive data
Decision adopted:
- Direct classification as L3, by operational criticality
Rationale
Even if the technical risk could be L2, the cost of failure justifies
treatment as a high-risk application.
This is an explicit example of deliberate over-classification,
accepted and recommended in SbD-ToE.
📝 Case 6 - Application with Advanced Automation (incl. AI)
Context
Internal application that uses assistive automation to:
-
generate code,
-
approve configuration changes,
-
execute actions with real impact.
-
Exposure (E): Internal, but with external integrations → 2
-
Data Type (D): Code, configurations, occasional secrets → 2
-
Impact (I): Automatic changes with real effect → 3
Classification:
E + D + I = 7 → L3 (High Risk)
Rationale
The classification is not high because of “using AI”,
but because there is:
- delegation,
- speed,
- and impact without mandatory human validation.
📌 Conclusion
These examples demonstrate that:
- risk classification is not mechanical;
- SbD-ToE accepts conservative and pragmatic decisions;
- the ultimate objective is always:
to apply the right level of care, control and validation.
The coherence of the model lies in proportionality,
not in an obsession with the perfect score.