Risk Register Template: The Columns, the Scoring, and the RAID Log

The register was four months old and technically perfect. Twenty-three rows, every one scored, every one categorized, colors in the score column. Somebody asked what had happened to row eleven, a data export problem that had moved from risk to issue back in June, and the answer took two days to assemble. Engineering had fixed it in July. Nobody had told the two customers who reported it, and nobody in the room had known there were two customers rather than one.

The register was not wrong. It was just describing a world that had moved on without it, which is the normal failure mode and it has almost nothing to do with the template. This guide gives you the eight columns, a scoring method with thresholds set in advance, a RAID log template for the three lanes a risk register leaves out, an issue log that stays current, a worked example, and a copy-paste version at the bottom.

What a Risk Register Actually Does

A risk register is a list of specific things that could go wrong, each with a score, a planned response, and a person who owns it. It exists to force a comparison. Any team can name fifteen worries. Very few can say which two of those fifteen deserve time this month, and that ranking is the entire product of the exercise.

Three things it is not, and each confusion produces a different useless document:

• It is not a list of topics

  Database performance, staffing, and third-party APIs are categories, not risks. A risk has a cause and an effect and something that could be done about it. Written as topics, every row is permanently true, permanently unresolvable, and permanently medium, which is why registers built this way never close a single line in the life of a project.

• It is not a compliance artifact

  Plenty of registers exist because a process document says one must exist. Those get built at kickoff, reviewed at the go or no-go meeting, and opened once more during the closure report. That is a real use, it is just not a management tool, and it is worth being honest about which one you are producing before spending a morning on scoring.

• It is not a place to record things that already happened

  A risk that occurred is an issue and needs a different set of columns, because probability stops being a meaningful field once the event is in the past. Mixing the two is the most common structural mistake in this document, and the cost is that live problems get discussed at the same weight as hypotheticals.

The Risk Register Template: Eight Columns

Eight columns, in this order. Anything beyond these tends to get filled in once and then left, and a column that is blank on half the rows makes the whole document look optional.

1. 1

   1. ID

   A short stable identifier, R-01 upward. It looks like bureaucracy and it earns its place the first time somebody refers to a risk in a meeting, a message, or a status report without having to restate the whole thing. Never reuse an ID after a row closes, because the closed rows are the ones you will want to look up later.

2. 2

   2. The risk, as a cause and an effect

   The most important cell in the document. Use the shape: because of a cause, an event may occur, which would result in an effect. The long version is worth the space, because a risk you cannot write in that shape is usually a worry rather than a risk, and finding that out during the writing is cheaper than finding it out in the review.

3. 3

   3. Category

   Technical, resource, external, schedule, or whatever set fits your work. Categories are not for sorting, they are for spotting the gap. A register with eleven technical rows and nothing under external is usually not a project without external risk. It is a project where the people in the room are all engineers.

4. 4

   4. Likelihood, 1 to 5

   How probable this is inside the project window, not in general. The window matters. A dependency that is very likely to slip at some point in the next two years may be a 1 for a six-week release. Agree what each number means once and write the definitions at the top of the document, because five people scoring on private scales produce numbers that cannot be compared.

5. 5

   5. Impact, 1 to 5

   What it costs if it happens. Be specific about the unit. A 5 that means catastrophic is unscoreable, a 5 that means slips the release by more than two weeks or affects more than ten percent of accounts can actually be argued about. Impact is where scoring goes soft, and the fix is a definition rather than more discussion.

6. 6

   6. Score

   Likelihood multiplied by impact, so 1 to 25. The precision is fake and everybody knows it. What the number buys you is a forced ranking between two rows that would otherwise both be described as pretty bad, and that comparison is the thing the register exists to produce.

7. 7

   7. Response

   Avoid, reduce, transfer, or accept, plus one sentence on what that means concretely. Accept is a legitimate answer and it should be written down as a decision rather than left as an empty cell, because an empty cell reads as an oversight to whoever inherits the document.

8. 8

   8. Owner and review date

   One name, never a team, plus the date this row gets looked at next. The pair is what makes the register a live document. A row with an owner and no date drifts, and a row with a date and no owner arrives at its review with nobody prepared to say anything about it.

How to Score Risk Without the Numbers Going Soft

A five by five grid gives scores from 1 to 25. What it does not give you is a decision, and that gap is where most scoring exercises quietly fail.

Set the thresholds first, in the document, before the first row gets a number:

• 1 to 6 is low: log it, review it monthly, do nothing else

  Low is not a euphemism for ignore. It means the row stays visible and gets rescored on the normal cadence, which matters because likelihood moves as a project progresses. Most rows should land here, and a register where nothing is low usually means the scale is being used to express concern rather than probability.

