A CISO does not take responsibility away from company leadership

Interview ahead of the ECSO CISO Meetup in Berlin

Boards have long known that cyber risk matters. Matthias Muhlert, Group CISO of the Oetker Group and Chair of the ECSO CISO Community, asks a different question ahead of the ECSO CISO Meetup in Berlin: Who remains responsible once the CISO is appointed?

On 1 and 2 October, CISOs from across Europe meet at the Estrel Berlin for the ECSO CISO Meetup 2026. It is the fifth edition after Brussels, Florence, Vienna and Valencia. The meetings of the ECSO CISO Community run under the Chatham House Rule. According to its own figures, the community of the European Cyber Security Organisation (ECSO) counts over 700 security leaders from 35 countries.

SecurityToday is media partner of the Meetup. Ahead of the event, the Chair of the ECSO CISO Community answered ten questions in writing. Matthias Muhlert speaks in this interview from his personal professional perspective and not about internal processes of his employer.

Responsibility stays with the board

Most boards I meet already understand that cyber risk matters. The harder question is who remains responsible after a CISO is appointed. Business decision-making does not suddenly move to the CISO’s desk. Choosing which suppliers to depend on, deciding how much downtime a production line can tolerate or acquiring a company also means making decisions about cyber risk. Those choices may not look like security decisions at first.

The CISO advises, helps reduce risk and has a responsibility to escalate. The CISO remains accountable for that advice and for the work within the role’s remit. Responsibility for business decisions stays with the people authorised to make them.

I would connect this more closely to strategy. A list of ten critical risks gives a board little direction. Explaining that two of them threaten this year’s growth plan gives it a concrete reason to weigh the options and allocate resources.

A metric a board cannot act on is decoration.

I can’t go into the Oetker Group’s internal reporting. Speaking generally, I would present evidence in three parts, covering what has been demonstrated and under which conditions, which assumptions remain untested, and what will be tested next, with a date and an owner.

A result without its test conditions tells only half the story. “A compromised account cannot reach production administration” is a claim. “In test X on date Y, the account reached layer Z and no further” is a concrete finding with clearly visible limits.

Each measure should help frame a decision or identify a question worth asking. I would leave out activity counts that do neither. On their own, millions of blocked attacks tell us more about the weather than the roof. A metric a board cannot act on is decoration.

The Oetker Group’s budget is not something I can discuss here. In that kind of debate, I would generally explain the consequences of a reduction and how certain I am about the assessment. Fear alone is a weak defence of a total. An honest answer also identifies work that no longer justifies its cost. That might be reporting nobody uses or duplicated activity. With tools, the expected security benefit has to justify the operating and support burden.

For a made-up example, take a business selling perishable goods. An interruption can cause losses that later production cannot recover. That business consequence belongs in the discussion alongside the cost of protection. It is a more useful starting point than automatically defending every existing security expense.

What NIS2 and the CRA change in a real incident

I can’t comment on the effects within the Oetker Group. The German law took effect on St Nicholas Day, when children in Germany traditionally find presents in their boots. Not every organisation welcomed this particular gift.

The rules themselves are, of course, open for discussion. What interests me is what they change during an incident. NIS2 uses reporting in stages. The early warning quickly alerts the relevant authorities and can help an organisation seek assistance. An early warning is not yet a final root-cause analysis. Later reports add detail. It remains important what was uncertain at first and what was corrected later.

Then comes the question of what happened to that information. I’d want to trace who used the information and which decision changed as a result. Test results would then help establish whether response or recovery actually worked better.

The effort of preparing the reports belongs in that assessment too. It needs to be weighed against the benefit, rather than treated as proof that reporting was pointless. Documentation can help protect an organisation. A completed form alone still cannot tell me whether anything works better when it matters.

I’d like to show them what implementation actually looks like. That includes what the team knew at each reporting stage and which statements it had to correct later. It also matters where the information was used and how much work went into preparing it. The same account can reveal operational benefits and administrative effort. The circumstances matter too. A small organisation and a multinational may face very different constraints while meeting the same obligation.

Results from exercises and experience from incidents can show which decisions changed and which capabilities were actually demonstrated. They cannot, by themselves, establish that a legal requirement caused an improvement. I would talk to policymakers about observed effects, costs and the questions still open. Sweeping verdicts that regulation either solves security or merely creates paperwork won’t help us much. Berlin gives practitioners and public institutions an opportunity to discuss those experiences together and understand what the results can tell us.

