How to Write a Risk Statement: The Three-Part Structure

A risk statement uses a three-part structure: cause, event, consequence. Written out, it reads: because of [cause], [event] may occur, which would result in [consequence]. The cause is something already true. The event is the uncertain part. The consequence is the damage, stated in money, time or a missed obligation.

This is for anyone who maintains a risk register that people are meant to read: project and programme managers, and whoever inherited the spreadsheet. It covers the structure, how to rewrite weak entries, what separates a risk from an issue, and where risk appetite fits.

What is the three-part structure used to define a risk statement?

The three-part structure is cause, event and consequence, joined into a single sentence so that all three are visible at once.

1. Cause. A condition that is true today. A supplier on extended payment terms, a contract ending in March, a dependency on one person’s knowledge. If you cannot point at it in the world now, it is not a cause.
2. Event. The uncertain thing that might follow. This is the only part allowed to be speculative, and it is the part the word “may” belongs to.
3. Consequence. What it costs if the event happens. Days, pounds, a missed regulatory date, a deliverable that cannot be accepted.

Practitioners often call this risk metalanguage, and the Association for Project Management uses that term for it. The label matters less than the discipline it enforces, which is that you cannot write a complete statement without knowing why you believe the thing might happen.

An if-then variant is equally common: if the event occurs, then the consequence, because the cause. Same three parts, different reading order. Pick one and use it consistently across the register, because mixed formats make the log unsortable by eye.

The test of a finished statement is whether a person outside the project could read it cold and say what should be done next. A statement with no cause is a prediction, and predictions do not have owners.

Weak risk statements, rewritten

Most registers are filled with nouns. Resourcing. Integration. Adoption. A noun cannot be mitigated, because there is nothing in it to act on.

Weak entry	What is missing	Rewritten
Resourcing	Everything. It is a topic heading.	Because two of the four backend developers are on contracts ending in March, the integration work may lose its lead engineer mid-build, delaying launch by a quarter.
Risk of project delay	A cause and a real consequence. Delay is the effect of a risk, not a risk.	Because the client’s legal review has no agreed turnaround time, sign-off on the data sharing agreement may slip past 14 March, leaving the build team idle for two weeks.
Key person dependency	The event and the cost. It names a condition and stops.	Because only one analyst knows the reconciliation logic, their booked leave in August may leave month-end close unsupported, risking a late statutory return.
Supplier may go into administration	A cause. Without one this is a headline.	Because our print supplier has renegotiated payment terms twice this year, they may fail before the November mailing, forcing a reprint at short notice and roughly double the unit cost.
Users might not like the new interface	A measurable consequence. Dislike is not a number.	Because the redesign was tested with staff rather than customers, the new checkout may increase drop-off at the payment step, reducing weekly online orders.

The cause is the part that gets dropped, and the reason is rarely laziness. Writing the cause down usually means naming a decision somebody in the room made: the contract that was signed short, the testing that was cut, the supplier nobody wanted to re-tender. Registers full of causeless risks are often a sign that the register is being written by one person after the meeting rather than during it.

Fix that procedurally. Agree the cause with the person who owns it before anyone commits the consequence to a spreadsheet. In a planning session, Projan asks what would have to go wrong and who would notice first, then exports the agreed wording to Jira or Confluence. The mechanism is not the point; getting the cause said out loud by the person responsible for it is.

What makes something a risk rather than an issue, an assumption or a worry?

A risk has not happened yet, has a cause that is already true, and has a consequence you could put a number on. Fail any of those three and it belongs somewhere else.

Item	Has it happened?	The test	What you do with it
Risk	Not yet	Can you name a cause that is true today?	Assign an owner, agree a response
Issue	Yes, already	Is it affecting the work now?	Resolve it or escalate it
Assumption	Treated as true, unchecked	What breaks if this is wrong?	Validate it, or promote it to a risk
Dependency	Pending, owned elsewhere	Who outside the team has to act?	Track the date, chase the owner
Worry	Unclear	Can you say what would cause it?	Leave it out until you can

The demotion nobody likes making is risk to issue. A risk that has already occurred is an issue, and leaving it in the risk column with a mitigation plan attached lets everyone keep discussing it in the future tense. If the supplier has already missed the date, stop scoring the likelihood and start managing the consequence.

The promotion in the other direction matters more than teams expect. Assumptions are where most late surprises are hiding, because an assumption is a risk somebody decided not to write down. Run through the assumption list at every review and ask what evidence would settle each one. Anything nobody can evidence should be restated with a cause and moved across. If you are deciding which tracker holds which of these, the comparison between RACI, RAID logs and a plain risk register covers the trade-offs.

New risks are easier to find in a structured session than in a review meeting. A premortem works because the failure is presented as having already happened, which forces people to state a cause rather than a fear.

What are the three main components of risk?

The three components of risk, as taught in most project management courses, are the event, its likelihood and its impact.

1. Event. The thing that might happen, described specifically enough to be recognised if it does.
2. Likelihood. How probable it is, expressed on whatever scale your organisation uses.
3. Impact. The size of the consequence if it occurs.

