John Bruggeman, CISSP, consulting (CISO) for CBTS and OnX, both are MSPs and MSSPs.
Why do cybersecurity professionals struggle to explain cyber risks to the executive team? Sometimes cyber risk is ignored because executives underestimate security. Often though, it is ignored because the risk arrives in a language leadership doesn’t understand and can’t act on.
The security team is correct that a protocol like TLS 1.0 is outdated, or that a critical 9.8 vulnerability in a load balancer needs remediation, or a generic authentication identity creates exposure. But if the explanation starts with technical details that only IT uses on a daily basis, with severity scores and security acronyms, the business decision can get lost before the leaders understand what is at stake. I have seen that happen literally hundreds of times, and I have been guilty of diving into the technology (which I love), at the expense of giving the executive team the information (not jargon) that they need.
Fifteen years ago, I learned that lesson and I have changed how I describe risk. You don’t have to believe me, though. That communication gap is becoming harder to tolerate; it’s actually a risk itself. Gartner’s 2026 CIO research points to a leadership agenda shaped by scaling AI, optimizing AI cloud investments and defending against AI-enabled cyber threats.
The Five Eyes cyber agencies recently sharpened that pressure by warning that cyber-risk assumptions can become outdated in months rather than years as frontier AI advances. If you are reading this article now, you know you need to stay current with the evolving risks and rewards of adopting AI.
For CISOs, that creates a very real and very practical operations problem. Security teams know where the risk is and how to address the risk, but CEOs and CFOs need to understand what a specific vulnerability or design flaw could mean in terms of lost revenue or increased legal liability. The CEO needs to know what choices they have to address the risk.
In enterprise environments, the hard part is often getting the fix approved, scheduled and implemented without disrupting the systems employees and customers use every day. Operations folks don’t like down time, and security improvements usually require some downtime to patch, upgrade or change a configuration. There is almost always tension between the operations folks and security folks, and not because the two teams don’t like each other. They just have different goals. So how do we address this communication issue?
Step One: Upskill the translator.
The first action leaders can take is to provide training for security and IT teams so that the teams can explain business consequences without technical detail. Technical precision matters, but a vulnerability becomes actionable when leaders understand what the risk is if they wait.
When an IT team raises a risk, the first explanation should connect the issue to the business function it supports. If an outdated protocol creates exposure, the conversation should quickly move to what business process depends on that protocol and the business risk that follows if the system is not upgraded. If a control requires funding, the explanation should show what risk the company has while that control remains unfunded. If a patch is delayed, the team should be able to explain which part of the organization absorbs the risk or impact if that unpatched system becomes an incident.
Framing risk this way helps teams and leaders make better judgment calls. A severity score or risk rating that security teams use to indicate how serious a technical vulnerability or finding appears is not the whole story. A medium-rated access issue on a customer-facing system deserves attention before a critical finding on an isolated test server. Knowing which vulnerability should be addressed first requires experience; explaining it to leadership requires great communication skills.
Step Two: Create the business-impact brief.
Once teams are trained to translate risk, leaders should give them a consistent vehicle for doing it. A business-impact brief changes how IT thinks and communicates. Now cybersecurity issues need to answer the same practical question: What decision does the business need to make?
A strong brief should answer the following questions which will help the IT team think business rather than technology:
1. What business process, customer-facing function or critical system is affected?
2. What could happen if action is delayed?
3. What decision is needed now?
4. Who owns the application and who fixes it?
5. What risk remains after remediation? What is the residual risk?
Where possible, the brief should also quantify the potential business impact if the recommendation is not followed, such as lost revenue, operational downtime, regulatory exposure or client attrition.
Consistency makes it easier to compare risks across teams and over time, helping the organization prioritize the issue that needs action first, not just the one that sounds most urgent. This is important. Being consistent will help the cybersecurity team and leadership, and what might sound urgent to the executive team could be a moot point for the IT team because the risk isn’t really present due to other security tools in place.
Step Three: Force the risk decision.
Once a cyber issue has been translated into business terms and packaged in a decision-ready brief, the executive team needs to decide who owns the fix. This is where many organizations lose momentum: The risk is understood, but no one wants to own the problem. Or it’s not clear who owns the system and can approve the change.
Leaders can make this practical by keeping cyber risk as part of the agenda of each ELT meeting. The security brief should name the remediation owner, the expected decision, the timeline for action and the business dependency that could slow the work. Using this method changes the conversation from “security found a problem” to “the business has a decision to make.”
Organizations that move the fastest will be the ones where technical teams and executives meet in the middle, not because one side learned the other’s vocabulary, but because both met in the middle. Security teams own the translation into business impact. Executives own the decision that follows.
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?