Cybersecurity as Business Risk and Governance · Lesson 3

Risk Assessment, Prioritization, and Treatment

7 min read

Lesson objectives

Create a simple risk register containing scenario, owner, likelihood, impact, controls, and response.
Use a qualitative prioritization scale while explaining its limits and avoiding false precision.
Distinguish inherent from residual risk and connect the response to an owner, date, and evidence.

A risk register is a decision tool, not a warehouse of worries

A simple cybersecurity risk register brings together the information decision-makers need to compare and track risks. A foundational register does not need dozens of columns. It usually needs a risk identifier, scenario description, affected asset or process, owner, qualitative likelihood and impact, priority, current controls, planned response, and a date or status. The goal is not to create a falsely precise number; it is to preserve the chain between “what could happen?”, “what did we decide?”, and “who follows through?”.

NIST CSF Current and Target Profiles can be used to compare the present state with the desired state and identify gaps, while linking cybersecurity with enterprise risk management helps prioritize and communicate risk in business terms. In this diploma we use the same idea at a smaller scale: record what we know today, define what needs to change, and connect the gap to a risk and decision. The register is not a substitute for a CSF Profile or a full enterprise-risk system; it is a practical learning tool for preserving the reasoning.

Field	What do we record?	What do we avoid?
Risk scenario	Event + weakness/condition + asset + impact	Threat name only
Owner	Authorized risk decision-maker	Generic team with no authority
Likelihood	Relative estimate grounded in what is known	Invented percentage
Impact	Consequence to service, data, money, or commitment	A label such as “very high” with no explanation
Response	Action, owner, and date, or justified acceptance	“Fix later”

Relative prioritization is better than false precision

A beginner may use a simple qualitative scale from 1 to 5 for likelihood and 1 to 5 for impact, then multiply them to create a prioritization indicator. These are not scientific probabilities or expected monetary values. They are an internal comparison aid for discussing why one risk receives more attention than another. To prevent the number from becoming an illusion, record the rationale: why was likelihood rated 4? What supports impact 5? What new evidence would change the estimate? A mature organization may use a different method, but the transparency rule remains useful.

We should also distinguish inherent from residual risk. Inherent risk is a view of the risk before considering relevant existing controls or in their absence, while residual risk is what remains after those controls are applied. In a simple model we may start with an initial estimate and then ask: what controls actually exist? Do we have evidence they work? How do they change likelihood or impact? We should not reduce a score merely because “there is a policy” when the policy is not implemented or we have no evidence of coverage.

Exercise

Exercise 1 — about 12 minutes: create three rows in a fictional risk register: (a) shared accounts in an important system, (b) backups that are not tested, and (c) a third-party supplier with access to operational data. For each row write a risk scenario and owner, assign a 1–5 likelihood and impact with a one-sentence rationale, then rank the rows. After ranking, write one new piece of information that could change the priority of each risk.

Check your answer

Guided answer: there is no single “correct” set of scores because the scenario is intentionally incomplete. Quality comes from consistency and reasoning: shared accounts may increase misuse likelihood and reduce accountability; untested backups may increase recovery impact; supplier access depends heavily on data type, controls, and contract. New information might be usage logs, a recovery-test result, or the supplier's actual access scope. A good register makes these questions visible.

A response should change the risk or our decision about it

After prioritizing a risk, we need a clear response. At a foundational level we can think in four paths: reduce the risk through controls, avoid it by changing the activity, share or transfer parts of it contractually or through insurance where appropriate, or accept it through an authorized and justified decision. “Transfer” does not mean responsibility disappears; relying on a supplier or insurance may change some consequences or obligations but does not erase all exposure. Every response needs an owner, a target date, and evidence of completion or a documented acceptance decision.

Exercise

Exercise 2 — about ten minutes: risk R-01 scored 20. After enabling additional authentication, removing unused accounts, and adding alerts for administrative privilege changes, the team decides likelihood falls from 4 to 2 while impact remains 5. Calculate the new indicator, then explain why the calculation alone is not enough to accept the residual risk. What evidence would you want before lowering likelihood?

Check your answer

Answer: the new indicator is 10. That does not prove the risk is “acceptable”; acceptance depends on tolerance boundaries, owner authority, and evidence quality. We might want a coverage report showing targeted accounts use additional authentication, a current list of active accounts, and evidence that the alert works. Lesson takeaway: a risk register links scenario, owner, estimate, controls, and response, while the score is a transparent prioritization aid rather than a precise incident probability.

Lesson summary

The lesson builds a simple risk register, uses qualitative likelihood and impact as a prioritization indicator rather than scientific probability, distinguishes inherent and residual risk, and selects a treatment with an owner, evidence, and follow-up.