The risk register lands in the steering committee meeting at Clearwater Financial Services, and the first entry reads: Cyber attack risk is High. The CFO looks at it, asks “which attack, on what, costing us what?”, gets no crisp answer, and moves to the next agenda item. Six months of assessment work, dismissed in forty seconds, because the risk was real but the sentence describing it was empty.
This is the quiet truth of GRC: assessments do not fail in the analysis. They fail in the writing. Learn to write a risk statement properly and every register, report, and recommendation you produce gets sharper. This article gives you the formula professionals use, ten weak-to-strong rewrites, and three scenarios to practice on.
Why weak risk statements sink good assessments
A risk statement is the one or two sentences that describe a single risk in a register. It has three audiences with three needs: leadership needs to grasp the business consequence instantly, technical teams need enough specificity to act, and future readers (auditors, your successor, you in a year) need it to still make sense without a meeting.
Weak statements fail all three. “Cyber attack risk” tells leadership nothing about consequence, gives engineers nothing to fix, and will mean nothing in a year. Vague risks get ignored; precisely described risks get funded. The writing is not decoration on the analysis. It IS the deliverable.
The formula: condition, event, consequence
Nearly every mature GRC team writes risk statements on the same skeleton, aligned with the risk model language in NIST SP 800-30.
Because of [condition], [event] could occur, resulting in [consequence].
Cause / condition (because of…)
The weakness or circumstance that makes the risk real: the vulnerability, in the vocabulary from Risk vs Threat vs Vulnerability. “Because customer logins lack multi-factor authentication…” Anchoring the statement in a condition does something subtle and powerful: it points directly at what to fix.
Event (an actor or failure could…)
What could actually happen: the threat acting on the condition. “…attackers using automated credential attacks could take over customer accounts…” Name the actor and the action concretely. “A breach could occur” is an event in name only.
Consequence (resulting in…)
The business harm, in business terms: “…resulting in customer financial losses, regulatory penalties under PIPEDA, and loss of client trust.” This clause is what leadership reads. Money, customers, legal exposure, operations, reputation: pick the ones that genuinely apply and be concrete.
Assembled: Because customer logins lack multi-factor authentication, attackers using automated credential attacks could take over customer accounts, resulting in customer financial losses, regulatory penalties, and loss of client trust.
One sentence. Cause, event, consequence. A CFO acts on that.
10 examples: weak version vs strong rewrite
All ten drawn from the kinds of entries that appear in real registers, set at Clearwater where a scenario helps.
1. Weak: “Phishing risk.” Strong: “Because staff receive no phishing awareness training, employees could be deceived into revealing credentials, resulting in unauthorized access to internal systems and customer data exposure.”
2. Weak: “Ransomware is a major threat.” Strong: “Because endpoint backups are not tested and servers run without offline copies, a ransomware infection could encrypt operational data with no reliable recovery, resulting in multi-day service outage and extortion costs.”
3. Weak: “Third-party risk is High.” Strong: “Because the payment vendor’s security has not been assessed since onboarding, a breach at the vendor could expose shared customer payment data, resulting in notification obligations and contractual penalties.”
4. Weak: “Employees might misuse data.” Strong: “Because support agents can view any customer account and activity logs are never reviewed, an agent could browse or exfiltrate customer records undetected, resulting in privacy violations and regulatory findings.”
5. Weak: “Patching is behind.” Strong: “Because portal components are patched ad hoc with no defined cycle, attackers could exploit a known software flaw, resulting in customer data exposure and emergency remediation costs.”
6. Weak: “Cloud misconfiguration risk.” Strong: “Because cloud storage settings are changed without review, a bucket could be exposed publicly, resulting in bulk customer data leakage and mandatory breach notification.”
7. Weak: “Risk of losing key staff.” Strong: “Because security operations knowledge sits with one engineer and nothing is documented, that person’s departure could leave monitoring unmanaged, resulting in delayed detection of incidents.”
8. Weak: “Passwords are weak.” Strong: “Because the password policy permits short passwords and no MFA on admin accounts, attackers could brute-force administrative access, resulting in full system compromise.”
9. Weak: “DR plan outdated.” Strong: “Because the disaster recovery plan has not been tested in two years, recovery after a data centre outage could fail or exceed tolerances, resulting in extended downtime and revenue loss.”
10. Weak: “Compliance risk with new privacy law.” Strong: “Because Quebec Law 25 requirements have not been mapped to current data practices, processing could violate consent and retention rules, resulting in fines and mandated process changes.”
Read the weak column again in one pass: notice every entry is a topic, not a risk. The strong column is the same knowledge, structured.
Common mistakes
- Stating a missing control as the risk. “No MFA” is not a risk; it is a condition. The risk is what the missing control allows to happen. If your statement has no event and no consequence, you wrote a finding, not a risk.
- Stating a threat without impact. “Hackers could attack the portal” is weather reporting. Attach the consequence or leadership has no reason to care.
- Stacking five risks in one sentence. If your statement contains “and also,” split it. One risk, one statement, one rating.
- Consequence inflation. Not every risk ends the company. Overstated consequences burn credibility, and credibility is the only currency a risk function has.
- Jargon in the consequence clause. The last clause belongs to leadership. “Resulting in compromised confidentiality of PII” loses to “resulting in customer data exposure and privacy penalties.”
How risk statements feed the register and the report
The statement is the seed everything else grows from. In the register, the condition clause tells you what control to evaluate, the event drives the likelihood rating, and the consequence drives the impact rating, the same ratings walked through in the risk assessment guide. In the report, the top statements become the findings summary almost verbatim, because they were written in leadership language from the start. Write the statement well and the register practically fills itself in.
Your turn: three raw scenarios
Draft a full condition-event-consequence statement for each before reading the model answers.
Scenario A: Clearwater’s marketing team signed up for a new email tool using a personal credit card. IT does not know it exists. It holds the full customer mailing list.
Scenario B: The office door badge system logs entries, but the log has never been checked, and two former employees’ badges were never deactivated.
Scenario C: Developers copy production customer data into a test environment to debug issues. The test environment has no access restrictions.
Model answers:
A: Because staff can adopt unsanctioned tools holding customer data without IT review, customer contact data could be exposed through an unvetted vendor, resulting in privacy violations and breach notification obligations.
B: Because former employees’ badges remain active and entry logs are never reviewed, an ex-employee could access the office undetected, resulting in theft of equipment or sensitive documents.
C: Because production customer data is copied into an unrestricted test environment, anyone with test access could view or leak real customer records, resulting in data exposure and regulatory penalties.
Close matches count. If your statements named a condition, a concrete event, and a business consequence, you now write a risk statement better than the “Cyber attack risk – High” that opened this article.
The natural next step is seeing statements at home in a full register: ratings, controls, and priorities attached. The free GRC Starter Kit includes the Sample Risk Register with professionally structured statements you can model, plus the assessment and policy templates from this series. Get the GRC Starter Kit.
