Start now
Back to Blog

Project Planning•September 7, 2026•11 Min Read

Turn Risks Into Priced Contingency: Agency Risk Register Template

Risk register and contingency title card

Start with a simple shared register your team can actually review. Set up the fields, agree on what likelihood and impact mean for this project, then use a kickoff conversation to name the delivery risks that could change the work or estimate.

TL;DR:

  • A risk register gives a project team one place to describe delivery uncertainty, assign an owner, and choose a review moment.
  • Clear "if... then" descriptions and a shared scoring approach make the entries easier to discuss and act on.
  • Revisit the register when work conditions, scope, timing, suppliers, or approvals materially change.
  • Use each reviewed entry to decide whether mitigation belongs in the work plan and whether a project-specific contingency deserves a quote review.
  • Keep the register lightweight enough that owners can use it in the project conversations already taking place.

Table of Contents

What Is a Risk Register Template, and When Do You Need One?

A risk register is a shared record of project risks, their possible impact, an owner assigned to each entry and a documented response strategy. It gives a team a practical place to capture what might affect delivery, who will follow up, and what action could help.

It is useful at kickoff, when the scope takes a meaningful turn, and before a dependency or third-party input becomes important to the timeline. Those are natural points to ask what could change the work and what the team wants to review beside the estimate.

People often use three related documents:

  • Risk register: a forward-looking list that can include likelihood, impact, an owner, and a response.
  • Risk log: sometimes another name for a register; some teams use it for a simpler running list.
  • RAID log: a broader record for Risks, Assumptions, Issues, and Dependencies.

Choose the format that fits the project. A dedicated register can keep delivery risks easy to scan, while a RAID log can suit a team that wants related project notes together.

Grab the Files, Then Follow This Quickstart Checklist

Use the heading as a prompt to gather the information your team already has: a brief, notes from similar work, open client questions, and the shared format where the register will live. The useful template is a consistent field set, not a particular file type.

For a look at common risk-register layouts, existing template providers can provide useful reading alongside your own project context. Build only the fields that help your team make the next decision.

Run through this checklist before your first working session:

  1. Add columns for risk ID, scenario, category, likelihood, impact, owner, response, contingency or action, status, and next review.
  2. Define a simple likelihood and impact scale that the people on this project can use consistently.
  3. Bring forward a few recurring delivery risks from comparable work if they give the team a useful starting point.
  4. Invite the people closest to the work so ownership and response ideas are part of the kickoff conversation.

The Core Fields, and How to Fill Them Without Writing Vague Nonsense

A risk register becomes useful when an entry gives the team something specific to review. Clear language makes the response easier to plan.

Here is a practical field set and what each field can hold:

  • Risk ID: a short reference such as R001, so the team can find the entry again.
  • Title: a brief label that makes the risk recognizable at a glance.
  • Description: an "if... then" statement, such as "If the payment API vendor delays its sandbox release, then integration testing moves later."
  • Category: labels that fit the project, such as technical, vendor, scope, resource, or another useful grouping.
  • Likelihood and impact: the team's chosen ratings for how plausible the scenario is and how much it could affect the work.
  • Risk score: an optional way to combine those ratings when it helps the team sort its attention.
  • Owner: the person who will bring the next update or response action to the group.
  • Treatment: the response approach, for example avoid, mitigate, transfer, or accept when those labels suit the work.
  • Contingency: a concrete action, extra effort, or reserve the team wants to review.
  • Status: a plain current-state label, such as open, monitoring, closed, or escalated.
  • Review date: the next project moment when the team will look at the entry again.
  • Existing safeguards: relevant steps already in place, which can help a team discuss residual risk versus inherent risk.

An illustrative entry might read: "R004, subcontractor certification status, if confirmation is still missing before the inspection window, then the milestone may need a new sequence; owner: Maria Chen; response: confirm status and identify a backup; status: monitoring; next review: the next delivery check-in."

Pro Tip: Keep category names, status options, and scale definitions in one easy-to-find place. A shared reference makes updates quicker when the project changes.

Central config sheet feeding risk dropdowns

How to Build the Register at Kickoff, Step by Step

