How to Write a Risk Register Entry in English

A risk register is only useful if each entry is specific enough to act on — “the migration might have problems” tells a stakeholder nothing, while a properly structured entry states what could go wrong, how likely it is, what it would cost, and who’s responsible for watching it. This guide covers the English vocabulary for writing entries that hold up in a project review.

Key Vocabulary

Risk statement — a specific description of what could go wrong, phrased as a concrete event rather than a vague worry. “The risk statement should read ‘the third-party payment API could exceed rate limits during Black Friday traffic,’ not ‘there might be payment issues.’”

Likelihood — an estimate of how probable the risk is, usually expressed as a category (low/medium/high) or a rough percentage, based on evidence where possible. “We rated the likelihood as medium, based on the fact that we hit similar rate limits during last year’s comparable traffic spike.”

Impact — the consequence if the risk materializes, described concretely in terms of cost, delay, or scope, not just “it would be bad.” “The impact would be an estimated four-hour checkout outage during peak traffic, translating to roughly $40,000 in lost sales based on last year’s figures.”

Mitigation — the proactive action taken to reduce either the likelihood or the impact of the risk before it happens. “The mitigation is implementing a request queue with backoff, which should keep us under the rate limit even during traffic spikes.”

Contingency plan — the reactive plan for what to do if the risk materializes despite mitigation, distinct from mitigation itself. “If we do hit the rate limit despite the queue, the contingency plan is to fail over to the backup payment provider automatically.”

Risk owner — the specific named person responsible for monitoring the risk and triggering the contingency plan if needed, not a team or department. “The risk owner is Maria, since she owns the payment integration and would be the first to see rate-limit alerts.”

Common Phrases

• “The risk statement is: [specific event] could occur due to [specific cause].”
• “We’re rating likelihood as [low/medium/high] based on [evidence].”
• “The estimated impact is [concrete cost/delay/scope change].”
• “Mitigation in progress: [specific action], expected to reduce [likelihood/impact] by [amount or qualitative description].”
• “If this risk materializes, the contingency plan is [specific reactive action], owned by [named person].”

Example Sentences

Writing a complete risk register entry: “Risk: the vendor’s API could experience an extended outage during our launch week, based on two similar incidents in the past six months. Likelihood: medium. Impact: launch would need to proceed without the vendor’s real-time verification feature, degrading but not blocking core functionality. Mitigation: we’re implementing a fallback to manual verification. Owner: James.”

Escalating a risk that’s grown more likely: “I want to flag that this risk’s likelihood should move from low to medium — the vendor’s status page shows two more outages this month than in the same period last year, which changes our confidence in the original estimate.”

Explaining a mitigation trade-off to a stakeholder: “The mitigation reduces the impact significantly but doesn’t eliminate the risk entirely — we’re accepting a residual risk here because eliminating it fully would require a six-week delay we don’t think is justified given the reduced impact.”

Professional Tips

• Write the risk statement as a specific, falsifiable event, not a general worry — a reviewer should be able to say clearly, after the fact, whether it did or didn’t happen.
• Base likelihood on evidence (past incidents, vendor track record, load estimates) where possible, and say so explicitly — an unsupported “medium” rating invites unproductive debate.
• State impact in concrete terms (dollars, hours, percentage of users) rather than adjectives like “significant” — concrete numbers are what let stakeholders prioritize across multiple risks.
• Always name a specific risk owner, never a team — a risk owned by “the platform team” tends to get monitored by no one in particular.

Practice Exercise

1. Write a specific risk statement for a hypothetical infrastructure dependency.
2. Write one sentence estimating likelihood with a stated piece of supporting evidence.
3. Write a sentence distinguishing a mitigation action from a contingency plan for the same risk.