The Board's Cyber Question Is Usually the Wrong One

"Are we secure?" is not a governance question. It is a request for reassurance. It invites a yes, produces no decision, and leaves the board no better positioned when something goes wrong.

Most boards approach cyber risk by asking their CISO or IT leadership some version of the same question: are we secure? The question feels responsible. It signals engagement. In practice, it achieves very little.

No one can answer it honestly. Security is not a condition that an organisation either has or lacks. It is a posture: a continuously negotiated set of decisions about what risk the organisation is prepared to accept, at what cost, in exchange for what operational benefit. Asking "are we secure?" is like asking "are we healthy?" It depends entirely on what you mean, what you are comparing against, and what you are willing to do about it.

The CISO who answers "yes" is offering reassurance, not information. The board that accepts that answer has not governed. It has delegated the discomfort.

When scrutiny arrives, whether from a regulator, an insurer, a counterparty, or a court, "we asked and were told yes" is not a defensible position. It is evidence that the board did not engage with the substance of the risk.

Security is a continuum of trade-offs

Every security posture reflects choices. Most of those choices are made implicitly, at an operational level, by people who are not thinking of them as governance decisions at all. That does not make them any less consequential.

Tighter controls cost money and slow operations. They create friction for users, add steps to processes, and constrain the speed at which the business can move. Looser controls reduce that friction but increase exposure. Between those poles, the organisation is making constant calibrations, whether it acknowledges them or not.

In practice, those calibrations often look ordinary:

• allowing personal devices on corporate systems in exchange for convenience
• deferring a security improvement to protect a delivery timeline
• onboarding a third-party SaaS platform without full vendor review
• keeping a legacy platform running beyond support because replacement is costly or disruptive

None of these decisions is inherently wrong. Some are perfectly sensible in context. The point is that each one represents a trade-off between usability, cost, resilience, and exposure. Each one belongs on someone's ledger.

The board's role is not to make every trade-off. It cannot and should not. Its role is to ensure that material trade-offs are made explicitly, by the right people, with appropriate authority, and that the decisions are recorded in a way that remains defensible later.

When that governance structure does not exist, the trade-offs still happen. They simply happen informally, at whatever level they surface, by whoever is closest to the problem at the time. The board then inherits a cyber posture it never consciously chose.

What the board should actually be asking

Better governance starts with better questions. The following are more useful than "are we secure?":

• What material trade-offs have been accepted in the last period, and who approved them?
• Which risks are outside our stated tolerance, and what is the plan for each?
• What would a regulator, insurer, or counterparty find if they examined our decision record today?
• Are escalation routes functioning? Are issues reaching the board at the right level and at the right time?
• What has changed in the threat or operating environment that affects decisions we have already taken?

These questions do something the usual cyber question does not. They presume that there is a decision to be made or reviewed, not a verdict to be delivered. They require the CISO or IT leadership to produce an account of choices, not a status signal.

They also make it much harder to give an answer that closes down scrutiny rather than enabling it.

What good board reporting looks like

The problem is not only what boards ask. It is also what they are given.

Much cyber reporting to boards is structured as a control inventory: a list of frameworks, workstreams, RAG statuses, maturity scores, and open actions. That format is not useless, but it rarely answers the question the board should be asking: what decisions are we being asked to make, note, or escalate?

Good board-level reporting is short, opinionated, and specific. It covers what is material, what decision is required, and what the consequence of inaction is. It translates technical reality into legal, commercial, and governance terms without pretending the nuance has disappeared.

The practical test is simple: could a non-technical board member read this paper and understand what they are being asked to approve, note, or escalate? If the answer is no, the reporting has not done its job, however detailed it may be.

The usual warning signs are familiar:

• length without clarity
• activity reporting instead of risk reporting
• RAG dashboards with no narrative about what the colours mean commercially
• framework scores presented as if a high score resolves material exposure

These formats are not malicious. They are just the natural output of a reporting structure built to answer the wrong question.

Briefing is not governance

When boards do not ask the right questions, and when reporting is structured to avoid producing them, the risk does not disappear. It accumulates informally.

Security teams absorb decisions that should be escalated. Trade-offs that should be recorded are not. Risks that exceed the organisation's stated tolerance are managed operationally rather than governed. The gap between what the board believes is happening and what is actually happening widens slowly until something forces it into the open.

By that point, the problem is rarely confined to one workstream. Incidents, transactions, insurer scrutiny, and regulatory enquiries have a way of surfacing accumulated governance failures all at once. The board cannot show it governed the issue. It can only show it was briefed.

That distinction matters. Briefing is not governance. Receiving a report is not a decision. Asking "are we secure?" and being told yes is not oversight.

The better question

Boards do not need to read penetration test reports or understand architecture in detail to govern cyber risk properly. They need a model that surfaces material decisions, records trade-offs, and ensures that the right people are accountable for the choices being made on the organisation's behalf.

The real shift is from asking for a verdict to asking for a decision record.

The question is not "are we secure?" It is: what decisions are being made on our behalf, what trade-offs do they reflect, and are they ones we would be comfortable defending later?

That question is harder. It is also the one that determines whether the board has actually discharged its responsibility when scrutiny arrives.