At three in the morning, the certificate will not answer the phone.

I don’t speak publicly about the Oetker Group’s specific supplier requirements. For the wider professional discussion, my measure would be whether cooperation holds up when something fails. I’d first establish what the supplier can access in a customer’s environment. That includes how the customer could restrict that access during an incident at the supplier. How quickly can affected services be restored, and when was that last tested?

I’d also want to know how soon the customer will be informed, through which channel and who will answer. Who else expects access to the same recovery capacity belongs in that conversation too.

A certificate tells you something about the area it covers. It won’t settle every question about this particular relationship. Cooperation needs to be exercised by agreement. Surprise calls are the wrong way to do that. At three in the morning, the certificate will not answer the phone.

What the community should achieve in Berlin

After someone says “this worked for us”, we can ask the next question. Why do we think it worked? That also means looking at what else changed along the way. Would the same approach hold up in a different organisation and under different pressure?

Confidentiality protects the person telling the story. Whether the explanation is right remains an open question. That setting lets us be generous with each other while still asking demanding questions.

In Berlin, I want to hear unfinished stories and understand why something that looked sensible failed anyway. What we still don’t know belongs in the conversation too. We have to be able to disagree. Otherwise we become a highly qualified group of yes-men who only agree with each other.

Before calling something a recovery capability, I want to know whether it still works when the hero is on holiday.

I’m interested in whether a successful response can be repeated next time. An undocumented workaround or one person’s judgement may have made the difference during an incident. That deserves recognition. Expertise and improvisation still matter. The organisation also needs to understand what it can reliably do next time without depending on that particular person’s memory and availability.

In a controlled exercise, make the usual decision-maker unavailable for one phase. The exercise can reveal whether the person covering for them is able to act and has the authority and information they need. Where do they hesitate? That helps reveal what the organisation can really depend on. Before calling something a recovery capability, I want to know whether it still works when the hero is on holiday.

For me, the overrated risk is the cinematic scenario of an AI deciding to turn on its owners. The underrated one is delegated authority and the premises it runs on. An AI system does not need to be malicious to cause damage. It can follow a permitted workflow while starting from something false. A procurement assistant might, for example, accept a fabricated claim that new supplier bank details have already been verified.

That is what I call premise injection, manipulating the propositions an agent treats as grounds for reasoning and action. Every delegation that no person can account for also adds to what I call audit debt. I mean the growing inability to reconstruct the actions and authority behind automated decisions.

The useful board questions are dull. What can this system change? What evidence supports the facts it relies on? Can a wrong action be stopped and reversed?

I’d like each participant to leave with an assumption they are willing to have challenged and a test they intend to run safely in their own organisation. They should also have a peer to tell what the test revealed. That should be someone who challenges an assumption in October and asks in November what happened.

Perhaps this second conversation a month later is especially important. It gives a good intention a real follow-up, and both people can discuss a result that failed to confirm the original lesson.

Berlin is where those conversations can begin. Their value becomes clearer when we see what people actually do afterwards.

Frequently Asked Questions

Every question is locked. A tap unlocks the answer.

When and where does the ECSO CISO Meetup 2026 take place?

On 1 and 2 October 2026 at the Estrel Berlin. It is the fifth edition after Brussels, Florence, Vienna and Valencia. It is aimed primarily at CISOs, Deputy CISOs and their teams. Participation is subject to approval of the registration. It is free of charge, and participants cover travel and accommodation themselves.

What does Matthias Muhlert mean by premise injection?

The manipulation of the propositions an AI agent treats as grounds for reasoning and action. A procurement assistant might, for example, accept a fabricated claim that new supplier bank details have already been verified.

Which metrics belong in a board briefing according to Muhlert?

Only those that help frame a decision or identify a question worth asking. He would leave out pure activity figures. To him, millions of blocked attacks tell us more about the weather than the roof.

Editor’s Picks

Editor’s PickFive Metrics the Supervisory Board Actually UnderstandsEditor’s PickThe concentration risk no supplier audit sees

More from the MBF Media Network

Digital ChiefsNIS2 liability for management boards applies despite registrationMyBusinessFutureManufacturers Report CRA Incidents to ENISA Ahead of the CSIRT

Image source: AI-generated (September 2026). Portrait in this article: Matthias Muhlert / ECSO (press photo).