{"id":24343,"date":"2026-09-30T08:41:50","date_gmt":"2026-09-30T08:41:50","guid":{"rendered":"https:\/\/www.securitytoday.de\/?p=24343"},"modified":"2026-09-30T08:41:54","modified_gmt":"2026-09-30T08:41:54","slug":"ciso-does-not-take-responsibility-from-leadership","status":"publish","type":"post","link":"https:\/\/www.securitytoday.de\/en\/2026\/09\/30\/ciso-does-not-take-responsibility-from-leadership\/","title":{"rendered":"A CISO does not take responsibility away from company leadership"},"content":{"rendered":"
Interview ahead of the ECSO CISO Meetup in Berlin<\/p>\n
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?<\/strong><\/p>\n
\n
Key takeaways<\/p>\n
\n
Responsibility stays at the top.<\/strong> Whoever decides on suppliers, tolerable downtime or acquisitions also decides on cyber risk. The CISO advises, helps reduce risk and escalates.<\/li>\n
Metrics must support decisions.<\/strong> Muhlert recommends presenting evidence in three parts: what has been demonstrated, which assumptions remain untested and what will be tested next.<\/li>\n
Suppliers matter in a real incident.<\/strong> Access, recovery and reachability need to be clarified and practised. A certificate does not answer these questions for every business relationship.<\/li>\n
Delegated authority is the underrated AI risk.<\/strong> Muhlert warns of premise injection and audit debt, meaning automated decisions that nobody can reconstruct any more.<\/li>\n<\/ul>\n<\/div>\n
\n
<\/div>\n
\n
In this interview<\/div>\n
Matthias Muhlert<\/div>\n
Group CISO of the Oetker Group, Chair of the ECSO CISO Community<\/div>\n<\/div>\n<\/div>\n
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.<\/p>\n
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.<\/p>\n
Responsibility stays with the board<\/h2>\n
\n
Question 01<\/p>\n
Boards have heard about cyber risk for a decade. What do most of them still get wrong in 2026, and what would you want every board member to understand?<\/p>\n<\/div>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n\n
A metric a board cannot act on is decoration.<\/blockquote>Matthias Muhlert, Chair of the ECSO CISO Community<\/figcaption><\/figure>\n
\n
Question 02<\/p>\n
When you brief a board, which three numbers or statements do you bring, and which ones do you deliberately leave out?<\/p>\n<\/div>\n
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.<\/p>\n
A result without its test conditions tells only half the story. \u201cA compromised account cannot reach production administration\u201d is a claim. \u201cIn test X on date Y, the account reached layer Z and no further\u201d is a concrete finding with clearly visible limits.<\/p>\n
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.<\/p>\n
\n
A proposal for the board briefing: evidence in three parts<\/p>\n
\n
✓<\/span>What has been demonstrated and under which conditions<\/li>\n
✓<\/span>What will be tested next, with a date and an owner<\/li>\n<\/ul>\n<\/div>\n
\n
Question 03<\/p>\n
Budget round 2027: many boards are cutting IT budgets. How do you argue for security spend in a year like this?<\/p>\n<\/div>\n
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.<\/p>\n
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.<\/p>\n
What NIS2 and the CRA change in a real incident<\/h2>\n
\n
Question 04<\/p>\n
Germany’s NIS2 implementing act has been in force since 6 December 2025, and the Cyber Resilience Act’s manufacturer reporting obligations began on 11 September 2026. Where do these rules make your organisation safer, and where do they add paperwork without security?<\/p>\n<\/div>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
\n
The key dates at a glance<\/p>\n
\n
6 Dec 2025<\/div>\n
Germany’s NIS2 implementation act enters into force.<\/div>\n<\/div>\n
\n
11 Sep 2026<\/div>\n
The manufacturer reporting obligations under the Cyber Resilience Act apply.<\/div>\n<\/div>\n
\n
1 Oct 2026<\/div>\n
The ECSO CISO Meetup opens at the Estrel Berlin.<\/div>\n<\/div>\n<\/div>\n
\n
Question 05<\/p>\n
What should European policymakers hear from CISOs before the next regulatory round?<\/p>\n<\/div>\n
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.<\/p>\n
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.<\/p>\n\n
At three in the morning, the certificate will not answer the phone.<\/blockquote>Matthias Muhlert, Chair of the ECSO CISO Community<\/figcaption><\/figure>\n
\n
Question 06<\/p>\n
Supply chain: what do you require from vendors today that you did not require three years ago?<\/p>\n<\/div>\n
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?<\/p>\n
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.<\/p>\n
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.<\/p>\n
What the community should achieve in Berlin<\/h2>\n
\n
Question 07<\/p>\n
The ECSO CISO Community works under the Chatham House Rule. What kind of exchange becomes possible there that does not happen at conferences?<\/p>\n<\/div>\n
After someone says \u201cthis worked for us\u201d, 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?<\/p>\n
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.<\/p>\n
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.<\/p>\n\n
Before calling something a recovery capability, I want to know whether it still works when the hero is on holiday.<\/blockquote>Matthias Muhlert, Chair of the ECSO CISO Community<\/figcaption><\/figure>\n
\n
Question 08<\/p>\n
Ransomware case studies are a fixed part of the Meetup. What is the one lesson from real incidents that rarely makes it into official guidance?<\/p>\n<\/div>\n
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.<\/p>\n
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.<\/p>\n
\n
Question 09<\/p>\n
AI: which AI risk is overrated in board conversations right now, and which one is underrated?<\/p>\n<\/div>\n
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.<\/p>\n
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.<\/p>\n
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?<\/p>\n
\n
Two terms from the interview<\/p>\n
Premise Injection:<\/strong> manipulating the propositions an agent treats as grounds for reasoning and action<\/p>\n
Audit Debt:<\/strong> the growing inability to reconstruct the actions and authority behind automated decisions<\/p>\n<\/div>\n
\n
Question 10<\/p>\n
What should a CISO take home from Berlin on 2 October?<\/p>\n<\/div>\n
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.<\/p>\n
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.<\/p>\n
Berlin is where those conversations can begin. Their value becomes clearer when we see what people actually do afterwards.<\/p>\n
\n
ECSO CISO Meetup 2026<\/p>\n
1 and 2 October 2026 \u00b7 Estrel Berlin<\/p>\n
The Meetup of the European Cyber Security Organisation (ECSO) takes place on 1 and 2 October 2026 at the Estrel Berlin.<\/p>\n
\n
\n
Who it is for<\/p>\n
It is aimed primarily at CISOs, Deputy CISOs and their teams.<\/p>\n<\/div>\n
\n
Participation<\/p>\n
Participation is subject to approval of the registration. It is free of charge. Travel and accommodation are at the participants’ own expense.<\/p>\n<\/div>\n<\/div>\n
![\"Matthias](\"https:\/\/www.securitytoday.de\/wp-content\/uploads\/2026\/09\/ecso-ciso-meetup-interview-matthias-muhlert-portrait-hero.jpg\")
<\/div>\n\nIn this interview<\/div>\nMatthias Muhlert<\/div>\nGroup CISO of the Oetker Group, Chair of the ECSO CISO Community<\/div>\n<\/div>\n<\/div>\n![\"\"](\"https:\/\/www.securitytoday.de\/wp-content\/uploads\/2026\/07\/ciso-board-reporting-kennzahlen-aufsichtsrat-cover-hero-250x143.jpg\")
<\/span>Editor’s Pick<\/span>Five Metrics the Supervisory Board Actually Understands<\/span><\/span><\/a>![\"\"](\"https:\/\/www.securitytoday.de\/wp-content\/uploads\/2026\/07\/konzentrationsrisiko-vierte-partei-lieferkette-cover-hero-250x143.jpg\")
<\/span>Editor’s Pick<\/span>The concentration risk no supplier audit sees<\/span><\/span><\/a><\/p>\n![\"\"](\"https:\/\/www.securitytoday.de\/wp-content\/uploads\/2026\/09\/net-nis2-organhaftung-nachweis-registrierung-50596877-250x143.jpg\")
<\/span>Digital Chiefs<\/span>NIS2 liability for management boards applies despite registration<\/span><\/span><\/a>![\"\"](\"https:\/\/www.securitytoday.de\/wp-content\/uploads\/2026\/09\/net-enisa-gibt-die-cra-meldung-ohne-csirt-pr-89978765-250x141.jpg\")
<\/span>MyBusinessFuture<\/span>Manufacturers Report CRA Incidents to ENISA Ahead of the CSIRT<\/span><\/span><\/a><\/p>\n