Free Excel download β’ Edit online β’ Save & share with Drive β’ Export to PDF
A Risk Register is a structured governance document that identifies, scores, assigns ownership for, and tracks every known risk facing a project or organization. Each entry records the specific risk event, its probability and impact scores, the Risk Priority Number derived from those scores, the inherent risk rating before controls, the mitigation controls in place or planned, a residual risk rating after controls, the treatment strategy, a named accountable owner, and scheduled review dates. It functions simultaneously as an operational management tool, a compliance evidence document, and a board-reporting instrument β used across project management, enterprise risk management, regulatory compliance, and insurance due diligence contexts worldwide.
Without a documented risk register, your organization has no systematic way to distinguish between risks that require urgent action and those that can be monitored, no evidence of due diligence to present to auditors, regulators, or insurers, and no individual accountability for risk events that materialize. When a data breach, a supply chain failure, or a regulatory violation occurs, the first question from your insurer and your legal counsel will be whether you had a documented risk management process in place β and whether the relevant risk was identified, assessed, and mitigated. A gap in that evidence trail directly affects coverage decisions, regulatory penalties, and litigation outcomes. A well-maintained risk register, formally approved and regularly updated, closes that gap and demonstrates that your organization manages risk systematically rather than reactively.
| If your situation is⦠| Use this template |
|---|---|
| Managing risks across a defined project with a start and end date | Project Risk Register |
| Logging IT, data security, and infrastructure risks for SOC 2 or ISO 27001 | IT Risk Register |
| Identifying and mitigating risks in a construction or capital project | Construction Risk Register |
| Tracking enterprise-wide strategic and operational risks for board reporting | Enterprise Risk Register |
| Documenting supplier and third-party vendor risks | Vendor Risk Assessment |
| Assessing risks associated with a specific process or procedure | Risk Assessment Report |
| Maintaining a business continuity plan alongside risk documentation | Business Continuity Plan |
Why it matters: Entries like 'reputational risk' or 'IT risk' cannot be scored, owned, or mitigated. They give auditors and boards the impression that risks have been acknowledged but not actually analyzed.
Fix: Rewrite every entry as '[Cause] could lead to [Specific Event], resulting in [Quantified or Described Consequence].' This forces specificity and makes mitigation planning actionable.
Why it matters: A register approved at project kickoff and never updated is a compliance artifact, not a management tool. New risks emerge, controls fail, and scores change β an outdated register provides false assurance to decision-makers.
Fix: Assign a named register owner responsible for scheduling and completing reviews at defined intervals. Log the date and outcome of every review in the status column.
Why it matters: When everything is rated high, the register provides no prioritization signal. Leadership cannot direct resources, and auditors question the methodology's credibility.
Fix: Anchor your scoring scale to agreed numerical thresholds before rating any risk. A calibrated scale β where 'high probability' means greater than 70% likelihood in the relevant period β produces a distribution that reflects reality.
Why it matters: Risks assigned to 'the team' or 'management' are reliably never reviewed. Without individual accountability, mitigation actions stall and review dates pass without action.
Fix: Name a single individual β by full name and role β as the owner of each risk. Document their acceptance of ownership and include their review obligations in the register itself.
Why it matters: Without the before-controls baseline, it is impossible to demonstrate the value of your risk management program to auditors, insurers, or boards. The gap between inherent and residual risk is the evidence that controls are working.
Fix: Score every risk twice: once assuming no controls exist, and once reflecting current controls. Record both scores and the delta in adjacent columns.
Why it matters: Mitigation reduces the likelihood or impact of a risk before it occurs; a contingency plan is activated after it occurs. Combining them means you have no defined response when a risk event actually materializes despite controls.
Fix: Create two separate fields for every high-rated risk: one for the preventive/detective mitigation control, and one for the step-by-step contingency response if the event occurs regardless.
In plain language: Names each risk, describes the event or condition that could occur, and categorizes it by type β strategic, operational, financial, legal, reputational, or technology.
Risk ID: [R-001] | Category: [OPERATIONAL] | Description: [SPECIFIC RISK EVENT OR CONDITION] could occur due to [ROOT CAUSE], resulting in [CONSEQUENCE].
Common mistake: Writing risks as vague issues ('market risk', 'IT failure') rather than specific event statements. A vague risk description cannot be assigned, scored, or mitigated effectively.
In plain language: Rates each risk on a 1β5 scale for likelihood of occurrence and severity of impact, producing a Risk Priority Number used to rank all risks in the register.
Probability: [1 = Rare / 2 = Unlikely / 3 = Possible / 4 = Likely / 5 = Almost Certain] | Impact: [1 = Negligible / 2 = Minor / 3 = Moderate / 4 = Major / 5 = Critical] | RPN: [PROBABILITY Γ IMPACT]
Common mistake: Scoring all risks as high probability and high impact to appear diligent. This flattens the register, making genuine critical risks indistinguishable and impossible to prioritize.
In plain language: Documents the risk rating before any controls are in place, establishing a baseline to measure the effectiveness of mitigation actions.
Inherent Risk Rating: [HIGH / MEDIUM / LOW] based on unmitigated probability score of [X] and impact score of [X], yielding RPN of [X].
Common mistake: Skipping the inherent risk rating and recording only the residual risk. Without the baseline, it is impossible to demonstrate the value of controls to auditors or boards.
In plain language: Describes the specific preventive or corrective actions in place or planned to reduce the probability or impact of each risk, with target completion dates.
Mitigation Action: [SPECIFIC CONTROL OR ACTION]. Status: [PLANNED / IN PROGRESS / IMPLEMENTED]. Target Date: [DATE]. Control Type: [PREVENTIVE / DETECTIVE / CORRECTIVE].
Common mistake: Listing generic controls like 'staff training' or 'regular review' without specifying what training, by whom, covering what content, and by what date.
In plain language: States the revised risk rating after all mitigation controls have been applied, confirming whether the risk now falls within the organization's defined risk appetite.
Residual Risk Rating: [HIGH / MEDIUM / LOW] | Revised Probability: [X] | Revised Impact: [X] | Revised RPN: [X] | Within Risk Appetite: [YES / NO].
Common mistake: Setting residual risk ratings optimistically before controls are actually implemented. Residual ratings should reflect the current state of controls, not the intended future state.
In plain language: Documents the response actions to be activated if the risk event occurs despite mitigation β including escalation triggers, responsible parties, and recovery steps.
Trigger: [SPECIFIC EVENT OR THRESHOLD]. Response: [IMMEDIATE ACTIONS]. Escalation To: [ROLE / NAME]. Recovery Target: [TIMEFRAME / OBJECTIVE].
Common mistake: Omitting contingency plans for high-rated risks on the assumption that mitigation will prevent them. Auditors and insurers specifically look for contingency planning on residual high risks.
In plain language: Assigns a named individual or role as the accountable owner for each risk entry, responsible for monitoring status, implementing controls, and reporting changes.
Risk Owner: [FULL NAME / ROLE TITLE]. Department: [DEPARTMENT]. Escalation Contact: [SENIOR ROLE]. Review Frequency: [MONTHLY / QUARTERLY].
Common mistake: Assigning the risk register itself as a shared team responsibility with no individual owner per risk. Without individual accountability, review cycles are missed and controls go unimplemented.
In plain language: Records the last review date, next scheduled review date, and current status of each risk, ensuring the register is a living document rather than a point-in-time snapshot.
Last Reviewed: [DATE]. Next Review Due: [DATE]. Current Status: [OPEN / MONITORING / CLOSED / ESCALATED]. Change Since Last Review: [DESCRIPTION OR 'NO CHANGE'].
Common mistake: Setting review dates but never updating the status column. A register with review dates that have passed and statuses marked 'open' from 12 months ago actively damages credibility with auditors.
In plain language: Documents the chosen strategic response to each risk β whether to avoid it entirely, reduce it through controls, transfer it via insurance or contract, or formally accept it within risk appetite.
Treatment Strategy: [AVOID / REDUCE / TRANSFER / ACCEPT]. Rationale: [ONE SENTENCE JUSTIFICATION]. If Transfer: [INSURANCE POLICY / CONTRACT REFERENCE]. If Accept: [APPROVED BY / DATE].
Common mistake: Defaulting every risk to 'reduce' without considering whether transfer or acceptance is more cost-effective. Insuring a low-frequency, high-impact risk is often more efficient than maintaining expensive preventive controls.
In plain language: Provides a top-level dashboard view of the total risk portfolio β count of high, medium, and low risks, trend direction, and top three risks requiring board or leadership attention.
Total Risks Logged: [X] | High: [X] | Medium: [X] | Low: [X] | Risks Escalated This Period: [X] | Top Risk for Leadership Attention: [RISK ID AND DESCRIPTION].
Common mistake: Omitting an executive summary and sending the full detailed register to boards. Senior stakeholders need a one-page summary with trend data β a 40-row detailed register without context produces no decisions.
Decide upfront whether the register covers a single project, a department, or the entire organization. Define your risk categories (strategic, operational, financial, legal, reputational, technology) so every risk is classified consistently from the start.
π‘ Agree on category definitions in a short kickoff meeting before anyone enters data β inconsistent categorization is the most common cause of an unusable register.
Conduct a risk identification session with stakeholders from each function. Use prompts like 'What could prevent us from achieving this objective?' and 'What has gone wrong before?' Log every risk raised, even if it seems unlikely.
π‘ A SWOT or PESTLE analysis run before the workshop surfaces strategic and macro risks that internal teams typically overlook.
Frame every risk entry as '[Cause] could lead to [Event], resulting in [Impact].' This three-part structure makes risks actionable and prevents vague entries like 'cybersecurity risk' from entering the register.
π‘ If you cannot write a specific consequence for a risk, it is not defined precisely enough to manage β break it into more specific sub-risks.
Apply your 1β5 probability and impact scales consistently across all risks. Use the same scoring definitions for every entry β agree on what 'major' impact means in dollar terms or operational disruption before scoring begins.
π‘ Anchor your impact scale to real numbers: for example, score '4 = Major' only if the financial impact exceeds $500K or causes more than 5 days of operational downtime.
Allocate each risk to a specific individual β not a team, not a department β who is accountable for the mitigation controls and status updates. Confirm acceptance of ownership with the individual before the register is finalized.
π‘ Risk owners should have the authority and budget to actually implement the controls assigned to them. Assigning a junior analyst to own a board-level strategic risk creates an accountability gap.
For each risk, list at least one preventive or detective control that is already in place, plus any additional actions needed. Assign a responsible person and a target completion date to every open action.
π‘ Distinguish between controls that are already operating and those that are planned. Auditors treat these very differently β mark each clearly as 'implemented' or 'planned, due [DATE]'.
After documenting controls, re-score probability and impact to produce a residual risk rating. For every risk rated high after mitigation, document the treatment strategy and obtain sign-off from the relevant risk owner or senior manager.
π‘ If residual risk remains high after all planned controls, escalate it to the executive summary section and flag it for board awareness β do not bury it in the detail rows.
Enter a next-review date for every risk entry β monthly for high risks, quarterly for medium, annually for low. Have the risk register formally approved and signed by the accountable executive before submitting it to auditors, clients, or regulators.
π‘ Build a calendar reminder for every review cycle at the time of sign-off. The most common audit finding is a risk register that was approved once and never updated.
A risk register is a structured document used to identify, assess, prioritize, and track risks facing a project or organization. Each entry records the risk description, probability and impact scores, a Risk Priority Number, the mitigation controls in place, a named owner, and scheduled review dates. It serves as the central reference for risk management decisions, board reporting, and compliance with standards such as ISO 31000, ISO 27001, and SOC 2.
At minimum: a unique risk ID, a specific risk event description, a risk category, probability and impact scores, a Risk Priority Number, the inherent risk rating, mitigation controls with status and due dates, a residual risk rating, the treatment strategy (avoid, reduce, transfer, or accept), a named risk owner, and next review date. A complete register also includes a contingency plan for high-rated risks and an executive summary section for board-level reporting.
No single law universally mandates a risk register for all businesses. However, it is explicitly required by several compliance frameworks β ISO 9001, ISO 27001, ISO 31000, SOC 2, and the UK Corporate Governance Code β and is effectively required by many regulated industries including financial services (FCA, SEC), healthcare (HIPAA), and construction (CDM Regulations in the UK). Many commercial contracts and government procurement frameworks also require one as a contractual deliverable.
Inherent risk is the raw exposure before any controls exist β the risk level if you did nothing. Residual risk is the exposure that remains after all planned mitigation controls are implemented and operating. The gap between the two is the evidence that your controls are effective. Auditors and insurers look for both scores in every well-structured register; a register that records only one undermines your risk management credibility.
High-rated risks should be reviewed monthly; medium-rated risks quarterly; and low-rated risks annually at minimum. The full register should be reviewed and formally signed off at the start of each project phase, after any significant change to the business or operating environment, and before any regulatory audit or compliance submission. Most ISO and SOC 2 auditors expect to see evidence of periodic review in the form of dated status updates within the register itself.
Overall ownership of the register sits with the accountable executive β typically the CFO, COO, or Chief Risk Officer for an enterprise register, or the project manager for a project-level register. Individual risks within the register should each be owned by a named person with the authority and budget to implement the assigned controls. The register owner is responsible for scheduling reviews and escalating unresolved high-rated risks to the board or senior leadership.
A risk assessment is a point-in-time analysis of risks in a specific context β a process, a facility, or a project activity β that produces a report. A risk register is the ongoing living document that aggregates all identified risks, tracks their status over time, and records the controls and ownership for each. A risk assessment typically feeds entries into the risk register; the register is the operational tool used to manage them continuously.
A single enterprise risk register can capture organization-wide strategic and operational risks. However, project-specific risks are typically managed in a separate project risk register because their scores, owners, review cycles, and treatment strategies differ significantly from enterprise risks. Mixing them produces a register that is too unwieldy to use effectively. The preferred approach is a two-tier structure: an enterprise register for organizational risks and separate project registers that escalate material risks to the enterprise level.
For internal management purposes, a formal signature is not always required. However, when a risk register is submitted to regulators, auditors, clients under a contractual obligation, or insurers as evidence of due diligence, it should be formally approved and signed by the accountable executive. A signed, dated register with a version history is significantly more defensible in a legal or regulatory dispute than an unsigned working document.
A risk assessment report is a point-in-time analysis of risks in a specific context β a process, a facility, or a single project phase β that produces a formal written report. A risk register is the ongoing operational document that aggregates, tracks, and manages all identified risks continuously. A risk assessment typically generates inputs for the register; the register is the living tool used to act on those inputs over time.
An issue log records problems that have already occurred and are actively being resolved. A risk register records events that have not yet occurred but could. Confusing the two leads organizations to manage risks reactively rather than proactively. Once a risk event materializes and becomes an active problem, it transitions from the risk register into the issue log.
A business continuity plan defines how the organization will continue operating after a major disruptive event has occurred. A risk register identifies and mitigates risks before they occur. The two documents are complementary: the register's contingency plans for high-rated risks should feed directly into the business continuity plan's response procedures. Neither replaces the other.
A project management plan defines scope, schedule, budget, and delivery methodology for a project. A risk register is a dedicated component of project governance that specifically tracks what could go wrong and how it will be managed. Most project management frameworks β PRINCE2, PMI PMBOK, and APMP β require a risk register as a mandatory artifact within the broader project management plan.
Regulatory capital risk, credit and counterparty exposure, AML compliance failures, and model risk β each requiring quantified financial impact scores aligned to FCA, SEC, or Basel III thresholds.
Safety and CDM compliance risks, subcontractor default, site environmental incidents, and cost overrun on fixed-price contracts β where contractual risk allocation must mirror register entries.
Patient safety events, HIPAA and GDPR data breach risks, clinical trial regulatory deviations, and supply chain failures for controlled substances β with regulatory submission requirements driving review frequency.
Cybersecurity and data breach risks for SOC 2 and ISO 27001, third-party API or cloud provider dependency, key-person concentration risk, and IP infringement exposure.
Supply chain disruption, equipment failure and downtime, environmental compliance breaches, and product liability risks β with mitigation controls tied to ISO 9001 quality management requirements.
Professional indemnity and errors-and-omissions exposure, client concentration risk, data confidentiality obligations under engagement contracts, and key-person departure risk.
No single federal law mandates a risk register for all businesses, but sector-specific regulations effectively require one. SEC-registered companies must disclose material risk factors in annual 10-K filings under Regulation S-K. HIPAA requires documented risk analysis for covered entities. SOX Section 404 requires documented internal controls over financial reporting, which typically relies on a risk register. State data privacy laws β including CCPA β increasingly require documented risk assessments.
PIPEDA and provincial privacy laws require documented risk assessments for personal information handling, with PIPEDA's breach-of-security-safeguards rules expecting evidence of risk management practices. Federal Crown corporations and provincially regulated financial institutions are subject to OSFI guidelines that require formal enterprise risk frameworks. Quebec's Law 25 (effective 2023) requires a documented privacy impact assessment that integrates directly with risk register practices.
The UK Corporate Governance Code requires premium-listed companies to maintain a robust risk management framework with board-level oversight, effectively mandating a documented risk register. The CDM Regulations 2015 require a construction phase risk register on all notifiable construction projects. The FCA's Senior Managers and Certification Regime (SM&CR) creates personal accountability for named individuals β making documented risk ownership in a register critical for demonstrating compliance. The UK GDPR requires Data Protection Impact Assessments that align with risk register methodology.
GDPR Article 32 requires organizations to implement risk-based technical and organizational measures, with risk registers serving as the primary evidence of compliance. NIS2 Directive (effective October 2024) mandates documented risk management measures for operators of essential and important entities across the EU. DORA (Digital Operational Resilience Act), applicable to financial entities from January 2025, requires ICT risk registers as a mandatory governance artifact. Member states vary in enforcement intensity, with Germany, France, and the Netherlands among the most active regulators.
| Path | Best for | Cost | Time |
|---|---|---|---|
| Use the template | Project managers and operations teams managing internal risk registers for standard projects or ISO certification | Free | 3β6 hours for initial population |
| Template + legal review | Organizations submitting the register to regulators, auditors, or clients as a contractual deliverable | $500β$2,000 for a risk consultant or compliance advisor review | 1β3 days |
| Custom drafted | Regulated industries (financial services, healthcare, critical infrastructure) or organizations under active regulatory scrutiny requiring a bespoke risk framework | $3,000β$15,000 for a specialist risk management consultant | 2β6 weeks |
This document is one of 3,000+ business & legal templates included in Business in a Box.
Access over 3,000+ business and legal templates for any business task, project or initiative.
Customize your ready-made business document template and save it in the cloud.
Share your files and folders with your team. Create a space of seamless collaboration.
"Fantastic value! I'm not sure how I'd do without it. It's worth its weight in gold and paid back for itself many times."
"I have been using Business in a Box for years. It has been the most useful source of templates I have encountered. I recommend it to anyone."
"It has been a life saver so many times I have lost count. Business in a Box has saved me so much time and as you know, time is money."
Stop downloading documents. Start operating with clarity. Business in a Box gives you the Business Operating System used by over 250,000 companies worldwide to structure, run, and grow their business.
Start freeΒ Β·Β No credit card required
