> ## Content Index
> Fetch the complete content index at: https://www.thedecisionlayer.online/llms.txt
> Use this file to discover other available public pages before exploring further.

# The Decision Layer #26: 340 Lines. Three Decisions. The CRO Couldn't Separate Them.
- URL: https://www.thedecisionlayer.online/the-decision-layer-26-340-lines-three-decisions-the-cro-couldnt-separate-them/
- Published: 2026-10-22T12:15:17.000Z
- Updated: 2026-10-22T12:15:17.000Z
- Description: A 340-line risk register could not tell the board which three decisions mattered now. Three fields turn a register from inventory into a decision tool.
- Author: Maman Ibrahim
- Tags: The Decision Layer©, Risk Register, Board Risk, Decision Prioritisation, Risk Governance, #decision-layer-series, #issue-26

Issue 26· 6 min read· Board Members · C-Suite · Senior Risk Leaders 

**This week:** A CRO presents the board with a 340-line risk register. The board chair asks: 'Which three of these should we be deciding something about right now?' The CRO cannot answer without rebuilding the report on the spot. Why risk registers are built for completeness, not for decision selection. The decision-priority filter. One filter to apply this week.

01THE SIGNAL

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.

02THE PATTERN

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.

A register that cannot distinguish between a risk that needs monitoring and a risk that needs a board decision is a reporting tool, not a governance tool.

03THE MODEL

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.

04THE MOVE

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.

For each risk item: assign a decision type (NOTE / APPROVE / DIRECT / ESCALATE). Set a decision timeline if the type is anything other than NOTE. Name the decision owner. Then count the distribution. How many APPROVE, DIRECT, or ESCALATE items are there? Are they clearly separated from the NOTE items?

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.

05THE INVITATION

Open. Not pushy.

SELF-ASSESSMENT 

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 →](https://drive.google.com/file/d/1vqF3GwGUVJaor5aYPaNeQWB50hos6f-J/?ref=thedecisionlayer.online) 

DIAGNOSTIC SESSION 

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 →](https://calendly.com/maman-thedecisionlayer/board-ai-risk-intelligence?ref=thedecisionlayer.online) 

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.