Talking about information security without mentioning risk management is like talking about literature without mentioning Shakespeare or philosophy without mentioning Socrates. While every info-sec professional worth his salt will know his threats from vulnerabilities, the actual designing of a risk management program in an organization is often neglected. Most organizations hire consultants to define a methodology for them and dive into identifying threats, vulnerabilities and risks in reams of excel. ISO 27005:2008 tries to correct this process. It says boldly: “The context is established first. Then a risk assessment is conducted.” OCTAVE mentions a step “Establish Impact Evaluation Criteria” before getting into details of assets, threats, et al. Most standards mention the need for establishing some sort of context before conducting a risk assessment. So what exactly does an organization have to do to establish the context for a risk assessment? The basic objective of establishing the context of risk management is to know the risk appetite, or the level of risk that an organization is willing to accept for itself. How does one find that out? Here, I think ISO 27005 has on of the best ideas on how to establish context and hence will elaborate more on that, in a way that I think is the most implementable. To be able to calculate the risk appetite, the organization needs to know what exactly does it mean by ‘risk’ to business. Here, the lines between ‘risks’ and ‘impacts’ start to blur. For example, “not being able to maintain transaction logs” would lead to the risk of ‘regulatory or legal penalties’. “Server crash during peak usage” could lead to the risk of ‘loss of goodwill’. Effectively, what the organization is trying to capture is its impact criteria. What will be the impact of a risk materializing on the organization’s finances, reputation, legal, regulatory and contractual obligations, etc? As you can see, things are starting to get murky. Let us take a step back and rethink. As an organization, I need to know my ‘risk appetite’. To know my risk appetite, I need to know what ‘impacts’ me the most. So, I make a list of the types of impacts that would be the most damaging. How do I do that? I get all the senior management team into a room (I can visualize those who have tried to set such a meeting before it before roll their eyes and say ‘there goes one month in the project plan’) and ask them what will cause the most damage to the organization. A simple list of the basic impacts can be prepared as a starting point.

•  Revenue
• Reputation and Goodwill
• Legal and Regulatory Obligations
• Contractual Obligations

The senior management will choose the most critical ones and add a few of their own. I now have your ‘impact criteria’. Now, I need to know what types of risks do I consider? Should i consider all the risks in the universe? Should I focus on a few key risks, a few key assets? So, before the senior management walks our of that room, I put in another question for them to discuss. “Should we do a risk assessment based on the strategic value of our business processes? Or should we do a risk assessment based on the criticality of information? This should trigger another round of discussions and debate. I would probably end up with another list:

• Evaluate risks for all business processes
• Focus only on the critical assets defined by the process owner
• All risks that affect the customer have to be addressed in detail
• Any risk to our reputation should be treated with the highest priority.

What we have just defined are our risk evaluation criteria. A final step that needs to be done before that slippery management team moves out of the meeting is ensure that they decide what sort of risks will be accepted and at what levels (Risk Acceptance Criteria). For example: “Approvals of any risks that affect productivity for more than 1 day will be approved by the executive vice president”. Armed with these three lists, an organization can begin its quest to assess risks!