Select a Risk Management Methodology
What method to use
A risk analysis method can be found in the 'Méthode Optimisée d’analyse des risks Cases' (Monarc). A more detailed approach can be found in ISO 27005:2011.
Your risk analysis can be very simple, or can be very detailed. Everything depends on the size of your organisation, the complexity of the projects and the sensitivity of the data that you handle. However, do not underestimate the work involved, because even if a project appears simple, the associated risks could be significant. Therefore, there is no correlation between the size of a project and its associated risks. In order to check the accuracy and comprehensiveness of your risk analysis, it has to be verified by different people in your organisation.
A Risk can be:
- Accepted: The Impact and Likelihood is too insignificant to take any further action
- Avoided: Based on the potential impact and likelihood, you decide not to continue your project
- Transferred: You contract a 3rd party to handle the impact of the risk. This can be insurance or e.g. a managed service provider
- Mitigated: You implement sufficient controls, in order to reduce the risk to an acceptable level
The result of your risk analysis will be your security plan, you must prioritize security measures that need to be established in order to have an implementation plan that can be approved by management.
Generally, organisations are free to choose the methodology they want to use, provided it meets a certain number of minimum requirements in terms of confidentiality and objectivity.
A risk analysis method can be found in the 'Méthode Optimisée d’analyse des risks Cases' (Monarc). A more detailed approach can be found in ISO 27005:2011, ISACA's COBIT for Risk or the NIST Risk Management Framework.
Risk assessment methodologies are either Qualitative (low-medium-high) or Quantitative (Financial Value)
Qualitative IT risk assessment
Qualitative risk assessment is opinion-based. It relies on judgment to categorise risks based on probability and impact and uses a rating scale to describe the risks as:
- low - unlikely to occur or impact your business
- medium - possible to occur and impact
- high - likely to occur and impact your business significantly
For example, you might classify as 'high probability' something that you expect to happen several times a year. You do the same for cost/impact in whatever terms seem useful, for example:
- low - would lose up to half an hour of production
- medium - would cause complete shutdown for at least three days
- high - would cause irrevocable loss to the business
Quantitative IT risk assessment
Quantitative assessment measures risk using monetary amounts. It uses mathematical formulas to give you the value of expected losses associated with a particular risk, based on:
- the asset value
- the frequency of risk occurrence
- the probability of associated loss
In an example of server failure, a quantitative assessment would involve looking at:
- the cost of a server or the revenue it generates
- how often does the server crash
- the estimated loss incurred each time it crashed
From these values, you can work out several key calculations:
- single loss expectancy - costs you would incur if the incident occurs once
- annual rate of occurrence - how many times a year you can expect this risk to occur
- annual loss expectancy - the total risk value over the course of a year
These monetary results could help you avoid spending too much time and money on reducing negligible risks. For example, if a threat is unlikely to happen or costs little or nothing to remedy, it probably presents low risk to your business.
However, if a threat to your key IT systems is likely to happen, and could be expensive to fix or likely to affect your business adversely, you should consider it high risk.
You may want to use this risk information to carry out a cost/benefit analysis to determine what level of investment would make risk treatment worthwhile.
Keep in mind that quantitative measures of risk are only meaningful when you have good data. You may not always have the necessary historical data to work out probability and cost estimates on IT-related risks, since they can change very quickly.