Skip to content

2.5.A KPIs, KRIs & Reporting to the executive and board" (the machinery) ~50 min Module 2 · Governance

Reporting to the executive and board

What you'll be able to do in this chapter
  • Tell a key performance indicator from a key risk indicator, and know which the board needs.
  • Choose metrics that are tied to a risk or objective and that drive a decision.
  • Build a board-altitude reporting pack that reports against appetite.

The all-green report that says nothing

Your first report to the executive could go one of two ways. The tempting version is a page full of green indicators: "100% antivirus coverage", "98% of staff completed training", "patches applied on average within five days". It looks reassuring, the room nods, the item is approved, and you have told them almost nothing about whether Scaldimet is actually exposed. Module 6 teaches the board to see through that report. Your job, from this side, is to build a better one. Reporting is part of governance. It gives decision-makers a view of risk, performance and the decisions that need their attention.

KPIs and KRIs are not the same

Two kinds of number get shown to boards and called "risk". They are different, and the difference decides whether a report is useful.

  • A KPI (key performance indicator) measures how well an activity is being done. "98% training completion." "Patches applied within five days." These describe effort and performance.
  • A KRI (key risk indicator) signals whether risk is rising or falling. "Number of OT systems still on a flat network." "Number of third-party accounts with unmonitored access." These describe exposure and danger.

The trap is that a page of green KPIs can sit happily above a serious, untreated risk. Scaldimet could show "100% antivirus coverage" (a fine KPI) while the French production network stays flat and unsegmented (a screaming KRI). Performance looks excellent; exposure is severe. You must build both kinds of number, but you must report the mix that tells the truth, and lead with the risk indicators.

A practical example: the 3×30 rule

(As this course is written, wildfires are affecting much of Europe. I use this example with respect for those fighting them and those affected.)

Firefighters watch a rough 3×30 rule for dangerous fire behaviour: around 30°C, 30 km/h wind, 30% humidity. When those cross together, fire can spread rapidly. (Exact figures vary by service; the principle is the point.)

That is a KRI, not a KPI. It says nothing about how well the crews work but it describes the conditions and level of risk they face. A service can have every truck checked and every drill completed (KPIs all green) and still face extreme danger because the weather turned.

A KRI asks "is the risk becoming more dangerous?", not "are we doing the work?".

What makes a metric worth reporting

Most metrics are vanity: easy to collect, comfortable to show, and decision-free. A metric earns its place on a report only if it has four properties:

  • Tied to a risk or objective. It traces back to something in the strategy (2.1). A number that maps to no objective is noise.
  • Owned. A named owner is accountable for moving it (Chapter 2.4). An unowned metric never improves.
  • Has a threshold or target. A number with no line drawn cannot trigger anything. "Three unowned critical systems" matters only against a target of zero.
  • Drives a decision. If no possible value of the metric would change what leadership does, do not report it. The test of a good indicator is that crossing its threshold forces an action.

Apply that test and most of the comfortable green disappears, replaced by a short list of numbers that actually move decisions.

Who you report to, and how often

Reporting is not one act aimed at one audience. It runs in tiers, each at a different levels of detail and reporting frequency:

  • The security committee (Chapter 2.4) sees the detail, often: the full metric set, every open exception, the operational movement.
  • The executive committee sees a regular summary (the risks that need an executive decision or resource) on a monthly or quarterly rhythm.
  • The board sees a distilled view, periodically: the few risks that bear on the objectives, each against appetite, with the decisions attached.

The higher the tier, the fewer the numbers and the larger each one's meaning. A report that hands the board what the committee should see has failed upward; one that hands the committee only what the board sees has failed downward. The same underlying data, distilled differently for each.

Reporting against appetite

Whatever the tier, two disciplines make a report land:

  • Against appetite. For each risk, state whether it is inside or outside the appetite set in the strategy (2.1). "Outside appetite" is what turns a risk from information into a decision.
  • So what, to the business. Translate every technical risk into its business consequence: lost production, missed deliveries, penalties, the contract.

There is a governance function in this too: the report is the record that leadership was informed. Under the accountability the law now places on the management body, a clear, accurate report is part of how it discharges that oversight duty.

Scaldimet's first honest reporting pack

A starting set of numbers, each tied to a risk and a threshold:

  • KRI: OT systems on a flat, unsegmented network (target 0; currently all of Site Beta). Outside appetite.
  • KRI: third-party accounts with unmonitored access (target 0; currently at least the maintenance contractor). Outside appetite.
  • KRI: critical systems without a named owner (target 0; falling as Chapter 2.4 is applied).
  • KPI: remote-access reviews completed on schedule (target 100%).
  • KPI: training completion across both sites (target 95%).

The one-page view leads with the three KRIs against appetite, each with a business "so what" and the decision being asked, of the ExCo routinely, and of the board when a risk rises to that level, and keeps the KPIs as supporting detail rather than the headline.

Application: design Scaldimet's reporting pack

By hand, choose three KRIs and two KPIs for Scaldimet. For each, write the risk or objective it traces to, its owner, and its threshold or target. Then sketch the one-page view: the top risks against appetite, each with a one-sentence business consequence and the decision (if any) the board is being asked to make. Finally, apply the killer test to every metric: if no value of it would change a board decision, cut it.

Model answer (open after you've drafted yours)

Three KRIs and two KPIs, each traced, owned and thresholded:

Metric Type Traces to Owner Target
OT systems on a flat, unsegmented network KRI Production continuity Beta operations director 0 — outside appetite
Third-party accounts with unmonitored access KRI Contractor-access risk Beta operations director 0 — outside appetite
Critical systems with no named owner KRI Ownership / governance CISO 0
Remote-access reviews completed on schedule KPI Access-control standard Alpha IT manager 100%
Training completion, both sites KPI Awareness HR / CISO 95%

One-page view (sketch): lead with the two "outside appetite" KRIs, each in one business sentence ("the French line could be halted by a compromise it is not segmented against") and the decision asked of the ExCo; keep the KPIs as supporting detail. Killer test: if a metric's value would change no decision, cut it. Yours passes if every metric traces to a risk or objective, is owned, and has a line drawn.

Key takeaway

Reporting is a governance instrument, not after-the-fact paperwork, and a poor report misleads the people you most need to inform. A KPI measures how well an activity is done; a KRI signals whether risk is rising; a wall of green KPIs can hide a severe exposure, so build both and lead with the risk indicators. A metric earns its place only if it is tied to an objective, owned, has a threshold, and drives a decision. Report at altitude, against appetite, translating every risk into its business consequence, and remember the report is also the record that the board was informed.


Next: Chapter 2.6 · Security Culture & Organisational Change →