What a board actually needs to hear about security
A slide of red and amber indicators tells a board that something is wrong and gives them no way to act on it. Three questions do more work than any dashboard.
Security reporting to a board or an owner tends to arrive in one of two useless forms. Either a technical summary nobody in the room can convert into a decision, or a traffic light chart that has been amber for four quarters.
Both fail for the same reason. A board’s job is to allocate money and accept risk. If a report does not help with either, it is information rather than governance.
The three questions worth answering
What would hurt us most, and how exposed are we to it?
Not a list of vulnerabilities. One or two specific scenarios in business terms, with the honest current position. “If our ERP were encrypted on a Friday in vintage, we would be operational again in roughly three days, and we would lose up to a day of transactions.” That is a sentence a director can respond to.
What are we doing about it, and by when?
A short sequence with dates and owners. Three items, not thirty. If the list is thirty, the reporter has not done the prioritisation, and the board will do it badly on their behalf.
What are we knowingly accepting?
This is the one that gets skipped and matters most. Every business runs risks it has chosen not to spend on, and that is legitimate. What is not legitimate is those risks being unspoken, so that after an incident the board learns they were carrying something nobody told them about.
Write them down. “We are not funding out-of-hours monitoring this year.” Once it is recorded as a decision, it is governance. Until then it is an assumption each side holds differently.
What to leave out
Vulnerability counts, patch percentages and blocked-email statistics. They feel like evidence and they are activity metrics: they go up and down for reasons unrelated to whether the business is safer, and nobody can act on them.
A board does not need to know that 14,000 emails were filtered. It needs to know whether a payment could be redirected without a phone call.
The framing that works
Money and time, not severity ratings.
“This costs $X and reduces our worst-case downtime from three days to one” is a capital decision, and boards are good at those. “This is a critical finding” is a request to be worried, and worry does not survive the next agenda item.
The same translation applies upward from technical work. Patching is not a virtue, it is the reason an internet-facing system does not become the entry point. Framed that way it competes for budget on equal terms with everything else.
On independence
There is an obvious conflict when the party reporting on your security posture is the party being paid to improve it. We are in that position with clients and it is worth naming rather than glossing.
The way we handle it is to keep advisory work priced separately from delivery, and to declare it plainly when a recommendation touches something we sell. It also means the prioritised list and the accepted-risk list belong to the client, in their words, so they can hand them to somebody else for a second opinion without translation.
If a provider only ever reports things that require buying more from them, that is worth noticing. A useful security report includes at least some items that cost nothing but a decision.
The short version
One page. Two scenarios in business language. Three actions with dates. A list of what you are choosing not to do.
If security reporting into your business does not produce that, it is not yet doing the job, whoever is producing it.