In board after board, we see the same scene play out. The security policies are on the agenda, someone walks the directors through them in under ten minutes, and then one of them says something along these lines: "I haven’t had time to read them, but I understand these documents were carefully prepared and are based on what the law requires. I propose we approve them." The policies are approved, and the meeting moves on.
Approval is often the only time security reaches the board.
We see this pattern in very different organizations, and fellow consultants describe it in almost exactly the same terms. No one in the room is being negligent. The board is told the work was done by people who know what they are doing, and it trusts them. That trust is reasonable. It is also the only thing the decision rests on.
What the board approves at that point is a statement of intent. A policy sets out what the organization plans to do. It says nothing yet about whether any of it works. The approval is not so much a judgement on the content as a vote of confidence in the people who prepared it.
The explanation is heard, everyone says they understand, and the meeting moves on to other business. Often that is the last time security appears on the agenda until something goes wrong.
The law asks for more than a signature.
Under Belgian NIS2 law, the management body of an organization in scope must approve its cybersecurity risk-management measures, oversee their implementation and be held accountable for them. Its members must also undergo training, so that they can identify risks and assess how the organization manages them.
Read that closely and the emphasis shifts. NIS2 does not make the board responsible for doing security. It makes the board responsible for knowing whether security works.
Approval is one half of that duty. Oversight is the other, and the law says very little about what it should look like. It does not prescribe a format, a frequency or specific reports. That is left to the organization, and in practice it often goes unaddressed.
Workplace safety gets attention because the board has figures to act on.
There is an understandable reason why cybersecurity struggles to hold the board’s attention. It is one of many risks directors are responsible for. In a production environment, a workplace accident with physical consequences will almost always weigh more heavily than a security policy, and that instinct is hard to argue with. As long as cyber incidents do not visibly spill over into the physical world, cyber tends to lose that comparison.
Physical impact is not the whole story, though. Look at what the board actually gets to see. Safety comes up at every meeting, backed by figures: incidents, near misses, trends and the follow-up actions taken. The board can compare one period with the last and decide where to intervene. For cybersecurity, that picture is usually missing.
There is a lesson in that comparison. An organization that struggles to say how much cyber risk it is prepared to accept can look at how it already expresses its tolerance for fire, flooding or workplace accidents. The risks are different, but the way you look at them can be the same.
A green report measures effort, not effect.
When cybersecurity does come back to the board after approval, it tends to be as a progress report: measures implemented, projects on track, everything green. In most of the reports we see, what gets tracked is the progress of the security measures, not whether risk is actually coming down.
There is nothing wrong with such a report. It tells the board that work is being done. It does not tell the board whether that work is making the organization any safer. A board that approves policies and then hears only about progress can do everything asked of it, in good faith, and still not know whether any of it works.
An indicator belongs on the dashboard only if it can change the decision.
What helps is a small dashboard at every board or management meeting: a handful of indicators that show what is really happening in cybersecurity and give the board something it can actually decide on.
The test for such an indicator is simple. Would a different status, or different data behind it, have changed the decision? If the board would have decided exactly the same either way, the indicator does not belong on the dashboard. That does not make the information worthless. It may well be useful, but it is better shared in another way.
It also means choosing only a few, and looking at the risk behind each one. An indicator is a window on that risk, not a target in itself. In the organizations where we introduce these indicators, we see what happens when that gets lost: once a board starts managing to the number, the effort goes into improving the figure while the risk behind it stays where it was. So the question for every indicator is not just whether it is green, but what it says about the underlying risk and whether that risk is coming down. A handful of indicators read that way, each capable of changing a decision, are worth more than a dashboard that looks complete.
Start with the report you already have.
Take the last cybersecurity report your board received and ask one question of every indicator in it: would a different status have changed our decision? Where the answer is yes, the indicator belongs on the dashboard. Where it is no, it belongs somewhere else. Approval is still necessary, and well-prepared policies deserve it. Oversight starts elsewhere, with the question of whether it works, and in many boardrooms that question has yet to find its place on the agenda.