Cybersecurity risk management: the complete guide

Most risk registers are archaeology: a list assembled once, scored optimistically, and reviewed when an auditor asks. A risk process earns its cost only if it changes what the organisation does — what gets funded, what gets accepted, and what gets escalated.

The cycle

1. Identify — what could stop you achieving your objectives.
2. Analyse — how likely, and how bad.
3. Evaluate — compare against appetite to decide whether it is acceptable.
4. Treat — avoid, reduce, transfer or accept.
5. Monitor and review — because both the risk and the controls change.

Frameworks require a documented, repeatable method producing comparable results. They do not prescribe the method — which means the burden is on you to make it consistent enough that two assessors reach similar answers.

Identification: get past the obvious

Risk workshops produce the same list everywhere: ransomware, phishing, insider, outage. Useful sources of the risks you would otherwise miss are your own incident history, near misses, audit findings, the dependency map from your business impact analysis, and — most productively — asking engineers what they are worried about. They usually know.

Write risks as cause, event and consequence rather than as one word. "Ransomware" is a category; "an unpatched internet-facing service is exploited, encrypting the customer database, halting order processing for days" is a risk you can assess and treat.

Scoring that survives challenge

Record inherent and residual separately. The gap between them measures how much your controls are carrying — which is what tells you where a control failure would be catastrophic, and what justifies continued spend on controls that make a risk look boringly low.

Two disciplines keep scores honest: define each scale point concretely (attach monetary and frequency bands, not adjectives), and make residual scores reflect how controls actually operate rather than how they are designed. A control failing its tests should not be reducing anything.

Appetite and tolerance

Appetite is how much risk the organisation is willing to take in pursuit of its objectives; tolerance is the practical boundary on a specific risk. Without them, "high risk" is an adjective rather than a trigger. With them, exceeding tolerance automatically means treat or escalate — which is what turns a register into a decision system.

Treatment, and the honest fourth option

Avoid, reduce, transfer, accept. Two cautions: transfer moves financial consequence, not the event — insurance does not restore your service or discharge your regulatory duty. And acceptance is a real decision requiring a real owner: a business leader with authority over the activity, recorded, with a review date. Acceptance by the security team is not acceptance.

Reporting so it lands

Boards do not act on a heat map. What moves decisions is a small number of named risks, what changed since last time, what is outside appetite, and the specific decision being asked for. Trend beats snapshot; exposure in money beats colour where you can produce it.

Where processes fail

• Owned by security rather than by the business, so nobody with budget is accountable.
• Reviewed annually, so it is always out of date.
• Scored once and never re-scored when controls fail.
• Too granular — three hundred risks is an inventory, not a decision aid.
• No link to controls, so nobody can say what would actually reduce the number.

Detailed guidance

Key takeaways

• Write risks as cause, event and consequence — not one-word categories.
• Record inherent and residual; the gap shows what your controls are carrying.
• Appetite turns a register into a decision system.
• Acceptance needs a business owner and a review date, or it is not acceptance.