Templates

IO Reporting™ Board Risk Update Skeleton

A board risk update that reports only what is comfortable is worse than none, because it manufactures confidence that the register does not support. This skeleton enforces the three figures that must appear together and puts the uncomfortable one…

Ready to useDocument v3.24 min read

A board risk update that reports only what is comfortable is worse than none, because it manufactures confidence that the register does not support. This skeleton enforces the three figures that must appear together and puts the uncomfortable one first.

Every issued update records the reporting period, risk-model version, appetite version, maturity-model version where used, generated-at timestamp, approved-by and approved-at. Publication freezes that issue. Later evidence creates a new issue; it never rewrites what the board previously saw.

This is the standard decision-pack structure for IO Reporting™.

Industry basis and IO position

NIST CSF 2.0 places cybersecurity risk inside enterprise governance, and ISO and COSO approaches expect leadership to make risk-informed decisions rather than receive operational activity reports. IO follows that norm and adds two constraints: every material movement must retain its derivation, and every headline position must disclose how much of the population cannot be assessed.

This is a decision pack, not a compliance report and not a substitute for the organisation's established board-reporting obligations. Legal, regulatory, financial and sector-specific reporting requirements still govern.

Page 1, Decision and position against appetite

Open with the decision the board or committee is being asked to make.

Decision fieldEntry
Decision required
Recommended option
Decision owner
Decision deadline
Consequence of no decision
Strongest argument against the recommendation

Then show the position the decision rests on. A status-only pack may omit the decision table, but it must be labelled for information before publication.

Three counts and three shares. All three, always, in this order.

StateCountShareChange since last period
Cannot be assessed, no measured residual
In breach, residual measured, above ceiling
Within appetite, residual measured, at or below ceiling

The unassessable count is displayed with equal prominence. It governs how much the other two are worth, and it is the number many registers hide. A board that is told 74% of the register cannot be assessed against appetite is being given something it can act on. A board told 26% is within appetite and 0% in breach is being misled by omission.

Beneath the table, one sentence: what has to happen for the unassessable population to shrink. Usually a connector, a window, or a verification measure that was never defined.

Page 2, Coverage

One number: the share of the register carrying any measured residual.

Then the trend across the last four periods, and the reason for any movement. Coverage rising because verifications are being recorded is a programme improving. Coverage rising because unmeasured risks were closed is a register shrinking, which is a different thing and must be said.

Page 3, What moved, and why

Every residual that changed since the prior period. Both directions.

RiskDirectionFrom → toVerification that moved itMeasured before → after

Rank by measured residual only. An unmeasured risk has no established position, and placing it in a ranking implies one. List the measured exposures in order, then the unassessable separately with their count and reason.

Consolidate by verification. One intervention affecting six risk records is one row naming the count, not six identical rows.

Lead this page with a regression if there is one. A residual that rose because an intervention was measured and found to have made things worse is the most valuable line in the pack. It is evidence the measurement is real. A pack in which nothing ever regresses is a pack nobody should trust.

Page 4, Overdue and unowned

Two short lists.

Risks in breach and overdue for review, the sharpest condition in the register, reported explicitly and never merged into a general overdue count.

Risks with no owner. Nobody can review a risk that belongs to no one, and an unowned risk in breach is a governance failure rather than a security one.

Page 5, Commitments and follow-through

Record what follows from the decision on page one.

CommitmentAccountable ownerDue dateEvidence expectedEscalation if missed

Carry unresolved commitments into the next issue unchanged. Do not replace an overdue commitment with a newly worded one that resets its age.

Publication gate

Nothing is released until a named person approves the exact issue. Approval applies to the frozen content and its model versions, not merely to a report title. Delivery status is recorded separately so an approved report is not mistaken for one the intended audience received.

What not to do with this skeleton

Do not add a summary score. An aggregate number across a register with 74% unassessable is a fiction with a decimal point.

Do not colour a threshold change as improvement. If the matrix or the appetite ceiling moved this period, the pack says: "N findings resolve because the threshold moved, not because anything changed. The same records behave exactly as they did before." In those words or words that concede as much.

Do not remove a risk because it is embarrassing. Removal is a decision with a name attached, recorded like any other.

Primary references

Next step

See it before you talk to anyone.

Two quarters of recorded activity across sixteen seats. One click, no install.