Risk Register from Meeting Notes

Project risks often appear in meeting notes before anyone calls them risks. A supplier says a date is still provisional. A room booking depends on approval. A task has an owner, but the input it needs does not. If those signals remain buried in a recap, the team may remember the discussion without managing the uncertainty.

A risk register turns those signals into a small working record: what might happen, what would be affected, what evidence would show the risk is increasing, who is watching it, and when the team will check again. The goal is not to predict the future with false precision. It is to make uncertainty visible early enough to act.

What is a risk register?

For an ordinary project, a risk register is a list of uncertain events or conditions that could affect an agreed outcome. Each entry keeps the supporting source, the possible effect, an owner, a response, and a dated checkpoint.

This article covers routine delivery work such as schedules, handoffs, vendors, venues, and dependencies. Safety, legal, privacy, security, financial, regulatory, and compliance risks need qualified review and a process appropriate to the stakes.

Separate risks from issues, tasks, assumptions, and questions

Not every concern in a meeting belongs in the risk register. Use the wording in the source to decide what kind of record you need:

Risk: an uncertain event or condition that could affect the outcome. “The lift booking may not be confirmed before move day.”
Issue: a problem that is already happening. “The lift booking was rejected.”
Task: work someone has agreed to do. “Mina will request a second booking window.”
Assumption: a belief the plan currently relies on. “The archive cabinets will fit through the service entrance.”
Open question: information the team does not yet have. “What is the service entrance width?”

If the plan depends on a belief that has not been checked, record it in an assumption log from meeting notes. If the team needs an answer before it can decide, use an open-question log. Link those records to the risk instead of copying the same sentence into several places.

Start with the project outcome and reporting boundary

Before extracting risks, write down the outcome, the notes reviewed, and the date of the review. Without that boundary, an old concern can look current and a new concern can appear unsupported.

Outcome: Move the team into the new office by 18 October
Notes reviewed: planning meetings on 12, 16, and 21 September
Register updated: 22 September, 13:30
Missing source: final building-access confirmation

The missing source matters. It tells readers which part of the picture is still incomplete.

Find risk language in the notes

Read once for uncertainty rather than for topics. Look for phrases such as “may,” “depends on,” “not yet confirmed,” “only if,” “waiting for,” “could delay,” and “we have not checked.” Then return to the surrounding lines. A phrase alone is not enough; the context should show the project outcome that could be affected.

Do not rewrite a possibility as a prediction. “The vendor may deliver on 17 October” does not mean “the vendor will be late.” Keep the uncertainty visible.

Use seven fields for each risk

A useful entry answers seven questions:

Risk statement: What uncertain event or condition could occur?
Source: Which note, message, or document supports the entry?
Possible effect: Which outcome, date, cost, or handoff could change?
Trigger: What observable evidence would show that the risk is increasing or has become an issue?
Owner: Who will monitor the risk and coordinate the response?
Response: What will the team do now, and what will it do if the trigger occurs?
Next checkpoint: When will the entry be reviewed, and what evidence is expected?

Add an “unknowns” field when the source is incomplete. An honest blank is better than an invented probability.

A worked example: a fictional office move

Imagine a fictional operations team preparing an office move. Its permitted meeting notes contain these statements:

the furniture vendor expects delivery between 15 and 17 October, but the date is not confirmed;
the team needs furniture installed before the network contractor can finish desk testing;
building management will confirm the service-lift window by 25 September;
the archive cabinets have not been measured against the service entrance;
Mina will measure the entrance and cabinets on 24 September;
a suggestion to hire temporary desks was discussed but not approved.

Those notes support three different risk entries. They do not support a claim that the move will be delayed.

Example risk register

Risk 1: furniture delivery could compress desk testing

Source: 21 September planning notes, vendor update.
Possible effect: Network desk testing could start later than planned.
Trigger: Delivery is not confirmed by the 27 September checkpoint, or the confirmed date moves beyond 15 October.
Owner: Jordan monitors the vendor date and coordinates with the network contractor.
Response: Confirm the latest workable testing sequence with the contractor. Temporary desks remain an unapproved option.
Next checkpoint: 27 September with written vendor confirmation.
Unknown: Minimum time the contractor needs between furniture installation and desk testing.

Risk 2: the service-lift window may not match the delivery plan

Source: 16 September planning notes.
Possible effect: Furniture unloading may need a different time or route.
Trigger: Building management does not confirm the requested window by 25 September, or confirms a conflicting window.
Owner: Priya follows up with building management.
Response: Hold the requested slot and prepare a question for the vendor about alternate unloading times.
Next checkpoint: 25 September after the building response.
Unknown: Whether an alternate unloading route is permitted.

Risk 3: archive cabinets may not fit through the service entrance

Source: 21 September planning notes.
Possible effect: Cabinet relocation may require disassembly or a different route.
Trigger: Measured cabinet width exceeds the usable entrance width.
Owner: Mina owns the measurement and records the result.
Response: Measure before confirming the cabinet move method; do not choose a workaround until the dimensions are known.
Next checkpoint: 24 September with measurements and photos.
Unknown: Clearance needed for safe handling, which requires the appropriate facilities guidance.

The entries are deliberately specific about evidence and deliberately cautious about what is not known. They turn a concern into a reviewable record without pretending to calculate certainty.

Prioritize without false precision

If your team uses low, medium, and high labels, define them for this project. A useful rule can be based on the effect and the time left to respond. Do not assign a percentage because it looks analytical. Use a probability estimate only when the team has a defensible method and the evidence to support it.

A short register can also be ordered by the next checkpoint. That often works better than a colour score because it shows what needs attention first.

Review the register as a living record

At each checkpoint, update the evidence rather than simply changing the label. A risk can remain open, reduce, increase, become an issue, or close. Preserve the earlier state and add the reason for the change.

When a risk becomes an issue, move the confirmed problem into the issue or action log and link back to the original risk entry. Closing a risk should also include evidence: the lift window was confirmed, the measurements passed, or the dependency was removed.

Copy this risk-entry template

Risk statement:
Source:
Possible effect:
Observable trigger:
Owner:
Response now:
Response if triggered:
Next checkpoint and expected evidence:
Unknowns:
Status and reason:
Last updated:

Run a final source check

Before sharing the register, compare every risk statement, owner, date, dependency, and response with the permitted source. Keep suggestions labelled as suggestions. Remove concerns that have no connection to the stated project outcome, and flag missing evidence rather than filling the gap from memory.

Choose one set of ordinary project meeting notes you are allowed to use. Write one risk entry with a source, possible effect, observable trigger, owner, response, checkpoint, and unknown. That single complete entry is more useful than a long list of unsupported worries.