Skip to main content

Residual Risk Analysis

Residual risk is the risk that remains after the effective application of the defined controls, and it is the factual basis for any conscious decision to accept, further mitigate or reject.

In Security by Design – Theory of Everything (SbD-ToE), residual risk is not an abstract value, but the result of a contextual assessment that considers:

  • the criticality level of the application (L1–L3),
  • the attributes of the risk,
  • the actual effectiveness of the controls,
  • and the available evidence.

This file complements the risk classification and acceptance model by introducing the logic of “before and after controls”, in an operational and auditable way.


🔢 Fundamental definitions​

  • Gross (inherent) Risk
    Risk identified before the application of controls, resulting from the combination of exposure, data and impact.

  • Residual Risk
    Risk remaining after the effective application of controls, considering:

    • actual reduction of impact,
    • increase in detectability,
    • improvement in evidentiability,
    • and limitation of reach or surface.
  • Acceptable Risk
    Maximum limit of residual risk tolerated by the organisation, depending on the application's level (L1–L3).

📌 In SbD-ToE, residual risk does not result from a simple mathematical subtraction, but from a conscious reassessment of the attributes of the risk after control.


🧠 Relationship with the E/D/I model​

Residual risk analysis must always be consistent with the application's E/D/I classification:

  • controls do not retroactively change the exposure or the data processed;
  • controls may:
    • reduce impact,
    • limit the likelihood of exploitation,
    • increase detection,
    • and improve evidence.

Whenever the application of controls does not materially change the relevant attributes of the risk, the residual risk remains high, even if “theoretical” controls exist.


🧩 Practical assessment of residual risk​

The assessment of residual risk must explicitly answer the following questions:

  • Are the controls implemented and active?
  • Is their effectiveness verifiable and evidentiable?
  • Is there effective human validation, where applicable?
  • Is the residual behaviour deterministic and reproducible?
  • Is the residual impact compatible with the application's level?

The absence of a positive answer to any of these questions prevents valid acceptance of the risk.


📝 Illustrative example (non-normative)​

Scenario: Exposed API with strong authentication

Dimension assessedBefore controlsAfter effective controls
Exposure (E)33 (remains exposed)
Data Type (D)22
Impact (I)32 (abuse limitation, rate limiting)
DetectabilityLowHigh (alerts, logging)
EvidentiabilityLimitedHigh (logs, metrics)

👉 The residual risk is reduced, but not eliminated.
Its acceptance depends on the application's level and on the available evidence.


⚖️ Role of residual risk in the decision​

Residual risk must be compared with the acceptance thresholds defined by application level:

Application LevelMaximum Acceptable Residual Risk
L1 (low criticality)up to 9
L2 (medium criticality)up to 6
L3 (high criticality)up to 4

📌 These values assume adequate evidence and effective control.
Without sufficient evidence, residual risk cannot be considered low, regardless of the estimated value.


❌ Situations in which residual risk is not acceptable​

It is not acceptable to consider residual risk tolerable when:

  • the controls are not demonstrably active;
  • the decision depends exclusively on implicit trust in automation or tooling;
  • the results are not reproducible or verifiable;
  • there is significant legal, regulatory or reputational impact;
  • the application is L3 and the residual risk depends on non-deterministic validation.

🔄 Integration with the lifecycle and with GRC​

  • Residual risk must be reassessed whenever a relevant change occurs in:
    • architecture,
    • data,
    • exposure,
    • automation or process.
  • It must integrate:
    • release gates,
    • security review artefacts,
    • and GRC systems with explicit thresholds.
  • Residual risk is not permanent: it has a deadline, a context and responsible persons.

📌 Final recommendation​

Every residual risk acceptance decision must be:

  • formally recorded;
  • justified with technical evidence;
  • compatible with the application's level;
  • time-limited and subject to reassessment.

Residual risk is not an “inevitable remainder”,
it is a conscious decision about what the organisation is willing to take on, here and now.