3.3 Risk Treatment & the Risk Register

Theory: Risk Treatment & the Risk Register

You have scored the risk (3.1) and perhaps priced it (3.2). Now what? Risk treatment is the decision about how the organization will respond to each risk. There are exactly four strategies, and choosing between them is a management judgment, not a formula. The decision is then written down in a risk register so that it can be acted on, tracked and revisited.

Diagram loads as you scroll.

The Four Treatment Strategies

The four risk treatment strategies

Avoid: eliminate the risk entirely by stopping the activity, decommissioning the system, or redesigning the process.

Mitigate: reduce the likelihood or the impact by patching the vulnerability, adding controls, or training staff.

Transfer: shift the risk (usually its financial consequences) to someone else through cyber insurance, outsourcing, or contractual liability.

Accept: acknowledge the risk and monitor it; appropriate when the cost of treatment exceeds the risk itself.

Strategy	What changes	MediCare Plus example
Avoid	The risky activity no longer exists	Decommission an old, unsupported file-sharing server that no one needs
Mitigate	Likelihood and/or impact goes down	Patch the EHR server, enforce MFA, run phishing-awareness training
Transfer	Someone else bears the financial loss	Buy cyber insurance; contract a vendor that is liable for breaches of the system it runs
Accept	Nothing is done except monitoring	Keep the separated guest Wi-Fi as it is and watch its logs

Common mistakes:

“Transfer removes the risk.” It does not. Insurance pays for the loss, but patient data is still leaked and the hospital’s reputation and legal duties remain. Transfer moves the financial consequence, not the event.

“Accept means ignore.” Accepting is a deliberate, documented decision with monitoring, ideally approved by someone with authority. An unrecorded, unexamined risk is not “accepted”, it is simply unmanaged.

Confusing Avoid with Mitigate. Avoid removes the activity or system completely; Mitigate keeps it but makes it safer.

Choosing a Treatment: Four Decision Factors

There is no formula that picks the strategy for you. It is a judgment call weighed against four factors:

Cost of treatment vs. cost of the risk: does fixing it cost more than the loss it prevents? (ALE from 3.2 answers this in money.)
Feasibility: is the fix technically and operationally realistic for this organization? A 3-person IT team cannot run a 24/7 security operations center.
Risk appetite: how much risk is leadership willing to tolerate?
Regulatory or legal requirements: some risks (for example, those involving patient data) must be treated regardless of cost.

A Rough Rule of Thumb

Risk level	Usual treatment
Critical / High	Avoid or Mitigate
Medium	Mitigate or Transfer
Low	Accept and monitor

The rule of thumb is not a rigid rule; always weigh it against the four factors. In the exam, a good treatment answer names the strategy and gives a one-sentence reason tied to one of the factors, e.g. “Mitigate, because patient data must be protected under PDPA regardless of cost, and patching is cheap and feasible.”

The Risk Register

A risk register is a living document that records every identified risk, its assessment, and the decision made about it, so that nothing gets forgotten and everyone can see the current picture.

The register turns a discussion into something the organization can act on, track and revisit. “Living” means it is updated whenever a new risk appears, a score changes, or a treatment is completed.

Example row (from the slides):

Asset	Risk	Likelihood	Impact	Risk Level	Treatment	Owner
Patient DB	Ransomware via phishing	3	5	High	Mitigate	IT Manager

(Check: $3 \times 5 = 15$ , which is in the High band 10–16.)

Columns of a Full Register

The course’s Risk Register template combines both assessment methods in one row:

Group	Columns
Identification	#, Asset, Risk description (threat + vulnerability)
Qualitative assessment	Likelihood (1–5), Impact (1–5), Score (L × I), Risk Level
Decision	Treatment strategy, Justification (one sentence)
Quantitative assessment	Asset Value, EF, ARO, SLE, ALE
Accountability	Owner

Why the owner matters. A risk with no owner is a risk nobody acts on. The owner is a specific role (e.g. “IT Manager”, “Data Governance Lead”) who is accountable for carrying out the treatment and reporting its status, not a vague group like “IT” or “everyone”.

In Class: Choose & Justify

In Activity 2, each group takes the risks scored in Activity 1, chooses Avoid, Mitigate, Transfer or Accept for each, writes a one-sentence justification (why this strategy and not another?), and begins filling in the Risk Register. The register built here becomes the input for Week 4, where risks are turned into policy.

Worked Examples

Exercise 1

Identify the treatment strategy in each MediCare Plus decision.

