A risk register is the structured record of every risk an organisation has identified, with its score, owner, controls in place, treatment decision, target score, and next review date. It is the working artefact a risk assessment produces and the ongoing risk-management programme maintains. Boards, auditors, regulators, and insurance carriers all expect to see one.
A risk register is the single, structured record of every risk an organisation has identified, with its score, owner, controls, treatment decision, target score, and next review date. It is the working artefact that a risk assessment produces, and the source of truth that every risk dashboard, board report, and audit pack reconciles against.
The term originates in project management (PMBOK introduced the project risk register in the late 1980s), was generalised by the International Organization for Standardization in ISO 31000:2009, and now applies across enterprise, operational, cyber, project, financial, and compliance risk. The format varies by framework; the underlying artefact does not.
The register is a live database that updates as evidence arrives. A report is a point-in-time view of the register, produced for a meeting. The two are not the same; conflating them is the most common mistake on a new programme.
Enterprise programmes carry one master enterprise register plus operating registers per business unit, system, or project. The master register escalates from the operating registers via a documented rule.
A register without an escalation column and a review cadence is a list. With those two columns, plus a named owner per row, it becomes the control that boards, auditors, and regulators expect to see.
“Risk register: record of information about identified risks. Note 1 to entry: The term ‘risk log’ is sometimes used instead of ‘risk register’.”
Boards, regulators, insurance carriers, and customers no longer accept a control checklist as evidence of a risk programme. They expect a current register: named risks, named owners, current scores, documented treatment, next review date. The register is the answer to every ‘show me your risk posture’ question on the table.
ISO 27001 Clause 6.1.2, HIPAA Security Rule §164.308(a)(1), PCI DSS v4.0 Req 12.3.1, SOC 2 TSC CC3.1, NIST 800-30, NYDFS Part 500 §500.09, EU DORA Article 6, and SEC cyber-disclosure rules all require a documented register of identified risks and the treatment posture against each.
The 2023 SEC cyber-disclosure rules and the EU Digital Operational Resilience Act require boards to evidence that material risks are identified, assessed, and managed. A current register is the audit-ready record both regimes accept.
Cyber-insurance applications and many D&O renewals now treat a documented risk register as a pre-condition for quoting. Carriers want to see the methodology, the row-level register, and the treatment plan before binding.
Ten columns are the working minimum. Anything below this list and the register is incomplete; anything beyond it is programme maturity. Each column does one job, and dropping one weakens a specific audit answer.
A unique, stable identifier (e.g. RR-2026-014). Survives re-scoring, owner changes, and category re-organisations. The ID is what cross-references from incident records, audit findings, and KRI breaches.
One sentence in the threat-vulnerability-impact form. 'A ransomware actor (threat) exploits an unpatched VPN appliance (vulnerability) to encrypt the production tenant and halt fulfilment (impact).' If you cannot write it this way, the risk is not yet defined.
Operational, cyber and IT, financial, strategic, compliance, physical and environmental. Use a starter taxonomy and split or merge as the programme matures. Categories drive the dashboards the board reads.
A named individual accountable for the residual score, not a team or a function. The owner signs off on treatment, escalates when the score moves, and answers when the audit committee asks.
Likelihood times impact before any controls are credited. Records the raw exposure so the next reviewer can see what the existing controls are doing. Most teams use a 5x5 ordinal scale.
The preventative, detective, and corrective controls currently reducing the risk, each linked to the control library so one piece of evidence supports the register and the compliance framework.
Exposure after the controls in place are credited. The gap between inherent and residual is the work the existing controls are doing. The gap between residual and target is the work the treatment still owes.
Accept, treat, transfer, or avoid (ISO 31000 Clause 6.5.3). For treat, the planned controls, the target residual score, the owner of the treatment, and the deadline.
Next scheduled review. Top-quartile risks review quarterly; the full register reviews annually; ad-hoc on material events. Stale review dates are the single most common audit finding on a risk register.
Open, in-treatment, monitored, closed, escalated. Plus the escalation path if the residual breaches appetite (named committee, named individual, time-bound trigger). The escalation column is what makes the register a control, not a spreadsheet.
Mature programmes add a few more: target residual score (what the planned treatment should deliver), KRI links (so the residual updates as evidence arrives), compliance-framework cross-map (so one control credit applies to HIPAA, ISO 27001, SOC 2, PCI DSS, and the register at the same time), and an audit trail of every change to the row.
The row below is a representative cyber risk on an enterprise register. Realistic content, realistic numbers, the format that will hold up at audit. Pattern-match it for your first 20 rows.
| Field | Value |
|---|---|
| Risk ID | RR-2026-014 |
| Description | A ransomware actor exploits an unpatched VPN appliance to encrypt the production tenant and halt customer fulfilment for 72 hours. |
| Category | Cyber and IT |
| Owner | CISO (J. Rivera) |
| Inherent score | 20 (L4 × I5) |
| Controls in place | EDR on all servers · MFA on all VPN accounts · 30-day backup retention · quarterly patch SLO · tabletop Q1 2026 |
| Residual score | 9 (L3 × I3) |
| Treatment decision | Treat. Replace legacy VPN with zero-trust gateway by 2026-07-31. Target residual 6 (L2 × I3). |
| Next review date | 2026-08-15 |
| Status / escalation | In treatment · escalates to Risk & Audit Committee if residual > 12 |
Three things to copy from this row. First, the description is one sentence in the threat-vulnerability-impact form: a named threat, a named vulnerability, a named impact. Second, the controls list links to the control library, not to free-text prose. Third, the status column carries the escalation rule (‘escalates to Risk & Audit Committee if residual > 12’) so the register acts as a control, not a snapshot.
The sequence below is the working method for a first enterprise register, calibrated against ISO 31000, ISO 27005, and NIST SP 800-30. It also reads cleanly for project registers under PMBOK if you swap ‘enterprise scope’ for ‘project scope’ in step one.
Define what the register covers (enterprise, business unit, system, project) and the framework it follows (ISO 31000 enterprise, ISO 27005 information security, NIST 800-30 federal IT, PMBOK project, COSO ERM US public company). Document the scoring scale, the appetite line, the review cadence, and the escalation path. The methodology section is the first thing an auditor reads.
Run interviews with risk owners, pull from past incident records, audit findings, threat intelligence, vendor due diligence, and prior register cycles. Each risk gets a one-sentence statement in the threat-vulnerability-impact form. Aim for 20 to 80 risks for a first enterprise register; cull duplicates and split anything that has two distinct treatment paths.
For each risk, score likelihood and impact on the same ordinal scale across the whole register. Use documented scoring criteria so 'High' means the same thing in every assessor's hand. Multiply for an inherent score. Run a calibration session before the first full pass so assessors converge on the criteria.
For each risk, list the controls already reducing it. Pull from the control library so a single control credit applies across HIPAA, ISO 27001, SOC 2, PCI DSS, and the register at the same time. Re-score to a residual figure. The control catalogue is where the register becomes a force multiplier instead of a parallel spreadsheet.
Compare each residual score to the documented risk appetite for that category. Anything above the line gets a treatment decision (treat, transfer, avoid). Anything below the line gets accepted, with the rationale captured in the register so the next reviewer sees why. Appetite is set once at the board level; the assessment compares to it.
For risks that need treatment, design the controls. Map each new control to the risk it reduces and to any compliance framework it also satisfies. Set a target residual score the treatment is expected to deliver, an owner, and a deadline. Treatment without a target score is a wish list.
Set review dates on every row (top quartile quarterly, full register annually, ad-hoc on material events). Wire KRIs to the residual score so the register updates as evidence arrives, not just on the calendar. Name the escalation path and the time-bound trigger that fires it. The fifth step in ISO 31000 (monitor and review) is where most spreadsheets fail.
Step seven is where most spreadsheets fail. Identifying, scoring, and writing down treatments is one cycle of work; keeping the register current between cycles is a programme. A working register has named reviewers, KRI-linked residual scores, and a documented escalation path with a time-bound trigger. Without those three, the artefact decays inside a quarter.
A spreadsheet works for a first cycle. It breaks the moment the programme adds a second framework, a third assessor, or a fourth business unit. Below are the trade-offs, and the free templates we publish if you are starting on Excel.
Hard to version control. No native escalation. Control double-counting is invisible. Cross-mapping to HIPAA, ISO 27001, SOC 2, and PCI DSS lives in parallel spreadsheets that drift apart. Audit-trail rebuilds itself every quarter.
Licence cost, configuration time, change-management. A platform pays back when the programme has two or more frameworks, two or more business units, or two or more assessors.
Start in a spreadsheet, deliver the first cycle, prove the methodology. Move to a platform on the next cycle once the programme has earned the budget. RiskWatch supports the import: bring the spreadsheet across, the control library and cross-map come standard, and the audit trail starts on day one.
The three terms get used interchangeably in early programmes. ISO 31000 Clauses 6.4 and 6.5 separate them cleanly, and most audit findings against a register trace back to conflating two of them.
| Term | What it is | Cadence |
|---|---|---|
| Risk register | The artefact. A structured record of every risk identified, with scores, owners, controls, treatment decisions, target scores, review dates, and an audit trail. The source of truth that every dashboard and board pack reconciles to. | Live (updated as evidence arrives) |
| Risk assessment | The process. A bounded activity that identifies, analyses, and evaluates risks against a defined scope. Produces and updates the register. Five activities in ISO 31000: identify, analyse, evaluate, treat, monitor. | Periodic (annual full cycle, quarterly top-tier, ad-hoc on material events) |
| Risk treatment plan | The project record. ISO 31000 Clause 6.5.3. Lists the treatments that have been decided for the risks above appetite: new controls, owners, deadlines, target residual scores, dependencies. Tracks execution against the register's treatment column. | Project-paced (per treatment, until target residual is reached) |
The simplest way to remember it: the assessment is what you do, the register is what you keep, and the treatment plan is what you owe. The register holds the ‘treat’ decisions; the treatment plan holds the projects that deliver them. Pair the two on the board pack so the audit committee can see both exposure and progress at the same time. For a full walk-through of the surrounding process, see our pillar on what is a risk assessment.
Most audit findings against a risk register fall into six recurring patterns. Each one is a programme issue, not a tooling issue; fixing tooling without fixing the underlying cadence does not move the score.
Risks captured in one cycle, never reviewed, never updated. By month nine the register reflects last year's exposure. Fix: a review-date column with a hard-stop default of one year, and KRIs wired to the residual score for the top quartile.
Different assessors interpret the 5x5 scale differently, scores wander up and down between cycles, the heat map looks busy without telling the board anything. Fix: documented scoring criteria, a calibration workshop before each cycle, and a sample of risks scored by a second assessor.
The owner column says 'IT' or 'Finance' instead of a named individual. When the residual moves, no one is accountable. Fix: every risk owner is a named person with a backup. The CRO holds the owner list and refreshes it on every reorg.
The same control (MFA, EDR, training) credited against many risks without a clear mapping, so the residual scores look artificially low. Fix: a single control library, each control linked to the risks it actually reduces, and a periodic spot-test for control effectiveness.
A register that records risks but has no path for the residual score to trigger action. The artefact exists; the control does not. Fix: an escalation column with a named committee and a time-bound trigger when residual breaches appetite.
A copy of the register lives on every owner's laptop, the master is out of date, and reconciliation eats the first day of every cycle. Fix: move to a system of record with role-based access; spreadsheets remain as exports, not as the source.
Wire the residual score on every top-quartile risk to a key risk indicator (KRI), and wire the KRI to a named escalation path. The register stops being a spreadsheet the day it acts on itself: a KRI breach moves the residual, the residual breaches appetite, the escalation fires, the committee meets, the treatment plan updates. That sequence is the difference between a working register and a museum.
Twelve questions that come up on the way to a working register, with practitioner answers.
The standards and regulator references cited on this page are published by international standards bodies, US federal agencies, and the SEC. Direct links below.
The Global Register, Risk Templates aligned to ISO 31000 / ISO 27005 / NIST 800-30 / PMBOK, KRI library, escalation rules, and Risk-vs-Compliance cross-map, all on one platform. 30-day free trial, no credit card.
No credit card required · 30-day free trial · Cancel anytime
