Who this is for: the CIO, CTO, security manager or owner-operator who has to put IT risk in front of a board, a management committee or the owners of the business, usually in a few minutes and a page or two. It assumes you have a scored risk register and need to turn it into something a non-specialist can act on.
What a board needs from you
A board is not there to understand your environment. It is there to oversee whether the organisation is taking risks it has chosen to take, within limits it has set, with someone accountable. That changes what a good IT risk report contains. It is not a summary of everything you did. It is a short account of three things:
- Where we stand against the level of risk we have said we will accept.
- What has changed since last time, and why.
- What we need the board to decide, approve or acknowledge.
If a page does not contribute to one of those, it belongs in an appendix or in the management pack, not the board paper.
The most common failure is a report that informs but asks nothing. If the board reads it and the correct response is “thank you”, the risk report has probably described activity rather than risk.
One page, built from the register
You can usually get what the board needs onto one page, with the detail available behind it. A workable structure:
| Section | Content | Length |
|---|---|---|
| Position | One or two sentences: overall exposure relative to appetite, and direction of travel | Two lines |
| Top risks | The five to eight highest-ranked residual risks, each with score and band, owner, trend since last report, treatment status and date | A compact table |
| Decisions required | Specific requests: approve spend, accept a risk, endorse a change in appetite, confirm an owner | Bullets, each with a recommendation |
| Changes since last report | Incidents, near misses, significant new risks, risks closed | Three to five lines |
| Assurance | What independent evidence exists, such as audit or attestation results, and open findings | Three lines |
| Looking ahead | Material events in the next period | Two lines |
Here is an illustration of the top-risks table, using fictitious data on the scale from the scoring guide:
| ID | Risk (plain language) | Residual | Trend | Owner | Treatment | Status |
|---|---|---|---|---|---|---|
| R-014 | Stolen staff passwords could let an attacker lock or copy finance data | 16 Critical | Same | Finance Director | Two-step sign-in on remote access, with restore test | In progress, due 15 Dec |
| R-009 | Admin accounts are not reviewed, so leavers may keep powerful access | 12 Critical | Down from 16 | Security lead | Quarterly review in place; first review done | Monitoring |
| R-021 | One payroll supplier holds all employee data and has no tested exit | 8 High | Same | Finance Director | Contract review and export test | Planned, due 28 Feb |
| R-033 | Backups not tested, so recovery time is unknown | 8 High | Up from 6 | IT manager | Quarterly restore test | Not started; decision needed |
Two choices in that table are deliberate. The risks are described in plain language that does not require the reader to know what MFA stands for. And “residual” is used, because the board cares what remains after controls, not what would happen if everything failed.
Ask for decisions, in the form of a decision
Convert each item that needs senior input into a request with a recommendation, an alternative and a consequence. For example:
Decision requested: Accept or fund treatment of R-033 (backups not restore-tested)
Recommendation: Approve 3 days of IT time per quarter for restore testing, starting this quarter.
Alternative: Accept the risk for six months without testing; review in the April report.
Consequence if not funded: Recovery time after a ransomware event remains unknown;
insurance renewal may ask for evidence of testing.
Risk owner: IT manager. Proposed review date: 2027-04-30.Note the last line before the owner. It states a concrete consequence without exaggeration. Boards grow wary of reports where every item is described as urgent. Reserve the word for items that are.
Show scores honestly
If you show a heat map, show the scale it uses and what a likelihood or impact of 3 means. A grid of coloured dots with no definitions invites the board to read more precision into the colours than the method supports. The scoring guide covers the limitations of multiplying ordinal scores; the practical consequence for reporting is to:
- State the scale and the horizon once, in an appendix or footnote.
- Show likelihood and impact as well as the band, at least for the top few.
- Avoid presenting a total or an average of scores, which has no meaning for ordinal values.
- When you can, express your most important risks in money ranges alongside the scores, with the assumptions. A statement such as “our estimate for a multi-day outage of the ordering system is a cost of between X and Y, and we see this as more likely than not to occur within five years, with low confidence” is more useful than a red square, provided the uncertainty is shown.
Metrics: leading, lagging and the ones to avoid
Metrics support the risk statements; they are not the report. Choose a handful that relate to the top risks and report the same ones consistently so trends mean something.
Examples that tie to decisions:
- Access review completion and number of privileged accounts removed, tied to the access review cycle.
- Restore test results: last successful full restore of each critical system and the time it took, compared with the recovery time the business has said it needs.
- Treatment overdue: count and age of overdue risk treatments.
- Supplier assurance currency: number of Tier 1 suppliers with an in-date assurance report.
- Incidents and near misses, with brief description of what the near misses taught.
Avoid raw counts that do not tell a story, such as the number of blocked emails or scanned vulnerabilities. They are large, they go up, and nobody can say whether that is good. If you must show a number like that, show it as a rate, against a target, with a sentence of explanation.
Tone and wording
Write for an intelligent reader who is not in IT. Replace “lateral movement” with “an attacker spreading from one machine to others”. Spell out acronyms once. Say “we do not yet know” when that is true: boards respond better to a flagged uncertainty than to a confident figure that later proves wrong.
Do not use the report to defend the department. Where something has not gone well, say what happened, what it taught and what has changed. A report that is uniformly positive becomes less trusted over time, and the first bad news then lands harder.
Cadence and the relationship to the register
Board reports are usually quarterly. The register is reviewed more often. Connect them explicitly: every item in the report carries a register ID, so a director who wants detail can ask for R-033 and get a one-page entry rather than a fresh explanation. Use the status and date fields from the register, so the report is a view of the register and not a separate document that can drift from it.
Between reports, define what triggers an out-of-cycle notification: a critical-band risk newly identified, an incident that crosses a defined severity, a regulatory notification, or a treatment that has failed. Agree these triggers and who is told, in advance, rather than negotiating them in the middle of an incident.
Appetite and tolerance
The board’s most useful contribution is a statement of how much risk it will accept. Without it, “the risk is high” has no benchmark. Propose a short appetite statement and ask for it to be adopted or amended, for example: “We will not accept critical-band residual risks for longer than one quarter without a funded plan. We will accept medium-band residual risks where the cost of treatment exceeds the estimated exposure, with an annual review.” Wording like that gives you a rule for the top-risks table: any critical entry that has persisted past its quarter is, by definition, a decision required.
Common mistakes
- The heat map as the whole report. A picture without scale, owners or decisions.
- Reporting inherent risk only, which makes controls invisible and every risk look alarming.
- No trend. A single point in time hides whether things are improving.
- Too many risks. More than about eight in the main table dilutes attention. Move the rest to an appendix.
- Jargon. If a director has to ask what a term means, the report failed.
- Assurance claims that are not supported. Saying “we are compliant” when what you have is a self-assessment. Say what the evidence is.
- No named owner. Each risk needs a person, not a department.
- Dates that move silently. Show the original and revised date.
What to do next
Take your top five residual risks from the register and draft the one-page table above, with plain-language descriptions and a decision for each that needs one. Check each number against its evidence: for example, that restore test results come from a real test, as described in audit preparation. Where a risk needs a treatment decision first, work through risk treatment so the request you bring is specific. You can use the risk matrix tool to produce a ranked summary to start from, remembering that it is a working estimate and not an audit.