a) The hospital buys a cyber-insurance policy that covers breach-notification costs. b) The hospital shuts down a rarely used legacy remote-access server instead of patching it. c) The hospital enables multi-factor authentication on all EHR accounts. d) The hospital decides that the risk of visitors misusing the separated guest Wi-Fi is low, records the decision, and reviews its logs monthly. e) The hospital outsources payment-card processing to a payment provider that is contractually liable for card-data breaches.

Show solution ↓

Solution

Ask for each: is the activity removed, made safer, shifted to someone else, or kept as it is?

a) The financial loss is shifted to the insurer: Transfer. b) The system, and with it the risk, no longer exists: Avoid. c) The system stays, but MFA lowers the likelihood of account takeover: Mitigate. d) Nothing is changed except documented monitoring: Accept. e) The risky activity and its liability move to another party by contract: Transfer.

a Transfer, b Avoid, c Mitigate, d Accept, e Transfer.

Exercise 2

(Mini-case) A board member argues: “Ransomware on the patient database is only scored High, not Critical, and protection is expensive. Let’s just Accept it.” Using the four decision factors, explain why Accept is not appropriate and recommend a treatment.

Show solution ↓

Solution

Check the proposal against each factor:

Cost of treatment vs. cost of risk: a ransomware attack on patient records would stop clinical work (Impact 5, Severe); the expected loss is far larger than the cost of basic controls such as phishing training, patching and offline backups.
Feasibility: these controls are realistic even for a 3-person IT team.
Risk appetite: a hospital cannot tolerate losing access to patient records, because patients could be harmed.
Regulatory requirement: patient data is protected by law (e.g. Thailand’s PDPA), so this risk must be treated regardless of cost.

The rule of thumb also points the same way: High → Avoid or Mitigate. Avoiding is not possible (the hospital cannot stop keeping patient records), so the realistic choice is to reduce likelihood and impact.

Accept is not appropriate; the recommended treatment is Mitigate (e.g. phishing training, patching, MFA and tested backups).

Exercise 3

The guest Wi-Fi risk at MediCare Plus has an ALE of ฿8,000 per year and a qualitative level of Low. A consultant proposes a monitoring appliance costing ฿60,000 per year to protect it. Which treatment should the hospital choose? Justify your answer.

Show solution ↓

Solution

Cost vs. risk: the control costs ฿60,000 per year but the expected loss is only ฿8,000 per year. Spending ฿60,000 to prevent at most ฿8,000 is not justified.
Rule of thumb: a Low risk is usually Accept and monitor.
Regulation: the guest network holds no patient data, so no legal requirement forces treatment.

Accept (and monitor), because the treatment would cost about 7.5 times more than the loss it prevents.

Exercise 4

Write a complete qualitative risk-register row for this MediCare Plus risk: “A former contractor still has working EHR access 45 days after the contract ended, because access is not revoked when contracts end.” Include Asset, Risk, Likelihood, Impact, Score, Risk Level, Treatment, Justification and Owner.

Show solution ↓

Solution

Work through the row one column at a time.

Asset: EHR system (patient records).
Risk: unauthorized access to patient records by a former contractor whose access was never revoked (threat: former contractor; vulnerability: no revocation process).
Likelihood: 3 (Possible). The account already exists and works, but misuse requires the former contractor to decide to log in.
Impact: 4 (Major). Viewing or leaking patient records is a serious confidentiality breach with harm to patients’ trust and possible PDPA consequences.
Score: $3 \times 4 = 12$ → High (10–16).
Treatment: Mitigate.
Justification: revoking access immediately and requiring access removal whenever a contract ends is cheap, feasible, and required to protect patient data.
Owner: IT Manager (provisions and revokes access).

Asset	Risk	L	I	Score	Level	Treatment	Owner
EHR system	Former contractor retains EHR access (no revocation on contract end)	3	4	12	High	Mitigate	IT Manager

Score 12, High, Mitigate, owned by the IT Manager. (A score of 4 for likelihood or 5 for impact would also be defensible if well justified.)

Exercise 5

(Conceptual) Why is a risk register described as a living document, and why must every row have a named owner?

Show solution ↓

Solution

Living document. Risks change: new systems are added, new threats appear (such as autonomous AI agents), controls are completed, and incidents reveal that a likelihood was underestimated. If the register were written once and filed away, it would soon describe a hospital that no longer exists. Keeping it updated means nothing gets forgotten and everyone can see the current picture.

Named owner. A treatment decision only matters if someone carries it out. An owner (a specific role such as “IT Manager”) is accountable for completing the treatment, monitoring the risk and reporting progress. Without an owner, every department can assume someone else is handling it.

The register stays useful only if it is kept up to date, and each risk is acted on only if a named role is accountable for it.