Zaheer Ikbal, Founder, CyHelm
I’ve written a lot of security reports for senior management over the years. The ones I’m least proud of were the longest.
You know the type. Forty slides. A red, amber and green heatmap on slide three. Patch percentages, phishing click rates, a chart of blocked attacks that goes up every quarter. Everyone nods. The meeting moves on. And nobody decided anything.
A board isn’t there to admire how busy the security team is. It’s there to set direction, accept or refuse risk, and check the money is doing what it was meant to do. If your pack doesn’t end in a decision, it was a status update with nicer fonts.
So if I were building a board pack today, I’d borrow the agenda from somewhere else: the Govern function in the NIST Cybersecurity Framework 2.0.
NIST published CSF 2.0 on 26 February 2024 and added Govern as a sixth function, alongside Identify, Protect, Detect, Respond and Recover. In its release, NIST frames cybersecurity as a major source of enterprise risk that senior leaders should weigh next to finance and reputation. That’s board language. Not SOC language.
Govern has six categories: organizational context, risk management strategy, roles and authorities, policy, oversight, and supply chain risk. You don’t need to adopt the whole framework to use that structure, and it isn’t a UAE regulatory requirement. It’s just a sensible order to ask questions in.
Take each one and turn it into a single question the board can actually answer.
1. What are we protecting, and for whom? (GV.OC)
Not the asset register. I mean the three or four services the business can’t lose for a week, the customers and regulators who’d notice, and the contracts that say what you promised.
GV.OC-03 asks that legal, regulatory and contractual requirements are “understood and managed.” Try asking the room which ones apply to you. If nobody can answer, you’ve found your first issue, and you haven’t even opened the heatmap yet.
2. How much risk are we willing to carry? (GV.RM)
This is the one most packs skip, and it’s the one that matters most.
GV.RM-02 asks for risk appetite and risk tolerance statements that are established, communicated and maintained. Without them, every decision becomes a debate about how people feel that day. With them, a manager can say “this is outside what the board accepted” and escalate it without any drama.
Keep it short and measurable. Something like: no internet-facing system stays exposed to a known exploited vulnerability for more than X days without sign-off. The board picks X. Not the security team.
3. Who owns it, and do they have what they need? (GV.RR)
GV.RR-01 puts accountability on organizational leadership. GV.RR-03 asks for resources that match the strategy.
If the owner of the ERP risk is “IT,” then nobody owns it. Put a name and a role against every top risk.
And if last year’s budget request got cut, show what didn’t get done because of it. That isn’t complaining. It’s the board’s own decision coming back to the board.
4. What rules did we set, and are they still right? (GV.PO)
Policy isn’t a folder on SharePoint. GV.PO-02 expects policy to be reviewed and updated when requirements, threats, technology or the mission change.
You don’t need a slide for this. One line will do: which policies changed this period, and why.
5. Is any of it working? (GV.OV)
This is where the metrics go. But only the ones that move a decision. Three is plenty:
- Time to close known exploited vulnerabilities on internet-facing systems, against the tolerance the board set.
- Share of top risks with a named owner and a dated treatment plan.
- Number of risk exceptions past their expiry date.
Each one needs a target the board agreed to. Then red actually means something.
6. Which suppliers can hurt us? (GV.SC)
A lot of your exposure now sits with other people. The managed service provider. The cloud tenant. The payroll provider. The AI tool someone in marketing signed up for last month.
Supply chain risk is a full category under Govern, and GV.SC-04 asks that suppliers are known and prioritized by criticality. So ask for the short list: which suppliers would stop a critical service if they failed, and when was each one last reviewed?
The slide that always gets skipped: exceptions
Every organization runs on a few workarounds. A legacy server that can’t be patched. A vendor fix that hasn’t shipped yet. A control switched off because the business needed a feature.
That’s normal. It’s fine, as long as each one is written down as what it really is: a temporary measure, not the fix. Each needs an owner, a reason, whatever covers the gap in the meantime, and an expiry date. When that date arrives, it’s either closed, or it goes back to whoever accepted it and gets renewed on the record.
An exception with no end date is just an accepted risk that nobody wants to admit they accepted.
If I could keep only one slide in the whole pack, it would be this one. Open exceptions, who accepted each, and when it ends.
One page, not forty
- Top: the decisions you need from the board today, with your recommendation.
- Middle: the six questions, one or two lines each, with a status the board can check.
- Bottom: open exceptions and their expiry dates.
- Appendix: everything else, for anyone who wants it.
If the board still wants the heatmap, fine. Put it in the appendix. Lead with the decisions.
After the meeting
Write down what was decided. Which risks were accepted, by whom, and until when. Which requests were approved, and which were refused.
That note is a record of the board’s decisions. It isn’t a new control or a procedure. Its job is simple. Six months from now, when someone asks why a system was left on a workaround, the answer is in the minutes, not in somebody’s memory.
Sources
NIST CSWP 29, The NIST Cybersecurity Framework (CSF) 2.0, 26 February 2024: https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf
NIST news release, “NIST Releases Version 2.0 of Landmark Cybersecurity Framework,” 26 February 2024: https://www.nist.gov/news-events/news/2024/02/nist-releases-version-20-landmark-cybersecurity-framework