Risk assessment in practice: a working method for GRC teams

Most risk assessments produce a spreadsheet that nobody reads after the meeting that signed off on it. The assessment was a ritual. The spreadsheet was the artifact of the ritual. Neither produced a decision. This article is a working method for risk assessment that is designed to produce decisions — specifically, decisions about where to invest control effort, what to accept, what to escalate, and what to watch. It draws from the ISO 31000 and NIST 800-30 methodologies but is deliberately practical: how to actually run this in a GRC program, not how to defend the choice of methodology in a footnote.

What risk assessment is for

A risk assessment is not a compliance artifact. It is a decision support tool. Its purpose is to give the people who decide where to invest control effort, attention, and money a defensible view of which outcomes matter most, how likely each one is, and what could be done about it. If the assessment does not produce decisions, you built an artifact instead of a tool. The first failure mode of most risk programs is that they are run for the auditor who wants to see a risk register, not for the executives who need to allocate effort. The register is a byproduct; decisions are the point.

Scoping the assessment

Scope is the first decision. A risk assessment scoped at 'the whole company' is almost always too broad to produce useful output. Scope to a unit of meaning: a product, a business line, a regulated program, a specific framework's control objectives, a new initiative. The narrower the scope, the more useful the output. Organizations that run one annual company-wide risk assessment produce one annual ritual. Organizations that run four or five focused assessments across the year — each scoped to a unit that can be acted on — produce a running view of enterprise risk that the executives actually use. The annual roll-up is a consolidation, not a primary instrument.

Identification: assets, threats, consequences

Risk identification is the step most programs rush through because it feels obvious. It is not obvious. Start with assets: what does your organization have that is valuable or critical? Data, systems, processes, relationships, licenses, people. For each asset, ask what could go wrong: confidentiality, integrity, availability failures, but also non-cyber failures — legal, operational, reputational, regulatory. For each failure mode, ask what the consequence would actually be — not in the abstract, but in concrete terms. 'Unauthorized access to customer PII' is not a consequence; it is a threat event. 'Regulatory fine under DPDPA, loss of customer trust, board-level incident response' is the consequence. The consequence is what the executive is being asked to tolerate.

Analysis: likelihood and impact

Likelihood and impact are scored on whatever scale your program has chosen. Three-by-three is too coarse. Five-by-five is standard and defensible. Seven-by-seven introduces false precision and is harder to calibrate. The scoring scale is less important than the calibration — the shared understanding of what each level actually means. 'High likelihood' needs to mean the same thing to the CISO, the compliance manager, and the business owner, or the scores are noise. Publish a calibration sheet with examples: 'High likelihood: equivalent to a one-in-three chance of occurring within the next twelve months, based on a combination of threat intelligence, historical incidents in the sector, and current control maturity.' Without a calibration sheet, every scoring session rederives its definitions from scratch.

Inherent, control, and residual risk

A rigorous assessment distinguishes three layers. Inherent risk is the level of risk before any controls are considered. Control effectiveness is the degree to which the controls in place actually reduce that risk. Residual risk is what is left after controls are accounted for. Programs that score only residual risk cannot tell you where they should invest — residual risk is the end of the story, not the beginning. Programs that score only inherent risk cannot tell you where the controls are earning their keep. Scoring both, and the control effectiveness in between, gives you a defensible answer to the question 'what happens if we stop doing X?' — which is the question every budget conversation eventually reduces to.

Treatment: the four options

For each risk, one of four things happens. Accept: the residual risk is within appetite and nothing more will be done. Document the accepter, the basis, and the review date. Treat: add, strengthen, or change controls to reduce likelihood or impact. Transfer: move the risk to another party — insurance, a vendor with an SLA, a contractual indemnity. Avoid: stop the activity that generates the risk. Most programs lean hard on 'treat' because it is the option that feels most like action. The other three are equally valid choices. The thing that makes a program credible is not the ratio of treat-to-accept; it is the discipline with which every accept decision is documented, owned, and revisited. A risk register full of un-reviewed accepts is a graveyard.

The review cadence

A risk assessment is worth the paper it is printed on for approximately one quarter — less if the environment is moving quickly. Build a review cadence into the program. At minimum, every accepted risk has a review date; every treated risk has a close date and an effectiveness re-check after treatment; every register as a whole is walked quarterly. Use the quarterly review to ask three questions about every risk: is it still relevant, is the scoring still accurate, and is the treatment still tracking? Register entries that cannot answer any of these three should be retired, re-scoped, or escalated. The register is a living document; when it stops moving, it has started dying.

Common failures we see

A short tour. First, heat map as theater — the quarterly heat map is produced, presented, and then nothing in the program changes because of it. Second, shared scoring without calibration — five people in the room each score 'high' differently, and the score is whatever the most senior person said. Third, missing consequence — the risk is described in threat terms, not outcome terms, and the executive can't tell what is actually at stake. Fourth, stale acceptances — half the register is accepted risks that were accepted two years ago under different conditions and have never been revisited. Fifth, no feedback loop from incidents — an incident happens, it is handled, and the risk register is never updated with what the incident taught. None of these failures is about sophistication. They are about discipline. A risk program that fixes these five things is ahead of most of its peers.

Tags