What Is Risk Management?

Risk management is the standing process of identifying what could go wrong, deciding which of those things matter enough to act on, doing something about them, and revisiting the judgement as circumstances change.

Its purpose is to make security spending a decision rather than a reaction. Where it works, the organisation can explain why it is doing what it is doing; where it does not, it has a risk register nobody reads and a programme driven by whatever was in the news.

The four responses to a risk

Mitigate — reduce it with a control. Transfer — move some of the financial consequence, usually through insurance or a contract. Avoid — stop doing the activity that creates it.

Accept — decide to live with it. Acceptance is a legitimate answer and it is the one most often taken implicitly rather than explicitly, which is the difference between a decision and a drift.

Risk appetite has to be usable

Appetite statements are frequently written at a level that guides nothing: we take a prudent approach to risk. A usable statement sets thresholds someone can apply — which severity of finding must be remediated within what period, what residual exposure may be accepted and by whom.

Without that, every risk decision escalates or none does. The test of an appetite statement is whether a manager could use it to decide something without asking.

The register is a working document, not an artefact

Registers decay predictably: entries added during an assessment, owners who have moved on, mitigation dates long past, and a growing list nobody revisits because revisiting it is uncomfortable.

What keeps one alive is a small number of entries that genuinely matter, each with a named owner, a stated treatment and a review date, discussed at a governance meeting where decisions are actually taken.

Scoring, and the false precision problem

Likelihood and impact multiplied together produce a number, and the number is frequently treated as more meaningful than the estimates behind it. A high-impact, low-likelihood event and a moderate one can score identically while requiring entirely different responses.

Quantified approaches that express exposure in monetary ranges are more useful for comparing options and require data and effort. The workable middle is consistent qualitative scoring, with the reasoning recorded so the judgement can be revisited rather than recomputed.

It has to speak the business's language

Risks described in technical terms cannot be prioritised by the people who own the consequences. Unpatched vulnerability on the file server is not a business risk; the possibility that patient records become unavailable for a week is.

Translating one into the other is the core skill of the function, and it is what distinguishes a security programme that gets funded from one that is tolerated.

Where it sits organisationally

Security risk decisions made inside the technology function have an inherent conflict, because the people accountable for delivery and uptime are also assessing the risk of their own trade-offs. That is the structural argument for independent reporting rather than a comment on anyone’s integrity.

It also needs to connect to whatever enterprise risk process already exists. A separate security risk register that never reaches the board alongside financial, operational and regulatory risk will be funded as a technical concern rather than as a business one.

Where to start

Take your three largest current exposures and establish, for each, who has accepted it and until when. Where nobody has, that is the gap the programme exists to close.

See assessment methodologies. GuardsArm delivers security strategy.