• 8 to 12 is medium: name a response, review it every two weeks

  Medium is where a response strategy becomes mandatory even if the response is accept. This band is the one that inflates, because medium feels responsible in a way that low does not. If more than about a third of your rows are medium, the scale is being used politically and the fix is to rescore against the written definitions rather than to argue about individual rows.

• 15 and up is high: an owner, a dated action, and a weekly review

  High should be uncomfortable and rare. Three or four high rows on a project is normal and nine is a signal about the project rather than about the register. When a row crosses into high, something has to change in the plan, and if nothing changes then the score is decorative and everybody will learn to read it that way.

• Rescore on the cadence, and close rows out loud

  The review that keeps a register alive is rescoring, not adding. A risk that was a 20 in week two and is a 4 in week nine because the migration completed should be marked closed with a line saying why. Registers that only grow become unreadable, and unreadable documents get replaced by somebody's memory of what the risks are.

The number is not the output. The forced comparison between two rows that both felt bad is the output, and a register that never changes anyone's ranking has not done its job.

RAID Log: The Three Lanes a Risk Register Leaves Out

RAID stands for risks, assumptions, issues, and dependencies. A risk register is the first of those four. The RAID log is the wider document, and the argument for running it is that the other three lanes are where projects tend to actually come apart.

Run the four in one document with four sections rather than four files. The single most useful property of a RAID log is that a row can move between lanes without being retyped, and four separate documents quietly prevent that.

RAID Log Template

The RAID log template below is the risk register plus three shorter tables. The column sets differ on purpose, because an issue with a probability column and a dependency with a mitigation strategy are both signs of a template that was copied rather than designed.

RAID LOG: [ project ]                    Last reviewed: [ date ]
Owner of this document: [ one name ]     Next review: [ date ]

Likelihood  1 rare  2 unlikely  3 possible  4 likely  5 near certain
Impact      1 trivial  2 minor  3 material  4 serious  5 severe
Thresholds  1-6 low   8-12 medium (response required)   15+ high (weekly)


RISKS
ID    | Risk (because X, Y may occur, resulting in Z) | Cat | L | I | Score | Response | Owner | Review
R-01  |                                               |     |   |   |       |          |       |
R-02  |                                               |     |   |   |       |          |       |


ASSUMPTIONS
ID    | We are assuming...        | Confirmed by whom | By when | Status | Becomes if false
A-01  |                           |                   |         |        |
A-02  |                           |                   |         |        |


ISSUES
ID    | What happened | Raised | Severity | Impact on plan | Owner | Target close | Status
I-01  |               |        |          |                |       |              |
I-02  |               |        |          |                |       |              |


DEPENDENCIES
ID    | What we need | From whom | Needed by | Confirmed? | If it misses... | Owner
D-01  |              |           |           |            |                 |
D-02  |              |           |           |            |                 |

The status column in the issues table is the one that rots, and the next two sections are about why.

Issue Log Template: Where a Risk Goes After It Happens

An issue log is the record of risks that already occurred plus problems that arrived without ever having been predicted. Most of the rows are the second kind, which is worth knowing before anyone concludes that a register with unpredicted issues was badly built.

The columns differ from the risk table in three ways that matter:

1. 1

   Severity replaces likelihood and impact

   Probability is meaningless once the event has happened, so the two scoring columns collapse into one severity rating. If your team already runs a severity scale for defects, reuse it rather than inventing a parallel one, and see bug severity versus priority for why the two are different fields and not a single one.

2. 2

   Target close date replaces review date

   A risk gets reviewed. An issue gets resolved by a date. The distinction changes what the weekly meeting sounds like, because a target close date that has passed is a specific question with a specific answer, while a review date invites a general update.

3. 3

   Impact on plan replaces the response strategy

   Avoid and transfer are not available once something has happened, so the column becomes what this costs us and what we are changing because of it. Write the schedule or scope consequence explicitly, because an issue with no recorded impact on the plan is the kind that gets absorbed silently and then explains a missed date two months later.

When a risk materializes, move it rather than duplicating it. Mark R-07 closed with a line saying it occurred on a date and became I-03, and open I-03 with the same wording. The trail is what lets you look back at the end of a project and see which risks you predicted and which ones arrived from a direction nobody was watching, which is most of the value in a project closure review.

Project Risk Assessment: The First Pass

A project risk assessment is the session that populates the register in the first place. Ninety minutes, done once at the start and repeated at any significant change of scope.

