Risk management is not just CFO or IT. This posting from CIO Insight (really the accompanying slideshow) starts off in the right direction, but, considering the source of the survey, it doesn’t take long to backslide to the risks posed by 3rd party software and services. Actually, it notes dismissively that this risk is not listed as a primary risk, being set aside for risks such as having the system being unavailable when it is needed or allowing customer data to be compromised.
All too often an organization’s risk management practices (assuming it has any at all) fall into two extreme positions. Someone, usually a project manager because that’s how they are trained, develops a register of risks, perhaps with some mitigation measures, and (in the absence of contingency funds and other institutional support) that’s the end of that. Or, because that’s mostly the kind of story the news media covers in this tech-loving era, security issues are believed to reside with the CIO, whose information assurance minions pass on ever-more restrictive standards developed for massive governmental programs and slowly but surely choke the electrons right out of the organization.
IT is not the only department doing this. The purchasing shop cheerfully drives project managers into making unwise purchases because they’ve made it impossible to buy what is really needed in a timely manner. CFOs allow short-term cash-flow or stockholder/stakeholder report concerns to override making the investments that the organization needs to overcome the very same issues that is causing those very same reports to show lackluster performance. These are approaches set up to manage specific risks (purchasing improprieties, foolish investments) that have morphed into blindly-followed procedures that have lost their connection to the underlying concept (organizational performance ) that the risk management effort was trying to protect in the first place.
It is not (or should not be) the intent of the risk management practice to protect the organization from any and all risks, regardless of financial cost or, worse, mission failure. The idea is to enhance the likelihood of mission failure by recognizing and controlling (or controlling for) potential risk events. Scoffing at primary risk management objectives that quantify the business’ mission-related concerns simply proves the frequent charge from the business CXOs that the IT community simply doesn’t understand IT’s role as an enabling function rather than as the reason for the organization’s existence.
Well, OK, the survey was sponsored by an organization that (despite its “standards-setting” positioning) effectively sells its services in managing 3rd party risks. Nonetheless, the conversational arc is pretty common in the IT security rank-and-file. Leaders in the IT security community (notably the Federal government which somewhat drives this entire sector) have striven over the past couple of years to shift the Information Assurance concept from procedural compliance to actual risk protection. That effort has run into the predictable roadblocks from the entrenched bureaucracy that is quite happy with the checklist compliance approach, and the guidance that has emerged so far looks very much like the procedures that were in place before. Only the terminology is different.
So I’m going to endorse the idea that 3rd party providers should be an important part of anybody’s risk assessment process. Not just IT either: any time you involve a party you don’t control, there are bound to be some risks, and it’s not as easy to resolve them by firing people or throwing more resources at the problem, which one can do for internally managed functions. It is, however, just one of many categories of risk that the organization should consider.
An important part of the executive role is to take the responsibility for making subjective judgments, such as how to balance the risks. It’s not just IT. Should we transport our own products to the customer or lease someone else deliver them? Should we own our own buildings or lease them? The fact that these approaches have not become near-universal standards for a given industry tells you that there must be some risks no matter which way we go.
- On one hand, we have high-probability risk events such as “our staff may not know how to build this solution” and “potential competitors may be able to build it better and cheaper and beat us to the market.” That’s a pretty potent combination and the usual response is to outsource the work to somebody who knows what they are doing and can do it cheaper and faster than trying to do it ourselves.
- On the other hand, if we let a third party do work for us, we expose ourselves to risk events such as effectively conveying the end customer’s real requirements, running into latent defects, difficulty in adapting a vendor’s one-size-fits-all solution to our particular needs, potential security risks from letting essentially unknown personnel into our applications and networks, and the problem of becoming totally dependent on this vendor for the duration of the solution. Here’s another post that looks at the risks of this approach. The traditional resolution of those risks is to in-source the work so we can have greater control over it. Which of course take us back to Square One.
Obviously we can’t have it both ways. Somebody has to decide which side of this balanced scale to weigh more heavily, and that’s where the executives come in.
Risk management is a primary component of the enterprise-wide, mid-to-deep future perspectives that executives are supposed to bring to the organization. Without that, you could just eliminate them and let the middle managers operate the organization on a day-to-day basis.
In many cases, it’s a matter of culture change. Even from the top, it’s very hard to force a culture change. If the executives don’t walk the talk, it’s never going to happen. Why should it? People aren’t going to stick their necks out for a moral principle that top leadership appears not to endorse. It is possible to infuse culture change from the lower levels of the organization, although it takes time and delicacy. (You can consult Let It Simmer for extended discussion of how to go about that).