Log In

Risk Register Examples for Project and Risk Managers

Decorative title card illustration for risk register article

Five copyable risk register entries, plus downloadable templates in Excel, Google Sheets, and Word, are what you need to start a working register in a single session. Each entry below includes realistic likelihood scores, impact ratings, controls, owners, and next-review dates you can adapt immediately.

Three things to do in the next 60 minutes:

  1. Download a template in your preferred format (Excel for offline reporting, Google Sheets for team sharing, Word for board-level narrative summaries).
  2. Run a 30-minute risk identification workshop with your team: ask “what could go wrong, who owns it, and how likely is it?” for each project phase or business function.
  3. Set your scoring thresholds before anyone fills in a single cell. Agree on what a “4” means for likelihood and what a “5” means for impact, and write it down.

The five completed entries in Section 5 are ready to copy. Start there, then build your governance rules around them.

Key Takeaways

A working risk register requires five core elements: completed entries with named owners, a calibrated scoring model, defined triggers, a fixed review cadence, and a governance rule that forces updates.

Point Details
Start with five core entries Copy the five completed entries in this guide and adapt them to your industry before adding new risks.
Score before you populate Define your 1–5 likelihood and impact scales with concrete examples before anyone fills in a score.
Name one owner per risk A risk owned by a team is owned by no one; assign a specific individual to every entry.
Review on a fixed cadence High and critical risks need monthly review; medium risks need quarterly; low risks need annual.
MSI Risk Management Certification Management and Strategy Institute’s certification formalizes the governance and scoring methodology this guide covers, with all fees included.

Table of Contents

What does a risk register actually contain?

A risk register is a structured record of identified risks, their assessed severity, assigned owners, and treatment plans. It functions as the single source of truth for every risk your organization or project has acknowledged, scored, and decided to act on. Unlike a risk log, which is often a simple running list of issues, a register includes treatment decisions, control evidence, and a named owner for each item.

Every working register needs these core fields:

  • Risk ID: A unique reference number (R-001, R-002) for tracking and audit trails.
  • Title: A short label (five to eight words) that identifies the risk at a glance.
  • Description: Three parts: the cause, the event, and the effect. “If X happens because of Y, the result will be Z.”
  • Category: Cybersecurity, regulatory, operational, financial, reputational, or project-specific.
  • Likelihood: A numeric score (typically 1 to 5) based on probability of occurrence.
  • Impact: A numeric score (1 to 5) based on severity of consequences.
  • Risk score: Likelihood multiplied by impact (inherent, before controls).
  • Inherent vs. residual columns: Inherent is the raw score before controls; residual is the score after controls are applied.
  • Controls: Existing measures already in place to reduce likelihood or impact.
  • Treatment decision: Accept, mitigate, transfer, or avoid.
  • Actions: Specific tasks to implement the treatment, with due dates.
  • Owner: The named individual accountable for monitoring and updating this risk.
  • Trigger: The observable signal that means the risk is materializing.
  • Status: Open, in progress, closed, or escalated.
  • Next review: The specific date when the entry will be reassessed.

A filled-in example of a single row: “R-003 | Ransomware attack | Unpatched systems allow malware to encrypt files, halting operations | Cybersecurity | Likelihood 4 | Impact 5 | Score 20 | Controls: endpoint protection, offsite backups | Treatment: Mitigate | Action: Patch all endpoints by March 15 | Owner: IT Director | Next review: April 1.”

How do you build a risk register from scratch?

