Sharp. Not sentimental.
340 Lines. Three Decisions. The CRO Couldn't Separate Them.
A quarterly board risk session. The CRO presented a comprehensive register: 340 risk entries, each with inherent and residual ratings, control assessments, trend indicators, and owner names. The pack ran to 62 pages.
The board chair set it down after twenty minutes and asked a direct question: 'Of everything in this register, which three items require a decision from this board today — not monitoring, not noting, but an actual decision?'
The CRO was not unprepared. She had deep knowledge of every item in the register. What she lacked was a mechanism in the register itself that separated items requiring board decisions from items requiring board awareness. The two categories were present but not distinguished.
She took twelve minutes to work through the register live and identify the three items. The board made the decisions. But the twelve minutes revealed something structural: a register designed for completeness had no field for decision-requirement.
Honest. Not accusatory.
Risk Registers Are Built to Record Risks. They Are Not Built to Surface Decisions.
The risk register as a governance tool has a clear purpose: to ensure that identified risks are logged, assessed, assigned, and monitored. It performs this function reliably. Most mature risk functions have well-maintained registers.
What the register does not do — by design — is distinguish between risks that require a decision and risks that require monitoring. Both types of risk appear as rows in the register. Both have ratings and owners. Both appear in board reports. The register treats them identically because its architecture makes no provision for the distinction.
The consequence is that board time is spent reviewing risks that require awareness, while risks that require decisions sit in the same list without signalling that they are different in kind from the others. The board that wants to govern — not just be informed — cannot tell from the register which items it is being asked to act on.
Simple. Not simplistic.
The Decision-Priority Filter: Three Fields That Transform a Register into a Decision Tool.
Three additional fields, applied to every register entry, convert a completeness register into a decision-priority register. They can be added to any existing register structure without rebuilding it.
| FIELD | WHAT IT CAPTURES | HOW IT CHANGES BOARD ENGAGEMENT |
|---|---|---|
| Decision type | NOTE: board receives for awareness. APPROVE: board ratifies a management position. DIRECT: board instructs management to act. ESCALATE: board decides on an item above management authority. | The board can immediately see which items require action and which require awareness. The register sorts itself into governance categories. |
| Decision timeline | When must the board act? Is there a regulatory deadline, a contractual trigger, or a risk velocity that makes delay costly? | The board knows not just which decisions to make but which ones are time-sensitive. The governance cadence can align with the decision timeline. |
| Decision owner | Who is bringing this to the board with a recommendation? Who is accountable for the outcome? | The board can direct questions to the right person before the meeting. The recommendation's accountability is visible before the session begins. |
These three fields also change how the register is prepared. Adding a decision type to every entry forces the question: is this item genuinely requiring a board decision, or is it on the agenda because it was on last quarter's agenda? That question, asked routinely, reduces the register to the items that genuinely warrant board attention.
Practical. Not obvious.
Apply the Decision-Priority Filter to Your Next Board Report.
Before the next board risk report is produced, apply the three fields to every item currently on the report.
The distribution tells you the shape of the report. A report that is 90% NOTE items is an awareness report. One that contains clear APPROVE and DIRECT items is a decision report.
If the board chair is asking 'what do we need to decide today,' the report hasn't done its job yet. The decision-priority filter does that job before the report leaves the risk function.
Open. Not pushy.
The Board Confidence Scorecard
12 questions that test whether your risk reporting supports real board decisions. The decision-type distinction is one of the most common failures the scorecard surfaces.
Access here →Book a 45-Minute Decision Architecture Conversation
If the filter exercise revealed a report that cannot separate decisions from awareness items, the diagnostic session maps what a decision-priority report structure looks like in your governance context.
Book a diagnostic session →That's The Decision Layer for this week.
The CRO knew which three items required board decisions. The register didn't. That gap is the one worth closing — not because the CRO was unprepared, but because governance that depends on individual knowledge rather than system design is governance that fails when the individual changes.
Forward this to whoever prepares board risk packs. The three-field addition takes an afternoon. The decision quality it produces lasts for every board meeting that follows.