← All insights ← →

Cyber Reporting to the Board on Its Own Is Not Yet Governance

Published: 15 July 2026

Cyber Reporting to the Board on Its Own Is Not Yet Governance

“No significant incidents.” A board reads that sentence four times a year, if cybersecurity even makes it onto the agenda, and it is reassuring. Except the sentence says nothing about what actually happened. It only says what was noticed, and that is the decisive difference.

The common answer to cyber risk at board level is structured reporting: quarterly, in business language, with trends, measures and third-party risk, tied to risk tolerance. That is correct, and it is better than what many boards receive today. It still is not enough. Reports like this have two built-in weaknesses, and both have grown larger over the past year.

Last month I wrote that AI mainly shifts the probability that a cyberattack happens, more than the damage per incident. That was correct, but only half the truth. AI also shifts the timeline. That is exactly where the comfortable idea that good reporting fulfils the oversight duty falls apart.

A Report Only Tells You What Was Noticed

In the cases of AI-assisted attacks documented so far, the AI’s role was mostly not uncovered by the victim’s own defences. It came to light through the attackers’ operational mistakes or through monitoring by the AI provider. That is how Check Point Research describes the incidents it examined.

What gave away that AI was involved was usually the attackers’ mistakes or the AI provider’s monitoring. Not the victim’s defences.

That finding is worth reading twice. The affected organisations noticed nothing: not the attack, not its scale, not the actor behind it.

Where detection fails, the report shows no significant incidents, and the board takes reassurance from that. But at that moment, the board is not measuring risk. It is measuring its own blind spot. The report is not wrong as such; it is only as good as the data behind it.

A report is therefore an inference, and anyone who cannot judge the inference cannot judge the report either. A board does not read journal entries, but it does read a balance sheet, and it recognises when a line item cannot be right. On technology, many boards lack exactly that level of literacy. It is not about configuring a firewall. It is about being able to read an architecture and recognise when an answer does not hold up. Anyone who cannot do that has to rely almost blindly on their deputies. Would a board simply do that in finance or in law?

A Report Comes From the Past

The second weakness is more fundamental, and quality alone cannot fix it. A report is a quarterly event. An attack has long since become an hourly one.

Switzerland’s Federal Intelligence Service (NDB) states that state-linked cyber actors from various countries are exploiting technological progress, including AI, to make their attacks more effective, and that the number of detected vulnerabilities will likely keep rising sharply. The World Economic Forum’s Global Cybersecurity Outlook 2026 names the advancement of adversarial capability through generative AI as one of the biggest concerns, from phishing to malware development to deepfakes.

Anthropic’s own example shows just how much cheaper vulnerability discovery has become. Using a Mythos-class model, the company and roughly fifty partners found more than ten thousand high- and critical-severity vulnerabilities within a month, across some of the world’s most important software. Cloudflare reports a tenfold increase in its find rate. Anthropic’s own conclusion is the more interesting part: software security progress used to be limited by how fast vulnerabilities could be found. Today it is limited by how fast they can be verified, disclosed and fixed.

The numbers behind that are sobering. Of 6,202 high- and critical-severity vulnerabilities found in open-source projects, 530 had been reported to maintainers and 75 fixed at the time of reporting. A patch takes two weeks on average. Several maintainers, volunteers with no budget behind them, explicitly asked Anthropic to slow down its disclosures, because they lack the time to build fixes. Finding costs almost nothing any more; fixing still costs enormous resources.

Today it is still the large language model providers building platforms like this. Anthropic itself expects that within six to twelve months, several other AI companies will have models of this class, and that they could release them without comparable safeguards. Tomorrow, then, it could be smaller providers or state actors. At that point, defence becomes considerably harder.

On the attack side, everything points in the same direction. Check Point Research describes malware with roughly 88,000 lines of working code, written by a single person in under a week, and an incident where an autonomous agent kept working independently after the initial breach and exfiltrated a database in under an hour.

Different senders, different motives, same direction. The most striking shift is not the damage per incident. It is the speed.

How fast that speed really is showed up in a detail I had to correct while writing this piece. When I wrote about cybersecurity in June, Mythos-class models were reserved for a small circle of defenders. Since 9 June, one such model has been generally available, protected by filters that redirect cyber-related requests to a weaker model. The unfiltered variant remains reserved for selected partners. A core assumption shifted between two ordinary board meetings.

An attacker working in hours meets a defence that works in days and weeks, and a board that works in months and quarters. The best quarterly report in the world changes nothing about that equation. It describes an incident that is already over before the board even hears about it.

Two Different Clocks