Build the first version with the people who understand the work. A short group conversation often surfaces delivery conditions that are hard to see from a brief alone.

  1. Run a structured brainstorm. Move through categories that fit the project and ask what could change the delivery plan in each area.
  2. Write clean "if... then" statements. Capture the condition and the possible effect on the work, timing, or estimate. Note any assumption that needs a client conversation.
  3. Choose a scoring model. A small matrix can suit a focused project; a larger scale can help where more distinction is useful. The existing risk-register guide is a retained reference for teams considering their own scoring approach.
  4. Calibrate together. Score a couple of examples as a group so the words and numbers have a shared meaning.
  5. Prioritize and assign. Decide which entries deserve an owner, a first response action, or a closer review point.
  6. Set a review moment. Record when the project team will revisit the entries that could change the next stage of work.

What This Looks Like in Real Projects

The fields can stay familiar across industries while the content follows the work in front of you.

  • Software project: "If the payments vendor's API sandbox arrives later than the agreed integration window, then testing may need a new sequence." The owner can be the person closest to the vendor relationship.
  • Creative or agency project: "If the client adds homepage variants after design sign-off, then the team may need to review revision effort and timing." The response can name the next conversation, the work to estimate, and the assumption behind it.
  • Construction or physical delivery: "If a subcontractor's certification status is still unclear before an inspection window, then the milestone may need a different sequence." The review point can sit near the decision that depends on it.

Keeping the Register Alive Instead of Letting It Rot

A register is most useful when it stays close to the project. Revisit it when a missed milestone, changed approval path, supplier update, or other material condition gives the team a reason to look again. The existing risk-statement guide is retained reading for writing clear entries.

A few simple practices can keep the register tied to the work:

  • Keep the scale definitions and status options easy to find so updates remain consistent.
  • Bring the entries that matter to the current decision into the relevant project conversation.
  • Notice when an entry has stayed open without a clear next action, then agree on an owner or a review moment.

Pro Tip: A short register with clear owners and next actions is easier to use than a crowded list with no current decision attached.

From Risk Entries to Priced Contingencies

A reviewed register can inform a pricing conversation. For each entry, the team can decide whether a mitigation action belongs in the work breakdown and whether a project-specific contingency is worth reviewing beside the estimate.

Risk entries flowing into priced contingencies

If you have a real brief, notes, or PDF, Roadbase can turn it into an editable project-plan and quote draft to review. Use that draft to discuss the work, assumptions, and project-specific contingency before exporting the reviewed proposal. Roadbase can create an editable draft work breakdown with phases, tasks or milestones, roles, estimated hours, timing, and brief estimate reasoning. Use the reviewed register to decide which mitigation actions belong in that work, then adjust the plan visually while keeping the estimate beside the work.

Roadbase can price estimated hours by the roles doing the work. Its quote view lets a team review labor, overhead, direct costs, contingency, and target margin behind the quote. Those inputs give the team a place to discuss a project-specific contingency alongside the work. For a related perspective, see tying contingency to a defensible percentage.

When a team wants a practical estimate workflow for its current project, the existing software consulting estimate page and Roadbase can provide product context. After review, Roadbase can export the plan and quote as a proposal PDF.

Three Governance Fixes That Actually Change Whether Teams Use This

Most teams get more value from a register when it has a clear place in the project rhythm. Three light habits help:

  1. Give each entry that needs follow-through a named owner and a visible next action.
  2. Bring the entries connected to the current decision into the meeting where that decision will be made.
  3. Set the next review moment while the team is discussing the entry, especially when timing, scope, or a dependency is moving.

Start with the risks that matter to this project, set an owner and a review moment, and let the register earn its place in the work.

- Nicolas Robertson

Sources

FAQ

How Do You Create a Risk Register?

Bring the people closest to the work together, describe each risk as an "if... then" scenario, choose a scale the team can use consistently, assign an owner where follow-through is needed, and record the next review moment. A kickoff session gives the group a practical first version to refine.

Is There a Free Excel Template for a Risk Register?

You can create a useful register in the shared format your team already uses. Start with a field set for risk ID, scenario, category, likelihood, impact, owner, response, contingency or action, status, and next review, then adapt it to the work.

What Should Be Included in a Risk Register?

Include a risk ID, description, category, likelihood, impact, owner, planned response, contingency or action, status, and next review date. Add a score or existing safeguards when those details help the team decide what to review next.

Can I Create My Own Risk Assessment?

Yes. Use categories and a scoring scale that fit the project, then calibrate a few examples with the team. That gives the group a shared way to discuss delivery uncertainty and decide what action belongs in the plan or quote review.

Recommended