The five steps below turn a blank template into a maintained register your team will actually use. The sequence follows the practical methodology adapted from ISO/IEC 27005 and NIST SP 800-30.

  1. Identify risks. Run a structured workshop (30 to 60 minutes) using prompts: “What could prevent us from delivering?” and “What external events could affect us?” Assign a facilitator to capture every item without filtering. Use categories (cyber, regulatory, operational, financial) as prompts to avoid blind spots. Output: a raw list of 15 to 30 candidate risks.

    • Invite cross-functional participants: project manager, IT lead, finance, legal, and operations.
    • Use a pre-built template so entries go directly into the register format.
    • Reference PMBOK-aligned project risk examples to prime the conversation.

  2. Score and prioritize. Apply your likelihood and impact scales to each risk. Calculate the inherent score (likelihood x impact). Rank by score and flag anything above your escalation threshold (for example, any score of 15 or higher on a 25-point scale). Do not score in isolation: calibrate as a group.

    • Use a 5×5 matrix to place each risk in a color zone (see Section 4).
  • Record both inherent and residual scores once controls are identified.
    • Flag the top five to ten risks for immediate treatment planning.

  1. Define treatment plans. For each high-priority risk, choose a treatment: mitigate (reduce likelihood or impact), transfer (insurance, contract), avoid (stop the activity), or accept (document and monitor). Write specific actions with due dates and named owners.

    • Each action must have one owner, not a team or department.
    • Link controls to the actions that maintain them.
    • Set a realistic completion date, not a placeholder.

  2. Monitor with triggers. A trigger is the observable signal that a risk is moving toward materialization. Define at least one trigger per high-priority risk before the register goes live.

    • Example trigger: “Vendor invoice overdue by more than 14 days” signals liquidity risk.
    • Review triggers at every status meeting so the team knows what to watch for.
    • Assign trigger monitoring to the risk owner, not a separate team.

  3. Document and report. A register that no one reads is a compliance artifact, not a management tool. Schedule a standing monthly review. Produce a one-page summary for leadership that shows the top ten risks, their scores, and any changes since the last review.

    • Version the register after every review (v1.0, v1.1) to preserve an audit trail.
    • Use a RAG (red, amber, green) status column for quick executive scanning.
    • Archive closed risks rather than deleting them; they are useful for future projects.

How do scoring models and heatmaps work?

The most common scoring model uses a 1 to 5 scale for both likelihood and impact. Multiply the two scores to get a risk rating between 1 and 25. That number places each risk in a priority band.

Likelihood scale:

  • 1: Rare (less than 10% probability)
  • 2: Unlikely (10–30%)
  • 3: Possible (30–50%)
  • 4: Likely (50–70%)
  • 5: Almost certain (above 70%)

Impact scale:

  • 1: Negligible (minimal disruption, no financial loss)
  • 2: Minor (small financial loss, short delay)
  • 3: Moderate (significant delay or cost overrun)
  • 4: Major (serious financial loss, regulatory breach)
  • 5: Catastrophic (business-threatening, irreversible harm)

Priority bands on a 5×5 matrix:

  • Score 1–5: Low (green zone). Monitor quarterly.
  • Score 6–12: Medium (amber zone). Assign owner, review monthly.
  • Score 13–19: High (red zone). Immediate treatment plan required.
  • Score 20–25: Critical (dark red zone). Escalate to senior leadership within 48 hours.

A heatmap plots each risk as a dot on a 5×5 grid, with likelihood on one axis and impact on the other. Color zones make it immediately visible which risks need urgent attention. Most teams build this in Excel using conditional formatting, or in a GRC platform that generates it automatically.

Pro Tip: Set your thresholds and calibration rules before anyone scores a single risk. Write a one-page policy that defines each scale point with a concrete example. Without it, one person’s “4” is another person’s “2,” and your heatmap becomes meaningless. Atlassian and other practitioners identify inconsistent scoring as the most common reason risk registers fail.

Diagram of risk scoring model and heatmap calibration

Five copyable risk register entries across common risk types

The table below provides five completed entries you can copy directly into your register. Inherent scores are calculated before controls; residual scores assume controls are in place and effective. Worked examples like these, covering cyber, compliance, data loss, outages, and liquidity, are the fastest way to calibrate your team’s scoring instincts.

Adaptation notes:

  • R-001 (Ransomware): A smaller team without a dedicated IT Director can assign this to the most technically capable team member and simplify controls to “cloud backup verified weekly.”
  • R-002 (Regulatory): For a construction firm, swap “data privacy regulations” for “OSHA safety standards” and adjust the owner to the site safety manager. OSHA publishes specific workplace safety guidance that supports building out safety-focused register entries.
  • R-003 (Data loss): A five-person startup can reduce this to a single control: “Google Workspace automatic backup enabled and verified.”
  • R-004 (Service outage): For a project team, reframe as “key vendor unavailability” and replace the failover test with a vendor contingency plan.
  • R-005 (Liquidity): A nonprofit can adapt this to “grant funding delay” and replace the credit facility with a reserve fund policy.

Which template variant fits your context?

