A risk register is the table where a project or program records each risk with its likelihood, impact, owner and response. If your project teams each keep risks in a different spreadsheet, or nobody has told you what one should contain, this guide is for you. It defines the register, shows a filled-in example at program level, gives you a template to copy and explains how to roll several project registers up into one program view.
- A risk register is a central record of identified risks. Each row holds a description, likelihood, impact, owner, response and status, and NIST defines it as a repository of risk information including the data understood about risks over time.
- Score every risk the same way: likelihood times impact on a 1 to 5 scale gives a score from 1 to 25. A risk matrix is the grid that plots those scores, so the register is the record and the matrix is a picture of it.
- Every risk needs one named owner and a review date. The project manager usually maintains the register, but an unowned risk is an unmanaged one.
- On a program, keep one register per project with identical columns, then roll up only the risks that cross workstreams or pass your escalation threshold.
What Is a Risk Register?
A risk register is a central record of the risks a project or program has identified, with the details needed to manage each one: what it is, how likely it is, what it would cost, who owns it and what the plan is. NIST's glossary defines it as "a repository of risk information including the data understood about risks over time", and a second NIST definition calls it a central record of current risks for a given scope or organization, where current risks include both accepted risks and risks with a planned mitigation path.
Asana describes the same idea in project terms: a document for identifying, tracking and mitigating potential risks before they become problems, with risk descriptions, likelihood, impact, ownership and response plans in one place. MetricStream calls it a living document that needs regular updates, and that matters more than the format. A register that was filled in at kickoff and never opened again isn't managing anything. The first entries usually come from the risk row of the project charter, and our project charter template shows where that row sits.
Separating the register from its summary helps. Project Management Academy explains that the register is the detailed log of each risk, with causes, likelihood, impact, response plan, owner, status and whether the risk is a threat or an opportunity. The risk report is the short summary that turns those details into something a sponsor can decide on. The sections below cover the register itself, and the comparison table later shows how the matrix, the report and a RAID log fit around it.
What Should a Risk Register Look Like?
A risk register looks like a table with one row per risk and columns for an ID, a description, a category, likelihood, impact, a score, an owner, a response, a status and a review date. Guides disagree on the exact list, although they overlap heavily, as the table shows.
| Source | Fields it names |
|---|---|
| Asana | Nine fields: identification, description, category, likelihood, analysis (impact), mitigation, priority, ownership, status. Optional: risk trigger, response type (positive or negative), timeline |
| MetricStream | Ten components: identification, description, category, ownership, analysis, priority, mitigation, action plan and timelines, comments and notes, status. Its example entry adds monitoring and controls and closure criteria |
| Vanta | Risk identifier and scenario, category, date identified, likelihood and impact, rating or score, owner, treatment plan and controls, inherent and residual scores, last reviewed date |
| Institute of Project Management | Risk ID and description (cause and effect), category, likelihood and impact scores, overall score (likelihood multiplied by impact), owner and response plan |
Three details in that table are worth copying. Vanta and the Smartsheet construction template both record a residual score, which is the score after your response has been applied, so you can see whether the response is worth its cost. Asana suggests keeping descriptions short, at roughly 80 to 100 characters. And the Institute of Project Management asks for the description as cause and effect, which stops entries like "budget overrun" that nobody can act on.
Wikipedia adds one distinction that affects the columns. A register can be qualitative, with ranked levels such as high or low, or quantitative, with numbers such as an amount in dollars and a percentage. Most project registers are qualitative, and the template below is too, even though a quantitative column can be added later.
Risk Register Example for a Program
A program risk register gives every risk an ID, a cause-and-effect description, a workstream, an owner, likelihood and impact scores, a response, a residual score and a status. The example below is illustrative: a hypothetical program replacing a customer portal, run as four workstreams. Likelihood and impact are scored from 1 to 5 and multiplied, a convention we explain in the scoring section. The last row is an opportunity, because Project Management Academy and Asana both note that a risk can be positive.
| ID | Risk | Workstream | Owner | L | I | Score | Response | Residual | Status |
|---|---|---|---|---|---|---|---|---|---|
| R-01 | If the identity vendor misses its August release, single sign-on can't ship with the portal launch | Platform | Platform lead | 3 | 5 | 15 | Mitigate: weekly vendor check-ins, keep the current login as a fallback for launch | 6 | Escalated to program |
| R-02 | If duplicate customer accounts in the legacy system aren't merged first, migrated profiles will show the wrong history | Data migration | Migration lead | 4 | 4 | 16 | Mitigate: run a de-duplication pass before the first rehearsal | 8 | Escalated to program |
| R-03 | If legal review of the new terms takes longer than three weeks, the launch date moves | Launch | Program manager | 3 | 4 | 12 | Mitigate: send a draft to legal before the final copy is ready | 8 | Open |
| R-04 | If support can't absorb launch-week ticket volume, response times will rise during the busiest days | Launch | Support lead | 4 | 3 | 12 | Mitigate: agree temporary cover with the support team before launch | 6 | Open |
| R-05 | If the launch lands in the same week as the finance close, two migration engineers may be pulled away | Data migration | Migration lead | 4 | 3 | 12 | Avoid: move the launch to the following week | 3 | Resolved, close at next review |
| R-06 | If the hosting contract renews at a higher price, run costs rise slightly above plan | Platform | Finance partner | 2 | 2 | 4 | Accept: note it, review at renewal | 4 | Open |
| R-07 | If the payment provider has an outage on launch day, customers can't check out | Payments | Payments lead | 2 | 5 | 10 | Transfer: confirm the provider's uptime commitment in the contract and agree a status page | 5 | Open |
| O-01 | If the vendor offers early access to passwordless login, one migration step could be dropped | Platform | Platform lead | 2 | 4 | 8 | Exploit: ask the vendor for beta access | n/a | Open |
Here's what to notice when you read it.
- Every row has one named owner. The owner keeps the risk moving, but they aren't always the person who fixes it.
- Two risks are escalated and the rest are not. R-01 and R-02 score 15 or more and R-01 depends on another team, so they go to the program register. The other rows stay in their workstream registers. The program section below shows how to decide.
- The response uses one of four verbs. Avoid, transfer, mitigate or accept are the four treatments that Vanta, MetricStream and the Institute of Project Management name (the last one writes reduce instead of mitigate). The example uses each of them once or more.
- Residual scores show whether the response works. R-05 drops from 12 to 3 because the cause is removed, while R-06 stays at 4 because accepting a risk doesn't change it.
- The opportunity has the same columns. Scoring an upside the same way lets you compare it with the threats, and it has a response too.
For the companion log that also tracks assumptions, issues and dependencies for this kind of program, see our guide to the RAID log.
Free Risk Register Template
Smartsheet publishes nine risk register templates, from a simple one to project, business, compliance, Agile, enterprise, construction and cyber versions, in Excel and Google Sheets (some also in Word). If you'd rather not download anything, build the template yourself. Create a spreadsheet with the columns below as the header row, add drop-down lists for Category, Response and Status, and copy the same sheet for each project. Start with the first eight columns and add the rest only when a meeting keeps asking for that information. You can export the sheet as a PDF when the steering committee wants a static copy.
| Column | What to write | Why it's there |
|---|---|---|
| ID | A unique number with a prefix per workstream, for example PAY-R-03 | Lets people refer to a risk without retyping it |
| Risk | One sentence: if this cause happens, this effect follows | Cause and effect makes it actionable |
| Category | Schedule, budget, technology, people, external or compliance | Groups risks for filtering (Asana lists operations, budget, schedule, technology, information, security, quality and project plan) |
| Workstream | The project or workstream it belongs to | Makes the program rollup a filter |
| Owner | One named person | Accountability |
| Likelihood | 1 to 5 | Input to the score |
| Impact | 1 to 5 | Input to the score |
| Score | Likelihood times impact | Ranks the risks |
| Response | Avoid, transfer, mitigate or accept, plus the action | The plan |
| Residual score | Score expected after the response | Shows whether the response is worth doing |
| Trigger | The early sign that the risk is happening | Asana lists the trigger as an optional field |
| Status | Open, escalated, resolved or closed | Shows what needs attention |
| Date raised | The day the risk was added | History |
| Review date | When someone must look at it next | Stops silent decay |
- Every risk has an ID, a cause-and-effect description, one named owner and a status
- Likelihood and impact use the same 1 to 5 scale in every project
- Each risk has a response (avoid, transfer, mitigate or accept) and a review date
- Opportunities use the same columns as threats
- Escalation rules are written down and agreed with the steering committee
- One place holds the register, and everyone knows where it is
How Do You Build a Risk Register Step by Step?
You build a risk register in six steps: identify the risks, describe each as cause and effect, score likelihood and impact, choose a response, name one owner and set a review date. MetricStream lists six steps in a similar order, and the Institute of Project Management gives a three-step version of the same flow.
Identify the risks with the people who'll feel them
MetricStream suggests gathering a cross-functional team and using methods such as SWOT analysis, interviews and a review of historical data. The Institute of Project Management says to run a workshop with the core team and stakeholders and to log every risk immediately. Individual contributors miss risks that others can see, so don't write the first list alone.
Describe each risk as cause and effect
Write it as: if this happens, then this follows. MetricStream asks for what the risk is, why it matters and when it could occur. A description like "budget overrun" names an outcome. "If the vendor re-quotes in Q2, the license line goes over budget" names something you can act on.
Score likelihood and impact
Use the same scale for every risk and write down what each level means, as the next section shows. The Institute of Project Management calls this a calibrated scale, so everyone scores the same way. Multiply the two numbers to get the score.
Choose a response
Avoid the risk, transfer it, mitigate it or accept it. MetricStream adds that each response needs actions, resources and timelines. For an accepted risk, write down who accepted it and what would change your mind.
Assign one owner
The Institute of Project Management says ownership should be assigned before the register goes to stakeholders, and that an unowned risk is an unmanaged one. A team or a department isn't an owner.
Set a review date and keep reviewing
Update the register at every project status meeting and at key milestones, according to the Institute of Project Management. Asana suggests weekly or bi-weekly reviews, plus an immediate update when a new risk appears or a status changes. Archive closed risks rather than deleting them, so the history is there for lessons learned.
How Do You Score Risks and Read a Risk Matrix?
You score a risk by multiplying its likelihood by its impact, each on the same scale, and you read a risk matrix by plotting that score on a grid. Wikipedia describes the same formula: a risk score is probability times impact, and it's used to rank the risks. Vanta says matrices are commonly 3 by 3 (high, medium and low tiers) or 5 by 5 (more granular levels). Asana uses a three-level likelihood and a five-point impact scale, which shows that the choice is yours, as long as you stay consistent.
We use 1 to 5 for both, because it's granular enough to separate risks and the product of two such scales is easy to scan. The level definitions below are our convention, not a standard. Replace the wording with figures from your own program, such as cost thresholds.
| Rating | Likelihood (1 to 5) | Impact (1 to 5) |
|---|---|---|
| Very low | 1, Rare: no reason to expect it | 1, Negligible: absorbed by the team, no change to plan |
| Low | 2, Unlikely: could happen but not expected | 2, Minor: small slip or cost within team tolerance |
| Medium | 3, Possible: has happened on similar work | 3, Moderate: a milestone moves or the budget line is affected |
| High | 4, Likely: expected on at least one workstream | 4, Major: a program milestone or budget tolerance is at risk |
| Very high | 5, Almost certain: already showing early signs | 5, Severe: the program outcome or launch date is at risk |
Multiplying the two gives the matrix below, with impact in the rows and likelihood in the columns. The shading bands are also our convention: 1 to 4 low, 5 to 9 medium, 10 to 14 high and 15 to 25 critical.
| Impact | Rare (1) | Unlikely (2) | Possible (3) | Likely (4) | Almost certain (5) |
|---|---|---|---|---|---|
| Severe (5) | 5 | 10 | 15 | 20 | 25 |
| Major (4) | 4 | 8 | 12 | 16 | 20 |
| Moderate (3) | 3 | 6 | 9 | 12 | 15 |
| Minor (2) | 2 | 4 | 6 | 8 | 10 |
| Negligible (1) | 1 | 2 | 3 | 4 | 5 |
Two cautions apply. First, a score is a conversation starter, not a measurement. Two people can score the same risk differently, even in good faith, which is why the scale definitions matter. Second, a single number hides the shape of a risk: a 2 by 5 and a 5 by 2 both score 10 but need different responses. Keep the likelihood and impact columns visible next to the score.
How Do You Run Risk Registers Across a Program?
Keep one register per project with identical columns, roll up only the risks that cross workstreams or pass your escalation threshold, and review both levels on a fixed rhythm. None of the guides we reviewed describe the program level, so the method below is ours, though we label it as such.
Give every project the same register
Use the template above with the same columns, the same 1 to 5 scales and an ID prefix per workstream. Identical columns turn a rollup into a filter instead of a rewrite, which is of course the point.
Write the escalation rules down
A risk moves up in one of four cases: it crosses a workstream boundary, its score passes an agreed threshold (15 on the 25-point scale used above is our example), it threatens a program milestone or budget tolerance, or it's overdue for its review date. Put the rules in the header of the register so nobody argues about them later.
Roll up what crosses a line
The PMO copies or links the escalated risks into the program register, keeping the original ID. The workstream register stays the record, and the program register is the view for the steering committee.
Decide who accepts what
Workstream leads can accept low risks inside their own register. Risks above the threshold are accepted, funded or escalated further by the sponsor or steering committee, and the decision is recorded in the register.
Review each level on its own rhythm
Workstream leads review their register in their regular status meeting, and the program manager reviews the program register with the PMO before each steering committee. Vanta recommends not relying only on periodic reviews and suggests flagging scores that haven't changed for more than six months. On a program that meets monthly, a shorter window such as two review cycles is easier to act on.
Who Is Responsible for a Risk Register?
The project manager usually creates and maintains the risk register, but every individual risk needs its own named owner. Asana lists four roles: the project manager leads creation and maintenance and runs the risk identification sessions, team members contribute day-to-day expertise, department leads help coordinate and assess cross-functional risks, and subject-matter experts spot what others miss. The Institute of Project Management adds that each risk has one individual accountable for monitoring, reporting and acting, and that a risk with no owner isn't being managed.
On a program, the same split holds one level up, while the sponsor sits above it. Workstream leads maintain their project registers, the program manager or PMO maintains the program register, and the sponsor or steering committee decides on risks above the threshold. If you also need to settle who decides what, our RACI chart for program managers has a program-level template.
Is a Risk Register a Legal Requirement?
None of the guides we reviewed describes a general legal requirement to keep a risk register, and Vanta, Asana and MetricStream don't claim one. A register is, of course, a management tool rather than a legal filing. Whether your industry, your contracts or a standard you have signed up to requires risk records is a question for your compliance or legal team, and we haven't verified any specific requirement here.
There's a related point about what a register can do to you. Risk Management Magazine (in an article from 2017) says registers can be discoverable in litigation, that registers prepared by non-lawyers may not be protected, and that preparing them through counsel may support a privilege claim. It also warns that a register stating a system is secure can be used against a company after a breach, and that an identified vulnerability left unfixed can be used as evidence of notice. In practice, write what you know, record what you did about it and ask legal how sensitive entries should be handled.
Risk Register vs Risk Matrix, Risk Report, RAID Log and Issue Log
The risk register is the full record of each risk, the risk matrix is a grid derived from it, the risk report is a summary for decisions, and a RAID log adds assumptions, issues and dependencies to the risks. The Institute of Project Management says to use both the register and the matrix, with the register as the source of truth. Project Management Academy says the register holds all the details and the report turns them into a clear summary.
| Document | What it is | What it contains | When it changes |
|---|---|---|---|
| Risk register | The detailed log of risks | Description, likelihood, impact, score, owner, response, status | Whenever a risk changes, and at every review |
| Risk matrix | A visual grid of likelihood against impact | Risk IDs placed by score | After each register update, as a picture of it |
| Risk report | A summary for decisions | The top risks, risks that occurred, responses taken, overall risk level | At milestones or reporting intervals |
| RAID log | One log for four kinds of entry | Risks, assumptions, issues and dependencies | At every status meeting |
| Issue log | A log of problems that have already happened | Description, impact, owner, resolution | When an issue is raised or resolved |
A risk is something that might happen and an issue is something that already has. When a risk occurs, log an issue, keep the risk's ID and link the two. The RAID log guide explains how entries move between types.
Which Tools Can Hold a Risk Register?
A risk register can live in a spreadsheet, in Smartsheet, in Asana or in Jira, and programs usually outgrow the spreadsheet when several people need to update entries, filter by workstream and get reminded about review dates. These are the options the sources describe, and the limits that come with them.
- Excel and Google Sheets. The simplest start. Smartsheet publishes its templates for both, and the table above builds in a few minutes. The cost is manual updates and no reminders, so review dates only work while someone checks them.
Smartsheet. Its template page lists nine versions, including an Agile register for sprint-level risks, a business register with a business unit drop-down and a compliance register with a control gap field. The simple and enterprise templates use a 5 by 5 probability and impact matrix. The page doesn't explain the scoring formulas, so you set those yourself.
Asana. Asana's template has fields for description, identification date, owner, due date, category, likelihood, impact on a five-point scale and priority. It offers list and board views, custom fields and rules for automation, and the board can move risks through stages such as analyzing and planning. It fits teams that already run their projects there.
Jira. The setups described by third-party app vendors use a risk-register app on top of Jira. SoftComply's tutorial lets you choose a risk model (a matrix or a risk score), pick a register template for information security, project or product risk, add fields such as risk owner and review due date, and use a Jira automation rule to email the owner three days before the review date. Expect to configure it yourself or buy an app, whereas Smartsheet and Asana ship ready-made templates.
Whatever you choose, the habits matter more than the tool. A register that nobody opens is useless in every tool, however good the template.
The Program Manager isn't a risk register and doesn't replace one. It maps dependencies across Jira and Asana and watches every milestone for risk, with a blocker workflow that has owners and due dates and a decision log. That covers the part of a program risk view that goes stale fastest when it's maintained by hand. For other tools that can hold the rest of a program, see our roundup of the best program management software.
Common Risk Register Mistakes
The most common mistakes are creating the register once and never updating it, writing vague descriptions and assigning ownership on paper only. The Institute of Project Management names exactly those three. Four more show up in the sources and in how programs actually run.
- Treating the register as a ritual. Wikipedia summarizes research that links registers to ritualistic decision-making and an illusion of control, and cites Toyota, whose register listed reputation risks from Prius malfunctions that the company didn't act on. A register records decisions. It doesn't make them.
- Letting scores go stale. Vanta suggests flagging any score that hasn't changed in more than six months. A score that never moves usually means nobody is looking, still less acting.
- Scoring differently in every project. If one team's 4 is another team's 2, the program rollup compares nothing. Define the scale once and reuse it.
- Mixing issues and risks. An issue has already happened, so it has no likelihood. Move it to your issue log or the issue section of a RAID log, and keep the register about what might still happen.
FAQ
What should a risk register look like?
A risk register looks like a table with one row per risk. Typical columns are an ID, a description written as cause and effect, a category, likelihood, impact, a score, an owner, a response, a status and a review date. Asana names nine fields and MetricStream names ten components, and they overlap on all of these.
What is the difference between a risk register and a risk matrix?
The risk register is the full, authoritative record of each risk, with descriptions, scores, owners, responses and review dates. A risk matrix is a visual grid of likelihood against impact that is derived from the register as a summary. The Institute of Project Management recommends using both, with the register as the source of truth.
Who is responsible for a risk register?
The project manager usually creates and maintains the register, with input from team members, department leads and subject-matter experts. Each individual risk needs one named owner who monitors it and acts. On a program, workstream leads keep their own registers and the program manager or PMO keeps the program view.
Is a risk register a legal requirement?
None of the guides we reviewed describe a general legal requirement for a risk register. Some industries, contracts or standards may ask for risk records, so check with your compliance or legal team. Risk Management Magazine adds that registers can be discoverable in litigation, so ask legal how to handle sensitive entries.
How often should you update a risk register?
Update it at every project status meeting and at key milestones, and immediately when a new risk appears or a status changes. Asana suggests weekly or bi-weekly reviews. Vanta says relying only on periodic reviews, such as quarterly ones, creates gaps.
What is a residual risk in a risk register?
Residual risk is the score that remains after your response has been applied. Vanta lists inherent and residual scores as common fields, and Smartsheet's construction template records original and residual ratings. Comparing the two shows whether a response reduces the risk enough to justify its cost.
Leave a Reply