You can’t always get what you want. As an engineer though, it’s your job to determine what’s best for the company and recommend it to management. What happens if your suggestion gets turned down? Well certainly your proposal must have been mis-understood, right? Maybe the decision-makers don’t truly understand the risk involved in not following your recommendation, whether that be financial, security, or otherwise. But maybe they do understand – and not only do they understand but they’re willing to accept that risk.
Risk acceptance is something that I’ve seen misunderstood by engineers over and over again. Especially when you’re earlier in your career, you get the feeling that you know what you’re doing – and therefore management should listen to you. I get it – I’ve been there too. It can be hard to propose an idea, then have that idea immediately shot down by your peers or management. That’s not to say that they aren’t listening, but maybe you might not have a great view of everything behind their decision.
Let’s take an example. As an engineer (server/network/security/etc), you’ve been alerted by your vendor that there is a huge vulnerability in a critical business application. That vendor has been extremely proactive, and has promptly provided you with detailed KB articles and download links to the upgrade package. The vulnerability that’s been disclosed certainly seems bad enough – it allows for remote code execution by an unauthenticated user. What do we do with this? Well we immediately meet with management to tell them that we need to patch this application immediately.
Their answer?
No.
Well that seems just impractical, doesn’t it? They don’t really want to leave the company at a massive risk to attack, do they? No – they certainly don’t. However, it may be that management has chosen to accept the risk for one reason or another. Let’s dig into a few reasons why they might:
Expense (Money) – It could be that the cost to remediate the issue is significant. Maybe the software is a bit out-dated and the company hasn’t paid for support. Renewing that support contract might be tens of thousands of dollars or more. If there are enough mitigating factors, that cost might not be worth it.
Expense (Time) – People also cost money, and time spent on fixing this issue also means lost productivity on other tasks. For some enterprises, an upgrade of a critical business application could take months of work. What happens when this new version breaks compatibility with another business application? Well now we’ve added on extra time so we can upgrade both. If there is no other value to the upgrade, then the fix might be held until there is.
Mitigating Factors – There may be enough other security controls in the network to reduce risk. Maybe in this case only the core servers for this application are affected – and they reside on their own network segment behind a firewall. Maybe that firewall also runs an intrusion prevention system, which has already been updated with signatures to stop this particular attack. There could be a number of things going on which have given management the comfort that the system is still safe.
Any of these might lead to the final decision: we’re going to live with this risk. By accepting it, we’ve evaluated it, we’re aware of it, and we are consciously choosing not to fix it. We may have limited the scope of this risk via other mitigations – but ultimately we are not completely ridding ourselves of this risk.
Does risk acceptance only apply to security? Nope. It applies to just about anything really. What if I recommend that we need to replace older hardware or risk network instability? That risk could be acceptable if the hardware isn’t critical. Same thing goes if we decide to forego renewing support on a pair of firewalls. Maybe it’s even suggesting an implementation of a new technology. Proposing to a big cloud provider that they should prepare for IPv6? There is a good chance they may still accept the risk of IPv4 depletion 🙂
As an IT engineer, it’s not just our job to keep things running and get projects done – it’s also our responsibility to keep the best interests of the business in mind when it comes to design, implementation, and maintenance. We need to evaluate all our options and always recommend what we think the best path is. However, we also need to respect that our recommendations may not always be followed. There may always be something else going on that we’re not aware of.
One last piece of advice I can give – If there is ever something you feel very strong about, get the final decision in writing. If you truly feel that the risk is too great, and you’ve made your pitch that has still been rejected – get the decision in writing (whether email, chat log, etc). This may seem silly at the time, but it’s better to be safe. People forget, whether intentionally or not – and if the risk becomes a reality, you don’t want to give them any reason to put the blame on you.