The general ethos of the ISO/IEC 27001 standard is to be proactive in managing information security and a central concept to this is risk assessment. This involves considering what could go wrong and then taking steps to do something about it in advance rather than waiting for it to happen. The standard points out that not everything that happens is necessarily negative and that there may be positive “opportunities” along the way too.
The whole idea of a risk-based approach is that the amount you spend on controls is appropriate to your level of risk and also takes account of how much risk you are prepared to live with. Risk is very much a spectrum as the wider debate on “privacy versus security” shows and your organisation will need to take a considered approach to the level of controls it chooses to introduce and maintain to provide the “right” level of security. An ISO 27001 risk assessment needs to be conducted to analyse and evaluate the impact and likelihood of various events occurring. This will give you the opportunity to do something about those risks that are both likely and have a significant impact i.e. to treat the risks.
Choosing a risk assessment method
There are many ways of analysing risk and the ISO/IEC 27001 standard mentions that another standard, ISO 31000, should be used as a framework for this. ISO31000 is worth a read and sets out how to establish an organisation-wide framework for risk assessment, not just for information security purposes but for all potential risks to the business. But ISO31000 itself doesn’t go into detail about how risks should be identified; there is yet another standard that does, which is ISO31010. You may realise from this that risk assessment is a very big subject in itself and there are very many techniques available to use if you choose to; ISO/IEC 27001 doesn’t dictate which one to use and our recommendation is that you keep it as simple as possible, depending on the size of your organisation and how much time you have.
The original version of the ISO/IEC 27001 standard (published in 2005) required that an organisation take an “asset-based” approach to risk assessment. This involved focussing on the organisation’s information assets and then considering the threats to them and their vulnerabilities to those threats. The 2013 version of the standard removed the requirement to take this approach, although it remains a perfectly valid way to assess risk. In the Toolkit we have provided a choice of an asset-based approach and a simplified scenario-based approach; either is compatible with the standard and it is up to you to decide which one works best within your organisation. Both risk assessment processes are compatible with the ISO31000 standard.
Identifying the risks
Effective risk identification can often be done by simply getting the right people with the relevant knowledge in to a room and asking them about what they worry about most with regard to their area of responsibility. This should give you a good starting point to assess the risks that they identify. Consult other parties such as external consultants and authorities where appropriate to get as good a picture as possible.
Risk assessment
The identified risks may be entered into the Risk Assessment Tool which helps you to assess the likelihood and impact of each risk, giving a risk score. The workbook uses a defined classification scheme to label each risk as high, medium or low risk, depending on its score. A template Risk Assessment Report is provided in the Toolkit to communicate the findings of the risk assessment to top management and so that they can sign it off.
Risk treatment
Whether or not each risk needs to be treated depends upon the risk appetite you defined in section 4.1 of the ISO/IEC 27001 standard (Understanding of the organisation and its context).
For those risks that do need treatment there are three main options:
1. Mitigate – take some action to reduce the likelihood or impact of the risk
2. Avoid – stop performing the activity that gives rise to the risk
3. Transfer – get another party to assume the risk (e.g. insurance)
Each of these options will have some effect on either the likelihood or impact of the risk, or both. The Risk Assessment Workbook allows you to define what effect you believe the treatment will have in order to decide whether it is sufficient.
Once the risks have been identified, assessed and evaluated, the risk treatment plan is created. Again the Toolkit has a template plan which may be used to obtain top management approval of the recommended risk treatments, some of which may involve spending money. Top management also need to agree to the levels of residual risk after the treatments have been implemented (i.e. the risks we’re left with once we’ve done everything proposed).
Statement of applicability
At this point the standard requires that a specific document called the “Statement of Applicability” be prepared which shows which of the reference controls in Annex A have been adopted and which haven’t. Each decision to adopt or not must be justified, usually by reference to a specific risk you have found that needs to be treated. Some of the reference controls will only apply in certain circumstances so if these don’t apply to your organisation (or your ISMS scope) then it is acceptable to state that you are not implementing them.
Examples might be that Control A.6.7 Remote working may not apply if you have no remote workers or Control A.8.25 Secure development life cycle may not be relevant if no software development takes place.
Conclusion
The key point to remember in treating risk is that it is a trade-off. Few organisations have limitless funds and so the money spent in treating risk needs to result in a larger benefit than the cost. There are many ways of performing this kind of “quantitative” analysis so that the potential loss from a risk can be expressed in financial terms. The methods used in the ISO27001 Toolkit are “qualitative” in that they simply categorise the risks; if your organisation wishes to use more detailed quantitative methods to assess risk loss against cost of treatment then that is perfectly acceptable within the ISO/IEC 27001 standard.
