Risk treatment and decision (Workshop 5)¶
What you'll be able to do in this chapter
- Choose a treatment for each evaluated risk: reduce, share, avoid or retain.
- Build an action plan whose measures link to the Module 3 applied controls — strengthening or extending existing ones, or adding new controls to the same framework.
- Drive inherent risk down to a residual level and have the right person accept it.
The workshop where analysis becomes decision¶
Everything so far has been analysis: what matters, who would attack it, how, how bad. EBIOS RM's final workshop turns that into decisions and an action plan. This is where the analysis becomes actionable, and where its connection to Module 3 becomes operational: most controls you decide here extend the applied controls you already built, and where a scenario needs one the baseline never had, that new control is folded into the same framework. Risk and compliance stay one system.
Four ways to treat a risk¶
Every evaluated risk gets a deliberate treatment decision, chosen from four options. Naming the choice matters, because "we'll look into it" is not a decision.
| Treatment | What it means | A Scaldimet example |
|---|---|---|
| Reduce | Add or strengthen controls to lower likelihood or severity | Segment Beta's OT network and monitor the contractor's access, cutting the line-halt likelihood |
| Share | Transfer part of the risk to another party | Cyber insurance for ransomware loss; contractual liability on a supplier |
| Avoid | Remove the exposure entirely | Disconnect an unsupported system that is not essential, ending the risk it carries |
| Retain | Accept the risk as it stands, knowingly | Accept a low-severity, low-likelihood risk rather than spend to treat it |
Most serious risks are reduced, because avoidance is often impossible (Scaldimet cannot disconnect its production line) and sharing only covers part of the loss (insurance does not un-stop the line or restore the OEM's trust). For Scaldimet's lead risk, the treatment is to reduce: the bespoke controls the scenarios revealed, segmentation, monitored access, compensating controls around the unpatchable OT.
The action plan, linked to applied controls¶
A treatment decision without an action plan changes nothing. EBIOS RM calls the output a continuous-improvement plan: each measure with an owner, a deadline and a cost, sequenced into milestones. A measure that names no owner and no date commits no one and will not happen.
The important point, and the reason this course taught compliance before risk, is that each treatment measure links back to an applied control. The scenario analysis did not discover a need for controls in the abstract; it discovered that specific controls (the segmentation and access-monitoring you scoped as applied controls in Lesson 3.5.A) must be strengthened or added to drive this risk down. So the action plan does not create a separate set of risk-driven tasks alongside the compliance programme. It feeds the same control set. A control now carries both its compliance rationale (the framework requires it) and its risk rationale (this scenario needs it), and progress on the control is progress on both at once. This links the risk treatment to the control environment established in Module 3.
Sometimes a scenario reveals a risk that the baseline does not address, and the treatment requires a control that is not already in the framework. This is a normal outcome of risk analysis: once compliance has established the baseline, risk analysis can identify additional controls that the baseline does not cover.
When this happens, do not leave the new control as a separate risk-treatment task. Develop and document it to the same standard as other applied controls (Lesson 3.5): define its objective, assign an owner, establish how it will be tested, and maintain an evidence trail. Then add it to the control framework. From that point, it is an applied control like the others: it is operated, tested and subject to the control and audit processes described in Chapter 3.6.
If you run ISO 27001, the control should also be reflected in the ISMS documentation and the Statement of Applicability where relevant. Clause 6.1.3 requires the organisation to determine the controls necessary to treat its information-security risks, compare them with the controls in Annex A, and justify the inclusion or exclusion of controls in the Statement of Applicability. Annex A is therefore a reference control set, not a limit on the controls an organisation may implement. An additional control can be justified by the organisation's own risk assessment even when no framework specifically requires it.
Adding such a control follows the governance process for the control framework (Lessons 2.3 and 2.4); the risk analyst does not decide this alone.
One caution: not every treatment becomes a control. A recurring, testable safeguard with a defined objective, such as segmentation, monitored access, or a new detection rule, can become a control and join the framework. A one-off remediation task, such as replacing a single end-of-life server by a defined date, closes a gap but is not a standing control; it remains an action in the treatment or remediation plan. Treating every task as a "control" would unnecessarily expand the framework and make the term less meaningful.
Residual risk and acceptance¶
After treatment, you re-evaluate: with the new controls in place, where does the risk now sit on the matrix? That is the residual risk (in the operational reading of Lesson 4.5.B: the socle plus the bespoke treatment). The line-halt risk, treated by segmentation and monitored access, might fall from intolerable to a tolerable level.
Whatever residual remains must be formally accepted by the right person: the risk owner, and for a serious risk, the management body (the accountability of Module 6, the duty of NIS2 Article 20). Acceptance is a deliberate act by someone with the authority to carry the consequence, not a default that happens because no one decided. EBIOS RM is explicit that the person accountable for accepting residual risk is identified up front, precisely so this final decision lands on a named owner rather than drifting.
Application: treat the lead risk¶
On paper, take Scaldimet's line-halt risk and write its treatment: choose the option (reduce), list two or three specific measures, and for each name the owner, a deadline, and the Module 3 applied control it links to. Then state the expected residual level and who must accept it.
Model answer (open after you've drafted yours)
Risk: multi-day halt of the French line from an OT compromise. Option: reduce (avoiding means stopping production; insurance does not stop the halt; retaining is outside appetite).
Measures, each linked to a Module 3 applied control:
-
Segment Beta's OT into zones with one monitored conduit to IT — owner: Beta operations director; deadline: [date]; links to the segmentation applied control (PR.IR-01, Lesson 3.5.A).
-
Put the contractor's remote access behind per-session, logged, reviewed authentication — owner: Beta operations director; links to the third-party-access applied control.
-
Wrap the unpatchable SCADA in compensating controls under a time-bound exception (Lesson 2.3), with a replacement plan — links to the lifecycle applied control (ID.AM-08.2).
Residual: severity stays 4, but likelihood drops from 3–4 to 2 once OT is segmented and access monitored — out of the intolerable band into "tolerate with monitoring".
Acceptance: the risk owner, and given severity 4, formally the management body (Lesson 6, NIS2 Art 20). The key move: for Scaldimet these measures happen to strengthen or extend existing applied controls (segmentation, access, lifecycle), so progress counts for both risk and compliance. Had a scenario instead needed a control the baseline lacked, you would build and document it to the same standard and add it to the framework, after which it is an applied control like any other.
Key takeaway
Treatment turns analysis into decision: each risk is deliberately reduced, shared, avoided or retained, with serious risks usually reduced. The decision becomes an action plan of measures with owners, deadlines and costs, and the defining move is that treatment feeds the same control set as compliance rather than a parallel programme: most measures strengthen or extend an existing applied control (which then carries both a compliance and a risk rationale), and any genuinely new, risk-driven control is documented to the same standard and added to the framework, so it is thereafter operated, tested and audited like the rest. After treatment you re-evaluate to a residual level (socle plus bespoke controls, the operational reading), which the risk owner, and the board for serious risk, must formally accept. This is the practical benefit of establishing the socle before the bespoke risk analysis.