Not every register needs the same shape. The right template depends on your industry, team size, and how mature your risk process is.

  • Project risk register: Built around project phases (initiation, planning, execution, closure). Add a “phase” column and link each risk to a work package. Best for teams using PMBOK or PRINCE2. Customization tip: add a “probability of occurrence by phase” column so risks that are only relevant during execution do not clutter the planning view.

  • Enterprise risk register: Covers strategic, operational, financial, and compliance risks across the whole organization. Requires a “business unit” column and a risk appetite statement. Customization tip: add a “risk appetite alignment” column (within appetite, at appetite, above appetite) to make board reporting faster.

  • Construction risk register: Heavy on safety, environmental, and contractor risks. Include a “site location” column and link each risk to a specific subcontractor or work package. Customization tip: add a “permit status” field because many construction risks are triggered by permit delays, not technical failures.

  • Compliance register: Organized by regulation or standard (GDPR, HIPAA, SOX, ISO 27001). Each row maps a requirement to a control and a gap. Customization tip: add a “regulatory deadline” column so the register doubles as a compliance calendar.

  • Agile backlog-based register: Risks are treated as backlog items with a priority score. Reviewed at each sprint retrospective. Customization tip: keep the register to five to eight active risks per sprint; anything lower priority goes to a “parking lot” tab reviewed monthly.

  • Cyber-specific register: Aligned to NIST SP 800-30 or ISO/IEC 27005. Includes threat source, threat event, and vulnerability columns alongside the standard fields. Customization tip: add a “CVSS score” column for technical vulnerabilities so the register connects directly to your vulnerability management tool.

On field count: A team new to risk management should start with eight fields (ID, title, category, likelihood, impact, score, owner, next review) and add fields only when the team will actually maintain them. A 15-column register that gets updated twice a year is worse than a 7-column register updated every two weeks.

How should you choose a file format for your risk register?

The format you pick determines whether the register gets updated or abandoned. Here is a practical breakdown:

  • Excel: Best for teams that work offline, need custom formulas for scoring, or produce formatted reports for leadership. The UCOP risk register template is a well-structured institutional example with field instructions built in. Use Excel when you need conditional formatting for heatmaps or pivot tables for reporting.

  • Google Sheets: Best for distributed teams that need real-time collaboration. Share a single link, assign edit access by column, and use Google Forms to collect risk submissions from team members who do not own the register. The downside: version control requires manual snapshots or a third-party add-on.

  • Word: Best for board-level narrative summaries or when the audience is executives who will not interact with a spreadsheet. A Word register typically contains a summary table plus a written commentary on the top five risks. Not suitable as a working register for day-to-day updates.

One-line decision checklist: If your team has more than five contributors, use Google Sheets. If you need offline access or automated scoring, use Excel. If the output is a board report, use Word as a secondary format alongside your working spreadsheet.

Keep templates lean. A register with fewer columns gets updated more often. Start with the minimum viable set of fields and add complexity only when the team asks for it, not because a template you downloaded happened to include it. Smaller, focused registers consistently outperform oversized spreadsheets because teams actually maintain them.

Spreadsheet or integrated platform: which one do you need?

Spreadsheets work well for teams that are new to risk management, running a single project, or operating with a small number of risks (under 50). They are free, flexible, and fast to set up. The trade-off is manual effort: someone has to update every cell, chase owners for status updates, and remember to version the file after each review.

Integrated GRC (governance, risk, and compliance) platforms automate the parts that spreadsheets cannot. They connect risks to controls, pull monitoring data automatically, send reminders to owners, and generate audit-ready reports. Modern risk practice increasingly favors these continuously updated registers over periodically refreshed spreadsheets.

When to move off a spreadsheet:

  • Your register has more than 50 active risks and multiple owners.
  • You need an audit trail that shows who changed what and when.
  • Risks need to connect to control evidence (policies, test results, vendor assessments).
  • Leadership requires real-time dashboards rather than monthly exports.

Tool categories to consider:

  • Spreadsheet tools (Excel, Google Sheets): Zero cost, fast setup, suitable for projects and small teams. Limited automation and no built-in audit trail.
  • Project management platforms with risk modules: Tools like Jira or Monday.com offer risk tracking within a project workflow. Good for agile teams already using those platforms. Fields are limited compared to dedicated GRC tools.
  • Dedicated GRC platforms: Purpose-built for risk management with control mapping, continuous monitoring, and compliance reporting. Higher setup effort and cost, but appropriate for organizations managing regulatory risk across multiple business units.

A note on migration: When moving from a spreadsheet to a platform, preserve your audit trail by exporting the full spreadsheet history before importing. Map your existing fields to the platform’s schema before migrating data, not after. Losing the history of how a risk was scored over time removes one of the most valuable outputs of a mature register.

What governance rules keep a risk register current?

