CIO risk-taking 101: Playing it safe isn’t safe

As CIO, you’re in the risk business. Or rather, every part of your responsibilities entails risk, whether you’re paying attention to it or not. And in spite of the spate of books that extol risk-taking as the only smart path, it’s worth remembering that their authors don’t face what might be the biggest risk CIOs have to deal with every day: executive teams adept at preaching risk-taking without actually supporting it.

There are, for example, those in leadership roles who, while promoting the value of risk-taking, also insist on “holding people accountable.” If this is a popular phrase in your company’s executive suite, risk-taking is a phantom virtue. To stay out of harm’s way, charter a few harmless initiatives — ones that aren’t likely to succeed, will pass the cool test if, in the off chance, they do happen to succeed, but won’t do much damage if they fail.

Promote these initiatives to your execs with polished PowerPoints that make it clear they’re in line with the company’s risk-taking culture. You’ll get credit for taking risks when they launch. When they do, in fact, crater you can either remind the company leadership that the initiatives were supposed to fail in the first place, or you can hold the initiative’s leaders accountable — a layer of insulation that gains you credit for the hard job of holding someone accountable without the consequences of being the one blamed for the failure.

Pro tip: Put the staff members and sponsor who annoy you the most in charge of these initiatives. Worst case they succeed, and people you don’t like now owe you a favor or two. Best case they fail and will be held accountable. You can’t lose.

Taking risks vs. dealing with risks

Those who encourage risk-taking often ignore its polysemy. One meaning: initiatives that, as outlined above, have potential benefit but a high probability of failure. The other: structural risks — situations that might become real and would cause serious damage to the IT organization and its business collaborators if they do.

You can choose to not charter a risky initiative, ignoring and eschewing its potential benefits. When it comes to structural risks you can ignore them as well, but you can’t make them go away by doing so and will be blamed if they’re “realized” (the risk-management term for “becoming real”).

To illustrate, some examples:

Applications portfolio rationalization: The most fundamental guiding principle of technical architecture management is to fill each required service exactly once. If your applications portfolio isn’t rationalized — that is, if it includes multiple, functionally overlapping capabilities — that creates a need for a geometrically expanding collection of synchronizations, along with a bunch of other vulnerabilities.

An unrationalized application portfolio, and for that matter poor rationalization of the other architecture layers, creates, in a word, “risks.”

Rationalizing the applications portfolio reduces the odds of these risks being realized. In risk management terms it “prevents” (aka avoids) them.

Identity management: Modern security architectures include tools for managing identity — for authenticating staff, assigning them to roles, and assigning rights, privileges, and restrictions to those roles, not to the individuals who fulfill them. Manage identity poorly and the wrong people will be in a position to do the wrong things.

Instituting sturdy identity management practices reduces the odds of a variety of risks becoming real — and also reduces the damage should a risk become real in spite of the organization’s preventive measures.

In the lexicon of risk management, prevention is about reducing the odds. Mitigation is about reducing the damage.

Ransomware: While artificial intelligence has pushed ransomware off the front page, it’s hardly gone away, and the risks associated with falling prey to an attack haven’t changed at all.

The steps you need to take to deal with ransomware risks include all four risk/response strategies: They prevent (reduce the odds), mitigate (reduce the damage), and insure you from the worst outcomes (insurance is about sharing the costs).

And if we’re honest with each other, our response also includes a healthy dose of the fourth risk response — acceptance, also known as “hope.”

Limitations to risk responses

No matter what you do, your responses to risk won’t be perfect. Specifically:

Prevention: Prevention reduces the odds of risk realization. It doesn’t eliminate them. In the end, the risk either will or won’t become real. If it does, guess who will be held accountable?

And if it doesn’t, another irrefutable law of IT risk will take hold: Successful prevention is indistinguishable from absence of risk. Which is to say if your preventive measures work, you’ll be found guilty of having cried wolf — of inflating the risk.

Mitigation: Mitigation is about reducing the damage should a risk be realized. Just as your preventive measures can’t be perfect, neither can your mitigations. If a risk is realized, your mitigations are unlikely to eliminate harm completely, and you can count on being blamed for whatever harm leaks through.

And if by some chance your preventive measures are completely successful you’ll be blamed for wasting budget and effort on unnecessary mitigations.

Insurance: You know how this plays out. If you buy insurance and the risks it covers aren’t realized you’ll be blamed for the money wasted on premiums. And if they are realized you’ll be blamed for unsuccessful prevention and insufficient mitigation.

Risk’s bottom line: Even if your company’s executive team genuinely prizes risk-taking, the risks they prize have nothing to do with the important risks you have to deal with, day in and day out.

There’s no point in quibbling. Just make sure you keep your conversations about risky initiatives and managing structural risks separate. Otherwise you’ll run the twin risks of missed opportunities and endangering the business.