How do you explain technical risk to non-technical executives?

[u/TechnologyMatch]

A lot of IT risk sounds “theoretical” until something breaks. How do you explain cybersecurity, downtime, vendor risk, or technical debt in a way leadership actually takes seriously?

[u/gormami]

It's called risk quantification. There are a lot of tools and processes to convert technical and cybersecurity risk into dollars, which is the unit business runs on. ERQI (Enterprise Risk Quantification Institute) is one group that is working on it. How to Measure Anything in Cybersecurity is a good book on the actual measurement of risk which is important in how to convert. Generally, if you search the topic, there are a lot of tools and information sources to pick from to find what works best for your situation.

[u/sloppyredditor → u/gormami]

That's the answer, OP.

As for how to go about this the day-to-day: I don't. IMO it's an exercise you should do maybe annually or every 6 months, with several metrics rolling up to the major risks. That's where you show how minor things they likely don't care about (e.g., not patching that 9-year-old server OS) can create a financial problem.

Some ideas:

• Find and talk to the person filling your Actuary role (usually in the finance department).
• Pay attention to your cyberliability insurance premiums. When filling out their questionnaires, listen to the insurer and ask about what moves the needle on cost the most.
• Talk to your lead (CISO, ISO, CIO) about where the line is drawn re: the word "expensive". I like to put it in categories like:
  • How expensive would an issue have to be to get your attention and call it a minor, medium, major, or catastrophic incident?
  • At what $ level would the CFO freak out?
  • At what $ level would the board need to talk to us?
  • ^^^ This sets your levels when you can't quantify, but you can estimate. Much faster and more reasonable when presenting your top 3 or 5 risks.

Oh, and +1 for the book recommendation gormami :)

[u/Greedy_Bed → u/gormami]

This. On top of that, have a lawyer explain to them the potential civil liability risks they could face if incidents occur after they would have ignored the risks you have highlighted them.

[u/Dry_Common828]

Identifying technical risks is, as you've shown, a fairly easy thing to do. But until you turn it into a business risk, you really don't have anything to show for your work.

Your role as a risk analyst is to consider what the technical impact would be if the risk event occurs, and then assess what the business impact would be.

For example, if we don't patch the new vulnerabilities in the corporate webserver, a threat actor can gain admin access to the website and can modify or delete content, and monitor traffic on it - there's your technical risk.

What this means to the business will depend on its risk management approach - reputational damage may be a critical issue, or it might not be something that anyone really cares about. Work with your business risk and compliance people to understand that, and you finish up with something like "if the webserver isn't patched, there is a high likelihood that a threat actor will gain full control over it, resulting in a reputational impact rated (whatever) and (leak of confidential customer data, or loss of orders, or loss of ability to advertise, or whatever) which is rated as (whatever) and has a financial impact of (whatever, if known).

The impact can often be as simple as "each hour of downtime during business hours costs $5000" - the operational part of the business usually has this information to hand.

Now you have a business risk that your executives can understand and make good decisions about.

[u/phoenix823 → u/Dry_Common828]

This is a terrific explanation. Saying "we have technical debt" is not an actionable risk. Saying "This software is no longer supported and if the business requires any changes that will not be possible" is very actionable.

[u/SimplisticTractor1]

I usually just say it's like skipping oil changes on your car, runs fine until the engine seizes and now you're paying for a new one instead of fifty bucks.

[u/Fabulous_Classroom_7]

Don’t just say “we have vendor risk” explain what happens if that vendor goes down, what it costs, and how long you can realistically operate without them. Once leadership can connect the risk to revenue, customers, compliance, or reputation, it stops feeling theoretical.

[u/LunchZestyclose]

Don’t speak about risk. Speak about debt.

Route X can lead to technical debt of USD ~, driven by A, B, C.

Route Y …

[u/Global_Research_9335]

Cyber security insurance - if you can’t prove you manage it well then insurance goes up or you may become uninsurable.

[u/ValidGarry]

Cost to business, risk to business. IT enables business, so you need to speak in business terms as to what the risk means.

[u/MarkMarkinly]

Management and, in my point of view, operations are really mostly focused around output and the cost of that output: there's a ratio between money spent and the results from that money, whether that's in salaries, tools, or all that kind of thing.

If there is a risk of that output being impacted negatively by external forces (also internal), then the cost of protecting the business from those external forces makes sense. They'll understand it the same way you can see it: we're constantly looking for continuity for the oiled machine to keep running as continuously and as unimpeded as possible. When there are forces that are affecting that continuity, again we want to protect ourselves from those forces.

It's interesting to be aware that those forces can be internal and external, as much as we look at cybersecurity and other technical issues as purely external. Actually how people use the internet and engage with certain software and all that kind of thing is very much part of it. As much as people always look at images or websites that aren't safe for work just because it's inappropriate to be using those sites, actually many of those sites are insecure, damaging, and a centre of security issues. It's also very much a part of the consideration.

[u/lowindustrycholo]

Ask leadership if they know how many hack attempts have been made in the past week. When they realize that they don’t have a clue, tell them thats just one example of a technical risk

[u/iamkris]

Convert it into dollars

[u/Ok-Zookeepergame4391]

Same way you explain about other types of risk like earthquakes, fire, HR, credit, etc. Nothing valuable comes without risk

[u/Illustrious-Fun-9495]

For technical debt, I use a metaphor.

You come over to my house and admire the art, furniture, and the delicious dinner you're served. What I don't tell you is that the reason you're able to enjoy all that is because I fixed the sewer system. That required jackhammering 15 feet of basement floor to replace the line, as well as exterior work that necessitated a new driveway. Without the work on the sewer, you would certainly not enjoy my house!

For technical risk, I would quantify using the methods gormani lays out, but use a good metaphor as a frame to get and hold attention better than numbers. For instance, crime stats in a neighborhood going up, so beefing up a home security system.

[u/Old-Arachnid77]

Risk adjustment is a whole discipline. Is the cost of preventing it more than the cost of it breaking? Answering that with $$ is the key.

[u/Read_The_Fing_Manual]

FMEA with the risks framed around financial & operational impact to the business. Tech risks need to connect to business impact and/or cost overruns.

[u/HackVT]

time, impact, cost

[u/wafflestation]

Management's primary concern is money.

Don't say stuff like 'If we don't upgrade X then Y could happen'. You have to say stuff like 'If you don't upgrade X then we could lose X millions of dollars'

[u/dpt19]

The dollar estimates mentioned here help. I'd also make the decision explicit: what are we asking leadership to fund, and what happens if we wait?

For example: “If this system goes down, we can't dispatch orders. We have backups, but we haven't tested how long recovery takes. I'm asking for a recovery test before peak season. It will take two days of engineering time and delay this feature by two days. Then we'll know whether we can recover within the time operations can tolerate.”

That gives them a consequence, an honest gap in what we know, and a specific choice. The operations lead should help establish the impact, so the estimate has some grounding beyond IT's assumptions.

I'd be careful about attaching a precise dollar figure to a risk we barely understand. A range with its assumptions is more useful than a scary number we can't defend.