How do CIOs take risks and deal with risks?

Source: Enterprise Network D1Net

The risks advocated by the executive team have little to do with the dangers that CIOs face every day. However, trying to avoid these dangers may be even more dangerous for the CIO's career.

As a CIO, you are in the midst of risky business, or more accurately, every one of your responsibilities involves risks, whether you pay attention to them or not. Despite a series of books praising risk-taking as the only wise path, it is worth remembering that these authors have not faced the biggest risks that CIOs must deal with every day: an executive team that promotes risk-taking but does not actually support it.

For example, some leadership teams advocate the value of risk-taking while also insisting on "holding people accountable." If this is a common phrase used by your company's top management, then risk-taking is a virtual virtue. To avoid danger, you can initiate some harmless projects—projects that are unlikely to succeed, and if they happen to succeed, they will pass through cool testing, but if they fail, they will not cause much damage.

Present these projects to your executives in a carefully crafted PowerPoint, clearly indicating that they align with the company's risk-taking culture. When the projects are launched, you will be recognized for taking risks. When they actually fail, you can remind the company leadership that these projects were supposed to fail, or you can hold the project leader accountable—this layer of protection allows you to be recognized for holding people accountable without bearing the consequences of being blamed for failure.

Professional tip: Make those employees and sponsors who annoy you the most responsible for these projects. The worst-case scenario is that they succeed, and now the people you don't like owe you a favor or two. The best-case scenario is that they fail and will be held accountable. You won't lose anything.

Risk-taking and Risk Management

Those who encourage risk-taking often overlook its ambiguity. One meaning is: as mentioned above, plans with potential benefits but a high probability of failure. Another is structural risk—situations that could become reality and cause serious harm to the IT organization and its business partners.

You can choose not to initiate a risky project, ignore and avoid its potential benefits. When it comes to structural risks, you can also ignore them, but you cannot make them disappear by doing so. If they "materialize" (in risk management terms, "become a reality"), you will be blamed.

Here are some examples:

Rationalizing application portfolios: The most basic guiding principle of technology architecture management is to precisely fill each required service. If your application portfolio is not rationalized—meaning it includes overlapping capabilities—there will be a demand for exponentially growing sets of synchronization and a series of other vulnerabilities.

An irrationalized application portfolio, along with poor rationalization at other architectural levels, can be summarized in one word: risk.

Rationalizing application portfolios can reduce the likelihood of these risks materializing. In terms of risk management, it "prevents" (i.e., avoids) these risks.

Identity management: Modern security architecture includes tools for managing identities—used to authenticate employees, assign them to different roles, and allocate rights, privileges, and restrictions to these roles, rather than to individuals performing these roles. If identity management is not properly handled, the wrong people may be in a position to do wrong things.

Establishing sound identity management practices can reduce the probability of various risks materializing and can also reduce the damage when risks materialize, even under the organization's preventive measures.

In risk management terms, prevention is about reducing the probability of risk occurrence, while mitigation is about reducing the damage caused by risk occurrence.

Ransomware: Although artificial intelligence has brought ransomware into the headlines, it has by no means disappeared, and the risks associated with ransomware attacks have not fundamentally changed.

The steps you need to take to address the risk of ransomware cover four risk/mitigation strategies: they prevent (reduce the likelihood of occurrence), mitigate (reduce the damage), and provide insurance to protect you from the worst outcomes (insurance is to spread the cost).

If we are honest with each other, our response measures also include the fourth risk response approach—acceptance, also known as "hope."

Limitations of Risk Response

No matter what you do, your response to risk will never be perfect. Specifically:

Prevention: Prevention reduces the probability of risk occurrence. But it does not eliminate risk. Ultimately, the risk will either materialize or not. If it does, guess who will be held accountable?

If it does not, another indisputable rule of IT risk will come into effect: successful prevention is no different from the absence of risk. In other words, if your preventive measures work, you will be blamed for falsely reporting risks—crying wolf.

Mitigation: Mitigation is about reducing damage when risk occurs. Just as your preventive measures cannot be perfect, your mitigation measures cannot be either. If the risk materializes, your mitigation measures are unlikely to completely eliminate the harm, and you can expect to be blamed for any residual damage.

If your preventive measures are completely successful, you will be blamed for wasting budget and effort on unnecessary mitigation measures.

Insurance: You know how this will play out. If you purchase insurance and the risks covered by the insurance do not materialize, you will be blamed for wasting money on insurance premiums. If the risk materializes, you will be blamed for unsuccessful prevention and insufficient mitigation.

The bottom line of risk: Even if your company's executive team truly values risk-taking, the risks they value have nothing to do with the significant risks you must deal with day in and day out.

There is no point in arguing; just make sure to keep the discussion about risk-taking plans separate from the discussion about managing structural risks, otherwise, you will face the dual risks of missed opportunities and jeopardizing the business.