Skip to main content

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.