How to explain cyber security risk to a non-technical board

The board is not your audience for the technology#

The most common mistake I see when technical people present to a board is treating the session as a chance to prove the work is hard. Slides of firewall logs, vulnerability counts, tool names and acronyms. The board nods, nobody asks a question because nobody wants to look out of their depth, and the meeting moves on to the next item.

That is a failed presentation, even if everything in it was accurate.

A board has a different job from the IT team. It is there to set direction, decide how much risk the organisation will accept, make sure the right resources and people are in place, and hold management to account. In the UK, directors also have legal duties, including the duty to exercise reasonable care, skill and diligence under the Companies Act 2006, and regulators such as the ICO can fine for serious data protection failures at up to £17.5 million or 4% of global turnover, whichever is higher. Cyber risk is therefore a governance matter and not an IT matter.

So the question to ask before you build any slide is simple: what does this board need to decide, and what do they need to know to decide it well?

What the board actually needs#

Strip the topic back and a board needs answers to five questions:

1. What could go wrong that would really hurt us? In business terms, not technical ones.
2. How likely is it, and how bad would it be? Roughly, with honest uncertainty.
3. What are we doing about it, and is it working?
4. What are you asking us to decide or fund?
5. Are we ready if it happens anyway?

The UK government's Cyber Governance Code of Practice, published in 2025, frames it in a similar way. It sets out five principles for boards: risk management, cyber strategy, people, incident planning, response and recovery, and assurance and oversight. The NCSC Cyber Security Toolkit for Boards is the companion resource and is written for exactly this audience. If you are preparing for a board session, read both, because the directors may already have seen them, and borrowing their language makes you easier to follow.

Translate technical risk into business impact#

A vulnerability is not a risk. A risk is a vulnerability combined with a threat and a consequence that someone cares about. Boards only care about the consequence.

The translation is mechanical once you do it a few times. Take the technical finding, then ask "so what happens to the business if this is exploited?" until you reach something a finance director would recognise.

Technical version: "Domain admin credentials are shared across 40 servers and there is no MFA on remote access."

Board version: "If one laptop is compromised, an attacker could plausibly take control of our whole network in an afternoon. In a ransomware attack, that means we could be unable to take orders, invoice customers or pay staff for somewhere between one and three weeks, and our insurer may question whether we met the conditions of the policy."

Technical version: "Backups are not immutable and the restore has never been tested."

Board version: "We believe we can recover from a ransomware attack, but we have not proved it. If the backups are also encrypted, the realistic choice becomes paying a criminal or rebuilding from scratch, and we do not know how long a rebuild would take."

Notice what the board versions have in common. They name a consequence in operational terms (cannot take orders, cannot pay staff), they give a rough duration or scale, and they are honest about what is unknown.

Recent real incidents make good context because directors have read about them in the press. Marks and Spencer said its 2025 cyber attack would hit operating profit by around £300 million, and the Jaguar Land Rover attack later that year halted production for weeks and led to a government loan guarantee. You do not need to claim your organisation is the same. The point is that the board can see the shape of the impact when it goes badly: operations stopped, revenue lost, customers and suppliers affected, and months of recovery.

Scenarios beat vulnerability lists#

Boards are good at thinking about scenarios because that is how they think about other risks, such as a supplier failing, a key person leaving or a major customer walking away.

Pick three to five plausible scenarios and describe each in a short paragraph:

• Ransomware on the main network. What stops, for how long, and what does it cost per day.
• Business email compromise. Someone impersonates a supplier or the finance director and a payment goes to the wrong account.
• Data breach involving customer or employee data. Notification obligations, regulator contact, legal costs and reputational damage.
• Supplier or SaaS outage or compromise. A critical third party goes down or is breached, and you depend on it for something important.
• Insider mistake or misuse. A well-meaning employee shares the wrong file, or a leaver keeps access.

For each, give the board the same four things: how it would happen in plain English, what the business impact would be, what controls reduce the likelihood or impact today, and what the remaining gap is. This turns a long list of technical findings into five stories the board can discuss and rank. It also makes the link to your controls clear. The identity risk and shared local admin password problems I have written about before are examples of how a small technical weakness turns into a business-wide scenario.

Be honest about uncertainty, and avoid false precision#

There are two traps here, and they pull in opposite directions.

The first is the heatmap: a five by five grid of red, amber and green dots. It looks authoritative, but it hides the thing the board needs most, which is how the ratings were produced. "Amber" can mean anything. Two different people will rate the same risk differently, and the colours do not add up to a total exposure.

The second is made-up precision, such as "a 17.3% chance of a breach costing £2.4 million". Nobody has data that good, and a board that spots it will stop trusting the rest of your numbers.

A better middle ground is to use ranges and plain language:

• "We think a serious ransomware incident in the next 12 months is realistic. Most organisations our size are targeted, and a minority of those are seriously disrupted."
• "If it happened, we would expect between one and three weeks of reduced operations. Our best estimate of the direct cost is £500,000 to £2 million, mostly lost revenue and recovery effort, before any regulatory or legal costs."
• "I am confident about the controls we have in place. I am less confident about our recovery time, because we have not tested it end to end."

If you want something more rigorous, look at the FAIR approach to quantifying cyber risk. You do not need the full method to borrow the key idea, which is to estimate frequency and impact as ranges and then say how confident you are.

Measures that show whether risk is going up or down#