1. 1

   1. Gather silently first, for ten minutes

   Everyone writes their own risks before anyone speaks. The first person to talk in an open session sets the frame for the whole room, and in risk work that means the register ends up reflecting one person's specialty. Silent writing is the cheapest available upgrade to this meeting.

2. 2

   2. Sort into the four RAID lanes before scoring

   Half of what people write will be assumptions and dependencies rather than risks, and sorting first stops the group from scoring probability on things that already happened. This step routinely takes longer than expected and it is the step that makes the scoring afterward mean anything.

3. 3

   3. Rewrite each risk as cause and effect

   Do this together and out loud for the first few. It is slow, it feels pedantic, and it is where roughly a quarter of the list turns out to be duplicates or vague worries. A room that skips this step ends up scoring topics, and topics all score 3.

4. 4

   4. Score against the written definitions, then rank

   Score individually, compare, and discuss only where people differ by two or more. The disagreements are the informative part, because a gap of three on likelihood usually means two people are imagining different events under the same sentence.

5. 5

   5. Assign owners and dates to the top rows only

   Take the highest-scoring five or six and give each a named owner and a dated action. Trying to assign all twenty-three in the room produces a document where most rows have an owner who was not consulted, which is functionally the same as no owner at all.

Risk Register Example: A Release With Two Real Risks In It

Structure advice is easy to agree with, so here is a compressed version with the proportions right. Note how much more room the two high rows take than the eight low ones.

R-04. Because the export runs a single unbatched query, month-end reporting may time out for accounts above roughly fifty thousand records, which would affect the four largest accounts on the day they most need the report. Category technical. Likelihood 4, impact 5, score 20, high. Response reduce: batch the query behind a flag before month-end. Owner Marc, review weekly.

R-09. Because the payments vendor has not confirmed the sandbox upgrade date, integration testing may not be able to start in week three, which would compress the test window to under a week. Category external. Likelihood 3, impact 4, score 12, medium. Response transfer: get a written date, and if none arrives by the eighth, escalate to the account manager. Owner Priya, review every two weeks. Note that this row is really a dependency wearing a risk's columns, and it moved to D-02 the following week.

A-02. We are assuming the four largest accounts run their month-end reports in the first three business days. Confirmed by the customer success lead, by the tenth. Status open. If false, R-04's impact drops to 3 and it stops being the top row.

I-03. R-04 occurred on the second. Two accounts hit the timeout during month-end and both filed support tickets. Severity high. Impact on plan: pulls one engineer off the vendor integration for three days, which puts R-09 up by one on likelihood. Owner Marc, target close the ninth.

I-03, three weeks later. Status still reads in progress. The fix actually shipped on the eighth. The engineering issue was closed, the register was never updated because the person who owned the row was not the person who closed the issue, and neither of the two customers who filed the original tickets was ever told. Nobody in the review could say how many accounts had been affected without going back through the help desk by hand.

That last paragraph is the realistic one, and it is not a discipline problem.

Why the Issues and Dependencies Rows Go Stale First

Sort a year of RAID rows by whether they stayed accurate and the pattern is immediate. Risks and assumptions stay current, because both are owned by someone in the room and reviewing them is a conversation among people who are present. Issues and dependencies go stale, because the work that resolves them happens somewhere the register's owner cannot see.

The most expensive version in a product company is the confirmed defect. A risk materializes, becomes an issue, and the resolution belongs to engineering. From the register's point of view the row now points at a backlog it has no visibility into. So the status column says in progress until somebody manually goes and asks, and the two facts that actually matter, which customers are affected and whether the fix has shipped, live in two systems that do not know about each other.

That is the same broken trail that makes closing the customer feedback loop the step teams skip, that forces the what-shipped slide in a QBR to be rebuilt by hand every quarter, and that leaves the evidence section of a PRD impossible to reconstruct months later.

The version that stays current is mechanical, and it depends on the link being recorded when the issue is opened rather than reconstructed at review time:

• Give the issue row the engineering issue's real identifier

  Not a description, not a link pasted into a comment, the actual issue key stored on the record. It costs nothing when the row is created and it converts every future status check from an investigation into a lookup. A row that points at a searchable identifier survives its owner going on vacation.

• Attach the reporting accounts at the moment of escalation

  An issue row that says two accounts affected is worth several times one that says customers affected. Recording the requesting account on the engineering issue when it is filed is what makes that count available later. Linear's customer requests model exists for exactly this, and its value shows up a month after anyone bothers to use it.

• Let the status flow back rather than being retyped

  A status column updated by hand is accurate on the day of the review and drifting by the next one. If the ticket that raised the issue and the engineering issue that resolves it stay in sync, the register's status is a read rather than a chore, and the review stops opening with five minutes of people not knowing.

