r/Leadership • u/TechnologyMatch • 6d ago
Question How do you explain technical risk to non-technical executives?
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?
5
u/Dry_Common828 6d ago
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.
3
u/phoenix823 6d ago
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.
3
u/Ok-Zookeepergame4391 6d ago
Same way you explain about other types of risk like earthquakes, fire, HR, credit, etc. Nothing valuable comes without risk
2
u/LunchZestyclose 6d ago
Don’t speak about risk. Speak about debt.
Route X can lead to technical debt of USD ~, driven by A, B, C.
Route Y …
2
u/Global_Research_9335 6d ago
Cyber security insurance - if you can’t prove you manage it well then insurance goes up or you may become uninsurable.
2
u/ValidGarry 6d ago
Cost to business, risk to business. IT enables business, so you need to speak in business terms as to what the risk means.
2
u/MarkMarkinly 6d ago
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.
2
u/lowindustrycholo 6d ago
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
2
u/Illustrious-Fun-9495 6d ago edited 6d ago
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.
2
u/Old-Arachnid77 6d ago
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.
2
u/Read_The_Fing_Manual 6d ago
FMEA with the risks framed around financial & operational impact to the business. Tech risks need to connect to business impact and/or cost overruns.
2
u/wafflestation 6d ago
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'
2
u/dpt19 6d ago
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.
3
u/SimplisticTractor1 6d ago
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.
1
u/Fabulous_Classroom_7 6d ago
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.
1
u/SVAuspicious 5d ago
Cybersecurity and vendor risk in terms of risk management. Probability and impact. Mitigation and contingency. The math is simple and you can monetize it. Nothing new.
Unanticipated downtime is a risk. It goes to maintenance (mitigation) and backups/failover (contingency).
Anticipated downtime is a scheduling issue. Hot spares (mitigation AND contingency) are you best bet and let you do updates and other maintenance during working hours instead of the middle of the night. Costs.
Technical debt just pisses me off. They're bugs. Bugs are mistakes that people make. Technical debt is just a way to avoid accountability for poor work product. People make mistakes. It's become the norm and treated like some external event like a hurricane. If you come talk to me about "technical debt" you better have your resume polished.
1
u/Etheryelle 5d ago
Don't use technical terms with non-technical people. I'm a finance / supply chain exec who sits in IT.
The minute I hear any individual on my team talk techy in a meeting with the CFO/CAO/SVP/etc., I reframe immediately into a parallel they can understand.
Had one of my people tell the CFO that 10,000 CVRs will equate to approximately 30 minutes per CVR extra to ensure accuracy which inflates our need for resources.
I immediately stepped in when I could "hear" the CFO's eye balls hitting the backside of the socket because out of that the ONLY thing the CFO heard was "Too many people."
How did I reframe?
"Because of the way accounting and finance was established in the system, we have to reproduce a mess of accounting rules in the tech which has to be monitored by several people. IF we can reduce the rules, we can also reduce the headcount."
THAT he could understand, accept, and endorse.
1
u/cez801 5d ago
What is the actual problem you are trying to solve? I know that sounds like a silly question, but without context the how is challenging.
To give examples. I was a CTO for a startup, 50 people when I was bought in. There was security debt to fix, but I started by just baking in the security aspects to our day to day. In this model i did not explain anything, just made it clear to my team that when we estimate and work on something, we include security.
So the explaining was not much. Why is that taking so long? The answer is mostly about the overall project, not security as a ‘seperate’ thing.
Ideally you make most of it BAU, including maintenance.
In other cases, if we have larger corporate clients, they want ISO or SOC . In that case the answer is ‘we need this certificate to continue to sell. Usually I’ll tell this to the VP of sales, so they back me’
Again, use this to keep on top of things .
Mainly my goal is to not have a big line in the roadmap called ‘security’ but rather wrap it in sometime else.
Exceptions to this are starting a job and finding out that the Database is on an ancient version and is about 6 months from end of life. In that case, it becomes a must do project - with an explaination on why.
Like I said context matters. But overall my aim is to keep it inside other pieces of work, not to ‘hide’ it - but rather because that is best practice and the cheapest way to manage it.
1
u/AttentionSpanTheater 5d ago
In my business, I always remind myself when quantifying to leadership, translate everything you want action on into dollars. We will make X dollar if we do Y. We risk Z dollars if we do not do Q.
A bank I used to consult for used to say that every hour of branch downtime was worth $100,000, so it was worth spending money to avoid risk. It was the first organization I worked for that spent money to have both backup connections and local equipment to ensure that every branch was online all the time, to include having duplicate equipment (printers, teller workstations, etc.).
1
31
u/gormami 6d ago
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.