If a board report says the organisation is secure but offers little evidence, ask what the critical exposures are and how management knows the controls work. Useful cybersecurity questions lead to decisions, named actions and evidence to review next time.
The problem isn't that boards don't care about cyber risk. It's that most directors have a governance background, not a technical one, and the questions they know how to ask — "are we secure", "have we had a breach" — don't map onto how cyber risk actually behaves. Cyber risk is dynamic, the threat and the control environment both change constantly, and a point-in-time assurance is stale within months. Better questions treat cybersecurity as an ongoing risk management discipline the board oversees, not a technical project it signs off once.
Five cybersecurity questions for boards that produce evidence, not reassurance
1. How have we prioritised our risks, and who decided?
This question tests whether risk prioritisation happened deliberately, based on the organisation's own critical assets and dependencies, or whether it's driven entirely by whatever the last audit or vendor pitch flagged. A defensible answer names the assets or services that matter most to the organisation's objectives, states who assessed the risk to them, and explains the basis — likelihood and consequence reasoning, not a vendor's severity score alone. If management can't tell you which three or four things they're most worried about and why, the risk assessment hasn't actually happened yet; it's been outsourced to whichever tool produced the last report.
2. What controls are we relying on, and how do we know they work?
A control that's documented is not the same as a control that works. This is the single most useful distinction a board can hold management to. Ask not just what controls exist — multi-factor authentication, backups, endpoint detection — but how the organisation knows they're operating as intended. Has anyone tested the backup restore, not just confirmed the backup job ran? Has access review actually removed accounts that should have been removed? A control inventory answers the first question. Testing evidence answers the second, and only the second tells the board anything.
3. Who can get to what, and why do they still have that access?
Access management questions are some of the most concrete a board can ask, because the answer should be a number, not a description. How many people hold privileged administrative access. When was that list last reviewed. How quickly is access removed when someone leaves or changes roles. Boards should be uncomfortable with vague answers here — "access is managed appropriately" is not a fact, it's a hope. Persistent, unreviewed privileged access is one of the more common findings behind incidents that took far longer to contain than they should have.
4. If something happens tomorrow, what's the plan, and has it been tested?
Every organisation says it has an incident response plan. Far fewer have exercised it against a plausible scenario in the last year, and fewer still have tested it with the people who'd actually be in the room — including someone from outside IT, since a serious incident is a business continuity and communications problem as much as a technical one. Ask when the plan was last exercised, what the exercise found, and what changed as a result. A plan that's never been tested is a document, not a capability.
5. What would tell us early that something is going wrong?
This is the vigilance question, and it's the one boards skip most often because it's the least concrete. A mature answer describes what monitoring exists, what triggers an escalation to executive or board attention, and roughly how quickly the organisation expects to detect an intrusion once it starts — acknowledging honestly if that expectation is more hope than measured fact. An organisation with no meaningful detection capability will typically find out about an incident from a customer, a regulator, or a criminal's ransom note, at which point the "early" in early warning has already been lost.
Worked example: a board pack answer, before and after
Here's the difference these questions make, using a fictional mid-size logistics company, Harrow Freight, reporting to its board on cyber risk.
| Question | Weak answer | Answer that survives follow-up |
|---|---|---|
| Prioritisation | "We follow industry best practice for cyber risk." | "Our top three risks are the freight scheduling system, customer payment data, and driver location data, prioritised because scheduling failure stops revenue directly and the other two carry regulatory exposure." |
| Controls | "We have multi-factor authentication and backups in place." | "MFA covers all remote access as of last quarter; backup restore was last tested in March and completed within the target window." |
| Access | "Access is reviewed regularly." | "14 staff hold privileged access; the list was reviewed last month and reduced from 19; leaver access is now removed within 24 hours, down from an average of 9 days." |
Notice the weak answers are all true statements that convey nothing. The stronger answers are specific enough that a director could ask a sensible follow-up question, which is the actual test of whether board oversight is working.
Why the follow-up question matters more than the first one
None of these five questions are especially hard for management to prepare a good-sounding first answer to. The value is entirely in whether a director is equipped and willing to ask the follow-up. "How do we know that control works" only functions as an oversight tool if someone in the room asks it out loud when the first answer is vague, and keeps asking it until the answer is specific. Boards that delegate all technical follow-up to a single cyber-literate director risk making cyber oversight that person's job rather than the board's, which quietly recreates the single point of failure the questions were meant to expose in the organisation's own control environment.
It's also worth being honest about what a board can't do with these questions. Asking them well surfaces whether management understands and is managing the risk; it doesn't substitute for independent assurance. A board that never commissions an external review or penetration test, and relies solely on management's own account of its controls, is still trusting the assessor to mark their own work. The five questions tell you what to ask management. They don't remove the need to occasionally ask someone else the same questions about management.
Common mistakes boards make with cyber oversight
Asking for assurance instead of evidence. "Are we secure" invites reassurance. "How do we know this control works" invites evidence.
Treating cyber as a standing agenda item with no depth. Ten minutes once a quarter with a green traffic light is oversight theatre, not oversight.
No director with enough fluency to ask a follow-up question. The board doesn't need a technologist, but it needs at least one person willing to ask "how do you know" out loud.
Confusing compliance with risk management. Passing an audit and being resilient to a determined attacker are related but different things, and a board that only asks about the former misses the latter.
No link between what's reported and what the organisation actually depends on. Generic threat statistics tell a board little; risk framed against the organisation's own critical services tells them what matters.
Take these questions into your next board meeting
Five Cybersecurity Strategies for Boards and Executives sets out a five-step roadmap that mirrors these questions in practice: assessing and prioritising risk, implementing controls, establishing access management, developing incident response, and maintaining vigilance, with links through to the supporting templates for each step. For the segmentation half of the controls conversation, Security Enclaves: Explaining Segmentation to a Board in One Picture is a useful companion, and if the board wants to see the underlying risk register rather than a summary, start with How to Build Your First Risk Register. Once risks are prioritised, A Six-Column Risk Treatment Plan Anyone Will Actually Update covers how to track what's actually being done about them.