Most security dashboards are full of activity measures: emails blocked, alerts triaged, vulnerabilities scanned. Those show that the tools are busy, not that the organisation is safer. A board wants to know whether the risk is moving in the right direction.

A short list of outcome measures works better. Pick five or six, show them as trends over time, and explain each in one line:

• MFA coverage. The percentage of users and admin accounts protected by multi-factor authentication, with phishing-resistant methods called out separately.
• Patch age for critical and high-risk updates. How many days the oldest unpatched critical update has been outstanding, compared with a target such as the 14 days that Cyber Essentials now requires.
• Tested recovery time. How long it took, in the last test, to restore your most important system from backup. This is the single most useful number for a ransomware conversation.
• Privileged access. The number of standing admin accounts, and how many have been reviewed in the last quarter.
• Phishing resilience. The percentage of staff who report suspicious emails, which is a better signal than the click rate on a simulated phish.
• Time to detect and contain. If you have monitoring or a managed detection service, how long between something suspicious happening and someone acting on it. The numbers in the grey zone post show why that matters outside business hours.

Always attach a target and a direction. "MFA coverage is 92%, our target is 100% for admins and 98% for users, and it was 85% last quarter" gives a board something to discuss. "MFA coverage is 92%" does not.

Use analogies carefully#

Analogies help a non-technical audience, but a bad one can mislead more than it explains.

Good ones for a board:

• Financial controls. Cyber controls are like segregation of duties and approval limits. They exist so that one mistake or one bad actor cannot do unlimited damage.
• Fire safety. You do not wait for a fire to test the alarms and evacuation plan. You rehearse. This is the best analogy for incident response and recovery testing.
• Insurance and the excess. Residual risk is what you decide to carry. The board is choosing how much, whether or not it makes the choice consciously.

Be wary of the "castle and moat" or "locks on the door" analogies. They suggest that security is a perimeter you build once, which is the opposite of how modern attacks work.

Structure the board paper so it gets a decision#

A long technical paper is easy to skim and easy to defer. A short paper with a clear ask is hard to ignore. A format that works well:

1. The headline (two sentences). Where we are, and the single most important thing for the board to know.
2. What changed since last time. New risks, incidents, improvements, regulatory changes.
3. Top risks as scenarios. Three to five, each with impact, current controls and remaining gap.
4. Five or six outcome measures. With targets and trends.
5. Readiness. When the incident plan was last exercised and what we learned.
6. The ask. One of: accept this risk, approve this spend, choose between options A and B, or note progress with no action needed.

If you can fit it on two pages, with detail in an appendix for anyone who wants it, do that. A board member reads the first page properly and skims the rest.

Make the ask a decision, with options#

"We need £80,000 for a new security tool" invites a yes or no based on gut feel. Compare:

"The most likely route into our network is a stolen password, because MFA is not enforced for around 10% of accounts. We have three options. Option A: do nothing and accept the risk. Option B: enforce MFA for everyone by the end of next quarter at a cost of £6,000 and some user disruption. Option C: B plus phishing-resistant keys for admins, at £15,000. I recommend C."

That gives the board a real choice, shows the cost against the exposure, and records an informed decision. If they choose to accept the risk, that is also a legitimate outcome, as long as it is recorded and they understand what they are accepting.

Run an exercise instead of another presentation#

If you only do one thing differently, run a tabletop exercise with the board or executive team. Give them a realistic scenario, such as ransomware on a Friday evening, and walk through the decisions: who is called, who speaks to customers, whether to pay, when to tell the regulator, how to operate without systems.

An hour of that teaches more than any slide deck. It exposes gaps in authority and communication that no technical audit will find, and it makes directors realise they will be the ones making the hard decisions at 2am. The NCSC's Exercise in a Box is a free tool that provides ready-made scenarios.

Common mistakes#

• Leading with fear. One dramatic breach story is useful context. A whole presentation of scare stories makes the board either numb or defensive.
• Jargon with no translation. If you must use a term, define it once in plain English and then stick to it.
• Presenting only problems. Boards want to know what is going well too, otherwise they cannot tell whether the money already spent is working.
• Hiding bad news. A board that discovers an unflagged problem through an incident loses trust in the whole function. Early and plain beats late and polished.
• Asking for everything at once. Prioritise. If everything is urgent, nothing is.
• No follow-up. Report on the decisions the board made last time and what happened as a result. That closes the loop and shows their decisions matter.

A short checklist before you walk in#

• Can I explain each risk in one sentence without an acronym?
• Does every risk have a business consequence, a rough size, and a current mitigation?
• Are my numbers ranges with a stated confidence level, not invented precision?
• Have I shown trends and targets, not just a snapshot?
• Is there a clear ask, with options and a recommendation?
• Have I tested the recovery story, so that "we can recover" is something I have evidence for?

If the answer to all of those is yes, you will probably get better questions than you expected, and the questions will be about the business rather than the technology. That is exactly where a board conversation about cyber should be.

References#

Sources and further reading for the claims above.

• UK Government, Cyber Governance Code of Practice
• NCSC, Cyber Security Toolkit for Boards
• NCSC, Exercise in a Box
• Companies Act 2006, section 174: duty to exercise reasonable care, skill and diligence
• Data Protection Act 2018, section 157: maximum penalty amounts
• UK Government, Government backs Jaguar Land Rover with £1.5 billion loan guarantee
• FAIR Institute, What is FAIR