A register without governance is a document. With governance, it becomes a management tool. The difference comes down to four rules applied consistently.

Governance rules:

  • Every risk has a named individual owner, not a team or department.
  • The register is reviewed on a fixed cadence: monthly for high and critical risks, quarterly for medium risks, and annually for low risks.
  • Unscheduled reassessments are triggered by specific events: a new regulation, a security incident, a major contract change, or a failed audit.
  • Every version of the register is saved with a date stamp and the name of the person who made changes.

Reducing scoring inconsistency:

Inconsistent scoring is the single most common reason risk registers fail. The fix is calibration before scoring begins.

  1. Write a one-page scoring guide that defines each scale point with a concrete example from your industry.
  2. Run a calibration exercise: present three to five hypothetical risks to the group and have everyone score independently, then compare and discuss differences.
  3. Agree on a set of anchor examples (one risk per score band) that the team can reference when scoring future risks.
  4. Revisit the calibration guide annually or after any major scoring disagreement.

A short calibration example: A project team scored a “vendor delay” risk as a 2 for impact (minor) and a 3 for impact (moderate) in the same session, depending on who answered. When the facilitator asked both scorers to describe the consequence in dollar terms, the team realized one person was thinking about a two-day delay and the other was thinking about a two-week delay. They added a “delay duration” qualifier to their impact scale and rescored consistently from that point forward.

Pro Tip: Schedule a 15-minute “risk triage” slot at the end of every weekly team meeting. Ask three questions: Has any risk score changed? Has any trigger been observed? Are there new risks to add? This habit prevents the register from going stale between formal reviews.

One habit that keeps a register alive

The registers that stay current share one trait: they are reviewed in a meeting that already exists, not in a meeting created just for risk. Attaching a 15-minute risk triage to a standing weekly call removes the friction of scheduling and signals that risk management is part of normal operations, not a compliance exercise.

One thing to adopt this week: At your next team meeting, add a standing agenda item: “Risk triage, 15 minutes.” Ask each risk owner to confirm whether their risk’s status has changed and whether any trigger has been observed. If nothing has changed, the meeting takes five minutes. If something has changed, you have caught it before it escalates.

Formalize your risk skills with a certification

Practical templates and governance rules get you started. Formal training locks in the methodology and gives you a credential that signals to employers and clients that your risk process is built on recognized standards.

Risk Management Certification

The Risk Management Certification from Management and Strategy Institute covers the full risk management lifecycle: identification, assessment, treatment, monitoring, and reporting. The curriculum aligns with the governance and scoring best practices covered in this guide, so the templates you are already using become part of a structured, auditable framework. All study materials and the certification exam are included in a single, all-in-one fee, with no hidden costs. You study at your own pace, from anywhere.

If you manage projects, lead a compliance function, or want to formalize the risk process your team already runs informally, the certification is a concrete next step. Visit the Risk Management Certification page to review the curriculum and enroll.

Risk Management Certification

Sources

FAQ

What should a risk register include?

A risk register should include a unique risk ID, title, description (cause, event, and effect), category, likelihood score, impact score, risk rating, existing controls, treatment decision, specific actions, a named owner, a trigger, status, and a next review date. These fields give every risk a clear owner and a documented path to resolution.

What are five common examples of risk?

Five common risk types found in most registers are: ransomware or cybersecurity attack, regulatory non-compliance, accidental data loss, operational service outage, and financial liquidity shortfall. Each appears as a completed entry in Section 5 of this guide with realistic scores, controls, and owners.

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

A risk log is typically a simple running list of identified issues or concerns with minimal structure. A risk register is a formal management document that includes scored severity, named owners, treatment decisions, controls, triggers, and scheduled review dates, making it an active management tool rather than a passive record.

How often should a risk register be updated?

High and critical risks (scores of 13 or above on a 25-point scale) should be reviewed monthly. Medium risks (scores of 6 to 12) need quarterly review. Low risks (scores of 1 to 5) are typically reviewed annually. Any significant event, such as a new regulation, a security incident, or a major contract change, should trigger an unscheduled reassessment regardless of cadence.

What scoring model works best for a risk register?

The 5×5 likelihood-by-impact matrix is the most widely used model. Likelihood and impact are each scored 1 to 5, and the two scores are multiplied to produce a rating between 1 and 25. Priority bands (low, medium, high, critical) are then mapped to color zones on a heatmap. The key is defining each scale point with a concrete example before scoring begins, so ratings stay consistent across reviewers.