Other disciplines split risk differently and are not wrong. Information security commonly works with threat, vulnerability and consequence, because the useful question there is what could be exploited rather than what might occur. Safety practice tends to use hazard, exposure and harm. If you are working across functions, agree which triple you are using before comparing scores between teams.

There is no universal scale for likelihood and impact. Five by five matrices are common, three by three matrices are common, and the bands mean whatever your organisation has defined them to mean. Numbers copied from one organisation’s matrix into another’s register are decoration. What makes scoring possible at all is the statement: you cannot rate the impact of “resourcing”, but you can rate a launch slipping a quarter. If you are choosing which columns the register needs, the fields worth keeping and the ones worth cutting are worth settling before you populate anything.

What are the three main components of a risk profile?

A risk profile describes the organisation’s stance on risk rather than the anatomy of a single risk, and the three components usually named are appetite, tolerance and capacity.

1. Risk appetite. How much risk the organisation is willing to accept in pursuit of its objectives. This is chosen, usually by a board, and it can differ by category. Many organisations are cautious on data protection and adventurous on product experiments in the same year.
2. Risk tolerance. The variation around that appetite that can be accepted before someone has to act. Tolerance is where escalation thresholds come from.
3. Risk capacity. The maximum the organisation could absorb before something breaks. Capacity is a fact about reserves, insurance and contractual liability, not a preference, and it is the one people confuse with appetite.

Be careful with this question, because the phrase gets used two ways. The trio above is the governance sense, and UK public bodies take that vocabulary from HM Treasury’s Orange Book. The other sense is descriptive: a risk profile as the current shape of the register, meaning how many risks sit in each likelihood and impact band. Both are legitimate. If someone asks for the risk profile, find out which one they want before you build it.

Exposure is the measured counterpart to all three. Appetite is what you said you would accept, exposure is what you are actually carrying. The gap between them is the only number on the page that should worry a board.

What is a high risk register?

A high risk register is not a separate document type in most methods. It is the filtered view of the main register showing risks that have crossed an escalation threshold, and in organisations that keep one formally it is usually the list reported to a board or corporate risk committee.

Thresholds are set locally. What matters is what changes when a risk crosses one:

• The owner becomes a named executive rather than a project role
• The response is reviewed on a fixed cadence rather than at the next convenient meeting
• Someone makes an explicit decision to treat, transfer, tolerate or terminate, and records who decided
• The risk keeps its wording, so the board reads the same statement the project team wrote

That last point gets lost. Risks are frequently rewritten on the way up, softened into something a committee can absorb, and the escalated version loses the cause. If a risk is worth a board’s attention it is worth carrying its original sentence.

A high risk register that only ever grows is a queue, not a control. Something should leave it every quarter, either because the risk was closed or because the organisation decided formally to tolerate it. Roles, accountability and handoffs across the register matter more here than anywhere else, because escalation without a named receiver is just a heavier email.

What is the purpose of a risk log?

The purpose of a risk log is to make decisions about uncertainty visible, dated and owned, so that nobody has to reconstruct later who knew what and when.

It does four jobs:

• Records what the team believed might go wrong, and when they first believed it
• Names one person accountable for each entry, so that responses have an address
• Holds the decision taken, including decisions to accept a risk and do nothing
• Gives auditors, funders and incoming staff a defensible account of how the project was run

Risk log and risk register generally mean the same artefact, with log being the older term and still widely used. Neither name changes what the document is for.

The purpose is easy to state and hard to sustain, because a log that is updated only before steering committees becomes a compliance exercise within two quarters. Building one and keeping it alive is a separate discipline from writing good entries, and it is the one that fails more often.

Frequently asked questions

How do you write a risk statement in if-then format? If-then is the same three parts in a different order: if the event occurs, then the consequence follows, because of the cause. Some teams find it reads better in a meeting because the event comes first. It carries the same obligation, which is that the because clause has to be a condition that is already true and not a second guess.

Should a risk statement include the mitigation or the score? No. Keep the statement to cause, event and consequence, and put the response, the owner and the scores in their own fields. Statements that swallow the mitigation are impossible to re-score later, because you can no longer tell whether the rating describes the risk before or after the planned action.

Can an opportunity be written as a risk statement? Yes, and the structure holds without modification. Because of a condition that is already true, an event may occur, which would produce a benefit rather than a loss. Registers that track only threats tend to lose the upside cases entirely, since nobody has a column to put them in and no owner is asked to pursue them.

How specific should the consequence be? Specific enough that someone with budget authority would recognise it as a loss. Days, pounds, missed dates, a named obligation. Vague consequences such as reputational damage survive review because nobody can argue with them, which is exactly why they never trigger a decision or attract funding for a response.

Write every entry as cause, event and consequence, and the register stops being a list of anxieties and starts being a list of decisions waiting to be made. The three-part structure is not a formatting preference. It is the smallest amount of information from which someone can work out what to do.