• Close the loop when the fix ships

  A fix that shipped on the eighth and reached the customer in November was worth a fraction of what it should have been. If the issue carries its reporters, then writing the release notes and telling the affected accounts become the same short job rather than two separate ones that only the first of ever gets done.

That table is not really about risk registers. It is about whether the handoff from support to engineering left a durable trail, and the register is simply the recurring meeting where a team discovers it did not. The same gap turns up in defect management, in the escalation matrix when nobody can say what happened after the escalation, and in managing feature requests from support to engineering.

For teams where support runs on HubSpot Service Hub and engineering runs on Linear, IssueLinker is what keeps that trail intact. A ticket becomes a linked Linear issue in one click with the customer's own wording carried across, the requesting account travels with it, and status and comments sync both ways, so an issue row's status is something you read rather than something you chase. The Linear HubSpot integration guide covers how the two-way sync works, and how to get bugs fixed faster covers the handoff itself.

The Risk Register Review Checklist

Run this at the recurring review. It takes about fifteen minutes and it prevents most of the ways a register quietly stops being trusted.

The fifth and sixth items are the ones that fail, and they fail structurally rather than through carelessness.

Mistakes That Make a Risk Register Decorative

Four patterns account for most registers that get built with care and then abandoned by week six.

• Scoring everything as medium

  When most rows land in the middle band, the register has stopped ranking anything and has become a list with numbers on it. The cause is nearly always missing definitions rather than indecisive people. Write what 1 through 5 mean, rescore against the definitions, and accept that a good register has a lot of low rows.

• Owners that are teams rather than people

  Assigning a row to engineering, to support, or to the vendor is how a risk survives four reviews untouched. A team cannot be asked on Thursday how it is going. Every row needs one name even when the work will obviously be shared, because the name is who notices when the row stops moving.

• A register that only grows

  Rows get added at every review and none get closed, so by month three the document takes twenty minutes to read and gets skimmed instead. Closing rows is the maintenance that keeps the rest legible, and a register with no closed rows in it has not been reviewed, it has been appended to.

• Keeping it somewhere nobody works

  A register in a document that opens only at the review is a register nobody updates between reviews. Put it where the project already lives, and accept a slightly worse table in exchange for a document that is current. The formatting is not what makes this useful.

The thread through all four is that a risk register is judged by whether it changed a decision. If a project ran exactly as it would have without the document, the document was a description, and describing a project is much easier than steering one.

Copy-Paste Risk Register Template

Here is the register on its own, without the other three RAID lanes, for teams that want to start with one table. Paste it into a doc, a sheet, a wiki page, or your tracker.

RISK REGISTER: [ project ]

Document owner: [ one name ]
Last reviewed:  [ date ]        Next review: [ date ]

SCALES
Likelihood  1 rare  2 unlikely  3 possible  4 likely  5 near certain
            ( within this project's window, not in general )
Impact      1 trivial   2 minor   3 material
            4 serious ( slips the date or hits >10% of accounts )
            5 severe  ( stops the release or hits the largest accounts )
Score       likelihood x impact, 1 to 25
Thresholds  1-6 low, review monthly
            8-12 medium, response required, review every 2 weeks
            15+ high, dated action required, review weekly


ID:         R-01
Risk:       Because [ cause ], [ event ] may occur,
            which would result in [ effect ].
Category:   [ technical | resource | external | schedule | scope ]
Likelihood: [ 1-5 ]      Impact: [ 1-5 ]      Score: [ L x I ]
Response:   [ avoid | reduce | transfer | accept ]
            [ one sentence on what that means concretely ]
Owner:      [ one name, never a team ]
Review:     [ date ]
Status:     [ open | closed on DATE because ... | occurred, now I-0n ]


ID:         R-02
...


CLOSED THIS PERIOD
- [ R-0n ]  [ closed or occurred ]  [ date ]  [ one line on why ]

Keep the closed section at the bottom rather than deleting rows. It costs nothing, and at the end of the project it is the only record of which risks you saw coming and which ones arrived from a direction nobody was watching. That comparison is worth more than the register was during the project, and it is the input to the next one.

If the same risk shows up on three consecutive projects, stop mitigating it row by row and give it a root cause analysis of its own. Recurrence across projects is a signal about the system rather than about any one plan, and a register is good at revealing that and poor at fixing it.

Frequently Asked Questions

What is a risk register?

What should a risk register include?

What is the difference between a risk register and a RAID log?

How do you score risk in a risk register?

What is the difference between a risk and an issue?

How often should a risk register be reviewed?

Who owns the risk register?