Board prep

Stress-test a risk register before the board reviews it

Before the risk register goes to the board, stress-test it line by line. Every risk needs one owner by role, a score with a stated reason, a trigger that says when it becomes urgent, and a mitigation with a date. Anything already happening is an issue and belongs on a separate list. Paste the register, last year's version, recent incidents, and your executives' top worries into one request. Instruct Pingpong to flag risks with shared or vague owners, scores that have not moved in a year, mitigations that say only "monitor," issues sitting in the register as if they were still hypothetical, and worries leaders named that it omits. Review your written answers in a second round.

This page is for chief executives and finance leaders preparing a register for board or audit committee review. Counsel owns legal and compliance risk framing. Pingpong checks the register for consistency and readiness. Executive starting points live under Pingpong for executives.

Five tests for every line

  • Owner: a single role. If the owner is "leadership team," nobody owns it.
  • Score: likelihood and impact, each with a sentence explaining why, and what changed since last quarter.
  • Trigger: a leading indicator and a threshold. When it crosses, the owner acts and the board hears about it.
  • Mitigation: a specific action, its owner, and a date. "Monitor" is a plan only if someone knows what they are watching for.
  • Risk or issue: if it has already happened, move it to the issue log with its own response.

How registers turn into theater

Registers usually start accurate. Someone runs interviews and the scores get argued over. Then the quarterly update becomes a copy of the last one with the date changed. Scores cluster in the middle of the grid because a high score invites questions and a low one looks careless. Owners drift to "leadership" as people change roles. New risks arrive and old ones never leave. Directors notice. Those on several boards can tell within a page whether a register is a working tool or a ritual.

A worked example

This example is illustrative and does not describe a customer. A 400-person company prepares its annual risk review for the audit committee. The register has 40 lines, each scored on a five-by-five grid.

The finance leader pastes the register, last year's version, a year of incidents and near misses, and short interview notes on what worries each executive most.

A useful pass finds that 31 of the 40 risks are scored three by three, and 27 have the same score they had a year ago. Eleven list the leadership team as owner. Six lines describe things already happening: the largest customer has given notice, a key compliance certification is delayed, and a senior engineer who maintains the billing system has resigned. None of the 40 has a trigger. Fourteen mitigations say "monitor." The risk four executives named in interviews, that one distribution partner accounts for 35 percent of revenue and its contract renews in nine months, does not appear at all.

The revised register has 12 risks for the board, with the rest kept in an operating appendix. Each has one owner by role, a score with its reason, a trigger, and a dated mitigation. The partner concentration risk is near the top, owned by the revenue leader, with a trigger tied to renewal talks and a plan to bring the share below 25 percent over two years. The six live issues move to an issue log with response owners. Counsel reviews the wording of the compliance and litigation risks before the meeting. A new column shows movement since last quarter, and one risk is marked as accepted, with the reason.

Before the board sees it

  1. Lead with the five risks that matter most and what moved.
  2. Say which risks you have chosen to accept, and why.
  3. Show the issue log separately, so live problems get their own conversation.
  4. Name the risk the register missed last year, if there was one, and what changed in the process.

When a risk needs rehearsing as a live scenario, see run a crisis tabletop before the real incident tests the plan.

A request you can copy

Below are our current risk register, last year's version, recent incidents and near misses, and executive interview notes. For each risk, check for a single owner, a reasoned score, a trigger, and a dated mitigation. Flag scores unchanged for a year. Separate risks from issues already happening. List concerns from the interviews that the register misses. Suggest the short list the board should see. Stop there so we can answer in writing, then review our answers.

How Pingpong runs the review

The web review app sends your request through several models in order. Each later model receives the original request and every earlier answer, with instructions to assess the work so far. For the steps inside the app, see running your first review.

What a model can't review

A model can only weigh the risks it is shown, and it cannot sense what your team is reluctant to write down. The interviews matter more than the grid. Pingpong checks whether the register reflects what they surfaced.

When the decision goes to the board, see war-game a decision before the board meeting. More guides live under work decisions before you commit.