The risk register is the most widely owned and least respected document in risk management. Every organization above a certain size has one; almost nobody can answer the only question that matters about it: what decision did this register change in the last quarter? The failure modes are so common they have furniture names — the graveyard (four hundred rows nobody has read since the consultant left), the wallpaper (a beautiful heat map that appears in every board deck and influences nothing), the ransom note (risks written so vaguely that no one could ever be accountable for them). And yet the register, done properly, is the organization’s single agreed picture of what could hurt it — ranked, owned, and wired to action. No other document does that job.
This guide is the register end to end: what it is for and where it sits among its sibling documents, every field and the reason it exists, a fully worked enterprise-level example, the scoring and appetite wiring that gives ratings consequences, the governance that keeps it alive, and the failure catalog — with fixes. It completes the core trio of our Risk Library: appetite decides what the organization is willing to hold, the RCSA is how management reports what it believes it is holding, and the register is where those two meet a ranked list and someone’s name.
In this guide
- What the register is for
- Register, RCM, RCSA: the three-document ecosystem
- Anatomy: every field and why it exists
- Writing risks people can own
- A worked enterprise register
- Scoring, appetite, and consequence
- Governance: keeping it alive
- The failure catalog
- How internal audit should use — and audit — the register
- Register formats compared
- Cascading registers: a worked roll-up
- The register review meeting
- Register metrics that show whether it is alive
- Frequently asked questions
What the register is for
Strip away the templates and the register does three things. It forces a single list: one agreed inventory of the organization’s material risks, instead of forty departmental versions that cannot be compared or added up. It forces a ranking: limited management attention allocated explicitly, on the record, rather than by whoever spoke last in the executive meeting. And it forces ownership: every row carries a name — a person with the authority to accept the risk or the budget to treat it. A document that does those three things earns its keep even if the scoring model is crude. A document that does none of them is a compliance exhibit, however sophisticated its methodology tab looks.
The test of a working register is behavioral, not aesthetic: risks move on and off it, ratings change when the world changes, out-of-appetite entries generate decisions with dates, and executives reference it unprompted when arguing for resources. If the register has been stable for two years while the organization launched products, changed systems, and reorganized twice, the register is not describing the organization — it is describing the year it was written.
Register, RCM, RCSA: the three-document ecosystem
These three get conflated constantly, and the confusion produces documents that do no job well. They differ on axis and altitude. The risk register is the enterprise- or business-level inventory: relatively few risks (a board-level register carries perhaps 10–25), each broad enough to matter to strategy, each owned by an executive. The risk and control matrix is a process-level instrument: one process, eight to twenty specific risks, mapped to the controls that address them and the tests that will prove it — the auditor’s working document. The RCSA is not a document at all but a process — the periodic exercise by which management self-reports its risks and control effectiveness, whose output populates and refreshes registers. Altitude is the practical tell: “cyber risk” belongs on the enterprise register; “terminated users retain system access because deprovisioning is manual” belongs in an RCM; the difference between what the register says and what the RCSA returned belongs on the risk committee’s agenda.
Registers also cascade. Most organizations run an enterprise register at board altitude, divisional or functional registers beneath it, and project registers at the edge. The discipline that makes a cascade work is explicit linkage with translation: a divisional register’s top risks should visibly roll up into (or consciously not into) enterprise entries, with the wording translated to the right altitude rather than copied. When the same sentence appears verbatim on the project register and the board register, one of those audiences is being served the wrong document.
Anatomy: every field and why it exists
| Field | What goes in it | Why it exists |
|---|---|---|
| Risk ID | Stable identifier (ER-07) | Committee minutes, KRIs, and audit plans reference it; never renumber |
| Risk title | Short handle (3–6 words) | What people say in meetings; the statement below is what they mean |
| Risk statement | Event + cause + consequence, at register altitude | Vague statements make ownership unenforceable — see the writing section |
| Category / taxonomy | Strategic, operational, financial, compliance — or your house taxonomy | Enables aggregation, trend views, and completeness checks against the taxonomy |
| Owner | One named executive role | The register’s entire enforcement mechanism; “shared” ownership is no ownership |
| Inherent rating | Impact × likelihood before controls, on anchored scales | Shows what is at stake if the control environment degrades |
| Residual rating | Impact × likelihood after current controls | The number appetite is compared against |
| Appetite status | Within / approaching / outside appetite | The consequence trigger — outside-appetite rows must generate decisions |
| Trend | Improving / stable / deteriorating, with a date | Direction is often more decision-relevant than level |
| Key controls / mitigations | The handful of things currently relied on, summarized | Links the rating to reality; detail lives in the RCM, not here |
| Response & actions | Treat / tolerate / transfer / terminate, plus open actions with dates | Where the register becomes a management tool instead of a description |
| KRIs | The 1–3 indicators watched for this risk, with thresholds | The early-warning wiring; a top risk with no indicator is being watched by nobody |
| Last reviewed / next review | Dates and reviewer | Staleness made visible; the graveyard’s first symptom is old dates |
| Assurance map ref | Recent audit, RCSA, or external review coverage | Shows the board what evidence sits behind the rating — and where nothing does |
Fourteen fields is the full set, and the same discipline applies here as to the RCM’s columns: the minimum viable register — statement, owner, residual rating, appetite status, response, review date — is six fields, and a register whose every field is maintained beats a wider one that has quietly gone stale. Add fields when a real consumer exists for them, and delete any column that has survived two cycles unfilled.
Writing risks people can own
Register risk statements fail in the same ways RCM risk statements do — category labels (“cyber risk”), absent causes, missing consequences — but the altitude adds a failure of its own: statements written so broadly that they are unfalsifiable and therefore unownable. “The organization may be affected by adverse economic conditions” is true of every organization in every year; no executive can be accountable for it, no rating of it can be wrong, and no action retires it. The register-altitude formula keeps event + cause + consequence but names the organization’s specific exposure: not “cyber risk” but “a ransomware event encrypts core operational systems because legacy-platform segmentation and recovery capabilities lag the threat, halting customer operations beyond the tolerable outage window.” Still board-altitude — no server names — but specific enough that it can be rated, owned, watched, and eventually retired. One more register-specific rule: write the risk, not the missed opportunity of the mitigation. “Failure to implement the new ERP” is a project status line; the risk is what the failure does — misstated reporting, manual-workaround cost, control gaps during parallel running.
A worked enterprise register
Here is an illustrative eight-row register for a mid-size operating company, written to the standard above. Ratings read inherent → residual on a five-point anchored scale (impact/likelihood); the point is the craft in each cell, not the specific numbers.
| Risk | Owner | I → R | Appetite | Response and open action | KRIs watched |
|---|---|---|---|---|---|
| ER-01 Cyber resilience. Ransomware encrypts core operational systems because legacy segmentation and recovery lag the threat, halting customer operations beyond the tolerable outage window | CISO | 5/4 → 4/3 | Outside | Treat: network segmentation program and immutable backup coverage for all tier-1 systems, due Q4; quarterly restore tests | % tier-1 systems meeting recovery SLA in test; critical patch latency |
| ER-02 Third-party concentration. A single payment processor carries most transaction volume; its failure or exit halts revenue collection beyond contingency capacity | COO | 4/3 → 4/2 | Approaching | Treat: dual-sourcing feasibility and contractual exit-assistance uplift, decision due Q1 | Single-vendor share of critical volume; processor incident count |
| ER-03 Regulatory change velocity. New obligations across jurisdictions outpace implementation capacity, producing breaches and remediation cost | CCO | 4/4 → 3/2 | Within | Tolerate with monitoring; horizon-scanning process owned by compliance | Obligations past implementation due date; open regulatory findings |
| ER-04 Key-person and scarce-skill attrition. Loss of critical engineering and finance-systems staff stalls the transformation program and degrades control operation | CHRO | 4/3 → 3/3 | Approaching | Treat: retention plan for named critical roles; succession coverage to 100% of tier-1 roles by Q2 | Regretted attrition in critical roles; time-to-fill; succession coverage % |
| ER-05 Financial reporting integrity. Misstatement risk from manual close processes during the ERP migration window | CFO | 4/3 → 3/2 | Within | Tolerate through cutover with compensating review controls; revisit post-migration | Late adjustments per close; unreconciled items > 30 days |
| ER-06 Product concentration. Revenue dependence on the flagship line leaves earnings exposed to a single competitive or regulatory shift | CEO | 4/2 → 4/2 | Within (watched) | Tolerate: concentration is strategy; board reviews the exposure semi-annually against pipeline | Revenue share of top product; new-product pipeline mix |
| ER-07 Transformation delivery. ERP cutover fails or degrades key controls during parallel running, disrupting operations and reporting | CIO | 5/3 → 4/3 | Outside | Treat: extended parallel run, control-uplift workstream, independent readiness assessment before go/no-go | Milestone slippage; open severity-1 defects; control exceptions in parallel run |
| ER-08 Liquidity and covenant headroom. Cash concentration and covenant terms leave limited headroom against a demand shock | CFO | 4/2 → 3/2 | Within | Tolerate; refinancing options paper maintained current | Covenant headroom %; weeks of available liquidity |
Read it the way a board member should. Two rows sit outside appetite, and both carry dated, funded actions — that is the register working. The statuses are mixed; a register showing every risk comfortably within appetite is either a very boring business or a scoring problem. Every row names one owner, watches named indicators, and states a response that is a decision (“tolerate: concentration is strategy”) rather than a placeholder. And ER-06 shows something registers rarely admit: a risk can be large, deliberate, and accepted — the register’s job is to make that acceptance explicit and reviewed, not to pretend the risk away.
Scoring, appetite, and consequence
Everything we wrote about scoring discipline in the RCSA guide applies at register altitude, compressed: anchored scales (impact bands in money, regulatory, and operational terms; likelihood in frequencies) so two executives land within a notch of each other; inherent defined as exposure-if-key-controls-fail, so the inherent-residual gap shows how much is riding on the control environment; never average across risks — the register reports worst-case and count, not a blended index. What the register adds is the appetite wiring: each residual rating maps to the appetite scale from your appetite statements, and the status column — within, approaching, outside — is the trigger mechanism. “Outside” must mechanically open a decision: treat with a dated action, or have someone with authority sign an explicit acceptance. “Approaching” exists so the register produces early conversations instead of late surprises. A register without that wiring is a measurement system with no actuator — which is why so many beautifully scored registers change nothing.
Governance: keeping it alive
Curatorship and ownership are different jobs. The risk function curates the document — methodology, consolidation, challenge, reporting — but each row is owned by the executive named on it, and the cure for “the CRO’s register” (a document management tolerates rather than uses) is making owners present their own rows to the risk committee. Rhythm: quarterly review as the floor, with event-driven refresh on the same triggers that reopen every risk document — reorganizations, major incidents, system cutovers, acquisitions, new products. Two disciplines separate living registers from graveyards. First, forced turnover: every cycle should add, retire, or materially re-rate something; retirement needs criteria (exposure reduced with evidence, absorbed into another row, or risk period ended) and a graveyard tab where retired rows go with their history — auditable, but out of the working view. Second, challenge with evidence: the committee confronts ratings with loss events, audit findings, and KRI breaches exactly as the second line challenges RCSA self-ratings, and a register whose ratings have never been overturned is receiving dictation, not oversight. Minute the decisions — especially acceptances. An accepted risk with no record of who accepted it reverts, at incident time, to having been nobody’s decision.
The failure catalog
| Failure mode | What it looks like | The fix |
|---|---|---|
| The graveyard | Hundreds of rows, most untouched for years; nobody can name the top five | Altitude discipline (10–25 enterprise risks), forced turnover each cycle, retirement criteria and a history tab |
| The wallpaper | Heat map in every deck; no decision traceable to it | Appetite wiring: outside-appetite rows mechanically open treat-or-accept decisions with owners and dates |
| The ransom note | Statements so vague no one could be accountable (“economic conditions may affect results”) | Event + cause + consequence at register altitude; if it cannot be rated wrong, rewrite it |
| Orphan and committee-owned risks | Owner column says “management” or lists four names | One executive per row with authority to accept or budget to treat; co-owners become consulted parties |
| The static register | Same rows, same ratings, three cycles running, through a reorg and two incidents | Event triggers plus forced re-rating; track and report the change rate as a health metric |
| Shadow registers | The “real” risk list lives in the CEO’s head or a divisional spreadsheet | Merge or kill: make the official register the one that allocates attention and money, and shadows die of neglect |
| Score theater | Two-decimal risk scores from unanchored gut ratings | Anchored scales, honest granularity (5 points, not 100), challenge with evidence |
How internal audit should use — and audit — the register
Use it as an input, never as the answer. The enterprise register is a primary source for audit’s own risk assessment, and the divergences are the most valuable part: a risk audit rates high that the register omits is either an audit blind spot or a management one, and the audit plan should find out which. But the Global Internal Audit Standards require the plan to rest on audit’s own documented assessment — adopting management’s register wholesale outsources the one judgment the function exists to make independently. Auditing the register itself is a high-leverage engagement: test completeness against the taxonomy and against what the divisional registers and RCSA output contain; re-perform a sample of ratings against the anchors; trace every outside-appetite row to a documented treat-or-accept decision; check the KRI column against indicators actually reported; and run the back-test — lay the last twelve months of incidents, losses, and findings against the prior register and see whether reality landed in rows the register rated green, or in risks it did not contain at all. That last analysis, presented as a single exhibit, has changed more risk programs than any methodology memo.
Final thoughts
The register is where a risk program stops being philosophy and becomes a list with names on it. Kept at the right altitude, written so ratings can be wrong, wired to appetite so statuses force decisions, and governed so rows turn over, it is the most useful page in the board pack. With appetite, the RCSA, and the register covered, the core machinery is complete — the wider context lives in our comprehensive operational risk guide, and the full set of frameworks, templates, and assessment tools is collected in the Risk Library.
Register formats compared: spreadsheet, GRC platform, board dashboard
The register’s format matters less than its governance, but the wrong format makes the right governance harder. Three formats dominate, and most organisations end up running two of them: a system of record and a presentation layer. The table compares them on the things that decide whether the register stays alive.
| Format | Strengths | Weaknesses | Fails when | Best used as |
|---|---|---|---|---|
| Spreadsheet | Universal; flexible; zero cost; owners can edit without training | No audit trail; version sprawl; links to KRIs and actions are manual; retirement history lost | More than one person maintains it, or the organisation passes a few hundred rows across cascaded registers | The system of record for small organisations and for a single enterprise register |
| GRC platform | Audit trail; workflow for review and acceptance; linkage to controls, issues, KRIs and the audit universe; cascade handled natively | Cost; configuration effort; copy-forward made effortless; owners avoid the tool and send emails instead | Configured by the vendor’s template rather than the organisation’s taxonomy, or when the tool becomes the process | The system of record for larger organisations; see the software hub for how GRC and audit platforms overlap |
| Board dashboard | Readable; focuses attention on movement and out-of-appetite rows; drill-down to detail | Not a record; tempts precision theater; averaging creeps in through the visuals | It becomes the only artefact and nobody maintains the detail beneath it | The presentation layer, generated from the system of record each quarter |
The failure that unites all three is the same one the RCSA guide warns about: the tool doing the thinking. A GRC platform that pre-populates this quarter’s review with last quarter’s ratings and a single “confirm” button produces a register with a perfect audit trail of nobody thinking. Whatever the format, the review step should require the owner to look at the evidence (loss events, KRI readings, audit findings since the last review) before the rating can be confirmed, and the platform should record that the evidence was displayed.
Cascading registers: a worked divisional-to-enterprise roll-up
The cascade section above gives the rule: explicit linkage with translation. Here is what it looks like for one enterprise risk, ER-07 Transformation delivery, in an organisation with three divisions each running its own register. The point of the exercise is that the divisional rows are different risks at a different altitude, not copies of the enterprise sentence.
| Level | Risk statement (at its own altitude) | Owner | Residual | Linkage note |
|---|---|---|---|---|
| Enterprise (ER-07) | ERP cutover fails or degrades key controls during parallel running, disrupting operations and reporting | CIO | 4/3; outside appetite | Rolls up DR-12, DR-31 and DR-44 below; the enterprise rating is set by judgment on the worst divisional exposure and the cross-divisional dependency, not by averaging |
| Division A (DR-12) | Order-to-cash cutover for the distribution business loses or duplicates customer orders during the dual-running window because interface reconciliations are manual | Division A COO | 4/3 | Primary driver of ER-07; shares the go/no-go gate |
| Division B (DR-31) | Plant maintenance scheduling moves to the new system before spare-parts master data is cleansed, causing stock-outs and unplanned downtime | Division B operations director | 3/3 | Contributes to ER-07; distinct operational consequence |
| Division C (DR-44) | Statutory reporting for the overseas entities relies on manual extracts during parallel running, risking late or misstated filings | Division C finance director | 3/2 | Contributes to ER-07 and to ER-05 (financial reporting integrity); cross-linked |
| Project register (PR-08) | Data migration defects in the customer master are not detected before cutover because reconciliation tolerances are set too wide | Programme data lead | Project scale: High | Feeds DR-12; a project risk, not a divisional one; closes at go-live |
Three features of the roll-up are worth copying. The enterprise rating is a judgment that names its basis, because an average of 4/3, 3/3 and 3/2 would understate a risk whose divisional components share one go/no-go decision. The project register row is linked but kept at project altitude, with a closing event, so that it does not become a permanent row in a register it does not belong in. And the cross-link between DR-44 and ER-05 is recorded in both places, which is how the register avoids counting one exposure twice or zero times. The risk taxonomy guide supplies the categories that keep cascaded rows comparable; the strategic risk assessment guide covers the top-down exercise that produces the enterprise rows in the first place.
The register review meeting: a forty-five-minute agenda
A register is kept alive in a meeting, and the meeting is usually run badly: every row read aloud, every rating confirmed, no decision taken. The agenda below runs in forty-five minutes at a risk committee or executive committee with ten to twenty-five enterprise risks, and it is built around movement and decisions rather than coverage.
| Minutes | Item | Who speaks | Output |
|---|---|---|---|
| 0 to 5 | What changed since last review: rows added, retired or re-rated, in one slide | Risk function | The committee sees turnover and asks about surprises |
| 5 to 20 | Out-of-appetite rows: each owner presents status of the treat-or-accept decision and the action dates | Row owners, not the CRO | Decisions confirmed, re-dated with reason, or escalated |
| 20 to 30 | Approaching-appetite rows and deteriorating trends, with the KRI readings behind them | Risk function, then owners | Early conversations; watch items named |
| 30 to 38 | Challenge: loss events, audit findings and KRI breaches in the period laid against the ratings they contradict | Risk function with internal audit present | Ratings changed on evidence, or rationale for holding recorded |
| 38 to 43 | Acceptances: risks the committee is being asked to accept explicitly, with the owner’s rationale | Owner, then chair | Acceptance minuted with name and date, or declined |
| 43 to 45 | Items for the board’s version of the register and the next review date | Chair | Board pack content agreed |
What is absent from the agenda is as important as what is on it: no reading of stable rows, no debate about scores that have not moved and no presentation by the risk function of other people’s risks. Owners presenting their own rows is the single discipline that converts the register from the CRO’s document into management’s. Internal audit attends the challenge item because its findings are part of the evidence, and because what it hears is an input to its own risk assessment; the quarterly pack guide shows how the audit committee then sees the register’s highlights alongside audit’s view of them.
Register metrics that show whether it is alive
Because the register’s failure modes are behavioural, its health is measured behaviourally. Five metrics, reported to the committee once or twice a year, make staleness visible before it becomes a graveyard.
- Turnover rate: share of rows added, retired or re-rated by at least one notch in the year; a living enterprise register typically moves a quarter to a third of its rows.
- Decision latency: median days from a row entering out-of-appetite status to a minuted treat-or-accept decision; weeks is healthy, quarters is wallpaper.
- Challenge outcomes: number of ratings questioned with evidence and the number changed, in each direction; zero changes in a year is dictation.
- Back-test hit rate: share of the year’s material incidents, losses and audit findings that landed in rows the register rated outside or approaching appetite, rather than in green rows or in risks the register did not contain.
- Owner presentation rate: share of out-of-appetite rows presented by their named owner rather than by the risk function.
Frequently asked questions
What is a risk register?
The organisation’s agreed inventory of its material risks, each written as event, cause and consequence at the right altitude, rated inherent and residual on anchored scales, mapped to appetite, owned by one named executive, wired to key controls, actions and indicators, and reviewed on a cadence with event-driven refresh. An enterprise register typically holds ten to twenty-five risks; divisional and project registers cascade beneath it.
How many risks should an enterprise risk register contain?
Ten to twenty-five. Below that the register is probably missing something; above it the register has slipped to the wrong altitude and is carrying process-level risks that belong in risk and control matrices or divisional registers.
What is the difference between a risk register and a risk and control matrix?
Altitude and purpose. The register is the enterprise- or business-level inventory of broad risks owned by executives; the RCM is a process-level working document mapping eight to twenty specific risks to the controls that address them and the tests that prove it. “Cyber risk” belongs on the register; “terminated users retain access because deprovisioning is manual” belongs in an RCM.
How often should the risk register be reviewed?
Quarterly as the floor, by a committee at which owners present their own rows, with event-driven refresh on reorganisations, major incidents, system cutovers, acquisitions and new products, and an annual back-test of the prior year’s ratings against what happened.
Who owns the risk register?
The risk function curates it (methodology, consolidation, challenge, reporting); each row is owned by the one executive named on it, who has the authority to accept the risk or the budget to treat it. “Shared” ownership is no ownership, and a register management tolerates rather than uses is usually one the risk function has been left to own alone.
Should internal audit rely on the risk register for its audit plan?
Use it as an input, never as the answer. The Global Internal Audit Standards require the plan to rest on audit’s own documented assessment. The divergences between the register and audit’s view are the most valuable part, and auditing the register itself (completeness, rating integrity, decisions on out-of-appetite rows, KRI linkage, back-test) is a high-leverage engagement.
Related guides
- Risk taxonomy — how to build one, with a three-level example.
- Risk assessment matrix — design, calibration and the pitfalls.
- Designing a KRI program — selection, thresholds and escalation for the indicator column.
- Risk appetite vs tolerance vs capacity vs limits — the four layers defined and cascaded.
- How to run an RCSA that is not theater — the process that populates and refreshes the register.
- The annual internal audit risk assessment — how audit uses the register as an input.
- How to run a strategic risk assessment — surfacing the bet-the-company risks that become enterprise rows.
- How internal audit should audit the ERM program — criteria, maturity and independence.
- Reporting to the audit committee — where the register’s highlights meet audit’s view.
Leave a Reply