- Executive management withholds budget because they perceive IT security as a cost center rather than risk management. This perception gap can be closed.
- Translate technical risks into business risks: euro amounts, production downtime, and contract risks instead of CVE scores and firewall rules.
- NIS2 makes executive management personally liable. This is the strongest lever for an honest conversation about cybersecurity investments.
- A single annual meeting isn't enough. Regular, short touchpoints keep the topic on the agenda and prevent unpleasant surprises.
- A one-page management summary per quarter that covers risks, progress, and open items is more effective than any 40-slide presentation.
Why Executive Management Often Says No
You probably know the situation: you've prepared a solid risk analysis, the vulnerabilities are obvious, the recommendations are on the table. And yet nothing happens. Executive management nods politely, says something like "That sounds important, let's look at it next quarter," and turns back to daily business.
This isn't malicious intent. It's a perception gap that exists in most companies — one that you must actively close. Executive management thinks in terms of revenue, margins, market share, and liability risks. You think in terms of vulnerabilities, attack vectors, and security controls. Both perspectives are valid, but they speak different languages.
The core problem is rarely that the C-suite considers IT security unimportant. Most executives have understood that cyberattacks are a real risk. What they lack is a tangible understanding of what exactly that means for their company, how high the financial risk actually is, and how investments relate to that risk.
There's also a psychological effect at play: as long as no serious incident has occurred, the current security level feels adequate. "We've never had an incident" is a phrase nearly every ISO has heard. The fact that the absence of incidents isn't proof of good security but may simply be luck is hard to convey in the abstract.
Once you understand this dynamic, the picture becomes clear: this is not a communication problem in the narrow sense. It's a translation problem. And the solution isn't to pile more technical details on the table, but to deliver the right information in the right format.
Finding the Right Language: Risk in Euros, Not CVE Scores
The most important paradigm shift you need to make: don't talk about technology — talk about business risks. This doesn't mean you should hide technical details. It means you need to contextualize them.
An example: "Our Exchange servers are unpatched and have three critical CVEs" is technically correct but meaningless to the C-suite. "Our email system has known security vulnerabilities that attackers can exploit to read all emails and inject malware. A comparable attack caused three weeks of production downtime at a competitor" is the same issue, but in language that resonates.
The translation almost always follows the same pattern: translate the technical risk into a business impact, then back it up with a concrete figure or a comparable incident.
Quantifying Financial Risks
You don't need to calculate an exact damage figure, but you should be able to provide a plausible order of magnitude. There's a simple framework that works even without elaborate risk analysis:
Direct costs of an incident. Forensics consultants charge between 200 and 400 euros per hour, and a typical ransomware case requires a team of three to five specialists for two to four weeks. Add recovery costs, potentially new hardware, and external communication expenses (lawyers, PR consultants). Even for an SME, this quickly adds up to 150,000 to 500,000 euros.
Revenue loss from business interruption. Take your company's annual revenue and divide it by 365. That's the theoretical daily revenue. A ransomware attack paralyzes a company for an average of 22 days. Even if you conservatively estimate only 50% revenue loss, a company with 20 million euros in annual revenue faces roughly 600,000 euros in losses.
Contractual penalties and customer loss. Review the contracts with your key customers: are there SLA agreements with penalties? Are there customers who contractually have the right to terminate if a security incident occurs? What would losing your largest customer mean? These figures are often alarmingly concrete and very persuasive.
Fines and regulatory consequences. With NIS2 and DSGVO (GDPR), there are clear legal frameworks. NIS2 provides for fines of up to 10 million euros or 2% of global annual revenue. You don't need to dramatize this, but you should mention it.
When you calculate these four categories for your company and lay the numbers side by side, the total exposure is typically well above the budget you're requesting. And that's exactly the point: your investment request is suddenly perceived not as a cost, but as risk mitigation.
NIS2 Liability as a Door Opener
Since the NIS2 Implementation Act, there's an argument that changes virtually every conversation about IT security budgets: the personal liability of executive management.
Section 38 of the NIS2 Implementation Act (NIS2UmsuCG) stipulates that managing directors and board members must oversee the implementation of cybersecurity measures and are personally liable if they fail to fulfill their duties. This is not an abstract possibility but a concrete legal requirement with severe consequences.
In practical terms, this means: if a security incident occurs and it turns out that adequate measures were not implemented, executives can be held liable with their personal assets. The company may not waive a claim for damages against management. You don't need to use this argument as a threat, but you should put it on the table clearly and factually.
The most effective way to address the topic is this: explain the NIS2 requirements factually, show which ones your company already meets and which it doesn't, and then clearly state what investments are needed to close the gaps. The subtext is obvious without you having to spell it out: if executive management rejects these investments and an incident occurs, the personal liability is documented.
Additionally, it's worth raising the management training obligation. NIS2 requires that governing bodies participate in cybersecurity training. This is not optional — it's a legal obligation. A short, well-prepared training session for executive management can simultaneously serve as the starting point for a more productive conversation about budgets, because it improves their understanding of the subject matter.
The Concrete Conversation Template
A good conversation with executive management about IT security budgets follows a clear structure. Here's a template you can adapt to your company:
Phase 1: Setting Context (5 Minutes)
Don't start with problems — start with context. Briefly show the current threat landscape with a focus on your industry. Use two to three recent incidents at comparable companies, ideally from BSI situation reports or industry publications. The effect: executive management understands that this isn't about abstract threats but about real risks affecting companies like their own.
Phase 2: Presenting the Status Quo (5 Minutes)
Show the current state of IT security at your company. Not as a deficiency list, but as an honest assessment: what's going well, where are the gaps, how do we compare against regulatory requirements? Use simple traffic-light logic (green, yellow, red) for the most important areas. Nobody wants to read a slide with 47 measures, but an overview with eight areas and clear color coding works.
Phase 3: Risks in Euros (5 Minutes)
This is where the financial risk assessment from the previous section comes into play. Show the total exposure and contrast it with the current security budget. When a company faces a risk exposure of 2 million euros and spends 50,000 euros per year on IT security, the discrepancy is obvious.
Phase 4: Concrete Proposal (5 Minutes)
Don't present a single solution — present three options with different investment levels and risk reduction:
Option A: Minimum. The absolutely necessary measures to meet regulatory requirements and address the biggest risks. Lowest cost, but only partial risk reduction.
Option B: Recommended. A solid security level that covers the essential risks and offers a good balance between investment and protection. This is the option you actually want.
Option C: Optimal. Best-practice level with comprehensive coverage. Highest investment, but also maximum risk reduction and future-proofing.
Experience shows: in most cases, Option B is chosen, sometimes with individual elements from Option C. By offering a choice, executive management feels involved rather than ambushed.
Phase 5: Next Steps (2 Minutes)
End the conversation with concrete next steps, responsibilities, and deadlines. No conversation should end without a clear "Who does what by when?"
ROI Arguments That Actually Work
Return on investment is a concept that executive management understands and values. With IT security, however, ROI works differently than with a new production line: you don't calculate the profit a measure generates, but the loss it prevents.
Risk Reduction as ROI. If a risk analysis shows that the company faces an annual loss expectancy of 500,000 euros from cyberattacks, and an investment of 80,000 euros reduces this risk by 60%, the ROI is clear: 80,000 euros in investment statistically prevents 300,000 euros in damages per year.
Insurance premiums. Cyber insurance is becoming increasingly expensive, and requirements for policyholders are rising. Companies that can demonstrate an ISMS receive better terms. Depending on company size, the savings on premiums can refinance a significant portion of the ISMS investment.
Customer requirements and tenders. More and more companies, especially in the automotive, healthcare, and financial sectors, require their suppliers to demonstrate an ISMS or certification. Without this proof, you're out of the running for tenders. This isn't a hypothetical risk — it's a concrete revenue loss you can quantify.
Efficiency gains through standardization. A structured ISMS reduces the effort for recurring tasks: instead of starting from scratch for every customer audit, you have up-to-date documentation. Instead of reacting ad hoc to every incident, there's a defined process. These efficiency gains can be translated into saved work hours.
Competitive advantage. This sounds like a soft argument but is measurable: companies with demonstrated information security win tenders they would have lost without proof. Ask your sales team how often the question about security certifications comes up in customer conversations. The answer will interest executive management.
Reporting Formats That Executive Management Actually Reads
The best security program in the world is worthless if executive management doesn't read the reports. And let's be honest: most security reports go unread. Not because the C-suite is disinterested, but because the reports are too long, too technical, and insufficiently action-oriented.
The One-Page Management Summary
The most effective format is a one-page management summary containing the following elements:
Overall risk indicator. A single number or traffic-light color summarizing the current security status. The C-suite wants to know at a glance: are we in good shape or not?
Top 3 risks. No more. Not the complete risk landscape, but the three biggest risks with one sentence of description each and the planned measure. More details are available on request.
Progress since last report. What was implemented, what's in progress, what's still pending? Ideally as progress bars or percentage values for the most important initiatives.
Budget status. How much was spent, how much is still available, are there unexpected costs? Executive management wants to know whether the budget is on track.
Action needed. Are there decisions that executive management needs to make? If so, which ones and by when? Formulate these as concrete questions, not open topics.
KPIs That Executive Management Understands
Forget technical metrics like "number of blocked attacks" or "average patch time." The C-suite can't do anything with those. Instead, use KPIs that directly relate to business objectives:
- Percentage of employees who completed security awareness training (target: 100%)
- Number of open audit findings past their deadline (target: 0)
- ISMS maturity level on a scale of 1 to 5 (target: at least 3)
- Number of security incidents with business impact (trend: decreasing)
- Compliance status against NIS2/ISO 27001 in percent
These KPIs are understandable, measurable, and show progress or need for action at a glance. ISMS Lite generates clear dashboards and management summaries directly from the maintained ISMS data, so quarterly reporting is no longer manual busywork. 500 Euro pro Jahr that's a fraction of the cost you present to executive management as risk mitigation.
Regular Touchpoints Instead of a One-Time Presentation
The biggest mistake you can make: give one big presentation per year and then not bring up IT security with executive management for another twelve months. By the next presentation, the topic is forgotten, priorities have shifted, and you're starting from scratch again.
Instead, you need a regular rhythm that keeps the topic continuously on the agenda without overwhelming the C-suite.
The Recommended Rhythm
Monthly: Short status update (15 minutes). Can take place as part of an existing management meeting. Five slides maximum: overall status, completed measures, current risks, action needed. No deep dive — just the essence.
Quarterly: Management Review (45-60 minutes). A structured review meeting, which ISO 27001 also requires. This is where KPIs are discussed, trends analyzed, budgets reviewed, and strategic decisions made. This is the right setting for larger investment decisions.
Semi-annually: Strategic alignment (90 minutes). Where does the threat landscape stand? How is the regulatory landscape evolving? Do our priorities still fit? Do we need a strategic adjustment? This meeting ensures the security program keeps pace with the corporate strategy.
Ad hoc: For incidents or urgent topics. Clearly defined thresholds at which executive management is immediately informed. This should be documented in the incident response plan so there's no debate about when and how to communicate in an emergency.
Establishing the Rhythm
The trick is to agree on the rhythm early and anchor it as a recurring calendar appointment in executive management's calendars. Start with a short format and expand it as the C-suite shows interest. Regular 15-minute sessions are better than an annual 90-minute session that gets cut short or rescheduled.
Common Objections and How to Counter Them
There are several standard objections you should be prepared for:
"We're too small — nobody would attack us." Attacks today are automated. Ransomware groups scan the internet for vulnerabilities and attack every vulnerable system, regardless of company size. The BSI situation report shows that SMEs are disproportionately affected because they have fewer protective measures. Moreover, NIS2 defines applicability based on sector affiliation and size, not on a subjective assessment of the threat landscape.
"We already have a firewall and antivirus." That's like a door lock without an alarm system: better than nothing, but not adequate protection against organized attackers. Modern attacks bypass technical measures through social engineering, compromised supply chains, or zero-day vulnerabilities. Technology alone isn't enough — you need processes, training, and systematic risk management.
"We can handle that internally." In many cases, that's partially true. But: do you have the capacity? Is someone with the necessary expertise on board? And most importantly: is someone freed up enough to drive the topic with the required priority? If the IT department is supposed to handle the ISMS "on the side," it won't work. Do an honest resource analysis and show what's possible internally and where external support would be more efficient.
"That costs too much." Compare the investment with the risk exposure. Show the costs of an average security incident in your industry. And ask the question: "How many days of production downtime can we afford?" The answer usually makes clear that investing in prevention is a fraction of the potential damage costs.
"We have other priorities." This is often the most honest objection and simultaneously the most difficult one. Here it helps not to argue against other priorities, but to position IT security as a prerequisite for those priorities. Digitalization without security? Expansion into regulated markets without compliance? Winning new customers without security certification? IT security isn't a counterargument to other priorities — it's their foundation.
What You Should Avoid
Just as important as the right arguments are the right manners in conversations with executive management. There are some patterns that are guaranteed to steer the conversation in the wrong direction.
Avoid FUD (Fear, Uncertainty, Doubt). Fearmongering might work once, but it destroys trust and credibility. If you predict doom every quarter and nothing happens, you'll eventually stop being taken seriously. Stay factual, work with facts and probabilities, not worst-case scenarios.
No blame games. "If you don't give us budget and something happens, it's your fault" may be factually accurate, but it's not a productive contribution. Instead, frame it as: "With the current budget, we can address these risks; these remain open. I'd like to document this decision so we have transparency."
Not too many details. Executive management doesn't need to know how a buffer overflow works. They need to know what the consequence is and what can be done about it. Keep the details in reserve for follow-up questions, but don't unload them uninvited.
No solo acts. Involve other stakeholders: the CFO for budget questions, sales for customer requirements, the legal department for regulatory topics. When the message comes from multiple directions, it carries more weight.
The First Step: How to Start the Conversation
If you haven't yet had a structured conversation with your executive management about IT security, the first step is often the hardest. Here's a pragmatic approach:
Prepare a short briefing — two pages maximum — covering the following points: the current threat landscape for your industry (two to three sentences), regulatory requirements with a focus on NIS2 liability (three to four sentences), three concrete risks for your company with estimated financial impact, and a concrete proposal for next steps.
Request a 30-minute meeting. Word the invitation to spark interest without causing alarm: "I'd like to briefly discuss the current cybersecurity requirements for our company and make a proposal for how we can position ourselves well."
In the conversation itself: listen more than you talk. Ask about executive management's priorities and show how IT security supports those priorities. And end the conversation with a concrete next step, even if it's just a follow-up meeting.
Because the goal of the first conversation isn't to get the full budget. The goal is to start a dialogue that continues regularly. Budget and buy-in come when executive management understands why IT security is a management task and not purely an IT topic. And you build that understanding step by step, not in a single meeting.