It would be too simple to conclude that everything is speeding up. The NDB paints a different picture on the state side. State and state-sponsored cyber actors have far greater resources than financially motivated groups, and they can afford to take their time. From initial reconnaissance to data exfiltration or sabotage, the NDB says months can pass, sometimes years.

A board is therefore dealing with two clocks at once. One ticks in hours: criminal, economically motivated, opportunistic, increasingly automated. The other ticks in years: state-run, patient, targeted. A governance model built for only one of the two will reliably miss the other.

Switzerland is a target here, not a bystander. The NDB states plainly on the ransomware picture: Switzerland sees one to two such attacks on critical infrastructure a month. Most hit companies, not authorities. Russian-linked groups are responsible for the large majority of these attacks. Anyone who wants to see what that looks like in practice can find a constant stream of Swiss clinics, industrial firms, logistics providers and service companies on publicly accessible leak sites, complete with name, date and data volume. That is not a threat picture. That is a list.

My Question That Went Unanswered

In an earlier project, I asked a simple question: how do we behave if we’re informed tomorrow that a ransomware attack has encrypted our systems? Do we have the processes in place, is it clear who decides, and what pre-committed decision have we already made?

The first half of the answer came quickly and was what I expected. The technical processes were in place. Thanks to properly tested backups, the business could resume quickly, and replacement hardware was ready. At that point, the meeting could have ended satisfied, and any report would have accurately captured that.

Then came my follow-up question: and what happens if our customer data also ends up on the dark web? That got no answer. Opinions diverged widely.

In a discussion, that is allowed, maybe even necessary. But you have to be aware of when that discussion actually happens in a real crisis: under time pressure, with incomplete information, under the scrutiny of customers, media and regulators. It is doubtful that a good decision gets made under those conditions. I deliberately say good, not right, because in a case like this there is no right answer.

That is precisely the board’s job, and it appears in no report. What is needed is not more time on the calendar. What is needed is moving decisions earlier on the timeline. For the board, that means engaging with a realistic worst-case scenario and preparing for it. Concretely:

  • A pre-committed decision instead of a decision under time pressure: Whatever has to be decided in a real crisis has to be decided beforehand, at least as a pre-committed decision based on today’s available information. Do we pay or not in a ransomware attack involving customer data loss, and who decides that. Who can take systems or sites offline without asking first. At what threshold does the board convene outside its regular calendar, do we need a crisis team, and within what timeframe must the board be able to act. Who triggers the notification to the Federal Data Protection and Information Commissioner (FDPIC), and who decides on internal and external communication. A board that first has to clarify its own room for manoeuvre in a real crisis is part of the delay, not part of the solution.
  • Delegation with limits instead of delegation on trust: The duty of care under Art. 754 OR can be organisationally distributed, but not handed away, and the oversight duty under Art. 716a para. 1 no. 5 OR cannot be delegated. Neither speaks against fast operational leadership, quite the opposite. But it requires that operational leadership’s room for action be defined, documented and resolved before it is ever needed.
  • Practised, not just written down: An emergency plan never tested under time pressure is a statement of intent. The same goes for the board’s own role in it. Restoring from backup can be tested, and many do test it. Almost nobody tests the question of how to handle published customer data. That is the harder of the two, because it usually involves data protection, reputation and trust. In a worst-case scenario, a case like that can ruin the company.

Questioning Architecture and Data Management

When large volumes of data can leave unnoticed, three questions arise:

  • Why did such a massive data transfer go unnoticed?
  • Why was that data so exposed in the first place, and does it need to be?
  • Does the company still command the complexity of its own architecture?

I have written elsewhere that environments that have grown organically over time often carry their biggest risk in their own complexity. Over years and decades, systems, databases and services get integrated, and at some point nobody asks any more whether the environment could be simplified and stripped down. The same applies, incidentally, in M&A processes, where the systems of two or more companies suddenly get integrated. The focus there often sits on data and processes, and less on cybersecurity.

Here too, the board has a role, and it comes down to a question that appears in no report: do we still actually have our systems under control?

The Bar Does Not Come From Regulation

Various regulatory frameworks describe, with increasing precision, what a governing body must approve, oversee and be accountable for. None of them, however, say how fast an open vulnerability actually has to be fixed.

Reporting remains necessary. It is simply not the only place where cyber governance happens. A board that receives a good report but, for lack of technology literacy, cannot question it, and that has made no pre-committed decision for the conceivable scenarios, is informed but not prepared. Preparation does not make a crisis easy. But it does decide whether a real decision gets made when it matters, or whether the board can only react.

Further Sources