Thursday, March 24, 2011

Is Risk assessment just change resistance?

An interesting thing about risk management is that providing risk assessment results to business will often be seen as reactive and resistant behaviour by the business. Let's see how risk assessment results are usually inserted within the context of a business initiative:
1. Business requests something (to IT, operations, product development, whatever)
2. Project or Initiative is defined and it triggers a risk assessment, according to the organization's security policy
3. Risk assessment is conducted and the results are presented to the business for decision (accept/mitigate/freak out/whatever)
So, the interesting aspect in this sequence of events is that, by the Business's perspective, the report with the results from the risk assessment seems to be a direct reaction from its request. This will frequently cause the impression of "I had asked someone to do something and they came back telling me why it shouldn't be done". In other words, resistance to change, one of the biggest sins in business. Isn't it easy to understand why those presenting the risk findings are not seen as "saviours" by the business, as some of us would probably picture themselves?
There are some ways to reduce these effects. The first one is to avoid FUD or any of those black magic (that's for you, Rothman) style risk measurement methodologies. If you are in a situation where your work is being seen as resistance to change, the worst thing you can do is do it in a way you cannot defend the presented results.
Another thing to be done is raise awareness in the business about the importance and role of the risk management process within the organization. The most important thing about this step is that it must be top-down. Business executives won't buy it if it's not their boss telling them they should manage the risks related to their initiatives. You can try, but you won't be able to succeed if it's not properly done in terms of economic incentives. The executives should have as much incentives to manage the risk of their initiatives as to make them successful. In fact, the definition of a successful initiative must comprise appropriate risk management.
The last suggestion is related to the roles in the process. It's common to have, for example, "Product" asking "Operations" to do something, and then "Security" going back to "Product" with a Risk Report. Can you see what is happening? The business (a.k.a "Product") sees "Operations" as those who will deliver what it wants, and "Security" as those trying to avoid that. How can we fix it? The risk assessment results should not be presented by Security to the business. The risk report should be part of the business case (or whatever artifact is presented to the business for approval), together with all other costs and expected results. And, of course, presented by those who will make it happen, not Security alone. 
We'll always be generating data that brings the executives wishful thinking about their pet projects down to reality. There's not much we can do about it, but we can at least avoid or reduce the impression that we do it just to react against change.