Writing Risk Statements That Actually Say Something

Illustration for: Writing Risk Statements That Actually Say Something

The weakest point of most risk registers is not the scoring model or the tooling. It is the statements themselves. “Cyber attack”, “GDPR non-compliance” and “key person risk” tell the reader nothing about what might happen, to what, or why anyone should spend money on it. This post sets out a structure that forces clarity, with real-feeling rewrites.

The condition-event-consequence structure

A risk statement should answer three questions in one or two sentences.

• The condition is what is true today that creates the exposure. A fact, observable now.
• The event is what could happen as a result. Something with a probability, that either occurs or does not.
• The consequence is what it would cost you, in terms the organisation cares about.

A template that works is this one. “Because [condition], [event] could occur, resulting in [consequence].”

The structure does real work. The condition points at the treatment. The event is the thing you estimate likelihood for. The consequence is the thing you estimate impact for. When a statement resists scoring, it is almost always because one of the three parts is missing, and the assessors are silently guessing different missing parts.

Example risk statement split into condition, event and consequence, showing what each part drives

The three parts of a risk statement and the job each one does.

The consequence should be specific to your organisation. “Reputational damage” appears on every register in the country and moves no one. “Loss of the two NHS contracts that provide 40% of revenue, which require Cyber Essentials Plus” moves people.

Bad statements, rewritten

These four appear on live registers everywhere, and each one is followed by the version that earns its place.

“Ransomware”

A threat category, not a risk. It has no condition and no consequence, so it cannot be scored consistently or treated deliberately. Written properly it becomes this.

“Because the manufacturing file servers are not covered by offline backups and share a flat network with user workstations, a ransomware infection could encrypt production planning data, halting order fulfilment for an estimated one to two weeks and breaching contractual delivery terms with our three largest customers.”

“Lack of security awareness training”

A control gap dressed as a risk. The absence of a control is a condition, not an event, and left like this the register fills up with a shadow copy of the control framework.

“Because staff receive no phishing training and finance processes accept emailed payment instructions, an attacker could redirect supplier payments through business email compromise, resulting in direct losses (peer firms in our sector reported £100,000 to £250,000 per incident) and strained supplier relationships.”

“Non-compliance with GDPR”

A legal obligation restated. There is no event here, and you cannot ask “how likely is GDPR?”.

“Because personal data of around 200,000 customers is retained indefinitely across three legacy systems with no deletion process, a breach or a subject complaint could expose holdings well beyond our stated retention policy, resulting in ICO enforcement action, mandatory remediation at short notice, and loss of customer trust during contract renewals.”

“Key person dependency in IT”

Too vague to act on. Which person, which capability, what breaks?

“Because only one engineer understands the payroll integration and no documentation exists, their departure or extended absence could leave payroll defects unfixable, resulting in late or incorrect salary payments and probable loss of staff goodwill within one payment cycle.”

Notice what the rewrites have in common, a named system or process, a plausible mechanism, and a consequence with a number or a contract attached. Each one implies its own treatment plan. The originals implied nothing.

Before and after table showing four one word risks rewritten as full condition, event and consequence statements

Four register one-liners rewritten so each implies its own treatment plan.

Causes dressed as risks

“Legacy systems”, “insufficient budget”, “shadow IT” and “technical debt” are conditions, not risks. They belong in the first slot of the statement, not on their own row. The test is whether the entry describes something that either happens or does not happen in a given year. Legacy systems do not “happen”. The outage they make more likely does.

This matters practically, because a cause-as-risk can never be closed. Conditions persist, so the row sits on the register for years at a static amber, training everyone to ignore the document. Convert each one by asking “so what?” until you reach an event. Legacy systems, so unpatched vulnerabilities, so a compromise of the customer portal, so fraud and notification costs. Then the row can move, and movement is what keeps a register believable.

Chain flowchart converting the condition legacy systems into a scoreable event and consequence by asking so what

Asking ‘so what?’ until a condition becomes an event the register can score.

Controls dressed as risks

Now the mirror image, which looks like “failure of MFA rollout”, “backup failures” and “inadequate joiner-mover-leaver process”. These describe controls misbehaving, not harm occurring. A register full of them reads like an internal audit report and duplicates work that belongs in control monitoring.

The fix is the same question from the other direction, which is “and then what?”. Backups fail, and then what? An unrecoverable loss of the finance system during month-end close, resulting in late statutory reporting. That is the risk, and backup failure is part of its likelihood story. Keep control health in your control framework and let the register carry the harms. One risk statement will often absorb three or four control-shaped rows, which is a bonus, because the register gets shorter.

Keep the statement scoreable and ownable

Two final quality checks apply before a statement goes on the register.

• Scoring. Could two informed people, working separately, put broadly similar likelihood and impact on it? If the event is vague (“data may be compromised”) they cannot. Tighten the event until they can.
• Ownership. Does the condition point at someone with the authority and budget to change it? “Because the network is flat” points at infrastructure. “Because staff make mistakes” points at nobody, which is why human-error risks written that way never get treated.

Length discipline matters too. One condition, one event, one consequence per statement. If you find yourself writing “and/or” chains, you have several risks, so split them, then decide which ones merit register space.

Putting it into practice

Pull up your register and find the five shortest risk titles on it. Rewrite each using “Because [condition], [event] could occur, resulting in [consequence]”, with at least one number or named system in the consequence. Then show the before and after to each risk owner and ask whether the rating still looks right. In my experience roughly half get re-scored on the spot, which tells you what the vague versions were hiding. Make the structure a standing requirement for new entries, and reject candidates that arrive as one-word threats. The register will get shorter, sharper, and considerably harder to ignore.