# How to keep a risk register from your project meetings > For project leads, consultants and fractional CTOs who hear risks raised on Google Meet and Microsoft Teams calls: how to set up a TrackHeros tracker as a risk register, with likelihood and impact as status columns, an owner, a list of mitigations and a first-raised date, how the column descriptions stop it guessing, and how each change keeps the words behind it. Canonical: https://trackheros.com/blog/risk-register-from-meetings/ Author: Sami Kanafani Updated: 2026-11-04 **In short:** TrackHeros can keep a risk register as a tracker you design, filled from your Google Meet and Microsoft Teams meetings: one row per risk, with likelihood and impact as status columns, an owner, a list of mitigations and a status. A value is filled only when a meeting states it, keeps the quote behind it, and waits for your review by default. | Fact | Detail | | --- | --- | | Built from | A tracker you design, described in a sentence or started blank | | Likelihood and impact | Status columns with options you define, such as Low, Medium and High | | Mitigations | A list: added when raised, removed when said to be resolved | | First raised | A date column that keeps the first value | A risk register is a table of what could go wrong on a project: how likely it is, how bad it would be, who owns it and what is being done about it. This guide is for project leads, consultants and fractional CTOs who hear those risks raised in standups, status calls and steering meetings on Google Meet or Microsoft Teams, and want the register kept from the meetings themselves rather than rebuilt from memory once a month. ## Why do risk registers go stale? Because they are updated at a review, and risks are raised everywhere else. Someone says in Tuesday's standup that the bank's API might not be ready; the register hears about it three weeks later, if anyone remembers. By the time the monthly review comes round, the register describes the project as it was at the last review. The ratings were set once and never moved, mitigations are listed long after they were dropped, and nobody can say when a risk first came up. ## What columns should a meeting-fed risk register have? Seven that meetings fill, and one that fills itself. TrackHeros is an AI meeting notetaker that connects every Google and Microsoft calendar you hold, recognises close to 100 spoken languages on its own, writes the notes in nine of them, and keeps every client's notes in a sealed workspace of its own. A tracker is a table that fills itself from those meetings, with columns you define. | Column | Type | How it fills | | -------------- | ---------------------------------------- | --------------------------------------------------------- | | Risk | Text, names the row | One row per risk | | Likelihood | Status: Low, Medium, High | The latest value wins | | Impact | Status: Low, Medium, High | The latest value wins | | Owner | Person | The latest value wins | | Mitigation | List | Items added when raised, removed when said to be resolved | | Status | Status: Open, Watching, Happened, Closed | Happened and Closed marked final | | First raised | Date | Keep the first value | | Last discussed | Automatic | The last meeting that mentioned the row | A later, different value for First raised is not applied; it is shown as a conflict for you to decide, so the date a risk first came up stays put even when somebody says "as I raised last week". ## Why use status columns for likelihood and impact rather than scores? Because people say "fairly likely" and "that would be bad", not "four out of five". A status column with options you define matches what is actually said, while a score from one to five invites a number nobody said. If your team does score risks out loud, a number column works too. The rule that matters is the same either way: the cell is filled only when a meeting states the value. ## How do you write the column descriptions? Each column has a one-line description, and that description is what TrackHeros reads to decide what belongs in the cell. Say what counts, what does not, and when to leave the cell empty: ```text Risk: Something that could go wrong on the project and has not happened yet, named as people name it. Not problems already happening; not general worries. Likelihood: How likely the risk is, only when someone says so. Leave empty otherwise. Impact: How serious it would be if it happened, only when someone says so. Owner: The one person said to be watching or handling the risk. Empty if nobody was named. Mitigation: Things being done to reduce the risk. Add one when it is agreed; remove one when it is said to be done or dropped. Status: Open when raised; Watching when someone says it is being monitored; Happened if the risk has occurred; Closed if it is said to be no longer a risk. First raised: The date of the meeting where the risk was first raised. ``` "Only when someone says so" is the phrase that stops a register filling with plausible ratings. [Designing the columns of a meeting tracker](/blog/design-the-columns-of-a-meeting-tracker/) covers descriptions in more depth. ## How do you create the register? There is no risk register among the six templates, so describe it in a sentence, such as "a risk register with likelihood, impact, owner and mitigations", and TrackHeros drafts the columns for you to edit. You can also start blank. Designing your own tracker is a plan feature; [pricing](/pricing/) says which plans include it. Before saving, preview the definition on one recent meeting where a risk was discussed. When you create it, you can have it read your recent past meetings in scope, oldest first, so the register starts with the risks already raised, each with its first date. ## What happens when a risk changes? The row is updated and the old value moves into the cell's history, with the meeting it came from, who said it, when in the meeting, and the words they used. Here is one risk on a fintech client's project: | Meeting | Change | Words used | | ------------------------------------ | ------------------------------------------------------------------- | -------------------------------------------------------------------------------------------- | | Status call, Monday 2 February 2026 | New row; likelihood Medium; owner Sara | Sara: "There's a fair chance the bank's API isn't ready for launch. I'll keep an eye on it." | | Status call, Monday 16 February 2026 | Likelihood High; mitigation added "Mock the bank's API for testing" | Daniel: "They've slipped again. Let's mock their API so testing doesn't wait." | | Status call, Monday 9 March 2026 | Status Closed; mitigation removed | Sara: "Production credentials arrived, so the API risk is gone. We can drop the mock." | A link opens the transcript at each moment, and the recording jumps there. The quotes are rebuilt from the stored transcript, never written by the model, and a value with no transcript line behind it is dropped. A meeting that repeats a rating is recorded as a confirmation, not a change, and an older meeting read late never overwrites a newer value. ## How are mitigations added and removed? As list items. A mitigation is added when it is agreed and removed when someone says it is done or dropped, so the cell shows what is still in place and the history shows when each one started and stopped. Removing an item always waits for a person, even when a tracker is set to apply confident changes on its own. So do a possible duplicate row and a change to a cell you edited by hand. By default, everything waits in a review queue first; [review before a value changes](/blog/review-before-a-value-changes/) explains the queue. ## Which meetings should feed the register? Usually every meeting of the client, with plainly unrelated ones skipped, because risks are raised wherever the work is discussed. If your client keeps risk talk to a few calls, limit the scope to meetings whose titles contain words such as "status" or "steering", or to a chosen recurring meeting. If you run projects for several clients, one definition can cover all of them. TrackHeros keeps a separate table for each client, shows them together with a client label on every row, and never merges rows from two clients, even when two risks have the same name. [Pricing](/pricing/) says whether your plan includes all-clients trackers. A steering call held in Spanish fills the register the same way as one held in English; trackers read meetings in any of the close to 100 spoken languages TrackHeros recognises, and the [languages page](/languages/) lists them. ## How do you use the register before a steering meeting? Filter the table to rows that changed recently, rows with conflicts and rows waiting for review, and settle the review queue first. Then ask the assistant in the client's chat, "which risks are rated high likelihood, and who owns them?", and the answer comes from the register, with the meeting each value came from. The assistant reads trackers; it does not change them. The table and its full history can be downloaded as CSV, which opens in Excel or Google Sheets; [pricing](/pricing/) says which plans include export. More on trackers for project work is on [project managers](/for/project-managers/) and the [Trackers feature](/features/trackers/). ## Frequently asked **Can TrackHeros score risks on its own?** No. Each column is filled only when a meeting states the value, and a value with no transcript line behind it is dropped. If nobody said how likely a risk is, the Likelihood cell stays empty, which is itself worth raising. **Is there a risk register template?** Not among the six templates. Describe the register in a sentence and TrackHeros drafts the columns for you to edit, or start blank. Designing your own tracker is a plan feature, and the pricing page says which plans include it. **Can one register cover several clients?** One definition can cover all your clients, but TrackHeros keeps a separate table for each client and labels every row with its client. Rows from two clients are never merged, even when two risks have the same name. --- TrackHeros is in early access: https://trackheros.com/#early-access