We’ve already looked at the ISO27001 risk assessment in the context of the ERM framework and in relation to the PDCA cycle. This chapter provides an overview of the steps that ISO27001 specifically requires, identifies some gaps, and introduces the additional best practice guidance available in ISO27002, ISO27005 and BS7799-3:2006 (BS7799).39
We want to remind readers, at this point, that there is an important difference between a specification and a code of practice. A specification, such as ISO27001, sets out specific requirements which, if followed, will allow a management system to receive a third party certificate of conformity. A code of practice, such as ISO27002 or ISO27005, provides guidance on best practice, but sets out no specific requirements against which a management system can be audited. It is not possible, therefore, for there to be a certificate of conformance with a code of practice.
ISO27001 contains a specification for the key steps in a risk assessment. Organisations seeking accredited certification to ISO27001 must – as a minimum – follow these steps. There are no other options. This is not a code of practice – it is a specification, a statement of requirements. You can do more than ISO27001 specifies and, in some areas, you’ll find that you need to – but you must, at the very least, do what is required.
A code of practice does provide useful guidance. It is not mandatory to follow the guidance, but there is some sense in taking advantage of work that has already been done in order to achieve better results, more quickly. You should remember, though, that whatever guidance you might turn to, no matter how useful it appears, it is the standard itself that counts. No matter what other experts, or even this book, suggest, it is ISO27001 itself that defines the one and only set of requirements that need to be met in order to develop and deploy an ISMS capable of accredited certification. The auditor should always turn to a copy of ISO27001 first and last in order to confirm what its requirements are.
ISO27002, ISO27005 and BS7799-3 are codes of practice. ISO27005 primarily provides best practice guidance on the implementation of the 133 controls that are in Annex A of ISO27001, but it does also provide limited guidance on risk assessment, some of which is useful in developing a risk assessment methodology. ISO27005 and BS7799-3, on the other hand, deal specifically with risk assessment and are sensible sources of additional information and guidance on areas in which ISO27001 is silent, but on which decisions will be required if the ISMS is to work in detail.
ISO27001 says that, first of all, ‘criteria against which risk will be evaluated’ must be contained within the ISMS policy (4.2.1 – b3). Within the context provided by the policy, the organisation must identify a suitable risk assessment methodology that takes into account identified business, information security, legal and regulatory requirements (4.2.1 – c1) and that the criteria for accepting risks and for identifying the acceptable level of risks are defined (4.2.1 – c2).
ISO27001 provides no guidance as to how an ‘acceptable level of risk’ should be defined.
While it is crystal clear on the steps that are required in the risk assessment, ISO27001 also provides no guidance as to what risk assessment methodology should be adopted although, as we said in Chapter 2, the expectation is that it will be a qualitative one. The standard is clear: the criteria against which risks should be evaluated should be established before the risk assessment is undertaken.
ISO27001 says that the organisation’s risk assessment methodology (which should reflect the organisation’s risk appetite and/or sit within the existing ERM structure, as we discussed earlier and as required by clause 4.2.1 – b3) must produce ‘comparable and reproducible results’ (clause 4.2.1 – c). This means that once the first risk assessment has been done, any subsequent risk assessments can be compared to it as a baseline or benchmark. As a consequence of this, once controls have been applied in the light of the risk treatment decision, the risk assessment could be repeated and the remaining, residual risks could be confirmed as being within the organisation’s level of risk tolerance and that, therefore, the ISMS is effective and the information security policy objectives are being achieved.
Once the risk assessment methodology has been defined, work can get under way. The precise risk assessment steps are that the organisation:
• identifies the assets (i.e. anything that has value to the organisation) within the scope of the ISMS, and the owners of those assets (clause 4.2.1 – d1);
• identifies the business, legal and contractual requirements that are relevant to the identified assets;40
• values the identified assets, taking into account the confidentiality, availability and integrity of the assets in each of their business, legal and contractual contexts;
• identifies the threats to the identified assets (4.2.1 – d2);
• identifies the vulnerabilities that might be exploited by those threats (4.2.1 – d3);
• analyses the impacts that losses of confidentiality, integrity and availability may have on each of the assets in each of their business, legal and contractual contexts (4.2.1 – d4);
• assesses the ‘realistic likelihood’ of these impacts occurring (4.2.1 – e2); and
• estimates the risks to the assets, using these factors (clause 4.2.1 – e3).
This estimation of the level of risk – what we call the ‘risk equation’ and which we discuss further, below – is achieved by first assessing the business, legal/regulatory and contractual impacts on the organisation of security failures (taking into account the consequences of a loss of confidentiality, integrity or availability), then assessing the realistic likelihood of the failure occurring for the given threats and vulnerabilities and (where appropriate) the controls currently implemented.
The relationship between these attributes is reflected in the diagram below. It assumes that there is an estimable likelihood that an identified threat will exploit an identified vulnerability; if it does, there will be an estimable impact and the product of impact and likelihood gives rise to the risk level. Whether or not that level of risk is acceptable depends entirely on the organisation’s risk acceptance criteria.
Clause 4.2.1 – e4 of ISO27001 then requires the organisation to determine which of these risks are acceptable and which require treatment in light of the criteria set out at the start of the process (at 4.2.1 – c).
The standard then requires you to ‘identify and evaluate’ options for the treatment of the risks (4.2.1 – f) and provides four possible headline options for this treatment. These are in line with our description in an earlier chapter and are to:
• knowingly accept the risks, providing they satisfy the organisation’s policies and risk acceptance criteria, i.e. they are within its level of risk tolerance or risk appetite; or
• apply appropriate controls (treating the risk) to reduce the risk to an acceptable level; or
• reject or avoid the risks, by, for example, finding a work-around; or
• transfer the business risks to other parties.
The risks that require treatment through the application of controls (option 2, above) are then handled in accordance with section 4.2.1 – g. Each risk is treated through the selection of a control objective and supporting control(s) that will meet the requirements identified by the risk assessment process and which will take account of the over-riding risk acceptance criteria, as well as the legal, regulatory and contractual requirements. Controls act to reduce likelihood and/or impact and the objective of the control selection process is to select controls that will bring the identified risk below the previously defined level of risk tolerance, as shown in the risk treatment matrix opposite:
The penultimate step in the ‘plan’ stage of the initial ISO27001 Plan-Do-Check-Act cycle is the production of a Statement of Applicability, the list of all the controls identified in Annex A of ISO27001 and a statement (together with a justification) as to whether or not that control has been applied within the organisation’s ISMS.
Formal management approval is then required for the Statement of Applicability, for the proposed residual risks, and for the implementation of the selected controls and operation of the ISMS.
Let’s now take a more detailed look at each of the key stages in the risk assessment process.
39 BS7799-3:2006 Information Security Management Systems – Part 3: Guidelines for information security risk management; see www.itgovernance.co.uk/products/162.
40 While this and the subsequent step are not clearly mandated by ISO27001, the requirement of clause 4.2.1 – b2 ‘takes into account business and legal or regulatory requirements, and contractual security obligations’ can only practically be met by addressing them at this point. This approach is precisely in line with the recommendations of BS7799-3, clause 5.3.
3.145.112.187